wsstack 4.4 Message Bus Architectural Analysis
Replace Mule with Spring Integration.
- Status: Step #1, initial draft
Features in the 4.4/5.0 release that are relevant for this feature.
- 5.0 SQS service configuration will need to use new approach, may have messaging requirements
- ELB using SWF relies on threading changes for scalable long polling
- EUCA-12691 JIRA (eucalyptus.atlassian.net) configuration may use a different property or may be removed due to changes for this feature
The threading model for spring integration is more flexible than mules. As part of the replacement we may want to use a design with fewer threads.
Currently we require blocked threads for local calls and remote calls are limited by a components thread pool size.
Calls between components must use distinct threads so that transactions are not shared across persistence contexts.
Mule configuration places "filters" by message type on the "pipes", we should evaluate if a similar approach is necessary for any replacement.
Request context is preserved for authorization use (i.e. with asynchronous calls where thread local context would be lost)
Mule examines messages (types) to route to service implementations.
Resolving target messages to methods on service implementations is widely used mule behaviour that does not have an exact replacement in spring integration.
The MuleSensor provides instrumentation for mule operations. We would need to implement a replacement for spring integration if we want to preserve this behaviour.
We should ensure that messaging changes do not impact tracing functionality.
Assumptions and open questions around requirements for the feature.
Assumptions:
- Minor limitations on service target method resolution are acceptable.
Open questions:
- Any impact on message tracing?
- Do we need to replace the MuleSensor functionality?
- Are any statistics gathered from mule particularly useful?
The "message bus" for services consists of the ServiceContext and ServiceContextManager . This component is responsible for the management of spring contexts and provides an API for synchronous and asynchronous message exchanges with service implementations.
ServiceContext configuration (cloud properties) should be updated and we should use a shared thread pool for all components by default.
Threads provides thread pools used by the messages bus.
Bootstrap manages the lifecycle of the message bus.
A message is sent between components of the system. Messages are handled by service implementations.
An endpoint represents a (component) destination for a Message. An endpoint may be equivalent to a service implementation, though some services have internal dispatch using distinct service implementations for a single component.
Areas currently identified as risks:
- Threading with spring integration differs from mule
- Spring Integration Reference Manual (docs.spring.io)
- Correlation ID in 4.2
- Architecture: Eucalyptus System Events
- Message bus design