Re: Proposed Revisions to MS ver 0.8

[Henry Lowe <hlowe@omg.org>]

Jim,

One minor comment on what you've written:
If this is supposed to be simple routing, I would suggest we 
stay away from dynamic routing mentioned below (it's not quite 
simple :-).

Sorry I wasn't in on this discussion last week, but the TP 
stuff was interesting, too.

Best regards,
Henry
-----------------------------------------------
At 11:21 AM 11/16/2000 -0800, Jim Hughes wrote:
>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
>