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

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

 

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.

 

-           (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…

 

 

 

 

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…

 

Thanks for the comments Jacques!

Dale

 

Cheers,

Jacques