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