[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
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. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]