Web服务网络：简化企业间工程的中介
Kelly Truelove（kelly_truelove@hotmail.com）
独立顾问
2001 年 10 月
与通宵的递送服务所做的大致一样，Web 服务可以作为一起工作的不同公司的中介，从而帮助他们更有效地做生意。然而，Web
服务的这种环境并不失其复杂性，它仅仅超出使多组织一起工作的商业问题。Kelly Truelove 研究了潜在的 — 使用 Web
服务作为中介的潜在问题。
在物质世界中，企业在彼此进行商务的过程中使用很多中介。例如，“联邦快递公司”（Federal
Express）包裹递送网络大大简化了组织间的货物运输和通信，代替了那些必须建立定制的点对点的递送系统。Web 服务网络通过使 Web 服务（Web
服务是由不同企业操作的）间通信更便利来执行类似的中介职能。和现实情况一样，中介通过解决许多疑难问题来增加巨大的价值，否则这些问题将留给企业自己解决。一个起步者，Grand
Central，已经在 Web 服务网络的概念上处于领先，并已经实施了这种服务。（请参阅参考资料。）
用于自动的后端企业对企业集成的 Web 服务
在深入之前，一些关于 Web
服务和企业间工程的词汇要确定。由术语“Web 服务”想象到的一般印象是一个企业门户网站，它把来自多个资源的数据和功能性集成到单一的最终用户视图。Web
服务标准确实支持这种前台集成，它使从分布式元素创建最终用户应用程序轻松一些。
然而，重要的是 Web 服务也适合于应用程序间的后台集成。这里，我将重点放在后台方案，方案里为了业务过程的自动执行，应用程序使用
Web 服务接口相互链接（服务器到服务器）。
当有关的 Web 服务是由不同组织操作时，该方案提出了特殊的要求，这正是本文所涉及到的情形。
中介提供缺少标准的环境支持
集成工程自然趋向于集中在数据格式和过程调用明确的问题，但是组件集成中有关的环境同等重要。
Web
服务标准在简单性和开放性方面是强大的。然而，目前它们的范围还没扩展到超出数据格式和服务描述的面向内容的问题，达到服务间交互操作的面向环境的问题的程度。与物质类比，地址格式标准、包装样式以及“装运”和“接收”方法存在的描述并没有解决当包裹递送了，可办公室却锁着这种与环境相关的问题时该做什么。返回给发送方？尝试明天再递送？还是放在门口？
“联邦快递公司”作为中介增加价值的一种方法是通过为包裹递送定义一个通用接口。每一个组织以其自己的特点（关于工作时间、位置以及装运和接收部门的策略）与“联邦快递公司”建立一个连接。这种方法，N
个公司定义 N 个关系，而不是组合 N2 个在其它情况下必需的链接。巨大的效率产生了。Web 服务网络给企业间 Web
服务工程带来同样数量级的成本缩减。在这两种情况下，中介解决面向环境的要求来增加价值。回到类比，“联邦快递公司”能允许发送方或者接收方就如果包裹没有签收时是否可以留下，作一个独立的面向环境的选择，使收发方免于担心在这一点上的协调。
企业间工程面向环境的要求
很多 Web
服务工程迄今都是在企业内的，在防火墙后（环境经常在这里被隐式地理解）执行。然而，正如使用其它技术的企业间工作的老手们清楚地意识到，这种情形在防火墙外更具有挑战性，那里不同组件的运营者不能控制（或者看到）彼此的系统。在此种情形下，不能对通常的环境的理解想当然。
企业间 Web 服务工程提出了两大类具有挑战性面向环境的要求：
I. 通信要求：
在因特网跨越防火墙集成所需的元素：异步、加密、可靠性和不可抵赖性以及轮询。
II. 协作要求：
安全地发布 Web 服务或者使用和集成 Web
服务来形成企业间业务过程所需的元素：访问控制、实现抽象、路由以及注册中心和发现。
通过更深入地研究其中的每一点，我们发现在直接的企业对企业基础上处理这些要求具是有挑战性的。
I.
通信要求
异步
企业间后台集成工程通常最好是使用异步消息传递，因为它允许参与者以最小的互依赖性操作。这通常是穿越防火墙（这里被连接的系统可能有关于响应和自主性的不同策略）的集成要求。异步方法在执行公司间复杂的业务过程是尤其有价值，它们可能要花数分钟、数小时甚至数天来完成，在那里等待或者阻塞于一个响应将是不切实际的和不可伸缩的。然而，当考虑到多公司交互操作时，异步协调的逻辑是很吓人的。谁拥有不能被传递的消息？
加密
经过加密的安全性是因特网上企业通信的标准要求。虽然使用现有标准提供这个功能相对容易，但是使用不同标准或者强加不同策略使多公司的业务过程复杂化。在多公司集成中，哪一个组织拥有能被别的组织采纳的标准或者策略？
可靠性和不可抵赖性
与加密相似，可靠性和不可抵赖性是企业对企业通信的标准要求
—
但是在直接企业对企业方案中它们处理起来特别困难。如果没有接收到消息，谁判定谁应该负责任？什么权威机构规定不可抵赖性？
轮询
在指定的
Web 服务通信中，一方自然是发送方，而另一方就是接收方。然而，接收方可能不希望不断侦听到来的消息所导致的花费，而是周期地轮询发送方。一般来说，Web
服务模型吸引人之处是在能满足不改变组织防火墙的要求方面。然而，如果收发方不得不作调整以不断地侦听消息的话就会失去这个优势。当其它方不得不侦听消息的时候谁开始享受轮询的乐趣？
II.
协作要求
访问控制
敏感数据交换或者专有服务公开使参与组织间的谨慎的信任管理成为必要。难题是业务过程经常扩展超出了端对端关系中的两方。相反，该体系结构必须满足管理动态的多对多关系的要求。结果，企业间工程要求一个构建在由像证书认证那样的标准提供的访问控制上的信任管理模型。在多公司集成中谁维护该模型？
实现抽象
把一个抽象层添加到系统接口非常有助于满足把服务管理成本减到最小的要求。创建独立的公共接口（从后端实现分离）允许改变或升级
Web
服务而不破坏可能依赖于它们的系统。企业对企业集成中抽象层被定位在防护墙的哪一边？
路由
在不同企业中，特定业务过程的实现可能要求多个不同企业间
Web
服务的串连或编排。企业间业务过程管理在一种情况下是独一无二的，这种情况就是被编排的特定过程典型地比那些在防火墙后找到的过程简单，然而由于不同公司和系统在执行它们，所以它们可能更难实现和管理。同样，Web
服务的业务处理管理组件必须在其执行时向过程提供可见性，并且在它将不同的企业系统投入运行时管理过程的状态。在自动的多企业业务过程中哪一方管理这种编排所涉及的路由？
注册中心和发现
包括众所周知的
UDDI 规范，注册中心和发现涉及与发布和查找位置、绑定以及访问控制信息相关的 Web
服务要求。它在区分一批有限的合伙人（典型为企业）间的私人协作和服务（典型为服务提供者）的公开宣传方面是有用的。这两方面的差异，尤其是企业要求产生了专用 UDDI
目录（在此根据一批有限的参与者的策略可以控制注册中心和发现）的概念。哪一方维护这样一个注册中心？
使用中介处理面向环境的要求
上面讨论的面向环境的要求呼吁企业间工程中需要中介。取代中介，组织必须参与决策，谁担任什么角色，结果都是技术和商务两方面令人头疼的事。当集成涉及到的各方数量增加时，困难成指数放大。此外，这些中介功能没有一个必须是寻求集成的企业的特征。正如包裹递送网络类似，很需要专门的中介，其核心能力专门满足这些面向环境的要求。
Web 服务网络：强大的中介
Web
服务网络作为一个无所不在可访问的服务工作，该服务满足本文讨论的通信和协作要求。
作为运行在因特网上端的服务，Web 服务网络的功能性可以容易地并入到现有的应用程序。
在通信前端，Web 服务网络可以为异步传递排列消息并提供通过轮询的队列访问。与包裹递送网络相似，Web
服务网络能够对可靠性和安全性负责，并提供象“联邦快递公司”一样的消息跟踪作为不可抵赖性机制。根据协作，中介可以充当服务间信任管理点。此外，它被独特地定位于在支持多企业业务过程的服务间路由消息。最后，通过
Web 服务网络公开它们的接口，系统得到引入实现抽象的层。
简而言之，正如企业通过把装运和接收部门并入包裹递送网络而不是直接将它们系在一起来享有很高的效率一样，企业通过利用 Web
服务网络的功能性，可以大大简化企业间 Web
服务工程。在这两种情况下，中介通过解决与面向环境有关要求的疑难问题增加巨大的价值，使企业得到解放从而将精力放在它们的业务上。Grand Central
已经在该领域确立了地位并得到了从事企业间 Web 服务工程开发者的关注（请参阅参考资料）。
参考资料
IBM
参考资料
2002-08-26 14:08