OASIS ebXML Collaboration Protocol Profile and Agreement TC
ebXML CPPA Technical Committee Teleconference
October 25, 2001
Dale requested volunteers to host teleconferences in November and December, noting that Cyclone's vendor had charged around $200 per call. Meanwhile, Brian offered to extend Commerce One's October sponsorship for the first week of November.
Dale raised the question of holding votes via the list. We'll pursue that matter at our next voting meeting.
Dale cautioned that in our current Specification, elements are all separately documented, so adding new elements has a relatively high "price tag" in terms of editorial effort. We're urged to keep that in mind.
Hima, with Dale, has submitted a JSR to the Java Community process for an API to support CPP/CPA processing. Dale suggested that members of our team consider whether they have time and interest to contribute to that effort if it goes forward - it's now in a preliminary stage.
Arvola reported that the MSG committee voted to accept the restructuring of their version 1.05 document, including separating out of various SOAP modules. David Burdett, David Fischer and Chris Ferris are confident they can meet the target date of Dec. 4 for submitting the MSG 1.1 specification to Karl Best. Their next F2F is targeted for mid-November - probably at East and West coast sites with video-conferencing between sites.
Brian reported that the BPSS committee had their first teleconference this week and will have the first cut of their issues list done on Friday, after which they should be ready for input from CPPA. He expects that CPPA and MSG issues may be integrated by the end of next week. Jamie pointed out that they have an explicit goal to come into alignment with the CPPA 1.1 spec. Brian noted that "Service and Action" hasn't come up yet in BPSS circles and is likely to generate some discussion.
We tabled discussion of PartyRef until next week, when Marty is expected to participate.
Dale urged everyone to read Arvola's proposal for the interpretation of different synchronous reply modes in the CPP/A.
Dale observed that the markup approach in Arvola's proposal ("multiplying elements") differed from his security proposal ("enumerated values for attributes") and they should try to decide on a common approach, but they're in agreement about semantics.
Dale commented that some messages from a responder may come back synchronously and others asynchronously - those will need an endpoint. Arvola said that the parts coming back asynchronously have an associated action that, together with the trading partner's role, can be used as the key to determine the endpoint. Hima asked if we could clarify information in the schema such that it corresponds to sender info and receiver info. He agreed to send a proposal to the list. Hima also commented that some transactions might involve multiple responses. Arvola responded that he's proposed more than one package with an action, e.g., a response or an exception.
Messaging Interlock Issues
We continued discussion from last week on Arvola's categorization of issues in the MSG team's database and his recommendations (see his Oct. 17 email on "[ebxml-cppa] Issues for discussions"). On Monday the MSG team discussed mostly issues listed under Sync Reply. For details, see Ian Jones' minutes for Oct. 22 on the MSG team page.
Arvola told us that MSG Issue 58 on "SyncReply should be in both header and Via" generated a lot of discussion. Sync reply information is already in the CPA, leading to the question: what if the header info disagrees with the CPA? That requires more discussion with our team. Arvola says that in 1.0, changes inconsistent with the CPA are not recommended, but if they occur, they're dependent on the implementation of the receiver. We discussed whether the CPA should model the ability to change message handling on a per message basis; Dale questioned whether per message changes are needed and felt it was beyond version 1.1. Brian thinks it's a good idea for messaging to be able to stand on its own, but it may be a case of over-engineering at this stage; for now people will get together and agree on the operation of the system on an end-to-end basis. Jamie argued against having SyncReply as message header functionality, noting that no one is currently implementing it. Dale also felt we should argue for eliminating it from the MSG spec. According to Arvola, there was no disagreement that the SyncReply flag in the Via element is needed for the next intermediary.
Arvola reported a fair amount of discussion on how MSH level signals like acks and delivery receipts are returned when using an HTTP/SOAP binding. He felt they were gravitating towards asking the CPPA team for a new synchronous response mode of "mshSignalsOnly" [as proposed by Arvola]. Although he didn't sense complete consensus, Ian's minutes state that the CPPA team will be so asked.
Arvola feels that QualityOfServiceInfo should also be available from the CPA, so it's debatable whether that's needed in the message header. Hima noted that the idempotency attribute of the ReliableMessaging element addresses duplicate detection. Dale called for opening a new version 1.1 issue to identify and properly name [markup and] values needed in the QOS area. Names need to be aligned with MSG.
Dale asked if it's now resolved that there will be two mechanisms for NRR, one through an MSH signal and another through a BP signal. Arvola said the question was not discussed yet. Reliable messaging will come up at the F2F and Dan Weinreb will draft a proposal regarding RM info in the header and the CPA. Jamie observed that the BPSS and CPPA teams must align on NRR, as must the BPSS and MSG teams. Brian agreed that the alignment issues must be added to the BPSS list.
Proposed Schema Changes from Arvola
Arvola reminded us that in v. 1.0, a ServiceBinding may [implicitly] have any number of actions that aren't overridden and thus use the default DeliveryChannel with the same packaging. That's a problem because the packaging has a set of simple parts, each with an associated name space, but it's not clear that all documents associated with different actions will use the same namespace. Dale agrees this need to be addressed for version 1.1. Arvola has introduced a repeating group called ActionBinding under ServiceBinding (see his proposal for more details). Dale noted that actions include business process signals as well as requests and responses. Arvola wants to support actions that use different delivery channels for sync and async cases. Dale questioned the idea that we should go to an enumeration of every action under a service, noting that Marty and Chris had previously wanted to avoid such a fine-grained approach. He'd like to keep the default packaging ID.
There will be another teleconference next week on November 1.