在该 Web service 方案中,代理为现有的非 Web service 应用程序提供 Web service 接口。
符号的关键字:
这有时称为 Web service 外观。Web service 接口的设计通常会涉及现有接口的某些重新分组、限制或增强,并且不受现有 WSDL 定义的约束。
代理为现有应用程序提供 Web service 接口,同时也可以提供其他混合功能,比如对发出的请求进行审计。
随着时间的推移,可以更改该实现,但不会影响提供给 Web Service 客户机的接口。
您的消息流接收 Web service 请求、将其转换为现有应用程序期望的格式,然后调用现有应用程序。来自现有应用程序的响应转换为有效的 Web service 响应。
现有的 CICS 应用程序具有 COBOL 副本接口。
目前使用 WebSphere MQ 进行输入或输出的大多数消息流都可以改编为使用 HTTP 作为替代或附加协议。
您可以在 MRM 域中为输入消息建模,并根据该模型生成 WSDL;或者您可以处理一般 XML 或 XMLNS 域消息。如果您已在 MRM 域中定义了该消息,则可以配置 HTTPInput 节点,以验证输入消息。如果消息不符合模型,则该节点生成异常。
您可以配置 HTTPReply 节点,为发送给客户机的应答消息生成一组缺省的 HTTP 头。这减少了将消息流从处理 WebSphere MQ 消息的消息流转换成处理 HTTP 消息的流时必须进行的修改。
第一个消息流在 HTTPInput 节点中从 Web Service 客户机接收入站请求。它包含以某个方式转换请求的 Compute 节点和将修改后的请求发送到 WebSphere MQ 应用程序的 MQOutput 节点。
第二个消息流在 MQInput 节点中从该应用程序接收响应。该消息传递到转换消息并将它传播到 HTTPReply 节点的 Compute 节点,HTTPReply 节点将它作为应答发送到发起 Web service 客户机。
尽管每个 Compute 节点完成的转换工作可能微不足道,但第一个节点中的 ESQL 代码必须保存 HTTP 状态信息,第二个节点将检索这些状态信息以确保来自 WebSphere MQ 应用程序的应答能够返回到发送原始请求的客户机。
第一个消息流接收消息,执行需要的转换,并将 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);