Re: Transaction in SOA

> 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
>>>
>>
>
>