Transaction in SOA

[Hendry Luk]

Guys,
Just curious how do you guys maintain atomic transaction in SOA?

Cheers
Hendry

[Jesse Ezell]

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

[Hendry Luk]

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

[Jesse Ezell]

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

[Greg Young-2]

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.

[Hendry Luk]

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

[Greg Young-2]

Consistency and scalability are well known trade offs.

On Tue, Aug 5, 2008 at 11:41 PM, Hendry Luk <hendrymail@...> wrote:

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

--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

[Casey Charlton]

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

[Greg Young-2]

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.

[Ayende Rahien-2]

Across service boundary == problem.It is better to use a
notification mechanism to allow for compensating the results.
It also gives you better history

On Wed, Aug 6, 2008 at 7:11 AM, Hendry Luk <hendrymail@...> wrote:

>  Guys,
> Just curious how do you guys maintain atomic transaction in SOA?
>
> Cheers
> Hendry
>
>

[Casey Charlton]

Indeed ... my post was more about the original problem ...

On 06/08/2008, Greg Young <gregoryyoung1@...> wrote:

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

[Jesse Ezell]

This is why using something like msmq is important. Each unit of work  
work should be done in it's own atomic transaction after pulling the  
message. That way, your system should never get in an invalid state.  
If the network is down, the message is placed back in a queue for  
retry. That does mean that changes aren't immediately consistent  
across all systems, but that's the tradeoff you make for increased  
flexbility and scalability.

On Aug 6, 2008, at 1:41 AM, "Hendry Luk" <hendrymail@...> wrote:

> 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.
>
>  ld; color: #628c2a; font-size: 100%; line-height: 122%; }  
> #ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad  
> a:hover{ text-decoration: underline; } #ygrp-sponsor .ad p{ margin:  
> 0; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text  
> tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:
> 4} --> l>

[Jesse Ezell]

Instead of "after pulling the message" I should have said "while pulling the
message" since you want the MSMQ transaction to be a DTC transaction that
encompases both the dequeue operation and the work in SQL or whatever other
resources you are working with.

On Wed, Aug 6, 2008 at 7:31 AM, Jesse Ezell <jezell@...> wrote:

>  This is why using something like msmq is important. Each unit of work
> work should be done in it's own atomic transaction after pulling the
> message. That way, your system should never get in an invalid state. If the
> network is down, the message is placed back in a queue for retry. That does
> mean that changes aren't immediately consistent across all systems, but
> that's the tradeoff you make for increased flexbility and scalability.
>
> On Aug 6, 2008, at 1:41 AM, "Hendry Luk" <hendrymail@...> wrote:
>
>      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@...<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.iservice
>> oriented.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.
>>
>
>  ld; color: #628c2a; font-size: 100%; line-height: 122%; }
> #ygrp-sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{
> text-decoration: underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size:
> 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
> blockquote{margin: 0 0 0 4px;} .replbq{margin:4} --> l>
>
>

[Greg Young-2]

No this is exactly what you want to avoid 2pc is evil in terms of
scalability ...

You should default to things like compensating actions and justify
greatly any use of 2pc.

Cheers,

Greg

On Wed, Aug 6, 2008 at 6:51 AM, Jesse Ezell <jezell@...> wrote:

> Instead of "after pulling the message" I should have said "while pulling the
> message" since you want the MSMQ transaction to be a DTC transaction that
> encompases both the dequeue operation and the work in SQL or whatever other
> resources you are working with.
>
> On Wed, Aug 6, 2008 at 7:31 AM, Jesse Ezell <jezell@...> wrote:
>>
>> This is why using something like msmq is important. Each unit of work work
>> should be done in it's own atomic transaction after pulling the message.
>> That way, your system should never get in an invalid state. If the network
>> is down, the message is placed back in a queue for retry. That does mean
>> that changes aren't immediately consistent across all systems, but that's
>> the tradeoff you make for increased flexbility and scalability.
>> On Aug 6, 2008, at 1:41 AM, "Hendry Luk" <hendrymail@...> wrote:
>>
>> 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.
>>
>> ld; color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor
>> .ad a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{ text-decoration:
>> underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; } .MsoNormal{
>> margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; } blockquote{margin: 0 0
>> 0 4px;} .replbq{margin:4} --> l>
>
>

--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

[Ayende Rahien-2]

2PC between the local DB and the local queue isn't really bad.

On Wed, Aug 6, 2008 at 7:09 PM, Greg Young <gregoryyoung1@...> wrote:

