Posted by: Sasirekha R
Architecture, ESB, Integration, SOA, Web Services
Essentials of SOA, Web Services and ESB in the Integration context – Part III
Traditional Enterprise application integration (EAI) provided a hub-and-spoke architecture as a better solution compared to direct point-to-point connections. ESB moved further to provide the concept of bus – where the nodes have more intelligence – and offers better flexibility and scalability.
SOA offers great promise but also has great pitfalls. Making SOA work, avoiding the pitfalls and getting ROI, is hard. Usage of commercial tools simplifies SOA implementation enabling the focus to remain on business requirements – and not on implementation platforms and protocols.
Originally, an ESB product had a core asynchronous messaging backbone supplemented with intelligent transformation and routing to ensure messages are passed reliably. In other words, ESB was seen as a shared messaging layer for connecting applications and other services throughout an enterprise.
Today ESB is seen as a collection of architectural patterns based on traditional enterprise application integration (EAI), message-oriented middleware, Web services, .NET and Java interoperability, host system integration, and interoperability with service registries and asset repositories. The commercial tools offers support for various types of integration – using EAI, BPM, SOA, Message driven, event-driven, B2B as well as adapters for communication with different protocols, databases as well as standard products like ERP, CRM etc.
Reasons for using ESB as the integration backbone include the following capabilities:
- Provide location transparency and enable service substitution;
- Support integration in heterogeneous environments ;
- Support SOA principles, separating application code from specific service protocols and implementations;
- Act as a single point of control over service addressing and naming;
In an ESB, there is no direct connection between the consumer and provider. With an ESB, the infrastructure shields the consumer from the details of how to connect to the provider. While the service endpoints can have their own integration techniques, protocols, security models etc., ESB provides a simplified view to the service consumers. Thus an ESB allows the reach of an SOA to extend to non-SOA-enabled service providers. ESB also supports a variety of ways to get on and off the bus.
ESB supports Integration at various levels including:
- Application adapters
- Connectivity to EAI middleware
- Service mapping
- Protocol transformation
- Data enrichment
- Application server environments (J2EE and .Net)
- Language interfaces for service invocation (Java, C/C++/C#)
Message oriented middleware (MOM), the key behind ESB, offers flexibility in application development. MOM permits time-independent responses because it operates in an asynchronous mode.