动态安置每个Web服务棋子
动态电子商务流程的Web服务实现
柴晓路
计算机世界报
动态电子商务是下一代电子商务，它来源于企业业务流程的过程重组。用Web服务实现动态电子商务是目前的主流，其中工作流是体现其动态特性的最好方式，它可以从整体规划的角度让我们体会流动的商务。同时它把开发人员从着眼于Web服务技术细节转向以全局的角度自如调用Web服务。在流模型中，Web服务成为一个个小小的、独立的棋子。
按照动态程度的递进，由Web服务提供技术保障的动态电子商务可以分为这样三个层次：一，电子商务应用能够在实时条件下被动态地集成，主要是通过UDDI的运行时态查询、WSDL的动态解析绑定等特性；二，在每个Web服务工作流的节点中，参与者（Web服务应用实例）可以被动态选择，即每次执行过程中参与角色的具体实例可以不同；三，Web服务工作流不但可以动态选择参与者，其子流程也可以被相应的其他流程片断所替代。其中第一个层次是Web服务的基本能力，第三个层次具有相对的前瞻性，所以本文的重点在第二个层次。
流模型着眼整体
工作流定义机制已经是一个比较成熟的机制，WfMC（国际工作流管理联盟）在工作流领域做了很多标准化工作。Web服务流语言（WebServicesFlowLanguage，简称WSFL）则是由IBM针对两个层面上的工作流提出的一项Web服务规范标准：
●它使用一个有向图模型来定义和执行商业流程；
●它定义了一个公共接口，该接口允许商业流程把自己发布为Web服务。
在Web服务的环境下，工作流定义机制必须能够对各种复杂情况控制自如，使基于XML规范的处理流程看起来更加有效。其中的难点就是创造一种能够迅速和精确定义工作流过程的方法，而且这种方法绝不能使控制逻辑变得过分复杂，以至于增加大量开销而无法实现。
为了从上述困境中走出来，WSFL不打算无所不能，它只把重点放在工作流核心模型的产生上。图1提供了一个简单的工作流示例。这是一个有向图，每个方框代表一个活动，每个活动表示必须由某人或某物完成的某个事务；每条带箭头的实线代表从一个活动到另一活动的控制流程，箭头指明流程进展的方向（因而被称做有向边），可能是有条件的，也可能是无条件的;连接各项活动的虚线表示两个活动之间的信息流程。各个控制点要判定是否继续进行处理、当前活动是否完成、边框图是否继续画下去以及是否发生了错误等。
可以看到，一个商业流程模型描述的是必须发生的事件链，而不是关于这些事件将如何发生的特定细节。
在大多数时候，开发人员习惯于根据他们要实现的技术或功能来看他们正在编写的应用程序，比如这儿是一个地址薄，那儿是一个购物车，或是即时消息、P2P架构等，经常容易忽视应用程序的整体规划和架构。但在许多情况下，整体规划和架构可以解决大多数类型的关键商业需求。商业流程建模通常从一个能表达整体流程的图开始，并按照以下因素分解开来：必须完成的特定活动、完成这些活动必需的顺序、这些活动间的依赖性以及确保完成这些活动的角色定义。
WSFL使Web服务在整个商业流程或“流模型”中扮演实现具体活动的角色。在整体规划中，这意味着个别类型的Web服务（地址薄、即时消息、信用卡验证服务等）都不如正在实现的整个工作流重要，至少从希望使用那些服务的公司来看是如此。换句话说，Web服务的真正价值在于它们能够使开发人员真正地引导商务或共享信息，而不在于个别Web服务自身的优点。
需要提醒大家的是:WSFL自身并不是一个关于如何创建商业流程模型的规范，而是一个关于如何应用新兴的Web服务架构实现商业流程模型的规范。也就是说不能实际使用WSFL来定义商业流程模型，具体的模型定义工作一般由UML来完成。因此，你需要理解的是如何将商业流程模型图转换为WSFL流模型。
tModel建立惟一标识
WSFL描述的是Web服务之间的流模型，而在这个流模型中，存在多个表示具体Web服务的结点。如何定位这些Web服务呢？在执行商业流程时，WSFL规范定义了四种不同的方法来定位参与的Web服务，即静态方法、本地方法、UDDI方法和动态方法。
使用静态定位只需向WSFL全局模型添加一个指向WSDL服务定义的直接URL；“本地”服务不必通过Web服务接口来提供，更多情况下，它们与处理请求的工作流引擎在同一台机器上，这与Web服务关系不大，只是作为一种兼容性而存在；通过对UDDI注册中心的查询本来会检索出符合条件的一系列候选Web服务，不过在WSFL全局模型的应用中可以使用选择策略，判定哪个Web服务将作为履行商业流程的角色；为WSFL提供更高灵活性的是动态定位机制，它允许WSFL工作流引擎完全根据调用流程时应用的一套规则来选择服务提供者，为处理Web上的商务添加了一种新的思维：动态联合并集成松散结合的应用程序组件。
然而，要使UDDI支持动态Web服务选择，UDDI必须提供某些手段，使得通过UDDI搜索到的结果集能满足动态选择的条件，例如返回结果集中的Web服务都要支持某种订单处理规范，那就需要在UDDI注册中心为每个这样的Web服务定义一个属性，表示它支持某种规范。在UDDI中通过tModel这个特别的数据结构来实现规范的定义和标注。
tModel作为描述一种技术规范的机制而存在。例如通过介质与其他软件通信的应用总是遵循某种预先议定的规范，这样规范的设计者就可以通过使用tModel注册规范的信息，以达到在一个UDDI注册中心建立惟一技术标识的目的。一旦通过这种方法注册，其他人就可以方便地在其Web服务描述数据中增加一个相应的tModel标识符（称为tModelKey）的引用来表示提供了符合某种规范的Web服务。
这种方法使得搜索符合特定规范的Web服务相当容易。一旦知道了正确的tModelKey值，就可以知道某个商业实体是否注册了一个引用那个tModelKey的Web服务。也就是说，tModelKey成为给定规范的惟一技术指纹。这种关于规范的信息，也就是传统的元数据结构。而在从前，为了实现一个具备兼容能力的软件，两个公司惟一可行的方式就是使用同样的规范达成协议，然后基于该协议架构软件并测试。
tModel概念在发现那些供广泛使用的服务信息的场合非常有用。假设企业购买了一个能通过其网站自动接受电子订单的软件包，就可以通过某个公共UDDI站点为这个商务功能发布服务。当完成了该软件的安装及配置后，它会自动查询公共UDDI站点来识别与该软件兼容的商业伙伴。
WSFL与其他
在商务流程定义方面，并非只有一个WSFL规范，WSFL是IBM的商务流程定义语言；Microsoft在推出其BizTalkServer时，就为BizTalk提供了定义商务流程的XLANG；而Sun，这个不甘寂寞和落后的技术提供商，同样与BEA、SAP和Intalio合作开发了Web服务工作流的规范，称为WSCI（WebServicesChoreographyInterface），WSCI来源于BPMI（BusinessProcessManagementInitiative，Intalio是其创始人），与Microsoft的XLANG以及IBM的WSFL非常类似。
无论是WSFL、XLANG还是WSCI都是来源于商务流程管理的技术框架和概念。在Web服务技术时代之前，OAGIS、RossetaNET、xCBL、UBL都是一些使用XML定义商务流程的早期尝试，其中最成功的应该是RossetaNET，当然RossetaNET不光是商务流程管理和定义，它还以此为基础延伸到了整个供应链管理的数据交换。ebXML则是一项新的国际标准，其核心的BPSS（BusinessProcessSpecificationSchema）也是一个重要的商务流程管理规范。
随着技术的发展，无论是WSFL、XLANG、WSCI糅合原有的技术在Web服务时代逐步取代旧有的规范；还是ebXML、RosettaNET进一步发展并融合越来越多的Web服务特性，令WSFL、WSCI等无疾而终；或是彼此达到一个相对的平衡，即WSFL、XLANG和WSCI在轻量级应用中得到使用，而ebXML、RosettaNET更注重于重量级企业应用。它们都会向同一个方向努力，那就是动态电子商务，这个真正充分利用Internet的电子商务模式。
