使消息的传输更加可靠

    对于使用消息总线之类的产品，如MQ，以实现诸如与大机之类的系统进行交互的过程。

    另一个要点是，异步服务需要一个关联ID(correlation  ID)来提供应答，关联ID格式通常是一个内部格式，可以兼容如MQ或者是目标服务所使用MQ 本地接口。

    异步请求/应答模式是被输出传输通道所控制，消息流程（除了$outbound 变量中transport所指定的数据）是并不了解JMS请求/应答和HTTP请求/应答这两种服务之间的区别。

    使用JMS  Correlation ID关联请求和响应的消息
   
    对于一个使用JMS方式在Service Bus上交互的请求和应答消息，必须通过JMS Correlation ID属性相互关联。换句话说，所实现的业务服务中，在接收消息时必须需要使用getJMSCorrelationID获取JMS Correlation ID， 而在消息发送到queue或topic之前，需要通过setJMSCorrelationID  来设定JMS Correlation ID。

    消息接口(javax.jms.Message) 是所有JMS消息的根本接口，JMS消息头包括了JMSCorrelationID 属性字段来关联不同的消息，JMSCorrelationID 可以保存一个提供者专用的消息ID，或应用专用的string对象或者byte[]值。

    在接收消息前，可以获取 JMSCorrelationID，发送消息前进行设定：

    String getJMSCorrelationID()：该方法返回JMS correlation ID 的值，可能是提供者专用的消息ID或是应用指定的String.

    void setJMSCorrelationID(String correlationID)：该方法用于设定JMS CorrelationID

    而如果后端消息处理系统为MQ Series，或者其他的JMS服务器，需要遵循该消息处理器所提供的消息关联机制，来设定消息关联的ID。例如，如果消息服务提供者为MQ Series，其消息ID关联的属性字段为MessageID，相应的Java实现接口也变为对MessageID属性的Get和Set操作了。

    动态路由

    在代理服务无法确切的了解哪个服务被调用，但知道接口的类型，而服务的调用是在输入的消息中所指定（服务接口类型可以被抽象化：命名消息类型、port类型和绑定信息，除了具体接口定义。具体的接口定义是表示服务具体位置的transport URL）

    此种场景下，实现机制是注册一个接口定义的业务服务（而transport URL的定义可以无关），流程中的路由或发布节点中，增加一个动作设定$outbound变量中的服务的URL信息，调用具体的服务，这可以使URL信息可以在运行状态时提供，而无需在设计时指定。

    操作Weblogic 8.1的回调

    Weblogic 8.1 提供一个所谓回调的概念。通常，具有回调接口的WSDL提供一个回调通知或具体的应答操作方法。回调地址在请求消息中的SOAP头中包含。

    为了支持与WebLogic Platform 8.1上的服务的互操作性，用户可以进行如下配置：

    1.将具有回调的WSDL 的port type/binding 分拆成两个port types/bindings --- 一个是消息接收(请求的 port type)，而另一个是服务回调方的回调(callback port type)。通知操作(Notification)可以成为一个新的单向操作，而具体的应答转变成为一个请求/响应的操作 ，服务总线提供了分拆WSDL的功能选择。
    2.基于请求的request porttype.  定义业务服务
    3.基于callback porttype 定义回调服务，具体的URL并不重要（可以参考上一节的动态路由）
    4.使用请求类型（request port type）定义代理服务 (Proxy_R)，并路由到请求的业务服务上
    5.使用callback port type定义回调的代理服务(Proxy_C)。并路由到回调的业务服务上。
    6.在Proxy_R的请求处理中，从SOAP头中获取回调的URL地址，并替换为 Proxy_C服务所提供的URL。这可以使请求的业务服务知道从该向哪里发起回调服务调用。流程中增加一个变量用于存储该URL，我们称之为回调URL（callback_URL），保存从Proxy_R SOAP请求中的SOAP头中的回调URL地址，这可以保障在Proxy_C服务执行时，它清楚该最初的URL地址，以便回调时可以找到。这样服务总线无需保存状态（服务总线是一个无状态的架构）。例如：传输给请求业务服务的回调地址为：http://Proxy_C?CallbackURL=”http://callback_URL”
    7.在 Proxy_C中，它首先从$inbound变量中获取参数，解析并抽取出callback URL参数，并在调用真正的回调服务时，在$outbound变量中进行设定，此时系统可以动态的路由回调到最初请求所指定的回调URL上。

    使用 WSCallouts

    服务总线关注于各种不同传输协议之间的路由消息，同时在处理过程中保障安全和格式转换。因此它并不真正适合创建复杂的消息，服务协调和服务数据的汇总。BEA的其他产品如：Aqualogic Data Service Platofrom或WebLogic Integration更加适合。服务总线的代理服务可以调用Liquid Data 服务或workshop开发的JPD，反之，Data Service或JPD也可以调用服务总线的代理服务。

    WScallouts 提供了服务协作、组装和数据汇总的服务调用功能。但WScallouts的基本使用场景是：

    消息验证：调用web service来进行消息格式校验，例如对于订单可以判断其是否能执行订单处理。
    消息格式丰富：调用web service来丰富消息的格式，以便路由节点所调用的服务能正常处理该消息。
    消息的转换：调用web service来通过相关转换引擎进行格式转换
    消息路由：调用web service 来传递相关参数，以便决定该向哪类服务进行路由