[Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Douglas Leite <do...@apache.org>]

I have implemented a sample scenario that explores the execution of
communicating processes that may be executing asynchronously. It can be
found at
http://svn.apache.org/repos/asf/tuscany/sandbox/dougsleite/travelagency.

The sample consists of a simple travel agency system organized like that:
two external services (Flight WS and Hotel WS) that are composed in a travel
agency component. The user interacts with the later by providing the needed
information to book a flight ticket and a hotel room, as well as, the
necessary information to make the payment. The sequence book/payment
operations for a flight ticket and a hotel room are executed concurrently.
This sample was inspired at [1, 2].

Actually, the sample was implemented without remotable interfaces. However,
it does not affect fully the expected behavior of the program, especially
the exceptional behavior.

The book operation for the flight service can raise an *
UnavailableFlightException* when something goes wrong during the execution
of that operation. Similarly, an *UnavailableHotelException* can be raised
by the hotel service. Since flight and hotel processes are executing
cooperatively in a composed service, an exception raised by one process
(flight or hotel) may affect the other one. So, the resolution actions made
when this kind of exception is raised may affect all process involved in the
composed service. It is important to have in mind that we are talking about
external exceptions, in other words, exceptions that could not be catch
locally at a service, and are raised to the composed service.

The Table 1 shows the actions that should be made when exceptions are
raised. An "ok" indicates that the operation was concluded, or it was
executing when an exception was raised by the other process. An "X"
indicates the occurrence of an exception. Finally, the presence of a "-"
indicates that the process did not execute that operation.

Cases 1 to 4 reflect exceptions raised by the hotel service. Similarly,
cases 5 to 8 reflect exceptions raised by the flight service. Cases 9 to 12
reflect the especial case where exceptions are raised concurrently by the
flight and hotel services.

Table 1 – Exceptional cases at travel agency sample.

*Services*

*Action*

*Book*

*Payment*

*Case 1*

Flight

ok

ok

cancel payment/book flight; cancel book hotel

Hotel

ok

X

*Case 2*

Flight

ok

ok

cancel payment/book flight

Hotel

X

-

*Case 3*

Flight

ok

-

cancel book flight; cancel book hotel

Hotel

ok

X

*Case 4*

Flight

ok

-

cancel book flight

Hotel

X

-

*Case 5*

Flight

ok

X

cancel payment/book hotel; cancel book flight

Hotel

ok

ok

*Case 6*

Flight

X

-

cancel payment/book hotel

Hotel

ok

ok

*Case 7*

Flight

ok

X

cancel book hotel; cancel book flight

Hotel

ok

-

*Case 8*

Flight

X

-

cancel book hotel

Hotel

ok

-

*Case 9*

Flight

ok

X

[concurrent exceptions]: cancel book flight

Hotel

X

-

*Case 10*

Flight

X

-

[concurrent exceptions]: cancel book hotel

Hotel

ok

X

*Case 11*

Flight

ok

X

[concurrent exceptions]: cancel book flight; cancel book hotel

Hotel

ok

X

*Case 12*

Flight

X

-

[concurrent exceptions]

Hotel

X

-



Analyzing the Case 1, for example, we can observe that the action chosen
when an exception is raised should take into consideration the state of the
composed service. When the exception is raised by the hotel service, it does
not have enough information to know in each case it was inserted (Case 1, 3,
10, and 11 are identical for the hotel service). Because of this, the
exceptions should be treating at the composed service context.

The major cases (and the focus of this proposal) are 9 until 12. At these
cases, we can see that concurrent exceptions are raised to the composed
service context. So, what should be done in this kind of situation? Maybe,
we could treat one of the exceptions and ignore the other ones. Or, we could
treat these exceptions individually, as if these ones were raised
sequentially. Or, we could combine the exceptions in another different
exception, and treat this one.

These solutions are described in papers and reports, and each one has yours
generality and implementation difficulty levels. In general, we are talking
about concurrent exception mechanisms.

As describe at [3]: *"exception handling mechanisms have the following three
steps: An exception occurrence is detected, an exception is signaled or
raised in a process, and an exception handler is executed by the process"*.
Moreover, Miller [3, 4] emphasizes three meaningful differences between
exception handling in a distributed system of asynchronous process, and
sequential exception handling, as follows:

*"[…] there are three significant differences in the sense that a sequential
process does not exhibit such semantics:*

   1. *An exception can be raised asynchronously in a process because of
   signaling by another process. A process must be in a proper program context
   to handle an exception even when a different process signals that exception.
   *
   2. *Exception handlers in multiple processes may need to coordinate to
   handle an exception even if the processes are in different program contexts.
   *
   3. *Multiple exceptions may be signaled concurrently in such systems. It
   is required that all concurrent exceptions are accounted for, though they
   may be independent of each other, and the correct context for handling these
   exceptions is determined for each process."* (MILLER, [3]).**

Miller [4] classifies the exception handling mechanisms in distributed
systems in three categories: remote exception model, concurrent exception
model, and global exception handling model.

In the first model, *"one process may signal an exception to another
process, which is called a remote exception"* (MILLER, [4]).  The exception
can be raised synchronously or asynchronously. In the first way, the
exception is raised when two process are communicating as with a remote
method invocation. In the second way, a signaled exception interrupts the
process which has this one raised in it, and the proper handler is invoked.

*"The limitations with the remote exception model are that it neither allows
explicit handler communication nor addresses the issue of multiple
exceptions that are concurrently signaled to a process." *(MILLER, [4]).

The major feature of the second model is the capability to handle concurrent
exceptions. Such model is based on an exception resolution mechanism (like
an exception resolution tree or a resolution function), and structuring the
program based on transaction like semantics.

In this model, an exception that is signaled to the participant processes of
a distributed application is called external exception. On the other hand,
an internal exception is that one handled locally in the process.

The exception resolution tree mechanisms "*considers the names or types of
the concurrently signaled exceptions to form a naming or type hierarchy
tree. The **resolved exception** is the root of the smallest sub-tree that
contains all the concurrently signaled exceptions*" (MILLER, [4]). This
approach is used in CA actions [1, 2, 5, 6, 7]. In this model, when the
resolved exception is discovered, it is raised in all the participant
processes of the CA action.

On the other hand, the resolution function model has as input parameters a
vector which contains all the concurrent exceptions, and as output an only
exception. The conversion of the exceptions in the vector to another one is
done based on some application specific heuristic. The output exception is
called concerted exception. This mechanism is adopted by Souchon to solve
the problem of concurrent exceptions at multi-agent distributed systems [8,
9].

The concurrent exception model avoids the support for handler communication
by structuring the program based on transaction like semantics, where the
exceptions signaled concurrently are sent to a exception resolution
mechanism, and after that, the resolved or concerted exception is raised in
all processes involved in the structure (like a Conversation [10], and CA
action). However, this model has some disadvantages. First of all, the use
of an exception resolution mechanism assumes that the concurrent exceptions
are related with each other in some way, what is not always easy to do.
Second, the model is based on transaction like semantics, and this kind of
architecture is not always applicable to structure a specific system.

The third model, global exception handling, is the most generic solution
based on the notion of a global entity that coordinate the concurrent
exceptions taking into consideration application specific recovery rules. In
the author words:**

"*The guardian model is based on the notion of global exception handling in
which a distributed global entity called a **guardian** orchestrates the
exception handling actions of each involved process. It directs the recovery
action of a process by raising in the process an appropriate exception,
which may differ from the exception raised in another process. The guardian
uses application defined **recovery rules** to determine the exception to
raise in each participant. The raised exception in turn causes the correct
exception handler to be invoked.*" (MILLER, [3]).

Miller shows that the use of this model has same advantages over the other
models:

   1. The guardian separates the global exception handling from the
   participant process, allowing for easier modification of the recovery
   polices.
   2. It represents a more flexible and primitive scheme than existing
   distributed exception handling approaches. So, due to its generality, the
   guardian can be used to implement other mechanisms like barrier
   synchronization, conversations, and CA actions.

However, there are some disadvantages too:

   1. Its implementation requires total-order reliable broadcast and
   time-bounded responsiveness of process. Programs have to poll or to be
   interrupted within time bounds, which may impose performance overhead on the
   program.
   2. When an exception is signaled, all processes must be interrupted, even
   those that are not involved in the exception handling. Due to this,
   additional performance overhead can be added.

I am a graduate student at University of Campinas, and my thesis is to
design and implement a concurrent exception handling mechanism in a Service
Component Architecture. So, in this context, we would have several
components (or composites – in this cases allowing nested structuring)
working concurrently and cooperatively in a fault tolerant composite.

I intend to combine the best characteristics of the concurrent exception
(especially CA actions) and global exception handling model (especially the
Guardian model), as well as, try to improve their disadvantages.

Maybe the travel agency sample, given above, is too simple to justify the
use of such complex (and maybe expensive) mechanisms. However, the real
scenarios to this kind of mechanism are safety-critical systems, in other
words, systems where fails can cost lives and financial prejudices. So, some
overhead over the system would be justified to avoid fails that can be very
expensive. Context-aware persuasive computing applications are also aim of
such kind of mechanism.

Taking into consideration the lasts publications on the exception handling
area, I could note that this is still an active research area, especially
because the popularization of SOA and related technologies, like SCA, over
the most different kinds of systems: safety-critical systems, context-aware
persuasive computing applications, e-science applications, etc.

Thoughts?

PS1: Sorry for my possible English mistakes.

PS2: I have most of the papers presented at "References". If interested to
read one, email me. :)

*References*

[1] TARTANOGLU, F.; ISSARNY, A.; ROMANOVSKY, A.; LEVY, N. "Coordinated
Forward Error Recovery for Composite Web Services". *22nd International
Symposium on Reliable Distributed Systems*, *IEEE* Computer Society Press,
2003, pp. 167-176.

[2] GORBENKO, A.; KHARCHECKO, V.; ROMANOVSKY, A. "On Composing Dependable
Web Services Using Undependable Web Components". *International Journal of
Simulation and Process Modelling*, Inderscience Enterprises Ltd., 2007, v.
2, n. 1/2, pp. 45-54. IJSPM 2007.014714.

[3] MILLER, R.; TRIPATHI, A. "The Guardian Model and Primitives for
Exception Handling in Distributed Systems". *IEEE Transactions on Software
Engineering*, IEEE Computer Society Press, vol. 30, 2004, pp. 1008 - 1022.

[4] MILLER, R.; TRIPATHI, A. "The Guardian Model for Exception Handling in
Distributed Systems"*.* *Proc. Of the 21st IEEE Symposium on Reliable
Distributed Systems*, IEEE Computer Society Press, 2002, pp. 304-313.

[5] XU, J.; RANDELL, B.; ROMANOVSKY, A.; RUBIRA C.; STROUD, R.; WU, Z.
"Fault Tolerance in Concurrent Object-Oriented Software through Coordinated
Error Recovery". *Proc. 25th International Symposium on Fault-Tolerant
Computing*, IEEE Computer Society Press, 1995, pp. 499-508.

[6]* *ROMANOVSKY, A.; PERIORELLIS, P.; ZORZO, A. "Structuring Integrated Web
Applications for Fault Tolerance". *International Symposium on Autonomous
Decentralized Systems*, IEEE Computer Society Press, 2003, pp. 99- 106.

[7] CAPOZUCCA, A.; GUELFI, N.; PELLICCIONE, P.; ROMANOVSKY, A.; ZORZO, A.
"CAA-DRIP: a Framework for Implementing Coordinated Atomic Actions". *17th
International Symposium on *Software* Reliability Engineering*, IEEE
Computer Society Press, 2006, pp. 385-394

[8] Souchon, F.; Dony, C.; Urtado, C.; Vauttier, S. "A Proposition for
Exception Handling in Multi-Agent Systems". *SELMAS'03 **2nd International
Workshop on Software Engineering for Large-Scale Multi-Agent Systems*, 2003,
pp. 136-143.

[9]* *Souchon, F.; Dony, C.; Urtado, C.; Vauttier, S. "Improving Exception
Handling in Multi-Agent Systems". *Lecture Notes in Computer Science*,
Springer,
2004, pp. 167-188. ISSN 0302-9743.**

