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).
<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.
![]() |
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.
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.
![]() |
![]() |
<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.
(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.
![]() |
<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.