内容


规划一个 Web 服务业务集成实践

增加 Web 服务 B2Bi 实践成功可能性的一套方法

Comments

Web 服务和 Service-Oriented Architectures (SOAs) 在中间件集成领域影响着主要变化。虽然一个基于 SOA 的开放式标准实现提供了很多的优势,但是当集成两个公司的 IT 系统(也可能是两个业务流程)的时候,利用 Web 服务规范来提供一个正面的经验还需要很多要注意的地方。在 Web 服务集成的技术方面开发者可以访问大量的各种各样的资料,本文寻求提供规划过程的一个比较大的、整体的见解。

在过去的这些年中,我已经把 IBM® 和他们主要的网络服务提供者的集成解决方案作了整理。该项目组设法归结一个集成的方法和过程到可以极大地降低失败风险的程度。我认为 Plato 能充分的体会到走上这条道路的团队的最大挑战。换句话说,“你并不知道什么是你不知道的”。

项目的关键阶段,如果你在正确的构件上问一些关键问题并且收集、签收,这时这个方法(如同任何恰当的方法)将对预防由疏漏引起的错误以及由收集、签收正确的构件引起的未知数将大有帮助。 图 1 说明了该套方法的细节。这篇文章集中讨论了第一个阶段,包括:

  • 规划
  • 架构
  • 设计

图 1. 一个高级 Web 服务集成项目规划
一个高级 Web 服务集成项目规划
一个高级 Web 服务集成项目规划

规划实践

一旦你建立需求来提供 B2Bi Web 解决方案,就应该集合项目组,并按照解决方案的交付来分配任务。这里要注意的一点是来自两个公司资产的集成提供了一个起作用的的解决方案。为了成功的实现这一点,你必须为两个公司都成立一个联合规划团队。我已经注意到使这个团队工作起来像某一个在初始阶段那样是非常重要的,但是实现起来却是非常困难。不同的公司和团队有不同的文化以及工作方式。这一点是非常重要的,因为如果你能成功地创建了一个统一的、具备凝聚力的项目团队,当问题不可避免的发生的时候,你将避免许多后来在测试阶段的无益工作。同样,必须确信联合团队清楚什么是合适的扩大途径以及决策制定过程是如何构成的,这也是十分重要的。如果你想要了解关于一个成功的项目团队需要什么样的成员的更多信息,你可以关注一下 Olaf Zimmermann 撰写的“Web 服务项目角色”这篇文章,在该篇文章的 参考资料部分突出显示了出来。

下一步是定义所有的需求,并确定其基线。如果两个公司的团队不在同一个城市,你有如下的两个选择:

  • 经历 4-6 个星期,每个星期要有几次两小时成的电话会议
  • 建立一系列良好规划的、面对面的会议以及所有团队都会出席的办公室

我本人非常喜欢后者。如果你做了合适的规划,在你的项目上你可以真实的取得许多成就并且会有一个实质性的开始。在你结束了会议周以后,你需要完成并且签发四个项目构件(对于测试阶段不可避免的问题以及职责的分配是非常重要的)。它们是:

  • 需求文档
  • 业务过程集成文档
  • 接口的技术规范
  • 数据映射规范

这些构件应该能够担保在在正确的时候问了正确的问题。在双方可以在他们的集成中间件或者是系统接口上进行任何所需的改变之前,他们也应首选涵盖来自双方的需求协议。当你在构建的列表上向下移时,你将看到每篇文档都是洋葱的下一层。

需求文档

需求文档很像是所有其它内容的开始点。因为核心需求经常随着工作的要求被一步步传递下来,这个文档很可能在会议开始的时候才接近完成。在这些需求中,确定诸如用例以及业务规则等条目是非常重要的。

业务流程集成文档

我已经发现业务流程集成是经常被忽视的一步。我的意思是,其中一个公司可能对另一个公司说,“让我们在这个合同上合作吧。我将处理所有服务的请求,到时我会将需要你来服务的请求发送给你。为了做到这一点,我们需要把我们的 Remedy Server 同你们的 e-ESM Server 集成起来来实现自动发送。”接下来发生的是,集成的请求传递到联合团队,人们立刻开始考虑获取他们各自的 Web Services Description Language(WSDL)文件,以及怎么调用彼此的 Web 服务,并且计算出消息语义。他们忽略了一个操作层面,两个系统的设计过程和提供的信息可能完全不同。

这样的一个例子是一个 helpdesk 管理场景。你可能用一个拥有固定选项集的下拉式列表框来设计 Remedy。比如,一个进入该系统的 helpdesk 代理更新许可仅仅能访问固定的选项集。e-ESM 的设计逻辑是不同的。这个设计提供了一个自由的文本框。为了解决一个问题,helpdesk 代理更新许可必须人工输入他们的行为。你怎么能将 Remedy 的固定列表映射到 e-ESM 中的自由概念呢?

图 2. 业务流程集成的问题
业务流程集成的问题
业务流程集成的问题

上面的 图 2 中图示了一个业务流程集成问题的例子。来自这两个公司的业务流程内容专家可以通过如下手段解决这些问题:仔细检查要交换的数据以及穿插在应用中的高级业务过程流。你可以使用 WebSphere® Business Integration (WBI) Modeler(请参阅 参考资料)工具来创建这些高级流,并传递给在系统集成方面工作的架构师。这个工具是 WebSphere Business Integration Suite 的一部分,并且包含了一些工具,可以帮助你在实现以前迅速有效的建模、模拟、分析复杂的业务场景。

