RE: Proposed Revisions to MS ver 0.8

[Rik Drummond <rvd2@worldnet.att.net>]

-----Original Message-----
From: Henry Lowe [mailto:hlowe@omg.org]
Sent: Thursday, November 16, 2000 1:03 PM
To: Transport Work Group
Subject: Re: Proposed Revisions to MS ver 0.8


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

>> agree

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.

>> i don't think it is necessary either, but it is a clear way to look at
the mhs functionality. it helped in the meeting when  john showed that way
on the board

   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.

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>

Best regards,
Henry
----------------------------------------
At 11:02 AM 11/14/2000 -0800, Jim Hughes wrote:
>Attached is a partially complete proposal for modifying Message Service
>Spec v0.8, in PDF format (if you can't read it or need the Word version,
>just contact me). David Burdett is now drafting changes for the parts he
>agreed to update in our Tokyo meetings. If we have time this Thursday, we
>could discuss the Simple Routing and Window topics shown in the attached
>version, so please have a look at it before Thursday's teleconference.
>
>Jim
>