RE: [ebxml-msg] Node type definitions

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

Title: Node type definitions

Ian:

 

Not sure if we can talk of "node types".

 

Before looking at intermediaries, we should keep in mind that these behaviors are already controlled in regular (Core V3) MSHs based on either PMode configuration or implementation details.

 

For example, " stream vs. collect"  is controlled in any MSH based on PMode configuration - Push or Pull. For example, the PMode will tell what are the MPCs to be pulled from (each endpoint MSHs will pull on a different MPC on the same intermediary )

 

The difference between "stream"  and "store+forward" could be reduced to an implementation aspect, just like when using a regular (Core V3) MSH, its implementation details will decide whether to store or send immediately, the message you submit. (Note that "stream" mode could still take advantage of RM resending mechanism - meaning some storage can take place in the RM module).

 

Now, it makes sense that some intermediaries - especially those that are only communicating with other intermediaries (not with endpoint MSH) should not be bothered with PModes. In such cases, we could assume a behavior that is kind of hardcoded - e.g. store and forward for all messages. To me, that still looks like an implementation decision, with little need for exposure in a multi-hop specification.

 

On the other hand, enabling a "forward and collect" mode on the intermediary MSH without resorting to a PMode deployment , will likely require PullRequest to be "extended" with an option that will make it possible to pull all messages, without having to know the various MPCs they have been assigned to.

 

The point is, because an intermediary may communicate both with other intermediaries and with regular MSHs, and because there is already a way to control these behaviors for a regular MSH (PMode). we have to be careful that these control mechanisms can coexist in the same MSH.

For example, if my intermediary MSH1 communicates both with intermediary MSH2 and endpoint MSH3, and you decide that MSH1 must do "store and collect" for MSH2, then you still want MSH1 to know how to separate the flow that goes to MSH3 (by push or pull) from the flow that is pulled by MSH2.  

 

Jacques

---

From: ian.c.jones@bt.com [mailto:ian.c.jones@bt.com]
Sent: Wednesday, February 27, 2008 5:05 AM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Node type definitions

All,

        my starter definitions for the types of node from Sander's proposal, feel free to add/refine and argue:

Definitions of node types

Store and forward
The node completes receipt of the transmission before beginning transmission to the next mode. i.e 2 separate sequential processes that the second does not start before successful completion of the first.

Store and collect
The node completes receipt of the transmission before allowing it to be retrieved (pulled). i.e. 2 separate process that the second cannot be attempted until the first is complete but the second process is always initiated by the other party.

Streaming
The node passes information as soon as it is received.  i.e. it just routes data to the next node as soon as possible it does not store any data.

Ian Jones
Chair OASIS ebXML Messaging Services TC
Email: ian.c.jones@bt.com