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