Re: Transaction in SOA

> Hmm..... that's pretty much what we've done in my current project.
>
> If somethig wrong durig the transaction, then stop doing the rest of the
> operation, and create a work for back-office agent to look at it.
>
> The thing is that it doesn't feel right because it compromise the integrity
> of the system, in the way that all data-alterations during all other
> operations that take place before the failure will still stay there and may
> harm the system. E.g., active billing without any network service, or the
> other way around.
>
> On Wed, Aug 6, 2008 at 6:04 PM, Greg Young <gregoryyoung1@...> 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@...> 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@...>
>> > 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@...> 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@...>
>> >>> 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.
>
>