架构Web Service:实战Web服务

内容：

案例需求描述

应用的系统架构

Catalog Service

Order Service

Feedback Service

交互，交互些什么?

为什么选择基于Web服务的解决方案?

什么是需要公开的?

参考资料

作者简介

相关内容：

基于Web服务的应用、解决方案和开发平台

什么是Web服务?

为什么需要Web服务?

动态电子商务模式

柴晓路 (fennivel@uddi-china.org)

Chief System Architect

2001年8月14日

（本文最初由 IBM developerWorks 中国网站发表，其网址是

http://www.ibm.com/developerWorks/cn/）

本文是架构Web服务的系列文章的第四篇，继探讨了Web服务的商业需求，技术定义和技术规范以及现有现有的Web服务实践之后，通过使用一个具体的案例开始对Web服务实战的篇章。在本文中给出了一个实际的具有实用性并且能够延伸出去的计算机产品交易市场的案例，通过简要的系统分析、模块划分，对松散系统间待交换的数据进行了界分，同时为定义基于Web服务的API的数据结构奠定了系统和分析的基础。在先前的文章系列里面，我已经对Web服务的商业需求、Web服务的技术实现以及Web服务当前的应用以及开发工具做了全面的介绍，那么在接下来的文章中，我将结合一个实例来详细地描述如何真正地规划、设计和创建一个Web服务的具体应用。

本文所引用的资源主要包括两类，一类是Web服务的技术资源网站，包含了大量Web服务的技术信息，另一类是Web服务“stack"系列技术规范，他们是一个整体的技术体系，包括UDDI、SOAP、WSDL、XML等。本文的最后给出了这些资源的链接，有兴趣的读者可以通过这些资源链接找到所需的内容。

生产商/零售商，这是直接销售计算机产品的商家，他能够通过自己的Web发布产品目录，同时也能将目录传送给计算机产品交易市场。他能够接受订单(来自自己的Web网站或者来自计算机产品交易市场)并转入内部管理系统，至于资金流和物流则由离线系统完成。 消费者，计算机产品的购买者(可能是个人，也可能是企业)，他能够访问计算机产品目录，能够利用在线的定购服务进行购买。 通过对以上角色及其行为的分析，我们认为在最终的实现系统中应该有这样几种概要层次上的对象：

产品目录，产品目录由生产商/零售商产生，由计算机产品交易市场汇总归类，由消费者浏览使用。 订单，订单由消费者生成，由计算机产品交易市场传递，由生产商/零售商接受。 反馈信息，由消费者产生，由计算机产品交易市场汇总归类，由消费者和生产商/零售商使用。 用户，用户分两类，一类是消费者用户，一类是生产商/零售商用户，分别用于处理两类事务。

大家可能会发现，Marketplace System和Retailer System这两个系统没什么大区别嘛? 的确是这样，我们在设计的时候应当无时无刻不能忘记"重用"这个概念，重用的组件越多，开发的代价就越少，维护的代价也越低，可扩展性也就越好，当然重用不能导致功能的异化，这也是我们需要注意的。

下面我花一点篇幅稍微解析一下框架中的三个主要服务：Catalog Service、Order Service和Feedback Service。

对于这个服务而言，Retailer System中的Catalog Service应当是Marketplace System功能的子集。Retailer System中，Catalog Service应当具备如下功能：

类别(Category)管理，包括增加一个Category、删除一个Category、修改一个Category等；

产品(Product)管理，包括增加一个Product、删除一个Product、修改一个Product、移动一个Product(从一个Category下移动到另一个Category下)等；

数据交换，包括单个类别下所有产品的导入导出(Import/Export)，单个产品数据的导入导出，整个类别树的导入导出等；

数据备份，整个目录下所有产品数据的备份/恢复等。

而Marketplace System中，需要增加一个功能：在数据交换和数据备份模块应当提供对指定数据拥有者的相关数据的操作，比如导出某个类别下IBM的所有产品等等。

对于这个服务而言，Retailer System中的Order Service和Marketplace System中的Order Service可以说基本没有什么本质上的差别。他们都将具备如下功能：

接受订单 向其他接受订单的服务发送订单 两者的区别，仅仅在于Retailer System中的Order Service接受的订单来自用户界面，而需要向Marketplace System中的Order Service传送。Marketplace System中的Order Service接受的订单来自Retailer System中的Order Service，而需要向自己内部的企业应用传送订单。

对于Feedback Service而言，在两个系统中的地位与Catalog Service是类似的。

反馈信息(Feedback)管理，包括增加一条反馈信息、删除一条反馈信息、修改一条反馈信息等，反馈信息可以挂在Category下，也可以挂在Product下(有针对一类产品的评测报告，也有针对一个产品的使用评价等)； 数据交换，包括与单个类别关联或与单个产品关联的反馈信息的导入导出(Import/Export)，以及与单个用户(Retailer用户，数据拥有者)相关的所有反馈信息的导入导出等； Feedback可以看作是与整个产品目录树的各个结点相关联的评论文章。不仅在Marketplace系统中由消费者发布并归消费者查询，同时也将在相关的Retailer系统保存并可供Retailer使用。

