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