[10] CAMPBELL, R.; RANDELL, B. "Error Recovery in Asynchronous Systems". *IEEE
Transactions on Software Engineering*, vol. 12, 1986, pp. 811-826.

-- 
Douglas Siqueira Leite
Graduate student at University of Campinas (Unicamp), Brazil

Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Douglas Leite <do...@gmail.com>]

Using the notion of the Guardian Model, we need to provide a way to annotate
all the exceptions that will be managed by the guardian. In this way, when
this kind of exception is signaled by an asynchronous process, it is sent to
the guardian, instead to the caller process. Thereafter, using the recovery
rules defined by the user, the guardian can verify which exception should be
raised in each process. This scheme also works properly when concurrent
exceptions are signaled.

The guardian works based on the notion of contexts. So, when the guardian
signals an exception in a participant, it specifies in which context the
exception should be treated (target context).

Was that what you had in mind?

On Wed, Mar 11, 2009 at 2:37 PM, Luciano Resende <lu...@gmail.com>wrote:

> On Mon, Mar 9, 2009 at 8:21 PM, Douglas Leite <do...@gmail.com>
> wrote:
> > Hi Luciano,
> >
> > This is right, and maybe one of the reasons that the specification
> doesn't
> > allow the use of @OneWay over methods that can throw an exception, is
> > because the issues it can generate.
> >
> > A simple example: If we have two methods (let's call a and b) annotated
> with
> > @OneWay, and at certain point in a, the method b is invoked, so it
> doesn't
> > matter if a or b finishes firstly, since there is no message dependency
> > among them (following the specification the methods must be void return
> > type, and must not throw exceptions).
> >
> > Allowing @OneWay over methods that can throw an exception is a
> complicating
> > factor in this scenario. Let's consider that b throws an exception, and
> is
> > annotated with @OneWay (hypothetically, since it is not allowed by the
> SCA
> > spec). So we would have the following cases:
> >
> > 1) b throw an exception and a is still executing.
> > 2) b throw an exception and a has finished its execution.
> >
> > In a normal exception flow, an exception thrown by b should be raised and
> > treated in a. In this manner, both cases have problems. In the first
> case,
> > although the method a is running when the b throws an exception, nothing
> is
> > said about the context that a is executing, in other words, the method a
> > need to be in a proper exceptional treatment context when the exception
> is
> > thrown by b. In Java language, it is like to declare all the code of
> method
> > a (starting at the point that method b is invoked) within a try block.
> >
> > The second case would introduce an error at the system, since the
> exception
> > thrown by b cannot be propagated to a. A way to solve this, is to let a
> > waiting for b finishes its execution, before go on its activity. But, if
> we
> > do that, the @OneWay specification is not respected, and we broke the
> > execution independence among the methods. So, in fact, we cannot do it.
> >
> > The mentioned solution is too simple, and doesn't solve the problem at
> all.
> > We need a powerful mechanism to control the flow of distributed
> exceptions,
> > like CA actions or the Guardian Model (more details at my first post in
> this
> > thread). In such kind of mechanisms, the exception flow is not too
> simple.
> > In the CA action for example, the exceptions are raised to each
> participant
> > of the composed service, and they come in and exit synchronously in the
> > action. The synchronous exit avoid the problem of one participant
> finishes
> > its execution before another one. Note that the entry and exit points are
> > synchronous, but the executions of the action’s participants are
> > asynchronous. On the other hand, the guardian model is based on the
> notion
> > of a global entity (the guardian) that coordinates the exception
> handling.
> >
> > Let me know if you need more clarifications.
> >
>
>
> A possible way to address this issue is to inject a global exception
> handler component  (e.g @GlobalExceptionHandler)  to a given component
> that will be invoked as @OneWay, and let that component handle the
> failure and execute any compensation actions required (like calling a
> callBack in the callerComponent responsible for executing the
> compensation actions), instead of returning control to the caller,
> that I think would broke the @OneWay paradigm.
>
> How does that sound like ? Is that the notion of "the guradian" that
> you mentioned ?
>
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>



-- 
Douglas Siqueira Leite
Graduate student at University of Campinas (Unicamp), Brazil

Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Luciano Resende <lu...@gmail.com>]

On Mon, Mar 9, 2009 at 8:21 PM, Douglas Leite <do...@gmail.com> wrote:
> Hi Luciano,
>
> This is right, and maybe one of the reasons that the specification doesn't
> allow the use of @OneWay over methods that can throw an exception, is
> because the issues it can generate.
>
> A simple example: If we have two methods (let's call a and b) annotated with
> @OneWay, and at certain point in a, the method b is invoked, so it doesn't
> matter if a or b finishes firstly, since there is no message dependency
> among them (following the specification the methods must be void return
> type, and must not throw exceptions).
>
> Allowing @OneWay over methods that can throw an exception is a complicating
> factor in this scenario. Let's consider that b throws an exception, and is
> annotated with @OneWay (hypothetically, since it is not allowed by the SCA
> spec). So we would have the following cases:
>
> 1) b throw an exception and a is still executing.
> 2) b throw an exception and a has finished its execution.
>
> In a normal exception flow, an exception thrown by b should be raised and
> treated in a. In this manner, both cases have problems. In the first case,
> although the method a is running when the b throws an exception, nothing is
> said about the context that a is executing, in other words, the method a
> need to be in a proper exceptional treatment context when the exception is
> thrown by b. In Java language, it is like to declare all the code of method
> a (starting at the point that method b is invoked) within a try block.
>
> The second case would introduce an error at the system, since the exception
> thrown by b cannot be propagated to a. A way to solve this, is to let a
> waiting for b finishes its execution, before go on its activity. But, if we
> do that, the @OneWay specification is not respected, and we broke the
> execution independence among the methods. So, in fact, we cannot do it.
>
> The mentioned solution is too simple, and doesn't solve the problem at all.
> We need a powerful mechanism to control the flow of distributed exceptions,
> like CA actions or the Guardian Model (more details at my first post in this
> thread). In such kind of mechanisms, the exception flow is not too simple.
> In the CA action for example, the exceptions are raised to each participant
> of the composed service, and they come in and exit synchronously in the
> action. The synchronous exit avoid the problem of one participant finishes
> its execution before another one. Note that the entry and exit points are
> synchronous, but the executions of the action’s participants are
> asynchronous. On the other hand, the guardian model is based on the notion
> of a global entity (the guardian) that coordinates the exception handling.
>
> Let me know if you need more clarifications.
>


A possible way to address this issue is to inject a global exception
handler component  (e.g @GlobalExceptionHandler)  to a given component
that will be invoked as @OneWay, and let that component handle the
failure and execute any compensation actions required (like calling a
callBack in the callerComponent responsible for executing the
compensation actions), instead of returning control to the caller,
that I think would broke the @OneWay paradigm.

How does that sound like ? Is that the notion of "the guradian" that
you mentioned ?


-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Douglas Leite <do...@gmail.com>]

Hi Luciano,

This is right, and maybe one of the reasons that the specification doesn't
allow the use of *@OneWay* over methods that can throw an exception, is
because the issues it can generate.

A simple example: If we have two methods (let's call *a* and *b*) annotated
with *@OneWay*, and at certain point in *a,* the method *b *is invoked, so
it doesn't matter if *a *or *b* finishes firstly, since there is no message
dependency among them (following the specification the methods must be void
return type, and must not throw exceptions).

Allowing *@OneWay* over methods that can throw an exception is a
complicating factor in this scenario. Let's consider that *b *throws an
exception, and is annotated with *@OneWay* (hypothetically, since it is not
allowed by the SCA spec). So we would have the following cases:

1) *b *throw an exception and *a* is still executing.
2) *b* throw an exception and *a* has finished its execution.


In a normal exception flow, an exception thrown by *b* should be raised and
treated in *a*. In this manner, both cases have problems. In the first case,
although the method *a* is running when the *b* throws an exception, nothing
is said about the context that *a* is executing, in other words, the method
*a *need to be in a proper exceptional treatment context when the exception
is thrown by *b*. In Java language, it is like to declare all the code of
method *a* (starting at the point that method *b* is invoked) within a
*try*block.

The second case would introduce an error at the system, since the exception
thrown by *b* cannot be propagated to *a*. A way to solve this, is to let *a
* waiting for *b* finishes its execution, before go on its activity. But, if
we do that, the *@OneWay* specification is not respected, and we broke the
execution independence among the methods. So, in fact, we cannot do it.

The mentioned solution is too simple, and doesn't solve the problem at all.
We need a powerful mechanism to control the flow of distributed exceptions,
like CA actions or the Guardian Model (more details at my first post in this
thread). In such kind of mechanisms, the exception flow is not too simple.
In the CA action for example, the exceptions are raised to each participant
of the composed service, and they come in and exit synchronously in the
action. The synchronous exit avoid the problem of one participant finishes
its execution before another one. Note that the entry and exit points are
synchronous, but the executions of the action’s participants are
asynchronous. On the other hand, the guardian model is based on the notion
of a global entity (the guardian) that coordinates the exception handling.

Let me know if you need more clarifications.

Regards

On Thu, Mar 5, 2009 at 1:35 AM, Luciano Resende <lu...@gmail.com>wrote:

> On Sat, Feb 21, 2009 at 11:07 AM, Douglas Leite <do...@gmail.com>
> wrote:
> > I think that a starter point could be allow the use of @OneWay annotation
> in
> > methods that can throw exceptions. In this way, we would allow the usage
> of
> > exceptional concurrent methods.
> >
> > Thoughts?
>
> This might not be a good idea, see a small snipet from SCA spec :
>
> 255 Nonblocking calls represent the simplest form of asynchronous
> programming, where the client of
> 256 the service invokes the service and continues processing
> immediately, without waiting for the
> 257 service to execute.
> 258 Any method with a void return type and which has no declared
> exceptions can be marked with a
> 259 @OneWay annotation.
>
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>



-- 
Douglas Siqueira Leite
Graduate student at University of Campinas (Unicamp), Brazil

Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Luciano Resende <lu...@gmail.com>]

On Sat, Feb 21, 2009 at 11:07 AM, Douglas Leite <do...@gmail.com> wrote:
> I think that a starter point could be allow the use of @OneWay annotation in
> methods that can throw exceptions. In this way, we would allow the usage of
> exceptional concurrent methods.
>
> Thoughts?

This might not be a good idea, see a small snipet from SCA spec :

255 Nonblocking calls represent the simplest form of asynchronous
programming, where the client of
256 the service invokes the service and continues processing
immediately, without waiting for the
257 service to execute.
258 Any method with a void return type and which has no declared
exceptions can be marked with a
259 @OneWay annotation.


-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Douglas Leite <do...@gmail.com>]

Hi Luciano,

In fact, the models that I have presented before can be seen as "patterns"
to handle concurrent exceptions in distributed systems. My proposal is to
adapt them to work with the SCA and its bindings.

The idea is to create a framework that allows specifying the distributed
concurrent exception handling, based on the models. Maybe this could be
described in the SCDL file, or maybe in another XML file. Specifics
annotations could be created too. Another approach could be the use of an
AOP language. All of them are just speculations, and more discussions and
studies need to be done. However, I do not know how big is the impact of the
usage of these approaches on the SCA Runtime.

I think that a starter point could be allow the use of *@OneWay* annotation
in methods that can throw exceptions. In this way, we would allow the usage
of exceptional concurrent methods.

Thoughts?
On Wed, Feb 18, 2009 at 3:47 AM, Luciano Resende <lu...@gmail.com>wrote:

