During a recent project at a customer I was designing and building several stateful and possibly long running BPEL processes that all interacted with each other in SOA Suite 11g. These processes would be required to read and write data to many different DB tables as well as integrate into 6+ web services and 1-2 MQ services. We decided that separating out the DB data access and service integration into different composites from the processes would provide several benefits such as:
- More easily supports multiple developers
- Clearly defines the purpose of each composite
- Minimize the impact of changes to DB or services
- Retain a single unified audit trail
- Deploy updates to individual layers
- Data Access
- Service Integration
The data access composite consisted of a single WS being exposed, with requests being routed through a mediator to multiple DB adapters. Each DB adapter generates its own XSD with its own namespace. We use the mediator to transform the input from the service to the required format for the adpater and to transform the output back to our standard data model using our defined namespaces. This meant that the only time the generated schemas were used was within the data access composite behind the mediator.
Even though we have split the data access and service integration into separate composite applications SOA Suite 11g is able to detect that they are running on the same SOA infrastructure and optimize the communication between them and retain a complete unified audit trail. This means that even though we have exposed the data access as a web service SOA Suite will internally optimize this and not make an external WS call, instead it will call the composite directly and keep a single audit trail. Below is an example of a unified audit trail between the process and data layers.