Ronald van Luttikhuizen - Effective fault handling in SOA Suite and OSB 11g
1. Effective Fault Handling in
Oracle SOA Suite 11g
Ronald van Luttikhuizen [Vennster]
Guido Schmutz [Trivadis]
1-Oct-2012 | Oracle OpenWorld & JavaOne
1|x
2. Guido Schmutz
• Working for Trivadis for more than 15 years
• Oracle ACE Director for Fusion Middleware and SOA
• Co-Author of different books
• Consultant, Trainer, Software Architect for Java, Oracle, SOA
and EDA
• Member of Trivadis Architecture Board
• Technology Manager @ Trivadis
• More than 20 years of software development
experience
• Contact: guido.schmutz@trivadis.com
• Blog: http://guidoschmutz.wordpress.com
• Twitter: gschmutz
2|x
3. Ronald van Luttikhuizen
• Managing Partner at Vennster
• Oracle ACE Director for Fusion Middleware and SOA
• Author of different articles, co-author Oracle SOA Book 11g book
• Upcoming book SOA Made Simple
• Architect, consultant, trainer for Oracle, SOA, EDA, Java
• More than 10 years of software development and architecture
experience
• Contact: ronald.van.luttikhuizen@vennster.nl
• Blog: blog.vennster.nl
• Twitter: rluttikhuizen
3|x
4. Agenda
1. What is Fault Handling ?
2. Fault Handling in SOA vs. traditional systems
3. Scenario and Patterns
4. Implementation of Scenario
5. Summary and Best Practices
4|x
5. Fault Handling
● The goal of every programmer should be to write unbreakable
software
● Extent of achievement depends on how good expected and
unexpected exception conditions are handled and managed
● Object-oriented languages such as C++ and Java provide an efficient
way for handling exceptions using constructs such as try, catch, and
finally
● With a SOA, most of what is available at language level is still valid
and usable
● SOA raises different challenges once starting orchestrating services
and creating composite applications
● Prevention vs. handling
5|x
6. What is a Fault ?
● Something happened outside normal operational activity or
“happy flow”
• Technical error
• Programming error
• Faulty operation by user
• Exceptional business behavior
● Prevention and handling
6|x
7. Two Types of Faults
Business faults
● Faults that service clients can expect and recover from
● Failure to meet a particular business requirement
● Often: expected, business value, contractual and recoverable
Technical faults
● Faults that service clients do not expect and cannot (easily) recover from
● Results of unexpected errors during runtime, e.g. null pointer errors,
resources not available, and so on
● Often: unexpected, technical, implementation and non-recoverable
7|x
9. Business Fault (II)
<soap:Envelope>
<soap:Header/>
<soap:Body>
<soap:Fault>
3. Actual service response
<faultcode>CST-1234</faultcode>
<faultstring>Customer not found</faultstring>
<detail>
<CustomerNotFoundFault>
<CustName>John Doe</CustName>
<City>Long Beach</City>
</CustomerNotFoundFault>
</detail>
</soap:Fault>
</soap:Body>
</soap:Envelope>
9|x
10. Technical Fault
<wsdl:operation name="orderProduct”>
<wsdl:input message="order:OrderProductMessage"/>
<wsdl:output message="order:OrderProductResponseMessage"/>
<wsdl:fault message="order:ProductNotInStockFaultMessage"
1. Service contract
name="ProductNotInStockFault"/> including fault
<wsdl:fault message="order:CustomerNotFoundFaultMessage"
name="CustomerNotFoundFault"/>
</wsdl:operation>
2. Actual service response
<soap:Body>
<soap:Fault>
<faultcode>S:Server</faultcode>
<faultstring>Could not connect to URL 127.0.0.1 on port 8001</faultstring>
</soap:Fault>
</soap:Body>
10 | x
11. Agenda
1. What is Fault Handling ?
2. Fault Handling in SOA vs. traditional systems
3. Scenario and Patterns
4. Implementation of Scenario
5. Summary and Best Practices
11 | x
12. Fault Handling SOA vs. traditional systems
External BPM User Multiple service consumers
Interface Services part of larger unit
Heterogeneous & external components
Long running processes
ESB
Asynchronous
Timed events
Often enterprise-wide
Implemen- Implemen- Implemen-
tation tation tation Transactions
12 | x
13. Agenda
1. What is Fault Handling ?
2. Fault Handling in SOA vs. traditional systems
3. Scenario and Patterns
4. Implementation of Scenario
5. Summary and Best Practices
13 | x
14. Old System with
limited scalability
Short Network
interruptions No 7*24 avail. for
single instance of
credit card service
Response
sometimes get
Fault if product is lost
no longer available
Not always
available
14 | x
15. Patterns for Fault Tolerant Software
Compensation
Exception shielding
(Limit) retry
Share the load
Alternative
Exception handler
Heartbeat
Throttling
15 | x
16. Fault Recovery Strategies
● Inaction – Ignore the request
● Balk – Admit failure
● Guarded suspension – Suspend execution until conditions for correct
execution are established
● Provisional action – Pretend to perform the request, but do not
commit until success is granted
● Recovery – Perform an acceptable alternative
16 | x
17. Fault Recovery Strategies
● Rollback – Try to proceed, but on failure, undo the effects of a
failed action
● Retry – Repeatedly attempt a failed action after recovering from
failed attempts
● Appeal to higher authority – Ask someone to apply judgment and
steer the software to an acceptable resolution
● Resign – Minimize damage, write log information, then signal
definite and safe failure
17 | x
18. Agenda
1. What is Fault Handling ?
2. Fault Handling in SOA vs. traditional systems
3. Scenario and Patterns
4. Implementation of Scenario
5. Summary and Best Practices
18 | x
20. Product Management
Result Caching
Result Cache
Problem
● Not to overload the old, non-scalable product system with the new
demand
Solution
● Use Result Caching to cache the product information (read-only
operation)
● Use Service Throttling to limit the number of concurrent requests
20 | x
21. Product Management
Result Caching
Results are returned from cache rather than always invoking the
external service
● Product data is rather static, so ideal candidate for caching
Proxy Business 1 Product DB
Service Service
2 3
Result
Cache
OSB
21 | x
22. Product Management
Service Throttling
Restrict the number of messages on the message flow to a Business
Service
Message Buffer
Proxy Business Product
Service Service DB
OSB
● Set from Operational Settings on the OSB console
22 | x
23. Credit Card Booking
Retry Configuration
Retry
Problem
● Unstable network between us and the external services
Solution
● Use Retry mechanism of OSB to try multiple times
● No Fault Management necessary for service consumer if network
interruption is only for a short time
23 | x
24. Credit Card Booking
Retry Configuration
Configured on the business service in OSB
1
Proxy Business
after 2s Credit Card Service
Service Service 2
OSB
5x
24 | x
25. Credit Card Booking
Service Pooling
Service Pooling
Problem
● Credit Card Service does not guarantee 7*24 availability for one single
instance
Solution
● Use the multiple instances (endpoints) that the company provides and
use service pooling feature of OSB
● No Fault Management for the service consumer if at least one endpoint
is available
25 | x
26. Credit Card Booking
Service Pooling
Credit Card Service instance 1
Proxy Business
Credit Card Service instance 2
Service Service
OSB Credit Card Service instance 3
26 | x
27. Order Management
Transaction configuration
Transaction of OSB
Service Consumer
Transaction of OSB
Service Consumer
Problem
● Guarantee that the message will be delivered to the order management
system
Solution
● Make sure that queues are available, even if the Handle Order system is not
● Make sure that queuing run’s in the same transaction as the service
consumer
27 | x
29. Order Management (II)
Fault Message on Callback Contract
Fault Message on
Callback Contract
Problem
● Need to return a Product No Longer Available Business Fault over an
Asynchronous MEP
Solution
● Design a separate Fault Message and Operation on the Callback
contract (WSDL) and use that
29 | x
30. Order Management (II)
Fault Message on Callback
“Business Fault” modeled as another operation on the
Callback WSDL
30 | x
31. Order History
Fault Management Framework
Use Fault Policy Management
In Mediator to configure retry
Problem
● Order History System not available should have no impact on
Business Process
Solution
● Use Mediator with Fault Management Framework to configure retry
independent of availability of Order History Web Service
31 | x
33. Order Handling Process
Return errors as synchronous response
Problem
● Both Product Management and Credit Card Booking can
Fault Handling return Business Faults
Fault Handling Solution
Reply with Fault ● Handle errors and map them to errors returned to the
service consumer (i.e. the caller of the process)
33 | x
34. Order Handling Process
Return errors as synchronous response
Handle Business Faults in BPEL error handler and reply with an error
34 | x
35. Order Handling Process (II)
Handle missing callback with timeout
Problem
● Order Processing response message can get lost in the Order
Processing system, i.e. the callback message will never
arrive in the process
Solution
● Timeout on the Wait For Answer with a BPEL pick activity
Pick with timeout
with a timeout
● Undo the process by doing compensation
Compensate
● Use the BPEL compensate activity together with
compensation handler to undo the Booking of the Credit Card
35 | x
36. Order Handling Process (II)
Handle missing callback with timeout
Pick Activity for handling callback
message with timeout branch
c
36 | x
37. Order Handling Process (III)
Compensation Handling
Problem
● Order Processing callback message can be a Product No
Compensation Longer Available Business Fault
Handler
Solution
● Undo the process by doing compensation
Handle Business ● Use the BPEL compensate activity together with
Fault and Compensate
compensation handler to undo the Booking of the
Credit Card
37 | x
38. Order Handling Process (III)
Compensation Handling
Compensate activity invokes compensation
handling on the inner scope
• Can only be invoked from within a fault handler or
another compensation handler
38 | x
39. Order Handling Process (IV)
Non-idempotent operations
Problem
● Credit Card Booking is a non-idempotent operation
Solution
Non-Idempotent ● To avoid BPEL calling the Book Card operation again (not
really possible here), we have set the idempotent
Property on the partner link to FALSE
Idempotent
39 | x
40. Order Handling Process (V)
Generic Error Handler w. Fault Policy Framework
Problem
● Unexpected (technical) fault
Unexpected (technical) error ● Multiple processes that deal with unexpected faults in
their own way
Solution
● Use fault handler mechanism to enqueue on error queue
without adding process logic
● Create one process to listen to error queue and handle
faults
● Retrieve process information by using (composite) sensors
40 | x
42. Order Handling Process (V)
Generic Error Handler w. Fault Policy Framework
Explanation of generic fault handler
42 | x
43. Agenda
1. What is Fault Handling ?
2. Fault Handling in SOA vs. traditional systems
3. Scenario and Patterns
4. Implementation of Scenario
5. Summary and Best Practices
43 | x
44. Summary
Issue Solution Product
Overloading product management system ThrottlingResult cache OSB
Credit Card Service does not guarantee 7*24 uptime due to e.g. Muliple endpoints OSB
network problems Service pooling
Guarantee message delivery to order management system Availability of queues OSB (and SOA Suite for XA
Enqueue and dequeue in service consumer propagation to OSB)
transaction
Returning business fault over async MEP from order management Separate operation and fault message OSB and SOA Suite (callback
system contract between the two)
Order history service not available Retry in Mediator using fault policy framework SOA Suite
Business fault handling from service to process to consumer Catch faults in process and reply fault to OSB and SOA Suite (correct
consumer contracts)
Detect missing response message Timeout in pick activity SOA Suite
Handle product no longer available Compensation SOA Suite
Avoid calling credit card booking twice Set non-idempotent property SOA Suite
Processes needing to deal with unexpected technical faults. All Fault policy frameworks, error queue, generic SOA Suite
processes solving it in their own way using process logic. error handler, SOA Suite APIs & composite
sensors.
44 | x
45. Best Practices
● Differentiate between business and technical faults
● Design service contracts with faults in mind: formally describe business faults in
service contracts
● Don’t use exceptions as goto’s
● Design with criticality, likeliness to fail, and cost in mind
● Differentiate fault patterns in OSB and BPM/BPEL
• OSB: Retry, throttling, transaction boundaries
• BPM/BPEL: Compensation, business fault handling, generic fault handler, timeout
● Handle unexpected errors generically
● Make services autonomous
● Fault-handling on scope of services and in wider perspective
45 | x