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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

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

Subject: RE: [ebxml-msg] CPPA 2.1 Transport changes for potential ebMS 3.0 pull support

<JD> inline:


From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com]
Sent: Friday, September 23, 2005 7:45 AM
To: Jacques Durand; ebxml-msg@lists.oasis-open.org
Cc: ebxml-cppa@lists.oasis-open.org
Subject: RE: [ebxml-msg] CPPA 2.1 Transport changes for potential ebMS 3.0 pull support



1.       About the "mep hint" :


-          we might use a lower-level concept closer to transport than ebMS MEPs that could do the same hint job. It might just look like a renaming issue, but I'd avoid  lowering ebMS concepts such as MEPs down to the transport level: it seems that ebMS mep info would be more appropriately associated with higher level CPA layers like Delivery channel - or maybe doc exchange info ?

-          At transport level, that could work like this: it is sufficient to know which of the TransportSender or TransportReceiver can initiate an exchange, in order to determine what ebMS MEPs can be run over this transport. An "initiator" attribute (true/false) of the TransportProtocol element of a TransportReceiver might just do that. If "true", it would tell that the transport can run ebMS One-way Pull, as well as more complex MEPs that include Pulling. But that depends indeed on how this transport is used (by which Delivery Channel), which does not have to be known or assumed, when defining  TransportProtocol.


Dale>> I think that there are several levels at which people discuss MEPs-the SOAP MEPs are not the same as
WSDL MEPs, for example. Nevertheless, I now see that the name may be more of a layering violation than useful hint.

I will see what the CPPA TC has to say about the matter today and report back to Messaging.


<JD> In fact, it probably boils down to just specifying which side of the Transport can execute the "method" whatever it is, since the method is specified. Then from there, the MSH knows what [ebMS] MEP (or part of it) it can run on this transport, because the MSH controls the mapping of its MEPs to SOAP MEPs, and also the binding of SOAP MEPs to transport specifics. (So I don't think we even need to add SOAP-level MEP info in Transport, though we could - but that would kind of repeat - possibly conflict with - some SOAP MEP binding info that should better remain specified elsewhere.)


-           (note: for sake of generalization, shouldn't the "method" be an unbounded child element instead of just an attribute? If the case, the "initiator" attribute could be associated to it, meaning that the party can actually generate the method, not just receive it.)


Well, the idea was that if you wished to specify the "method" you would have distinct Transport elements with different methods, even if they happened to have the same Endpoint info, for example. We probably also want to generalize or offer a choice for Endpoint, given that a Receiver Endpoint in the pull pattern only serves to identify and is not to be used for contact...


<JD> I see. So a Transport is a combination protocol/operation. In that case indeed it calls for a single method.



2.       Endpoint in TransportReceiver: this one should probably have minOccurs="0" like for Sender, because the case where some Receiver has no endpoint address, now makes sense with Pulling.


Dale>> OK, but where will the URI identifier go? I was reusing (and overloading) the Endpoint element for the identification information...


<JD> That is interesting - we came to a similar conclusion that we need some kind of identification for PullRequest, even in that case, and even when authentication / authorization is not required - just for being able to assign the Pull to the right queue (that we prefer to abstract as a "pipe") . Assuming that indeed the Receiver may not have an endpoint associated (no more than a Sender) we still need some identifier that is at least unique within the context of a Sender. Could  tp:transported hold such an Id? Else I believe we need another element, orthogonal to the endpoint values (yet such an ID could by default take the value of the  TransportReceiver endpoint URI when present.)


Thanks for the comments Jacques!






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