Protocol Bridging is quite easy to achieve using OpenESB because one of the core advantages provided by the JBI infrastructure is loose coupling between bindings and services.
A Binding Component (BC) Service Unit (SU) acts as service proxy. From the perspective of services within OpenESB, a BC SU offers a wsdl-described interface to a remote service over a particular protocol. That is, it appears as just another service interface. From the perspective of a remote service, a BC SU offers a protocol specific interface which results in a service invocation of some other service within OpenESB.
To achieve Protocol Bridging you need to:
Create a BC SU to the remote Service Provider. This SU creates a wsdl-described service interface - a service proxy - for that Provider within the OpenESB.
Create one or more BC SUs for the Service Consumers.
Join the SU(s) for the Service Consumer to the Service Provider. This results in the incoming Service Consumer request to invoke the service interface for the outgoing request to the provider.
Things to remember:
The payload of the incoming Service Consumer request must match the payload expected by the Service Provider.
To ensure the SUs within OpenESB are protocol agnostic, Binding Components remove protocol specific information when requests come into OpenESB and add protocol specific information when request go out of OpenESB. If you have an EJB SU being exposed through a SOAP BC, then the SOAP BC removes the SOAP envelope and only passes the SOAP Body payload to the EJB SU running in the JavaEE SE. Alternatively, you could have the same EJB SU being exposed via the JMS BC. If you passed a SOAP msg over JMS, the BC would remove the JMS specific information and pass the payload - i.e., the entire soap envelope - to the EJB SU.
Service offered locally in an Service Engine
Local Scenario #1:
The general scenario is that you have a Service being offered by OpenESB with a particular binding. E.g., the SU is running in a particular Service Engine - e.g., BPEL SE or JavaEE SE. The service is exposed to remote consumers using a particular protocol binding - e.g, SOAP 1.1 webservice. The goal it also offer it through another binding, such as JMS. This scenario is an generalisation of the Dual Protocol pattern.
Local Scenario #2:
A less common, though valid scenario, is when you have a scenario like Scenario #1 above. However, rather than routing the payload from the JMS msg directly to the service, you want it to be routed via the SOAP Binding instead. This may be because you are receiving SOAP msg over JMS and you want the SOAP/HTTP Binding to process the SOAP msg and enforce a WS-Security Policy in the binding rather than pass the entire soap envelope to your service logic. This is the same as the remote service example detailed below.
Service offered remotely through a Binding Component
Remote Scenario #1:
Using OpenESB as a Broker which connects external Service Consumers and Providers that communicate using different protocols. The example provided by SOAPatterns.org, and illustrated in the image above, shows a broker connecting Consumers that communicate using SOAP1.1 and JMS with an existing Service Provider the communicates using SOAP1.2. In this scenario you would require a BC to represent the SOAP1.2 connection to the Service Provider. You then add a SOAP1.1 and JMS BC and connect them both to the SOAP1.2 BC to achieve a Protocol Bridge.
This is illustrated in the following example. For this example, an EJB WS is implemented to represent a remote service. Although it is running in the same application server as OpenESB, it is external to OpenESB and requires over-the-wire communication. The scenario assumes a Service Consumer that communicates via File/FTP. It add service requests to a file location on the OpenESB node and fetches responses from the same directory at a later time. To achieve the Protocol Bridge, a SOAP/HTTP BC is used to provide the interface to the remote service. Additionally, a File BC is to provide the binding for the Service Consumer request and reply. The same principles apply if the Consumer required another protocol.
The screencast begins by showing the remote service and testing it. Then a CASA project is created and the outgoing BC is created by importing the WSDL for the remote service. The incoming binding is created by adding a File BC SU to the canvas and connecting it to the outgoing BC SU.
This screencast depicting how to implement WS-Security with Mutual Certificate authentication is an example of Protocol Bridging. An EJB webservice is implemented which enforces the ws-security policy using the WSIT/Metro libraries. In OpenESB, a composite application is created with a SOAP BC SU configured to call that service using the appropriate security configuration. However, the unit testing tool does not support WS-Security, so a proxy interface is created with another SOAP BC SU. The two SUs are connected to bridge requests from the the anonymous unit test tool to the protected Service Provider
The principles that govern how Protocol Bridging can be realised - the loose coupling between service and bindings - remains the same for OpenESB v3. However, whether those SUs are connected in CASA or the Integration Flow Language and its WebGUI are still being determined. If IFL/WebGUI is used to implement the Protocol Bridging, then the solution also starts to implement the Orchestration pattern. More discussion of how IFL can be used to Orchestrate services is available on the Orchestration page.
The following example shows how to implement the Remote Scenario #1 using the IFL WebGUI of OpenESB v3
SP-TODO: screencast showing protocol bridging using v3 and webgui