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
The final design we decided on ended up with 3 composite applications for the project:
- Process
- Data Access
- Service Integration
Process Layer
The process composite consisted of all of out BPEL processes, business rules, and the SFTP/DB adapters the were starting our processes. This composite only contained 2 references, one WS adapter to connect to the Data Access service and one WS adapter to connect to the Service Integration service. All of the data within this composite was based on the set of XSDs that we created to represent our data model. These XSDs contained the namespaces and data structures that we defined and were not generated.
Data Access Layer
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.
Service Integration Layer
The service integration composite consisted of a single WS being exposed, with requests being routed through a mediator to multiple WS and MQ adapters. In our case each web service we were consuming had many operations, but we were only concerned with 1 or 2 operations on each service. Also these services required a fairly large set of input data (15-20 fields), but most of this data was hard coded for a given project and only 1 or 2 fields were dynamically passed in. Having this layer allowed us to reduce the input of the service down to the 1 or 2 dynamic fields and add in all of the hardcoded values during the transformation in the mediator. It also allowed us to simplify the results passed back to the process layer to a subset of the data that we required instead of the 300 or more fields being returned.
Audit Trail
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.
Summary
By moving our data access and service integration to separate composites it allowed us to greatly reduce the complexity in the process composite. The developer working on the BPEL processes then did not need to know the details of the integrations, had much simpler data structures to work with, and could always work with a single data model. We found that this greatly improved the effeciency of building out the processes and allowed the developer to focus much more on the process itself instead of integrations and transformation.
