WS-CDL服务协作技术与海关业务流程整合
【内容提要】海关信息技术应用的进一步发展迫切需要解决业务流程的整合问题。对于部门内部的业务流程整合，我们可以利用工作流技术加以实现，然而，对于部门之间业务流程的衔接问题，传统的软件技术和工作流技术都不能很好解决。本文提出了一种基于WS-CDL服务协作技术的解决方案。该技术是由国际万维网组织提出的一种Web服务协作描述语言，能实现对部门之间Web服务协作的描述。通过对海关业务流程整合的技术和业务需求的分析，以及对WS-CDL技术的研究，提出了利用WS-CDL技术实现海关业务流程整合的理由和技术方案，构造了WS-CDL的执行引擎，还进一步讨论了WS-CDL规范的完善和扩展。
【关 键 词】业务流程整合 服务协作 WS-CDL
一、引言
近年来，随着H2000业务系统和HB2004办公自动化系统的推广和应用，计算机与信息技术在海关的应用水平得到了长足发展。一方面，信息技术已成为了海关业务工作和日常办公不可或缺的组成部分，在通关、监管及日常事务管理等方面对计算机技术的依赖性也迅速提高；另一方面，许多关处均根据其自身工作特点和业务需要建立了各自的应用系统，从而大大提高了海关监管的严密性，提高了工作效率，降低了行政成本，也促进了计算机技术的整体应用水平。然而，正如大家所知晓的，这种独立开发、各个为政的发展模式的一个突出问题就是：应用数量众多却相互独立，信息共享水平低，系统之间难以相互协作。海关业务流程整合的想法正是在这种的背景下提出的。
所谓业务流程整合，其基本想法就是，利用计算机和网络技术，将现有各自独立的业务流程组合起来，构建出一个统一、跨部门的“大流程”，从而实现业务流程在不同部门之间乃至不同海关之间的自动流转。就海关科技应用当前所处的阶段而言，确实已经到了实施业务流程整合的时候，这不仅是因为海关业务和科技应用的发展已经明确提出了业务流程整合的需求，而且还因为计算机技术本身的发展已经为这种整合提供了现实基础和实现手段。
在技术层面上，以Web服务为基础的工作流技术的广泛应用开辟了服务计算（SOC）技术的新纪元。工作流技术的中心思想就是将一项复杂的工作流程分解为一系列相互独立的计算单元，然后以配置文件的形式将这些计算单元组装成一个完整的业务流程。服务计算吸取了工作流技术的成功经验，能更加灵活、高效的实现部门内部和部门之间的业务流程的控制、整合与协作，而这正为海关的业务流程整合提供了实现的技术手段。
二、业务流程整合的两种实现模式与WS-CDL
（一）基于服务组合的业务流程整合模式及其存在的问题
服务计算中，主要有两种用于实现业务流程整合的模式：服务组合与服务协作。服务组合在很大程度上源自工作流技术，它通过将一项复杂的业务流程分解为一系列称之为“服务”（主要是Web服务）的相互独立的计算元，然后用流程描述文件将这些服务组合成一个完整的业务流程，并交由一个中心执行引擎统一控制业务流程的推进。
就技术本身而言，由于服务组合源自工作流，它自然就比较成熟，其中一种实现方式，BPEL4WS，不仅已经成为了工业标准，而且还有诸如WebSphere和Biztalk等大量支持该技术的应用服务器。为此，不少人提出可以利用工作流技术或服务组合技术还实现海关业务流程整合，但笔者认为，这种实施方案中存在着一系列的问题，主要包括：
首先，海关业务流程整合应该在保证各关区、各部门业务特色的情况下，实现业务流程的无缝对接，即属于一种“大框架、小自由”的模式。但由于服务组合需要一个流程的中心执行控制引擎，这必然要求进行全国性的统一实施，因而也不可避免的会忽略各个关区、各个部门之间的业务特色，结果反而会造成监管上的盲区。
其次，如果实施全国性的流程整合，那么中心执行控制引擎必须对全国的业务流程进行控制。随着业务流程复杂性的上升，中心服务器的系统负担也会直线上升，发现系统崩溃的可能性也随之上升，而中心服务器一旦崩溃，影响的将是全国海关的正常运作。
由工作流技术发展而来的服务组合技术，其本身目标只是为了实现一个部门内部的业务流程自动化。而对于实施海关业务流程整合这种跨关区、跨部门、全局性流程拼接，则应该采用更为先进的服务计算技术，即我们下一节讨论的基于服务协作的业务流程整合模式。
（二）基于服务协作的业务流程整合模式与WS-CDL
与服务组合不同的是，基于服务协作的业务流程整合模式不需要一个中央控制单元，而是由参与实体之间对等的（Peer-to-peer）进行信息交互，从而达到业务流程的对接。其中的参与实体可以是直属海关、隶属海关，也可以是海关内部的一个部门，实施起来相当灵活。它克服了基于服务组合模式中难以顾及各关区、各部门业务特点的诟病，能够在实现全局性流程整合的同时，又照顾到各参与实体本身的业务特点，很好兼容了“大框架、小自由”整合模式。而且，由于协作过程没有一个中央控制单元，任何一个局部系统的崩溃都不会影响到全局的运行。WS-CDL正是这样一种基于Web服务的协作技术。
WS-CDL是一种基于Pi-演算的Web服务协作描述语言，主要用于描述对等实体之间的协作关系，于2005年11月成为国际万维网组织（W3C）的候选标准（Candidate Recommendation）。WS-CDL规范的主要设计目标是定义出一套公认的描述语言，使之能在WS-CDL执行引擎的帮助下，自动实现任何类型参与者之间的业务流程的有效协作和整合。利用WS-CDL规范，我们就可以定义出一套全局性的消息交换次序和收发条件，即各个参加者之间的“可见行为”，从而使各个参与者都能根据这些全局定义去分别构造各自的本地系统，并在本地系统完成之后利用WS-CDL执行引擎和描述文档实现与其他参与者之间自动协作。
WS-CDL主要应用在涉及跨部门的业务流程协作中，就海关业务流程整合而言，它可以应用于：
□ 直属海关内部各个部门之间的业务流程整合
□ 直属海关与直属海关之间的业务流程协作
□ 直属海关与地方政府各部门之间的业务流程协作
值得注意的是，尽管WS-CDL至今尚未正式发布，但利用该技术实施海关业务流程整合将是一项及其有前途的工作，那是因为：
第一，WS-CDL是第一种，也至今为止唯一一种定位于各个组织之间业务流程协作的技术。随着计算机技术应用的进一步发展，各个组织的信息交互势必日益频繁，参与实体之间的业务流程协作也将变得不可缺少。
第二，由于WS-CDL有严格的理论基础——Pi-演算的支持，使得我们有办法利用Pi-演算的形式化工具对业务流程对接的结果进行前期验证，从而大大降低了将不正确的整合流程上线运行后引起的各种系统的和业务的故障。这种前期的验证机制也正是诸如BPEL4WS这种基于工作流的服务组合技术所难以提供的。
第三，业务流程整合是当前电子政务和电子商务的一个发展热点，但至今还鲜有完善的方案可供借鉴。WS-CDL提供了一个现实而可行的实现技术。如果海关能利用该技术完成对业务流程的整合，那对其他各部门业务流程整合的实施，都具有重大的借鉴意义。
三、WS-CDL在海关业务流程整合中的应用
（一）在海关业务流程整合中应用WS-CDL的现实可行性
纵观海关信息技术的发展过程和阶段，我们认为，应用WS-CDL技术的客观条件已经成熟，这表现在：
第一，在业务需求上，随着信息技术的应用和发展，大部分关处都已建立了自己独立的业务流程自动化系统，如何与其他关处进行业务流程的自动协作将成为下一步需求之一。
第二，在网络设施上，随着“三网分离”和网络扩容工程的完成，海关内部的网络带宽大大拓宽，安全性能也有了显著提高，完全可以承载WS-CDL应用所需要的信息交互的带宽。
第三，在技术基础上，许多关处都已经开始在其电子政务系统中部署工作流及Web服务，这就为WS-CDL的引入奠定了技术基础。
（二）WS-CDL的应用模型
WS-CDL主要面向的是部门之间（或组织之间）基于Web服务的对等协作应用，其应用模型如（图1）所示。从上图中我们可以发现，参与WS-CDL协作的实体之间通过海关内网相互连接，在地位上是完全对等的，且没有一个中心控制器。任何一个参与实体都无法直接调用另一个参与实体所控制的Web服务，而必须通过向其所属的参与实体发送消息的方法，这样就降低了软件模块之间的耦合性，有利于日后的流程更改及重组。如图1：
（三）WS-CDL执行引擎的设计与实现
笔者已经实现一个WS-CDL执行引擎的原型系统，该系统能根据WS-CDL文档的描述实现WS-CDL参与实体之间的信息交互和有效协作，现介绍如下 如图2：
1．整体架构与主要功能
其中各个模块的主要功能如下：
CDL解析器：负责将WS-CDL的描述解析成一组CDL实体，供编排执行引擎使用。
CDL实体仓库：用于保存roleType、channelType、choreography、activities等CDL实体。它由CDL解析器在系统初始化时负责构造，在执行过程中供编排执行引擎检索需要的信息。
编排执行引擎：是系统的核心组件。它根据用户要求或在接收到某个特定消息时初始化一个编排实例，该编排实例随后从CDL实体仓库中读取相应的choreography实体，根据其变量定义的内容建立并初始化相应的变量，最后该实例启动一个新的线程并以递归的方式在新启动的线程中执行该choreography中的activity。
2．消息通道的实现
WS-CDL是基于Pi-演算的Web Service组合技术，它引入了channelType机制来实现对动态变化的服务进行建模，从而能更好的适应各种复杂应用系统的开发，是WS-CDL技术的一大亮点。在WS-CDL执行引擎中，channelType的实例称为消息通道。一个消息通道由一个位于发送方的channel和一个位于接收方的endpoint组成。位于发送方的channel既是一个变量又是一个消息传递的通道，作为变量，它保存了接收方endpoint的地址，而作为消息传递的通道，它可以用于消息的发送或者接收。而位于接收方的endpoint则对应了channelType中指定roleType的一组role，它在收到一个消息包后根据相应channelType中的identity定义选取一个相应的role，然后将该消息包发送给该role。
利用消息通道机制，我们就可以很容易的通过传递channel变量的方式来实现对拓扑结构动态变化的服务进行建模。由于channel变量实际保存了接收方endpoint的地址，如果服务器A将通往服务器P的一个消息通道发送给了服务器B，那么B实际上就拥有了一个通往P的消息通道，服务器A、B、P之间的拓扑结构也就发生了相应的变化，这一过程。如图3：
3．编排实例的创建和调度
假设有A、B台运行WS-CDL执行引擎的服务器分别属于两名参与者，服务器A根据用户需要向服务器B发送订票请求信息，服务器B在收到订票消息后调用相应Web Service并将结果送回服务器A。该编排的执行过程如下：
（1）A根据用户要求创建相应的编排实例，并通过某种方式取得B的endpoint地址，从建立通往B的消息通道；
（2）A向B发送订票请求消息包；
（3）B收到来自A的请求包后根据通道中的identity定义初始化一编排实例，并执行之；
（4）B根据CDL描述调用相应的Web服务，并将返回的结果保存到特定的变量中；
（5）B利用A已经建立的消息通道将结果消息包送回给A；
（6）A收到来自B的结果消息包并将其保存至相应的变量中，编排任务完成，服务器A、B同时撤销该编排实例。
4．异常的传播与Coordination机制
在WS-CDL编排的执行过程中，如果任意一个参与实体发生，该异常必须被传播到其他参与实体中，从而使所有的参与实体都能够以相同的方式终结编排。这就是所谓的coordination机制，而执行引擎中专门用于提供coordination机制的软件实体则称为coordinator。每个参与编排的role都对应了一个特定的coordinator。
为了向其他参与实体发送coordination消息包，coordinator必须拥有相应的endpoint地址。在编排实例初始化时，每个coordinator只拥有自己对应role的endpoint地址。随后，当两个role之间进行消息交互时，其coordinator之间也有交换endpoint地址。这样，coordinator中实际保存了所有已经参与编排的role地址。当异常发生的时候，coordinator利用该地址列表将异常内容传播给所有已经参与编排的实体。
（四）WS-CDL的完善与扩展
WS-CDL规范目前尚未正式发布，还没有完全成熟，其中有许多地方，如安全性及定时操作等方面，还值得我们去完善和扩展：
首先，WS-CDL中没有提供一个专门的变量初始化机制，这样一来，用户就只能以<assign>方式将变量的初始化代码嵌在编排代码中，这个做法在很大程度上降低了代码的可读性，不符合软件工程的要求。为此，可以考虑在变量定义中增加一项专门用于指明变量初始值的cdl:initValue属性。
其次，由于WS-CDL是一种编排描述语言，其中并不涉及对消息包传输格式的描述。但对于执行引擎来说，这却是必不可少。本文的WS-CDL执行引擎实现了一种消息包的传输格式，但由于不同开发者实现的消息包可能不一样，使得它无法很好的与其他开发者提供的执行引擎进行协作。因此，建立一种统一的CDL消息包传输对WS-CDL技术的应用是有必要的。
再次，基于时间的自动执行机制是现代软件开发技术中是不可缺少的，事实上，在EJB和BPEL4WS中都提供了这类机制，然而，现行的WS-CDL规范却没有直接提供这个机制。为此，我们可以考虑在WS-CDL中增加定时操作机制。该机制可通过在顶层choreography定义中增加cdl:timer和cdl:timerLoop属性来实现，其中cdl:timer属性用于指定该choreography自动执行的时间，而当cdl:timerLoop的值为true时，表示当到达特定时间该choreography会重复执行，否则，该choreography一次执行完毕后就不再被执行。
另外，尽管在W3C提供的WS-CDL规范中也提到利用WS-Security规范来实现WS-CDL的安全性，但这种安全机制显然不能很好的满足各种复杂的较大规模的应用开发的需要。对此，我们可以考虑在choreography定义中增加cdl:needSignature属性，当该属性的值为true时，执行引擎将检查每个收到消息包中的数字签名，以确保发送方的合法性和消息包的完整性。
结束语
随着以计算机和网络为基础的信息技术的应用在海关内部的不断发展，科技、业务一体化的趋势日益明显，信息技术应用的层次不断提高，部门之间业务流程协作问题的解决也显得日益迫切。WS-CDL为海关业务流程整合提供了一种基于对等计算模式的现实方案，能很好的解决海关之间或海关各部门之间的工作流协作问题。虽然该技术才出现不久，现在仍处在不断的发展和完善之中，但可以预见，随着其自身的不断成熟及其应用领域的不断拓宽，它必将成为一种实现海关业务流程整合的有效途径之一。
【参考文献】
［1］NICKOLAS K, DAVID B, GREGORY R, TONY F, YVES L, CHARLTON B. Web services choreography description language version 1.0.
http://www.w3.org/TR/2005/CR-ws-cdl-10-20051109/, 2005-11.
［2］DAVID B, NICKOLAS K. WS choreography model overview.
http://www.w3.org/TR/2004/WD-ws-chor-model-20040324/, 2004-03.
［3］STEVE R, TONY F. Web services choreography description language: primer.
http://www.w3.org/TR/2006/WD-ws-cdl-10-primer-20060619/, 2006-06.
［4］廖军，谭浩，刘锦德：基于Pi-演算的Web服务组合的描述和验证．计算机学报，2005，28（4）：635-643．
［5］ALISTAIR B, MARLON D, PhHILLIPA O. A Critical Overview of the Web Services
Choreography Description Language (WS-CDL). BPTrends Newsletter, 2005(3):3.
［6］CHENG Y, LEE E, DILIP K L. Web services composition – an overview of standards.
Synthesis Journal, 2005:137-150.
Related posts: