Re: Some pictures and questions

[christopher ferris <chris.ferris@east.sun.com>]

Rich,

Please see my responses below.

Cheers,

Chris

rsalz@CaveoSystems.com wrote:
> 
> I've been confused about reliability, synchronicity, intermediaries, etc.
> Yesterday's call didn't help. :)
> 
> In order to understand it, I drew some pictures.  I hope that others
> find them useful, too.  The numbered lines are intended to show the
> ordering and sequencing of the data flows.
> 
> The internal line within the MSH boxes is intended to show that there
> is per-transport (HTTP, SMTP, etc) code.  The internal line within the
> Party boxes is intended to show that there is an API.
> 
>  +------------+                                         +------------+
>  |            |                                         |            |
>  | From Party |                                         |  To Party  |
>  |------------|                                         |------------|
>  +------------+                                         +------------+
>     ||   ^^                                               ^^     ||
>      1    6                                                3      4
>     vv   ||                                               ||     vv
>  +------------+                                         +------------+
>  |           || ================== 2 =================> ||           |
>  | Orig. MSH ||                                         ||Target MSH |
>  |           || <================= 5 ================== ||           |
>  +------------+                                         +------------+
> 
> The data transfer mechanism *and format* for (1) and (6) are not currently
> defined; the spec says that a language-independant binding (I assume
> that means Corba IDL) is a topic of future work.  This is also true for
> (3) and (4).
> 
> The data transfer mechanism for 2 and 5 is defined for different
> transports, and the data format is ebXML (section 7).
> 
> I'm pretty sure that all of the above is correct.  Now for the questions
> and discusson.
> 
> I believe we want the behavior that the application sees to be the same,
> no matter the delivery topology.  Is that right?
> 
> If the From Party is connecting via HTTP to the Target MSH, then the
> >From Party is also the Orignating MSH.  Now, it will probably be a
> poor-quality MSH.  In fact, it might be so limited that it cannot meet
> the spec, in which case the the browser (or mail user-agent, etc.)
> *cannot* be an Orig. MSH.  For example, implementation of timeouts and
> retries will be difficult.
> 
> So, are off-the-shelf browsers, mail programs, etc., intended to work
> as a "bundled-in" Originating MSH, or is it expected that additional
> code will be required on the client machine?

the latter. Could be a plug-in, applet or some other mechanism.

> 
> Next question:  what does "reliable" mean, from the client's perspective?
> Does it mean that it got to the Originating MSH, the Target MSH, or
> the To Party?  It seems to me that it cannot always mean it got to the
> To Party, because that might be a big-iron batch process that isn't
> scheduled to run until later.  For example, the best that the Target
> MSH might be able to do is punch the cards and signal the operator to load
> the deck. (Okay, maybe not cards.  Maybe write the 9track tape. :)

From the "application's" perspective (client) as you point out, 
there is no defined API, but because the MSH assumes responsibility
for the reliable delivery, an application *can* fire-n-forget
w/r/t the originating MSH. However, an application may require
synchronous exchange (e.g. it is going to block on a response)
and in this case the originating MSH has to perform its
function, await the response and return that response to
the calling application/client).

> 
> When Intermediate MSH's are involved, as shown below, does the meaning
> of reliable change?
> 
> Last week we were approaching consensus to move to a point-to-point
> protocol.  That would imply that reliable means "the next transit
> agent got the message."  So the From Party has no visibility beyond
> Originating MSH, and the Originating MSH only knows that the Intermediate
> MSH accepted responsibility.
> 
>  +------------+                                         +------------+
>  |            |                                         |            |
>  | From Party |                                         |  To Party  |
>  |------------|                                         |------------|
>  +------------+                                         +------------+
>     ||   ^^                                               ^^     ||
>      1    6                                                3      4
>     vv   ||                                               ||     vv
>  +------------+              +------------+             +------------+
>  |           || ==== 2.1 ==> ||          || === 2.2 ==> ||           |
>  | Orig. MSH ||              ||Inter. MSH||             ||Target MSH |
>  |           || <=== 5.2 === ||          ||<=== 5.1 === ||           |
>  +------------+              +------------+             +------------+
> 
> What does "reliable" mean from an MSH's perspective?  Does it mean it got
> to the next hop, or that it got to the target MSH? Is an MSH expected to
> know if it's an Originator or an Intermediate? In the event of delivery
> failure (e.g., the Target MSH determines that there is no such To PArty),
> is the intent that the failure notice go to the Intermediate MSH for
> delivery to the Originator or directly to the Originator?

In Tokyo, we discussed this and concluded that the intermediary
MSH was actually delivering the received message to a "routing
application" which made the determination as to the next
destination (resolving the To logical address to a physical
address of the next MSH in the chain). Thus, it is no different
than a terminal MSH in that it resolves the receipt of a message
to some application handler for processing.

> 
> How much state are we going to require the Intermediate MSH to keep?
> Is it just a pass-through pipe, or is it expected to do its own resends
> and re-acks, for example?

The intermediary should (IMHO) be supporting reliable delivery
and therefore it needs to persist the messages, ack them, etc.

> 
> I think "synchronous" also gets into the picture...  What's the intended
> behavior when an MSH says "I got your message" and later on finds out it
> is unable to deliver it?  If the From Party API blocks until the message
> is received, that's synchronous delivery, right?  If it doesn't block,
> then the Originating MSH can only say "apparently queued successfully".
> And later on -- via interrupt, callback, or explicitly query API --
> the Originating MSH will be able to inform the From Party that delivery
> failed.
> 
> Should all delivery failures be sent to the Originating MSH?  I think
> they have to be, because the failing MSH has no way of knowing if the
> >From Party is blocked in the API, looping in a queue read, or whatever.
> 
> Do we need delivery ACK notices?  Without them, then either:
>     a.  an MSH must maintain state to tell its client about the failure; or
>     b.  the Failure must contain the state

delivery ack is orthogonal to reliable messaging semantics
IMHO. 

The question that I always try to frame is "what is the
originating MSH gonna do about a receiving MSH's inability to
forward the message to the handling application? Typically,
it can do nothing other than to possibly report this
to the "application" or log the failure in some file
that is interigated by some human...

The business process defines a set of "signals" that a
party can employ so as to inform the other party in a 
collaboration that it (the receiving party):
	- is capable of parsing/processing the message
	- has pre-processed the message against a set
	of rules and found it to be...
	- has accepted the message and will act on it

or something to this effect. The MSH cannot and should not
be in the business of generating these messages... this
is something which either the application, or some 
support layer of software should be performing as it
is specific to the business process, not a generic
messaging function. The MSH MAY facilitate some
of this processing as an extension to its base
functionality, but clearly this is outside the scope
of the MSH specification.

> Is there another alternative?
> 
> Okay, that's enough.  Hope this more helpful than harmful.
>         /r$
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard