Please enable JavaScript.
Coggle requires JavaScript to display documents.
Chapter 7: The Enterprise Service Bus - Coggle Diagram
Chapter 7: The Enterprise Service Bus
ESB introduction
ESB in SOA Infrastructure:
It facilitates the utilization of services within a productive system.
ESB is an integral part of Service-Oriented Architecture (SOA) infrastructure.
Definition and Role:
ESB stands for Enterprise Service Bus.
There are varying opinions regarding the exact role and responsibilities of an ESB.
Technical Approaches:
Different technical approaches exist for realizing an ESB.
These approaches lead to different understandings of ESB functionality.
Consequences:
The chapter explores the consequences of various technical approaches to ESB implementation.
ESB Responsibilities:
Enable consumers to call service providers' supplies.
Provide connectivity between various components.
Perform data transformation tasks.
Handle (intelligent) routing of messages.
Manage security aspects of communication.
Ensure reliability of message delivery.
Perform service management functions.
Monitor and log system activities.
Main Role:
The main role of the ESB is to provide interoperability.
Routing:
Routing is a fundamental task performed by the ESB.
Extension of Core Task:
The ESB extends its core task of providing interoperability to enhance system functionality.
Heterogeneous ESBs
The ESB was initially viewed as an Enterprise Application Integration (EAI) bus.
Web Services emerged as the de facto standard.
There arose a necessity to map proprietary buses to Web Service Buses through gateways.
Both providers and consumers expect the service API to be transparent from their perspectives.
ESB Differences
ESBs can vary significantly both technically and conceptually.
Some solutions may not require specific tools or software, relying solely on protocol definition.
Alternatively, an ESB might comprise various centrally or decentrally run tools and programs.
These tools are utilized by service designers, implementers, and operators.
Point-to-Point Connections
vs. Mediation
Point-to-Point Connections:
Consumer needs to know the endpoint.
Each request is sent to a specific receiver.
Call fails if the physical receiver is unavailable.
Mediation:
Consumer doesn't need to know the endpoint.
Service identified by a tag or symbolic.
ESB interprets to find an appropriate provider.
ESB acts as a mediator or broker.
Leads to a loosely coupled infrastructure.
Interceptors
ESBs with point-to-point protocols use "interceptors" or "proxies" to support indirect service calls.
Interceptors act as proxies for each provider and consumer in a complex ESB approach.
Consumers communicate only with their specific interceptor, which routes calls to the appropriate provider.
Web Services protocol is inherently point-to-point with no provisions for load balancing or failover.
Failed or overloaded web services can't route SOAP requests to alternative sites without interception.
Future ESBs based on web services must incorporate interceptors for load balancing, failover, security, and monitoring.
Protocol-Driven vs. API-Driven ESB
Protocol-driven ESB:
The ESB defines a protocol for communication.
Providers and consumers send and receive messages according to this protocol.
Example: Web Services using SOAP protocol.
API-driven ESB:
The ESB defines platform-specific APIs (e.g., Java interfaces).
Providers and consumers utilize these APIs for service implementations and calls.
Layersfrom business to Protocol Code
Tradeoff: Independence of infrastructure and development teams.
Protocol-driven approach:
Providers and consumers have more responsibility.
Infrastructure team and development teams are less interdependent.
Development teams for providers and consumers:
Have greater autonomy and control in the protocol-driven approach.