1) Explanation
The ESB (Enterprise Service Bus) is the holy grail of applications integration.
It is actually an integration platform used to allow applications to integrate more easily into an enterprise landscape.
The ESB defines the infrastructure, the foundation, in which the different applications and services of an enterprise landscape will integrate. It stands for a specific architecture style enforcing a communication bus to be used for inter-application or inter-services communication. Depending on the structuring of the enterprise landscape, that means service oriented or application based, the bus is used for service integration in comparison to "only" connecting different applications over a common communication bus.
2) Initial situation
Having an enterprise landscape with many applications that need to communicate with each other,
lead to many point-to-point communications with all its disadvantages.
That are implementing retry mechanism in each application that interacts with another application.
Dealing with the complexity of timeouts(connection and read timeout) - finding the right timeout window, distinguishing between operations that can and that shouldn't be repeated.
3) Benefits
Business events that happened are published by the source application to the bus.
Typically there is an application interested in this event, so it will consume it as this kind of processing would have been done by a point-to-point communication.
But now comes the benefits of an enterprise bus into play. If business requirements changes and enterprise landscape grow more and more applications might potentially be interested in that kind of events. So the producing application does not have to be changed at all.
Additional systems that are interested in that event just subscribe to the topic or if there is a dispatcher application in place, that consumes special kind of messages laying on the bus, will then dispatch requests to the corresponding systems.
Integration scenarios are typically configured / implemented with the help of a DSL leading to more maintainability and faster realization.
ESB allows:
- Heterogeneous environments get interoperable
- Service virutalization aka as location transparency
The service consumer and the service provider is decoupled by the ESB.
With service virtualization the service consumer has not be reconfigured if the service provider is changed regarding
endpoint information.
- Service versioning
With message transformation the message of an interface that is not support anymore is translated into a message of
new interface version.
Benefitting from again the fact that the service consumer is decoupled from the service provider.
The additional "layer" can be used to allow a technical mapping between an old interface and the new one.
Allowing business adaption independent of interface availabilities.
- Transaction-based message processing
The message is taken from queue and during the processing of the defined workflow involving maybe different services
and service calls, the whole transaction is only committed if the process arrived the last service that is a database
adapter. The whole process is committed as the flow reaches the db adapter.
So the ESB can be used to coordinate distributed transactions with different services involved. The client has only to
mark the begin and end of a transaction.
The coordination work is done by the bus.
4) Background
Basic groundwork was done by Hophe and Woolf with their work on EIP - Enterprise Integration Platform.
They have described common integration scenarios, abstracted them into different patterns, and categorized them into the following 6 categories:
- Message endpoints
All kind of patterns for connecting applications that should integrate with each other.
E.g.:
- Polling consumer - An adapter that polls periodically a data source and consume the data that needs to be
processed.
- Service activator - A component that locates a service of an application that then will be called.
- Message construction
All kind of patterns that deal with messages itself.
E.g.:
- Correlation Identifier - The correlation id is used to map messages to a transaction Messages that took part in a
transaction should have the same correlation id.
- Message expiration - Message have a period of time in which they need to be processed. If this time passed
without processing they are dropped by the message broker or moved do a dead letter queue.
- Message channels
All kind of patterns that describe how message are delivered to message endpoints.
E.g.:
- Guaranteed delivery - Producer can rely to 100% on the fact that if a topic or queue has confirmed the receive of a
message, that the message will be later on processed. After the confirmation the resources of the JMS client are
freed and he can continue with further actions/processing.
- Point-to-point channels - A message channel pattern to realize a synchronous communication based on JMS.
Sender blocks until receiver of a message has processed and delivered the result to the sender.
- Message routing
All kind of pattern that do not change the semantics of a message - no content change. But based on certain rules
messages are forwarded to different endpoint.
E.g.:
- Aggregator - Split message are composed to a new resulting message.
- Splitter - A message is split in several parts that result in new messages.
- Message transformation
All kind of patterns that change the content of a message.
E.g.:
- Enricher - A message is enriched with further information from other services, data sources etc.
- Message translator - Transforming a message of a data model A into a message of a data model B without
changing the semantic of the message.
- System management
All kind of patterns that can't be categorized in the above categories or have general supporting characteristics.
The ESB (Enterprise Service Bus) is the holy grail of applications integration.
It is actually an integration platform used to allow applications to integrate more easily into an enterprise landscape.
The ESB defines the infrastructure, the foundation, in which the different applications and services of an enterprise landscape will integrate. It stands for a specific architecture style enforcing a communication bus to be used for inter-application or inter-services communication. Depending on the structuring of the enterprise landscape, that means service oriented or application based, the bus is used for service integration in comparison to "only" connecting different applications over a common communication bus.
Having an enterprise landscape with many applications that need to communicate with each other,
lead to many point-to-point communications with all its disadvantages.
That are implementing retry mechanism in each application that interacts with another application.
Dealing with the complexity of timeouts(connection and read timeout) - finding the right timeout window, distinguishing between operations that can and that shouldn't be repeated.
Business events that happened are published by the source application to the bus.
Typically there is an application interested in this event, so it will consume it as this kind of processing would have been done by a point-to-point communication.
But now comes the benefits of an enterprise bus into play. If business requirements changes and enterprise landscape grow more and more applications might potentially be interested in that kind of events. So the producing application does not have to be changed at all.
Additional systems that are interested in that event just subscribe to the topic or if there is a dispatcher application in place, that consumes special kind of messages laying on the bus, will then dispatch requests to the corresponding systems.
Integration scenarios are typically configured / implemented with the help of a DSL leading to more maintainability and faster realization.
- Heterogeneous environments get interoperable
The service consumer and the service provider is decoupled by the ESB.
With service virtualization the service consumer has not be reconfigured if the service provider is changed regarding
endpoint information.
With message transformation the message of an interface that is not support anymore is translated into a message of
new interface version.
Benefitting from again the fact that the service consumer is decoupled from the service provider.
The additional "layer" can be used to allow a technical mapping between an old interface and the new one.
Allowing business adaption independent of interface availabilities.
The message is taken from queue and during the processing of the defined workflow involving maybe different services
and service calls, the whole transaction is only committed if the process arrived the last service that is a database
adapter. The whole process is committed as the flow reaches the db adapter.
So the ESB can be used to coordinate distributed transactions with different services involved. The client has only to
mark the begin and end of a transaction.
The coordination work is done by the bus.
Basic groundwork was done by Hophe and Woolf with their work on EIP - Enterprise Integration Platform.
They have described common integration scenarios, abstracted them into different patterns, and categorized them into the following 6 categories:
- Message endpoints
All kind of patterns for connecting applications that should integrate with each other.
E.g.:
- Polling consumer - An adapter that polls periodically a data source and consume the data that needs to be
processed.
- Service activator - A component that locates a service of an application that then will be called.
All kind of patterns that deal with messages itself.
E.g.:
- Correlation Identifier - The correlation id is used to map messages to a transaction Messages that took part in a
transaction should have the same correlation id.
- Message expiration - Message have a period of time in which they need to be processed. If this time passed
without processing they are dropped by the message broker or moved do a dead letter queue.
All kind of patterns that describe how message are delivered to message endpoints.
E.g.:
- Guaranteed delivery - Producer can rely to 100% on the fact that if a topic or queue has confirmed the receive of a
message, that the message will be later on processed. After the confirmation the resources of the JMS client are
freed and he can continue with further actions/processing.
- Point-to-point channels - A message channel pattern to realize a synchronous communication based on JMS.
Sender blocks until receiver of a message has processed and delivered the result to the sender.
All kind of pattern that do not change the semantics of a message - no content change. But based on certain rules
messages are forwarded to different endpoint.
E.g.:
- Aggregator - Split message are composed to a new resulting message.
- Splitter - A message is split in several parts that result in new messages.
All kind of patterns that change the content of a message.
E.g.:
- Enricher - A message is enriched with further information from other services, data sources etc.
- Message translator - Transforming a message of a data model A into a message of a data model B without
changing the semantic of the message.
All kind of patterns that can't be categorized in the above categories or have general supporting characteristics.
No comments:
Post a Comment