« Return to Thread: Transaction in SOA
Re: Transaction in SOA
by Jesse Ezell
::
Rate this Message:
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
>>>
>>>
>>
>
>
"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
>>>
>>>
>>
>
>
« Return to Thread: Transaction in SOA
| Free embeddable forum powered by Nabble | Forum Help |
