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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: [no subject]


Not sure we can define exactly what it will be, until the spec is close
to adoption.  Follow convention used by WS-Context; something like
http://docs.oasis-open.org/wscaf/2005/02/wscf
Moved by Mark, seconded by Simeon; approved by unanimous consent.

  How should faults be handled in WSDL
    http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=211

All messages, including error indications, are at application level.
Mark believes some of them should be SOAP faults.
Simeon: How will the WSDL change?
Mark: That's a separate question, which does need to be addressed.
John: WS-Addressing fault mechanism may change, because it violates the
  SOAP spec.
Peter: Any protocol layer needs to handle its own faults, but may use
  a lower layer to carry them.  We have 2 levels: WSDL and SOAP.
  WS-Addressing has a FaultTo address, to which you can send a SOAP
  one-way, which is a Fault.
Eric: Sounds like support for using the SOAP Fault format.
Mark: Could consider SOAP Faults as "system exceptions" (CORBA
  terminology), while the WS-CF ones may be application exceptions.
Mark volunteers to write up a proposal.

  Should registration for multiple protocols be atomic?
    http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=212

Mark: The problem is that a registration service may successfully
  register a participant using one or more protocols, and fault another,
  but the participant would remain registered.
Eric: We could report success for some, and failure for others.  It would
  be up to the registrant to remove himself.
Tony favors atomic registration.
Doug: Are there other operations that could have partial success and
  partial failre, for which we would set a precedent?
Mark: No, only this and removeParticipant fall into this category.
(Discussion about dynamic discovery and application of policy.)
Doug: One method of discovery is to try everything, and see what "sticks".
Mark proposes that addParticipant and removeParticipant be atomic,
  with respect to protocol URIs that are specified.  Tony seconds.
Tony: Will you still report which ones you do support?
Mark: Yes, agree.  This should happen only if participand and registration
  service disagree on their policy.
Friendly amendment from Tony: The endpoint that is performing the
  registration will return a list of URIs that it supports.
No objections; motion is approved.

  List activity group participants in the context?
    http://services.arjuna.com/wscaf-issues/show_bug.cgi?id=213

Tony: It's reasonable to ask the registration point who is registered.
  Should be possible to refuse to say, however.
Eric: Which spec does it belong in?  Sounds like a larger issue than we
  can deal with on this call.  Dicuss at F2F.



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