Re: Proposed Revisions to MS ver 0.8

[Jim Hughes <jfh@fsc.fujitsu.com>]

At 02:02 PM 11/16/2000 -0500, Henry Lowe wrote:
>Hi,
>
>Since we didn't get to discuss this on this morning's ConCall,
>here are a few comments via the list server.  These are general
>principles so there are no line-by-line changes.
>
>1. While workflow is mentioned, details are not spelled out, but it
>    is implied that workflow is similar to Simnple Routing in clause 2.4.
>    I do not beleive this is the case.  Workflow is very different from
>    what is trying to be done with simple messaging and should be handled
>    by a separate layer above the MS layer.  This means there should be
>    NO data structures in MS for workflow -- workflow will define its
>    own processing and routing (it may well appear in the TPA when NG TPAs
>    can deal with more than two parties).

I agree that WF should be handled as a BP level activity, from the 
perspective of the MSH, at least for the current ebXML deliverables. Maybe 
sometime late next year this could be revisited. :-)

>2. The simple routing assumes a model wherein it is a separate layer
>    above the MS.  If this model is used (I don't think it is necessary),
>    as for workflow, there should be NO data structures in MS for routing
>    as routing will define its own headers, etc. in its own message.

It may be stretch to call it another 'layer', as there is really no upper 
level activity possible in this Simple Routing. The model just describes 
how an implementor could bolt together two MSHs (Receiving and Sending) 
with some pre-defined logic to forward messages along. This hub could use 
routing tables, dynamic choices based on loading, fixed routing or whatever 
to decide how to forward the unmodified message.

Yep, the number of Routing Headers increases with each link in the chain, 
but that was the design, given the security constraints. Of course, it's 
open for discussion!

>    The way it is, simple routing (both with and without reliable delivery)
>    (a) violates layering, (b) requires routing tables, and (c) causes
>    headers to grow which means that lengths (at least) have to be 
> recalulated
>    at each step of the route.
>
>    While the Internet uses routing tables, this is not the only way to do
>    routing.  Instead, I would suggest using source routing which doesn't
>    require the management of routing tables (a headache ebXML doesn't need)
>    and is probably adequate for what ebXML requires.  All source routing
>    demands is that the party sending the message know which intermediaries
>    it will pass through (e.g., the Yahoo portal)  on its way to destination
>    party.  Also, if the MS headers are extended to support it, source 
> routing
>    can be handled by the MSH in the intermediary without need of a routing
>    process.  Also, it should be possible to set up the extended headers such
>    that it is not necessary to change the size of the headers as the message
>    proceeds along its route which means that it will not be necessary to
>    recalculate message lengths.
>
>    Attached is a contribution from back in August which lays out the basics
>    of this approach.  It wasn't discussed in August as routing was deferred
>    to phase II.  The individual Hop headers can be modified to add time-
>    stamps, etc. needed for reliable messaging.  The information for each of
>    the headers could, of course, come from the CPA.

Source routing could be used, with the appropriate structures in the 
Routing Header, of course. But I heard some strong voices against this, and 
a push to making it possible for hubs to dynamically choose routes. 
Probably we should take a step back for a moment and make sure we all agree 
on the actual requirement...

>  Comments?
>
><mount soap-box>
>A general comment in closing: As is done in the IETF with internet protocols,
>I believe we have be very careful about observing the separation of functions
>in different layers or extensibility will become very difficult.  The
>discussion of the "test" attribute in todays ConCall is an example of
>confusing the functions from various layers -- if it's for the application,
>it should be in the payload (though we may have to define a separate
>XML application header body part to carry these things if the application
>data has no facility to do so itself).  Each layer must define its own
>functionality and data structure and not bury them in a lower layer or,
>possibly even worse, in an upper layer -- that kills extensibility.
></mount soap-box>

Agree!


>Best regards,
>Henry
>----------------------------------------

Jim

---------------------------------------------------------------
Jim Hughes                            Tel:   (408) 456-7859
Director, Industry Relations          Fax:   (408) 456-7960
Fujitsu Software Corporation          Cell:  (408) 420-7768
3055 Orchard Dr, San Jose, CA 95134   email: jfh@fs.fujitsu.com