在开发从MQ消息请求制造厂的订单请求Web服务时，需要注意的几个问题是

　　1) MQ的消息头

　　为了能将Web服务的返回的SOAP消息重新构造成MQ的消息，我们需要在MQ的消息转换成SOAP消息保留MQ的头消息。在ESQL中通过将MQ的头消息保存到环境中可以达到这个目的。

　　SET Environment.MySavedMQMD = InputRoot.MQMD;

　　2) Message Broker中如何集成Web服务的调用

　　在Message Broker中提供了一组内嵌的节点可以集成Web服务的调用，HttpRequest节点就是一个用来配置集成Web服务请求的节点。在HttpRequest节点的属性中可以设置甲或乙制造厂的订单请求的Web服务的URL，如下图所示:

　　图9:设置HttpRequest节点的Web服务地址

　　3) 在ESQL中使用XMLNS域处理消息格式的转换

　　在我们的场景中为了实现自解析而不需要定义消息集的目的，我们设定了HttpRequest和消息流中的MQ的域是XMLNS。XMLNS域对带命名空间的XML格式消息可以实现自解析。这里的转换工作我们使用ESQL语言完成，构建消息的过程必须参照特定的Web服务的SOAP的请求的描述。使用ESQL语言处理XMLNS域的消息与普通的XML域的不同，主要在命名空间的处理上。自解析的XML消息在Message Broker中会解析成一颗消息树，但是在SOAP的请求消息中会有很多的命名空间，这是我们需要处理的额外内容。这些命名空间通常包括 "http://schemas.xmlsoap.org/soap/envelope/"等,以及我们的场景中的Web服务定义的命名空间"http://csdl.ibm.com"。请参阅在Message Broker Toolkit 的帮助文档中ESQL中关于XMLNS的部分。我们场景中的MQ和SOAP消息之间的转换的ESQL的代码在附带的样例下载中。

　　小结

　　到这里，SIBus与WBI Message Broker的集成工作已经完成。在我们的场景中，不同策略实现的ESB的互联发生在当用户查询自己生产的零件的价格并且发现零件库存为零。这时会往SIBus上的外部目标写入订单请求消息。通过互联配置，订单请求消息会到达MQ的队列中。

　　Message Broker的消息流根据消息的内容路由到甲或乙两个不同的制造厂。Message Broker的消息流会将MQ的消息转换成SOAP的请求消息后，请求甲或乙两个不同制造厂的提供的订单请求接口。而订单请求的状态返回也是SOAP的返回消息，再转换成MQ的消息后，将会放到MQ的出队列中。而MQ出队列的消息通过互联的配置又路由回了SIBus中。

　　回顾一下我们所做的主要工作在于如何在SIBus和MQ中配置与对方的通信，因为是相互独立的软件，所以经常遇到必须将某些名称设置为一致的情况，这是读者在实际配置时必须要注意的一点。由于篇幅的关系，随文可以下载的样例中包含了更加详细的配置说明过程。