Point-to-point communication normally has issues with scalability. These issues are further compounded with increased systems. ESB, a middleware technology, is a Bus-like architecture used to integrate heterogeneous systems. In ESB, each application is independent and yet able to communicate with other systems. It, thus, prevents scalability issues and ensures that communication happens only through it.
ESB’s guiding principles are:
- Orchestration – integrates two or more applications and services to synchronize data and process.
- Transformation – transforms data from canonical to application-specific format.
- Transportation – protocol negotiation between multiple formats like HTTP, JDBC, JMS, and FTP, etc.
- Mediation – multiple interfaces for supporting multiple versions of a service.
- Non-functional consistency – transaction management and security.
When to use ESB architecture
The first step when opting for ESB architecture is to map its value to requirements. Given below are some usage guidelines:
- When system integration points grow beyond two, with additional integration requirements.
- When using multiple protocols such as FTP, HTTP, Web Service, and JMS etc.
- When there is a requirement for message routing based on message content and similar parameters.
ESB architecture Implementation Rules
- Messaging services like JMS can be used to de-couple applications
- XML format when canonical data is used for communication
- Using an adapter that is responsible for marshaling and un-marshalling data. The adapter is also responsible for communicating with the application and bus. It is then used to transform data from application format to bus format
- Non-functional activities like securities, transaction management are also performed by the adapter in ESB.
To summarise, ESB provides for a flexible architecture. It enables multiple application communication and provides easy integration with other systems.
