Solving EAI with SOA Suite
By Tejas Joshi on Oct 18, 2010
By Tejas Joshi :Those of us who have been around for a while in IT, would know that we tend to solve same problems with new ways of thinking. I remember hype around EAI and working on number of projects 7 - 8 years ago in solving integration issues for very complex systems.
Some of the challenges that were dealt with were
- Standardize the integration interfaces across business systems
- allow for protocol switching
- allow for data mapping between source and target systems
- Transactional integrity with compensation logic
Some of the pattern in EAI were
- Hub-and-Spoke: example of hub and spoke concept refers to a parent or holding company that uses one business software system (the hub), which is integrated with the systems used business units within its fod.
- Bus: Example of Message Bus is a combination of a common data model, a common command set, and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces.
But we ended up with following disadvantages
- High initial development costs, especially for small and mid-sized businesses (SMBs)
- Require a fair amount of up front business design, which many managers are not able to envision or not willing to invest in.
- Most EAI projects usually start off as point-to-point efforts, very soon becoming unmanageable as the number of applications increase
- Costly and time-consuming to maintain tightly coupled point-to-point integrations
- Service premiums for evolving proprietary integration broker implementations
- Static data integrations with proprietary interfaces are difficult to extend to the web
With advent of SOA, a new way of thinking evolved which allowed us to look at integration as not just IT challenge but a business challenge. This forced us in thinking for business benefits, allowed us to priorities integration across systems that were business critical versus everything. We looked at building business functionality through reuse or service enablement rather than point integration between systems.
Recently, I was involved in migration project of an old EAI based Hub-n-Spoke systems to SOA Suite. It became quite apparent that even though our mandate was a clear migration from proprietary EAI system to SOA Suite, we could simplify a very complex solution using principles of SOA and SOA based tooling.
We had to migrate over 200 integration points across 15 systems with SOA Suite. While the requirements were captured as system behaviour, during analysis phase we realised that there were distinct integration patterns emerging around two principles
a) protocol used and message type
b) System data structure mapping from source to target
We were able to map a single integration pattern with 4 high level components
The pattern focused on four reusable services that formed the core of the solution.
- Inbound Reader Service: This service would accept inbound messages using required messaging protocol and type. Oracle Service bus is best placed to implement such services, which could be configure to read inputs across multitude of protocols in forms of proxy services.
- Structural Validator Service: This service would validate the messages to be structurally correct. This will ensure that the message processor service will only process valid messages. Example of such validation could be schema validation, file structure validation etc.
- Message processor Service: This service would be detailed business logic based orchestration to run business validation and transformation. SOA Suite based SCA could be used to implement this in BPEL. To make this process generic BPEL XPATH functions could be used to dynamic transformation.
- Message Publisher: This service would use dynamic content based routing to publish message to target system. This could be either implemented in SCA (mediator) or OSB.
The proposed solution based on SOA Suite can replace EAI for fraction of the original project cost and still maintain the essence of Hub-n-Spoke pattern