[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] 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 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! Dale Cheers, Jacques |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]