OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: MSH spec


Message text written by Christopher Ferris
>
I believe that the purpose of the ebXMLHeader tags should
be to enable the MSH and/or the BSI adaptor layer to 
correctly identify the message's context within a given
choreography. Of course, it would also need to use a
value in the Manifest which identified the type of message
in the Payload to complete the mapping.

<<<<<<<<<<<<<

David,

This works for TRP role #1 - shipping of transactions within
a BP.  

ie.  <payload><somedatahere process="buying"/></payload>

However, notice with Registry and other models, the payload
itself identifies the role explicitly because the payload contains
an <action> with <verbs>.

ie.  <payload><getRegisteredObject/></payload>

So there is potential conflict and redundancy here.  Frankly,
I prefer a generic header, and a decoupling - because that
way the Registry services are transport layer neutral - which
buys us better future proofing.   Two years from now we may
be wanting to support more than just TRP, and/or TRP itself
will have morphed.   Minimizing the coupling just looks to me
to be smart.   That way each layer can focus on doing its own
job, and it avoids the Catch22 of needing to know what to put
in the transport header to access the registry, but needing 
to access the registry to find out what that is in the first place,
or to register in the first place!

DW.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC