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