代理实现新的 Web service 接口

在该 Web service 方案中,代理为现有的非 Web service 应用程序提供 Web service 接口。

该图显示了定义文件导入到消息集中的现有应用程序。WSDL 文件是从消息集中生成的。该消息集将部署到代理的一个流中。该流在运行时与作为消息源的现有应用程序和 Web Service 客户机进行交互。

符号的关键字:

该图描述了在其他图中使用的符号,那些图在此处没有描述,因为它们都有自己的描述。

这有时称为 Web service 外观。Web service 接口的设计通常会涉及现有接口的某些重新分组、限制或增强,并且不受现有 WSDL 定义的约束。

可能的用户

代理为现有应用程序提供 Web service 接口,同时也可以提供其他混合功能,比如对发出的请求进行审计。

随着时间的推移,可以更改该实现,但不会影响提供给 Web Service 客户机的接口。

设计步骤

  1. 为业务消息创建消息集,可能通过导入现有接口定义(例如,C 头文件或 COBOL 副本)进行创建。
  2. 从消息集中生成 WSDL 定义。
  3. 使用 SOAP 工具箱(如 Rational Application Developer)根据 WSDL 创建合适的 Web Service 客户机。
  4. 部署消息流以实现 Web service。

运行时

您的消息流接收 Web service 请求、将其转换为现有应用程序期望的格式,然后调用现有应用程序。来自现有应用程序的响应转换为有效的 Web service 响应。

示例 1

现有的 CICS 应用程序具有 COBOL 副本接口。

  1. 导入 COBOL 副本以创建消息模型。
  2. 创建具有以下节点的消息流:HTTPInput、HTTPReply 和 CICS。
  3. 使用 HTTPInput 和 HTTPReply 节点提供 Web service 外观。
  4. 使用 CICS 节点调用原始 CICS 实现。

示例 2

消息流作为 Web service 进行调用
您修改现有消息流的设计,以通过 HTTP 与 Web Service 客户机交互。现有的消息流接受定义明确的输入消息,客户机可以使用从 WebSphere Message Broker 工具中导出的 WSDL 调用消息流。

目前使用 WebSphere MQ 进行输入或输出的大多数消息流都可以改编为使用 HTTP 作为替代或附加协议。


该图显示了具有节点 HTTPInput、Compute1、DataUpdate、Compute2 和 HTTPReply 的消息流。

您可以在 MRM 域中为输入消息建模,并根据该模型生成 WSDL;或者您可以处理一般 XML 或 XMLNS 域消息。如果您已在 MRM 域中定义了该消息,则可以配置 HTTPInput 节点,以验证输入消息。如果消息不符合模型,则该节点生成异常。

您可以配置 HTTPReply 节点,为发送给客户机的应答消息生成一组缺省的 HTTP 头。这减少了将消息流从处理 WebSphere MQ 消息的消息流转换成处理 HTTP 消息的流时必须进行的修改。

示例 3

该消息流提供对 WebSphere MQ 应用程序的访问。
您可以设计两个从 Web service 客户机接收请求并向其发送应答的消息流,让它们与尚未改编为通过 HTTP 进行通信的现有 WebSphere MQ 应用程序进行交互。

第一个消息流在 HTTPInput 节点中从 Web Service 客户机接收入站请求。它包含以某个方式转换请求的 Compute 节点和将修改后的请求发送到 WebSphere MQ 应用程序的 MQOutput 节点。

第二个消息流在 MQInput 节点中从该应用程序接收响应。该消息传递到转换消息并将它传播到 HTTPReply 节点的 Compute 节点,HTTPReply 节点将它作为应答发送到发起 Web service 客户机。

尽管每个 Compute 节点完成的转换工作可能微不足道,但第一个节点中的 ESQL 代码必须保存 HTTP 状态信息,第二个节点将检索这些状态信息以确保来自 WebSphere MQ 应用程序的应答能够返回到发送原始请求的客户机。


该图显示了两个消息流;第一个消息流具有节点 HTTPInput、Compute1 和 MQOutput。第二个消息流具有 MQInput、Compute2 和 HTTPReply。终止第一个消息流的 MQOutput 节点将消息放入现有应用程序维护的 WebSphere MQ 队列中,该应用程序将其响应放入由开始第二个流的 MQInput 节点维护的输入队列中

第一个消息流接收消息,执行需要的转换,并将 HTTP 请求标识编入外发消息中。(如果希望,也可以将请求标识存储在数据库中)。HTTPInput 节点将请求标识 Destination.HTTP.RequestIdentifier 作为 LocalEnvironment 树中的字段提供,Compute1 可以读取和存储该值。

第二个消息流接收应答消息,并将它转换回客户机消息格式。Compute2 从该消息中读取 HTTP 请求标识,并使用该值设置 LocalEnvironment.Destination.HTTP.RequestIdentifier。HTTPReply 节点使用请求标识来确保该消息到达正确的 HTTP 客户机。

该方案的实施需要对 MQMD 进行正确的处理。通过 HTTP 进入消息流的消息必须添加了 MQMD 后才能发送到 MQOutput 节点中。同样,通过 WebSphere MQ 进入的所有消息必须在除去 MQMD 后才能发送到 HTTPReply 或 HTTPRequest 节点上,除非希望在 HTTP 流中包含 MQMD。

在 Compute1 的 ESQL 模块中,包含类似以下内容的语句:

SET OutputRoot.XML.A.MessageID =
CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);

在 Compute2 的 ESQL 模块中,编码类似以下内容的语句:

SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier =
CAST(InputRoot.XML.A.MessageID AS BLOB);
相关概念
Web service、WSDL 和消息流
代理调用现有的 Web service
代理实现现有 Web service 接口
代理实现新 Web service 的非 Web service 接口
声明 | 商标 | 下载 | 书库 | 支持 | 反馈
Copyright IBM Corporation 1999, 2006 最后一次更新时间:2006/08/14
ac34540_