> No this is exactly what you want to avoid 2pc is evil in terms of
> scalability ...
>
> You should default to things like compensating actions and justify
> greatly any use of 2pc.
>
> Cheers,
>
> Greg
>
> On Wed, Aug 6, 2008 at 6:51 AM, Jesse Ezell <jezell@...> wrote:
> > Instead of "after pulling the message" I should have said "while pulling
> the
> > message" since you want the MSMQ transaction to be a DTC transaction that
> > encompases both the dequeue operation and the work in SQL or whatever
> other
> > resources you are working with.
> >
> > On Wed, Aug 6, 2008 at 7:31 AM, Jesse Ezell <jezell@...> wrote:
> >>
> >> This is why using something like msmq is important. Each unit of work
> work
> >> should be done in it's own atomic transaction after pulling the message.
> >> That way, your system should never get in an invalid state. If the
> network
> >> is down, the message is placed back in a queue for retry. That does mean
> >> that changes aren't immediately consistent across all systems, but
> that's
> >> the tradeoff you make for increased flexbility and scalability.
> >> On Aug 6, 2008, at 1:41 AM, "Hendry Luk" <hendrymail@...> wrote:
> >>
> >> 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.
> >>
> >> ld; color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor
> >> .ad a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{
> text-decoration:
> >> underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; }
> .MsoNormal{
> >> margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; } blockquote{margin:
> 0 0
> >> 0 4px;} .replbq{margin:4} --> l>
> >
> >
>
>
>
> --
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Greg Young-2]

Nope that is absolutely ok ... I must have read the post wrong, my bad.

Cheers,

Greg

On Wed, Aug 6, 2008 at 9:18 AM, Ayende Rahien <Ayende@...> wrote:

> 2PC between the local DB and the local queue isn't really bad.
>
> On Wed, Aug 6, 2008 at 7:09 PM, Greg Young <gregoryyoung1@...> wrote:
>>
>> No this is exactly what you want to avoid 2pc is evil in terms of
>> scalability ...
>>
>> You should default to things like compensating actions and justify
>> greatly any use of 2pc.
>>
>> Cheers,
>>
>> Greg
>>
>> On Wed, Aug 6, 2008 at 6:51 AM, Jesse Ezell <jezell@...> wrote:
>> > Instead of "after pulling the message" I should have said "while pulling
>> > the
>> > message" since you want the MSMQ transaction to be a DTC transaction
>> > that
>> > encompases both the dequeue operation and the work in SQL or whatever
>> > other
>> > resources you are working with.
>> >
>> > On Wed, Aug 6, 2008 at 7:31 AM, Jesse Ezell <jezell@...> wrote:
>> >>
>> >> This is why using something like msmq is important. Each unit of work
>> >> work
>> >> should be done in it's own atomic transaction after pulling the
>> >> message.
>> >> That way, your system should never get in an invalid state. If the
>> >> network
>> >> is down, the message is placed back in a queue for retry. That does
>> >> mean
>> >> that changes aren't immediately consistent across all systems, but
>> >> that's
>> >> the tradeoff you make for increased flexbility and scalability.
>> >> On Aug 6, 2008, at 1:41 AM, "Hendry Luk" <hendrymail@...> wrote:
>> >>
>> >> 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.
>> >>
>> >> ld; color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-sponsor
>> >> .ad a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{
>> >> text-decoration:
>> >> underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; }
>> >> .MsoNormal{
>> >> margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; } blockquote{margin:
>> >> 0 0
>> >> 0 4px;} .replbq{margin:4} --> l>
>> >
>> >
>>
>>
>>
>> --
>> It is the mark of an educated mind to be able to entertain a thought
>> without accepting it.
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>
>

--
It is the mark of an educated mind to be able to entertain a thought
without accepting it.

[Ayende Rahien-2]

As long as we are talking about that, how do you get the bus into the
entity?

On Wed, Aug 6, 2008 at 8:52 PM, Greg Young <gregoryyoung1@...> wrote:

