Index Changes

As part of orchestrating services, it is often found necessary to call certain services whose end points (addresses) are not known at design time. Dynamic Partner Links feature allows you to assign an end point for the partner link if it is not known beforehand or change an end point during the process execution. This means you can use one partner link for sequential communication with several web-services (the services must have the same interface).

Please refer to Dynamic Partner Links for use cases and further technical information.

There are many ways to construct the end point information in BPEL. This article will show you all the different possible ways of doing the same. To deliver the address information to the partner link you can use standard Assign activity and BPEL Mapper. In the following examples the end point address follows the WS-Addressing schema. Refer to WS-Addressing standard (WS-A).



Following code snippet shows how a BPEL literal syntax can be used to define an endpoint address (here a http end point) and assign it to a partner link.

            <bpws:assign name="Assign2">
                <bpws:copy>
                        <bpws:from>
                                <bpws:literal>
                                        <sref:service-ref>
                                                <ns1:EndpointReference>
                                                        <wsa:Address>
                                                            http://localhost:8080/stockQuoteService/stockQuotePort
                                                        </wsa:Address>
                                                        <wsa:ServiceName PortName="stockQuotePort">
                                                            ns3:stockQuoteService
                                                        </wsa:ServiceName>
                                                </ns1:EndpointReference>
                                        </sref:service-ref>
                                   </bpws:literal>
                            </bpws:from>
                            <bpws:to partnerLink="plStockQuote"/>
                    </bpws:copy>
            </bpws:assign>

(Take it for granted that all the prefixes are defined correctly in the BPEL). Important thing to note here is that the WS-A defined schema object should be wrapped in an element called service-ref that is defined in the BPEL. Refer to BPEL spec, section 6.3 for further details on this wrapper service-ref.

The partnerLink "plStockQuote" could be subsequently used in an invoke.



Following BPEL mapping and code snippet shows how to extract partner link's endpoint and assign it to another partner link.

which generates the source code

        <assign name="Assign2">
            <copy>
                <from partnerLink="PartnerLink1" endpointReference="partnerRole"/>
                <to partnerLink="PartnerLink2"/>
            </copy>
        </assign>

In the above snippet, we copied 'PartnerLink1' partnerRole endpoint to 'PartnerLink2' and this 'PartnerLink2' could be used in subsequent invokes.



Refer here for complete BPEL and WSDL files used in the following code snippets.

Define the message with the end point schema as part of it. (There are a number of ways to do that, what is shown here is just one way of doing it).

    <types>
        <xsd:schema targetNamespace="http://j2ee.netbeans.org/wsdl/dynamicPL">
            <xsd:import namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" 
            schemaLocation="http://schemas.xmlsoap.org/ws/2004/08/addressing/"/>
            
        </xsd:schema>
    </types>
    <message name="dynamicPLOperationRequest">
        <part name="part1" element="wsa:EndpointReference"/>
    </message>
Note: prefix wsa is defined to point to http://schemas.xmlsoap.org/ws/2004/08/addressing.

Use this message variable to assign the end point at runtime to a partnerlink. See this sample and video demo. There is a special mapper function called "wrap with service reference" which eases the life of the BPEL developer to map the WS-A message to a partnerlink.

This special function generates BPEL doXslTransform() function as shown in the code snippet below.

        <assign name="Assign1">
            <copy>
                <from>ns0:doXslTransform('urn:stylesheets:wrap2serviceref.xsl', $DynamicPLOperationIn.part1)</from>
                <to partnerLink="PartnerLink1"/>
            </copy>
        </assign>
The stylesheet for the transformation is already defined by the editor.

Thats it! With the above knowledge of the partner links you can pretty much do all the dynamic invoking that your application demands. Based on your business use cases, you would employ one or more of the above techniques in your business processes. One of the things commonly used is to do a look-up of end point information and use that looked-up end point to invoke the service. The look up could be based on business needs. One example here (see the examples tab) uses a UDDI look up.


There is one more thing that users of BPEL and dynamic address need to know. A service needs to have the capability of sending it's own endpoints which may be used as call back addresses. The following mapping shows how to achieve this in BPEL.

The code snippet that it generates is

        <assign name="Assign2">
            <copy>
                <from partnerLink="PartnerLink1" endpointReference="myRole"/>
                <to variable="DynamicPLOperationIn" part="part1"/>
            </copy>
        </assign>
If this variable "DynamicPLOperationIn" is used in the subsequent invokes in the BPEL, then the end point information is passed on to the partner.

Note: BPEL spec mandates that only the partner address can be changed dynamically. In BPEL terms, only the partnerRole of a partnerLink can be assigned a value and myRole doesn't change after the BPEL has been deployed.

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-21) was last changed on 20-Mar-08 04:49 AM, -0700 by SenthilPrabhu