在 WebSphere Application Server V6.1 中实现 WS_Notification

petutor

Application Server 6.1 允许将自定义参数与使用者引用关联，从而提供了实现此设计模式的一流解决方案。清单 14 显示了用于创建自定义参数并将其与使用者引用关联的代码片段。


清单 14. 将自定义参数与端点引用关联
                               
EndpointReference consumerEPR = null;
QName pname = new QName("http://www.cna.com/data/name","name", "name";
try{
    URI epURI = new URI(ep);
    consumerEPR = EndpointReferenceManager.createEndpointReference(epURI);
                       
    // Add custom parameter to the consumer reference
    SOAPFactory soapFactory = SOAPFactory.newInstance();
    SOAPElement param = soapFactory.createElement("param", "param",
                                                                                "http://www.cna.com/data/param";
    param.addTextNode("Some parameter data";
    consumerEPR.setReferenceParameter(pname,param);
}
catch(Exception e){
    System.out.println("Error creating notification URI";
    e.printStackTrace();
}
          


通过将清单 14 中所示的代码添加到订阅实现（清单 3），可向 consumerReference 添加一个额外的元素，如清单 15 中所示。


清单 15. 使用者引用请求中的自定义元素
                               
<ConsumerReference xmlns="http://docs.oasis-open.org/wsn/b-2">
    <wsa:Address xmlns:wsa="http://www.w3.org/2005/08/addressing">
        http://localhost:9080/notificati ... icationConsumerPort
    </wsa:Address>
    <wsa:ReferenceParameters xmlns:wsa="http://www.w3.org/2005/08/addressing">
        <name:name xmlns:name="http://www.cna.com/data/name">
            <paramaram xmlnsaram="http://www.cna.com/data/param">
                Some parameter data
            </paramaram>
        </name:name>
    </wsa:ReferenceParameters>
</ConsumerReference>
          


随后会通过（此订阅的）每个通知消息以 SOAP Header 的形式传播此自定义属性，如清单 16 中所示。


清单 16. 通知消息中采用 SOAP Header 形式的自定义属性
                               
<soapenv:Header>
        <name:name wsa:IsReferenceParameter="true"
                        xmlns:name="http://www.cna.com/data/name"
                        xmlns:wsa="http://www.w3.org/2005/08/addressing">
                <paramaram xmlnsaram="http://www.cna.com/data/param">
                        Some parameter data
                </paramaram>
        </name:name>
</soapenv:Header>
          


为了访问此 Header，通知使用者实现应该实现 JAX-RPC 定义的 javax.xml.rpc.server.ServiceLifecycle 接口中的方法，如清单 17 中所示。


清单 17. 更改通知使用者以访问自定义属性
                               
public class NotificationConsumerBindingImpl
                           implements NotificationConsumer, ServiceLifecycle{

    protected MessageContext context;

    public void init(Object ctx){

        System.out.println("Inside Service init method";
        // Initialize message context for the service use
        ServletEndpointContext sc = (ServletEndpointContext)ctx;
        if(ctx != null)
            context = sc.getMessageContext();
        else
            context = null;
    }

    public void destroy(){

        System.out.println("Inside Service destroy method";
    }
       
    public void notify(NotificationMessage[] notificationMessage, SOAPElement[] any)
                                                        throws java.rmi.RemoteException {

        System.out.println("Recieving Notification ...";
               
        try{
            SOAPMessageContext smc = (SOAPMessageContext) context;
            SOAPMessage sMessage = smc.getMessage();
            SOAPHeader header = sMessage.getSOAPHeader();
            if(header != null){
                Iterator elements = header.getChildElements();
                while(elements.hasNext()){
                    SOAPElement hElement = (SOAPElement)elements.next();
                    System.out.println("Additional SOAP header:";
                    OutputFormat ouf = new OutputFormat();
                    XMLSerializer serializer = new XMLSerializer(System.out,ouf);
                    serializer.serialize(hElement);
                    System.out.println(" ";
                }
            }
        }
        catch(Exception e){
            System.out.println("Error getting additional SOAP headers";
            e.printStackTrace();
        }
    .................................
    }
}
          


由于额外的参数是作为常规 SOAPElement 的一部分表示的（在 XML 树中有效），因此可以表示所需的任何信息，包括实际通知使用者的端点地址（图 8）、映射要求和系数等等。这样就能构建非常轻量级的无状态代理 (proxy) 来支持多种传输和转换选项。

结束语：有价值的折衷带来更大的灵活性

通过使用 WebSphere Application Server 6.1 中的 WS-Notification 代理，可以在 SOA 中创建用于发布和订阅消息传递的基于标准的灵活可扩展实现。它非常便于配置、使用和编程。

共享本文...


Digg 本文章

发布到 del.icio.us

  Slashdot 一下！




还需要对一些现有 SOA 实践进行反思。尽管许多书籍文章都支持使用其他方式，但很多当前的 SOA 实现都使用强类型通信替代语义消息传递。用于设计服务接口的常见方法（并不一定是正确的方法）是以 Java 类的形式对其进行定义，并随后基于其生成 WSDL 文件。此类方法可最小化开发人员处理 XML 和 WSDL 的需求，将 XML 封送/取消封送工作转移到 Web 服务运行时，从而简化了开发人员的工作。不过，这通常会对服务实现的可操作性造成影响。

直接公开本地应用程序模型通常会导致在整个系统中进行大规模转换工作。WS-Notification 规范将业务消息定义为 SOAPElement（XML 树），如果使用此规范，则需要采用不同的方法处理接口定义。与企业应用程序集成（Enterprise Application Integration，EAI）最佳实践类似，这种体系结构要求使用可供所有使用者和提供者共享的规范消息定义。此类规范消息通常会定义企业语义（业务对象定义的公共集），从而支持不同使用者和提供者之间实现无缝的互操作能力。

此外，此方法避免了使用 Web 服务运行时进行 XML 处理。开发人员需要负责以编程的方式在 SOAPElement 和基础应用程序对象之间进行转换。尽管乍看起来似乎是个复杂的服务实现，但最终会带来灵活得多的系统。此类方法不再使用 XML 为对象封送提供开销巨大的支持，从而释放了 XML 语义消息传递的强大功能。各个参与者能够自由地按照所需的方式准确地处理消息。（他们可以仅选取关心的元素。）而且，发布方引入的对消息传递的任何扩展并不会影响现有通知使用者。