[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]
Powered by eList eXpress LLC