RE: [ebxml-msg] Latest state of multihop Use Cases

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Hello Jacques,

 

A few comments:

 

First of all, the "Communication constraints" for "Use Case 3" is a cut-and-paste error from your "Use Case 1" that I failed to notice before sending to the list.  The real-life deployment that this use case is inspired on uses a form of multihop with ebMS 2.0, so all MSHes push and are pushed to, no pull feature.  (I mentioned this before in http://lists.oasis-open.org/archives/ebxml-msg/200803/msg00039.html but I created and understand the confusion, apologies !).

 

Second, I think people could argue that your use case 1 could evolve quickly into one of the other scenarios:  is it really the case that there is never any need to send user messages to these branches (as notifications, or as responses in asynchronous two way interactions)?  If there emerges such a need, how are the branches addressed and routed to by intermediaries?  Well, eb:To/eb:PartyId seems like a likely option, since the branches are separately identifiable entities (Use case 3).  If there are really huge numbers of branches (more than thousands), an indirection based on eb:To/eb:PartyId/@type would be useful (Use case 2).  

 

After some thinking, I can imagine cases like use case 1, e.g. if some MSH connects using variable gateways, e.g. a roaming MSH that uses some convenient or dynamically determined gateway MSH.  The ebXML equivalent of a roaming traveller using whatever hotspot is available to connect while travelling.  Signals and reliable messaging need to be aware of which hotspot=gateway MSH the message originates from.  No static reverse routic tables would work. But is this a hard requirement for the interactions that are in scope for ebXML, positioned not as a general messaging framework like WS-*, but as a specialized higher-level framework for B2B/G2G interactions, typically based on negotiated agreements and collaborations?  What real-life B2B/G2G application scenarios can we not handle if we add optional user message elements to signals and require reverse routing tables based on such elemens only?

 

Pim

 

---

From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
Sent: 13 March 2008 19:54
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] 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).