OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-cppa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Notes on January 13 2006 Teleconference


January 13, 2006 OASIS ebXML Teleconference Notes

 

Attendance

 

Sacha Schlegel

Pim van der Eijk

Dale Moberg

 

Excused

Monica Martin (on plane)

 

Absent

Pete Wenzel

 

 

Agenda is at http://lists.oasis-open.org/archives/ebxml-cppa/200601/msg00004.html.

 

Because Pim was present we reviewed his comments on Sacha’s proposal. So we mainly dealt with agenda item one. Other agenda items needs Monica and/or Pete.

 

For background here is Sacha’s option 1 and his preferred approach for allowing finer grained specification of the channel for delivery of mshSignals, when syncReplyMode implies an independent return of mshSignals.

 

"mshSignalsOnly" è returned on same connection

"signalsOnly"   è returned on same connection

"signalsAndResponse"  è returned on same connection

 

"responseOnly" è independent msh signal return

"none" è independent msh signal return

 

 

Adding an optional element to the ThisPartyActionBinding called something along the line: "AsyncDeliveryChannel". The following rule could be added:

 

o If the element is not present, the defaultMSHChannel will be used.

o If the element is present but the syncReplyMode of the delivery channel referenced in "ChannelId" indicates synchronous transport the element will be neglected.

o If the element is present, and syncReplyMode indicates asynchronous transport and there is an OverrideMSHChannelId, the new element "AsyncDeliveryChannel" has precedence.

 

Pim’s Comments and TC discussion points:

 

[1] Perhaps the element should be called "SignalChannelId" instead of "AsyncDeliveryChannel", to indicate it would only be used for signals, not for business documents. 

 

Discussion revealed that clarification is probably needed that Signals in CPPs and CPAs need to have their own Channels specified when they are not handled by the syncReplyMode information. Name of new element to handle per-action declaration of mshSignal channel is still open for discussion.

 

As you say, its absence would mean that, if the syncReplyMode of the business channel (see note [2] below) is "none" or "responseOnly", the Default Msh Channel would be used for MSH signals (see note [3] below).

 

I'm not sure what channel would be used for standalone ebBP signals (see note [4] below).

 

Standalone signals get their own description as documents exchanged, so have their own channels defined. Apparently the text about these matters needs to be made clearer. Textual review will be undertaken and a report on options for clarification will be sent to the list.

 

[2] Along that line, the "ChannelId" could be renamed to "BusinessChannelId"? Perhaps more clear, although it would break backward compatibility with existing CPAs.

 

We could do this by using our normal substitution group trick that is being used to preserve 2.0 elements while introducing new ones. Sacha expressed reservations that this was really needed.

 

[3] There currently is a  "defaultMshChannelId", shouldn't there be a "defaultBusinessChannelId" too?

 

Just a thought.  It would make editing CPAs a bit more user-friendly.

 

Dale suggested that we consider this as a 3.0 item. This appears to be acceptable to all.

 

[4] I note there is a "defaultMshChannelId".  What is the default channel for standalone ebBP signals (as different from ebMS signals), which would be used with a value of "none" or "responseOnly"? 

 

Again, we need to be more explicit about the need for Signals having actionbindings…

 

Perhaps the "defaultMshChannelId" should be renamed to "defaultSignalChannelId" and also used to cover ebBP signals. Or, you could define a separate default channel for them. 

 

Dale suggested that we consider this as a 3.0 item. This appeared to be acceptable to all.

 

[5] Would there ever be a need to send asynchronous Msh Signals using a different channel from ebBP signals?

 

Allowable now.

 

If yes, there could be a separate "MshSignalId" and "BpSignalId" element in a Party Action Binding. Defaulted as per [4].

 

We can continue to consider this in the next January meeting.  It would permit more succinct CPP and CPAs. Continuing discussion of this option for 2.1version  action.

 

ebXML CPPA Teleconference Notes January 13 2006.doc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]