Re: Proposed Revisions to MS ver 0.8

[Henry Lowe <hlowe@omg.org>]

Marty,

Glad to see you agree.  One extra bit of info I'd like to add 
about application headers in a separate MIME part of the payload:
for pragmatic reasons, this might be a reasonable idea as many 
of the documents we are carrying may not have headers for the 
application built in, e.g., legacy documents such as EDI messages 
or pre-ebXML documents.  As long as these application headers 
are in the payload (and TRP would not define their contents 
except to say that they should/must(?) be in XML syntx) they 
probably don't violate strict layering.

Re the philosophy: and I thought I was an "agnostic".  Guess 
I was wrong and am a true believer! ;-)

Best regards,
Henry
----------------------------
At 03:16 PM 11/16/2000 -0500, Martin W Sachs/Watson/IBM wrote:
>
>I see I am missing some good stuff by being too busy with TP :-)
>
>I would like to echo Henry's comments.  I can think of no good reason why
>the MS should have to special-case workflow or any other type of
>application process.  The process-specific routing information should be in
>process-specific headers which, ideally, should simply be part of the
>application payload from the messaging-service's viewpoint.  As I pointed
>out in an earlier posting, it might be necessary to allow the application
>headers to be visible in the message service header structure in order to
>enable application service middleware to find them easily, but even in that
>case, the messaging service layer should be able to ignore them.
>
><Philosophy>
>I think that part of the confusion about layers stems from the mind-set
>that the messaging service is agnostic to layers above and below.  Here I
>mean "agnostic" in the English Language Dictionary sense of "skeptical of
>the existence of God" or in our case, skeptical of the existence of layers
>above and below.  If you don't believe that those layers exist, you try to
>cram everything into your layer.  By allowing your self to believe that
>those layers are really there, you can then think in terms of what to
>assume that they do and therefore you don't have to do. Defining the upper
>and lower interfaces to the Messaging Service will help give the focus to
>understanding what is above and what is below.
></Philosophy>
>
>Regards,
>Marty
>
>****************************************************************************
>*********
>
>Martin W. Sachs
>IBM T. J. Watson Research Center
>P. O. B. 704
>Yorktown Hts, NY 10598
>914-784-7287;  IBM tie line 863-7287
>Notes address:  Martin W Sachs/Watson/IBM
>Internet address:  mwsachs @ us.ibm.com
>****************************************************************************
>*********
>
>
>
>Henry Lowe <hlowe@omg.org> on 11/16/2000 02:02:51 PM
>
>To:   Transport Work Group <ebxml-transport@lists.ebxml.org>
>cc:
>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).
>
>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
>>
>
>
>
>
>