[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]