其中黄色的三个实体完全可以看成是一个树状的信息目录，其中有三个层次的结点：Category，Product和Feedback，Category的子结点可以是Category、Product和Feedback，而Product的子节点只能是Feedback，整个目录树的根结点是Category。

而对于每个Product而言，都有一个数据拥有者，这个数据拥有者应当是Marketplace中的一个Retailer帐号。

另一类实体是订单，对于一张订单而言，将可以包含多个Product的定购记录，以及定购对象：某个Retailer。

在系统之间交互数据是交互的第一层次：数据交换，然而对于Web服务而言，光光有数据交换是不够的，应当提供更高层次：服务集成的支持。

因此，交互的内容不光包括互相交互的数据，同时应当包含对数据的操作(比如数据请求，数据添加，数据更新等等)。这些往往会对应与服务端的一个处理模块。

无论是对数据的操作，还是数据本身，为了在系统与系统之间进行交互，尤其是异构平台之间，我们需要将所有的操作(服务调用)和操作的数据(服务调用的参数和返回值)进行规范化的描述，形成规范文档后发布以供所有需要参与互操作的系统共同遵守。

大家可能会说Retailer系统不也是我们来开发的么？是的，一部分，甚至可能是很大一部分Retailer系统可能用的都是与Marketplace系统同构的平台，而且只不过是服务模块少了几块而已。然而，我们是处在Internet的开放互联的时代，对于Marketplace来说，越多的Retailer的进入就代表着更多的商机，Marketplace的运营者一定会想尽办法招揽，集成更多的Retailer系统，那么与其每出现一个异构的Retailer系统就要运用人力物力与其进行单点集成的项目开发，不如制定一种规范，使得这些新加入的Retailer能够依照这些规范自主地加入系统。Marketplace同样具备海纳百川的能力，同时又不用指数倍地投入开发代价。

同时如果该规范成为一种公共接受的规范的话，其他的兼容该标准的Marketplace同样也可以出现，而遵循该规范的Retailer系统则可以广泛地以极低的代价接入到所有兼容该规范的Marketplace中去，获得更多的销售机会和渠道。甚至按照规范来实现，Retailer系统之间还能实现低代价的对等互联。可以说，依据规范的基于Web服务的服务集成是真正的按照Internet的开放互联理念的Internet时代的服务集成的方式。

Programmer's API：这是类似传统含义的API定义，不过承载的介质是SOAP Message，也就是说Programmer's API是一组SOAP API，不同的API用于完成不同的服务调用，在这部分中需要定义不同的SOAP API的行为和实现的调用/响应的功能描述； Data Structure：这部分定义了在SOAP消息中传输的参数/数据和响应数据的XML模式，这部分为每个API补充的消息格式，同时为最终的API处理提供了数据层解析/包装的规范。 在后面的文章中，我将就本文关注的这个Demo Case，一步一步地讲述如何定义Programmer's API和Data Structure。

UDDI-China.ORG, 以UDDI为主的Web服务技术网站。 WebServices.ORG, Web服务的综合类技术网站。 IBM developerWorks/Web Service Zone, IBM的Web服务技术资源中心 MSDN Online Web Services Developer Resources, Microsoft的Web服务的开发者资源网站 ITPapers/Web Service, ITPapers的Web服务评论文章 解决B2B电子商务应用交互和集成的InterOP Stack系列技术标准规范 UDDI执行白皮书, UDDI-China.org, UDDI.org UDDI技术白皮书, UDDI-China.org, UDDI.org UDDI程序员API规范, UDDI-China.org, UDDI.org UDDI数据结构参考, UDDI-China.org, UDDI.org Web Service Description Language (WSDL) 1.0, IBM, 25 Sep 2000 SOAP: Simple Object Access Protocol Specification 1.1, IBM, Microsoft, DevelopMentor, 2000 Extensible Markup Language (XML) 1.0 (Second Edition), W3C, 6 Oct 2000 架构Web services系列 架构Web Service(一): 为什么需要Web服务 架构Web Service(二): 什么是Web服务 架构Web Service(三):基于Web服务的应用、解决方案和开发平台 架构Web Service(五): 交互界面，Web服务定义的核心 架构Web Service(六):描述与注册，发布Web服务 柴晓路: 上海得易电子商务技术有限公司(DealEasy)首席系统架构师、XML技术顾问。UDDI-China.org蓝色火焰工作室(Blue Blaze Studio)成员。UDDI Advisor Group成员，WSUI Working Group成员。2000年获复旦大学计算机科学硕士学位，曾在国际计算机科学学术会议(ICSC)、亚太区XML技术研讨会(XML Asia/Pacific'99)、中国XML技术研讨会(北京)、计算机科学期刊等各类国际、国内重要会议与期刊上发表论文多篇。专长于基于XML的系统集成和数据交换的技术研究，同时对数据库、面向对象技术及CSCW等技术比较擅长。