Home arrow Web Services arrow Page 2 - Fault Handling with Web Services
WEB SERVICES

Fault Handling with Web Services


Last week, we looked at the assign and other basic activities, and studied flow. This week, we'll be examining more sturctured activities, and fault handling. This article, the fifth in a six-part series, is excerpted from chapter 12 of Building Web Services with Java: Making sense of XML, SOAP, WSDL, and UDDI, written by Steve Graham et al. (Sams; ISBN: 0672326418).

Author Info:
By: Sams Publishing
Rating: 4 stars4 stars4 stars4 stars4 stars / 20
August 31, 2006
TABLE OF CONTENTS:
  1. · Fault Handling with Web Services
  2. · Fault Handling
  3. · Fault Handler Example
  4. · Event Handling

print this article
SEARCH DEVARTICLES

Fault Handling with Web Services - Fault Handling
(Page 2 of 4 )

BPEL introduces fault handlers in order to let you deal with exceptional situations, such as the following:

  • A fault recognized as the result of a Web service invocation

  • A fault thrown explicitly by the process logic

  • A fault caused by a problem encountered by the runtime infrastructure

Let's take a closer look at these three potential sources of faults in BPEL.

Fault Situations

The outcome of a Web service invocation is either regular output or a fault, as specified by the WSDL operation. The example shows the definition of a WSDL operation with two faults. WSDL faults have a name and a reference to a message definition, as shown in the following snippet:

<wsdl:operation name="doSubmission"> 
<wsdl:input message="pos:poSubmissionRequest"/>
<wsdl:output message="pos:poSubmissionResponse"/>
<wsdl:fault name="invalidPO"
message="pos:poSubmissionFaultInvalidPO"/> <wsdl:fault name="outOfStock"
message="pos:poSubmissionFaultOutOfStock"/> </wsdl:operation>

BPEL also lets you raise faults explicitly by means of the throw activity. The throw activity declares a qualified name of a fault and optionally provides a variable to associate data with the fault. The following BPEL snippet shows a throw activity. It's used to end the execution of the normal path in the process because the validation of the received purchase order has failed:

<throw faultName="pos:invalidPO"/>

Finally, the BPEL runtime infrastructure recognizes a number of predefined exceptional situations within a running process instance. If such a situation occurs, a BPEL standard fault is raised. Examples for such standard faults are

  • mismatchedAssignmentFailure—Incompatible types in an assign activity

  • forcedTermination—Fault in an enclosing scope

  • correlationViolation—Message contents in receive, reply, invoke, or pick/onMessage don't match correlation data

  • uninitializedVariable—Attempt to access an uninitialized part of a message variable

  • invalidReply—Attempt to execute a reply for which no corresponding receive activity has been processed

Fault Handlers

In BPEL, fault handlers are the mechanism to explicitly catch these faults and respond to them in appropriate business logic. Fault handlers are associated with a scope activity or with the overall process.

When a fault is recognized, the scope or process first stops all its nested activities. Structured activities are terminated immediately. Some types of basic activities are also interrupted, including wait, receive, reply, and invoke. Other activities are considered short-lived and aren't interrupted.

A fault handler contains an activity that runs in case the corresponding fault occurs. For example, the fault handler may contain a reply activity that notifies a partner that normal processing of the logic can't be completed.

Syntactically, a fault handler is a catch or catchAll element. The catch element lets you specify the qualified name of a fault, a fault variable, or both. The fault variable can be omitted in cases where faults don't have additional data associated with them. The catchAll element doesn't have attributes.

Following is an example of a fault handler declaration for the overall process:

<process ...>
...
<faultHandlers>
<catch faultName="pos:invalidPO">
<reply partnerLink="buyer" 
portType="pos:purchaseOrderPortType"
operation="submitPurchaseOrder" 
faultName="pos:invalidPO" 
variable="purchaseOrderFaultInvalidPO"/>
</catch>
<catch faultName="pos:outOfStock">
<reply partnerLink="buyer" 
portType="pos:poSubmissionPortType" 
operation="poSubmission" 
faultName="pos:outOfStock" 
variable="poSubmissionFaultOutOfStock"/>
</catch>
</faultHandlers>
...
</process>

Fault handlers can be declared in the same way for scopes. They can also be declared for invoke activities, which is a shorthand notation for defining an enclosing scope with the fault handler.


blog comments powered by Disqus
WEB SERVICES ARTICLES

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials