Dynamic endpoint binding in Oracle SOA Suite

Why is dynamic endpoint binding needed?

Sometimes a BPEL process instance has to determine at run-time which implementation of a web service interface is to be called. We’ll show you how to achieve that using dynamic endpoint binding.

Let“™s imagine the following scenario: we“™re running a car rental agency called RYLC (Rent Your Legacy Car) which operates different locations. The process of renting a car is basically identical for all locations except for the determination which cars are currently available. This is depicted in the following diagram:

There are three different implementations of the GetAvailableCars service. But how can we achieve calling them dynamically at run-time using Oracle SOA Suite?

How to dynamically set the service endpoint

There are just a couple of implementation steps we need to perform to enable dynamic endpoint binding:

• create a new SOA project in JDeveloper
• add a CarRental BPEL process
• add an external reference to the GetAvailableCars service within the composite
• create a DVM file containing the URI’s by which the services for the different locations can be accessed
• set the endpointURI property on the Invoke component calling the GetAvailableCars service (value is taken from the DVM file)

Those steps are described in more detail here: http://sgrosjean.blogspot.de/2013/01/how-to-set-endpointuri-dynamically-in.html

The composite view should now be similar to this:

Decouple composite design from specific endpoints

We need to allocate a concrete implementation of the GetAvailableCars service to the composite when deploying it. We could use the implementation of any of the location specific services (e.g. the Berlin service) but that is generally not a good idea as once the particular service is unavailable the composite can no longer be deployed.

Therefore we decouple the CarRental composite from any specific endpoint by adding the GetAvailableCars interface as an exposed service:

The mocked GetAvailableCars process is just there for decoupling a certain location from the caller during deployment time. During run-time the mock will not be called but replaced with one of the services configured in the DVM. However, if the dynamic call fails the mocked GetAvailableCars process returns an appropriate error message.  

In the config plan used for deploying the composite we must set the location of the external reference so that the composite seems to be calling itself:

Thereby we don’t have any dependencies on location specific services while deploying the composite. At run-time, however, the endpointURI property will override the deployed settings.

For the sake of completeness we must not forget that the dynamic call as described here (using Oracle SOA Suite only) could also be achieved using the Oracle Service Bus (OSB) and its Dynamic Routing component. In scenarios where no service bus is available, however, our approach is certainly worth consideration.