这个文档也应该详细讨论两个系统在业务流程级别上如何互操作。例如,它应该为每一个高级业务流程描述所有场景应该发生的情况。这对于接口技术规范和数据映射规范来讲是非常有用的信息。因为这个文档很可能被那些想要知道系统怎么工作的非技术以及行政员工参考,它应该详细描述在团队之间实用的操作过程,比如意外的流程(谁在什么时候因为什么被调用了)、变更控制以及增加过程。

接口技术规范

目前,WSDL 没有提供足够的信息作为系统接口规范的确凿来源。这篇文档补充了 WSDL 的规定并且实际上有很高的技术含量。它也被考虑作为双方之间系统级别的接口契约。更合适的是,这篇文档应该提供相关外部架构文档的引用,比如网络架构文档,其详述了在两个接口之间的网络传输过程以及其它相关信息(比如为最新的表安排行程的路由、连接的种类以及什么防火墙需要打开什么端口)。该文档也应该提供每个公司系统接口的 WSDL 文件。这是他应该列举 WSDL 没有涵盖的系统以及集成属性。这些的例子可能是:

  • 是否操作调用应该是 Document/Literal 或者 Remote Procedure Call(RPC)。
  • 你正在用什么协议(Java™ Message Service(JMS)、HTTP以及其它的)?
  • 是否存在合作伙伴已经实现了的私有配置(比如需要在 Simple Object Access Protocol(SOAP)或者 HTTP 头中提供特定的安全信息)?
  • 怎么处理 SOAP 错误(客户端或者服务器),以及他们将发生在什么场景下?
  • 失败的事务是否被队列化,或者是否有监控代理提供通知功能(为哪一方)?

有个人这时应尝试记录消息协议流。这是非常重要的,因为 B2Bi 系统在 Web 服务的使用上面与那些调用 Web 服务来得到同步请求及时响应的标准客户代理有些细微的不同。一个 B2Bi 系统通常发送一个庞大而且复杂的载荷给它的服务提供者。该服务提供者在气可以提供相应以前,经常不得不分解载荷,并且把它发送到多个系统来处理。因为性能的原因,这些交易在其完成以前通常是异步的,并且实际的业务服务请求可以包含许多异步的 Web 服务操作。尽可能清晰的安排它以避免在团队之间产生混淆是非常重要的。我已经发现创建整个流程以及包含所有操作的图表是一个避免混淆的好方法。

一旦联合团队理解了流程,为了完成给定服务请求的完整生命周期,你需要在文档中记录一个公司哪个 Web 服务操作映射到另一个公司的哪个操作。这需要仔细的讨论、案例流的引用、需求讨论中生成的业务规则来确信两个系统都有了它们需要集成的东西。因此,这是为操作以及他们各自为不同种类事务的消息模式(并且提供样例消息)建立基线的好地方,这样开发团队就可以获取一个清晰的概念,下面到底会是什么。

用文档记录你使用的消息安全框架。例如,如果你使用安全套接层(比如,HTTPS 上的 SOAP),它是服务器认证的还是客户端服务器都要认证的?你计划使用什么样的数字证书格式?你是要使用自签署的证书还是真实的证书来测试?最后,你的系统可以处理什么样的事务限制?把这些记录下来是非常有意义的,因为一旦系统被建立起来并且运转良好,项目主办人的倾向就是指导更多的用户来使用它。关于该系统到底能做什么,主办人以及该团队建立一个公平的期望是很重要的。

数据映射规范

在描述接口技术规范的那部分中,我阐述了为了履行一个给定的请求或者响应,记录哪个 Web 服务操作需要调用哪个合作伙伴的 Web 服务操作是十分必要的。在这些操作里面,一个 XML 文档的文本载荷是在 SOAP 主体里面被交换的。为了合作伙伴的后端能处理你的请求,这个载荷需要用指定数据的指定格式。当你的系统初始化一个指向你的合作伙伴的事务,你需要转化你的文本 XML 请求到你合作伙伴系统的载荷中去。为了做到这一点,你需要一个映射规范文档来详述在你映射的两方之间每个 Web 服务操作的每个消息模式。这时各个方面的开发团队都能在稍后使用它,把它任何 XSLT 映射的需求,这些映射在合作伙伴的 Web 服务被调用以前应该被完成。

正如你在下面的 图 3 所看到的那样,IBM 用它期望的格式发送数据到合作伙伴,并且该合作伙伴用 IBM 所期望的格式作了响应。你可以通过数据映射来实现这个功能。

图 3. 一个数据转化的例子
一个数据转化的例子
一个数据转化的例子

结束语

这篇文章讨论了你怎么规划一个 B2Bi Web 服务实践。我对规划过程作了一个全面的阐述,规划过程是通过检查哪个活动是通向成功的本质因素来实现的。同时也提供了一些可以避免一些疏漏的指定基线构件,并且在其方法方面,我也作了详细的论证。最后,我关注了一下你需要什么构件,它们的内容以及它们在解决方案中的使用。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=49054
ArticleTitle=规划一个 Web 服务业务集成实践
publish-date=10012004