|
我们将从一个典型的电子商务应用：供应链管理应用开始，阐述如何设计和实施基于Web服务体系的供应链应用。
这是一个简化的供应链应用，里面涉及到了两种商业实体，家用电子产品零售商和家用电子产品生产商。家用电子产品零售商向最终用户直接销售电器，具体的商品供应是由各个家用电子产品生产商供应。在这个场景中，涉及到了两个供应环节，分别位于消费者(最终用户)和零售商之间以及零售商与生产商之间。第一个环节是一个典型的B2C商务模式，实施的应用可以是一个在线购物的网站(Online Shop)。最终用户通过浏览器在在线购物网站中提交订单，实施电器购买的行为。第二个环节则是一个典型的B2B商务模式，零售商根据自己的订单情况，按需定期向生产商提交订货合同。具体的实现可能是零售商的订单管理系统和生产商的销售系统进行应用集成等。当生产商得到订货合同之后，需要根据总体的订货情况(当然还有其它的零售商向它订货)制订生产计划，并向它自身的零件部件供应商订货。这里为了简化描述，省略掉了向下游零部件供应商订货的这个环节，假设生产商自身就能生产产品了。图1演示了这一应用场景的结构。
其中家用电子产品零售商Artistic Consumer Electronics(简称ACE)是一个位于Art City的电器零售公司。它的供货商是Art City中的若干消费类家用电器制造商，我们称之为Manufactory A、Manufactory B……Manufactory N。ACE在整个城市中设置了多个仓库Warehouse A、Warehouse B……Warehouse Z，用于存放各个制造商的产品。原则上一个仓库主要存储一到两个制造商的产品(为简化流程，简单描述起见)。 （图片） ACE的整体运营流程可简单描述如下：
1. 购买者通过ACE的零售窗口(可能是某个销售在线网站)向ACE提交购买订单。
2. ACE零售窗口按照订货的类别向相关的仓库发出要货请求，仓库分别作出应答之后，零售窗口如果判断可以满足订货需求的，则响应购买者订货确认，同时向相应仓库发出运送请求。
3. 仓库接收到运送请求之后，确认运货请求，同时将货运出。运货流程完毕之后，检查库存，如果指定商品的库存水平位于临界值之下，则向相应的制造商发出订货请求。
4. 制造商接收到订货请求后，安排并检查生产计划和库存情况。如果可以满足则确认，并发货；如果无法满足则返回无法满足的响应。
案例分析
按照前面描述的需求，就可以界定这个系统了。其中主要考虑的对象是三个角色：客户(购买者)、零售系统(包括零售窗口和仓库)、制造商。其中包括的用例有这样5个：
UC1，购买商品，客户向零售系统购买商品；
UC2，运送商品，零售系统从仓库中核查并发出商品；
UC2，补充商品，零售系统应库存不足而向制造商请求补充商品；
UC4，供应商品，制造商应零售系统请求供应商品；
UC5，生产商品，当制造商库存不足，则生产商品。
由于本文的重点在于应用而不在于技术，因此Use Case的详细介绍就不在本文中给出了。我们先给出一些非功能性的需求假设，这是我们做最初步设计的基础。在做完初步设计之后，我们将逐步放宽限制，看看此时整体系统要做何种改进。
1. 单个订单可以包含多个描述项，每一项都针对某一特定的产品，同时包含了定购的数量。在一个订单中，同一个订单中同一种产品不可出现在两个不同的项中。
2. 订单项商品数量最小为1，最大无限制。
3. 对于一个订单而言，针对其中某一产品，只能做出能够满足或者不能满足的响应，不可有部分满足的响应。例如库存10个，订单要定购20个，只能作出不能满足的响应。
4. 对于一个订单而言，针对其中某一产品，只能从一个仓库送货，而不能由多个仓库组合满足其需求。这和第三点是相通的。
5. 要么订单被满足，要么订单被驳回，订单不会被缓存在等待队列中。
6. 关于实际的支付和配送环节，将不在本系统中涉及。
7. 制造商总能够满足ACE的订货，无论是使用现有库存来满足需求还是通过生产制造来满足。
8. 当来自客户的某个订单使得某个仓库的库存低于预设值，该仓库将向相应的制造商请求商品供应。
应用模块结构设计
按照前面的Use Case分析，我们可以将系统规划为如图2的体系。其中零售系统由三个组件组成：（图片） 1. Online B2C Web Application，这是一个提供在线定购的B2C网站应用。
2. Warehouse Service，提供零售系统的仓库管理，同时该服务提供Web服务接口。由于仓库管理系统的使用者(客户端)有多种，除定购系统外，还包括公司的财务系统、物流系统等其他系统，因此构架为Web Service将使得互操作更为灵活。
3. Logistics Service，提供零售系统中仓库所需的物流管理。同样该服务也提供Web服务接口，除与Warehouse Service类似的原因外，通过将Logistics Service的接口Web服务标准化。我们今后可以方便地将这个系统升级为使用第三方物流的模式。
而制造商系统则由四个组件组成：
1. Order Service，这是一个B2B商品定购的服务，接收来自零售商和代理商的商品定购服务，将其部署为一个Web Service，可以方便其与各个零售商和代理商的系统互相进行B2Bi(B2B Integration)。
2. Warehouse Service，提供制造商系统的仓库管理，同时该服务提供Web Services接口。由于仓库管理系统的使用者(客户端)有多种，除定购系统外，还包括公司的财务系统、生产系统、物流系统等其它系统，因此构架为Web Service将使得互操作更为灵活。
3. Logistics Service，提供制造商系统中仓库所需的物流管理，同样该服务也提供Web服务接口。除与Warehouse Service类似的原因外，通过将Logistics Service的接口Web服务标准化，我们今后可以方便地将这个系统升级为使用第三方物流的模式。
4. Manufactory System，制造商的生产系统。一般而言，这个系统早已经存在了。我们需要视需求将其提供的接口进行封装，但一般难度比较大，因此可以考虑在其他应用中使用目前可用的API进行调用。如果该平台技术允许的话，也可以进行技术改造。
服务接口设计——Warehouse Service
仓库管理是供应链管理中最为重要的几个组成部分之一。首先我们来定义这个Warehouse Service的Web Services接口。通过前面的分析，应该能够了解，在零售系统和制造商系统中的Warehouse Service是非常类似的。我们就从零售系统的Warehouse Service开始设计。
零售系统的Warehouse Service应当包含这样几类API：
◆ 设置更新指定产品的最大库存值和最小库存值；
◆ 查询指定产品的当前库存量；
◆ 商品入库；
◆ 商品出库。
setStorageLevel
设置更新指定产品的最大库存值和最小库存值的API消息为setStorageLevel函数调用。在一个setStorageLevel消息中，可以设置1到多个商品的库存值。具体可通过storageLevel子元素进行设置，其中minLevel(最小库存值)、maxLevel(最大库存值)可选择性地出现或不出现，若出现则表示要更新相应值的设置。而指定相关产品的方法是通过在storageLevel的属性productID中设置相应产品标识来实现。
queryProduct
查询指定产品当前库存量的API消息是queryProduct函数调用。通过传入1到多个productID，来请求返回这些商品的库存情况。该调用的返回消息是productInfos，包含了对应传入productID的多个productInfo元素。每个productInfo元素包含productID、minLevel、maxLevel和currentQuantity四个子元素。minLevel、maxLevel分别表示该商品的最小库存值和最大库存值，而currentQuantity则表示该商品的当前库存值。
importProduct和exportProduct
商品入库的API消息是importProduct函数调用。通过传入多个productIO元素，用于表示多个入库的商品及其数量。而相应的，商品出库的API消息是exportProduct函数调用。通过传入多个productIO元素，用于表示多个入库的商品及其数量。这里两种productIO元素分别引用了不同的复合类型：productImportType和productExportType。这两种类型都是继承了同一个复合类型productIOType。除公共表示产品和产品数量的productID和quantity元素之外，productImportType包含了额外的manufactoryID元素，用于表示生产商。而productExportType则包含了额外的userID，用于表示送货的定购用户。至于用户的送货信息等，则由用户系统来管理。
前面介绍了零售商系统的Warehouse Service，至于制造商系统的Warehouse Service，其importProduct和exportProduct两个API会有所差别。对于importProduct，不需要manufactoryID，因为总是自己工厂生产的；而exportProduct则应当使用零售商系统的warehouseID代替userID，其理由也是显而易见的。
前面给出的API是一个API原型设计。在具体使用时，对于不同的Warehouse，我们一般会使用同一个Service进行管理，那么warehouseID肯定是需要被传入的。对于这个需求，我们有两个选择：方案A是在API消息的根结点上加一个warehouseID属性，以区分对不同Warehouse的访问；方案B则是在服务入口的URL后面加上HTTP GET类型的参数(http://url/WarehouseService?warehouseID=xxx形式)。
Logistics Service
对于零售系统和制造商系统的Logistics Service而言，同样是非常类似的。对于零售系统而言，Online B2C Web Application通过查询Warehouse Service，确认相应的订单可以被满足之后，就调用Logistics Service，要求其从Warehouse中提出相应的商品，并发往指定用户。也就是说Logistics Service需要提供一个deliverProduct的API消息。在执行过程中，Logistics Service需要调用相应Warehouse Service的exportProduct函数从仓库出货。
而对于制造商系统而言，则是由Order Service驱动Logistics Service，要求其从Warehouse中提出相应的商品，并发往指定零售系统的指定仓库。同样在执行过程中，Logistics Service需要调用相应Warehouse Service的exportProduct函数从仓库出货。
第三方物流
在上面的讨论中，我们已经看见了Logistics Service在两个系统中的功能是类似的。如果将userID和warehouseID统一为destinationID的话，我们就可以很方便地将前述的模式拓展为第三方物流模式(如图3)。 （图片） 对于第三方物流模式而言，零售系统和制造商系统都不设物流系统，所有的物流服务由第三方物流公司负责。反映到系统上，也就是统一调用第三方物流的Logistics服务。
对于第三方物流，由于它不是企业内部系统，那么就应当提供丰富的查询功能，以备服务使用者进行物流状态查询。因此它需要提供一个Tracking Service，随时提供当前的运输状态。我们定义其Web Service方法名为trackTransportationStatus。
trackTransportationStatus
调用trackTransportationStatus函数时，应当传入一个SerialID。这是一个唯一标识了物流事务的编号，说白了就是通过这个ID能够和你在物流公司中获得的服务一对一挂钩。该服务接收请求消息trackTransportationStatus之后，查询数据库，如果SerialID正确，那么将响应transportationStatus消息。该消息会包含一系列的checkPoint元素，分别表示整个运输过程中的多个核检点。每个核检点的信息包括：date/time(时刻)、converyance(运输工具，即从上一个checkPoint到当前checkPoint所使用的运输工具)、auditor(审核人员)、location(运输到达地点)、description(备注)以及isDestination(是否是运输终点)。
第三方仓储
通过Web Services技术，我们可以很方便地将企业系统和第三方物流的系统进行连接。由于Web Services的平台无关性、系统无关性和语言无关性，因此使用Web Services接口的第三方物流系统可以很方便地被需要物流服务的企业所使用。使用Web Services技术使得第三方物流能够平滑无缝地与各个企业系统相集成。
考察了物流之后，我们可以来考察仓储系统。前面已经讨论过Warehouse Service在零售系统和制造商系统中是非常类似的。事实上，仓储系统在各种实体中的作用也是非常类似的。第三方仓储目前也是一种常用的仓储模式，即企业本身不使用仓库，而使用第三方仓储公司的仓库作为自身的仓储设施。参考第三方物流，我们得以将前面刚刚改装过的服务组件图进行再一次拆零，重新组装。组装正是Web Services的一大优点。通过标准的接口定义，Web Services组件组装可以无视实现平台和实现语言的差异，进行跨平台的灵活的服务组装。 （图片） 通过业务的重组，现在零售系统和制造商系统都使用了第三方物流和第三方仓储，如图4所示。通过Web Services技术，商业模式得以进行一次分拆式的革新，赋予了第三方物流/第三方仓储这类从传统业务体系中分离出来的商业实体更强的竞争优势。通过Web Services接口，从某种角度而言，它们已经能够与企业自身的仓储部门和物流部门展开直面竞争了。
协同会话
由于一个完整的事务需要跨越多个Web Service，甚至跨越不同商业实体的Web Services。在整个Web Service调用流中，应当具备会话机制，以跟踪整个事务的执行流程。例如，我们参照第三方仓储那节中的Web Services模型：
◆ 首先Retailer的Online B2C Web Application接受到一个客户的定购请求。
◆ B2C Web Application作为Web Service客户端调用Third-Party Warehouse的Warehouse Service，以查询并确定定购的商品在哪些仓库中有足够的库存，能够满足客户的需求。
◆ B2C Web Application调用Third-Party Logistics的Logistics Service要求其运送指定Warehouse的指定数量的某种商品到某处(客户所指定的地址)。
◆ Logistics Service调用Warehouse Service，从仓库出货，并运送。
◆ 运送完毕后，Logistics Service将向B2C Web Application响应一个送货到达的通知。
在这个流程中，我们需要在不同的服务之间保持会话状态。由于会话与具体的应用关系不大，其应当是平台的特性，因此我们需要使用SOAP Header(SOAP Extension)来实现之。
在基于会话的消息交换模式下（如图5），多个会话的参与者将进行一个长时间的会话进程，其中将包含多次消息交换。在多个参与者之间，可能会有同一个进程的多个实例存在。
在商业伙伴之间的交互经常是远远比一个简单的请求/响应消息交换要复杂得多。在我们这个供应链管理的商业交互中，从定购到送货整个过程可能要跨越数天。在这种情况下，将多个个体形式出现的消息组成一个长时间的消息交换集，可以带来很多实现上的好处。这样一种多次的消息交换的形式就是我们所熟知的会话。会话可以在一对交易伙伴之间长时间地继续。一个会话实例可能需要几天、几周，甚至几个月才能完成。
在两个交易伙伴之间的会话可以被类似ebXML交易伙伴协定(Trading Partner Agreement, TPA)这样的共享构造信息来定义。一个交易伙伴协定(TPA)所包含的信息有诸如期望的响应次数、每个交易方承诺完成的商务流程的动作、安全信息以及消息内容结构等。
图5所展示的这个应用模式可以按照如下的方式来实现。每个参与者的SOAP处理器都能够访问一个按照TPA协定而配置的数据库，TPC协定是在两个参与者之间达成的。SOAP发送者中的会话状态处理模块负责处理的SOAP Header条目中包含的信息，能够表示该条目所在的消息是会话实例的一部分。而对等的SOAP接收者的相应会话状态处理模块则使用发送者提供的信息，来测试收到的消息是否是遵照TPA的规则的。该测试过程具体是通过检查它自己的规则数据库来实现的。这个数据库里保存着每个当前活跃的会话实例的状态信息。如果当前消息违背了TPA的规则，那么应用程序可以产生一个错误。（图片） 需要注意的是，图5中并没有包含一些用于处理其它SOAP Header条目的处理模块，因此在TPA协约下所需要的可靠性或是安全性等特性并没有在该图中体现。
下面将给出的是一个请求和响应消息的例子，其中使用了一个名为ConversationState的SPAP Header条目来用于标识管理两个交易伙伴之间消息交换的协定，具体是使用AgreementId元素。为了支持在统一协定下的多个并发会话，在ConversationState SPAP Header条目下还包含了另一个用于标识会话的ConversationId元素。在一个特定的会话交换的整个生命周期中，AgreementId元素和ConversationId元素的值将保持不变，同时将即在请求消息中出现，也在响应消息中出现。
作为会话消息交换一部分的SOAP请求消息示例如下：
uuid:09233523-345b-4351-b623-5dsf35sgs5d6 uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j …………
作为会话消息交换一部分的SOAP响应消息示例如下：
uuid:09233523-345b-4351-b623-5dsf35sgs5d6 uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j …………
6/30/2004
|