> Douglas
>
>   If I understood your proposal, it looks like you are investigating
> a "pattern" or "best practice" to handle exceptions in SCA components.
>   Do you envision any requirements on the SCA Runtime to support this ?
>
> On Sun, Feb 15, 2009 at 8:25 AM, Simon Laws <si...@googlemail.com>
> wrote:
> > Hi Douglas
> >
> > Interesting post. Look forward to seeing what you come up with. Re.
> >
> > "Maybe the travel agency sample, given above, is too simple to justify
> the
> > use of such complex (and maybe expensive) mechanisms"
> >
> > Maybe it's not simple enough in the very first instance? In the travel
> agent
> > sample you have 2 concurrent business processes executing where each
> process
> > takes the form:
> >
> > Book
> > Pay
> >
> > What would be lost to your scenario if you considered Book and Pay an
> atomic
> > operation which leaves you with four combinations;
> >
> > success
> > hotels fails (either flight has or hasn't run)
> > flight fails (either hotel has or hasn't run)
> > concurrent exception
> >
> > Just a thought.
> >
> > Regards
> >
> > Simon
> >
>
>
>
> --
> Luciano Resende
> Apache Tuscany, Apache PhotArk
> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende>
> http://lresende.blogspot.com/
>



-- 
Douglas Siqueira Leite
Graduate student at University of Campinas (Unicamp), Brazil

Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Luciano Resende <lu...@gmail.com>]

Douglas

   If I understood your proposal, it looks like you are investigating
a "pattern" or "best practice" to handle exceptions in SCA components.
   Do you envision any requirements on the SCA Runtime to support this ?

On Sun, Feb 15, 2009 at 8:25 AM, Simon Laws <si...@googlemail.com> wrote:
> Hi Douglas
>
> Interesting post. Look forward to seeing what you come up with. Re.
>
> "Maybe the travel agency sample, given above, is too simple to justify the
> use of such complex (and maybe expensive) mechanisms"
>
> Maybe it's not simple enough in the very first instance? In the travel agent
> sample you have 2 concurrent business processes executing where each process
> takes the form:
>
> Book
> Pay
>
> What would be lost to your scenario if you considered Book and Pay an atomic
> operation which leaves you with four combinations;
>
> success
> hotels fails (either flight has or hasn't run)
> flight fails (either hotel has or hasn't run)
> concurrent exception
>
> Just a thought.
>
> Regards
>
> Simon
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Douglas Leite <do...@apache.org>]

Hi Simon,

In this example, due to the fact that the actions made when an exception is
raised are towards recovering the system to a consistent state (compensation
actions are executed), I think the use of book and pay operations as an
atomic operation would not affect the essence of the exceptional behavior of
the scenario.

As you observed, we would have less cases, since now book/pay can be seen as
an atomic operation. When some error is detected within the atomic
operation, it tries to put the system into a consistent state, then it
signals to the composed context an exception, just to information.

However, maybe for another scenario, we could not have actions towards
recovering the system to a consistent state, but actions which execute some
exception treatment logic and try to go on with the operation execution. In
the fault-tolerance area, we call this behavior as forward error recovery.

On Sun, Feb 15, 2009 at 1:25 PM, Simon Laws <si...@googlemail.com>wrote:

> Hi Douglas
>
> Interesting post. Look forward to seeing what you come up with. Re.
>
> "Maybe the travel agency sample, given above, is too simple to justify the
> use of such complex (and maybe expensive) mechanisms"
>
> Maybe it's not simple enough in the very first instance? In the travel
> agent sample you have 2 concurrent business processes executing where each
> process takes the form:
>
> Book
> Pay
>
> What would be lost to your scenario if you considered Book and Pay an
> atomic operation which leaves you with four combinations;
>
> success
> hotels fails (either flight has or hasn't run)
> flight fails (either hotel has or hasn't run)
> concurrent exception
>
> Just a thought.
>
> Regards
>
> Simon
>



-- 
Douglas Siqueira Leite
Graduate student at University of Campinas (Unicamp), Brazil

Re: [Proposal] Supporting Concurrent Exception Handling at Tuscany SCA

[Simon Laws <si...@googlemail.com>]

Hi Douglas

Interesting post. Look forward to seeing what you come up with. Re.

"Maybe the travel agency sample, given above, is too simple to justify the
use of such complex (and maybe expensive) mechanisms"

Maybe it's not simple enough in the very first instance? In the travel agent
sample you have 2 concurrent business processes executing where each process
takes the form:

Book
Pay

What would be lost to your scenario if you considered Book and Pay an atomic
operation which leaves you with four combinations;

success
hotels fails (either flight has or hasn't run)
flight fails (either hotel has or hasn't run)
concurrent exception

Just a thought.

Regards

Simon