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