ebcore — archive

[Pim van der Eijk]

A reminder that our bi-weekly CPPA SC is today. Here are some additional comments, following up from my email of September 3rd. http://www.oasis-open.org/apps/group_public/email/ebcore/200 909/msg00005.html I continue the numbering from that email. 6) WS-A EPR and synchronous business responses (Follow up on (5) in earlier email, replacing the @usesTransportBackChannel attribute by anonymous EPR). In CPA 2.0 and the draft 3.0, synchronous business responses are modelled using nesting. In the CollaborationInfo structure of the initiator, there is a CanSend element (or ActionBinding equivalent) that can have an CanSend. Similarly, the responder has a CanReceive with a nested CanSend. In a CPP, multiple DeliveryChannels can be used to express alternatives. However, if a partner supports synchronous and asynchronous responses, this can not be expressed as separate DeliveryChannel options, that can be selected by CPP intersection. You have to have multiple CanSends (resp. CanReceive etc.), one with an embedded CanReceive, and another without one. An simple alternative way to express synchronous responses is to adopt WS-Addressing and the anonymous EPR. Then we can describe the "response" message in the CPP as having two alternative channels: one with a proper URL (that can be HTTP posted to asynchronously) and another with an http://www.w3.org/2005/08/addressing/anonymous EPR. To accomodate this, we should change DeliveryChannelType to have either a transportId reference or reference to an EPR, as a transport reference is not needed. (In the approach with synchronous replies as nesting, there still is a required reference from the embedded action binding, though it is not used). We need the EPR change and optional transport anyway for multihop: 7) Multiple channels With multihop, some agreement parameters are end-to-end (sender and ultimate recipient), and others are between endpoints and edge intermediary (see section 2.8.2 and 2.8.3 in the Part 2 draft). The partner agreement is only about the end-to-end agreement. We could extend the CPP to extend each delivery channel option from a single channel reference to multiple Where each channel is tagged with a role: