« Return to Thread: Transaction in SOA
Re: Transaction in SOA
by Greg Young-2
::
Rate this Message:
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@...> 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@...> 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.
>
>
--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.
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@...> 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@...> 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.
>
>
--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.
« Return to Thread: Transaction in SOA
| Free embeddable forum powered by Nabble | Forum Help |
