Run ION with multiple simultaneous Exchange message brokers
|References||CIAD COI OV Exchange|
|Is Used By|
|Is Extended By|
|In Acceptance Scenarios||None|
|Technical Notes||A message broker performs many functions: providing the primary messaging service for clients, implementing Exchange Points and Exchange spaces, hosting communication sessions, and enforcing messaging governance. Redundancy and distribution of load are two key reasons to operate multiple message brokers.|
|Primary Service||Capability Container & Distributed Service Infrastructure Part 2|
|UC Status||Mapped + Ready|
This information summarizes the Use Case functionality.
Operate the Integrated Observatory system with multiple Exchange message brokers, first under one domain of authority, then under different domains of authority. (In this scenario, no single broker is a single point of failure or source of governance.) Bring up two different message brokers and demonstrate they are separate; connect an application to each broker; and demonstrate the ability to communicate between the two applications. Repeat with brokers that are nominally being operated by a different authority (e.g., Scripps Institute of Oceanography rather than UC San Diego, with a different system running the message broker outside of ION.
ION is running with a single Exchange message broker.
- ION System Developer starts a second message broker within the same domain of authority.
- ION System Developer brings the second message broker into the system so that both are operational.
- They should be aware of each other, as appropriate to the design.
- ION System Developer connects an application to each broker, demonstrating its operation with its own broker.
- ION System Developer demonstrates the communication of the two applications, across the two brokers.
- ION System Developer shuts down the first message broker. Demonstrate that the system continues normal operations, as all messages are routed to the second broker.
- ION System Developer starts a third message broker, within a different domain of authority.
- At a minimum, the system is running externally to ION, in an independent system.
- Ideally, the system can be running using a different but compatible message broker. (Not a requirement for R2.)
- ION System Developer associates the two message brokers from the two domains of authority.
- ION System Developer demonstrates the communication of an application using the third, external broker with an application using the internal broker.
Communications among multiple message brokers has been demonstrated internally and across authority domains.
These comments provide additional context (usually quite technical) for editors of the use case.
This use case does not include demonstrating the successful recover from the failure of a message broker, but should by R3.
This use case should be enhanced (or perhaps another one developed) in Release 3 to cover additional requirements regarding messaging between brokers, such as intermittent connectivity (due to remote connections like satellite), intermittent bandwidth, quality of service and the ability to define VLANs. (See DOORS requirements.)