以文本方式查看主题 - 计算机科学论坛 (http://bbs.xml.org.cn/index.asp) -- 『 Web Services & Semantic Web Services 』 (http://bbs.xml.org.cn/list.asp?boardid=10) ---- SOAP 消息级别的互操作性 (http://bbs.xml.org.cn/dispbbs.asp?boardid=10&rootid=&id=40228) |
-- 作者:flyfoxs -- 发布时间:11/20/2006 11:39:00 AM -- SOAP 消息级别的互操作性 SOAP 消息级别的互操作性 http://www-128.ibm.com/developerworks/cn/webservices/ws-soa-intersoap/index.html?ca=drs-tp4406 级别: 中级
2006 年 11 月 15 日 使用 Web 服务时,达成一致的 XML 模式能否保证在系统间进行成功的数据交换? 您可以在本案例研究中找到答案。您将了解如何在涉及集成层时定义 WSDL 文档来在 SOAP 消息级别实现互操作性。文中对 Web 服务的远程过程调用(Remote Procedure Call,RPC)和 Document 样式进行了讨论。 在基于 Web 服务的 SOA 设计中,通常需要为提供者和使用者定义 XML 模式来进行数据交换。定义这种共同达成一致的模式是互操作性的第一个步骤,但并不一定保证进行成功的数据交换。为了通过使用 Web 服务确保数据事务总体可互操作,还必须考虑 SOAP 消息。 XML 有效负载通常包装在 SOAP 消息中,以便进行数据传输。如果没有正确的 SOAP 消息设计,则可能无法正确交换 XML 有效负载,即使有效负载遵循提供者和使用者的公共 XML 模式也是如此。SOAP 消息结构由 WSDL 文档中的 SOAP 绑定定义确定。本文中的案例研究说明了 WSDL 定义会如何影响 SOAP 消息和数据交换。 案例研究 以下序列图说明了一个案例,其中涉及到使用集成层来在基于 Web 服务的 SOA 中进行数据交换。System A 是使用 Web 服务将其数据发布到集成层的数据系统,而集成层使用 Web 服务将数据中继转发到下游系统,如 System B。集成层充当数据事务的中间层服务。它可提供服务聚合和协调等功能。在此案例中,集成层控制数据系统 A 和 B 之间的数据流。 从理论上讲,基于 SOA 的集成中并不一定需要集成层,但事实上,如果没有这个层,成功的可能性就很小。我们此处给出的案例的情况适用于使用集成层进行数据流控制和服务协调的 SOA,可提供要集成的系统的必要分离。本文重点讨论如何恰当设计 Web 服务,以在 SOAP 级别实现数据交换互操作性。 此数据交换案例中涉及到两个 Web 服务:publishSomeData 和 receiveSomeData 服务。publishSomeData Web 服务由集成层实现,用于发布来自 System A 的数据。System A 是 publishSomeData Web 服务的使用者。它将调用集成层的“publish”服务,以发送 publishSomeDataRequest 消息,将其数据以包装在 SOAP 信封中的 XML 格式进行广播。集成层接收到此消息后,会立即向 System A 发送一条响应消息 publishSomeDataResponse。 集成层接收到消息有效负载后,将与其协调服务进行联系,确定哪些系统订阅了此数据。它将随后通过调用 System B 提供的“receive”服务 receiveSomeData 把消息发送到接收方 System B。 为了简化案例研究,我们使用以下 XML 消息有效负载作为示例: SOAP 绑定,RPC 样式 在 RPC-literal 样式中,服务使用者会将 Web 服务作为远程过程调用进行调用。它将发送带有作为参数的输入的消息。在通过 HTTP 等传输协议进行调用前,Literal XML 有效负载被封装在 SOAP 消息中。 从服务使用者 System A 发出的典型 RPC SOAP 消息如下所示: 正如上面所提到的,SOAP 消息的构造方式主要在 WSDL 文档中确定。要构造此类 SOAP 消息,可以在 WSDL 文档中将 SOAP 绑定定义为: 数据流从 System A 调用集成层的 publishSomeData 服务开始。集成层接收到 SOAP 信封中的 XML 消息后,会使用确认信息响应 System A。集成层随后通过调用接收方端的 receiveSomeData 服务将 SOAP 消息传递给接收方。通常,集成层并不会打开 SOAP 信封来处理 XML 有效负载。同样,它仅充当控制数据流的中间层服务,并确保正确地接收数据。 在接收方端,System B 根据其自身的 WSDL 定义预期接收采用 RPC 样式的传入的 SOAP 消息。作为“receive”服务,其 WSDL 操作通常按照以下方式进行定义:
清单 4. WSDL 操作 根据 wsdl:operation 的定义,接收方 Web 服务接口将预期接收通过 receive 操作包装的 RPC 样式的 SOAP 消息,如下所示: 可以采取很多方法解决这个问题。其中一种方法是,让集成层处理 SOAP 消息,然后使用恰当的操作名称重新构造另一个 SOAP 消息。不过,这样会导致在集成层进行额外的处理工作。解决此问题的一个首选方法是,使用 Document-literal 样式的 SOAP 消息,并假定对于这个特殊集成,“rpc”和“Document”样式都是允许的。 SOAP 绑定,Document 样式 在 Document-literal 样式的 SOAP 消息中,SOAP 主体仅包含 XML 有效负载,而不会包装操作名称。典型的 Document 样式 SOAP 消息与以下所示内容类似: Document-wrapped 样式 对于 Document 消息,还有两种其他样式:Wrapped 和 Unwrapped。Wrapped Document-literal 样式用于模拟 RPC 样式。在 Document wrapped 样式中,wsdl:operation name 必须定义为与 XML 文档的根元素的名称相同。上面列出的 Document 消息是采用不同操作和模式元素名称的 Unwrapped Document 样式。在下面的 Document-wrapped SOAP 消息中,模式根元素被重命名为“publishSomeData”,以与在其 WSDL 文档中定义的操作名称匹配。 只要在接收方的 WSDL 中定义了相同的名称,接收方端就不应有与接受此类 Document 样式 SOAP 消息相关的问题。不过,这违背了应在接收方端定义“receive”操作而在发布端定义“publish”操作的 SOA 角色模式。在“receive”模式中使用“publish”元素完全违反了“receive”服务的语义。在这种情况下,可以将相应的语法更正为 Document-wrapped 样式的,但这样并不一定是 SOA 实现的好方法。 结束语 总之,必须在 SOAP 级别和 XML 有效负载级别实现互操作性。各种 SOAP 消息样式都可以通过在 WSDL 进行不同的组合来用于进行数据交换。某种样式并不一定要比其他样式好,但任何消息样式选择都应该满足业务和集成需求。在本文提供的案例中,Document-literal 和 Unwrapped 的样式组合比较合适。
学习 您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/library/ws-soa-intersoap/index.html?S_TACT=105AGX52&S_CMP=cn-a-ws]英文原文[/URL] 。 获得产品和技术 获得[URL=http://www.w3.org/TR/soap]最新的 SOAP 版本[/URL]。
讨论 参与 [URL=http://www.ibm.com/developerworks/blogs/?S_TACT=105AGX52&S_CMP=cn-a-ws]developerWorks 博客[/URL],从而参加到 developerWorks 社区中来。
关于作者
Shawn Hu 是 Xtensible Solutions 的一名解决方案架构师。他的专长包括 Web 服务设计 (WSDL)、数据分析和建模以及 XML/XSD 生成。他曾参与过各种系统集成项目,工作重点是接口设计和数据流。他获得了加拿大西安大略大学的博士学位。 |
W 3 C h i n a ( since 2003 ) 旗 下 站 点 苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》 |
42.969ms |