Data Services是专门化的Web Services。它允许您在SOA参考架构中定义特定于数据服务（以及其他专门化Web Services）角色和职责的设计模式和方法。我开发且已成功被几位客户使用的一个设计模式是“SCRUDI”。

当您考虑对数据使用的典型和传统操作范围时，往往可以总结成首字母缩写“CRUD”，即Create、Retrieve、Update、Delete。这就足够了。CRUD在数据领域是个熟悉的概念。如果考虑HTTP或REST中的操作，将得到GET、HEAD、PUT、POST、UPDATE、DELETE、OPTIONS、TRACE、CONNECT概念，大多数web开发人员都应该熟悉这些概念。熟悉使用Web进行搜索的用户还会熟悉web搜索的概念。在SOA中，您将功能组件化到服务中。在创建SOA解决方案时识别并定义服务及其交互和支持基础架构是常见的活动。服务还可能以接口（例如，WSDL）、格式（例如，XSD）、示例和文档的形式提供信息，以帮助潜在的服务消费者利用该服务。

实际上，Data Services结合了以上许多方面，也就是说，它们是面向数据/信息的专门化Web Services。现在，当您结合数据操作（CRUD）或使用HTTP/REST操作、Search与SOA Services以及信息时，最终将得到什么样的聚合呢？我将得到的结果称为“SCRUDI”，即Search、Create、Retrieve、Update、Delete、Information。考虑SOA中数据服务的基本能力、功能和使用上下文时，SCRUDI似乎能成功捕获Data Services实际需要执行的操作。如果HTTP或REST更适合您的方法，则也可以使用其中定义的操作（也就是以GET、PUT、POST等术语）描述SCRUDI。

定义Canonical Data（规范数据）或Information Model（信息模型）时，常常用到描述“域”概念的实体，例如Customer、Account、Address、Order等（这也是命名数据库表的常见抽象！）。在语义业务模型级别定义Data Services并提供SCRUDI功能，将拥有一组期望从提供数据/信息交互的服务中获得的核心行为。使用Customer作为示例，可以如下定义逻辑Customer Data Service：

服务名称：Customer

操作：Search、Create、Retrieve、Update、Delete、Information

然后就可以在WSDL中捕获和公开此服务定义。对于Logical Canonical Model(逻辑正则模型)中定义的每个实体，都可以使用相同的名称/粒度定义一个Data Service，并提供这6项操作。在一些情况下，还将提供识别信息。例如，在Search请求中，将提供匹配搜索标准，甚至可能支持正则表达式；对于Retrieve、Update或Delete，则可能提供惟一的标识符信息以获取、更新或删除特定信息。因为您的数据服务是专门化的web服务，所以可使用XML Schema Definition(XSD)来定义以上各个定义的请求和响应格式。在Customer数据服务示例中，使用文档样式方法的Retrieve结果将是符合Customer.xsd定义的XML文档实例。如果该架构中定义的Customer信息很庞大、复杂，或者您只希望Retrieve这些信息的子集，就会希望支持使用XQuery/XPath表达式的特殊查询，类似于关系数据的SQL功能。因为处于Web服务的上下文（或称为SOA中的Data Services），并且我们的数据格式为XML，所以使用XQuery/XPath比使用SQL更合适。

现在我们的Data Services表现了Canonical Model（正则模型）（粒度相同或相似），提供了一组标准的操作(SCRUDI)，并支持使用特殊查询来检索数据，这与XSD定义和特定的服务消费者需求一致。尽管模式简洁，但其功能非常强大。它是基本的逻辑模型/规范模型/数据服务设计模式。然后就可以考虑更高级的逻辑抽象，即使用这些数据服务来提供Application Specialization功能。例如，可以为Customer定义另一个包含getShippingAddress()操作（该操作使用客户标识符作为参数）的逻辑数据服务。然后，该操作的实现可以利用我们的Canonical Model Customer Data Service的Retrieve操作来传递同一个标识符和XQuery/XPath语句（用于获得所请求的运送地址信息）。如果使用文档样式，则将根据XSD以XML文档格式返回这些信息。Data Service消费者可以使用合适的抽象层，如果应用程序或一组应用程序有类似的数据需求，则可以为这组应用程序定义和使用一个Application Specialization。使用Application Specialization高级接口（例如，getShippingAddress()操作）的交互使用Web服务（数据服务）接口（例如WSDL），并且不要求直接了解/使用XQuery/XPath。定义的任何XQuery或XPath都将被封装、重用和优化……每个项目的每个开发人员都不需要精通XQuery / XPath，只需提供Application Specialization逻辑层数据服务的开发人员精通即可，这些服务与底层提供SCRUDI操作接口的逻辑数据服务进行交互。这是降低复杂性、TTM、成本并提高灵活性和重用的实用方式。

我为不同领域的若干客户成功地使用了此设计模式。该模式简单、强大并且灵活，我认为是SOA Data Services / Canonical Modeling实现的最佳实践。如果您的工作与数据服务有关，或需要与SOA/Web应用程序中的数据进行交互，就会希望了解如何对您的数据服务和规范模型设计应用SCRUDI设计模式。此外，考虑利用SCRUDI数据服务的Application Specialization，以充分发挥该方法的价值。

当然其价值不至于此。我在BEA咨询部门任职，因此如果您对研究该方法或组织的其他数据服务实现战略感兴趣，我乐意帮助您。请告诉我您如何看待该方法和数据服务设计模式，并且如果有什么问题，敬请告知。谢谢！

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号