April 13 2011

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. 
Process Layer

 

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. 

 

Data Layer

 

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.  

 

Service Layer

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.

Audit Trail

 

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.

About the Author

Adam Desjardin

Adam DesJardin is the Chief Technology Officer for AVIO Consulting.  Adam focuses on technical strategy, standards and delivery both within AVIO and for our customers.  Prior to joining AVIO in 2007, Adam held various consulting and architecture positions at Fuego and BEA Systems where he developed and delivered process and service driven solutions.

Join the Conversation

Enter your first name. It will only be used to display with your comment.
Enter your email. This will be used to validate you as a real user but will NOT be displayed with the comment.
By submitting this form, you accept the Mollom privacy policy.