> Nope that is absolutely ok ... I must have read the post wrong, my bad.
>
> Cheers,
>
> Greg
>
> On Wed, Aug 6, 2008 at 9:18 AM, Ayende Rahien <Ayende@...> wrote:
> > 2PC between the local DB and the local queue isn't really bad.
> >
> > On Wed, Aug 6, 2008 at 7:09 PM, Greg Young <gregoryyoung1@...>
> wrote:
> >>
> >> No this is exactly what you want to avoid 2pc is evil in terms of
> >> scalability ...
> >>
> >> You should default to things like compensating actions and justify
> >> greatly any use of 2pc.
> >>
> >> Cheers,
> >>
> >> Greg
> >>
> >> On Wed, Aug 6, 2008 at 6:51 AM, Jesse Ezell <jezell@...> wrote:
> >> > Instead of "after pulling the message" I should have said "while
> pulling
> >> > the
> >> > message" since you want the MSMQ transaction to be a DTC transaction
> >> > that
> >> > encompases both the dequeue operation and the work in SQL or whatever
> >> > other
> >> > resources you are working with.
> >> >
> >> > On Wed, Aug 6, 2008 at 7:31 AM, Jesse Ezell <jezell@...> wrote:
> >> >>
> >> >> This is why using something like msmq is important. Each unit of work
> >> >> work
> >> >> should be done in it's own atomic transaction after pulling the
> >> >> message.
> >> >> That way, your system should never get in an invalid state. If the
> >> >> network
> >> >> is down, the message is placed back in a queue for retry. That does
> >> >> mean
> >> >> that changes aren't immediately consistent across all systems, but
> >> >> that's
> >> >> the tradeoff you make for increased flexbility and scalability.
> >> >> On Aug 6, 2008, at 1:41 AM, "Hendry Luk" <hendrymail@...>
> wrote:
> >> >>
> >> >> 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.
> >> >>
> >> >> ld; color: #628c2a; font-size: 100%; line-height: 122%; }
> #ygrp-sponsor
> >> >> .ad a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{
> >> >> text-decoration:
> >> >> underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; }
> >> >> .MsoNormal{
> >> >> margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
> blockquote{margin:
> >> >> 0 0
> >> >> 0 4px;} .replbq{margin:4} --> l>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> It is the mark of an educated mind to be able to entertain a thought
> >> without accepting it.
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> >
> >
>
>
>
> --
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Jesse Ezell]

Could you clarify what you are asking?

On Aug 6, 2008, at 6:00 PM, "Ayende Rahien" <Ayende@...> wrote:

> As long as we are talking about that, how do you get the bus into  
> the entity?
>
> On Wed, Aug 6, 2008 at 8:52 PM, Greg Young <gregoryyoung1@...>  
> wrote:
> Nope that is absolutely ok ... I must have read the post wrong, my  
> bad.
>
> Cheers,
>
> Greg
>
> On Wed, Aug 6, 2008 at 9:18 AM, Ayende Rahien <Ayende@...>  
> wrote:
> > 2PC between the local DB and the local queue isn't really bad.
> >
> > On Wed, Aug 6, 2008 at 7:09 PM, Greg Young  
> <gregoryyoung1@...> wrote:
> >>
> >> No this is exactly what you want to avoid 2pc is evil in terms of
> >> scalability ...
> >>
> >> You should default to things like compensating actions and justify
> >> greatly any use of 2pc.
> >>
> >> Cheers,
> >>
> >> Greg
> >>
> >> On Wed, Aug 6, 2008 at 6:51 AM, Jesse Ezell <jezell@...>  
> wrote:
> >> > Instead of "after pulling the message" I should have said  
> "while pulling
> >> > the
> >> > message" since you want the MSMQ transaction to be a DTC  
> transaction
> >> > that
> >> > encompases both the dequeue operation and the work in SQL or  
> whatever
> >> > other
> >> > resources you are working with.
> >> >
> >> > On Wed, Aug 6, 2008 at 7:31 AM, Jesse Ezell <jezell@...>  
> wrote:
> >> >>
> >> >> This is why using something like msmq is important. Each unit  
> of work
> >> >> work
> >> >> should be done in it's own atomic transaction after pulling the
> >> >> message.
> >> >> That way, your system should never get in an invalid state. If  
> the
> >> >> network
> >> >> is down, the message is placed back in a queue for retry. That  
> does
> >> >> mean
> >> >> that changes aren't immediately consistent across all systems,  
> but
> >> >> that's
> >> >> the tradeoff you make for increased flexbility and scalability.
> >> >> On Aug 6, 2008, at 1:41 AM, "Hendry Luk"  
> <hendrymail@...> wrote:
> >> >>
> >> >> 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.
> >> >>
> >> >> ld; color: #628c2a; font-size: 100%; line-height: 122%; }  
> #ygrp-sponsor
> >> >> .ad a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{
> >> >> text-decoration:
> >> >> underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; }
> >> >> .MsoNormal{
> >> >> margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }  
> blockquote{margin:
> >> >> 0 0
> >> >> 0 4px;} .replbq{margin:4} --> l>
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> It is the mark of an educated mind to be able to entertain a  
> thought
> >> without accepting it.
> >>
> >> ------------------------------------
> >>
> >> Yahoo! Groups Links
> >>
> >>
> >>
> >
> >
>
>
>
> --
> It is the mark of an educated mind to be able to entertain a thought
> without accepting it.
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>  x; padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px 0; }  
> #ygrp-sponsor .ad #hd1{ font-family: Arial; font-weight: bold;  
> color: #628c2a; font-size: 100%; line-height: 122%; } #ygrp-
> sponsor .ad a{ text-decoration: none; } #ygrp-sponsor .ad  
> a:hover{ text-decoration: underline; } #ygrp-sponsor .ad p{ margin:  
> 0; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text  
> tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:
> 4} -->

[Ayende Rahien-2]

Greg has talked several times in the past about messages and messaging being
core part of his domain.
I wanted to know how the bus is involved in this.

On Thu, Aug 7, 2008 at 3:39 AM, Jesse Ezell <jezell@...> wrote:

>  Could you clarify what you are asking?
>
> On Aug 6, 2008, at 6:00 PM, "Ayende Rahien" <Ayende@...> wrote:
>
>  As long as we are talking about that, how do you get the bus into the
> entity?
>
> On Wed, Aug 6, 2008 at 8:52 PM, Greg Young <gregoryyoung1@...>wrote:
>
>> Nope that is absolutely ok ... I must have read the post wrong, my bad.
>>
>> Cheers,
>>
>> Greg
>>
>> On Wed, Aug 6, 2008 at 9:18 AM, Ayende Rahien <Ayende@...> wrote:
>> > 2PC between the local DB and the local queue isn't really bad.
>> >
>> > On Wed, Aug 6, 2008 at 7:09 PM, Greg Young <gregoryyoung1@...>
>> wrote:
>> >>
>> >> No this is exactly what you want to avoid 2pc is evil in terms of
>> >> scalability ...
>> >>
>> >> You should default to things like compensating actions and justify
>> >> greatly any use of 2pc.
>> >>
>> >> Cheers,
>> >>
>> >> Greg
>> >>
>> >> On Wed, Aug 6, 2008 at 6:51 AM, Jesse Ezell <jezell@...> wrote:
>> >> > Instead of "after pulling the message" I should have said "while
>> pulling
>> >> > the
>> >> > message" since you want the MSMQ transaction to be a DTC transaction
>> >> > that
>> >> > encompases both the dequeue operation and the work in SQL or whatever
>> >> > other
>> >> > resources you are working with.
>> >> >
>> >> > On Wed, Aug 6, 2008 at 7:31 AM, Jesse Ezell <jezell@...>
>> wrote:
>> >> >>
>> >> >> This is why using something like msmq is important. Each unit of
>> work
>> >> >> work
>> >> >> should be done in it's own atomic transaction after pulling the
>> >> >> message.
>> >> >> That way, your system should never get in an invalid state. If the
>> >> >> network
>> >> >> is down, the message is placed back in a queue for retry. That does
>> >> >> mean
>> >> >> that changes aren't immediately consistent across all systems, but
>> >> >> that's
>> >> >> the tradeoff you make for increased flexbility and scalability.
>> >> >> On Aug 6, 2008, at 1:41 AM, "Hendry Luk" <hendrymail@...>
>> wrote:
>> >> >>
>> >> >> 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>
>> 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>
>> http://www.iservice
>> oriented.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.
>> >> >>
>> >> >> ld; color: #628c2a; font-size: 100%; line-height: 122%; }
>> #ygrp-sponsor
>> >> >> .ad a{ text-decoration: none; } #ygrp-sponsor .ad a:hover{
>> >> >> text-decoration:
>> >> >> underline; } #ygrp-sponsor .ad p{ margin: 0; } o{font-size: 0; }
>> >> >> .MsoNormal{
>> >> >> margin: 0 0 0 0; } #ygrp-text tt{ font-size: 120%; }
>> blockquote{margin:
>> >> >> 0 0
>> >> >> 0 4px;} .replbq{margin:4} --> l>
>> >> >
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> It is the mark of an educated mind to be able to entertain a thought
>> >> without accepting it.
>> >>
>> >> ------------------------------------
>> >>
>> >> Yahoo! Groups Links
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> It is the mark of an educated mind to be able to entertain a thought
>> without accepting it.
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>    (Yahoo! ID required)
>>
>>
>>
>  x; padding: 0 8px; } #ygrp-sponsor .ad{ padding: 8px 0; } #ygrp-sponsor
> .ad #hd1{ font-family: Arial; font-weight: bold; color: #628c2a; font-size:
> 100%; line-height: 122%; } #ygrp-sponsor .ad a{ text-decoration: none; }
> #ygrp-sponsor .ad a:hover{ text-decoration: underline; } #ygrp-sponsor .ad
> p{ margin: 0; } o{font-size: 0; } .MsoNormal{ margin: 0 0 0 0; } #ygrp-text
> tt{ font-size: 120%; } blockquote{margin: 0 0 0 4px;} .replbq{margin:4} -->
>
>
>