[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Issue - 170 - How to handle faultcode, faultstring,and faultactor
I agree that an implementer's note pointing out the issue would be appropriate. This is a problem a lot of implementers will run into and therefore justifies a note. If you would like to propose a new issue to include such a note I at least would see it as a bug fix. Thanks, Yaron Yuzo Fujishima wrote: > Yaron, > > I have been aware of the fact that facultcode and so on are not > defined by WSDL, and hence hard to handle in the current BPEL specification. > > My position, as stated in the original message, is as follows: > >> >> Even though those three elements don't appear in a WSDL definition, > >> >> they (especially the faultcode) convey information that is too > >> >> important just to ignore. > > I agree with you that the issue is currently out of scope for BPEL. > The question is, as I see it, "Is it OK to keep the issue out of scope?" > > In my opinion, both "yes" and "no" can be justifiable. > (I've listed the two alternatives in the original message.) > > If we choose "yes", then adding a note to clarify/explain > would be useful in helping readers correctly understand the > specification. > > If we choose "no", then we would need the rationale of expanding > the scope together with the concrete solution. > > Yuzo Fujishima > NEC Corporation > > > Yaron Y. Goland wrote: > > First, faultcode, faultstring and faultactor are all defined by SOAP, > > not WSDL. Since BPEL restricts itself to dealing with WSDL the value of > > these elements is outside the scope of BPEL. > > > > Second, the only reason there is an issue here is because the WSDL 1.1 > > specifications definition of a SOAP fault binding only provides for > > binding to the SOAP fault details element and not the fault* elements. > > However BPEL explicitly limits itself to WSDL portTypes and does not > > address bindings. Therefore this issue is again out of scope for BPEL. > > > > To paraphrase Satish, we aren't in the business of fixing WSDL. I would > > that we were but it's clear from previous votes that we aren't. > > > > Yaron > > > > > > > > Yuzo Fujishima wrote: > > > >> Yaron, > >> > >> Correct me if I am wrong. > >> > >> A fault message type is defined via WSDL definitions/message. > >> The problem is that what is defined there is the type of the > >> content of the <detail> element, not the whole SOAP fault message. > >> Because a BPEL message variable is defined via WSDL definitions/message, > >> it can only contain the content of a <detail> element, not faultcode or > >> the likes. > >> > >> Below is an example quoted and editied from > >> http://www-106.ibm.com/developerworks/xml/library/ws-tip-jaxrpc.html > >> > >> ---- WSDL ---- > >> > >> <definitions ...> > >> <types> > >> <schema xmlns="http://www.w3.org/2001/XMLSchema";> > >> <element name="InsufficientFundFault"> > >> <complexType> > >> <sequence> > >> <element name="balance" type="xsd:int"/> > >> <element name="requestedFund" type="xsd:int"/> > >> </sequence> > >> </complexType> > >> </element> > >> </schema> > >> </types> > >> ... > >> <message name="InsufficientFundFaultMessage"> > >> <part name="fault" element="tns:InsufficientFundFault"/> > >> </message> > >> > >> <portType name="Bank"> > >> <operation name="withdraw"> > >> <input message="tns:withdrawRequest"/> > >> <output message="tns:empty"/> > >> <fault name="fault" message="tns:InsufficientFundFaultMessage"/> > >> </operation> > >> </portType> > >> ... > >> </definitions> > >> > >> ---- SOAP Message ---- > >> > >> <soapenv:Envelope > >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> > >> <soapenv:Body> > >> <soapenv:Fault> > >> <faultcode >...</faultcode> > >> <faultstring>...</faultstring> > >> <detail> > >> <InsufficientFundFault xmlns="http://example";> > >> <balance>1000</balance> > >> <requestedFund>2000</requestedFund> > >> </InsufficientFundFault> > >> </detail> > >> </soapenv:Fault> > >> </soapenv:Body> > >> </soapenv:Envelope> > >> > >> Yuzo Fujishima > >> NEC Corporation > >> > >> > >> Yaron Y. Goland wrote: > >> > These three values are all available as elements inside of the Fault > >> > Message as defined by the SOAP 1.1 standard. Why would BPEL need to > >> have > >> > any direct support for them beyond the support we provide for > >> > setting/getting any XML value in a message? > >> > > >> > Yaron > >> > > >> > ws-bpel issues list editor wrote: > >> > > >> >> This issue has been added to the wsbpel issue list with a status of > >> >> "received". The status will be changed to "open" if the TC accepts it > >> >> as identifying a bug in the spec or decides it should be accepted > >> >> specially. Otherwise it will be closed without further consideration > >> >> (but will be marked as "Revisitable") > >> >> > >> >> The issues list is posted as a Technical Committee document to the > >> >> OASIS WSBPEL TC pages > >> >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a regular > >> >> basis. The current edition, as a TC document, is the most recent > >> >> version of the document entitled ** in the "Issues" folder of the > >> >> WSBPEL TC document list > >> >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - > >> >> the next posting as a TC document will include this issue. The list > >> >> editor's working copy, which will normally include an issue when > >> it is > >> >> announced, is available at this constant URL > >> >> <http://www.choreology.com/external/WS_BPEL_issues_list.html>. > >> >> > >> >> > >> >> Issue - 170 - How to handle faultcode, faultstring, and > >> faultactor > >> >> > >> >> *Status:* received > >> >> *Date added:* 18 Oct 2004 > >> >> *Categories:* Syntax & semantics <#category_syntax_&_semantics> > >> >> *Date submitted:* 15 October 2004 > >> >> *Submitter:* Yuzo Fujishima <mailto:fujishima@bc.jp.nec.com> > >> >> *Champion:* Yuzo Fujishima <fujishima@bc.jp.nec.com> > >> >> *Document:* WSBPEL Working Draft, September 8, 2004 > >> >> *Description:* In the current specification, there is no way to > >> set or > >> >> get faultcode, faultstring, and faultactor in sending, receiving, > >> >> throwing, or catching a fault. > >> >> > >> >> Even though those three elements don't appear in a WSDL definition, > >> >> they (especially the faultcode) convey information that is too > >> >> important just to ignore. > >> >> *Submitter's proposal:* > >> >> > >> >> I think we have to do either of the following: > >> >> > >> >> 1. Do not support faultcode, faultstring, and faultactor. Add a > >> >> note to the > >> >> specification telling that those are not supported. Also add > >> the > >> >> rationale > >> >> and possibly recommended values of them to use by > >> implementation in > >> >> sending fault. > >> >> 2. Support faultcode, faultstring, and faultactor. > >> >> One way to support faultcode, faultstring and faultactor is as > >> follows: > >> >> > >> >> Add optional faultCodeVariable, faultStringVariable, > >> >> faultActorVariable attributes to <catch>, <throw>, and <reply>. For a > >> >> <catch>, the attributes specify the names of the variables to set the > >> >> values to, while for the latter two, the variables to get the values > >> >> from. > >> >> > >> >> The default values (not the variable names) are "soap:Server", "", "" > >> >> for faultcode, faultstring, faultactor, respectively. > >> >> *Changes:* 18 Oct 2004 - new issue > >> >> > >> >> > >> > -------------------------------------------------------------------------------- > >> > >> >> > >> >> > >> >> To comment on this issue (including whether it should be accepted), > >> >> please follow-up to this announcement on the > >> >> wsbpel@lists.oasis-open.org list (replying to this message should > >> >> automatically send your message to that list), or ensure the subject > >> >> line as you send it *starts* "Issue - 170 - [anything]" or is a reply > >> >> to such a message. If you want to formally propose a resolution to an > >> >> open issue, please start the subject line "Issue - 170 - Proposed > >> >> resolution", without any Re: or similar. > >> >> > >> >> To add a new issue, see the issues procedures document (but the > >> >> address for new issue submission is the sender of this announcement). > >> >> > >> >> > >> >> Choreology Anti virus scan completed > >> >> > >> > > >> > To unsubscribe from this mailing list (and be removed from the > >> roster of > >> > the OASIS TC), go to > >> > > >> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > >> > >> > > >> > > >> > > >> > > >> > >> > >> To unsubscribe from this mailing list (and be removed from the roster > >> of the OASIS TC), go to > >> > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > >> > >> > > > > > > > To unsubscribe from this mailing list (and be removed from the roster of the > OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]