This problem (decoupling the business logic and interfaces) occurs not only in Java components but in case of any middleware components.
Applying this pattern would be vital for our OSB components as well. One of the greatest ability of the OSB is to create middleware components very quickly and easily. However using this design pattern in OSB is not so straightforward at first glance. Please have a look at the next image:
As you can see the service definition is bundled with the message flow. Do we have to copy and paste the message flow if we want to create an additional interface (e.g. for JMS)? Of course we mustn't even think of this solution! The solution is the next:
We have to create a proxy service for the business logic and some other proxy services for the facade interfaces (e.g. if we have to implement a JMS and a webservice interface for our service then we have to create three proxy services).
The only tasks of these facade proxy services are to provide their interfaces and to call the WORKFLOW proxy. We can keep the message flow very simple.
We have to implement the business logic in the WORKFLOW proxy service. The attributes of proxy:
Service type: Any XML Service
Protocol: local
This proxy must be defined as a local service. You can find more information about the local proxies here: http://docs.oracle.com/cd/E23943_01/dev.1111/e15866/local.htm. Now it is enough to know that we can use this type of interface to define common components in OSB.
It is very important that in case of fault we have to use an action 'Reply with Success' otherwise we wouldn't be able to catch the fault in the facade proxy service.
I created the next project/folder structure:
