Depending of the choice of the broker architecture:
Very often a central Hub is chosen as the broker architecture. That means the messages on the bus all go through the hub.
- Scalability
-- less scalable as a distributed broker architecture
- Maintenance
++ easy to monitor
++ easy understanding
-- maintenance work on hub gets crucial
- Stability
-- single point of failure
Service locator
The service locator is responsible for locating / identifying the service of an application, that needs to be called to process a certain message.
Every service provider has to register the service at the service registry. Service consumer ask for the service and retrieve the endpoint for starting to consume the service.
The danger of a centralized service locator is similarly to the central Hub. If the service locator is to a certain moment not available no messages are processed as no services could be identified.
It is important that there are multiple instances of the service registry and that the configuration information is synchronized between them.
Messaging
Leads to decoupling between the communication partners - the messages are guaranteed delivered by buffering, saving and forwarding.
But there are situation where asynchronous communication leads to just more overhead and complexity swallowing the advantages.
Batch processing
The bus should not be misused for batch processing as throughput may much less as direct batch processing.
Mass data processing should still be accomplished by corresponding batch applications that might publish their result or special cases to the bus.
Business logic
A big danger is the possible development that business logic leaks into the bus - leading to maintainability and scalability problems.
Business logic should not be handled directly in the bus.
Commands
The bus should not be thought of an assembly line for placing orders.
Much better is to place occurred business events on the bus and let the connected applications / services consume those events.
No comments:
Post a Comment