General business-level description:
- A particular set of government services and processez is provided by agencies in different sectors reporting to different ministries, that have their own (very large) private networks. Dozens of MSHs in various sectors, with some MSHs serving dozens or hundreds of parties. In total a few thousand parties.
Topology:
- Within a sector, agencies communicate via an intermediary. There is never any Endpoint to Endpoint communication. The intermediary is also the connection to agencies in other sectors (via their sector intermediary). Each intermediary knows whether the addressed To/PartyId is connected to itself (two hops) or is connected to some other sector hub (more than two hops).
Routing function:
- some intermediaries are also Endpoints (sector hubs, hosting sector services). They inspect the eb:Service to determine if they provide this service themselves (possibly on behalf of many different organizations), or need to forward the message to a separate MSH.
- when (not delivering locally but) forwarding, forwarding is based on ebMS header content: eb:To/eb:PartyId.
Communication constraints:
- Branches are not addressable. Can only push, or pull. The branches only use One-way / Push MEPs for invoking the servers. Need to pull the "Signals".
- Sometimes a business partner is first connected as an Endpoint to an intermediary, then later a Intermediary is inserted. This should not require any changes at the Endpoints other than changing the URL and TLS details. An intermediary should not have to know if the MSH it is connecting to is the Endpoint for the message, or an Intermediary that forwards it.
- PartyIds may move from one Endpoint MSH to another. Only the closest intermediary should have to take action to account for that change. No other intermediary or Endpoint should need to know (as they will still receive messages from, and send to, the same intermediary).
- Some intermediaries are also