Latest state of multihop Use Cases

A summary of multihop use cases we have so far, along 
with clarifications on some of these:

 

============= 
Use Case 1 =============

General 
business-level description: 

- 
A large number of "branches" (e.g. from of a global business) e.g. in the 
thousands across the world, need to send messages to a small set of global, 
specialized servers. The servers are selected based on eb:Service/eb:Action 
content. The branches never need to get anything back from these servers, except 
some signals (errors, receipts). 

Topology: 

- "networked gateways" model. Each branch has its ebMS MSH. Branches 
are grouped in many regional clusters with each cluster sharing the same 
(Gateway) intermediary to communicate with the world. Other intermediaries are 
involved on the path of a message toward 
its destination MSH for the appropriate server. 

Routing 
function: 

- 
from Branches to the Service providers: based on ebMS header content: 
eb:Service/eb:Action. 

Communication 
constraints: 

- 
Branches are not addressable. Can only push, or pull. The branches only use 
One-way / Push MEPs for sending messages. Need to pull the 
"Signals". Branches are uniquely identified (globally unique 
eb:From/PartyId). The regional Gateways are 
always addressable, accept messages from any other intermediary of the 
I-Cloud.

- variant (b): branches are addressable, can receive 
incoming eb messages over HTTP requests.

- variant (c): regional Gateways are restricting the 
set of intermediary nodes they can receive from.

Evolution 
profile: 

every 
week, new branches are created, some disappear.

 

============= 
Use Case 2 =============

General 
business-level description: 

- 
Public e-Procurement in Europe. Companies providing services to governments in 
their own countries will use the national messaging infrastructure (several 
emerging, may or may not use ebMS) to send invoices, receive orders etc. using a 
regional subset of UBL. Companies providing servives to governments in foreign 
countries will need a way to "bridge" between the two national 
infrastructures. 

Topology: 

- 
Cross-border messaging using a transformation point. That transformation point 
may act as an ebMS intermediary (if both countries use ebMS and there is 
end-to-end messaging, reliability and security, routing) or it may be an ebMS 
endpoint (repackaging the UBL business document using a different, non-ebMS 
infrastructure if the other country does not use ebMS). 

Routing 
function: 

- 
from companies to transformation point: the eb:PartyId/@type would indicate that 
the eb:To organization is in a different country, and which country. From the 
transformation point to the To party based on eb:PartyId/text() 

Communication 
constraints: 

- 
Variable. 

Evolution 
profile: 

- 
countries may open up to cross-border messaging in different speeds. Within each 
country there could be hundreds of thousands or more companies.

 

============= 
Use Case 3 =============

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". 

Evolution 
profile: 

- 
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).