UML软件工程组织

 

 

逻辑数据服务 – “SCRUDI”设计模式
作者:Richard Manning 来自:dev2dev.bea.com.cn
 

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号