RE: [ebxml-msg] Node type definitions

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:  
[mailto:] 
Sent: Wednesday, February 27, 2008 5:05 
AM
To: 
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: