Re: Proposed Revisions to MS ver 0.8

[Henry Lowe <hlowe@omg.org>]

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

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.

   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
>

RoutingPaperV1.doc