Re: Transaction in SOA

>
>   You say "do it" if something else fails I may tell you to take a
> compensating action to reverse what you did.
>
> There is a difference say at a restaurant between someone placing an
> order and cancelling it as compared to never placing it. If we take
> this in a systems view a 2pc is like them never placing it if it fails
> anywhere in the process. A compensating action would show that the
> order was placed and was then cancelled.
>
> Cheers,
>
> Greg
>
> On Wed, Aug 6, 2008 at 7:55 AM, Casey Charlton <casey@...<casey%40goinsane.co.uk>>
> wrote:
> > And I think the way I get it right in my head is that a transaction
> > effectively leaves all component parts in a flux state until committed or
> > rolled back.. When you are operating over a remote service, you ate
> trying
> > to leave a system not under your control in a flux state till you tell it
> to
> > commit... Which may or may not happen ... Which expressed that way is "a
> bad
> > idea"
> >
> > Casey
> > On 5 Aug 2008, at 23:04, "Greg Young" <gregoryyoung1@...<gregoryyoung1%40gmail.com>>
> wrote:
> >
> > To summarize what Jesse has said, I believe the pattern name he was
> > looking for was a [Compensating Action]
> >
> > Here is a great post that gives some of the alternatives ...
> > http://www.eaipatterns.com/ramblings/18_starbucks.html
> >
> > Cheers,
> >
> > Greg
> >
> > On Tue, Aug 5, 2008 at 10:19 PM, Jesse Ezell <jezell@...<jezell%40gmail.com>>
> wrote:
> >> The SOA way to handle this is with events. Events in SOA (commonly
> called
> >> "loosly coupled events") are handled via message queues.
> >>
> >> In your example, a message might first come in via the web site with an
> >> order placement. That order placement message will cause the order to be
> >> persisted. You then notify the customer that their order was placed (not
> >> that they were billed or the order has shipped) and place outgoing
> >> messages
> >> into a queue to be picked up by the other services. The message should
> be
> >> something like "OrderPlaced" (just like a normal event). The billing
> >> system
> >> will try to charge the card and if the card can't be charged might
> follow
> >> some workflow (automatic rejection, manual call to the customer, email
> to
> >> customer, etc.). When the billing is complete, the billing system will
> >> place
> >> a "OrderBilled" message in the queue. When the order is billed, the
> >> accouting system will receive a message to update the it's records with
> a
> >> record of the purchase. Meanwhile the fulfillment system will receive a
> >> notification and begin the process of shipping the order. If when the
> >> order
> >> gets to the fulfillment system you are somehow out of stock, you again
> >> follow a workflow to determine the course of action. Maybe the action is
> >> manually calling the customer to explain the situation and see if they
> >> would
> >> either like a refund or are willing to wait till you get the item back
> in
> >> stock.
> >>
> >> All of these processes are happening asynchronously, just like they do
> in
> >> the real world. When you write a check for a purchase, the merchant
> can't
> >> just roll back the transaction if the bank rejects the check, they have
> >> processes they follow to correct the situation and attempt to collect
> the
> >> money. If you order food at a restraunt and the waitress comes back and
> >> says
> >> they are out of what you ordered, she doesn't send you back in time as
> if
> >> nothing happened, she follows a set workflow to compensate for the
> error.
> >>
> >> The nice thing about building systems this way is that it ends up giving
> >> you
> >> a ton of flexibility and eventually will let you align your services
> with
> >> real business processes. It is a little more work to do it this way at
> >> first, but the end result is a much more flexible system and can save
> >> countless hours once the infrastructure is in place and the foundation
> is
> >> laid.
> >>
> >> On Tue, Aug 5, 2008 at 11:54 PM, Hendry Luk <hendrymail@...<hendrymail%40gmail.com>>
> wrote:
> >>>
> >>> What about a transaction that involves 5 different services (e.g. a
> >>> prepaid topup involves many services, from inventory, network-provider,
> >>> billing-engine, to accounting)? When one failed, everything else should
> >>> ideally fail.
> >>>
> >>> On Wed, Aug 6, 2008 at 4:21 PM, Jesse Ezell <jezell@...<jezell%40gmail.com>>
> wrote:
> >>>>
> >>>> If you really need them, WCF and MSDTC support WS-AT. However, you
> >>>> should
> >>>> not even to consider an that option unless there are things outside of
> >>>> your
> >>>> control that force you to go that way. Generally, you want any
> >>>> transactional
> >>>> behavior to be hidden behind the service. If your services are being
> >>>> designed properly, this should not be an issue, since each call will
> >>>> typically contain all the information to complete the transaction.
> >>>>
> >>>> I have a post here about how you need to shift your mindset when
> >>>> building
> >>>> services:
> >>>>
> >>>>
> >>>>
> http://www.iserviceoriented.com/blog/post/Introduction+to+Service+Oriented+Architecture.aspx
> >>>>
> >>>>
> >>>> On Tue, Aug 5, 2008 at 11:11 PM, Hendry Luk <hendrymail@...<hendrymail%40gmail.com>
> >
> >>>> wrote:
> >>>>>
> >>>>> Guys,
> >>>>> Just curious how do you guys maintain atomic transaction in SOA?
> >>>>>
> >>>>> Cheers
> >>>>> Hendry
> >>>>
> >>>
> >>
> >>
> >
> > --
> > It is the mark of an educated mind to be able to entertain a thought
> > without accepting it.
> >
> >
>
> --
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>
>
>