Gopalan Suresh Raj
Web Cornucopia
Gopalan's Profile
Archives
« November 2009
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
     
       
Today
Click me to subscribe Download Open ESB
Syndication
Search

Table of Contents
Tags
bpel choreography ejb esb http integration javacaps javaee javaone jax-ws jbi management openesb orchestration process-oriented rest sca service-oriented soa soap wsdl xml xsd
Links
 
Referrers

Today's Page Hits: 194

Map of Visitors
Locations of visitors to this page
Caveat Emptor
This is my personal weblog. The contents of this Weblog represent my personal opinion which may differ from the official views of my employer, Sun Microsystems, Inc. or any past employers. I do not speak for my employer or any past employers.
View Gopalan Suresh Raj's profile on LinkedIn
« JBI/SOA Tips: Use... | Main | JBI/SOA Tips: Favor... »
Friday May 25, 2007
May
25
JBI/SOA Tips: The Wire Always Goes Forward never Back

If something goes wrong in a long-running transaction, you need to able to re-synchronize. The simplest way to re-synchronize is to do whatever you have to do and start over again. In some cases it may be some smaller fall-back in which case you can define the message to fall back to some intermediate restart point that you agree on in the collaboration design. However you look at it, it can get complicated. These collaborations do not happen in an atomic transaction, since these are transactions whose life cycle spans multiple partners and happens over a time of hours, or days, or weeks, or months. For example, in booking a reservation for travel you have your travel agent and your business process for booking a flight, a car, and a hotel. What happens when you get the flight, the car, and no hotel? Either you can choose to live with it and solve the hotel problem externally, or you could cancel the whole thing and try again with some other combination.

Certain run times or frameworks provide a previous snap-shot in time to figure out how to incrementally re-work the problem. This is more confusing than it is helpful. The very fact that you are looking at a state of the business process that does not represent the current state it is in, is more confusing than it is helpful. By giving you a view back in time where you think you are in a consistent state to make a decision, you have to understand where you currently are because you are somewhere else in time. How do you relate the previous state in time with where you currently are? So, do not rely on some generic  automated runtime or framework to solve your business problem for you. It is better for you to handle this within your business logic.

Compensation for Business Processes

Compensation is an application level function that defines the semantics for resolving issues that come up with in-flight instances. It is better handled by providing application level ‘cancellation’ functions. Think of the Collaboration as an entity that relentlessly pushes forward - it may change but it never ‘goes back’ to a previous state. If things get hopelessly stuck, then cancel and take whatever business hit cancellation costs (such as canceling a nonrefundable flight reservation).

Like this write-up? Subscribe to receive more like it.


 

Posted at 04:26AM May 25, 2007 by Suresh Gopalan in A Tip a Day  |  Listen to this article Listen to this entry  |  Comments added Comments[0]

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed

Disclaimer: The contents of this Weblog represent my personal opinion which may differ from the official views of my employer, Sun Microsystems, Inc. or any past employers.



View blog top tags

Enter your email address:

Delivered by FeedBurner

[Valid RSS]