Exception Handling in Object Oriented Systems: Towards...

Exception Handling in Object Oriented Systems: Towards Emerging Application Areas and New Programming Paradigms

Workshop

July 21, 2003

ECOOP 2003

iii

Table of Contents Introduction.............................................................................................................................. v Workshop Organizers ............................................................................................................. vi Workshop Program ................................................................................................................ vii Invited talk

Getting Control of Exception (Abstract)......................................................................... 1

Papers

Errors and Exceptions – Rights and Responsibilities..................................................... 2 Analyzing Exception Usage in Large Java Applications .............................................. 10 Bound Exceptions in Object Programming .................................................................. 20 Exceptions in Java and Eiffel: Two Extremes in Exception Design and

Application ........................................................................................................... 27 Non-Functional Exceptions for Distributed and Mobile Objects ................................. 35 Using Exception Handling for Fault-Tolerance in Mobile Coordination-

Based Environments ............................................................................................ 45 Primitives and Mechanisms in the Guardian Model for Exception

Handling in Distributed Systems ......................................................................... 57 Component Integration using Composition Contracts with Exception

Handling ............................................................................................................. 66 Error Recovery for a Boiler System with OTS PID Controller .................................... 74 Exception Handling in Component-based Systems: a First Study................................ 84

v

Introduction There are two trends in the development of modern object oriented systems: they are getting more complex and they have to cope with an increasing number of exceptional situations. The most general way of dealing with these problems is by employing exception handling techniques. Many object oriented mechanisms for handling exceptions have been proposed but there still are serious problems in applying them in practice. These are caused by

o complexity of exception code design and analysis o not addressing exception handling at the appropriate phases of system

development o lack of methodologies supporting the proper use of exception handling o not developing specific mechanisms suitable for particular application

domains and design paradigms. Following the success of ECOOP 2000 workshop, this workshop aims at achieving better understanding of how exceptions should be handled in object oriented systems, including all aspects of software design and use: novel linguistic mechanisms, design and programming practices, advanced formal methods, etc. The workshop will provide a forum for discussing the unique requirements for exception handling in the existing and emerging applications, including pervasive computing, ambient intelligence, the Internet, e-science, self-repairing systems, collaboration environments. We invited submissions on research in all areas of exception handling related to object oriented systems, in particular: formalisation, distributed and concurrent systems, practical experience, mobile object systems, new paradigms (e.g. object oriented workflows, transactions, multithreaded programs), design patterns and frameworks, practical languages (Java, Ada 95, Smalltalk, Beta), open software architectures, aspect oriented programming, fault tolerance, component-based technologies. We encourage participants to report their experiences of both benefits and obstacles in using exception handling, reporting, practical results in using advanced exception handling models and the best practice in applying exception handling for developing modern applications in the existing practical settings. Our intention is to discuss the problem of perceived complexity in using and understanding exception handling: why do programmers and practitioners often believe that it complicates system design and analysis? What should be done to improve the situation? Why is exception handling the last mechanism to learn and to use? What is wrong with the current practice and teaching? Alexander Romanovsky Christophe Dony Jørgen Lindskov Knudsen Anand Tripathi

vi

Workshop Organizers

Alexander Romanovsky School of Computing Science

University of Newcastle upon Tyne Newcastle upon Tyne, NE1 7RU, UK

email: [email protected]

Christophe Dony Université Montpellier-II

LIRMM Laboratory 161 rue Ada

34392 Montpellier Cedex 5, France email: [email protected]

www: http://www.lirmm.fr/~dony

Jørgen Lindskov Knudsen Mjølner Informatics A/S

Helsingforsgade 27 DK-8200 Århus N

Denmark email: [email protected]

www: http://www.mjolner.dk/~jlk

Anand Tripathi Department of Computer Science

University of Minnesota Minneapolis, MN 55455 USA email: [email protected]

vii

Workshop Program 9.00 - 9.10 Introduction. Alexander Romanovsky Section 1: Exception Handling Engineering (9:19-10:30) Invited talk. William Bail (Mitre) Getting Control of Exception Johannes Siedersleben (SD&M Research, Germany). Errors and Exceptions – Rights

and Responsibilities Section 2: OO Systems (11.00 - 12.30) Darrell Reimer, Harini Srinivasan (IBM Research, USA). Analyzing Exception Usage

in Large Java Applications Peter A. Buhr, Roy Krischer (U. Waterloo, Canada). Bound Exceptions in Object

Programming Joseph R. Kiniry (U. Nijmegen, Netherlands). Exceptions in Java and Eiffel: Two

Extremes in Exception Design and Application Section 3: Mobile and Distributed Systems (13.30-15.00) Denis Caromel, Alexandre Genoud (INRIA Sophia Antipolis, France). Non-

Functional Exceptions for Distributed and Mobile Objects Giovanna Di Marzo Serugendo (U. Geneva, Switzerland), Alexander Romanovsky

(U. Newcastle, UK). Using Exception Handling for Fault-Tolerance in Mobile Coordination-Based Environments

Robert Miller, Anand Tripathi (U. Minnesota, USA). Primitives and Mechanisms in the Guardian Model for Exception Handling in Distributed Systems

Section 4: Components (15.30-17.00) Ricardo de Mendonça da Silva, Paulo Asterio de C. Guerra,, Cecília M. F. Rubira (U.

Campinas, Brazil). Component Integration using Composition Contracts with Exception Handling

Tom Anderson, Mei Feng, Steve Riddle, Alexander Romanovsky (U. Newcastle, UK). Error Recovery for a Boiler System with OTS PID Controller

Frederic Souchon (LGI2P Nimes and LIRMM Montpellier, France), Christelle Urtado, Sylvain Vauttier (LGI2P Nimes, France), Christophe Dony (LIRMM Montpellier, France). Exception Handling in Component-based Systems: a First Study

Section 5: Discussion and Wrap-up (17.00-17.20)

Invited talk William Bail (Mitre): Getting Control of Exception Abstract Being able to define and use exceptions has provided a significant advantage in being able to write more reliable software. While not explicitly helping us avoid errors, they enable us to detect their presence and control their effects. Yet they act in opposition to much of what we have learned is good software design - simple structures with well-defined control flows. In addition, they complicate the process of performing formal analyses on our systems. This talk explores this issue and projects some potential ideas to help reconcile these challenges, especially with the use of OO concepts.

ECOOP'2003 - EHOOS workshop

1

Errors and Exceptions – Rights and ResponsibilitiesJohannes Siederslebensd&m Research, Munich1

Abstract

There is no generally accepted agreement on how exceptions are to be used. Many projectssuffer from a mess of exceptions thrown across the system with no defined responsibility forcatching them. This paper presents a simple component-based strategy addressing thefollowing points:

• How many and which exception classes are useful?• When should an exception be thrown? In Java: should it be a checked or an unchecked

exception?• Who is responsible for catching exceptions?• How far may exceptions be thrown?

Preconditions are considered in detail. The paper is based on the experience of many reallarge software projects.

I. Introduction

Exceptions are considered to be an important added value of modern programming languages,but they have turned out to be hard to use. We list some of the typical problems encounteredin many projects in the range from 1 to more than 100 man-years:

o There is a mess of exceptions flying around. It is neither clear when exceptions shouldbe thrown nor how they are caught.

o The code gets messy because of nested try-catch blocks.o Many (sometimes all) catch blocks are either empty, contain nonsense code (output to

the console, useless mappings of one exception class into another) or – at best – somelogging, but no true exception handling.

o A huge number of exception classes create undesired dependencies between the callerand the callee.

o Exceptions are misused to return ordinary values.

This paper presents a guideline for dealing with errors and exceptions in large systems. Codeexamples are in Java, but most results apply to other object oriented languages as well. Thepaper is based on material published as early as 1991 [Denert1991] and further developed in[Siedersleben2002].

The rest of the paper is structured as follows: Chapter II and III discuss exceptions and theproblems they cause in programming languages; Chapter IV introduces the idea ofcomponent-based emergencies; Chapter V and VI present strategies for exception handling.

1 software design & management,Thomas-Dehler-Str. 27D 81737 München


2

Pre- and postconditions are addressed in Chapter VII, and Chapter VIII summarizes ten rulesto follow.

II. Exceptions and Normal Business

Software may fail as any other result of human engineering. Thus, software is expected tocope with failure: damage should be minimized; recovery and restart should be part of thesystem design. [Parnas1976] calls undesired event whatever is not considered to be part of thenormal business and suggests to handling these events in separated traps. This is just anotherapplication of separation of concerns, which is a truism in other branches of engineering. Letus look at a fighter: as long as things go well, the fighter is fully functional without the ejectorseat; the whole system is unaware of this feature. The ejector seat becomes functional only inthe highly undesirable event of a hit or some other disaster; the seat may well be aware of thecontext it runs in: on the ground it is disabled. While Parnas' paper is certainly one of themain roots of current exception mechanisms, we find the term undesired event not appropriatewhen the roof is on fire. Instead, we suggest the term emergency which is introduced inChapter IV.

III. Exceptions and Programming Languages

Programmers have always felt the need for a supplementary information channel from thecallee back to the caller: doubtful constructs like global state variables, message areas and thelike have been in use to this day. Just returning one or more values is not enough. This is evenmore so in object oriented languages: Constructors return nothing; overloaded operatorsreturn exactly one value. So, there is no room to inform the caller about failures. This is thesyntactic reason for object oriented languages to provide an exception mechanism: you returneither nothing, a value, xor an exception.

Exceptions are a supplementary way for passing information to the caller, which can be usedfor any purpose. [Goodenough1975] mentions three: signaling failure, classifying a result(e.g. overflow, end of file) and monitoring (e.g. "that many records have been processed").So, exceptions are not necessarily exceptional, but may well be part of the normal business. InJava, only runtime exceptions such as ClassCastException or NullPointerException indicatesevere problems; checked exceptions are used for many different purposes (e.g.InterruptedException, NumberFormatException), which are not exceptional at all, but happenall the time. So, the term exception is not restricted to failures, undesired events oremergencies.

Designing sound exception mechanisms turned out to be extremely difficult. [Howell1991]complains how poorly Ada exceptions match with object orientation, Ada scoping rules, andconcurrency. C++- and Java exceptions match with object orientation and the less harshscoping rules of these languages, but C++-exceptions are completely unaware of concurrency;in Java, exceptions never leave the thread of their origin. The InterruptedException plays avery special role: it is thrown behind the scenes and serves for synchronizing threads.

Java distinguishes checked and unchecked exceptions. Checked exceptions must either behandled within the method itself or they are part of its signature as in:

void foo() throws RemoteException { .. }


3

While it is a good idea to be honest about possible failures, experience shows that checkedexceptions tend to spread all over the system. To see this, look at the foo-example: Theprogrammer calling foo has probably no idea how to handle a RemoteException and willtherefore propagate it to the next level. So, RemoteExceptions will show up everywhere,creating an undesired dependency and making changes hard if not impossible. What should bedone is to pass RemoteExceptions to the next safety facade as discussed in Chapter VI.

Exceptions don't need to be handled immediately. They fly to the next matching catch block,which can be at any distance; in the worst case, exceptions are caught by the outermost catchblock, i.e. the one of the runtime system. So, exceptions have a lot in common with thenotorious goto-statement; in fact, they offer similar opportunities for misuse.

Exceptions tend to reveal implementation details not intended for the caller. An examplewould be a stack implementation throwing an IndexOutOfBoundsException [Howell1991].This information is welcome for debugging; at runtime it is useless.

Exceptions are for free if they don't happen, but very costly if they do. In the followingexample the first method is 750 times slower than the second one (under Windows XP andJava 1.4) if called with non-Integers; if called with Integers, there is almost no penalty:

public static boolean testForInteger1(Object x) { try { Integer i = (Integer) x; return true; } catch (Exception e) { return false; }}

public static boolean testForInteger2(Object x) { return x instanceof Integer;}

As a consequence, [Cunningham2002] goes back to the roots and suggests that exceptions areexceptional: they should only be used for rare events, not for the normal control flow – a goodidea, but not in agreement with the actual use of exceptions in Java.

IV. Components, Emergencies and Assertions

We use the term component in the usual meaning (cf. [Szyperski1998]): There is at least oneinterface and one implementation. The caller calls operations defined by the interface; he isunaware of the implementation. In Java, a component is implemented by means of packages;the top level package contains everything the caller needs to use the component. This toplevel package typically contains one or more Java interfaces and the classes (includingexception classes) you need to use these interfaces. A component can call any number ofother components.

A component is either in its normal state (that is, it is able to process calls), or it is not. In thelatter case an emergency has occurred: an emergency is a situation where the programmer ofthe component doesn't know what to do – there is no local help available: the component


4

where the emergency happened is unable to solve the problem; the calling componenthowever may or may not recover.

Emergencies range from programming errors to unreachable databases and crashed neighborsystems. They could be stated as violated assertions, but assertions (and in particular assert inJava 1.4) are often used for debugging purposes only; many programmers switch them offonce the system has been tested. Emergency handling, however, cannot be switched off.All Java runtime exceptions are emergencies from the JVM's point of view: the JVM has noway to solve the problem. At the programming level, we encounter a lot of emergencies aswell: the database is not available, an SQL-statement is incorrect, or a neighbor systemreturns a meaningless value. The number of potential emergencies is as huge as the number ofpossible reasons for a car to break down: a complete enumeration is impossible.

Inexperienced programmers tend to invent and implement ad-hoc repair measures. If thishappens at a large scale, the system is doomed to failure. It is the job of the system architect toprecisely define for each component what an emergency is and what is not. Let us look at thecase of an incorrectly working neighbor system: if this situation is considered to be anemergency the calling component has the right to give up – and that is cheap to implement. Ifit isn't, then you have to design a possibly complicated and expensive fallback procedure! Theemergency-decision is always binary (there is no warning level) and local for the component:A find-operation may find zero, one or many matching objects – that's normal business, butthe caller may consider a zero-result as an emergency. The find-operation would consideritself to be in an emergency if the database connection is down, but the caller may try toreconnect the database and call find again.

We suggest using a simple class Emergency throwing an EmergencyException:

public class EmergencyException extends RuntimeException { public EmergencyException(String message) { super(message); }

}

public class Emergency {

public static void ifTrue(boolean condition, String message) { if (condition) throw new EmergencyException(message); }

// ifFalse, ifNull, now, ...

}

So you would code

public void foo() {

String result = .. // must never be null Emergency.ifNull(result, ...);}


5

Emergencies should be detected as early as possible. Detected emergencies are not desirable,but can be handled (cf. Chapter VI). The later you detect an emergency the more damage itmight have caused and the less debug information you will get. Emergencies not detected bythe program finally lead to a crash with no or little information about the reasons – the bestyou can get is a dump (cf. [Denert1991]).

detected undetectednormal state ok never happensemergency emergency handling crash

So there shouldn't be any undetected emergencies left, but this is not easy to achieve.

V. Application Errors

Methods can also fail for application reasons: you cannot withdraw money from an overdrawnaccount. These are application errors as opposed to emergencies; they are part of the normalbusiness. In general, there are only a few possible application errors: often it is sufficient tojust return ok or nok; many methods (e.g. getter-methods or rollback) cannot fail at all fromthe application point of view. Application errors can and should be fully enumerated. Theyare completely different from emergencies.

There are two ways to inform the caller about application errors: return values and exceptions.Our advice is: use return values whenever possible, use exceptions (in Java: checkedexceptions) otherwise. Example: find-methods should return null or an empty list if there areno matching objects. Using an exception to report the found-nothing result makes the codemore complicated and is much slower if found-nothing is frequent. Another example: Awithdraw-method that normally returns the balance after withdrawal should throw a checkedexception if the account is overdrawn (and for performance reasons, we hope that this rarelyhappens).

There is a hard rule: Exceptions representing application errors must be handled immediatelyby the caller and not by some hidden exception handler. They don't fly. If they did you wouldinvariably end up with a scattered, goto-like control flow. This rule implies that checkedexceptions are far from being ideal for handling application errors: They are slow if the erroroccurs and we only use a tiny part of the exception machinery.

When designing return codes or exception classes, one should carefully separate control flowon the one hand and messages for the user on the other hand. It is quite common to have alarge number of different messages, which inform the user about success or failure, but onlytwo possible outcomes affecting the control flow: ok and nok. Our advice is to use selfimplemented exception classes only if they do affect the control flow.

VI. Emergency Handling and Safety Facades


6

Emergencies are not handled by the immediate caller. Let us first discuss how emergenciescan be handled at all and then ask who takes care. There are four ways to handle emergencies:ignore, retry, call an alternative, or resign. Resigning means: minimize damage, write loginformation, and signal definite and safe failure. Definite means: it makes no sense to try anyharder, and safe says that all damage reducing measures have been taken.

The first option is used rarely and only mentioned for completeness: You just don't care aboutsuccess or failure. Retry can be useful but should be handled carefully because cascadedretries multiply. In some cases there is an alternative you can call: if the main database isdown, there might be a local fall back database. The most frequent option is to resign:minimize damage by undoing or neutralizing side effects2, freeing resources and protocol thesad event. Once the emergency has been handled, there are only two possible outcomes:success or definite and safe failure.

All this is obvious, but who takes care of all this? Here's the answer: you can call acomponent safely or unsafely. An unsafe call calls the callee directly with no emergencyhandling in between. That is, caller and callee form a risk community: they succeed togetheror they perish together. Risk communities grow by transitivity: if component a callscomponent b unsafely then a and b belong to the same risk community.

Safe access to risk communities is provided by safety facades. The safety facade – a specialcase of the well-known facade pattern [Gamma1995] – is in charge of emergency handling.All emergencies detected within the risk community fly over all involved components and arefinally caught by the safety facade. This includes all runtime exceptions as well. Riskcommunities must be designed carefully; all components belonging to the same communityshare the same emergency handling mechanism. The safety facade provides the context therisk community runs within. This architecture is quite opposed to the idea of plugged-inemergency handlers.

Safety facades can and will usually be cascaded: emergencies are handled by the nearestsafety facade; the outcome (success or definite failure) would be reported to the callingcomponent which is free to consider the definite failure as an emergency or not: a batchprocessing one million records would just protocol and skip unreadable records. So, at eachstage the emergency can either be masked or propagated to the next safety facade, jobabortion being the last resort at the outermost level (probably the main program).

What we are presenting can be considered as just a modern version of the trap mechanismsuggested in [Parnas1976].

VII. Pre- and Postconditions

Pre- and postconditions are part of the contract between caller and callee (cf. [Meyer1995,p.16]). This is an old idea: [Goodenough1975] discusses domain failures (some inputassertion is tested and not satisfied) and range failures (the operation fails to meet its outputassertion). In an ideal world, pre- and postconditions just hold – they must be valid, but inpractice one has to decide how to use them, how and where they are checked and what to do ifthey don't hold.

2 In practice, this is often done by a database rollback.


7

Preconditions are meant to protect the called component from illegal calls. They are stated interms of the input parameters and/or the component's state. It is a good idea to assume allinput parameters to be non-null as an implicit precondition and to allow null explicitly.

It is the caller's responsibility to make sure that all preconditions hold true. Thus, violatedpreconditions are the caller's problem, not the callee's. The callee would just reject a call if atleast one precondition is violated. This is an emergency from the caller's point of view, but thecallee doesn't care.

We suggest using a simple class Reject, which throws a ViolatedPreconditionException:public class ViolatedPreconditionException extends RuntimeException {

public ViolatedPreconditionException(String message) { super(message); }

}

public class Reject {

public static void ifTrue(boolean condition, String message) { if (condition) throw new ViolatedPreconditionException(message); }

// ifFalse, ifNull, now, ...

}

So you would code

public void foo(String s) {

Reject.ifNull(s, ...); // s must not be null}

Preconditions must be designed carefully: weak preconditions mean more work for the calledmethod; strong preconditions more work for the caller. So, a square root function wouldreject negative input values, but a matrix inversion would accept all non-null square matricesregardless of their rank – if the caller had to compute the rank, it could invert the matrix aswell. The safety facade (cf. Chapter VI) – if present – catches all exceptions but theViolatedPreconditionException, which is passed unhandled to the calling component.

Postconditions are completely different from preconditions: postconditions protect the calleragainst erroneous implementations. So, it is mainly the caller's interest to checkpostconditions: the less confidence you have in a given implementation (e.g. when writing atest driver) the keener you are on checking postconditions. The implementation itself is a badplace for checking postconditions and leads to silly code like the following:

int add(int a, int b) {

int result = a + b; assert result == a + b; return result;}


8

VIII. Ten Rules

1. Have a clear distinction between emergencies and application errors.2. Detect emergencies as early as possible.3. Reject calls if there is a violated precondition.4. Assume all input parameters to be non null by default.5. Design risk communities accessed by safety facades.6. Concentrate emergency handling in safety facades.7. Let safety facades catch all exceptions but the ViolatedPreconditionException.8. Report application errors using special return values (e.g. null) if possible. Use

checked exceptions otherwise.9. Handle application errors immediately.10. Don't use self implemented exception classes unless they are necessary for the control

flow.

IX. References

[Cunningham 2002] W. Cunningham, A. Hunt, D. Thomas: The Pragmatic Programmer. Addison-Wesley, 2002.

[Denert1991] E. Denert, J. Siedersleben: Software-Engineering. Springer Verlag, 1991.[Gamma1995] E. Gamma, Helm, Johnson, Vlissides: Design Patterns. Addison-Wesley, 1995.[Goodenough1975] J.B. Goodenough: Exception Handling: Issues and a Proposed Notation. CACM,

18, 12, pp. 683-696, 1975.[Howel1991] C. Howell, D. Mularz: Exception Handling in Large Ada Systems. Washington Ada

Symposium, Washington, June, 90-101, 1991.[Meyer1995] B. Meyer: Object Success. Prentice Hall, 1995.[Parnas1976] D.L.Parnas, H.Würges: Response to Undesired Events in Software Systems.

Proceedings of the Second International Conference on Software Engineering,1976, pp. 437-447

[Siedersleben2002] J. Siedersleben (Ed.): Software-Technik. Hanser Verlag, 2002.[Szyperski1998] C. Szyperski: Component Software. Addison-Wesley, 1998.

Acknowledgments:The author is grateful to two anonymous referees and to Ernst Denert for being anindefatigable discussion partner. The term emergency was coined on January 9, 2003 in hisoffice in Berlin.


9

Analyzing Exception Usage in Large Java Applications

Darrell Reimer and Harini Srinivasan

IBM Research, 19 Skyline Drive, Hawthorne, NY, USA 10532 {dreimer, harini}@us.ibm.com

Abstract. The Java programming language provides a way of identifying when semantic constraints of the program are violated using its exception mechanism. Whenever a semantic constraint in the program is violated, control flow is transferred from the point where the exception happened (throw site) to the point specified by the programmer (catch site). While this is indeed a robust and portable mechanism of handling semantic errors and exceptional program behavior, the mechanism is often misused and/or abused. In our experience working with large J2EE applications, we have encountered several inappropri-ate exceptions usage patterns that have made maintainability of these applica-tions extremely difficult. Proper exception usage is necessary to minimize time from problem appearance to problem isolation and diagnosis. This article dis-cusses some common trends in the use of exceptions in large Java applications that make servicing and maintaining these long running applications extremely tedious. The paper also proposes some solutions to avoid or correct these mis-uses of exceptions.

1 Introduction

The Java Virtual Machine [12] uses exceptions to signal semantic errors in a pro-gram. In particular, whenever a semantic error occurs, the JVM raises an exception. It is the responsibility of the application programmer to both (a) identify when such exceptions can happen, i.e., when semantic errors can happen and (b) catch these exceptions in a manner that helps identify them during program execution. Exceptions can also be used to remedy an incorrect execution behavior of the application.

Proper handling of exceptions is extremely important to be able to manage and service large J2EE applications. For example, consider a J2EE application that handles online banking transactions. Typically, the financial institution would like the applica-tion to run in a 24x7 mode to be able to service their customers continuously. The cost of stopping and starting these applications is usually very high for these institutions. Given this scenario, if a failure happens during application program execution, it is extremely important to be able to quickly locate the point of failure. In particular, if an exception is not logged, once a failure occurs, additional logging must be added, the application restarted, and the problem must be reproduced. Restarting such 24x7 ap-plications is highly undesirable. Most of the J2EE API methods whose execution can


10

result in failures are designed to throw exceptions. Examples of such methods are those that result in interactions with other components of the application architecture, for example, database, network, LDAP etc. The most desirable programming practice that can help in tracing failure points is to catch the specific exceptions thrown by these methods and output some kind of log information indicating the failure. Logging the failure this way helps in understanding what happened during program execution later on. However, in the large J2EE applications we have worked with, we noticed that this exception handling practice is not common.

Before proceeding to talk about exception usage patterns in these applications, we give a brief overview of the exception mechanism in Java (Section 2). This section is not intended to be a tutorial of Java exceptions. The reader is advised to consult the Java language specification and the Java Virtual Machine specification for details on language and implementation semantics of Java exceptions. Section 3 discusses ex-ceptions usage patterns in a handful of large J2EE applications we have worked with. This section is the primary contribution of this paper. In Section 4, we discuss ap-proaches to solve this problem of improper exception handling. Section 5 discusses related work in the area of understanding exceptions usage in Java applications.

2 Overview of Java Exceptions

An exception can occur under one the following circumstances [11]:

• An abnormal execution condition was synchronously detected by the JVM. For example, integer divide by zero, array out of bounds, out of memory er-ror, loading or linking errors.

• A throw statement was executed. • An asynchronous exception occurred because the stop method of class

Thread was invoked or an internal JVM error occurred.

The Java programming language defines class Throwable and allows the applica-tion programmer to extend this class. The Throwable class and its subclasses are col-lectively referred to as exception classes and instances of these classes are used to represent exceptions. Among these exceptions, all exceptions that are instances of class RunTimeException and its subclasses and exceptions that are instances of class Error and its subclasses need not be checked, i.e., these exceptions need not be explic-itly handled by the application. All other exceptions are checked exceptions and need to be explicitly handled in the program. The language provides the try and catch clauses to define exception handlers. During the process of throwing an exception, the Java virtual machine abruptly completes, one by one, any expressions, statements, method and constructor invocations, initializers, and field initialization expressions that have begun but not completed execution in the current thread. This process con-tinues until a handler is found that indicates that it handles that particular exception by naming the class of the exception or a superclass of the class of the exception. If no such handler is found, then the method uncaughtException is invoked for the


11

ThreadGroup that is the parent of the current thread-thus every effort is made to avoid letting an exception go unhandled. [11]. The following is a simple try – catch combi-nation:

// in the main method:try() {

foo();} catch (MyException me) {

System.err.println(me);} finally {

clearResources(); // code to close resources.}

The method foo() or one of its callees can potentially throw an exception of type

MyException (or a subclass of MyException). MyException, in this case, is a checked Java exception. When such an exception is thrown, control is transferred from the call site of foo() to the beginning of the catch block and execution proceeds from that point on. When a method such as foo() throws an exception, the signature of the method must advertise the specific exception(s) thrown. What happens inside the catch clause is still up to the application programmer. It is possible that the exception is rethrown using a throw statement, or the exception is logged or some code is executed or nothing at all happens. There is also the finally clause to a trystatement. The semantics of the finally block is that it is always executed. Whether a catch clause executes or not, the code within a finally is always executed. In the above code snippet, the method clearResources() executes both when the program exhibits normal and exceptional control flow. The Java API itself defines a number of checked and unchecked exceptions.

3. Exception usage in Large Java Applications

From our experience working with large J2EE applications, we have observed the following exception usage patterns that have hindered the maintainability and service-ability of these applications. All these applications are “real-life” i.e., customer appli-cations that have been deployed and in production.

3.1 Swallowed Exceptions

Exceptions should not be ignored through empty catch blocks. In general, every path out of a catch{} block should result in the exception being logged or the exception being re-thrown or have some kind of remedial code that remedies the exceptional execution behavior. If a handler block has neither logging code nor a rethrow, we refer to the corresponding exception as swallowed. The following is an example of a swal-lowed exception:

// example swallowed exception


12

try{foo();

} catch (MyException me) {}

where, there is no rethrow of an exception or some kind of logging code to record that the exception happened within the catch block. In one very large e-business customer application, the application code had ignored many exceptions, i.e., contained empty catch blocks without any logging information. Consequently, when such a system failed in production, it was extremely hard to track the cause of failures. Ignored ex-ceptions severely impaired the effectiveness of monitoring systems in this application environment. For example, the application had a try block that had an SQL update in it. The corresponding catch was empty. [An SQL update (executeUpdate()) method call is part of the J2EE API to access the database component of the applica-tion. The method call is usually implemented in a driver that interfaces with C code that exchanges information with the Database system, typically via sockets. ] In this case, if the update failed, there will be no record of it for the application server.

However, under certain circumstances, a catch block without any logging code or re-throw is perfectly fine. These are usually cases where exception constructs are used to manage normal program control flow, or certain exceptions caught need not be logged, e.g., InterruptedException, or the catch block contains remedial code. Listed below are a few examples:

1. // example OK swallowed exception case

key = null;try {

key = foo();} catch (MyException me) { return key; }return key;

In the above example, the value of variable key is set to null before the try state-

ment. When foo() throws an exception, the catch block executes but does not have to set the value of key to be null again. The exception thrown appears to be swallowed because of the absence of logging code or a throw statement within the catch block. Interestingly, in this example, if the programmer did not intend to use the try-catch for normal control flow, the calling method will likely see a NullPointerException that is not caught causing debugging nightmares.

2. // example OK swallowed exceptiontry {

key = foo();} catch(MyException me) {key = ValMaybeNull; }return key;

In this example, a semantically valid assignment to the variable key occurs within the catch block which can potentially execute as normal program control flow. A variation of this example is when key is initialized to null prior to the try block and the han-dler has no code in it.


13

3. // example OK swallowed exception – remedial code

sentFlag = false;

while(!sentFlag){

for(int i=0; i<connectRetry && !sentFlag; i++){

try {

send_something();

if (success) sentFlag = true;

} catch (Exception ex){

Thread.currentThread().sleep(SLEEP_TIME);

retryCount=i; // used to track #failures

}

}}

In the above example, taken from a real J2EE application, whenever a failure oc-curs during the send, i.e., in method send_something(), an exception is thrown. The while loop iterates until the method execution succeeds. This is an example where the exception causes remedial code to be executed.

3.2 Single catch block for multiple exceptions

If exceptions are caught in the same block, it should be possible to identify which exception was handled by the exception handler by the logging. However, several times, we have encountered the following (undesirable) code in these applications:

// exceptions are not handled individuallytry {

foo();bar();

} catch (Exception e) {System.out.println(“catching exception” + e);

}

The above example also points out the case where exceptions are subsumed. The following is preferred for debugging, where foo() can throw the specific exception MyException and bar() can throw the exception MyException1.

try {

foo();bar();

} catch (MyException me) {System.out.println(“MyException raised “ + me);

} catch (MyException1 me1) {System.out.println(“MyException1 raised “ + me1);

}

Within a try block, exceptions of the same type should not be raised at multiple pro-gram points. If not, it will be difficult to identify within the catch block which pro-gram point (call site) raised the exception resulting in debugging difficulties. For ex-ample,


14

// multiple program points raising same exceptiontry{

foo();bar();Object obj = baz();

} catch (MyException me1) {System.out.println(“me1 raised by bar”);

} catch (MyException me) {System.out.println(“me raised by baz or foo”);

}

where both methods foo() and baz() can throw an exception of type MyExcep-tion.Likewise, if an exception is being re-thrown, the application should avoid mapping multiple exceptions to the same exception since this hides problem sources from de-buggers.

3.3 Exceptions not handled at appropriate level

Another coding pattern that makes debugging difficult is when exceptions are not handled close to the source of the exception. If exceptions are propagated a long way up the call chain, the error message and handling will become less meaningful and debugging much more difficult.

3.4 Log verbosity in catch blocks

A common coding style in a handler that can do as much harm as good is: log(“some exception happened”);e.printStackTrace();

For example, consider a system under a load surge – some resource in the system becomes overloaded, and temporarily fails, resulting in several exceptions getting thrown. Normally, this would just affect the requesting users, but if the exception handling is overly heavy (e.g. lots of I/O, and getting the stack trace), it just adds more load to the system, causing a cascading failure that feeds on itself.

3.5 Application Statistics

The table below shows some statistics on a handful of J2EE applications that we ana-lyzed. The results show the number of swallowed exceptions as defined in this section, after filtering out cases that have return statements in the catch blocks and catch blocks that do not have to log exception information. The applications A1-A5 listed in this table are all J2EE customer applications and hence the names are hidden. The application PetStore is a J2EE sample application published by Sun Microsystems. The #classes, #methods and #handlers columns report the numbers in just the applica-tion code, not including the J2EE and J2SE libraries. The last row shows the results on JDK1.3.1 rt.jar J2SE library classes.


15

Applica-tion

# classes #methods #handlers #swallowed #after fil-tering

A1 1724 19387 9951 182 162 A2 781 8509 492 74 35 A3 666 9355 16770 80 47 A4 1151 10458 3373 97 27 A5 2202 30964 16215 444 350 PetStore 353 2001 428 22 11 rt.jar 5484 46723 3670 974 723 The following table gives additional results on false positives for some of the applica-tions, i.e., what goes on inside the handlers for some of the applications: Applica-tion

#handlers # handlers with calls

#handlers with re-throws

#handlers with loads/stores

A1 9951 9363 0 27 A4 3373 3119 0 18 A5 16215 15487 0 54 PetStore 428 372 0 1 rt.jar 3670 2242 0 77 Note that a majority of the handlers had calls in them and in the applications we ana-lyzed, we did not come across exception re-throws. When we examined application A1 in more detail and looked at the calls made inside the handlers, we noticed that a majority of these calls were not to logging code, but calls to application code doing business logic of some kind.

4. Approaches to handle the problem

How can exception handling be made more effective? Most of the J2EE API methods require the programmer writing these applications to enclose the methods in try – catch blocks. It appears the kinds of improper exception handling that we discussed in the previous section happens due to lack of rigor in writing these applications. For example, consider an application method that (1) gets a database connection using the javax.sql.DataSource.getConnection() call, (2) creates one or more data-base SQL statements using java.sql.Connection.createStatement() (3) executes the SQL statements created (that may be updates or queries to the database) using the java.sql.Statement.executeUpdate() or java.sql.Statement.executeQuery() methods and, (4) finally processes the results from the database using the java.sql.ResultSet interface methods. Almost all of these methods throw SQLException. It is tempting for the application devel-oper (who does not practice rigor) to either (a) enclose all these methods within a single try – catch block that catches an SQLException or, (b) enclose each of the


16

above method calls in a try – catch block that catches an SQLException, but the handlers do not log any information. We have encountered both these coding patterns in the applications we have worked with. As mentioned in the previous section, both these exception coding patterns make debugging an exceptional condition during program execution extremely tedious. A log of which of the database operations caused the exception to occur will be extremely helpful in debugging not only the application on the Java side, but also any database errors.

Several approaches are possible to handle this “bad coding practice” problem: ! The programming environment (an integrated development environment, IDE)

automatically inserts try – catch blocks for method calls whose signature has the throws clause in it. In addition, such an IDE could also insert a default print method call that logs some (minimal) information about the exception being caught by the handler. This approach saves a lot of trouble on the programmer’s side and also reminds the programmer to log exceptions. However, a drawback of this approach is that, in cases where the try – catch block is used to capture nor-mal control flow (see examples in Section 2), the programmer has to explicitly undo some of the operations of the IDE. While one could argue that try – catch – finally is used for normal control flow only rarely, when actually used, undoing the work of the IDE can be annoying to the developer.

! Another approach is to statically analyze the application program and point out program points in the application where exception handling has not been imple-mented properly. For example, check the application for swallowed exceptions, multiple exceptions handled by a single catch block, catch block not catching the exact exception thrown but it’s supertype etc. Such an analyzer can be integrated as part of an IDE that checks for bad coding patterns. This is the approach that we have used in our tool called SABER. SABER does static program analysis (con-trol and data flow) to check for many bad coding patterns, including swallowed exceptions and handlers catching supertype exceptions. The tool is integrated into the WebSphere Studio development environment and reports messages to the programmer in a manner within this IDE that links the error message to the pro-gram point where the bad coding pattern appears.

! Finally, is it possible for the JVM to provide more information? Typically, when an exception is thrown, the JVM dumps a stack trace. However, if the exception is rethrown within the catch block, the stack trace will include method calls only from the point where the exception was actually caught. Another factor prohibit-ing debugging of exceptions is when the JIT is on. Most JVMs do not provide line number information in the stack trace when the method has been JIT-compiled. The optimizing compiler should keep track of this information and convey the line number of the method invoked that caused the exception to occur. This approach will still not be able to provide any other logging information other than the stack trace, which is not always sufficient in debugging the problem.


17

5. Related Work

Several research papers have looked into proper handling of exceptions and have studied the control flow aspects of exceptions. Robillard and Murphy [5][6] describe their tool called Jex that can be used to illustrate to the programmer the structure of exceptions in application code. Based on the exception control flow, the programmer will be able to identify program points where exceptions are caught accidentally, error handling procedures are not being followed or finer-grained recovery code can be added in the program. Jex analyzes exception control flow and identifies exception subsumption, i.e., wherever a precise exception is not raised, and unhandled excep-tions. By presenting the resulting information to the application programmer, the tool allows the developer to encode handlers for exception types that are missing, there by increasing the robustness of the code. Our work is along the same lines as Robillard and Murphy’s and, we look at a wider range of exception usage issues including sub-sumed and unhandled exceptions within method bodies. We also present results of exception usage on large real-life applications that are typically developed by multiple development organizations and hence exhibit varying coding styles and conventions. Ryder et al [10] describe another static analysis tool, JESP, for examining the usage of exceptions. The paper provides empirical results of exception usage on Java bench-marks and discusses the implications of the results on compiler optimizations. We have observed that not all the empirical results (#exception constructs (try, catch, finally), distance between the throw and the corresponding catch, prevalence of user-defined and Java-defined exceptions, #exception classes and the shape of the excep-tion hierarchy) apply to larger Java applications that we have analyzed. A number of other papers talk about control flow representations of programs written in languages that support exceptions: the Marmot compiler [9], and Choi et al [4] for Java, the Vortex compiler [3] that supports Modula-3, Java and the Cecil languages, Chatterjee et al [8] that talks about modeling exceptions in an interprocedural control flow graph. Another paper that raises issues related to flow analysis of Java programs in presence of exceptions talks about instruction scheduling in presence of these con-structs [7]. Stevens [1,2] studies exception control flow in Java programs and the negative impact of this type of control flow on compiler driven optimizations. He also discusses ap-proaches to reducing this effect using static, whole program analysis on the byte code representation of Java programs. Romanovsky and Sander [13] talk about misusing exception handling in Ada pro-grams that have a lot in common with how exceptions are misused in Java. Miller and Tripathi [14] discuss how object-oriented techniques interact with excep-tion handling and which OO features conflict with current exception handling mecha-nisms.

References

1. Andrew Stevens, Des Watson. The Effect of Java Exceptions on Code Optimisation.


18

In European Conference on Object Oriented Programming 2000: Exception Handling in Object Oriented Systems. Workshop Talk 2. Andrew Stevens JeX: An Implementation of a Java Exception Analysis Framework to Exploit Potential Optimisations, University of Sussex, 2001. 3. Jeffrey Dean, Greg DeFouw, David Grove, Vass Litvinov and Craig Chambers. Vortex: An optimizing compiler for object-oriented languages. In ACM Conf. On Object Oriented Programming Systems, Languages and Applications, pages 83-100, October 1996. 4. Jong-Deok Choi, David Grove, Michael Hind, and Vivek Sarkar. Efficient and precise modeling of exceptions for the analysis of Java programs. In ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering (PASTE99), Sep 1999. 5. Martin P. Robillard and Gail C. Murphy. Analyzing Exception Flow in Java Programs. In Proceedings of the 7th European Software Engineering Conference and 7th ACM SIGSOFT Symposium on the Foundations of Software Engineering (Toulouse, France), volume 1687 of Lecture Notes in Comp. Sci., pages 322-337. Springer-Verlag, Sep 1999. 6. Martin P. Robillard and Gail C. Murphy. Designing Robust Java Programs with Exceptions. In Proceedings of the ACM SIGSOFT Eight International Symposium on the Foundations of Software Engineering (FSE-8): Foundations of Software Engineering for Twenty-First Century Applications (San Diego, California, USA), ACM Press, pages 2-10, November 2000. 7. Matthew Arnold, Michael Hsiao, Ulrich Kremer, and Barbara G. Ryder. Instruction scheduling in the presence of java's runtime exceptions. In Proceedings of Workshop on Languages and Compilers for Parallel Computation (LCPC'99), August 1999. http://citeseer.nj.nec.com/arnold99instruction.html 8. Ramakrishna Chatterjee, Barbara Ryder, William A. Landi. Complexity of concrete type inference in the presence of exceptions. In Lecture Notes in Computer Science, 1381, pages 57-74. Springer-Verlag, April 1998. Proceedings of the European Symposium on Programming. 9. Robert Fitzgerald, Todd B. Knoblock, Erik Ruf, Bjarne Steensgard and David Tarditi. Marmot: An optimizing compiler for Java. Technical Report MSR-TR-99-33, Microsoft Research, June 1999. 10. Barbara G. Ryder, Donald Smith, Ulrich Kremer, Michael Gordon and Nirav Shah. A Static Study of Java Exceptions using JESP, In Proceedings of CC 2000, pp 67-81. 11. James Gosling, Bill Joy, Guy Steele, Gilad Bracha. The Java Programming Language, Second Edition. Addison-Wesley, 1997. 12. Tim Lindholm, Frank Yellin. The Java Virtual Machine Specification. Second Edition. Addison-Wesley, 1999. 13. A. Romanovsky and B. Sanden. Except for Exception Handling, Ada Letters, v. XXI, 3, pp. 19-25, 2001 14. Robert Miller and Anand Tripathi, Issues with Exception Handling in Object-Oriented Systems, European Conference on Object-Oriented Programming, (ECOOP), June 1997


19

Bound Exceptions in Object Programming

Peter A. Buhr and Roy Krischer

University of Waterloo, 200 University Ave. West,Waterloo, Ontario, CANADA, N2L 3G1{pabuhr,rkrische}@plg.uwaterloo.ca

1 Introduction

In this discussion, exception handling is treated purely as a control-flow mech-anism versus a class-specific or a software-engineering mechanism [7]. From theperspective of control-flow, routine and exceptional transfers can be character-ized by two properties: 1) static/dynamic call, where the routine/exceptionname at the call/raise is either looked up statically or dynamically, and 2)static/dynamic return, where completion of a routine/handler returns to itsstatic or dynamic context; resulting in the following language capabilities:

call/raisereturn/handled static dynamic

static sequel terminationdynamic routine/member resumption

While several main-stream object-oriented programming languages (OOPL)provide exception handling mechanisms (EHM), e.g. Ada, C++, Modula-3, Java,C#, to deal with ancillary control flow, the EHM is disjoint from the objectparadigm. This position paper reexamines previous ideas for binding exceptionsto objects, as well as suggesting some extensions to these ideas.

2 Bound Exceptions

Most EHMs usually rely on only the exception type to find a matching handler.For example, the exception FileErr raised during a file operation is caught by anyhandler for FileErr. The problem is the lack of connection between the exceptionand the object raising the exception. This lack of specificity makes it difficult todistinguish among multiple files in a catch clause when one file raises an excep-tion, which may be crucial to correct handling. Hence, matching only by type isinsufficient in complex situations, and especially in object-oriented systems. Forexample, in the left example of Figure 1, FileErr exceptions can be raised by thedoWrite method of logFile, dataFile and tmpFile. For the matching-by-type strat-egy, all exceptions are handled by a single unbound handler, regardless of whichobject actually causes the error (note, SpecialFileErr is derived from FileErr). Inmany circumstances, it is unlikely that errors from three different file objectscan be uniformly handled by a single handler. When appropriate, it should bepossible to use a separate handler for each file object raising an exception.


20

2 Peter A. Buhr and Roy Krischer

class FileErr { . . . };class SpecialFileErr : FileErr { . . . };class File {

void doWrite() {. . . throw FileErr(); . . .

}};class SpecialFile : public File {

virtual void doWrite() {. . . throw SpecialFileErr(); . . .

}};File logFile;File dataFile;SpecialFile tmpFile;try { . . . logFile.doWrite(); . . .

. . . dataFile.doWrite(); . . .

. . . tmpFile.doWrite(); . . .} catch ( FileErr ) { . . . }

procedure BoundExceptions isgeneric package File is

FileErr : exception;procedure doWrite;

end File;package body File is

procedure doWrite isbegin . . . raise FileErr; . . .end doWrite;

end File;package dataFile is new File;package logFile is new File;begin

. . . dataFile.doWrite; . . .

. . . logFile.doWrite; . . .exception

when dataFile.FileErr => . . .when logFile.FileErr => . . .

end BoundExceptions;

Fig. 1. Unbound (C++) versus Bound (Ada) Exception Matching

From an object-oriented standpoint, the conventional matching-by-type han-dling of exceptions is inconsistent. Objects are the main components in an object-oriented software design, and their actions determine program behaviour. Hence,an exceptional situation is (usually) the result of an object’s action, suggest-ing the object responsible may need to be associated with the catching. Whileprior discussion exists on associating objects with exceptions for Ada [3], C[2],Lisp [8], Smalltalk [4] and Beta [5], none of this work has had an effect onmain-stream OOPLs. Therefore, it is important to strongly reiterate this cru-cial object-oriented exception-handling design objective. This discussion focusesalmost exclusively on this specific point.

For example, Ada has a partial solution by binding an exception to a pack-age instance, so the same exception originating from different instances can behandled separately. In the right example of Figure 1, the FileErr exception isdeclared inside the generic package File. Pseudo-objects are created for bothinstances of File, i.e., dataFile and logFile. Then it is possible in the handlerto bind the FileErr exception with dataFile and logFile using the dot-notation.Matching during propagation now uses both the exception type and the objectraising the exception. However, Ada disallows an unbound version of FileErr in ageneric package, precluding the ability to handle some cases as instance specificand others by a general handler. While Lisp/Smalltalk/Beta can mimic boundexceptions, it is done through mechanisms that do not or cannot exist in main-stream statically-typed OOPLs, e.g., continuations, dynamic typing, reflection,runtime compilation, virtual-machine. But most importantly, mimicking is a pro-gramming convention versus a language construct; we strongly believe this is asituation in which it is necessary to cast a convention into a specific construct,to ensure correct usage and for efficiency.


21

Lecture Notes in Computer Science 3

The following example construct for binding objects and exceptions is in-spired by the Ada example:

try { . . . logFile.doWrite(); . . .. . . dataFile.doWrite(); . . .. . . tmpFile.doWrite(); . . .

} catch ( logFile.FileErr ) {. . .} // boundcatch ( dataFile.FileErr ) {. . .} // boundcatch ( FileErr ) {. . .} // unbound

The dot-notation is an extension to the catch argument, where catch ( object .exception-type ) only matches if the raised exception is of type exception-typeand bound to object. This syntax is backwards-compatible but unusual as thesecond operand of the dot-operator is a type rather than a field of an object.Notice that exceptions from logFile and dataFile are handled by bound handlers,while exceptions from tmpFile are still handled by an unbound handler. Finally,the exception raise has to be extended to transfer an object/exception pair inthe event. Initially, it is assumed the object used at the raise is fixed duringpropagation, called static binding (see Section 5 for dynamic binding).

3 Static Bound Exceptions

Attempts are often made to simulate static-bound exceptions; however, we claimthese simulations are either unsatisfactory or incomplete. A simple simulationis to embed each operation in its own try-block so each error condition canbe handled individually. However, because the try-block is so tight around themethod call, nonlocal error-handling is impossible, i.e., error handling at outerscope levels. Additionally, since block positioning determines automatic storageallocation and execution control, it is often impossible to achieve an equiva-lent simulation. An intermediate approach is to only support bound exceptionsamong classes rather than the more general case of objects, while retaining theability to have unbound handling by deriving class-specific exceptions from anunbound exception type. That is, matching is based on the type of object thatraised the exception and the exception type. This approach provides discrim-ination among classes in bound matching, and may be accomplished with nolanguage extensions. However, besides the restriction to only class-bound excep-tions, there are several major disadvantages, such as the large number of requiredexception types and a restriction to languages supporting exception inheritance.

The most advanced approach to mimic bound exceptions is through the“catch and reraise” approach [1, §6.4]. The parameter mechanism is used topass the “bound value” from the raise to the catch site, such as the object’s id(most likely its address), and this association can be interpreted as a bindingrelationship. In C++, the latter can be done by introducing an attribute intothe exception class (left example in Figure 2). After catching the exception, thepassed value can be compared to the desired binding; if equal, the exception canbe handled, otherwise it is reraised. This solution is now able to differentiate be-tween exceptions raised by logFile and those raised by dataFile, which is a majoradvance over class-specific exception types. On the other hand, this approach


22


class BoundException {public :void * origin; // object s ID/addressBoundException(void * p) : origin(p) {}

};class FileErr : BoundException { . . . };class SpecialFileErr : FileErr { . . . };. . .try { . . . logFile.doWrite(); . . .

. . . dataFile.doWrite(); . . .

. . . tmpFile.doWrite(); . . .} catch ( FileErr e ) {

if (e.origin == &logFile) { . . .} else if (e.origin == &dataFile) { . . .} else if (e.origin == &tmpFile) { . . .} else throw ; // reraise

}

try { . . . logFile.doWrite(); . . .. . . dataFile.doWrite(); . . .. . . tmpFile.doWrite(); . . .

} catch ( SpecialFileErr e ) {if ( e.origin == &tmpFile ) { . . .} else throw ; // reraise

} catch ( FileErr e ) {if (e.origin == &logFile) { . . .} else if (e.origin == &dataFile) { . . .} else if (e.origin == &tmpFile) { . . .else throw ; // reraise

}

Fig. 2. Catch and Reraise / Reraise Anomaly

increases the program’s complexity by adding additional data and code to theexception handling process. In particular, a programmer must follow the strictconvention of inheriting from BoundException, and manually checking the bindinginformation after catching the exception and reraising it if there is no handler forthat binding. Following such a convention is always unreliable and error-prone.As well, there are situations in which the “catch and reraise” approach does notwork. In the right example of Figure 2, a SpecialFileErr bound to tmpFile is tobe handled, or a FileErr bound to logFile, dataFile, or tmpFile (note SpecialFileErrinherits from FileErr). If tmpFile raises a SpecialFileErr exception, the first catchmatches and the handler is executed correctly. If one of logFile or dataFile raisesa SpecialFileErr exception, the first catch also matches but the binding fails, andtherefore, the exception is reraised. However, because a catch clause has alreadybeen matched for the guarded block, the reraise cannot perform further match-ing on the lexically following catch clauses of the same try-block. Thus, the“catch and reraise” strategy cannot reach the second catch clause, which wouldotherwise match and handle the exception. This behaviour does not match theusual semantics of exception handling and that necessary for bound exceptions,is counter-intuitive, and results in control flow that is difficult to predict.

By using a complex programming transformation, it is possible to eliminatethe reraise anomaly [6]. The approach splits related catch-clauses into differ-ent (nested) try-blocks, but since the order of catch clauses is important, thecatch clauses lexically following a related one must also go into the containingtry-block. While try-block splitting can mimic bound exceptions with conven-tional exception handling, the conversion is complicated and can produce largeamounts of additional code. As for the other simulations, it is unreasonable torely on programmers to follow complex conventions to achieve a sophisticatedprogramming concept. Therefore, if bound exceptions are a desirable feature, itis necessary to implement them as part of the language.


23


4 Bound Exception Design

There are multiple issues in designing bound exceptions: where and how boundexceptions are defined, and the object binding during exception propagation.

With respect to bound exception definition, there are multiple approachesin languages like C++. Probably the best mechanism is specifying the bindingas part of the handler or the raise, giving four possible combinations of un-bound/bound catching/raising:

unbound raise bound raiseunbound catch 1) unbound 2) unbound

bound catch 3) not handled 4) bound

Case 1) is the catch and raise are unbound, which is conventional exceptionhandling with unbound handler matching. Case 2) is an unbound catch anda bound raise, so the handler is not object-specific. The unbound catch-clausecan handle all exceptions of that type, both unbound and bound. Hence, thebound exception is handled by an unbound handler. Case 3) is a bound catchand an unbound raise, but the bound catch-clause cannot handle this exceptionbecause it is unbound. Case 4) is a bound catch and a bound raise (to the sameobject), so the catch clause is able to provide an object-specific handler and theexception is handled as a bound exception. It is possible to simplify the table(eliminate column 1), with only minor loss in functionality, by defining all raisesto be bound, i.e., always include the object raising the exception as part of theexception event. In this design, no functionality is lost between Case 1) and Case2), as both perform an unbound catch. However, the functionality of Case 3) iseliminated as there is always a binding at the raise, which may be a null bindingvalue (see below). Now the binding decision is made solely in the catch clause.The positive consequence of this design decision is that legacy code, which doesnot know about bound exceptions, continues to work after replacing all raises bybound ones (possibly by recompiling). A negative consequence is that all raisesnow require additional memory for the binding information and time to storethe binding information, regardless of whether the binding information is used.However, the space/time overhead is not an issue because the space is small andexceptions normally occur infrequently.

The selection of the binding object seems obvious, i.e., the object responsiblefor the raise, which precludes raising an exception bound to a different object(e.g., throw logFile.FileErr); such a possibility would weaken an object’s control.For special cases, such as non-member routines and static class-members, thebinding value can be set to null. Hence, if a programmer does not want anexception to have a direct binding, the exception can be raised indirectly in astatic-member routine.

Interestingly, extending the concept of bound exceptions to resumption prop-agation is straight-forward since there are no differences during propagation withrespect to matching between termination and resumption exceptions. Nonlocalpropagation among coroutines/tasks (i.e., propagation across execution-stacks)


24


is possible by extending the object binding. The previous binding rule is inappro-priate for nonlocal exceptions because the object raising the nonlocal exceptionin a coroutine/task may not be meaningful or even known in the target corou-tine/task, and a nonlocal exception can essentially happen anytime, anywhere.A better solution for nonlocal exceptions is to bind to the raising coroutine/task,so it appears the exception emanates from it. For the case where a coroutine ortask does not care about the specific tasks sending it nonlocal exceptions, e.g.,clients communicating with a server, it is possible to process the exceptions usingunbound handlers.

5 Dynamic Bound Exceptions

The problem with static binding is that the object raising the exception may bea local variable or argument of a block. Therefore, once the exception propagatesoutside of the declaring block, the binding object may disappear or be invisible.This issue can be solved in many cases if the exception changes its binding duringpropagation at each object it traverses through, called dynamic binding. Thesecases are illustrated in the left example of Figure 3. Assume the declaration ofdb either passes a file for initializing variable DB::f or DB::f is created as a localvariable. In either case, routine DB_ Manager::flush does not know about this fileobject (especially when separately compiled). Now the catch clause inside commitis within the scope of f, so it can catch any exceptions raised by f. However, theattempted catches in flush are syntactically or semantically incorrect. The firstcatch is syntactically incorrect since f is invisible inside the scope of flush (unlesscoincidentally there is an f variable in the current scope, which would result ina difficult to locate error). The second catch is semantically incorrect since dbdoes not raise the bound exception FileErr, so this catch is never matched. Whilethese catch clauses are wrong, logically the user is trying to do the correct thing.That is, catch the specific FileErr exception associated with its operation (flush),but not catch FileErr exceptions associated with other operations, which might behandled at a higher level of abstraction. In fact, the catch clause catch (db.FileErr)is probably what a user really wants to write, as db exists in the current scopeand (from a logical point of view) is responsible for raising the exception. Thiscatch clause works for dynamic binding because the binding object changes fromf to db when exception propagation terminates the call to commit. The right sideof Figure 3 visualizes the binding change during stack unwinding when dynamicbinding is used during propagation. In fact, we have identified cases where a usermay need both static and dynmaic binding to correctly handle an exception, andwith extra syntax it is possible to support both.

6 Conclusion

Bound exceptions truly incorporate exception handling into the object-orienteddesign process. The ability to associate exceptions with objects strengthens therelationship between an exception and the object responsible for its raise. Thisfeature creates more powerful exception handling capabilities, contributing to


25


class DB {File [&]f; // parameter or localpublic : void commit() {

try { f.doWrite(); // raises FileErr} catch ( f.FileErr ) {. . .} // OK

}};void DB_ Manager::flush( DB &db ) {

try { db.commit();} catch ( f.FileErr ) {. . .}

catch ( db.FileErr ) {. . .}}DB db(. . .);class Driver {

public : static void run() {DB_ Manager dbman;dbman.flush( db );

}};

do_write()

commit()

flush()

run()

Stack

f

db

dbman

Driver::run()

???

bound object

f

f

db

dbman

dbman

Fig. 3. Dynamic Binding

building more robust software. We believe this capability cannot be simulated inmost OOPLs, and hence, requires a language construct. This work discusses twokinds of bound exceptions: static and dynamic. While some form of static bindinghas been discussed previously, this discussion extends static binding and presentsdynamic binding as an interesting addition. As well, identifying that both kindsof bound exceptions can coexist and that each provides distinct capabilities toallow a user precise control in matching exceptions is an important idea.

References1. P. A. Buhr, A. Harji, and W. Y. R. Mok. Advances in COMPUTERS, volume 56,

chapter Exception Handling, pages 245–303. Academic Press, 2002.2. P. A. Buhr, H. I. Macdonald, and C. R. Zarnke. Synchronous and asynchronous

handling of abnormal events in the µSystem. Software—Practice and Experience,22(9):735–776, Sept. 1992.

3. Q. Cui and J. Gannon. Data-oriented exception handling. IEEE Transactions onSoftware Engineering, 18(5):393–401, May 1992.

4. C. Dony. A fully object-oriented exception handling system: Rationale and smalltalkimplementation. In Exception Handling, volume 2022 of LNCS, pages 18–38.Springer-Verlag, 2001.

5. J. L. Knudsen. Fault tolerance and exception handling in BETA. In ExceptionHandling, volume 2022 of LNCS, pages 1–17. Springer-Verlag, 2001.

6. R. Krischer. Bound exceptions in object-oriented programming languages. Diplo-marbeit, Universitat Mannheim, Mannheim, Deutschland, Oct. 2002. ftp://-plg.uwaterloo.ca/pub/uSystem/KrischerThesis.ps.gz.

7. R. Miller and A. Tripathi. Issues with exception hnadling in object-oriented systems.In ECOOP’97, volume 1241 of LNCS, pages 85–103. Springer-Verlag, 1997.

8. K. M. Pitman. Condition handling in the lisp language family. In Exception Han-dling, volume 2022 of LNCS, pages 39–59. Springer-Verlag, 2001.


26

Exceptions in Java and Eiffel:Two Extremes in Exception Design and Application

Joseph R. Kiniry

Computing Science Department, University of NijmegenToernooiveld 1, 6525 ED Nijmegen

The [email protected]

1 Introduction

The designers of future languages will need to decide whether to include exceptions in their new languages.If they decide exceptions are warranted, they must then consider what exceptions represent: a structure forcontrol flow, a structure for handling abnormal, unpredictable situations, or something in-between. Finally,the syntax and meaning of exceptions must be considered.

The syntax of exception mechanisms is important: syntax impacts how program code looks and iscomprehended, it influences the design and realization of algorithms, and it affects the manner in whichprogrammers handle unusual cases and unexpected conditions (what we’ll call “errors”), thus indirectlyimpacts software reliability. While the syntax of exception mechanisms is the face most programmers see,their semantics is what tool developers and language theoreticians must wrestle with. In general, a small,elegant semantics is desired by all parties.

An excellent way to consider how to design a feature like exceptions in future languages is to analyzetheir design in today’s languages. The analysis of exceptions in niche, historical, or research languages likeAda, PL/I, and CLU can reveal a gem or two, but perhaps more can be gained by examining the contraryviewpoints that exist in two modern languages.

The programming languages Java and Eiffel offer two opposing viewpoints in the design and use ofexceptions. A detailed analysis of exceptions in these two languages: their language design, formal spec-ification and validation, core library use, and non-technical “social” pressures, can help future languagecreators design their own exception mechanisms.

2 Language Design

Language design only partially influences the use of exceptions, and consequently, the manner in which onehandles partial and total failures during system execution. The other major influence are examples of use,typically in core libraries and code examples in technical books, magazine articles, and online discussionforums.

This latter “social” effect is clearly seen in the use of exceptions in Java and Eiffel, as we will discussin Section 5.

Exceptions in Java are designed to be used as control structures. This is also true of exceptions in mostother modern programming languages including Ada, C++, Modula-3, ML and OCaml, Python, and Ruby.

Eiffel’s exceptions, on the other hand, are designed to represent and handle abnormal, unpredictable,erroneous situations. The languages C#, Common Lisp, and Modula-21 use this general meaning for ex-ceptions as well.

1 Note that Modula-2 did not originally have exceptions; their addition caused a great deal of controvery through theearly 1990s (i.e.,, compare [12] to [13]). See http://cs.ru.ac.za/homes/cspt/sc22wg13.htm for a historical discussionof such.


27

2.1 Java

Exceptions in Java are used to model erroneous circumstances. They always indicate situations that shouldnot be witnessed during a typical execution of a program. Most Java exceptions are meant to be dealt withat runtime—just because an exception is thrown doesnot mean that the program must exit.

Java’s exceptions are represented by classes which inherit from the abstract classjava.lang.-Throwable . They are generically calledthrowablesbecause raising an exception is Java is accomplishedwith thethrow keyword.

Java’s throwables are one of two disjoint types:unchecked exceptionsorchecked exceptions. The formerinherit from either the classjava.lang.RuntimeException or the classjava.lang.Error , thelatter inherit fromjava.lang.Exception [4, Section 11.2].

Java’s Checked ExceptionsIf a method can raise a checked exception, the checked exception typemustbe specified as part of the signature of a method. Thethrows keyword is used to designate such. A clientof a method whose signature includes an exceptionE (i.e., the method states “throws E ”) must eitherhandleE with acatch expression, or the client also must declare that it can throwE.

Checked exceptions are mainly used to characterize failure conditions for method invocations, like afile not being readable or a buffer overflowing. Not all erroneous conditions in Java are represented byexceptions though. Many method return special values, encoded as constant field of related classes, whichindicate failure. This brings us to the first key point of this paper:

Exceptions should have a uniform, consistent informal semantics for the developer.

The state of Java with regard to point one is poor. While some attempt has obviously been made to useexceptions only for truly unexpected incidences, there are numerous examples of inconsistent use (e.g.,ArrayStoreException , FileNotFoundException , andNotSerializableException ).

Examples of common checked exceptions that are part of many method signatures includeIOExcep-tion andInterruptedException .

Java’s Unchecked ExceptionsUnchecked exceptions are either runtime exceptions or errors.Runtime exceptions are conditions that can rarely (but potentially) be fixed at runtime, and thus are not

errors. Examples includeArrayIndexOutOfBoundsException , ClassCastException , andNull-PointerException .

Errors indicate serious problems with which most applications should not try to deal. Most errors in-dicate abnormal conditions with either the operating environment or the program structure. Examples oferrors areAssertionError , NoSuchMethodError , StackOverflowError , andOutOfMem-oryError .

2.2 Exceptions in Eiffel

The fundamental principle in Eiffel is thata routine must either succeed or fail: either it fulfills its contractor it does not. It the latter case an exception isalwaysraised [9, 8]. Thus, exceptions are, by design, to beused in Eiffel exclusively to signal when a contract is broken.

Exceptions are not specified as part of the type signature of a routine, nor are they mentioned in routinecontracts. In fact, there is no way to determine if a routine can raise an exception other than through aninspection of the routine’s code, and all the code on which it depends.

Eiffel exceptions are represented byINTEGER andSTRING values; there are no exception classes2.Exceptions that are part of the language definition are represented byINTEGER values, developer-definedexceptions bySTRING values3. This limited and non-uniform representation of exceptions brings us tothe second key point:

2 Eiffel class names are always capitalized.3 Earlier versions of the Eiffel language standard permitted developer-defined integer exception values, but this seems

to no longer be the case. It is unclear when and why this change was made.


28

Exceptions should have a uniform representation,and that representation should be amendable to refinement.

Eiffel’s exceptions have two representations, causing some design impedance when dealing with them.Additionally, because they are basic values and not objects, they have no internal semantics beyond thatwhich can be expressed in a helper routine, which necessarily cannot be foolproof because of the represen-tation overloading in effect.

Contract Failure Contracts can be violated in several ways, all of which are consideredfaults, but onlysome of which are under programmer control.

Operating environment problems, such as running out of memory, are one situation in which exceptionsare signaled. In these cases a contract can fail, but not necessarily because the caller or the callee didsomething wrong.

Certainly, intentionally allocating too much memory, or otherwise using an extraordinary amount ofsystem resources, is the fault of the program. But such situations are more malicious than typical.

Software infrastructure failures can cause exceptions. Some operating system signals raise an excep-tion. Failures in non-Eiffel libraries that are used by an Eiffel application can cause exceptions as well. Forexample, Eiffel programs that link with Microsoft Windows COM components can witness an exceptionspecific to COM routine failure. Eiffel programs that use UNIX libraries can see an exception which indi-cates that an external library failed but did not set theerrno system variable. A floating point exceptionis raised on some architectures when a division by zero is attempted.

But most exceptions used in Eiffel are not due to external factors, but instead areassertion violationsor developer exceptions, both of which are used to indicate program errors.

If assertion checking is enabled during compilation, assertion violations cause an exception to be raised.These exceptions are classified according to the type of assertion that has been violated.

The check instruction, which is equivalent to C’s or Java’sassert construct, cause aCheck -instruction exception to be raised. ALoop variant exception is another assertion violation; it israised when a loop variant does not monotonically decrease during loop execution.

Violating a contract, either by failing to fulfill a class invariant, a method precondition or postcondition,or a loop invariant, is the final kind of exception. Contract violations fall into two categories: those that arethe fault of the client of a class, and those that are the fault of the supplier of a class. The classification ofan exception is determined by the context of the failure during program execution.

If a contract is broken at the time a method is called, regardless of whether the caller is another objector the current object (in the case of a callback, or the use of theretry keyword, see below), then the faultlies with the caller.

Exactly one kind of exception, calledVoid call target , can be the fault of either the caller or thecallee. If a method is invoked on an object reference with valueVoid , aVoid call target is raised. Ifthe caller set the value toVoid , or did not check the reference prior to making the invocation attempt, thenthe fault lies with the caller. In situations where the reference was obtained via a routine call, either via aformal parameter or a return value, and the value isVoid , the fault lies with the callee, as the specificationof the routine is not strong enough to eliminate the possibility of theVoid value.

The uniform design for assertion violation signaling with exception in Eiffel is contrary to that whichexists in Java. Several tools exist to permit the formal specification of contract for Java code. We use theexcellent JML tool suite [7]. Unfortunately, because assertion violation semantics is so primitive in Java,there is no uniformity of exceptions across different assertion tools and specification languages. This bringsus to point three:

If exceptions are used to represent assertion failure, their design and semanticsshould be incorporated into the core language specification.

The users of these tools have suffered tremendously because the creators of Java ignored this key pointin language design.


29

2.3 Comparing Eiffel’s Exceptions to Java’s Unchecked Exceptions

Eiffel’s exceptions and Java’s unchecked exceptions are exclusively focused on unexpected, erroneousbehavior that an application should not try to handle. Thus, one would expect every Eiffel exception to mapto a single Java unchecked exception. This is not the case.

Some of Eiffel’s built-in exception types are equivalent to standardcheckedexceptions in Java. Forexample, Eiffel’sIo exception , Runtime io exception , andRetrieve exception are semi-equivalent toIOException and some of its children.

A number ofuncheckedexceptions are equivalent to standard Eiffel exceptions. For example,Void -call target is equivalent toNullPointerException , andFloating point exception isequivalent toArithmeticException .

Finally, some children ofjava.lang.Error are equivalent to the remaining Eiffel exceptions:As-sertionError is equivalent to the set of specification-centric Eiffel exceptions (Check instruction ,Class invariant , Loop invariant , Loop variant , Postcondition , andPrecondition ),andNo more memory is equivalent toOutOfMemoryError andStackOverflowError .

Missing Mappings Several exceptions that exist in each language have no peer in the other language.Rescue exception has no mapping, as Java does not perform any special handling of exceptions

thrown in afinally clause.An equivalent forSignal exception is not part of the core Java language as Java’s definition

focuses on multiplatform development and not all platforms have signals4. The Eiffel language specificationstates that such system-specific exceptions should be contained in system-specific classes, but no compilersimplement this suggestion.

An error likeVoid assigned to expanded is not possible in Java as Java has no expanded typesand the type system prohibits assignment ofvoid to built-in types likeint andboolean .

The Eiffel literature claims that Eiffel has no casting (cf., [10, page 194], thus there is no equivalentto Java’sClassCastException . This claim is a bit disingenuous because Eiffel’s assignment attemptoperator ‘?=’ is simply a built-in conditional downcast in the form of an operator5.

Routine failure is a generic exception that indicates a routine has failed for some reason. Thereason is sometimes recorded (as aSTRING) in themeaning associated with the exception, but this is notmandatory. This is also true of Java exceptions, each of which has an optional message associated with itobtainable viaThrowable ’s getMessage method. Unfortunately, there is absolutely no uniformity tothe use of these representations in either language.

When defining a new type of exception, human and machine comprehensible representations (e.g., a stringvalue and a predicate) should either be mandatory, or not exist at all.

None of the various Java exceptions dealing with out-of-bounds access to arrays and strings exist inEiffel because the contracts of accessor routines for these types prohibit such. Cloning-related exceptionsdo not exist because all objects can be cloned in Eiffel.

Integrated contracts significantly decrease the number and complexity of exceptions.

This point is emphasized by the quantative analysis of Section 4.Standard Eiffel also does not have several features of Java: reflection, introspection, concurrency, and

sandboxing. These features contribute significantly to the complexity of Java’s exception class hierarchy.

4 One can catch and handle signals in Java, but internal classes likesun.misc.Signal andsun.misc.SignalHandler , or a package like [6], are needed.

5 This is not the only pragmatic circumvention in Eiffel. Other examples include the dual semantics of routine calls(with and without an explicit “Current ”) and the semantics of theequal andclone routines of ANY.


30

Controlling Exceptions in Eiffel Exceptions are primarily controlled in Eiffel usingrescue clausesandthe retry instruction. Exceptions are also indirectly controlled by the choice made incompilation modeduring application development.

A routine may end with a rescue clause. Arescue clauseof a routine is a block of code that will executeif any exception is raised during the execution of the routine.

The rescue clause does not discriminate between different types of exceptions. In this respect, it isfunctionally equivalent to the surrounding every Java method body with atry /catch block where thecatch expression is “catch (java.lang.Throwable) ”. The rescue clause isnotequivalent to Java’sfinally construct. The code enclosed in a finally block isalwaysexecuted when a method completes,whether it completes normally or abnormally, while a rescue clause only executes when a routine fails.

The retry instruction causes a routine to restart its execution, attempting again to fulfill its contract.This instruction can only be used within a rescue clause. If a rescue clause does not contain a retry instruc-tion, then the routine fails and the current exception is raised in the immediate caller.

We will return to the details offinally andrescue in the sequel.Exceptions are manipulated in Eiffel using the EXCEPTIONS class. Using this class one can find out

information about the latest raised exception (much likeerrno in C), handle certain kinds of exceptionsin a special way, raise special developer-defined exceptions, and prescribe that certain exceptions must beignored at run-time.

The EXCEPTIONS class is part of the Eiffel Kernel Library, thus is available in all Eiffel compilers.

3 Exceptional Specifications and Validation

The key difference between the use of exceptions in the two languages in that exceptions arepart of amethod contract in Java and arenot part of a routine contract in Eiffel. Thus, a fundamental notion of “De-sign by Contract”, that of exceptions exclusively indicating contract failure, has a different interpretationin Java.

3.1 Contracts with Exceptions in Java

We use the Java Modeling Language to write formal specifications of Java components [1]. We have partic-ipated in the development of a coalgebraic semantics for Java and JML [5]. The discussion in this sectionare based upon that experience.

The semantics of Java, and thus JML, are significantly complicated by the possibility of abrupt methodtermination (i.e., an exception being thrown). Validation proofs must deal with three cases in Java: normaltermination, abrupt termination, and divergent behavior, sometimes tripling proof size.

The default specification for a failure is simply “true”, which means that the routine guarantees nothingin particular when a failure takes place. Rarely can nothing stronger be said, and in fact exceptional casesare often the first part of a formal specification we write.

This information helps the caller deal with the exceptional cases in a more reasonable manner than justhalting. We have also found that the specification of a postcondition for abrupt termination ismandatoryfor reasoning about systems during abrupt termination. Without such assertions, class invariants wouldbecome significantly more complex because ghost variables would be needed to represent failure states forall of the routines of a class.

3.2 Specifications of Eiffel Exceptions

In Eiffel, the semantics ofexceptional-correctroutines is rolled into the definition ofclass correctness[10,Chapter 15 and Section 9.16].

The definition [10, Section 15.10] ofexception-correctis:A routiner of a classC is exception-correct if and only if, for every branchb of its rescue block:

1. If b ends with aRetry : {true} b {INV_C and pre_r}2. If b does not end in aRetry : {true} b {INV_C}


31

whereINV C is the class invariant ofC; pre r is the precondition of routiner.This existing semantics is a problem in practice because it means that Eiffel code must always have

a rescue block that “puts everything right” (fulfills the normal postcondition), which usually means eithera significant weakening of the postcondition (one can barely state anything is true if things can either failor succeed) or an extremely complex postcondition with a large set of disjuncts with error-flag guardedexpressions.

For example,

method_call_failed implies (F || G || H)|| not method_call_failed implies (I || J || K)

This kind of specification is evident in the very few places where exceptions are handled in Eiffel code, andwe speculate this is true because of the inherent complexity in such specifications.

Specifications in JML that use keywords likeexsures andexceptional behavior which aresimply shorthand for these more complex expressions. We believe that Eiffel could benefit from suchexpressions as well.

This semantics significantly complicates contracts and weakens their application. Neither case is sur-prising: either (in case 1) a rescue clause must fulfill the invariant and the precondition of the retried routineor, (in case 2) a retry does not happen so the routine has to leave the object in a legitimate state by fulfillingits invariant. What is surprising is thatnothingis know about when or why the exception happened in thefirst place, since both preconditions are as weak as possible, and nothingnewcan be specified about thestate of the objects when a failure takes place, since the postcondition is exactly the invariant.

JML is exactly contrary here—it provides the ability to state a stronger postcondition in these excep-tional cases, and this information is essential to validating programs with exceptions.

This brings us to our next key point:

The specification of object state when an assertion is raised, either via an exceptional postcondition or anexception predicate, is very desirable if programs are to be formally verified.

The Java Modeling Language fulfills this key point admirably, while Eiffel fails in this regard.

4 Qualitative and Quantitative Comparisons

In the end, it is unclear how important exceptions are in the Eiffel world. This might be due to exception’sperceived second-class nature in the Eiffel universe of “correct” software, as evidenced by their rare use(see below).

If exceptions in Eiffel are equivalent to unchecked exceptions in Java, and if library programmers forthe two languages equally careful and capable of handling unexpected circumstances, then an analysis ofexception usage in the two core code bases should yield comparable results.

The data in Table 1 is the result of such an analysis. In the case of the Gobo and SmartEiffel systems, allcode, library and applications, was analyzed for this data. The number of declared exceptions is determinedby counting and classifying all calls toEXCEPTIONS.raise andEXCEPTIONS.die, in the case of Eiffel,and counting all descendants ofjava.lang.Throwable , in the case of Java. The number of raisedexceptions is determined by a count of the number of calls toEXCEPTIONS.raise andEXCEPTIONS.die,in the case of Eiffel, and the number ofthrow expressions, in the case of Java. The data on stack tracesis determined by counting and analyzing all calls to routinesexception name, tag name, meaning ,and developer exception name of classEXCEPTIONS. All numbers are approximate and onlymeasured using thewc command.

Consider that in Java an unchecked exception is thrown for approximately every 140 lines of code,where in Eiffel one is used for every 4,600 lines of code; that is a difference of over thirty times infrequency. The above statistics clearly show that either or both (a) exceptions in Eiffel, either throughtechnical issues or social pressure, have a second-class (or perhaps even ignored) status, or (b) the built-inexistence of adequate specification technologies inherently leads to fewer assertions being thrown. Giventhe preponderance of quality Eiffel software available, the latter point holds much more weight. This isespecially highlighted in the complete lack of exception usage in the GNU SmartEiffel system.


32

Library Gobo 3.1ePosix 1.0.0ISE Eiffel 5.3 SmartEiffel 1.0JDK 1.4.1 (java.)Number of direct/indirectmentions of EXCEPTIONS,or unchecked exceptions 18 3 17 0 525/ 15,000Number of unchecked/checkedexceptions declared 3/- 6/- 5/- 0/- 50/ 150Number of raised unchecked/checked exceptions 66/- 87/- 13/- 0/- 3,000/ 2,650Number ofrescue orfinally clauses 6 10 29 0 50Number ofretry commands 81 3 15 0 N/ANumber of times a stack traceis (a) checked or manipulated,or (b) printed or ignored 0/0 0/0 0/0 0/0 8/79Total lines of code and documentation250,000 25,000 372,000 115,000 421,000

Table 1.Use of Exceptions in Eiffel and Java

This data should be carefully considered by the committee performing ECMA language standardizationof Eiffel. It also provides evidence for potential avenues for language refinement, particularly with regardsto the specification of exceptional conditions.

5 Exception Equivalency

Both languages have exceptions mechanisms that can be treated as equivalent. A hierarchy encoding can berepresented by integer or string values, so we could build an artificial type hierarchy for Eiffel exceptionsif we felt it necessary.

Likewise, the minimal exception interface of Eiffel, embodied in theEXCEPTIONS class, could bemodeled in Java. In fact, some Java developers advocate avoiding checked exceptions entirely, insteadinheriting exclusively fromRuntimeException [3].

We can find no evidence of the converse, that of Eiffel programmers using exceptions as flow controlmechanisms.

As any Java programmer knows, the volume oftry /catch code in a typical Java application is farlarger than the comparable code necessary for explicit formal parameter and return value checking in otherlanguages that do not have checked exceptions.

In fact, the general consensus among in-the-trenches Java programmers is that dealing with checked ex-ceptions is nearly as unpleasant a task as writing documentation. Thus, many programmers report that they“resent” checked exceptions. This leads to an abundance of checked-but-ignored exceptions, as evidencedby the next to the last line of the table of the previous section.

Additionally, the presence of checked exceptions percolates through the system. As discussed by thedesigners of C# [2],

Examination of small programs leads to the conclusion that requiring exception specificationscould both enhance developer productivity and enhance code quality, but experience with largesoftware projects suggests a different result – decreased productivity and little or no increase incode quality.

This attitude guides the design of error handling in the .NET framework as well [11, see Section “ErrorRaising and Handling Guidelines”].

These issues lead us to our last, and perhaps crucial point:

Checked exceptions generally increase system fragility (because of signature refactoring), increase codesize (due to explicit, localized, mandatory handling), and cause programmer angst (as evidenced by thenumber of empty or spitefulcatch blocks in public Java code), so their inclusion in a language should

be carefully considered.


33

In the end, so long as an exception mechanism has a simple semantics, is consistently used, and providesa tool which programmers can understand, depend upon, and not resent, then they should be included infuture languages.

Acknowledgments.This work was supported by the Netherlands Organization for Scientific Research(NWO). Thanks to the anonymous reviewers and Alexander Kogtenkov for their comments.

References

1. Lilian Burdy, Yoonsik Cheon, David Cok, Michael Ernst, Joe Kiniry, Gary T. Leavens, K. Rustan M. Leino, andErik Poll. An overview of JML tools and applications. Technical Report NIII-R0309, Dept. of Computer Science,University of Nijmegen, 2003.

2. Posted by Eric Gunnerson. Original author unknown. Why doesn’t C# require exception specifications?3. Bruce Eckel. Does Java need checked exceptions? See http://www.mindview.net/Etc/Discussions/CheckedExceptions,

particularly the ensuing feedback on this issue.4. James Gosling, Bill Joy, and Guy Steele.The Java Language Specification. Addison-Wesley Publishing Company,

first edition, August 1996.5. Bart Jacobs and Erik Poll. A logic for the Java modeling language JML. Technical Report CSI-R0018, Computing

Science Institute, University of Nijmegen, November 2000.6. What is JavaSignals?, 1999. See http://www.geeksville.com/ kevinh/projects/javasignals/.7. Gary T. Leavens, Albert L. Baker, and Clyde Ruby.Behavioral Specifications of Business and Systems, chapter

JML: A Notation for Detailed Design, pages 175–188. Kluwer Academic Publishing, 1999.8. Bertrand Meyer. Disciplined exceptions. Technical Report TR-EI-13/EX, Interactive Software Engineering, 1988.9. Bertrand Meyer.Object-Oriented Software Construction. Prentice-Hall, Inc., second edition, 1988.

10. Bertrand Meyer.Eiffel: The Language. Prentice-Hall, Inc., 1992.11. .NET framework general reference, 2003. Documentation version 1.1.0.12. Richard J. Sutcliffe, editor.Modula-2 (Base Language). Number 10514-1:1996 in ISO/IEC Modula-2 Standard-

ization. ISO/IEC, 1999.13. Niklaus Wirth.Programming in Modula-2. Springer–Verlag, 1982.


34

Non-Functional Exceptions for

Distributed and Mobile Objects

Denis Caromel and Alexandre Genoud

INRIA Sophia Antipolis, CNRS - I3S - UNSABP 93, 06902 Sophia Antipolis Cedex - France

[email protected]

Abstract. While there is quite a lot of techniques to separate non func-tional properties from functional code, the handling of induced excep-tions remains often blurred within application. This paper identifies Non-Functional Exceptions as exceptions related to various failures of non-functional properties (distribution, transaction or security). We proposea hierarchical framework where reified exception handlers are attachedto various entities (proxies, remote objects, futures). Such handlers allowmiddleware and application oriented handling strategies for distributedand mobile computation. The mechanism tries to handle exceptions atnon-functional level as much as possible.

1 Introduction

Distributed environments provide synchronous and asynchronous calls, remotereferences, migration of activities. Complex communications are subject to var-ious failures such as the remote communication failure. It is always unclearwhether the failure occurred in the communications medium or in the remoteprocess, and the state of the system is in general uncertain. Unfortunately, thetry/catch construction is heavy to use, and only convenient for simple commu-nication errors.

In this article, we define non-functional exceptions as exceptions related todistribution. We present a hierarchical model based upon handlers of exception.Sets of handlers are dynamically attached to various entities (JVMs, remoteand mobile objects, proxies, ...) in order to provide a generic and flexible re-covery mechanism at a non functional level. This model has been implementedand bench marked in a framework for parallel, distributed and mobile comput-ing known as ProActive1. As implementation remains simple, the port to othermiddlewares is possible.

The first section presents previous works related to exception handling indistributed architectures. Then, non-functional exceptions are defined and thoserelated to distribution are classified. The next chapter describe a flexible modelused to handle simple communication failures but also to create advanced fault-tolerance strategies. Finally, pragmatic examples are presented. Performancesare discussed in the appendix.

1 http://www.inria.fr/oasis/ProActive


35

2 Denis Caromel and Alexandre Genoud

2 Related Work

Exceptions have been created in ADA in the 1970s and are now a standard mech-anism to report errors and failures. In distributed environments, they are raisedfrom host to host and thus are difficult to handle. Through the development ofour distributed library, we realized that standard handling mechanisms are notappropriate to distribution, as developers must define handling code for everydistributed exception.

Authors of [4] highlight a critical problem that appears when several failures oc-cur simultaneously. While communications between distant processes are broken,an unstable state is probably reached. This article suggests to gather communi-cating processes into a conversation before starting any kind of communication.Participants first save their own state ; then a set of handlers is associated tothe conversation. All action participants are involved in co-operative handling ofany exception raised by any action participant : the conversation is paused untilthe handling process is terminated. When handlers are not sufficient to recoverfrom failure, the conversation is canceled. Every process checks possible side ef-fects and rollbacks to its initial state. This collaborative strategy seems reallypromising but fails with asynchronism. As the return time of an asynchronouscall is unknown, the lifespan of the conversation is also unknown. The recoveryprocess could be maintained as long as no result is delivered.

Agents are active objects having autonomous behavior according to their en-vironment. As mobility is one possible behavior, an agent can decide to migrateon a different virtual machine. In this context, authors define guardians in [5]as centralized mechanisms helping agents to handle exceptions related to distri-bution. Only one guardian is needed for every agents-based application. Whenan agent cannot handle an error, the exception is raised to the guardian whichsend back instructions. Of course, the handling behavior depends not only ofthe nature of the exception but also of the agent environment. When distantobjects become unreachable, the guardian can advise to delay communication.When critical failures occur, the guardian can terminate agents. An interestingstrategy to handle failures related to the migration of agents could be to findan equivalent destination using the replication strategy. This centralized modeloffers simplicity as it provides only one single guardian even for large distributedsystems. However, many problems would occur if the guardian becomes unreach-able or crashes.

3 Non-Functional Exceptions

During the conception process, we identified three majors features required fordistributed handling mechanisms : flexibility, genericity and dynamicity. Con-sidering that previous models did not meet all of these requirements, we decidedto create an original model from scratch based upon a new classification of ex-ceptions.


36

Non-Functional Exceptions for Distributed and Mobile Objects 3

3.1 Functional versus Non-Functional

In recent literature, classifications of exceptions are proposed. According to [7],exceptions can be divided into internal exceptions, raised from and handledwithin a method, and external exceptions propagated toward other methods.This classification is not useful for distributed environments which require com-plete description of internal failures. In our framework, we consider the mecha-nism of distribution as a non-functional property [8]. We use this specificity todefine non-functional exceptions as exceptions raised from any non-functionalproperty.

Definition 1 Non-functional Exceptions announce failures occurring in nonfunctional properties. They are raised in non-functional code and handled, asmuch as possible, within it.

We make a clear difference between functional exceptions, related to abnormalbehavior of applications, and non-functional exceptions, related to failures ofnon-functional properties. Exceptions related to distribution should be consid-ered as non-functional exceptions coming from the middleware. We agree withthe recommendation of [9] which claims that exceptions have to be handledat meta level. It is much more simple indeed to handle exceptions directly ininternal mechanisms of distribution.

3.2 Location of Non-Functional Exceptions

Distributed environments provide synchronous and asynchronous communica-tions as describe in [1]. Failures in such communications result in non-functionalexceptions as shown in 1. While in synchronous calls, those exceptions are simplyhandled at results delivery, asynchronous calls lead to two solutions. Exceptionsare eventually handled when requests containing reified calls are synchronouslyqueued. But non-functional exceptions have to be handled in future objects whenpending requests are served or when results are stored within them.

Functional Code

VM A

// v is an active object

// foo returns an int// The call is synchronousint result = v.foo();

// The call is asynchronousB b = v.bar();

// bar returns a reifiable object

b.useResult();// and used when available// Result is stored in B,

Non−Functional Code

HandlingMechanism

Exceptions also occur

at result delivery or

in future objects

Exceptions related tosynchronous calls

calls are stored in queuesexceptions occur whenIn asynchronous calls,

Fig. 1. Exceptions Raised from Synchronous and Asynchronous Calls


37


3.3 A Hierarchy of Distributed Exceptions

We first identified and classified potential failures (figure 2) of distributed envi-ronments. Then, we built a hierarchy of potential failures, opened to developerswho can add new failures and topics. We kept this structure customizable asflexibility is the most important feature of recovery mechanism. Finally, we asso-ciated non-functional exception to every failure. This hierarchy is used to definehandling strategies for specific exceptions as well as for groups of exceptions.

Distributed Exceptions

Communication Migration Security Creation Group Services

SendRequest

SendReply

SendCom

ReceiveRequest

ReceiveReply

ReceiveCom

SendRequest

SendReply

SendCom

ReceiveRequest

ReceiveReply

ReceiveCom

SendRequest

SendReply

SendCom

ReceiveRequest

ReceiveReply

ReceiveCom

SerializationOnDepartureOnArrival

ActiveObjectFutureReifyObject

Send Send Send ReceiveReceiveReceive

ServiceFailed

Fig. 2. Hierarchy of Failures Encountered in Distributed Environments

4 A Hierarchical and Dynamic Handling Mechanism

The hierarchy of failures described above is used in the construction of hierar-chical handlers, working indifferently at functional or non-functional levels.

Definition 2 Handler of exceptions handle non-functional exceptions as well asgroups of such exceptions, thanks to object inheritance.

For instance, a handler can be associated to SendRequestGroupException or toevery member of GroupException (see [10] for detail about group communica-tions). Handlers provide basic strategies in non-functional code, but application-specific strategies are also possible. They reify the try/catch construction tosupport both genericity and flexibility required by any handling mechanism.Handlers implement a common interface and provide functional as well as non-functional treatments of non-functional exceptions.

4.1 Prioritized Levels of Handling

Our mechanism is based upon a default and static level, created during themiddleware initialization, and some dynamic levels set during execution. Each


38


structure can provide a specific fault tolerance strategy created from an ap-propriate set of handlers. Every non-functional exception is associated to onehandler in the default level. The default strategy is basic but always presentwhile complexes strategies appear occasionally in higher levels. We defined sixdifferent levels, associated to constants within the implementation and presentedbelow from lower to higher priority.

1. Default level is static and initialized in core of applications. This level providea basic handling strategy for every non-functional exception.

2. Virtual Machine level is the first level that can be created dynamically. Itoffers the possibility to define a general handling behavior for every VM.

3. Remote and Mobile Object level is used to bind handlers to remote objects.Handlers associated to mobile entities migrate along with them.

4. Proxy level is used to define strategies for references to active objects. Whenreference are passed to other VMs, handlers are passed also.

5. Future level is attached to the results of asynchronous calls.6. Code level allows temporary handlers to be set in the code.

As describe above, the default level provides a basic handling strategy, definedduring the initialization of middleware. Virtual machine level and higher onesare set dynamically to improve this strategy. Dynamic handlers are created atruntime and added to an appropriate level (VM, remote object, proxy, future orcode levels).

4.2 Presentation of the API

The API is both used for middleware adaptation (e.g. wireless oriented) andfor distributed application. It consists in two major static functions which offersettings and configurations of handlers into appropriate levels. The five dynamiclevels are defined with constants.

// Binds one handler to a class of exception at the specified level.

void setExceptionHandler(level, Handler, Exception, Target);

// Removes handler associated to a class of exception at specified

// level. Target is different from null when level is object-related.

Handler unsetExceptionHandler(Level, Exception, Target);

The following example show how to protect an application from commu-nication failures. We add a handler with the setExceptionHandler primitive.Communication failures are thus handled for that object.

// Creation of a remote and mobile object with handlers

RO ro = (RO) ProActive.newActive("RO", "//io.inria.fr/VM1");

// A communication handler is dynamically associated

// to the remote object trough its proxy.

setExceptionHandler(ProxyLevel,

"CommunicationHandler",

"CommunicationException",

ro);


39


4.3 Dealing with Mobility

Most of the distributed environments offer remote and mobile objects. Such ob-jects can migrate from host to host. This additional constraint can break thecontinuation of the handling mechanism. The migration process must be modi-fied to take into account the migration of mobile object handlers. As explainedlater, mobile objects and their associated levels remain always gathered. Han-dling mechanism can be associated to proxy also in order to attach a specificstrategy to remote references.

4.4 Implementation

As explained before, the handling strategy is built upon one static level improvedoccasionally with dynamic levels. Handlers are searched with the following ded-icated function.

// Searches through prioritized levels the handler associated

// to the given class of exception

Handler searchExceptionHandler(Exception, Target);

The following code is part of the middleware and describe how to activate thehandling mechanism. Instead of providing a treatment directly in the try/catchblock, we use the searchExceptionHandler primitive.

try {

// Send the reified method call

sendRequest(methodCall, null);

} catch (NonFunctionalException e) {

// Looks for an appropriate handler and

// use the handler if possible

Handler handler = searchExceptionHandler(e);

if (handler) handler.handle(e);

}

We tried to keep implementation as simple as possible but performance is-sues were also considered. Levels are implemented with hashmap to provide fastaccess to handlers. Considering the memory available in modern computer, wesupport time complexity instead of space complexity even if migration increasememory requirements because of levels associated to mobile objects. The cost isproportional to the number of handlers contained in the object level.

Reflexion is used to search handlers for a specific class of exception or for themother class of a group of exceptions. The algorithm supports generic handlers ofhigher levels instead of specific handlers from lower level ; Levels have precedenceover the type of exceptions. For instance, on figure 3, the most suitable handlerfor exceptions related to class 02 is found in the highest level. When no handleris available at remote object level, the search continue in VM an lower level.This choice, which seems more natural, can be invert.


40


An exceptionoccurs

in class O2VM LEVEL

− Handler O1

− Handler O2

O2Class

3. Default level is usually used when no strategy is defined

1. The search starts in higher levelHandler O1 is preferred to an eventualHandler O2 from lower levels

REMOTE OBJECT LEVEL

ClassO1 Handler O1

2. Search continues in VM Level

DEFAULT LEVEL

− Handler for every exception

Fig. 3. Levels have Precedence over Exception Type when Searching Handlers

5 Canonical Examples

We present in this section two applications which use our handling mechanism.

5.1 Handling Exceptions in Unconnected Mode (e.g. wireless PDA)

Distributed applications for Personal Digital Assistants should provide an un-connected mode to handle at least communication exceptions due to brokenconnections. We defined a strategy where handlers store requests sent to un-reachable PDAs in a queue. Time by time, a thread checks if the connection isrestored in order to deliver requests. The point is not to define a sophisticatedstrategy, but to show how easily it can be activated. Here is the scheme of sucha PDA-Handler.

Class PDACommunicationHandler implements Handler {

public boolean isHandling(Exception e) {

return (e instanceOf CommunicationException);

}

public void handle(Exception e) {

// A thread testing connectivity is created

if (firstUse) {

connectivityThread = new ConnectivityThread();

}

// Then reified method calls are stored in the

// queue and exceptions are not propagated anymore

queue.store(e.getReifiedMethodCall());

}

}


41


Imagine now that an entity is about to create a mobile object that migrateon some wireless PDA.

// Creation of a remote and mobile object with handlers

RO ro = (RO) ProActive.newActive("RO", "//io.inria.fr/VM1");

// A communication handler is dynamically associated

setExceptionHandler(ProxyLevel,

"PDACommunicationHandler",

"CommunicationException",

ro);

// The mobile object can now migrate safely

ro.migrateTo("//pagode.inria.fr/VM2");

5.2 Simulating a Centralized Error Manager

The handling mechanism can easily be configured into a centralized error man-ager similar to the one presented in [5]. We create first a remote object containinga complete set of prioritized handlers. This object is located on one virtual ma-chine but is known from every active object of the application. Non-functionalexceptions reporting failure are not handled directly in the active object but areraised to the centralized error manager instead. A handler corresponding to thefailure is sent back to handle the exception. This strategy does not avoid thetypical problems common to every centralized error manager but offers at leastan efficient centralized handling mechanism, easy to configure.

H1 H3H2 H4

H1’ H2’ H3’

H1" H2" H3" H4" H5"

Centralized GUARDIANContains Set of Handlers

VM ARemote objects notify exceptionsrelated to distribution. Informationabout the level is also provided.

handler according to the contextGuardian searches for a reliable

of exception. Then handlers is sentback to the remote object

1

2

VM B

Signal exceptionSend back areliable handler

Legend

ObjectRemote

ObjectRemote

ObjectRemote

ObjectRemote

ObjectRemote

Fig. 4. Centralized Error Managers are Easy to Implement


42


6 Conclusion and Perspectives

We defined a dynamic, flexible and generic model to handle non-functional ex-ceptions. We proposed a classification for non-functional exceptions along witha hierarchy of prioritized levels. As implementation use the classical try/catchlanguage construct, the model is reliable for a large panel of modern, object-oriented, programming languages.

References

1. D. Caromel, W. Klauser and J. Vayssiere. Toward Seamless Computing and Meta-computing in Java. Concurrency Practice and Experience (September-November1998) p. 1043-1061 Editor Geoffrey C. Fox, published by Wiley & Sons

2. E. F. Walker, R. Floyd, P. Neves Asynchronous Remote Operation Execution inDistributed Systems. In Proc. of the Tenth International Conference on DistributedComputing Systems, May/June 1990.

3. F. Baude, D. Caromel, F. Huet and J. Vayssiere, Communicating Mobile ActiveObjects in Java HPCN Europe 2000, Amsterdam - The Netherlands, May 2000

4. Jie Xu, Alexander B. Romanovsky and Brian Randell. Coordinated Exception Han-dling in Distributed Object Oriented System (Revision and Correction). Depart-ment of Computing Science, University of Newcastle upon Tyne, Newcastle uponTyne, UK.

5. Arnand Tripathi and Robert Miller . Exception Handling in Agent-Oriented Sys-tems. Advances in Exception Handling Techniques, Springer-Verlag LNCS 2022,March 2001.

6. Valerie Issarny. Concurrent Exception Handling. Advances in Exception HandlingTechniques 2000: 111-127. Inria Rocquencourt.

7. Alessandro F. Garcia, Cecilia M. F. Rubira, Alexander Romanovsky and Jie Xu.A Comparative Study of Exception Handling Mechanisms for Building DependableObject-Oriented Software. Journal of Systems and Software, Elsevier, Vol. 59, Issue2, November 2001, p. 197-222.

8. Kiczales, Lamping, Mendhekara, Maeda, Lopes, Loingtier, Irwin. Aspect-OrientedProgramming. Proceedings of ECOOP 97, n 1241 LNCS, Springer-Verlag, June1997, p. 220-242.

9. Ian S. Welch, Robert J. Stroud and Alexander Romanovsky. Aspects of Excep-tions at the Meta-Level (Position Paper). Department of Computing, Universityof Newcastle upon Tyne.

10. Laurent Baduel, Francoise Baude, Denis Caromel. Efficient, Flexible, and TypedGroup Communications in Java. Proceedings of the Joint ACM Java Grande -ISCOPE 2002 Conference. Nov. 2002.

11. Anh Nguyen-Tuong. Integrating Fault-Tolerance Techniques in Grid Applications.Partial Fullfillment of the Requirements for the Degree Doctor of ComputerScience. University of Virginia.


43


Appendix: Time and Space Performances

Space Complexity : Each system contains at least default and virtual machinelevels : some handlers contained by two hashtables.

Strategy Description Number of Handlers Size in Byte

No Handler No handler is provided. Wejust pay the cost of an emptylevel based upon Hashtable

0 82

Minimal One global and generichandler achieve applicationsoundness

1 209

Per Group One handler is provided foreach group of non-functionalexception (see 2)

7 1561

Per Communication Every communication ex-ception has 2 handlers : re-mote object level and VMlevel

2 * 6 = 12 2833

Table 1. Space Requirements Depends of the Number of Handlers

Time Complexity : Adding and removing handlers do not break overallperformance of the system. Research of handlers is complexity-less, thanks tohashtable properties. We raised a huge number of exceptions and measured timeto find handlers. The ratio is 1:4.

0

100

200

300

400

500

600

700

0 500 1000 1500 2000 2500 3000 3500 4000

Han

dlin

g Ti

me

(in m

illis

econ

d)

Number of Raised Exceptions

try/catch Handling MechanismDynamic Handler Mechanism

Fig. 5. Time Complexity


44

�� ! "�$#&%��'(�)�+*-,.�/�0�1#2�� 3��4 ��5(��768�9�$#2��:�2�0�/�9*<;=�>�?��@A�CB��0#2�/�(DE��/��

F:GIHKJML"NONPLRQSG+T�LVUXW�HCY[Z�U]\O^_Z�NPÒH[aSLVNP`�b�cdZ�efL"NP`fZ�Uhg1H"iCLVNOHKJfj]k[l[mnporq)sKtvuwq�xys{z}|MqXuw~vz�t��z�uwq1�O� ��s_�I��uw��twz��K�{q��_xys{z}|MqXuw~vz�t��+��q)s_q)|��V�

or�y�w��V��S��qXs{q)|��:�_�[�V��z�tw�)q]uw�d��s[��V��V �¡M¡" -¢¤£_�X¥[ �¦M§V��¨V©�ª_�-¢¤ªM¡"��«K¬¢v©�®

¯��V°]±_�K��P��+or��>²{�_twz}s_³>�"°Xz�qXs{°)q��{x�s_z�|�qXuw~vz�t´��¶µyqX��°)��~·tw�}q��µh¸2��¹0º2x»µ�q]��°��~·tw��q1�_²f��sR¼¶�"s{q��_x�½

¾K¿�¬�ÀV �¡MÁK¬�¦¶¢¤ÂV�)¥[ �¡"��"Ã�ÄVÅK¨�¡V¬�Æ_©� MÃ�ÇV¿�¬¶¢· M©-¢�ª�Ä

È É{ÊÌËfÍOÎ�ÏSÐ�Ñ-ËOÒwÎÌÊ

T(H"ÓOGIcIG�ÔwlÕH"Ö$\Pj]Z�U)j�L"NP`�×0Hf`fZ_Ø�×0H"\PÙOcdZ�`�Ú�GdÔ]ÛÜÔ]HfÒLMlfj9Ù-HKÚ�Z�U]ÖÝ\OcSÛ<LVNP`fÛPZ�cÞ`Ü`fZ�J{GÞ×0Z�j�ØLVcIcdHKÚ1j$\Pj�Ô]HßL"N{Ô]GÞ×0GIÙPLKÔXZpÔ]Û<LKÔCLà×0cÞL"jXj�H"ÖSLVÙPÙOcdGÞ×�LVÔ]GIH"NPj�ØrÚ�ÛOGI×)Û.Ú�GdcIc�ÔXLVk_ZpiRH"UXZ�L"NPì/H_U]Z�GdiRÙ-H"U]ÔXL"NP×0Z/GdNàÔ]ÛOZRNOZ�e[Ô:l_Z�LVU)j�ØPGÞj�ÔXÛPLKÔ>H"ÖÌiRH"ÓOGIcdZRLV^_Z�N{Ô�á·ÓPL_j�Z�`(LVÙOÙOcIGÞ×�LKÔXGdH_NPj�âã NP`fZ�Z�`Ø�ÛPL"NP`fÛOZ�cI`»`fZ�J{GÞ×0Z�jRNOZ�Z�`.cIGI^"Û{Ôp×0Hf`fZ�Ô]ÛPLVÔ9×�L"NäÓ-Z�ÖÝU]Z�Z�cIlåiRHKJ"Z�`åÖÝU]H_iæH"NPZ`fZ�J[GÞ×0Z1ÔXH�L"NOHVÔXÛOZ�U�Ø_L_×�×0H_UXÒGdNO^çÔXH�ÔXÛOZ�\Pj]Z�U�è j�iRH"ÓOGIcIG�ÔwlRH"UyNOZ�Z�Òj�â{T(H_ÓOGIcdZ:LV^"Z�N{Ô�á·ÓPL"j]Z�`LVÙOÙOcIGÞ×�LKÔXGdH_NPjçÔwl[ÙOGÞ×�L"cdcIlàUX\ONéH"NåL�iRH_ÓOGdcIZ9×�H{H_UXÒGdNPLVÔ]GIH"Nfá·ÓPL_j�Z�`àZ�N{J[GIU]H_NOiRZ�N{Ô�Ø+Ú�ÛOZ�UXZÙOU]H_^"U)LViCj×0H_iRi$\ONOGÞ×�LVÔ]Z�L_j�l[NP×)ÛOUXH"NPH"\Pj]cdl1Ô]ÛOUXH"\O^_Û>L1j�Û<LVUXZ�`:iRZ�iRH"UXlSj]ÙPL"×�Z"â�êhÛOZ�UXZ2GIjL�N[\Oi$Ó-Z�UyHVÖ¶H_\fÔXj�ÔXL"NP`fGINO^�GÞj]j]\OZ�jyGINpÙOUXHKJ{GÞ`fGINO^çÖ¤LV\Pc�Ô�Ô]H_cdZ�UXL"NP×0Z�H"Ö+j�\P×)Û�LVÙOÙOcIGÞ×�LKÔXGdH_NPj�âêhÛOZ9LVGIiëHVÖhÔ]ÛOGÞj�ÙPLVÙ-Z�U�GÞj>ÔXH�ÙOUXH"Ù-H_j]ZpLVNéZ�ef×�Z�ÙfÔXGdH_NéÛPLVN<`fcdGINO^(iRHf`fZ�chj]\OG�Ô)LVÓOcIZCÖÝH_Ui/H_ÓOGIcdZ�×�H{H_UXÒGdNPLVÔ]GIH"Nfá·ÓPL_j�Z�`CZ�N[J[GdUXH"NPi/Z�N{ÔXj�â

ì<í�ì îSï¶ð"ñ{òró�ô¤õ-öø÷(ùOörú?û�ô¤örüýSNOZçHVÖ+ÔXÛOZ>×)ÛOGIZ0ÖrÔ]UXZ�NPÒjhGIN�ÙOU]HKJ[GÞ`fGINO^/ÒZ�Ù-Z�NPÒL"ÓOGIcdGdÔwlpHVÖriRH[ÒZ�UXN�j]lfjwÔXZ�iCjhGIj�ÔXÛOZ>`fZ0á×0UXZ�L"j]GINO^�U]H_cdZ2ÙPcILMl_Z�`:Ó[l�ÔXH"cIZ�U)LVNP×�Z2Ô]H1Û<LVU)`fÚ�L"U]Z�áÚXZ�cÞLKÔXZ�`1Ö¤LV\OcdÔXj�â�êhÛPGIj+GIj?`f\OZ�ÔXH�j]Z�J"Z�UXL"cÖ¤L"×�ÔXH"U)j�þ_GdiRÙOUXHKJ"Z�iRZ�N{ÔXj2GINpÛPL"UXÒÚ�L"U]Z1ÿ{\PL"cdGdÔwl"Ø{L�`fU)LViCLKÔXGI×�^_U]HKÚhÔXÛCHVÖ Ô]ÛPZ:×�H"iRÙOcIZ0efG�ÔwlHVÖ2j�H"Ö ÔwÚ�L"U]Z_Ø[Ô]ÛOZ�GINP×�U]Z�L"j]GdNO^RGIN[J"H"cIJ"Z�iRZ�N{Ô�HVÖrÔ]ÛOZ�\PNOZ0efÙ-Z�UXGdZ�NP×0Z�`�\<j�Z�UXj�GIN�iCLVNPL"^"GINO^j�\P×)Û j]l[j�Ô]Z�iCj�Ø¶L�^_U]HKÚ�GINO^9JKL"U]GIZ0Ôwl�H"Ö�L"ÓONOH"UXiCLVc2j]G�ÔX\PLKÔXGdH_NPjçGdN ÔXÛOZpj�lfj�Ô]Z�i Z�N[J[GIU]H_Nfái/Z�N{Ô�â_bSjÌL>UXZ�j]\OcdÔÌHVÖ-Ô]ÛPGIj�Ø_iRHf`fZ�U]NCLVÙPÙOcdGÞ×�LVÔ]GIH"NPj�ÛPLMJ"ZhÔXH�Ó<ZS`fZ�j]Gd^_NOZ�`RGINpj]\P×)ÛpLçÚ�LMlÔ]ÛPLVÔ/ÔXÛOZ�låL"U]Z�×�L"ÙPLVÓOcIZ�HVÖS`fZ�LVcIGdNP^àÚ�GdÔ]ÛøLà^_U]HKÚ�GINO^�N[\Oi�Ó<Z�U/H"Ö�JKLVUXGdH_\Pj/LVÓONOH_U]iCL"cj�GdÔ]\PLVÔ]GIH"NPj�GdNßL9`fGÞj]×�GdÙPcdGINOZ�`(Ö¤L"j]ÛOGdH_N¶â<êhÛPZ$H"NPcdl�^"Z�NOZ�U)LVc+j]H"cI\fÔXGdH_N�Ô]HpÔXÛOZ�j]Z$ÙPU]H_ÓOcdZ�iCjGIj$Ô]H j�lfj�Ô]Z�iCLVÔ]GÞ×�LVcIcIl GINP×�H"UXÙ<H_UXLVÔ]Zpj]HVÖ ÔwÚhLVUXZCÖ¤LV\OcdÔ/Ô]H"cIZ�U)LVN<×0ZpGIN{Ô]H�ÔXÛOZ�LVÙOÙOcIGÞ×�LKÔXGdH_NPj�âýSNOZ9LVÙPÙOU]H{L"×)Û GIj�Ô]H�\<j�ZpÓ<L"×)k[Ú�L"UX`ßZ�UXUXH"U>UXZ�×0HKJ_Z�UXl�Ô]Z�×)ÛONOGÞÿ_\PZ�j � j�\<×)ÛåL"j>UXH"cIcdÓ<L"×)k��Ú�ÛOGI×)Û ×�L"NàÓ-ZRiRL_`fZCLVcIiRH_j�ÔSÔXUXL"NPj�Ù<LVUXZ�N{Ô�ÖÝH_USÔXÛOZCLVÙOÙPcdGÞ×�LVÔ]GIH"N¶â��1NOÖÝH"U]Ô]\ONPLVÔ]Z�cdl�GdÔ>GIjNOHVÔ�^"Z�NPZ�U)LVc´ØV\Pj]\PLVcIcdlRÿ{\OGdÔ]Z1Z�e[Ù-Z�N<j�GIJ"Z_Ø_LVN<`CHVÖ ÔXZ�NCNOH"Ô�ávLVÙOÙOcIGÞ×�LVÓPcdZ�LVÔyLVcIc´â{êhÛOGÞj�GÞj�Ú�Û[lZ�iRÙOcIHKl{GINO^�LVÙOÙOcIGÞ×�LKÔXGdH_Nfávj�Ù-Z�×�G��<×�Z0eO×0Z�ÙfÔ]GIH"N�Û<LVNP`fcIGINO^9GÞj:NOHKÚ�L_ÒLMlfj�ÙOcÞLMl[GdNO^�LpiCL�wH_UU]H_cdZçGIN�ÓP\OGdcÞ`fGINO^C×0H_i/ÙPcdZ�e�`fZ�Ù<Z�NPÒLVÓPcdZ>LVÙPÙOcdGÞ×�LVÔ]GIH"NPj�â

eO×0Z�ÙfÔ]GIH"NøÛPL"NP`fcIGdNO^éUXZ�cIGIZ�jCH_NøÖÝZ�LKÔX\OUXZ�jRÖÝH_U�`fZ�×0cÞLVUXGdNO^ Z�ef×�Z�ÙfÔXGdH_NPjpGIN�`fG��-Z�U]Z�N{Ôj]×�H"Ù-Z�j � Z�eO×0Z�ÙOÔ]GIH"Né×0H_N_ÔXZ0e[ÔXj �çLVN<` L_j]j]Hf×0GÞLKÔXGdNO^�ÛPL"NP`fcIZ�U)j>Ú�G�ÔXÛ Ô]ÛOZ�i�ØrL"jçÚ�Z�cIcÌL"jçH_N


45

LVÓOGIcdGdÔwl�ÔXHçUXL"GIj]ZhZ0eO×0Z�ÙfÔ]GIH"NPj2L"NP`/ÙOUXH"ÙPL"^_LKÔXZ�ÔXÛOZ�i8H"\fÔ)j�GÞ`fZ�Ô]ÛPZ � NOZ�jwÔXZ�`��jX×0H_Ù<Z�j�âVT�H_j�ÔÙOUXL_×�ÔXGI×�LVcPcÞLVNP^"\PL"^"Z�j � GINP×0cI\P`fGINO^��_LMJKL�L"NP`pbSÒL��ÌL"jyÚyZ�cdc L"j�L�N[\Oi�Ó<Z�UyH"Ö+×0H"iRÙ-H"NOZ�N{ÔÔ]Z�×)ÛPNOH"cIH"^_GdZ�j � j]\P×)Û�L"j ��ÙPU]HKJ[GÞ`fZçÖÝZ�LVÔ]\OUXZ�jhÖÝH_U�ÛPL"NP`fcIGdNP^CZ0eO×0Z�ÙfÔ]GIH"NPj�â eO×0Z�ÙOÔ]GIH"NÛPLVNPÒcdGINO^�ÖÝZ�LKÔX\OUXZ�j:j�ÛOH_\OcÞ`�iCLKÔ)×)Û(Ô]ÛOZR×)ÛPL"UXL_×�Ô]Z�U]GÞj�Ô]GÞ×�j1H"Ö�Ô]ÛPZ/L"ÙOÙOcIGI×�LKÔ]GIH"N�Ô]H�Ó<ZR`fZ0áJ"Z�cIH"Ù-Z�`.LVNP`åÔ]ÛOZ�Z�N[J[GdUXH"NPi/Z�N{Ô�Ø?Ô]ÛOZ(`fZ�j�GI^"NåÙ<LVU)L"`fGI^"i�Ø¶ÔXÛOZ(×0H_i/ÙP\fÔXLVÔ]GIH"NPL"cyiRHf`fZ�cLVNP`åÔ]ÛOZ�cIL"NO^"\<LV^"Z��ÔXZ�×)ÛONOH_cdH_^"l�\<j�Z�`�� ·â�QSZ�J_Z�cIH"ÙOGINO^ j�Ù-Z�×�GIL"cdGIW�Z�`éZ0eO×0Z�ÙfÔ]GIH"N.ÛPLVNfá`fcdGINO^(iRZ�×)Û<LVNOGÞj�iCj:GÞj�LVN LVUXZ�L�HVÖhL�J"Z�UXl�L"×0Ô]GIJ"ZRUXZ�j]Z�LVU)×)Û¶â��OH_U>Z0eOLViRÙOcIZ"Ø¶L�N[\Oi$Ó-Z�UHVÖ+H_Ó��wZ�×0Ô�á·H"UXGdZ�N_ÔXZ�`CiRZ�×)ÛPLVNOGÞj]iRjyÚ�Z�UXZSÙOUXH"Ù-H_j]Z�`9LVUXH"\ONP`�� !��"OØ{LKÔ]H_iRGI×:L"×0Ô]GIH"N9Ó<L"j]Z�ì/Z�×)ÛPLVNPGIj]iCj�ÖÝH_UyÙOUXHKJ[GIÒGdNO^�Ö¤LV\OcdÔyÔXH"cIZ�U)LVNP×�Z � Z�eO×0Z�ÙOÔ]GIH"NpÛPL"NP`fcIGdNP^��ÌGdN�×0H"N<×0\OUXU]Z�N{Ôy×0H"áH"Ù-Z�U)LKÔ]GIJ"Zçj]l[j�Ô]Z�iCjhÚyZ�U]Z>`fZ�J"Z�cIH"Ù-Z�`�GIN�iRGÞ`#�!""j�â

ì<í%$ &�õ¶õ('Kú?ô�ö?ùfó�ô¤õ-ö*) +�ù�,�ñ[ú.- õ�/�ô¤û�ñ�îSö�0¶ô1'Mõ-ö32åñ[ö ó ,

T(H"ÓOGIcIZ$×0H[H"U)`fGINPLKÔXGdH_Nfá·ÓPL"j]Z�`9Z�N[J[GdUXH"NOiRZ�N_Ô)j�\Pj]\PLVcIcIlpÖÝH"cIcIHKÚALCÒLVÔXLVá·`fUXGIJ"Z�N(×�H{H_UXÒGdNPLVáÔ]GIH"N.iRHf`fZ�c4� 56�´Ø�\Pj]GdNP^ßL j�ÛPL"U]Z�`åÒLVÔXL j�ÙPL_×0Z87L�cÞL:9+GdN<ÒLOâ2b1^_Z�N{ÔXjR×�H{H_UXÒGdNPLVÔ]Z�GdN»L9¶GINPÒL$j]ÙPL_×0Z1Ó[lRGdN<j�Z�U�ÔXGdNO^<Ø_UXZ�L_`fGINO^�H"UyU]Z�iRHKJ{GINO^çÔX\OÙOcIZ�j�HVÖ+ÒLVÔXLçÖÝUXH"i L$ÓOcIL_×)k[Ó<H{LVU)`âê+\OÙPcdZ�jpLVUXZ�U]Z�Ô]UXGdZ�J"Z�`»L"×�×0H_UX`fGINO^ Ô]HåL"NÕL"jXj�Hf×0GÞLKÔXGdJ_Z�j]Z�L"UX×)Û+â�T(H"ÓOGIcIZ�×0H[H"U)`fGINPLKÔXGdH_NfáÓPL"j]Z�`9Z�N[J[GdUXH"NOiRZ�N_Ô)jÌÙPU]HKJ[GÞ`fZ�j�j�Z�J"Z�UXL"cOÔ]\PÙOcdZ>j]ÙPL"×�Z�j�LVNP`9Ú�LMlfjÌÖÝH"U�LV^_Z�N{ÔXjÌÔ]HR`fZ�NOHVÔXZLVNP`�L"×�×0Z�jXj�Ô]ÛPZ�`fG�� Z�UXZ�N{Ô�j]ÙPL"×�Z�j�â

b1iRH"NO^�iRH_ÓOGdcIZ�×0H[H_UX`fGINPLVÔ]GIH"Nfá·ÓPL"j]Z�`�Z�N[J[GdUXH"NPi/Z�N{Ô�Ø�Ú�Z�×�LVN>×�G�ÔXZ;9¶GIiRZ<� =>�´Ø�T�b�g�Y�� ?>�·ØLVNP`49?LVNPL@��A�´â9+GdiRZ � 9¶GINPÒLSGdN/L1iRH"ÓPGdcIZyZ�N[J{GIUXH"NOiRZ�N{ÔB� GIjrÚ�Z�cIc{j]\OGdÔ]Z�`>ÖÝH"UrÓ-HVÔ]Û�cdH_^"GÞ×�L"ci/H_ÓOGIcdGdÔwl9H"Ö2L"^"Z�N_Ô)j�LVNP`�ÙPÛ{lfj]GI×�LVciRH"ÓPGdcIG�Ôwl�HVÖ�`fZ�J{GÞ×0Z�j�â(9¶GIi/Z$i/H_ÓOGIcdZ�L"^"Z�N{Ô)j�×0H[H"U)`fGdáNPLKÔXZ�Ô]ÛOUXH"\P^"ÛC9¶GINPÒL>Ô]\OÙOcIZ�j]ÙPL"×�Z�jÌ\Pj�GINO^�LD�Pe[Z�`Cj�Z�ÔyH"Ö GIN{Ô]Z�UXL_×�Ô]GIH"NRÙOUXGIi/GdÔ]GIJ"Z�j�â�9¶GIiRZÔ]\OÙOcIZ�j]ÙPL"×�Z�j�LVÔy`fG��-Z�U]Z�N{Ôyj�GdÔ]Z�jÌL"U]Z�iRZ�UX^"Z�`�Ô]H"^_Z0ÔXÛOZ�UÌL"NP`RLV^_Z�N{ÔXj�L_×�×�Z�jXj�Ô]ÛOZ�i ÔXUXL"NPj�áÙPLVUXZ�N{Ô]cIløL"jpGdÖ>Ô]ÛPZ�løÚyZ�U]ZàcdHf×�L"c�â�T�b�gSY � T(H_ÓOGIcdZ b1^"Z�N{Ô�g�Z�L_×�ÔXGdJ_ZßY[ÙPL_×0Z�j �CGÞj9L"NH"Ó��wZ�×�Ô�á·H"UXGIZ�N{Ô]Z�È�{LMJKLKá·ÓPL"j]Z�`9Z�N[J[GdUXH"NOiRZ�N_Ô�ØOÚ�ÛOZ�U]Z4�{LMJKL/L"^"Z�N_Ô)j�×0H[H"U)`fGINPLKÔXZçÔ]ÛOUXH"\P^"ÛLVNéH"Ó��wZ�×�Ô]á´H_U]GIZ�N{ÔXZ�`ßÔ]\OÙPcdZ�j�ÙPL_×0Z:7L�cÞL�9+GdNP`PLOØr\Pj�GINO^àL�ÙOU]H_^"U)LViRiCLVÓOcIZCj�Z�Ô$HVÖ�ÙOUXGIi�áG�ÔXGdJ_Z�j�ârb T�bSg�YåL"^"Z�N{ÔR×�LVN.H"NOcIléL"×�×�Z�jXj�ÔXÛOZ�Ô]\OÙOcIZ�j�ÙPL_×0Z�L"jXj�Hf×0GÞLKÔXZ�` ÔXH�ÔXÛOZ�ÛPH_j�ÔÚ�ÛOZ�UXZ$GdÔ:GÞj:×0\OUXU]Z�N{Ô]cIl�Z�efZ�×0\OÔ]GINO^Pâ�9+L"NPLpGÞjSL"N�H"Ó��wZ�×�Ô]á´H_U]GIZ�N{ÔXZ�`F�{LMJMLVá´Ó<L"j]Z�`�Z�N[J[GIU]H_Nfái/Z�N{Ô�ØfÚ�ÛOGÞ×)Û�×�H"i�ÓOGdNPZ�jhÙOUXHKJ[GIj]GdH_NpHVÖ�×0H[H"U)`fGINPLKÔXGdH_N�L"NP`�j]Z�×�\OUXG�ÔwlpL"NP`9GÞj�`fZ�j�GI^"NOZ�`CÔXHU]\ON9H"NCÓ-HVÔ]Û�jwÔ)LVNP`PLVU)`R\Pj�Z�UHG�I�jÌ×0H_NONOZ�×�Ô]Z�`RÔ]H$Ô]ÛOZ ã N{Ô]Z�UXNOZ�Ô�LVN<`RÛPLVNPÒÛOZ�cÞ`p`fZ�J{GÞ×0Z�j�â9+LVN<L>LV^"Z�N{ÔXj�×�H{H_UXÒGdNPLVÔ]ZhÔXÛOU]H_\O^"ÛpL"NCH"Ó��wZ�×�Ô]á´H_U]GIZ�N{Ô]Z�`�Ô]\OÙOcIZ�j]ÙPL"×�Z@7LçcÞL49¶GINPÒLPØ"\Pj]GdNP^L$`fZ�Ö¤LV\OcdÔH�Pe[Z�`9j]Z0Ô�HVÖ+ÙOUXGIi/GdÔ]GIJ"Z�j�Ø{Ú�ÛOGÞ×)Û�×�LVNpNOZ�J"Z�U�ÔXÛOZ�cIZ�jXj�Ó-ZSZ�e[Ô]Z�N<`fZ�`9Ó{l/ÔXÛOZSÙPU]H"á^"U)LViRiRZ�U�â_b1N�LV^_Z�N{Ô�×�LVN9L_×�×0Z�j]jyÓ-HVÔ]Û�U]Z�iRHVÔ]Z:LVNP`pcdHf×�L"cPÔX\OÙOcIZ>j�ÙPL_×0Z�j�â�9+LVN<L$`fZA�PNOZ�jÙOU]H"Ô]Z�×�Ô]GIH"N�ÒH"iCLVGINPjhÖÝH_U�GINfÖÝH"UXiCLKÔ]GIH"N�L_×�×�Z�jXj�ØPL"NP`�ÙOUXZ�J_Z�N{ÔXjSLVÙOÙOcIGÞ×�LKÔXGdH_N(×0U)L"j]ÛOZ�j�Ó[l×0H"N<j�GÞ`fZ�UXGINO^�NPZ0ÔwÚ�H"UXkRÖ¤LVGIcd\OUXZ�j�L_jhNOH"UXiCLVcZ�J"Z�N{Ô)j�â

ì<íKJ L?ù�M?û¤óN) Oyõ-û¤ñ�'KùOörð"ñ�ô�ö.- õ�/�ô¤û�ñF&�õ¶õ('Kú?ô�ö?ùOó�ô¤õ-öP)Q+/ù�,�ñ[úøî:ö�0¶ôR'Kõ<ö32åñ[ö ó ,

LVUXcIlåÚyH_U]kéH_N»Ö¤LV\OcdÔ�á´Ô]H_cdZ�UXL"NP×0Z�GINø×�H[H"U)`fGdN<LKÔ]GIH"NOá´ÓPL_j�Z�`åZ�N{J[GIU]H_NOiRZ�N{ÔXj�ÖÝHf×0\<j�Z�`äH_N\Pj�GINO^(ÔXUXL"NPjXL"×�ÔXGdH_NPj�GINS9+GdNP`PLKá·cdGIk"ZpZ�N[J{GIUXH"NOiRZ�N{Ô�â+êhÚyH L"ÒÒG�ÔXGdH_NPLVcyÙOU]GIiRG�ÔXGdJ_Z�j�LVcIcdHKÚLVcIcÙOU]Hf`f\<×0Z�`9Ô]\PÙOcdZ�j�Ô]HRÓ-Z>U]Z�ÔXLVGINOZ�`p\ON{Ô]GIcÔXÛOZ:Ô]U)LVNPjXL"×0Ô]GIH"N�×�H"iRiRG�Ô)j�Ø[ÔXÛOZçÔ]\PÙOcdZ�j�LVUXZÔ]ÛOZ�N9L"×0Ô]\PL"cdcIl/L_Ò`fZ�`/Ô]H>ÔXÛOZ1ÔX\OÙOcIZSj]ÙPL"×�Z"â_g1Z0ÔXL"GdNPGdNO^�Ô]\OÙOcIZ�jyZ�N<j�\OUXZ�j�Ô]ÛOZ1Ô]U)LVNPjXL"×0Ô]GIH"Nj�Z�iRL"N{Ô]GÞ×�j�ØÓO\fÔ�U)LVGÞj�Z�jSÙPU]H_ÓOcdZ�iCj>LViRH"NO^(`fZ�Ù<Z�NP`fZ�N_Ô$L"^"Z�N_Ô)j�â¶b UXZ�cÞLKefZ�`�J"Z�UXj]GIH"NT� ��

?


46

ÙOU]HKJ[GÞ`fZ�jÌÔ]ÛPZçL"cdcH_UhNOHVÔXÛOGdNP^$ÔXUXL"NPj]L_×�ÔXGdH_N�j]Z�iCLVN{Ô]GÞ×�j�ØfLMJ"H_GI`fGINO^�ÙOU]H_ÓOcIZ�iCjhLViRH"NO^/`fZ0áÙ<Z�NP`fZ�N{ÔçLV^"Z�N{ÔXj�ØfÓ{l�UXZ�cÞLKefGdNP^RÔ]ÛOZ$LVÔ]H_i/GÞ×0GdÔwl9ÙPU]H_Ù<Z�U�Ôwl_âPê+\PÙOcdZ�j�L"U]Z�LMJKLVGIcÞLVÓOcIZ>GdiRiRZ0á`fGILVÔ]Z�cdlpGIN�Ô]ÛOZçÔX\OÙOcIZ�j�Ù<L"×0Z_ØfZ�J_Z�N�G�Ö�cÞLKÔ]Z�UhÔ]ÛOZçÔXUXL"NPjXL"×�ÔXGdH_N�`fH[Z�jhNOHVÔ�×�H"iRiRG�Ô�â

T(H"ÓOGIcIZ�×�H[H"U)`fGdN<LKÔ]GIH"NOá´ÓPL_j�Z�` Z�N[J[GdUXH"NPi/Z�N{ÔXj�ØrcIGIk"Z#UVIW9 L"NP`T�{LMJKL_Y[Ù<L"×0Z_Ø2`fZN�PNPZNOHVÔXG��<×�LKÔXGdH_NàiRZ�×)ÛPL"NOGÞj�iCj�â b�^"Z�N_Ô)jçL"j]k�ÔXH�Ó<ZRNOH"Ô]G��PZ�`àÚ�ÛOZ�NOZ�J"Z�UçL�iCLKÔ)×)ÛOGdNP^�Z�N_ÔXU]lGIj/Ú�UXG�Ô]Ô]Z�N.Ô]HßÔ]ÛOZ�j]ÙPL"×�Z"â2êhÛOZ�NOHVÔXG��<×�LKÔXGdH_NåiRZ�×)ÛPL"NOGIj]i�Ø2×0H"\PÙOcdZ�`éÚ�GdÔ]ÛäÔ]ÛOZ�NOHVÔXGdH_NHVÖçÔ]U)LVNPjXL"×0Ô]GIH"NPj�Ø�ÙOUXHKJ[GIÒZ�jpLåÖ¤LV\OcdÔ�á´Ô]H_cdZ�UXL"N_ÔpiRZ�×)ÛPLVNOGÞj]i�ØyÚ�ÛOZ�UXZàL"NÕZ�J"Z�N{Ô�×�LVÔX×)ÛOZ�UGIj$NOHVÔXG��PZ�` HVÖhiCLKÔX×)ÛPGdNO^(Z�N{Ô]UXGdZ�jçÖÝH"U$Ô]ÛOZ9Ò\OUXLVÔ]GIH"N HVÖ�Ô]ÛPZCÔ]U)LVNPjXL"×0Ô]GIH"N¶â ã N Ô]ÛOZ9×�L"j]ZHVÖX9+L"NPLOØÌÖ¤LV\OcdÔ�á´Ô]H_cdZ�UXL"NP×0ZàGIj�L"×)ÛOGIZ�J_Z�`øGINÜLVN L"j]l{N<×)ÛOU]H_NOH"\<jRÖ¤L"j]ÛOGIH"N¶ØÌÔ]ÛOUXH"\O^_ÛÕÔ]ÛPZNOHVÔXGdH_N9HVÖrZ�J_Z�N{ÔXj�â J"Z�N{ÔXjhLVUXZS`fZ�Ù<H{j�GdÔ]Z�`9GIN{Ô]H/Ô]ÛPZSÔX\OÙOcIZ>j�ÙPL_×0ZçLVNP`�UXZ0Ô]UXGIZ�J"Z�`CÓ[lCÔ]ÛPZ×0H"UXUXZ�j]Ù<H_NP`fGINO^9LV^_Z�N{Ô�þ GIiRi/Z�`fGÞLKÔ]Z�cdl_Ø G�ÖyÔ]ÛOZRLV^_Z�N{ÔSÚhL"jSÚ�L"G�ÔXGdNP^9ÖÝH_U�ÔXÛOZRZ�J"Z�N{Ô Y cILVÔ]Z�UH"N¶Ø GdÖyGdÔ>j]Z�L"UX×)ÛPZ�j�ÖÝH"UçG�ÔçcÞLKÔ]Z�UçGdNßÔ]ÛOZ/ÔX\OÙOcIZRj]ÙPL_×0Z!Y H_USNOZ�J"Z�U�Ø GdÖÌÔ]ÛPZ/L"^"Z�N{Ô>`fH[Z�j:NOH"Ô×�LVUXZ>LVÓ-H"\fÔhÔXÛOZ>Z�J_Z�N{Ô�â

Z HKÚ�Z�J"Z�U�Ø�L"cdcKÔXÛOZÌL"Ó<HKJ_ZriRZ�N_ÔXGdH_NOZ�`:iRZ�×)Û<LVNOGÞj�iCj ÖÝH_U+`fZ�LVcIGdNO^hÚ�GdÔ]ÛçÖ¤L"\Oc�Ô]á�ÔXH"cIZ�U)LVNP×�ZLKÔ�Ô]ÛPZ$LVÙOÙPcdGÞ×�LVÔ]GIH"N�cdZ�J"Z�c´ØPj]\�� Z�U�ÖÝUXH"i ÔXÛOZ>Ö¤L_×�Ô�Ô]Û<LKÔ�Z�ef×�Z�ÙfÔXGdH_N�Û<LVNP`fcIGINO^PØOGIN(GdÔXjhÔXUXLVá`fG�ÔXGdH_NPLVcçj]Z�NPj]Z"Øh×�L"NONOHVÔ�Ó<Z UXZ�LVcIGIW�Z�`¶â ã NPÒZ�Z�`¶ØhL"N�Z0eO×�Z�ÙfÔXGdH_N¶Ø�j]GI^"NPL"cdGINO^.L"NÜLVÓONPH"U]áiRL"c+Z�J"Z�N{Ô�ØOGIj1NOHVÔ�NPZ�×0Z�j]jXLVUXGIcdl9×�LV\O^_Û{Ô1H"U�ÛPL"NP`fcIZ�`Ø<NOZ�GdÔ]ÛOZ�USj]l[NP×)ÛOUXH"NOH_\Pj�cIlCH"USL"j]l{NOá×)ÛOU]H_NOH"\<j�cIl"Ø[Ó[l9LVN(L"^"Z�N{Ô�â

ì<í\[ &�õ-ö óA'KôR/]M+ó�ô¤õ-ö

êhÛOZ1ÖÝHf×0\<jÌH"Ö¶Ô]ÛOGÞjyÙPLVÙ-Z�U�GIjyH"N�`fGIjX×0\<j]j]GdNP^$L�NOZ�ÚÕiRH[ÒZ�c-HVÖ¶Z0eO×�Z�ÙfÔXGdH_NpÛPLVN<`fcdGINO^/j�\OGdÔ�áLVÓOcIZ1ÖÝH_UÌiRH"ÓOGIcIZSLVÙPÙOcdGÞ×�LVÔ]GIH"NPjy`fZ�J_Z�cIH"Ù-Z�`RGIN9×0H[H_UX`fGINPLVÔ]GIH"Nfá·ÓPL"j]Z�`/Z�N{J[GIU]H_NOiRZ�N{ÔXj�â[ýS\PU^"Z�NPZ�U)LVcrJ{GIZ�Ú ÛOZ�UXZ$GÞjSÔ]ÛPLVÔ:Z�ef×�Z�ÙfÔXGdH_NPjçLVUXZ�j]Ù<Z�×0GÞLVc � L"ÓONOH_U]iCLVc%��Z�J"Z�N_Ô)j1ÔXÛPLKÔ>×�L"NONOH"ÔÓ<Z�Ô]UXZ�LVÔ]Z�`ßL"jS\Pj]\PLVc � NPH"UXiRL"cK�1Z�J_Z�N{ÔXj�â eO×0Z�ÙOÔ]GIH"NPjSÛPLMJ"Z$Ô]H�Ó<ZF^_�`;â>bC×�LV\P^"Û{Ô:L"NP`ÛPLVNPÒcdZ�`Ø"ÔXÛOZ�lCL"U]Z1L"ÓONOH"UXiCLVcOZ�J"Z�N_Ô)jÌL"cdÚhLMlfj2NOZ�Z�`fGINO^�UXZ�L"×0Ô]GIH"N¶â[F:Z�NOZ�UXL"cdcIlRj�Ù-Z�L"k{GINO^<ØÔ]ÛOZ/LV^"Z�N{ÔSÙO\fÔ]Ô]GINO^pÔX\OÙOcIZ�GIN(ÔXÛOZ/j]ÙPL_×0Z$L"NP`�×0H_N{Ô]GIN{\PGdNO^9G�Ô)j�Ú�H"UXk�L_×�Ô)j1\ONPÒZ�U:Ú�U]H_NO^L"jXj�\OiRÙfÔXGdH_N�Ô]ÛPLVÔSGdÔXj�ÙOU]Hf×�Z�jXj�GINO^CÚ�H"\OcÞ`�^"H9j]iRH[HVÔ]ÛPcdl_â<êhÛOZ�ÙOU]H_ÓOcIZ�iCj�ÛOZ�U]Z$L"U]Z_þ<`f\PZÔ]H�`fZ�×0H"\PÙOcdGINO^>Z�J"Z�N{Ô�ÙOUXHf`f\P×�Z�U)jrÖÝU]H_i ×0H_NPj]\OiRZ�U)jrÔ]ÛOGÞj�LV^_Z�N{Ô�×0H_N_ÔXGdN[\OZ�j2GdÔXj2Z�e[Z�×0\fÔXGdH_NL"jRGdÖçNPHéZ0eO×0Z�ÙfÔ]GIH"N»ÛPL"jpÓ<Z�Z�NøUXL"GIj]Z�`¶Ø�j�HéGdÔpGIjpNOHVÔpUXZ�L_`fléÔ]HéÓ-Z�GIN[J"H"cIJ"Z�`åGINøÛPLVNfá`fcdGINO^<â?T(H_U]Z�HKJ"Z�U�Ø G�ÔR×�L"NécdZ�LMJ"Z/Ô]ÛOZ�cdHf×�LKÔ]GIH"N+â+êhÛOZ�UXZpGÞj�×0cIZ�L"U]cIlßL�NOZ�Z�` Ô]H�ÛPLMJ_Z � ÔXH`fl[NPLViRGÞ×�LVcIcIl�×0UXZ�LVÔ]Z>H_U�cdGINOk��LCcIHf×�LVc+ÛPLVNPÒcdZ�U�Ô]ÛPLVÔ�Ú�H"\OcÞ`�j�l[NP×)ÛOUXH"NPH"\Pj]cdlpÒZ�LVc+Ú�G�ÔXÛZ0eO×0Z�ÙfÔ]GIH"NPj�Ø�Ú�ÛOGdcIZßÔ]ÛOZ ÙOUXH[×�Z�jXj�Z�jpU)LVGÞj�GINO^åZ�eO×0Z�ÙOÔ]GIH"NPj�k"Z�Z�ÙÜ×�H"iRi$\ONPGI×�LKÔ]GINO^»L"j]l{NOá×)ÛOU]H_NOH"\<j�cIl"â ã NéL"`P`fG�ÔXGdH_N Ô]H�Ô]ÛPGIj�Ø+GdÔ$GÞj>GdiRÙ-H"U]ÔXL"N_Ô>ÔXH(iCLVk"ZCZ�eO×0Z�ÙOÔ]GIH"N ÛPLVN<`fcdGINO^�L_jcPZ0efGIÓOcdZ(L_jRÙ<H{j]j]GdÓPcdZ_âd�OH"UCZ�eOLViRÙOcIZ"ØrÔ]HéH!�-Z�U�ÖÝZ�LKÔX\OU]Z�j/Ô]Hé×)ÛPL"NO^"Z�`fl[NPLViRGÞ×�L"cdcIléÔ]ÛPZ`fGdUXZ�×0Ô]GIH"N�HVÖ�Z0eO×0Z�ÙfÔ]GIH"N�ÙOUXH"ÙPL"^_LVÔ]GIH"N¶â

e fÕÐ�ÊSÊ�Ò]Ê<gihEjlknmioqpsr

UßZßGdN{Ô]UXHf`f\P×�ZßLåj]iCLVcIcSÓPL"NOk[GdNP^.j�lfj�Ô]Z�i3ÔXÛPLKÔ�H"Ù-Z�U)LKÔXZ�jCÚ�GdÔ]Û i/H_ÓOGIcdZàL"^"Z�N_Ô)j9L"NPÙ]Z�ÿ_\PGdUXZ�j Ö¤L"\OcdÔ+Ô]H_cdZ�UXL"NP×0Z_Ø�LVN<`>Ú�ÛOGÞ×)Û>GIj+GdiRÙOcIZ�iRZ�N{ÔXZ�`>GIN>Ô]ÛPZH9+L"NPL�Z�N{J[GIU]H_NOiRZ�N{Ô�â�êhÛOGIjZ0eOLViRÙOcIZ1Ú�GIcdc-Ó<ZS\Pj]Z�`RÔXH$GIcdcI\Pj�Ô]U)LKÔ]Z1Ô]ÛOZ:`fGIjX×0\<j]j]GdH_NCH"NRÔXÛOZ�Ö¤L"\OcdÔ�á´Ô]H"cIZ�U)LVN{Ô2ÔXZ�×)ÛONOGÞÿ{\OZ�jGdN{Ô]Z�NP`fZ�`9ÖÝH_U�iRH"ÓOGIcdZ�×�H[H"U)`fGdN<LKÔ]GIH"NOá´ÓPL_j�Z�`CZ�N[J[GIU]H_NOiRZ�N{ÔXj�â

5


47

$í�ì O4trñ�uyùOö?ù î:ö�0¶ôR'Kõ-öv2åñ[ö óY[GdN<×0Zw9?LVNPLçÚ�GIcdc<j�Z�U]J_Z1L"j�LçÓPL_j�GÞj�ÖÝH_U�H"\OUy`fGIjX×0\<j]j]GdH_N�H_NRÖ¤LV\OcdÔ�ÔXH"cIZ�U)LVNP×�Z"ØKÚ�Z�Ú�GdcIc��PU)j�ÔZ0efÙOcÞLVGINøj]H"iRZF9+L"NPLßÖÝZ�LVÔ]\OUXZ�j�âHIyH"iRi$\PNOGI×�LKÔXGdH_NäGINPj]GI`fZ�L ÙPU]H_^"U)LVi�Hf×�×�\OURÔ]ÛOUXH"\P^"Ûj�l[NP×)ÛOUXH"NPH"\PjçiRZ0ÔXÛOHf`å×�L"cdcÞj�â Z HKÚ�Z�J_Z�U�Ø*9+L"NPL�ÙOUXH"^"U)LViCj>×�H"iRi$\ONPGI×�LKÔ]Z9\Pj�GINO^T^bBax�yzQ{�|~} x }� byiRZ�Ô]ÛOHf`/×�LVcIcÞj�âMêhÛOZ�j]Zh×�LVcIcÞj?L"U]Z�j�Z�×0\OUXZyGIN�ÔXÛPLKÔrÔ]ÛPZh×�LVcIcdGINO^SÙOU]H_^"U)LViAGIjr^_GdJ_Z�NL/ÖÝU]Z�j�Û��Na9H"Ó��wZ�×�Ô1Ú�ÛOZ�N�ÔXÛOZ$×�LVcIcGIj�GIjXj�\PZ�`ØPL"NP`�H"NOcIlCÔXÛOGIj�k"Z�l9×�L"N�Ó-Z�\Pj]Z�`�ÔXHCGdNfáÔ]Z�UXÙOUXZ0ÔRÔ]ÛPZ(i/Z�Ô]ÛOHf`äU]Z�ÙOcIl"â�êhÛOGÞjCiRZ�×)ÛPL"NOGÞj�iæÙPU]Z�J"Z�N{Ô)j�iCL"cdGÞ×0GIH"\Pj/ÙOUXH"^_UXL"iCj�ÖÝUXH"iGdN{Ô]Z�UX×�Z�ÙfÔXGdNP^/H_UhÔXL"i/Ù-Z�UXGINO^RÚ�G�ÔXÛ�iRZ�j]jXLV^_Z�jh`fZ�j�Ô]GINOZ�`9ÖÝH_U�HVÔXÛOZ�U)j�â

�W� �Ax��b�LVUXZç\Pj�Z�`�ÖÝH"U�j]Gd^_NPLVcIGINO^RU]Z�Ô]\OUXNOZ�`�JKLVcI\OZ�j1HVÖ2L"j]l{N<×)ÛOU]H_NOH"\<jyiRZ�Ô]ÛOHf`(×�L"cdcÞj�âêhÛOZ�l9L"U]ZçLVcÞj]H/\<j�Z�`pÖÝH_U1j�GI^"NPL"cdGINO^/Z�UXU]H_UXjyH"UhZ�ef×�Z�ÙfÔXGdH_NPj�ØOj�\P×)Û�L"j�þOj]Z�×0\PU]GdÔwlCJ[GdH_cILVÔ]GIH"N� NOH Ù<Z�U]iRGÞj]j]GIH"NéÖÝH_U/Lài/Z�Ô]ÛOHf`ä×�LVcIc%��Ø�H"U�Ô]ÛOZ�Ö¤L"×0Ô$ÔXÛPLKÔ/Ô]ÛOZ�UXZ�ÿ{\OGIU]Z�`éÙOUXH"^"U)LViëÛPL_ji/HKJ_Z�`â�G�UXZ0áv`fZN�<NOZ�`�Z�J"Z�N{ÔSÔwl{Ù-Z�jSGINP×0cI\P`fZ�Ô]ÛOH{j�Z_þPÔXÛPLKÔ:GdN<`fGI×�LKÔXZ$ÔXÛPLKÔçLpiRZ0ÔXÛOHf`�ÛPL_jU]Z�Ô]\OUXNOZ�` �R��!�� BY<Ô]ÛPLVÔ�ÔXÛOZ9iRZ0ÔXÛOHf`.×�LVcIcÌÛPL_j�Ö¤L"GdcIZ�`åÒ\OZpÔXH�Ô]ÛPZ9GIN{J_H"k_Z�`ÙOU]H_^"U)LVi ÛPLMJ[GINO^�iRHKJ_Z�` �1��!��6�� BYKNPHRL_×�×�Z�jXjyUXGI^"Û{Ô�ÛPLMJ[GdNO^/Ó-Z�Z�N�^"U)LVN{ÔXZ�`��>��6��!��6�!� �NY"ÔXÛOZ/Z0efZ�×�\fÔ]GIH"NßHVÖ2Ô]ÛPZ�iRZ0ÔXÛOHf`à×�H[ÒZ�ÛPL_j�^_Z�NOZ�UXLVÔ]Z�`(LVNàZ�e[á×0Z�ÙOÔ]GIH"N*Y?Ô]ÛOZ�U]Z�iRHVÔ]Z9ÙOcILVÔ�ÖÝH_U]ië^"Z�NOZ�U)LKÔXZ�` LVN � j�lfj�Ô]Z�iC��Z0eO×0Z�ÙfÔ]GIH"N¶ân��Na>b9L"U]Z9\Pj�Z�`Ô]H cdHf×)k H"Ó��wZ�×�Ô)j�L"NP`éZ�J_Z�N{ÔXj�â@�vx��1� � ��k"Z�lfj�L"U]Z�LV\fÔXH"iCLKÔXGI×�LVcIcdl ^"Z�NOZ�U)LKÔXZ�` ÖÝH_U�Z�L"×)ÛL"j]l{N<×)ÛOU]H_NOH"\<j�iRZ0ÔXÛOHf`.×�L"cdc´â; ;��¡�� ¢.k"Z�l[j/×�L"NåÓ-Z�^_Z�NOZ�UXLVÔ]Z�`éÓ[låj�Z�J"Z�U)LVcyÙOUXH"^"U)LViCj�ØÔ]ÛOZ�l L"cdcIHKÚ Ô]U)LVNPj�ÖÝZ�U�HVÖ�ÚyZ�cdcdá·k{NPHKÚ�N H_Ó��wZ�×0Ô�×0H_ÙOGIZ�j>ÔXÛOUXH"\O^_Û Ô]ÛOZ�\Pj�Z9HVÖ1Là×�H"iRiRH"Nk"Z�l_â

êhÛOZ$L"j]l[NP×)ÛOUXH"NOH_\PjhNOH"Ô]G��<×�LVÔ]GIH"N(HVÖ2Z�J"Z�N{Ô)j1GÞj�LKÔSÔ]ÛOZ$ÛOZ�L"U�Ô�H"Ö2Ô]ÛOZ�×0\OUXU]Z�N{Ô1Ö¤LV\OcdÔ�áÔ]H"cIZ�U)LVN<×0ZpiRZ�×)Û<LVNOGÞj�i ÙOUXHKJ[GIÒZ�` Ó[l89+LVN<LOâ?êhÛPZ9Ôwl[ÙOGÞ×�L"c�jX×0Z�NPLVUXGdH(GÞj$Ô]ÛOZ�ÖÝH"cIcdHKÚ�GINO^<þLVN�LV^_Z�N{Ô�Ù-Z�U]ÖÝH"UXiCj��PU)jwÔSL"N�L"j]l[NP×)ÛOUXH"NOH_\PjhiRZ0Ô]ÛPH[`à×�LVcIc´ØPGdÔ�Ô]ÛPZ�Nà×�H"N{Ô]GIN[\OZ�j�GdÔXjSZ0efZ�á×0\fÔXGdH_N � Ú�GdÔ]ÛPH"\fÔ>ÚhLVGdÔ]GINO^pÖÝH_U�ÔXÛOZ�iRZ�Ô]ÛOHf`�UXZ0ÔX\OUXN(��Ø H"N<×0Z/G�ÔçGIj:GIN{Ô]Z�UXZ�j�Ô]Z�`(GINàÛPLMJ[GINO^Ô]ÛOZ>iRZ0ÔXÛOHf`�U]Z�Ô]\OUXN¶ØfGdÔ�Ù-Z�U]ÖÝH"UXiRj�L"N �6£�¤!��]¥ ¦ Ø"Ú�ÛOGÞ×)Û�ÓOcIH[×)kfj�ÔXÛOZ�LV^_Z�N{Ô�\ON{Ô]GIc¶Ô]ÛPZi/Z�Ô]ÛOHf`àÛPL"jSU]Z�Ô]\OUXNOZ�`â-êhÛPZ$UXZ0Ô]\PU]Nà×�LVN�Z�G�ÔXÛOZ�U:Ó-Z$ÔXÛOZ�Z�efÙ<Z�×�Ô]Z�`(UXZ�j]\Oc�Ô�Ø H"USL"N¨§�Z�e[á×0Z�ÙOÔ]GIH"N�©�Z0efÙOcÞLVGINOGINO^�Ô]ÛOZCÙPU]H_ÓOcdZ�i�â*9+LVN<L�L"cdcIHKÚ1jçj�\<×)ÛßZ�ef×�Z�ÙfÔXGdH_NPj:Ô]H�Ó-ZC^"Z�NOZ�U)LKÔXZ�`ÖÝU]H_i L�U]Z�i/H"Ô]Z/ÙOcÞLKÔ�ÖÝH_U]i�ØÛOHKÚ�Z�J_Z�USÔ]ÛOZ �!£�¤!��]¥ ¦ ×�H"iRiCLVNP`ßi$\Pj�Ô>Ó<ZCcIHf×�L"c�ØG´â Z_âdØLVN�L"^"Z�N_Ô�Ô]Û<LKÔhi/HKJ_Z�jyi$\Pj�Ô1`fZ�cIZ�^{LKÔXZ�ÔXÛOZ �!£�¤!��]¥ ¦ ÔXH/L"N�LV^_Z�N{Ô�Ô]ÛPLVÔ�j�ÔXLMlfjyGdN�Ô]ÛPZÙOcILVÔ�ÖÝH_U]i ÖÝUXH"i Ú�ÛOZ�UXZ:Ô]ÛOZ�×�LVcIcÛPL"jhÓ-Z�Z�N�GIjXj�\PZ�`â

$í%$ - ù�'�ª-ñ{ó�«>û�ùOð"ñßî�ï¶ù�2éòrû�ñ�¬PuÌùOörù®�ñ�,�ô¤ü-ö�?GI^"\PU]ZF�pj]ÛOHKÚ1j>L(\Pj]Z�U�Ø¶Ú�GÞj�ÛPGdNO^�ÔXH�L"×�ÿ_\PGdUXZpj�H_iRZCÙOU]Hf`f\<×�Ô�â Z ZpcÞLV\ON<×)ÛOZ�j�L�ÓP\Ol"Z�ULV^"Z�N{Ô�ÔXÛPLKÔRÚ�GdcIc�UXH_LViëÔXÛOZ ã N_ÔXZ�UXNOZ0ÔCj]Z�LVU)×)ÛOGINO^�ÖÝH_U/L j]Z�cIcdZ�URL"^"Z�N_ÔRH6� Z�UXGINO^�ÔXÛOZ�U]Z�áÿ_\PZ�j�Ô]Z�` H_Ó��wZ�×0Ô�â+êhÛPZpÓO\Ol_Z�U$L"NP` j�Z�cdcIZ�U$L"^"Z�N_Ô)j>Ú�GIcdcyi/Z�Z0Ô$GINåLVN Z�cdZ�×�Ô]UXH"NPGI×RiCLVUXk"Z�ÔÙOcIL_×0Z_Ø�Ú�ÛOZ�U]Z�ÔXÛOZ�l:Ú�GdcIc"Z�eO×)ÛPLVNO^_Z2GdNOÖÝH"UXiRLVÔ]GIH"NçUXZ�^_L"UXÒGdNO^hÙOUXHf`f\P×0ÔXjÔXÛPLKÔ+Ô]ÛOZ�GdU?U]Z�j�Ù-Z�×0áÔ]GIJ"Z�\Pj]Z�U)j�`fZ�j�GIU]ZçÔXHpÓO\Ol�H"U1j]Z�cIc´â L_×)Û(LV^"Z�N{ÔhGÞj1Z�ÿ{\OGdÙPÙ<Z�`�Ú�G�ÔXÛ�LVN(Z0á·ÙO\OU)j]Z:ÛPH"cÞ`fGdNP^j�H_i/ZhLViRH_\ON{ÔrH"ÖPZ�cIZ�×0Ô]UXH"NOGÞ×ÌiRH_NOZ�l_â ã Ö<Ô]ÛOZyÔwÚ�H:L"^"Z�N{Ô)j+ÛPLMJ_ZÌiCLKÔ)×)ÛOGINO^SUXZ�ÿ{\OZ�jwÔ)j�Ø�ÔXÛOZ�lU]Z�L"×)ÛßL"NßL"^"UXZ�Z�iRZ�N_Ô � ÔXÛOZCÙOUXHf`f\P×�Ô>GÞjçÓ<H[H_k"Z�`¶Ø L"NP` L�×�H"N{Ô]U)L"×0Ô:GÞj>×0H_NP×0cI\P`fZ�`��Ø¶L"NP`Ô]ÛOZ1Ù<LMl{iRZ�N_Ô�GÞj�ÔXÛOZ�NCUXZ�L"cdGIW�Z�`�Ó[l$Ô]U)LVNPj�ÖÝZ�UXU]GINO^>j]H"iRZ�iRH"NOZ�l�ÖÝUXH"i Ô]ÛOZ�Z�á´ÙO\PUXj]Z�HVÖ Ô]ÛPZÓO\Ol"Z�U>LV^"Z�N{Ô:`fGIU]Z�×�ÔXcdl�ÔXH�ÔXÛOZ/Z0á·ÙO\OU)j�Z/HVÖ�ÔXÛOZCj�Z�cdcIZ�U>L"^"Z�N{Ô�â ã NßÔ]ÛOGÞj>×�L_j�Z$Ô]ÛOZRZ�á´ÙO\PUXj]ZL"×�Ô)j�L_j1×�L_j�Û(iRH"NPZ�l"ØPÔ]ÛOZ�U]Z$GIj�NOHpNOZ�Z�`�Ô]H�L"j]k9ÖÝH_USLRÓPL"NOk�×�Z�U]Ô]G��<×�LVÔ]GIH"N¶â ã Ö�Ô]ÛOZ�ÙPLMl{ái/Z�N{Ô�Ö¤L"GdcÞj�Ø[Ô]ÛOZ�N9ÔXÛOZ>LV^"UXZ�Z�iRZ�N{Ô�Û<L"jyÔ]H/Ó<Z�×�LVNP×�Z�cIcdZ�`ØfLVNP`9Ô]ÛPZçj]Z�cIcIZ�U�LV^_Z�N{Ô�UXZ�cIZ�L_j�Z�jÔ]ÛOZ(ÙOUXHf`f\P×0Ô�â�b1NøZ�á´ÙO\PUXj]Z�GIjRGIiRÙOcdZ�iRZ�N{Ô]Z�`äÓ[l.L"N»L_Ò`fGdÔ]GIH"NPL"c1LV^_Z�N{ÔRÔ]ÛPLVÔRÛ<LVNP`fcIZ�j

¯


48

Ô]ÛOZCLViRH_\ON{Ô:H"ÖÌiRH"NOZ�l(HVÖÌÔXÛOZRZ0á·ÙO\OU)j�Z_Ø-L_×�×�Z�jXj�ÙOUXGIJ{GIcIZ�^"Z�j�Ø`fZ�Ù<H{j�GdÔ>LVNP`àÚ�G�ÔXÛP`fU)LMÚ�L"cH"Ù-Z�U)LKÔ]GIH"N<j�â

ã N�ÔXÛOGÞj�jX×0Z�N<LVUXGdH<Ø[Ô]ÛOZ�ÓP\Ol"Z�U�LV^_Z�N{Ô1×�LVN(Ó-Z�Z�G�ÔXÛOZ�U�L"cdH_NOZ>H"U1×�H"iRÙ-H_j]Z�`�HVÖ�j]Z�J"Z�UXL"cLV^"Z�N{ÔXjUXH_L"i/GINO^hÔXÛOZ ã N{Ô]Z�U]NOZ�Ô?j]Gdi�\Oc�Ô)LVNOZ�H"\Pj]cIl"â ã ÔriRLMlSÓ<Zy`fG�°p×�\Oc�ÔrH"U?Z�J"Z�NçGdiRÙ-H_jXj�GIÓOcIZÖÝH"U�ÔXÛOZ9\<j�Z�U$ÔXHà×0H_N_Ô)L"×0Ô�Ô]ÛOZ�ÓO\Ol_Z�U/LV^"Z�N{Ô$H"U>ÖÝH_U$ÔXÛOZ9ÓP\Ol"Z�U�LV^_Z�N{Ô�ÔXHß×0H_N{ÔXL"×0Ô�Ô]ÛPZLV^"Z�N{ÔXj�ÒGIj�Ô]UXGdÓP\fÔ]Z�`�Ú�H"UXcI`[á·Ú�GÞ`fZ"â ã NP`fZ�Z�`ØLpiRH"ÓPGdcIZ ã G j]×)ÛOZ�iRZ$Z�N<LVÓOcIGdNP^pÔ]H�×0H_N{ÔXL"×0Ôi/H_ÓOGIcdZçLV^_Z�N{ÔXjyGdUXUXZ�j]Ù<Z�×�Ô]GIJ"Z�cdl/HVÖ+Ô]ÛOZ�GdUhÙ-H_j]G�ÔXGdH_N9GÞj�ÒG�°p×0\Pc�Ô�Ô]HR×0H_NPj�GÞ`fZ�UyÚ�ÛOZ�N�L"^"Z�N{Ô)jNOZ�GdÔ]ÛOZ�U1k[NOHKÚ�Z�L"×)Û�HVÔ]ÛPZ�U�NOH_U�ÙPLVU]Ô]GÞ×0GIÙPLKÔXZçGdN�Ô]ÛPZ�j]L"i/Z>L"ÙOÙOcIGI×�LKÔ]GIH"N+â

±;²�³�´µ�´(¶ ��u¸·�qXtH¹+��°XqS¸�º_��>²_��q

êhÛOGIj�Z0eOL"i/ÙPcdZ�j�×�H"NPj]GIj�ÔXj$HVÖ1ÔwÚ�H�iCLVGINT9?LVNPLàLV^"Z�N{ÔXj�þ¶Ô]ÛPZ�ÓO\Pl"Z�URLVN<` Ô]ÛOZ�j]Z�cIcdZ�ULV^"Z�N{ÔSÔXÛPLKÔ>Ú�H"UXk�H_NàÓ-Z�ÛPL"c�Ö�HVÖyÔ]ÛOZRÓO\Ol_Z�U�ØLVNP` j�Z�cdcIZ�U:UXZ�j]Ù<Z�×�Ô]GIJ"Z�cdl_â+ýSNP×0ZRÓ-HVÔ]ÛßÔ]ÛPZÓO\Ol"Z�U�LVNP` j]Z�cIcdZ�UçL"^"Z�N_Ô)jçÛPLMJ"Z/UXZ�L"×)ÛPZ�`(ÔXÛOZRiCLVUXk"Z0Ô>ÙOcÞL"×�Z"Ø¶L�j]Z�ÿ{\OZ�N<×0Z/HVÖ�ÒLKÔ)L�Z�e[á×)ÛPLVNO^_ZçH[×�×0\OU)j�Ô]ÛPU]H_\O^"Û�Ô]ÛPZ>i/Z�j]jXLV^_ZçÓ<H{LVU)` � GdN�ÔXÛOZ�×�L_j�ZçÚ�ÛOZ�U]ZçÔXÛOZ�UXZ>GIj1NOHCZ�UXU]H_U �0þÔ]ÛOZçÓO\Ol_Z�U � j�Z�cdcIZ�UB��LV^"Z�N{Ô�GINPj]Z�U]ÔXjhL/ÓO\Ol[GdNP^ � j�Z�cdcIGINO^��yUXZ�ÿ{\OZ�j�ÔhU]Z�j�Ù-Z�×0Ô]GIJ"Z�cIlCGIN9ÔXÛOZçÔ]\fáÙOcdZ:j�Ù<L"×0Z_â_êhÛOZSÓO\Ol_Z�UyL"^"Z�N_ÔyU]Z�Ô]UXGdZ�J"Z�j�Ô]ÛOZ:j�Z�cdcIGINO^�UXZ�ÿ{\OZ�j�Ô�L"NP`RÙOUXH"Ù-H_j]Z�jyL�×0H_N_ÔXUXL_×�Ô�ØÚ�ÛOGI×)Û�GÞj1L"×�×0Z�ÙfÔ]Z�`�Ó[l9Ô]ÛOZ$j]Z�cIcIZ�U�âPêhÛOZ>GIN_ÔXZ�U)L"×0Ô]GIH"N�Z�NPÒj�Ú�G�ÔXÛ�Ô]ÛOZ�Ù<LMl{iRZ�N_Ô�ØOG´â Z_âdØOÓ[lÔ]U)LVNPj�ÖÝZ�UXU]GINO^/iRH"NOZ�lCÖÝU]H_i Ô]ÛPZ>ÓO\Ol"Z�U�Z0á·ÙO\OU)j�Z:ÔXHRj]Z�cIcIZ�U�Z0á·ÙO\OU)j]Z"â

UßZ�Ú�GIcIc+NOHKÚ ×0H_NPj�GÞ`fZ�UhÔ]ÛOUXZ�Z>Ôwl[Ù-Z�j�HVÖ�Z�UXU]H_UXj�þOj�lfj�Ô]Z�i Z�UXUXH"U�ØOLVÙOÙOcIGÞ×�LKÔXGdH_N�Z�UXU]H_UXj�ØNOZ0ÔwÚ�H"UXk.Ö¤L"GdcI\OUXZ�j YyL"NP`�j]Z�Z�ÛOHKÚ ÔXÛOZ�lÕ×�LVNÕÓ-ZßÛPL"NP`fcIZ�`ÕÚ�GdÔ]ÛPGdNÕÔXÛOZ ×0\OUXU]Z�N{ÔE9+L"NPLi/Hf`fZ�c�þ

»½¼ a>bB�¾�N¿À� |B|~}| â{êhÛOZ�cdHf×�LVcOH_U�U]Z�iRHVÔ]ZhÙOcÞLKÔ]ÖÝH"UXi ^_Z�NOZ�UXLVÔ]Z�jrL"NCZ�UXU]H_U�ØMZ_â ^<âdØKÔXÛOZ�×�H[ÒZ×�L"NONOHVÔ�Ó-Z>Z0efZ�×�\fÔ]Z�`ØfÔXÛOZ�×�L"cdcIZ�`�LV^_Z�N{Ô�ÛPL"jhiRHKJ"Z�`ØfZ0Ô)×Vâ

»iÁ }�z ^_�ÂWÃ!Ã�_Ä� z ^�Å� } x � |B|~}6| bNÆ��PH"U�GINPjwÔ)LVNP×�Z"ØfÚ�Z>×�LVN�iRZ�N{Ô]GIH"N+þÇ Ô]ÛPZ�UXZ>GIjhNOHCH!�-Z�U�iCLKÔX×)ÛPGdNO^/ÔXÛOZ>U]Z�ÿ{\OZ�j�Ô YÇ Ô]ÛPZ�UXZ�GÞjyL>ÓP\O^$GINCÔ]ÛPZSj]Z�cIcdZ�UyLV^_Z�N{Ôy×�H[ÒZ"þ{G�Ô�GIjÌGdiRÙ-H_jXj�GIÓOcIZ1Ô]H�U]Z�L"×)ÛCLVN�LV^"UXZ�Z�áiRZ�N{Ô1H"UhÔXHCL"×�×�Z�jXj�Ô]HRZ0á·ÙO\OU)j]Z!Y

Ç Ô]ÛPZ>ÓO\Ol"Z�U�Z0á·ÙO\OU)j�Z>`fH[Z�jhNOHVÔ�×�H"N{ÔXL"GdN�j�\�°C×�GdZ�N{ÔhiRH_NOZ�l�YÇ Ô]ÛPZ�ÓO\Ol_Z�UyZ0á·ÙO\OU)j�Z�ÒH{Z�jÌNPHVÔyÙPU]Z�j�Z�N_Ô�j�\�°p×�GdZ�N_Ô�ÙOUXGdJ[GIcdZ�^"Z�j�ØVZ_â ^<âdØ[L�×0H_N��P^_\OUXLVáÔ]GIH"N�Z�U]UXH"U�`fH[Z�jhNPHVÔ1LV\fÔXÛOH"UXGIW�ZçiRH"NOZ�lCÔ]HCÓ-Z>Ú�G�ÔXÛP`fU)LMÚ�N9ÖÝUXH"i=Ô]ÛOZ>Z�á´ÙO\PUXj]Z"â

È


49

»ÊÉ �KbB� | �1Ë � �¾� ¢FÂHÃ!Ã�_Ä� z ^�Å� } x � |B|~}| bAÆ�YfZ�J"Z�UXL"c�L"^"Z�N_Ô)j$Ú�H"UXk ×0H[H"Ù-Z�U)LKÔXGdJ_Z�cIl"ØrZ"â ^PâIØ+ÔXHÓO\Ol�j�Z�J"Z�U)LVc GdÔ]Z�iRj1HVÖ+ÔXÛOZ�jXLViRZ�j�Z�U]GIZ�j�â ã N�Ô]ÛOZ�×�L"j]Z:H"ÖrL"N�Z�U]UXH"U�Ø{Ô]ÛOZ�U]ZçGÞj1L/NOZ�Z�`ÖÝH"U1LR×0H_cdcIZ�×0Ô]GIJ"ZçUXZ�×0HKJ_Z�UXlRHVÖrÔ]ÛOZ>Z�U]UXH"U�â

»ÊÌ �A��` }6|~Í v^�%_ ��| �BbAÆ-êhÛOZ�U]Z>LVUXZ>×0H_i/i�\ONOGÞ×�LVÔ]GIH"N�Ö¤LVGIcd\OUXZ�jhÓ-Z0ÔwÚ�Z�Z�N9ÔXÛOZ>ÓO\Ol_Z�U1L"NP`j�Z�cdcIZ�U1L"^"Z�N_Ô�ÙOcÞLKÔ]ÖÝH"UXiCj�ØfH_U�Ó-Z0ÔwÚ�Z�Z�N�Ô]ÛOZ�L"^"Z�N{Ô�ÙOcÞLKÔ]ÖÝH"UXi LVNP`�GdÔXj�\Pj]Z�U�â

ã NåÔ]ÛPZ�×�L"j]Z�H"ÖSj�lfj�Ô]Z�i�Z�UXU]H_UXj�Ø¶ÔXÛOZ�cIHf×�L"c�H_U�UXZ�iRH"Ô]Z#9+LVN<L�ÙOcÞLKÔ]ÖÝH"UXi�^"Z�NPZ�U)LKÔ]Z�jLVNåZ�J"Z�N{Ô�Ø?G´â Z_âdØrGdÔ�GINPj�Z�U�Ô)j�ÔXÛOZ�×0H"UXUXZ�j]Ù<H_NP`fGINO^�Ô]\OÙPcdZ�GdN.Ô]ÛOZ�j�ÛPL"U]Z�` iRZ�iRH"UXléj�ÙPL_×0Z_âêhÛPLVNOkfjyÔ]H/ÔXÛOZçk"Z�l_Ø{Ô]ÛOZ:Ô]\PÙOcdZçGÞjyÔ]ÛOZ�N�UXZ0ÔXU]GIZ�J_Z�`CÓ[lRÔXÛOZ>LV^"Z�N{ÔyÔXÛPLKÔ�ÚhL"j�Ú�L"G�ÔXGdNP^$ÖÝH_UÔ]ÛOZ�×�H"UXU]Z�j�Ù-H"NPÒGdNO^/H"Ù-Z�U)LKÔXGdH_N¶â

ã N�Ô]ÛPZ/×�L"j]Z$HVÖ�LVÙOÙOcIGÞ×�LKÔXGdH_NàZ�U]UXH"U)j�ØPZ"â ^PâIØ<ÔXÛOZ�UXZ/GIjçLVNßZ�UXU]H_US`f\PU]GINO^pÔXÛOZRÙPLMl[iRZ�N{Ô`f\OZ�ÔXH�GdN<j�\�°p×�GdZ�N_Ô�iRH_NOZ�l_ØVÔ]ÛPZ1ÓO\Ol_Z�UÌL"^"Z�N{Ô�GINPj]Z�U]ÔXj�LçÙPLMl[iRZ�N{Ô2Ö¤L"Gdc<Z�J"Z�N{Ô�ØVUXZ0ÔXU]GIZ�J_Z�`Ó{låÔ]ÛOZ�j]Z�cIcdZ�UpLV^_Z�N{Ô�ÔXÛPLKÔpÚhL"jRÚhLVGdÔ]GINO^ßÖÝH"URÔXÛOZ(ÙPLMl[iRZ�N{Ô�â�êhÛOZ(cÞLKÔ]Ô]Z�Up×�LVN<×0Z�cÞj/Ô]ÛPZÔ]U)LVNPjXL"×0Ô]GIH"N¶Ø¶L"NP` U]Z�GdNPj]Z�U]ÔXjSÔXÛOZ9j]Z�cIcdGINO^�U]Z�ÿ{\OZ�j�Ô�âP�rGINPLVcIcIl"ØÔXÛOZCÓO\Ol_Z�U�LV^_Z�N{Ô>GdNOÖÝH"UXiRjÔ]ÛOZSÓO\Ol"Z�UyGINCÔXÛOZSH_U]GI^"GINPL"cOÙOcÞLKÔ�ÖÝH_U]i8ÔXÛPLKÔhLVNpZ�U]UXH"U�Hf×�×0\OUXU]Z�`C`f\OUXGdNP^�Ô]ÛPZ�ÙPLMl[iRZ�N{Ô�Ø{GdÔGdNPj]Z�U]ÔXj�ÔXÛOZ�×0H_U]UXZ�j]Ù-H"NP`fGINO^/Z�J_Z�N{Ô�GdN�Ô]ÛPZ>H"UXGd^_GdNPL"c ÙOcILVÔ�ÖÝH_U]i�â

êhÛOZÌ×�L_j�ZÌHVÖP`fGÞjwÔXU]GIÓO\fÔXZ�`�L"ÙOÙOcIGI×�LKÔXGdH_NPj¶Z�U]UXH"U)jGÞjÔ]ÛPZyiRH_j�Ô+GIN{Ô]Z�UXZ�j�Ô]GINO^1H_NOZ"â ã NP`fZ�Z�`ØÔ]ÛOZSÙOU]H_ÓOcIZ�i8ÛOZ�UXZ1GÞj�ÔXH�U]Z�L"×)Û¶Ø_Z�J_Z�NpL"j]l[NP×)ÛOUXH"NOH_\Pj]cdl_ØKÓO\fÔyNPZ�×0Z�j]jXLVUXGIcdl_Ø"LV^_Z�N{ÔXjÌÚ�ÛOH_j]ZcdHf×�LVÔ]GIH"NßGIjçNOH"Ô>k{NPHKÚ�N¶â¶b8Ù<H{j]j]GdÓPcdZCLVÙPÙOU]H{L"×)Û(ÔXH�U]Z�LVcIGdW�GdNO^9Ô]ÛOGÞj>GINÎ9?LVNPL�GÞj:ÖÝH"UçÔ]ÛPZLV^"Z�N{ÔXjRÔXHåLV^"UXZ�Z�\OÙ-H"N�Lé×�H"iRiRH"NøÙOcÞLKÔ]ÖÝH"UXi Ú�ÛOZ�U]Z(Z�J"Z�N_Ô)j�ØÌU]Z�cILVÔ]Z�`äÔXHåLVÓONOH_U]iCL"cj�GdÔ]\PLVÔ]GIH"NPj�ØPL"U]Z>j�Ô]H"UXZ�`¶âPb�Ö ÔXZ�U�ÔXÛPLKÔ�Ó-HVÔXÛ�Ô]ÛOZ4��\Ol_Z�U�L"NP`�Ô]ÛOZ$YfZ�cIcdZ�U�LV^_Z�N{ÔXjhcIZ�LMJ_ZçL"NL"Ò`fGdÔ]GIH"N<LVcPL_j]j]GIj�ÔXL"N{ÔÌLV^"Z�N{Ô�GINRÔ]ÛPGIjÌÙOcILVÔ�ÖÝH_U]i�Ø"Ú�ÛPH_j]Z�U]H_cdZhGÞj2Ô]H>H_ÓPj]Z�UXJ"Z�Ô]ÛOH{j�Z�Z�J"Z�N{ÔXj�ØLVNP`9Ô]HCGINfÖÝH"UXi ÔXÛOZ�GIU1UXZ�j]Ù<Z�×�Ô]GIJ"Z>L"^"Z�N{Ô)j�â

�?GINPL"cdcIl"Ø?Ô]ÛOZÏ9+L"NPL(iRHf`fZ�chLVcIcdHKÚ1j$NOZ0ÔwÚ�H"UXkßÒGIjX×0H_NONOZ�×0Ô]GIH"NPj�Ô]HßÓ<Z�ÛPLVNPÒcdZ�`éGdNäLJ"Z�UXl�j�GIiRGdcÞLVUSÚ�LMl_âPb1^_Z�N{ÔXj:LVUXZ>GdNOÖÝH"UXi/Z�`(HVÖ2ÔXÛOZ�Ö¤L"GdcI\OUXZ>Ô]ÛPU]H_\O^"Û(Z�J"Z�N{Ô)j�Ø LVNP`�Z�G�ÔXÛOZ�UÚ�L"G�Ô�ÖÝH_U1Ô]ÛPZ$LMJKLVGIcIL"ÓOGdcIGdÔwlpHVÖ�Ô]ÛPZ$×0H_NONOZ�×0Ô]GIH"N¶Ø<H"U�×�H"N{Ô]GIN[\OZçÔ]ÛPZ�GIU�Z0efZ�×0\fÔXGdH_N�\PN_ÔXGdc?Ô]ÛPZ×0H"NPNOZ�×0Ô]GIH"N�GIj�\PÙ¶ØOH"U�`fZA�PNOGdÔ]Z�cdl�^"GIJ"Zç\OÙ¶â

$íKJ Ð�ö?ùOû1Ñ*,�ô�,9+LVN<L�ÔXU]Z�LKÔXjyZ0eO×�Z�ÙfÔXGdH_NPjhL"jyÔ]ÛOZ>×�H"N[J"Z�N_ÔXGdH_NPLVcPÔ]\OÙPcdZ�j�LVNP`9H6� Z�U)jyÓ<L"j]GI×SÙOUXGdiRGdÔ]GIJ"Z�jyÖÝH_UGdiRÙOcIZ�iRZ�N{ÔXGdNO^:Z0eO×�Z�ÙfÔXGdH_N>ÛPLVNPÒcdGINO^Pâ>��\fÔ�ÚyZyÛPLMJ"Z2ÖÝH_\ONP`çÔXÛPLKÔrÔ]ÛPZ�UXZÌGÞj?×�cdZ�LVUXcdlçL�j]ÙPL"×�ZÖÝH"U�Z0efÙPL"NP`fGINO^�ÔXÛOZ�j]Z�ÖÝZ�LVÔ]\OUXZ�j?Ô]HçÛOZ�cdÙRLVÙPÙOcdGÞ×�LVÔ]GIH"N�ÙOU]H_^"U)LViRiRZ�U)j¶GIN/ÒZ�J"Z�cdH_ÙOGINO^�Ö¤L"\OcdÔÔ]H"cIZ�U)LVN{ÔÌL"ÙOÙOcIGI×�LKÔ]GIH"N<j�GdNpL�jXLKÖÝZ�U�LVNP`RcIZ�jXj2Z�U]UXH"U]á´ÙPU]H_NOZyÚhLMl"â6�rGIUXj�ÔÌH"Ö L"cdc´Ø�9?LVNPLçLVcIcIHKÚ1jZ0eO×0Z�ÙfÔ]GIH"NPjÔ]H1Ó-Z�cIZ0Ö Ô?\PNOÛPLVN<`fcdZ�`:áPÚ�ÛOGÞ×)Û>GIj+×0cIZ�LVUXcIl�Z�UXUXH"U]á´ÙOUXH"NPZrL"NP`ç×�LVN>Û<LMJ"Z2j�Z�U]GIH"\<jZN� Z�×�Ô)j�H_N j]lfjwÔXZ�i�U]Z�cdGÞLVÓOGIcIG�Ôwl_â?Y[Z�×�H"NPÒcdl_ØÔ]ÛOGÞj�iRHf`fZ�c�iRG�efZ�j$NOH"UXiCLVc�L"NP` LVÓONOH_U]iCL"ccPHKÚ1j�HVÖ�×�H"N{Ô]UXH"c¶L"NP`(×0Hf`fZ_ØPLVNP`(ÒH{Z�j�NOH"ÔSj�Z�ÙPLVU)LKÔXZ�j�\�°C×�GdZ�N{Ô]cIlpÔ]ÛPZ�NOH"UXiCLVc+j]lfjwÔXZ�iÓ<Z�ÛPLMJ[GdH_\OU/ÖÝU]H_i�Ô]ÛOZ�L"ÓONOH_U]iCLVc�H"NPZ�á�Ú�ÛPGI×)Û»GIjCÔ]ÛOZ�iCLVGINäGÞ`fZ�LßÓ-Z�ÛPGdNP`»Z�ef×�Z�ÙfÔXGdH_NÛPLVNPÒcdGINO^Ò� Ó� � L"jSLRiRLVÔ�ÔXZ�U�H"Ö?Ö¤L_×�Ô�GIN�Ô]ÛPZ�GIU�Z�L"U]cIl9Ú�H"UXkCÔXÛOZ�L"\fÔ]ÛOH_UXjhH"Öd9+LVN<LCjwÔ)LKÔ]Z�`×0cIZ�LVUXcIl��A�Ô]ÛPLVÔ1Z0eO×0Z�ÙfÔ]GIH"NPjhj]ÛOH"\PcI`�NOHVÔ1Ó-ZçGdN{ÔXU]Hf`f\P×�Z�`�L"jhNOH_U]iCL"c-Z�J"Z�N_Ô)jQ�0âOêhÛOGIUX`fcIl"ØÔ]ÛOZ<9?LVNPLSiRH[ÒZ�cP`fH[Z�j?NPHVÔ�GINP×0cI\P`fZ�LVN[l$j]Ù-Z�×0G��<×hj]\OÙOÙ-H"U]ÔrÖÝH_U2Z0eO×0Z�ÙfÔ]GIH"N/ÛPL"NP`fcIGdNO^>L"NP`cdZ�LMJ"Z�j>L"cdc�×0H_i/ÙPcdGÞ×�LVÔ]Z�` GÞj]j]\OZ�j>Ú�G�ÔXÛ Ô]ÛOZ�LVÙOÙPcdGÞ×�LVÔ]GIH"Né`fZ�j]GI^"NOZ�UXj�â¶êhÛOZ�j]ZpÛPL_j�j]Z�J"Z�UXL"cj�Z�U]GIH"\PjC×�H"NPj]Z�ÿ{\OZ�NP×0Z�j/Ú�ÛOGI×)ÛøiCLMlä×�H"iRÙOcIGI×�LKÔXZ�j]lfjwÔXZ�i `fZ�j]Gd^_N»L"NP`»iCLVk"Z�GdÔ9iRH"UXZZ�UXU]H_U�á·ÙOUXH"NOZ_â�ýSNOZ�HVÖ�Ô]ÛOZ(Z�efL"iRÙOcdZ�GÞj/Ô]ÛPLVÔ/ÔXH ^"\PL"UXL"N_ÔXZ�Z9Ô]ÛPLVÔCÔ]ÛOZ�GINfÖÝH"UXiCLKÔ]GIH"NäGIj`fZ�cIGdJ_Z�UXZ�`/ÔXÛOZ�ÙOUXHf`f\P×�Z�UÌj]ÛOH"\PcI`CÚhLVGdÔ�ÖÝH_U�Ô]ÛPZ�NOH"Ô]G��<×�LVÔ]GIH"NRÔ]H$Ó<ZSGdiRÙOcIZ�iRZ�N{ÔXZ�`pLVÔÌÔ]ÛPZLVÙOÙOcIGÞ×�LKÔXGdH_N�cIZ�J"Z�c�Ø-GIN(Ô]ÛOZR×0Hf`fZ�HVÖ�Ó-HVÔXÛ�Ô]ÛPZ�ÙOUXHf`f\P×�Z�USL"NP`�ÔXÛOZ/×�H"NPj]\OiRZ�U�â<b�NOHVÔXÛOZ�U

Ó


50

Z0eOLViRÙOcIZ�GIj/ÔXÛPLKÔC9+L"NPL `fH[Z�jRNOH"ÔRÙPU]HKJ[GÞ`fZ�jRLVN[låj]lfjwÔXZ�iCLKÔXGI×�ÚhLMl[j$ÖÝH"URÔXUXL"NPj�ÖÝZ�UXU]GINOÛ]Z�j�Ù-H"NPj]GIÓOGdcIGdÔwl ÖÝH"URÛPLVN<`fcdGINO^ Z0eO×0Z�ÙfÔ]GIH"N<j/ÖÝU]H_i Ô]ÛOZ�ÙOUXHf`f\P×0Z�URHVÖSL"NäZ�J"Z�N{Ô/Ô]Héj]H"iRZHVÔ]ÛPZ�U�ÙOU]Hf×�Z�jXj �V×0Hf`fZ"â�T(H"UXZ�HKJ_Z�U�Ø2Ô]ÛPGIj�iRHf`fZ�c>`fH[Z�j�NOH"Ô�GIN{Ô]UXHf`f\P×0ZàÔ]ÛOZ ×0H_NP×0Z�ÙfÔ�HVÖZ0eO×0Z�ÙfÔ]GIH"N»×0H"N{ÔXZ0e[Ô�Ø�Ú�ÛOGÞ×)Û.GÞjR×0UX\P×0GÞLVcyÖÝH"UCLVN[l Z0eO×�Z�ÙfÔXGdH_N.ÛPL"NP`fcIGdNO^ iRZ0ÔXÛOHf`fH"cIH"^_lßáÚ�ÛOGI×)ÛßiCLVk"Z�j:G�Ô>GIi/Ù-H_jXj]GdÓOcIZ�Ô]H�\ONP`fZ�UXj�ÔXL"NP`�Ú�ÛOH�ÛPL"NP`fcIZ�j:Z0eO×�Z�ÙfÔXGdH_NPj�Ø Ú�ÛOZ�NßL"NP`�GdÖÔ]ÛOZ�l�LVUXZ�ÛPLVN<`fcdZ�`�LKÔçLVcIc�âê?H[HpiCLVN[l�U]Z�j�Ù-H"NPj]GIÓOGdcIGdÔ]GIZ�j � LVN<`(U]H[H_i ÖÝH_U�iRGÞjwÔ)LVk"Z�jQ��LVUXZcdZ�Ö Ô�Ú�G�ÔXÛ(LVÙOÙOcIGÞ×�LKÔXGdH_N�ÙPU]H_^"U)LViRiRZ�U)j�â ã N(L"ÒÒG�ÔXGdH_N�ÔXH/Ô]ÛOGÞjw9?LVNPL/Z0eO×�Z�ÙfÔXGdH_N�ÛPL"NP`fcIGdNP^`fH[Z�jCNOH"Ô�j]\OÙOÙ-H"U]Ô9NOZ�j�Ô]GINO^<Ø�NOH"U9G�Ô�j]\OÙOÙ-H"U]ÔXj9×0H[H"Ù-Z�U)LKÔXGdJ_Z�Û<LVNP`fcIGINO^éÔ]Û<LKÔ9GIN[J"H"cIJ"Z�jj�Z�J"Z�U)LVc ÙOUXHf×0Z�j]j]Z�j�â

Ô hÏj1Ñ�r*o1ËOÒ�ÎÌÊÖÕ×k2Ê�Ïqp�Ò�ÊwgiØæÎhÏwrPp

ã NéÔ]ÛOGÞj$j]Z�×0Ô]GIH"NéÚ�Z9`fGÞj]×�\PjXj�H"\PU$LVÙOÙPU]H{L"×)Û Ô]H�GIN{Ô]UXHf`f\P×0GINO^à×�H[H"U)`fGdN<LKÔ]GIH"NOá´ÓPL_j�Z�`àZ�e[á×0Z�ÙOÔ]GIH"N�ÛPLVN<`fcdGINO^RÚ�ÛOGÞ×)Û�j]Ù-Z�×0G��<×�LVcIcdl9ÖÝH[×�\Pj]Z�jhH"N�×0Hf`fZ>iRH_ÓOGdcIGdÔwl"â

J¶í�ì Ù�ñ�Ú�MrôR'Kñ�2åñ[ö ó ,Û HKJ"Z�c2Ö¤LV\Pc�Ô�Ô]H"cIZ�U)LVN<×0ZRÔ]Z�×)ÛONOGÞÿ{\OZ�j�Ô]HàÓ-Z9L"ÙOÙOcIl{GINO^�GIN.`fZ�J"Z�cdH_ÙOGdNP^�×0H"iRÙOcIZ0e iRH"ÓOGIcIZj�lfj�Ô]Z�iCj�ÛPLMJ_ZÌÔXH>×0H"UXUXZ�j]Ù<H_NP`çÔ]HçÔXÛOZ�GIU�j]Ù<Z�×0G��<×h×)ÛPLVU)L"×0Ô]Z�UXGÞjwÔXGI×�j�âMb�j�H_\OU�LVNPL"cdlfj]GIjrGINÏ� ¯ �j�ÛOHKÚ1j:ÔXÛOZCiCLVGIN Ú�LMl�H"ÖyZ�NPj�\PU]GINO^�Ö¤LV\OcdÔ�ÔXH"cIZ�U)LVNP×�Z�GINåj�\<×)Û j]lfjwÔXZ�iCj>GÞjçÓ{lßZ�iRÙOcIHKl{áGdNO^>L"ÙOÙOcIGI×�LKÔ]GIH"NOá·j]Ù<Z�×0G��<×yZ0eO×0Z�ÙfÔ]GIH"N�ÛPLVNPÒcdGINO^çiRZ�×)ÛPL"NOGIj]iCj�âKb�i/H_NO^çHVÔXÛOZ�U�GIi/Ù-H"U]ÔXL"N{ÔÙOU]H_Ù<Z�U�ÔXGdZ�jhÔ]ÛPZ�j]Z$iRZ�×)ÛPL"NOGÞj�iCj1j]ÛOH"\PcI`�Ó-Z$cIGd^_Û{ÔSLVNP`Ïc<Z0efGdÓPcdZ_ØPÔXÛOZ�l�j�ÛPH"\OcÞ`(LVcIcdHKÚAÖÝH_U`fl[NPLViRGÞ×>L"`>�w\Pj�Ô]iRZ�N_Ô)j1LVN<`pÖÝH_U1LV\fÔXH"NOH_i/H_\Pj � cIHf×�L"cdGIW�Z�`��ÛPLVN<`fcdGINO^RHVÖ2LVÓPNOH"UXiCLVcj�GdÔ�á\PLKÔXGdH_NPj�â[êhÛOZ�j�Z1iRZ�×)ÛPLVNOGÞj]iRj�j]ÛOH"\OcÞ`RÓ-Z:j]\OGdÔXLVÓPcdZ�ÖÝH"UÌH_Ù<Z�N9j]l[j�Ô]Z�iCjÌGINpÚ�ÛOGÞ×)ÛpiRH"ÓOGIcIZLV^"Z�N{ÔXj�LVUXZçÔ]HCH_Ù<Z�UXLVÔ]ZçGIN(\ONOk[NOHKÚ�N�Z�N[J[GdUXH"NPi/Z�N{ÔXj�LVN<`�Ó-Z$×�LVÙPL"ÓOcdZçH"Ö2ÒZ�LVcIGINO^RÚ�G�ÔXÛLVÓONOH_U]iCL"c j]GdÔ]\PLVÔ]GIH"NPj�ÔXÛPLKÔ�L"U]ZçNOH"Ôhk[NOHKÚ�N�GIN�L_`fJKLVNP×�Z"â

J¶í%$ - õ+ú?ñ[ûêhÛOZÜ�PU)jwÔSÙOU]H_ÓOcIZ�i ÛOZ�UXZ�GÞj�Ô]H�jwÔ)LMl�Ú�GdÔ]ÛOGINà`fZ�×0H_\OÙOcIZ�` � L_j�l[NP×)ÛPU]H_NOH"\Pj ��×0H_i/i�\ONOGÞ×�LVáÔ]GIH"NRiRH[ÒZ�cPL"NP`RLKÔ2Ô]ÛPZ1j]L"i/Z�ÔXGdiRZ�ÔXH>^"\PL"UXL"N_ÔXZ�Zh`fZ�cIGIJ"Z�UXl�H"Ö-Z�ef×�Z�ÙfÔXGdH_NPjrÔ]H>Û<LVNP`fcIZ�U)j�âýSNOcdlRGINpÔXÛOGIj�×�L_j�ZSÚyZ:×�L"Np^"\PL"UXL"N{Ô]Z�Z1Ô]ÛPLVÔ�LVcIc-Z0eO×0Z�ÙfÔ]GIH"NPj�LVUXZS×�LV\O^_Û{ÔyLVNP`�LKÖ ÔXZ�UyÔ]ÛPLVÔÛPLVNPÒcdZ�`ârýS\OU>GÞ`fZ�L�GÞj:Ô]H(k_Z�Z�Ù \Pj]GdNP^�\<j�\PL"c�jwÔ)LVNP`PLVU)`ßL_j�l[NP×)ÛOUXH"NPH"\PjSÚ�LMlfj:HVÖ�×0H_i/ái$\ONOGÞ×�LVÔ]GIH"N � G�â Z"â-k"Z�lfj1H"USZ�J_Z�N{ÔXj ��ÓO\OÔSÔXHpiCLVk"Z/j�\PU]Z>ÔXÛPLKÔ�Ø-j]ÛOH_\OcI`àLVN�Z�ef×�Z�ÙfÔXGdH_N�Ó-ZUXL"GIj]Z�`Ø[ÔXÛOZ>ÛPL"NP`fcIZ�U1LVcIÚhLMl[jyZ0efGÞjwÔ)j�GIN9ÔXÛOZ>cdHf×�LKÔ]GIH"N+â

b�j$ÒZ�ÙOGÞ×�ÔXZ�`åGINS�rGI^"\OUXZE?fØ+Ô]ÛOZ�\ONP`fZ�U]cIl[GdNP^�GIÒZ�L�ÛPZ�UXZpGIj�Ô]ÛPLVÔ�Ú�Z�L_j]j]\OiRZCÔ]Û<LKÔ�ØG�Ö�L"N ��6�� GIj�×0H_NPj�\Pi/Z�`ÕÓ[lÕLåÙOUXH"^_UXL"i ��6��Ý��!��¤>�!Þ�� Ø�LVN<`�LVN�Z�eO×0Z�ÙOÔ]GIH"N �GIj�UXL"GIj]Z�`ø`f\PU]GINO^åÙOUXHf×0Z�j]j]GdNP^éHVÖ>Ô]ÛPGIj�Z�J_Z�N{Ô�ØÌÔ]ÛOZ�NÕÔ]ÛOGÞj�Z�J"Z�N{Ô9GIjpÔ]ÛOZ ×�L"\Pj�ZàHVÖ>Ô]ÛPZZ0eO×0Z�ÙfÔ]GIH"N¶Ø?LVNP`éj]\P×)Û Z0eO×0Z�ÙfÔ]GIH"Néj]ÛOH"\PcI` Ó-ZRÔ]UXZ�LVÔ]Z�` H_\fÔXj]GÞ`fZ ��!��Ý��6��¤>�!Þ��!� â-ýSNPZÙ<H{j]j]GdÓPcdZ:j�H_cd\fÔXGdH_NpGÞj�ÔXH�LVcIcIHKÚ»H_NOcIlRj]l[NP×)ÛOUXH"NOH_\PjÌ×�H"iRi$\PNOGI×�LKÔXGdH_N¶Ø"GIN9Ú�ÛOGÞ×)Û9×�L"j]Z1Ô]ÛPZÙOU]Hf`f\<×0Z�U�H"ÖOÔ]ÛOZhZ�J"Z�N{Ô�Ø ��!��ß��!�� Ú�H"\OcÞ`�Ó-Z�Ô]ÛOZhÓ-Z�j�Ô2ÛPLVNPÒcdZ�U�â��\fÔ�G�Ö-ÚyZhÚhLVN{ÔÔ]HàL"cdcIHKÚ8L_j�l[NP×)ÛPU]H_NOH"\Pjç×�H"iRi$\ONPGI×�LKÔ]GIH"NéL"NP`éLV^_Z�N{Ô�iRH"ÓOGIcdGdÔwlàÚ�Z9×�LVNONOH"Ô�ÓOGINP` Ô]ÛPZÙOU]Hf`f\<×0Z�U�â_Y[HçÔXÛOZ�H"NPcdl�Ù<H{j]j]GdÓPcdZ1j]H"cI\fÔ]GIH"NRGÞj2ÔXH�×0UXZ�LKÔXZ�LçNOZ�ÚøÙOUXHf×0Z�jXj]à ¥~��¦ Ô]H>ÛPL"NP`fcIZÔ]ÛOZ>Z�ef×�Z�ÙfÔXGdH_N¶â

=


51

Handler Creation by System

result

H(E)

event

E

EventProducer

exception

EventConsumer

Shared Tuple Space

retrieved if necessary

Result of H(E) asynchronously

±d²\³�Áá�´ ¸�º"°)q)²"twz��s ¶ �V�"q)�

êhÛOZ/j]Ù-Z�×0GÞLVcIGIW�Z�`àÙOUXH[×�Z�jXjwà ¥~��¦ GÞjç×0UXZ�LVÔ]Z�`àÚ�ÛOZ�N LVNßZ0eO×0Z�ÙfÔ]GIH"N � GIjçj]Gd^_NPLVcIZ�`(Ó[l��!��Ý��!��¤>�!Þ�� â ã N�H"\OU�LVÙOÙPU]H{L"×)ÛøLVN[läZ�eO×0Z�ÙOÔ]GIH"N�GÞj9LåÔ]\OÙOcIZàH"Ö$Låj]Ù<Z�×0GÞLVcSÔwl{Ù-Z"þÔ]ÛOZ�U]ZpGÞj$L"cdÚhLMlfj>L(ÙOUXHf×0Z�jXjçÚhLVGdÔ]GINO^(Ô]HàÛPLVNPÒcdZ � G�â Z"â+Ô]Hà×�H"NPj]\OiRZ��>G�Ô�ârY[\P×)Û.ÛPLVNPÒcdZ�Uà ¥~��¦ Ø U]Z�ÙOU]Z�j�Z�N{Ô]GINO^9ÔXÛOZCZ0eO×�Z�ÙfÔXGdH_N ×�H"N{Ô]Z�e{Ô�ØGIjç\<j�\PL"cdcIlà`fZ�j�GI^"NPZ�`ßÓ{l�Ô]ÛOZp`fZ�J"Z�cdH_Ù<Z�UHVÖ ��!��ß��6�� ÓO\OÔpG�Ôp×�L"N.Ó-Z(`fZ�j]Gd^_NOZ�`.Ó[léÔ]ÛOZ(`fZ�j�GI^"NPZ�U/HVÖ ��!��Ý��!��¤>�!Þ��L"j�ÚyZ�cdc´â ã N�Ô]ÛOZ cILVÔ�ÔXZ�U�×�L"j]ZàZ�G�ÔXÛOZ�U�Ô]ÛPZßÛPL"NP`fcIZ�U�ÙOUXHKJ{GÞ`fZ�`øÓ{l ��!��ß��!�� GIjGd^_NOH"UXZ�`CGIN9UX\ON{Ô]GIiRZ>LVNP`9H"NOcIl/Ô]ÛOZçÛPL"NP`fcIZ�Uhj�\OÙPÙOcdGIZ�`�Ó[l ��6��Ý��!��¤>�!Þ�� GIj�\Pj]Z�`Ø[H_UÓ<H"Ô]ÛéÛPL"NP`fcIZ�U)j>U]Z�×0Z�GdJ_Z/Z�eO×0Z�ÙOÔ]GIH"N �T� GdNéÚ�ÛPGI×)Ûå×�L"j]ZRÔ]ÛOZ�lß×�L"Nå`fZ�×�GIÒZRÔ]H�ÛPL"NP`fcIZpGdÔ×0H[H"Ù-Z�U)LKÔXGdJ_Z�cIl��0â+êhÛOZpÛ<LVNP`fcIZ�U�ÙOUXH[×�Z�jXj>\Pj]\PLVcIcIl ×�H"iRÙOcIZ0Ô]Z�j�ÛPL"NP`fcIGdNP^�LVNP`åÒGdZ�j�â3�y\OÔÔ]ÛOZ�lp`fH$NOH"Ô�Û<LMJ"Z�ÔXHPâfF:Z�NOZ�UXL"cdcIlCj�Ù-Z�L"k{GINO^<Ø"ÔXÛOZ�lp×�LVNpÓ-ZSGIN[J"H_cdJ_Z�`RGINpÖÝ\OU]Ô]ÛOZ�U�j]lfjwÔXZ�iZ0efZ�×�\fÔ]GIH"N�ÖÝH"U1L_jhcdH_NO^CL"jhNOZ�×0Z�jXjXLVUXl"â

ã N(H"\OU�L"ÙOÙOUXH_L_×)Û�Z�L"×)Û�Ô]\PÙOcdZXâ�ÙOUXHf`f\P×�Z�`�Ó[l ��!��ß��6�� ÛPL"j�LCN[\Oi$Ó-Z�USHVÖZ0eO×0Z�ÙfÔ]GIH"NPjy`fZ�×�cIL"U]Z�`RGdN9G�Ô)jyj]Gd^_NPLKÔX\OUXZ"þ �*ã ØPâIâIØ �� GdN9L_Ò`fGdÔ]GIH"NRÔXH�L�j]Z0Ô�HVÖ¶ÙPL"UXL"i/Z�Ô]Z�UXj�âUÕÛOZ�NÜâSGIjÙP\fÔ+GIN_ÔXH1L�Ô]\OÙPcdZÌj]ÙPL_×0Z�Ô]ÛPZÌj�lfj�Ô]Z�i j]ÛOH"\OcÞ`:ÛPLMJ"Z�UXZ0ÖÝZ�U]Z�NP×0Z�j-Ô]H�`fZ�×0cÞLVU)LKÔXGdH_NPjHVÖfN�ÛPL"NP`fcIZ�U)j�þ�H"NOZ2ÖÝH_U+Z�L"×)Û>Z0eO×�Z�ÙfÔXGdH_N¶â�êhÛOZyÛPLVN<`fcdZ�U¶ÙOUXHf×0Z�jXj¶GÞj+×�U]Z�LKÔXZ�`çcIH[×�LVcIcdl_Ø�Ú�ÛOZ�NLVN�Z0eO×0Z�ÙfÔ]GIH"N�GÞj1j]Gd^_NPLVcIZ�`�ÓO\fÔ�GdÔ�`fH[Z�j1NOHVÔ1ÛPLMJ_Z:Ô]HCÓ-Z$LVcIÚ�LMlfj�cIH[×�LVc´þOGdÔ�×�LVN�iRHKJ"Z:ÔXHÓ<Z�Ô�Ô]Z�URÛPLVNPÒcdZ�Ô]ÛOZ�Z0eO×�Z�ÙfÔXGdH_N¶ân�y\OÔ/GdÔ/GÞj/GdiRÙ-H"U]ÔXL"N_Ô�Ô]H LVcIÚ�LMlfj�×0UXZ�LKÔXZ9GdÔ/Ú�ÛPZ�NäL"NZ0eO×0Z�ÙfÔ]GIH"NßGIjçj]Gd^_NPLVcIZ�`â�U Z/Ó-Z�cIGIZ�J"Z�Ô]Û<LKÔçG�Ô>Ú�H"\OcÞ`(Ó-Z/Ú�UXH"NP^pÔ]H�iCLVk_Z�LVN[l�Z0efGÞjwÔXGdNP^ÙOU]Hf×�Z�jXj>Ô]HßÓ<Z�L�Û<LVNP`fcIZ�U�Ó<Z�×�L"\Pj�Z9Ô]ÛOZ�U]Z�GIj�NOHß^"\PL"UXL"N_ÔXZ�ZCÔXÛPLKÔ/G�ÔRÚ�GIcdc�ÛPLVN<`fcdZ�Ô]ÛPZZ0eO×0Z�ÙfÔ]GIH"N Ú�G�ÔXÛOH"\OÔ>ÒZ�cÞLMl[j�þ G�Ô$×�LVNßi/HKJ_Z$ÔXH(LVNOH"Ô]ÛOZ�U:cIHf×�LVÔ]GIH"N Ó<Z�ÖÝH"UXZRL"NàZ�ef×�Z�ÙfÔXGdH_NGIj>j]Gd^_NPLVcIZ�`àH"U:G�Ô$×�LVNßÓ<ZRÓO\Pj]là`fH_GdNP^�H"Ô]ÛOZ�UH�wH_Ó L"NP`�Ó-Z�×�LV\Pj]ZRHVÖ�ÔXÛOZCL"j]l[NP×)ÛOUXH"NOH_\PjNPLKÔX\OU]ZçH"Ö�×�H"iRi$\ONPGI×�LKÔ]GIH"N�iCLMlp`fZ�×�GIÒZçÔ]HCÛPL"NP`fcIZ:GdÔ1Ú�ÛOZ�N�GdÔ1GÞj�Ô]H[HCcILVÔ]Z_â

ýS\OU�j]×)ÛPZ�iRZCLVcIcdHKÚ1jç`fZA�PNOGINO^�L�ÙOU]Hf×�Z�jXjçÛPLVNPÒcdGINO^(j�Z�J"Z�UXL"c � H"U�ØZ�J_Z�N¶Ø¶L"cdc�Z�eO×0Z�ÙOáÔ]GIH"NPj �yÖÝU]H_i Ô]ÛPZ�j�GI^"NPLVÔ]\OUXZ:HVÖlâ ØOH"U�ØfZ�J_Z�N¶Ø[ÖÝUXH"i ÔXÛOZ�j]Gd^_NPLKÔX\OU]Z�j�HVÖ2`fG�� Z�UXZ�N{ÔhÔ]\PÙOcdZ�j�â

ýSNOZ1ÙOUXH"ÓOcIZ�i Ú�Z�LVUXZ1ÙOcÞLVNPNOGdNP^>Ô]H/L"Ò`fUXZ�jXj�GÞj�þ_Ú�ÛPLVÔyÛPL"ÙOÙ-Z�NPjÌG�Ö ��!��Ý��!��¤>�!Þ��i/HKJ_Z�jSÔ]H(L"NOHVÔXÛOZ�UçcIH[×�LKÔXGdH_NßLVN<`ßj]Gd^_NPLVcÞj:Z0eO×0Z�ÙfÔ]GIH"N � Ú�ÛOGIcIZR×�H"N{Ô]GIN[\OGINO^�ÙPU]Hf×0Z�j]j]GINO^Ô]ÛOZ:×0H"N<j�\OiRZ�`/Ô]\OÙOcIZäâ�GINCÔ]ÛPGIjycdHf×�LKÔ]GIH"N+â!U ZSj]ÛOH"\OcÞ`CÓ-ZSL"ÓOcdZ1Ô]H�×�U]Z�LKÔXZ�ÛPLVNPÒcdZ�UHà ¥~��¦GdN�Ô]ÛOZ>NPZ�ÚÜcIHf×�LVÔ]GIH"N9Ó-Z�×�LV\Pj]Z:Ô]ÛOGÞj�GÞjhÚ�ÛOZ�UXZSÔ]ÛOZ>Z�ef×�Z�ÙfÔXGdH_NpÔX\OÙOcIZ>GIjhÙO\OÔ1GdN�Ô]ÛOZ>cIHf×�L"cÔ]\OÙOcIZ�j]ÙPL"×�Z"â

�


52

ê+H/iCLVk"Z:H"\PUhjX×)ÛOZ�i/Z:Z�J_Z�N�i/H_U]ZqcPZ�e[GIÓOcIZSÚ�ZçÙOcÞLVNpÔXHCLVcIcdHKÚ>þ[LVN�Z0eO×0Z�ÙfÔ]GIH"N9Ô]HRÓ-ZÙOU]H_ÙPLV^{LKÔXZ�`(ÔXH�j�Z�J"Z�UXL"c2ÛPLVNPÒcdZ�U>ÙOU]Hf×�Z�jXj�Z�j>LVNP`ßÔ]ÛPZCÛPLVNPÒcdZ�U$LVNP`ßÔXÛOZCZ0eO×0Z�ÙfÔ]GIH"N ÔXHÓ<Z�`fl[NPL"iRGI×�LVcIcdl9L_j]j]Hf×0GÞLKÔXZ�` � Z"â ^PâOÚ�ÛPGdcIZçGdNPj]Z�U]Ô]GINO^åâpGIN{Ô]HpL/cdHf×�LVc Ô]\PÙOcdZ�j]ÙPL_×0Z��0â

b1NOH"Ô]ÛOZ�U�ÖÝZ�LVÔ]\OUXZpÚ�ÛOGÞ×)ÛåÚ�H"\OcÞ`éL"`P`ÎcPZ0efGIÓOGdcIGdÔwlàÔXHàH"\PU�jX×)ÛOZ�iRZpGÞj>ÔXHàLVcIcdHKÚ L"N{lZ0efGIj�Ô]GINO^/ÙOUXH[×�Z�jXj�Ø_Ú�ÛOGÞ×)Û9GÞjycIHf×�L"cPÔXH ��!��Ý��!��¤��!Þ�� LVNP`CÔ]H/Z0eO×0Z�ÙfÔ]GIH"N � Ø_Ô]H/ÛPL"NP`fcIZG�Ô�ÔXH"^"Z�Ô]ÛOZ�U�Ú�G�ÔXÛ(jwÔ)LVNPÒL"UX`9ÛPLVN<`fcdZ�U�ÙOUXH[×�Z�jXj�Z�j�â ã N�ÙPL"U�ÔXGI×�\OcIL"U�Ø[GdÔ�j�Z�Z�iCj�Ô]HCÓ-Z>\Pj]Z0ÖÝ\OcÔ]HpLVcIcIHKÚ ��6��ß��!�� Ô]HD�wH_GdN�GIN�ÔXÛOZçÛPLVN<`fcdGINO^<â

J¶íKJ - ù�'�ª-ñ{ó�«>û�ùOð"ñßî�ï¶ù�2éòrû�ñ#Ù9ñ�0¶ô1,�ôÝó�ñ{úUßZÌÒZ�iRH"NPj�Ô]U)LKÔXZ�H"\PU+LVÙOÙPU]H{L"×)Û:\Pj�GINO^hÔXÛOZÌiCLVUXk"Z�Ô¶ÙOcÞL"×0Z2Z�eOLViRÙOcIZ�GdN{ÔXU]Hf`f\P×�Z�`:Z�L"U]cIGIZ�U�â

Shared Tuple Space

exception

Buyer Agent

Handler1 InsufficientMoneyException

Buyer E-Purse Agent

Seller E-Purse Agent

Seller Agent

Asks Money to the Bank

MoneyTransfer

PaymentReceived

ContractConcluded

StartPaymentDepositMoney

StartPayment

±d²\³�Ńæ�´ ¸*º_��>²_�}qhºyqX|"z}~vz�twq��çf�V�{°)°)qX~v~·�Þ�{�PºÌq)°)�0|MqXuv�

ã NRÔ]ÛOGÞjÌÙ<LVU]Ô]GÞ×0\OcÞLVUÌjX×0Z�NPLVUXGIHçÔ]ÛOZw��\Ol_Z�U�b1^"Z�N{ÔyL"j]kfj2G�Ô)j áèGÌ\OU)j�Z�b1^_Z�N{Ô�ÔXH�U]Z�cdZ�L"j]ZÔ]ÛOZßi/H_NOZ�lÕL"NP`ÕÙOUXHKJ[GI`fZ�jRÔ]ÛPZ áèGÌ\OUXj]Z�b1^_Z�N{Ô�Ú�GdÔ]Û LåNPL"i/ZàHVÖ�GdÔXj�ÙOU]HMefløLV^_Z�N{Ô� Z L"NP`fcIZ�U��yÔXÛPLKÔS×�LVN�Ó-Z�cdHf×�LVcIcdl�×0UXZ�LKÔXZ�`�Ú�ÛOZ�N(NOZ�×�Z�jXj]L"U]lCÔXHp`fZ�L"c¶Ú�GdÔ]Û(Z0eO×�Z�ÙfÔXGdH_NPj�âêhÛOZé��\Ol_Z�U á·ÙO\OU)j�Z/b1^"Z�N{ÔSU)LVGÞj�Z�j�LVNßZ0eO×0Z�ÙfÔ]GIH"Nß`f\OZ�Ô]HpÔXÛOZ�Ö¤L"×�Ô:Ô]Û<LKÔ:Ô]ÛOZ�U]Z�GIj:NOH"ÔZ�NOH_\O^"Û/iRH"NOZ�l�GdN/ÔXÛOZ1Z0á·ÙO\OU)j]ZÌÖÝH_U�U]Z�LVcIGdW�GdNP^�ÔXÛOZ�ÙPLMl[iRZ�N{Ô�âVêhÛOZ1j]lfjwÔXZ�i Ô]ÛOZ�NR×�U]Z�LKÔXZ�`Z LVN<`fcdZ�U �_ØfÚ�ÛOGÞ×)Û�×�LKÔ)×)ÛOZ�jhÔXÛOZ>Z0eO×�Z�ÙfÔXGdH_N¶â Z L"NP`fcIZ�U��>L"×�×�Z�jXj�Z�j�Ô]ÛOZ>Ó<LVNOk ØOGIN�H"U)`fZ�UhÔXHÔ]U)LVNPj�ÖÝZ�UhiRH"NOZ�lRÖÝU]H_i Ô]ÛPZ:Ó<LVNOk9L_×�×�H"\ON{ÔÌÔXH/Ô]ÛOZçZ0á·ÙO\OU)j]Z � j�Z�ZD�rGI^"\OUXZD5��â ã Ô1`fZ�Ù<H{j�GdÔXjÔ]ÛOZ�N Ô]ÛOZpiRH_NOZ�l�H_N Ô]ÛOZpZ�á´ÙP\OUXj]Z"Ø?LVNP` j�ÔXLVU]ÔXj>L"^_L"GdNßÔ]ÛOZ9ÙPLMl[i/Z�N{Ô�ÙOU]Hf×�Z�`f\OUXZ"â¶êhÛPZi/H_NOZ�lçÔXUXL"NPj�ÖÝZ�U?ÖÝU]H_i ÔXÛOZ��y\Pl"Z�UrZ0á·ÙO\OU)j]Z�Ô]HSÔ]ÛPZhY[Z�cdcIZ�U�Z�á´ÙO\PUXj]ZÌHf×�×�\OU)j+NOHKÚå×�H"UXU]Z�×�ÔXcdl_âêhÛOZhYfZ�cIcdZ�UrZ�á´ÙP\OUXj]ZyL"^"Z�N_Ô?Ô]ÛOZ�N�GINfÖÝH_U]iCj?Ô]ÛOZ�Y[Z�cdcIZ�U2LV^_Z�N{Ô+ÔXÛPLKÔ�ÔXÛOZyÙ<LMl{iRZ�N_Ô�ÛPL_j?Ó-Z�Z�NU]Z�LVcIGdW�Z�`Ø�LVNP`çÔXÛOZ�Y[Z�cIcdZ�UrL"^"Z�N_ÔP�PNPLVcIcIl:GINfÖÝH_U]iCj+Ô]ÛOZW�y\Pl"Z�UrLV^_Z�N{Ô¶Ô]Û<LKÔrÔ]ÛOZÌÔ]U)LVNPjXL"×0Ô]GIH"NÚ�L_j�j�\P×�×0Z�j]j�ÖÝ\Oc´â

�?GI^"\PU]Z ¯ j]ÛOHKÚ1j�LC`fG��-Z�U]Z�N{ÔS×�L_j�Z_â Z LVN<`fcdZ�U ��ÒH{Z�j�NOH"Ô�j�\P×�×0Z�Z�`�GIN�UXZ0ÔXU]GIZ�J[GINO^pL"`fá`fG�ÔXGdH_NPLVc-iRH"NOZ�l/ÖÝU]H_i ÔXÛOZ:ÓPLVNOk � Ô]ÛOZ:ÓPLVNPkpL"×�×�H"\ON{ÔÌGÞjyNOHVÔ�j�\�°C×�GdZ�N{Ô]cIl�ÖÝ\PU]NOGÞj]ÛOZ�`Ø[H_UÔ]ÛOZ�U]Z9L"U]ZCNPH(ÙOU]GIJ[GdcIZ�^_Z�j ��â Z LVNPÒcdZ�U �CGINfÖÝH"UXiCjçÔ]ÛPZE��\Ol"Z�U$b1^_Z�N{Ô>Ô]ÛPU]H_\O^"ÛéL(UXZ�^_\OcIL"U

�


53

Shared Tuple Space

exception

Buyer AgentStartPayment

Handler1 InsufficientMoneyException

Handler2

ContractCancelled

Seller Agent

NotEnoughMoney

PaymentFailedException

Buyer E-Purse Agent

Unsuccessfull Money Recovery

Start New Selling Request

Contract Cancellation

±d²\³�Ńê�´ ¸�º_��>²{�}qhºÌq)|Vz}~vz�twq��ç�ë[��z}�}q��/ºÌq)°)�0|Mq]uv�

Z�J"Z�N{ÔçL"Ó<H_\fÔSÔXÛOZRGdN<j�\�°p×�GdZ�N_Ô>iRH"NPZ�l(ÙOUXZ�j]Z�N{ÔçGdNßÔ]ÛOZ/Z0á·ÙO\OU)j]Z"âêhÛOZ��y\Pl"Z�U>b�^"Z�N{ÔçGIjNOHVÔ2LVÓOcIZ�ÔXHS×�H"Ù-ZyÚ�GdÔ]Û$Ô]ÛOGÞj�j�GdÔ]\PLVÔ]GIH"N¶ØMLVN<`�U)LVGÞj�Z�j+LVN$Z0eO×0Z�ÙfÔ]GIH"N¶ØK×�LV\O^_Û_ÔrÓ[l Z LVNPÒcdZ�U ?OØÙOU]HKJ[GÞ`fZ�`ßÓ[l(Ô]ÛPZ9Y[Z�cIcdZ�U�b1^_Z�N{Ô�â Z LVNPÒcdZ�U ?9GIj�GdNé×)ÛPL"U]^_Z�H"Ö�×�L"NP×0Z�cdcIGINO^�Ô]ÛOZCH_Nfá´^_H"GINO^×0H"N{ÔXUXL_×�Ô�Ø"G�Ô�ÔXÛOZ�N9GdNfÖÝH_U]iCj�ÔXÛOZ:YfZ�cIcdZ�UÌb1^_Z�N{Ô�Ø"Ô]ÛPLVÔyj�\PÓPj�Z�ÿ{\OZ�N{Ô]cIlRjwÔ)LVU]ÔXj�LçNOZ�ÚÕj�Z�cdcIGdNPÛ]Z�ÿ_\PZ�j�Ô�âPbSj1LVN�L"c�ÔXZ�UXNPLKÔXGdJ_Z"ØfÚ�Z�×0H"\PcI`�LVcÞj]H/Z�N[J{GÞjXLV^"Z:ÔXÛPLKÔ Z LVNPÒcdZ�U ?/×0UXZ�LVÔ]Z�j�LVN�L"`fá`fG�ÔXGdH_NPLVc Y[Z�cIcIZ�Uyb�^"Z�N_Ô2ÔXÛPLKÔ�Ú�GdcIc<j�ÔXL"U�Ô2ÔXÛOZSjXLViRZ1j]Z�cIcdGINO^�UXZ�ÿ{\OZ�jwÔ�ØVcIZ�LMJ[GdNP^çÔ]ÛOZSH"UXGd^_GdNPL"cY[Z�cIcdZ�U/b�^"Z�N_Ô�ÖÝU]Z�ZpÔXH ×�H"N{Ô]GIN[\OZpGdÔXj/ÚyH_U]k � Z_â ^<âdØrÓO\Ol[GINO^ßLßj�Z�U]GIZ�j�HVÖ1GdÔ]Z�iCjQ�0â�êhÛPGIj�GIjÙPLVU]Ô]GÞ×0\OcÞLVUXcIlC\Pj�Z�ÖÝ\Oc´ØOÚ�ÛOZ�N�ÔXÛOZ>H"UXGd^_GdN<LVc¶Y[Z�cIcIZ�U1b1^_Z�N{Ô1NOZ�Z�Òj�ÔXHCi/HKJ_Z"â

êhÛOGIj�j]GIi/ÙPcdZ>Z�efL"iRÙOcdZ>L"cdcIHKÚ1j�\PjhÔ]HC`fU)LMÚ j]Z�J_Z�U)LVc×0H_NP×0cI\Pj]GdH_NPj�þ

» GdNì9?LVNPL:ÔXÛOZ�GdN{ÔXZ�U)L"×�ÔXGdNP^çL"^"Z�N_Ô)j�ÛPLMJ"Z�ÔXH�LVcIÚ�LMlfjrÚ�L"G�Ô�\PN_ÔXGdcOÔ]ÛOZ1Z�NP`RLVNP`/\ON{ÔXGdcPL"cdcNOHVÔXG��-×�LKÔXGdH_NPj?ÛPLMJ"Z�Ó-Z�Z�N$UXZ�×�Z�GIJ"Z�`¶Ø�ÓO\fÔ�GIN$H"\PUrL"ÙOÙOUXH_L"×)Û:ÔXÛOZ�l�`fHSNOHVÔ�Ó-Z�×�L"\Pj]Z�Ô]ÛPZÛPLVN<`fcdZ�U>LV^"Z�N{ÔXjç×�L"NàÛPL"NP`fcIZ/ÙPU]H_ÓOcdZ�iCj � H"\OU�j]H"cI\fÔXGdH_NßLVcIcIHKÚ1j�\Pj:ÔXH�ÓO\OGIcI`ßU]Z�LVcIcdlL"j]l[NP×)ÛOUXH"NOH_\Pjyj]lfjwÔXZ�iCj �BY

» iRH"UXZ�HKJ"Z�U�Ø[H_\OU1LVÙOÙPU]H{L"×)Û�LVcIcdHKÚ1j�L"^"Z�N{Ô)j�Ô]HRÖÝUXZ�Z�cIl9iRHKJ_ZSÔXHCHVÔXÛOZ�U1cIHf×�LVÔ]GIH"NPj�L"NP`jwÔ)LVU]ÔpHVÔXÛOZ�UpÚ�H"UXk.Ú�GdÔ]ÛPH"\fÔ9ÚhLVGdÔ]GINO^ ÖÝH"U�LVcIc1NOH"Ô]G��<×�LVÔ]GIH"NPjRá�G�Ö�LVNÕZ�eO×0Z�ÙOÔ]GIH"NøGIjj�GI^"N<LVcIZ�`äGdNøÔXÛOZ(H"UXGd^_GdN<LVc�cIH[×�LVcIG�ÔwlåÔ]ÛOZ�U]Z�L"cdÚhLMlfjRGIjpL ÛPL"NP`fcIZ�UCÔXHå`fZ�L"c1Ú�GdÔ]ÛÕGdÔcdHf×�LVcIcdl�Y

» GdNé9+L"NPLSL"cdc{ÛPL"NP`fcIGdNO^:GÞjrLSÙPL"U�ÔrHVÖOÔXÛOZ1Y[Z�cIcdZ�U�Ø�ÔXÛOZW��\Ol_Z�U�LVNP`�Ô]ÛOZ á¾G�\PUXj]ZÌb1^_Z�N{ÔXjÓO\fÔ$GIN H"\OU�LVÙOÙOUXH_L_×)ÛàÛPL"NP`fcIGdNP^(GIj>GIiRÙOcIZ�iRZ�N{Ô]Z�` GdNéj]Z�ÙPL"UXLVÔ]ZRÛPL"NP`fcIZ�U�LV^_Z�N{ÔXj:áH"\OU�ÒZ�j]Gd^_N GÞj�×�cdZ�LVNOZ�U�LVNP` Ú�ZRj]Z�Ù<LVU)LKÔ]Z/ÔXÛOZCNOH"UXiCLVc�×�H[ÒZRÖÝU]H_i Ô]ÛPZpLVÓONOH_U]iCL"cH"NOZ_ân�yZ�×�L"\Pj�Z�HVÖ�ÔXÛOGIj�Ø2H"\PU/L"ÙOÙOUXH_L"×)ÛéGÞj�i/H_U]ZícPZ0efGIÓOcIZ"â]UßZ(×�LVN¶Ø?ÖÝH"U/Z0eOLViRÙOcIZ"Ø\Pj]Z�`fG��-Z�U]Z�N_Ô�ÛPLVN<`fcdZ�U�ÙOUXHf×0Z�jXj]Z�j�ÖÝH_Uy`fG��-Z�U]Z�N{ÔÌcdHf×�LKÔ]GIH"N<j2Ú�ÛOGÞ×)ÛRÔ]ÛOZä�y\Pl"Z�Uyb1^"Z�N{ÔJ[GIj]G�Ô)j�ØPÚ�ÛOGdcIZçGdNF9?LVNPL/ÛPL"NP`fcIGdNO^RGÞj�ÛPL"UX`fÚ�GIUXZ�`pGIN{Ô]HRÔXÛOZ4��\Ol"Z�Uhb�^"Z�N_Ô�âUÕG�ÔXÛ�UXZ�j]Ù<Z�×�ÔrÔ]Hç`fZ�L"cdGINO^SÚ�G�ÔXÛ/`fGÞj�Ô]UXGdÓO\OÔ]Z�`/LVÙPÙOcdGÞ×�LVÔ]GIH"N�Z�U]UXH"U)j¶Ú�Z�Ú�GdcIc[Ó<ZhZ0e[ÔXZ�NP`[á

GdNO^�H_\OU�LVÙOÙPU]H{L"×)Û�Ú�GdÔ]Û Ô]ÛPZp×0H"N<×0Z�ÙOÔçH"ÖyÔXÛOZp×0H_N{Ô]Z0e[Ô � j]Z�Z/ÔXÛOZpQ�GÞjX×0\PjXj�GIH"NéY[Z�×�Ô]GIH"N��

��"


54

ÓO\fÔ�GINÒ9+L"NPL/Z�J_Z�UXl_ÔXÛOGINO^pLV^{LVGIN�j]ÛOH_\OcI`�Ó-Z�`fZ�J"Z�cdH_Ù<Z�`�Z�efÙOcdGÞ×0GdÔ]cIl�Ó{l9Ô]ÛOZ/LVÙOÙPcdGÞ×�LVÔ]GIH"NÙOU]H_^"U)LViRiRZ�U)jÌÚ�GdÔ]Û�NOHCL_Ò`fGdÔ]GIH"NPL"c¶j�\OÙPÙ<H_U�Ô�ÖÝUXH"i ÔXÛOZ�j]l[j�Ô]Z�i�â

ã Ô$GIj�×0cIZ�L"U>Ô]ÛPLVÔ�LVN[lßÙPLVU]Ô]GÞ×0\OcÞLVU�ÖÝZ�LKÔX\OUXZpÚ�ÛOGÞ×)ÛéH"\OU$L"ÙOÙOUXH_L_×)ÛßÙOUXHKJ[GIÒZ�j�×�LVNéÓ-ZGdiRÙOcIZ�iRZ�N{ÔXZ�`CGINí9+L"NPLçH"U�LVN[l$H"Ô]ÛOZ�Uy×�H{H_UXÒGdNPLVÔ]Z�`�iRHf`fZ�cIj�â{êhÛPZ1U]Z�LVcPÿ{\OZ�jwÔXGdH_NCGIjyÛOHKÚZ0efÙ<Z�NPj]GdJ_Z:L"NP`pZ�U]UXH"U]á´ÙPU]H_NOZhÔ]ÛOZ�j�Z>j]H"cI\fÔ]GIH"N<jyL"U]ZçLVNP`9Ú�ÛPLKÔ�j]H"U]Ô�H"Ö?j�\PÙOÙ<H_U�Ô�Ô]ÛPZ:ÙPU]H"á^"U)LViRiRZ�U)jhÛPLMJ"Z:Ô]H�j�lfj�Ô]Z�iCLVÔ]GÞ×�LVcIcIlpZ�iRÙOcIHKl9Z�ef×�Z�ÙfÔXGdH_N�ÛPLVNPÒcdGINO^Pâ-êhÛOGÞj�GIj�Ú�ÛOZ�UXZ>H"\PUj�H_cd\fÔXGdH_NéÙOUXHKJ{GÞ`fZ�j>L(N[\Oi$Ó-Z�U�H"Ö�Ó<Z�NOZN�OÔ)j$Z�NPj]\OU]GINO^<ØÖÝH"U�Z0eOLViRÙOcIZ"ØÔXÛPLKÔ/LVN[lßZ�eO×0Z�ÙOáÔ]GIH"NàGÞj:LVcIÚ�LMlfj�ÔXU]Z�LKÔXZ�`â ã NàL"`P`fG�ÔXGdH_N�ÔXHpÔ]Û<LKÔçH"\OUçLVÙOÙPU]H{L"×)Û�U]Z�j�Ù-Z�×0ÔXj:L"j]l[NP×)ÛOUXH"NOH_\Pj×0H"iRi�\ONOGÞ×�LKÔXGdH_NpiRZ�×)ÛPL"NOGÞj�i LVNP`9`fH[Z�jyNOHVÔhU]Z�jwÔXU]GÞ×�Ôy\ONONOZ�×0Z�jXjXLVUXGdcIl�ÙPU]Hf×0Z�j]jÌiRH"ÓOGIcdGdÔwl"â

î fïrPpsk?Ë�r+ÏÖð Î�Í�ñlò

ê+H�Ô]ÛOZRÓ-Z�j�Ô>HVÖÌH_\OUçk{NPHKÚ�cdZ�`f^"Z$Ô]ÛOZ�U]ZRLVUXZ$NOH�^"Z�NOZ�U)LVcrZ0eO×�Z�ÙfÔXGdH_NàÛPL"NP`fcIGdNO^�ÖÝZ�LKÔ]\PU]Z�j`fZ�J_Z�cIH"Ù-Z�`>ÖÝH_U?iRH_ÓOGdcIZ�×0H[H"U)`fGINPLKÔXGdH_Nfá·ÓPL"j]Z�`:Z�N[J[GIU]H_NOiRZ�N{ÔXj?iRZ�Z0ÔXGdNP^SÔXÛOZ�U]Z�ÿ_\PGdUXZ�iRZ�N{Ô)jLVÓ-HKJ"Z"âMêhÛOZ�U]Z�LVUXZÌH"NPcdl:ÖÝZ�Ú.U]Z�cdZ�JML"N{ÔrÙPL"Ù<Z�UXj?H"N$Z0eO×0Z�ÙfÔ]GIH"N�ÛPLVNPÒcdGINO^:GdN/×0H[H"U)`fGINPLKÔXGdH_NfáÓPL"j]Z�`�j�lfj�Ô]Z�iRj�âfQ�GÞLVW>Z�Ô1LVcd� È �¶ÙO\fÔhÖÝH_U]ÚhLVU)`9L/ÓPL_j�GÞ×�Z�eO×0Z�ÙOÔ]GIH"N�ÛPLVNPÒcdGINO^/ÖÝUXL"iRZ�Ú�H"UXkÖÝH"U�ÔXÛOZpcIH"^_GI×p×)Û<LVNONOZ�c�á·ÓPL_j�Z�`ß×�H{H_UXÒGdNPLVÔ]GIH"N iRHf`fZ�c´â ã N ÔXÛOGÞj$iRHf`fZ�cyÚ�ÛOZ�NåL�ÙOU]Hf×�Z�jXjGIjR×0UXZ�LVÔ]Z�`åLßj]Ù-Z�×0GÞLVchcIH"^_GI×�LVch×)ÛPLVNONPZ�c�GIjRL"jXj]H[×�GILVÔ]Z�`éÚ�G�ÔXÛ.GdÔ�Ø�j]HàÚ�ÛOZ�N.ÔXÛOZ�ÙOU]Hf×�Z�jXjUXL"GIj]Z�j�L"NéZ0eO×0Z�ÙfÔ]GIH"NéGdÔ�GÞj�ÙPU]H_ÙPLV^{LKÔ]Z�`ßÔ]ÛOUXH"\O^_Û Ô]ÛOGÞj$ÒZ�`fGÞ×�LVÔ]Z�`.×)ÛPLVNONPZ�c´â?êhÛOZpGÞ`fZ�LÛOZ�UXZ9GÞj�Ô]ÛPLVÔ/Ú�ÛOZ�NäLàÙOU]Hf×�Z�jXj$GÞjR×0UXZ�LKÔXZ�`éL j�Ù-Z�×�GIL"cyÙPU]Hf×0Z�j]j�\Pj]Z�`åÖÝH"U/ÛPLVNPÒcdGINO^ßL"cdcG�Ô)jçZ0eO×0Z�ÙfÔ]GIH"NPj:GÞjç×0UXZ�LKÔXZ�`ßLVNP` j�Z�N{ÔçL_jSÚ�Z�cIc´â êhÛPGIj>jX×)ÛOZ�iRZ/GIjçNPHVÔçH"UXGdZ�N_ÔXZ�`�Ô]HKÚhLVU)Òji/H_ÓOGIcdZ�Z�N[J[GdUXH"NOiRZ�N_Ô)j�Ø+G�Ô/U]Z�cdGIZ�j$H"NåL"j]l[NP×)ÛOUXH"NOH_\Pj>Z�ef×�Z�ÙfÔXGdH_NéÛPLVN<`fcdGINO^�iCL"k{GINO^�NPH`fG�� Z�UXZ�N<×0Z�Ó<Z�ÔwÚyZ�Z�N»NOH"UXiCLVc1L"NP`äL"ÓONOH_U]iCLVchZ�J"Z�N{Ô)j � ÚyZ�Ú�GIcdcS`fGIjX×0\<j]j�Ô]ÛPGIjCGÞjXj�\OZ�GIN`fZ0Ô)LVGIcÌcÞLKÔ]Z�U$H_N(��L"NP`Ø+Ó-Z�j]GÞ`fZ�j�Ø?L_j]j]Hf×0GÞLKÔ]GINO^(ÛPL"NP`fcIZ�U)j�Ú�GdÔ]Û ÔXÛOZ9ÙOUXHf×0Z�j]j>ÙPU]Hf×0Z�j]j]GINO^GdNfÖÝH_U]iCLVÔ]GIH"N(LVÙOÙ-Z�L"UXj�ÔXHCÓ<Z$J"Z�UXl9j�ÔXLVÔ]GÞ×VâPêhÚ�HCiRH"UXZ:GÞjXj�\OZ�j�Ú�GdÔ]Û�Ô]ÛPGIjSLVÙOÙOUXH_L_×)Û�L"U]Z_þÔ]ÛOZ�U]Z�GIj�H"NOZ�ÛPLVNPÒcdZ�U1ÖÝH"U:LVcIc?Ù-H_jXj]GdÓOcIZ�Z�ef×�Z�ÙfÔXGdH_NPjSUXL"GIj]Z�`�Ó[l(LCÙOUXH[×�Z�jXj�L"NP`�Ô]ÛPZ�UXZ�GIjNOHCj�\OÙPÙ<H_U�Ô�ÖÝH_U�UXL"GIj]GdNP^�Z�ef×�Z�ÙfÔXGdH_NPjhGIN�j]Z�J_Z�U)LVc ÙOUXHf×0Z�jXj]Z�j�â

b1NOH"Ô]ÛOZ�UpU]Z�cdZ�JKLVN{ÔpÚyH_U]k Ø�Ó[l»g�HKÚ1jwÔXU]H_Nó� ��·Øy×�H"NPj]GÞ`fZ�U)j/Ö¤LV\OcdÔ�á´Ô]H_cdZ�UXL"NP×0Z�ÖÝH_U9`fGÞjwáÔ]UXGdÓO\OÔ]Z�`éÔ]\OÙOcIZ�j]ÙPL_×0Z"Ø?GdNåÔ]ÛOZ9ÖÝUXL"i/Z�ÚyH_U]kßHVÖ1j�ÔXLKÔXGdH_NPLVUXlßL"^"Z�N_Ô)j�â ã Ô�GIN{Ô]UXH[Ò\P×0Z�j>Ô]ÛPZNOHVÔXGdH_NCHVÖP©ViRH_ÓOGdcIZ�×�H{H_UXÒGdNPLVÔ]GIH"N�©PØVÚ�ÛOZ�U]Z1iRH_ÓOGdcIZ1GÞj�UXZ�cÞLKÔXZ�`/Ô]H$Ô]ÛOZSiRHKJ"Z�iRZ�N_Ô�H"Ö+×0H"áH"U)`fGdN<LKÔ]GIH"NàÙOU]GIiRG�ÔXGdJ_Z�j�Ø-ÖÝH"UXi/GINO^9Ô]H"^_Z0ÔXÛOZ�UçL�×�H[H"U)`fGdN<LKÔ]GIH"N(H_Ù<Z�UXLVÔ]GIH"N¶Ø<Ô]H�Ô]ÛPZRj]Z�UXJ"Z�UjwÔXH"UXGdNO^pÔ]ÛOZ�Ô]\OÙPcdZ/j�ÙPL_×0Z_â-êhÛOZ�H"Ù-Z�U)LKÔXGdH_N(GIjSZ0efZ�×�\fÔ]Z�`àL_×�×0H_UXÒGdNO^RÔXH�L"NàLVcIc?H_U�NOH"Ô]ÛfáGdNO^(j]Z�iCLVN{ÔXGI×�j�Ø Ú�ÛOGÞ×)ÛßNPZ�J"Z�U�ÔXÛOZ�cIZ�jXjçLVcIcdHKÚ1j:GIN{Ô]Z�UXiRZ�`fGÞLKÔXZ$ÔX\OÙOcIZ�jçÔXH�Ó<ZCLMJKLVGIcIL"ÓOcIZ�GINÔ]ÛOZ(ÔX\OÙOcIZ�j�Ù<L"×0Z_â;�PL"\OcdÔ�á´Ô]H"cIZ�U)LVN<×0Z�ÖÝH"Upj]iCLVcIc�j�Z�^"iRZ�N{Ô)jCHVÖçÙOUXH"^"U)LViCj/GÞjRÔ]ÛOZ�NøU]Z�LVcdáGdW�Z�` Ó[l�Ô]U)LVN<jwÖÝZ�U]UXGdNP^�ÔXÛOZ9×�H"UXU]Z�j�Ù-H"NPÒGdNO^�ÙOUXGdiRGdÔ]GIJ"Z�j�Ø+L"NP` L"jXj�Hf×�GILVÔ]Z�` j�ÔXLKÔXZ"ØÔXH(Ô]ÛPZj�Z�U]J_Z�U�â+êhÛOGÞj/L"ÙOÙOUXH_L_×)Û ÒH{Z�j$NPHVÔ�Z�NPLVÓPcdZ9Ô]ÛOZ�ÙOUXH"ÙPL"^_LKÔXGdH_N HVÖ1Z0eO×�Z�ÙfÔXGdH_NPj�ØrGINéÔ]ÛOZ�GdUÔ]U)L"`fGdÔ]GIH"NPL"c�j]Z�N<j�Z_Ø?H_\fÔXj]GIÒZpÔ]ÛPZ�×�H{H_UXÒGdNPLVÔ]GIH"NéH_Ù<Z�UXLVÔ]GIH"N¶â Z HKÚ�Z�J_Z�U�Ø¶Ô]ÛPZ�L_Ò`fGdÔ]GIH"NPL"cNOHVÔXGdH_N(HVÖn©"LV^_Z�N{Ô1Ú�GIcdcK©CLVcIcdHKÚ1j�Ô]HCÙ-Z�U]ÖÝH"UXi j]H"iRZ>Z0eO×�Z�ÙfÔXGdH_N�Û<LVNP`fcIGINO^pH"\OÔXj]GI`fZ�×0H[H"U]á`fGdN<LKÔ]GIH"N<j�â�UÕGdcIcIj�LVUXZ�iCLVGINOcIl�\Pj]Z�`CÔ]H$×�cdZ�LVN[\OÙRÔ]ÛPZ1Ô]\PÙOcdZ:j�Ù<L"×0Z�GdÖ+LVNpL"^"Z�N_ÔÌÖ¤LVGIcIj�Ø_L"NP`LVUXZSL"jXj]H[×�GILVÔ]Z�`RÚ�G�ÔXÛ�L>ÔX\OÙOcIZ>j�ÙPL_×0Z_Ø{L"NP`RÔ]ÛPZ:jXLViRZ�Ú�GIcIc-GÞjhLVÙOÙPcdGIZ�`RÔXH/L"cdc-H"Ù-Z�U)LKÔXGdH_NPj�â

ô õ�Ò~ò[ÑÐwò�ò[ÒwÎÌÊ

ã N/H_\OU2ÖÝ\fÔX\OUXZ�ÚyH_U]k�Ú�ZhÙOcÞLVN/Ô]H�L"ÙOÙOcIl�Ô]ÛPZ�GI`fZ�L"j�ÒGIjX×0\PjXj]Z�`�GdNRÔXÛOZ�ÙPLVÙ-Z�U�ÖÝH"U�`fZ�J"Z�cIH"ÙOáGdNO^�LRNOHKJ"Z�cZ0eO×0Z�ÙfÔ]GIH"N(ÛPL"NP`fcIGdNP^Ci/Z�×)ÛPLVNPGIj]i=ÖÝH_Uq9+L"NPLOâ<ýSNPZ>Ô]H_ÙOGI×çH"Ö2H"\OU�ÖÝH_cdcIHKÚ�GINO^

��


55

ÚyH_U]k/Ú�GdcIc-Ó<Z:GdN{ÔXU]Hf`f\P×�GdNP^$UX\OcdZ�j2ÖÝH_U�jX×0H_ÙOGdNP^>Ô]H/GdN[J_H"cIJ"Z1LVcIc-ÙOU]Hf×�Z�jXj�Z�j2ÖÝUXH"i8Ô]ÛOZçjXLViRZj]×�H"Ù-Z(GdNÕ×0H[H_Ù<Z�UXLVÔ]GIJ"Z�ÛPLVNP`OcdGINO^éHVÖ>LVN[låZ�eO×0Z�ÙOÔ]GIH"NÕj�GI^"N<LVcIZ�`äÓ{l»LVN[låH"ÖSÔXÛOZ�i�âyb�cdcÙOU]Hf×�Z�jXj�Z�j�Ó-Z�cIH"NO^_GdNP^9ÔXH9ÔXÛOZCj]L"i/Z/cIH[×�LVcIG�Ôwl(GÞjSÔ]ÛOZRiRH_j�ÔçcdGIk"Z�cdl�×�LVNP`fGÞ`OLVÔ]Z�ÖÝH"UçGdN{ÔXU]H"á`f\P×0GINO^pjX×0H_ÙOGdNP^CU]\OcIZ�jhÓP\fÔ�Ú�Z�LVUXZç×�H"NPj]GÞ`fZ�UXGdNP^/H"Ô]ÛOZ�U1ÚhLMl[jhH"Ö�jX×0H_ÙOGINO^CL"j�Ú�Z�cIc�â<êhÛOGIjÚyH_\OcI`pU]Z�j�H_cdJ_Z�Ô]ÛOZSÖÝH"cIcIHKÚ�GdNO^�ÙOUXH"ÓOcIZ�i Ú�GdÔ]ÛpÔXÛOZçj�H_cd\fÔXGdH_NpÙOUXH"Ù-H_j]Z�`CGIN�Y[Z�×�ÔXGdH_NE5Oþ{Ú�ZGdiRÙOcIGI×�G�ÔXcdlpL_j]j]\OiRZ1ÛOZ�U]Z1Ô]ÛPLVÔÌÔ]ÛPZS×0H_NPj]\OiRZ�UyL"cdÚhLMlfj�`fZ�Ô]Z�×0ÔXj�LVNpZ�U]UXH"UyLVNP`pj]GI^"NPL"cIj�L"NZ0eO×0Z�ÙfÔ]GIH"NéÓ-Z0ÖÝH_U]ZpGdÔ�ÙPU]Hf`f\P×�Z�j�LVN[l�ÔX\OÙOcIZ9H"U�Ó<Z�ÖÝH"UXZpGdÔ/j�ÔXLVU]ÔXj$×0H"N<j�\OiRGINO^(ÔXÛOZ9NOZ�e[ÔÔ]\OÙOcIZ1á�Ú�ÛOGÞ×)ÛpGÞj�GINpZN� Z�×0ÔhL>J_Z�UXl�j�Ô]UXH"NO^�L"jXj�\OiRÙfÔXGdH_NRÖÝH"U�iCLVN[l�ÙPUXL_×�Ô]GÞ×�L"cPj]G�ÔX\PLKÔXGdH_NPj�â

ö ÷ÕÑ�ñhÊ�ÎPø.p¸r+Ïwg;mir+ÊyË

UßZpL"U]Z/^"U)LKÔXZ0ÖÝ\Oc�ÔXH�TåâPG2LMÚ�cIL"k(LVNP`8ISâP��U]lf×�Z$ÖÝH_UçÔ]ÛOZ�GdU>GIN[JML"cd\<LVÓOcIZC×0H"iRiRZ�N{Ô)jçU]Z�á^_LVU)`fGINO^Ü9+L"NPL>LVNP`/GdÔXjÌZ0eO×0Z�ÙfÔ]GIH"NRiRHf`fZ�c´â_b$â_g�H_iRL"NOHKJfj�k[l>GÞj2ÙPL"U�ÔXGIL"cdcIl�j]\OÙOÙ-H"U]Ô]Z�`�Ó[l GyYOglIl�6�wùAQçý:ê1YCG�UXH6�wZ�×0Ô�â_F/â[QSG-T�L"U]W�H$Y[Z�UX\O^_Z�NP`fH$GIjyj�\OÙPÙ<H_U�ÔXZ�`CÓ[lCY[Ú�GIjXj Û Y��^"U)LVN{Ôl?��0á¾Ó!��"�?6ÓPâ "�?fâ

f.rPúQr+Í�r+Ê�Ñ�rvò� û1oHû�ü?uv�"°)q�� oHû-ºy��)�Aý[��±{qX�Þ�"�-��s{� ¶ û�¹��A·�ûXþ<��s{�!ç�ÿys��²{²"uw�M��°�±�tw�/²_uw��³�u��>�>z}s{³��_tw��s_��>��{~>~·�"~·twq)�>~ ûé��s®üHû ¶ ��³�s"�_~v~v��sP��q��"z}tw��u�� ! "�#�%$��%&�'(�*)(+,+-�� .'��{|M��}�{�>q��(/M¹0�>��0213�54_�[²{��³�qX~��6"��7./98(6!û<�V²_uwz}s{³�qXuv��:?qXuw��³_�[�(898��6û

�û1�qû<o��;_uwz �(þPû�þPq)��s{��u��_z �<��s{�Cë3û=<P��,;f��s{q)�}�}z%û�ºyq)��°Xtwz}|Mq1tw�{²_��q�~v²[��°)q)~��I��u��>�(;{z}�}qç��³�q)sKt°)�K��u��_z}s[�0twz}��s(ûM�´s1½Dû)ºÌ��tw±_qXuw�>q)�M��s[�<ë3û��y��±{� ��q)�_z�tw��uw~)�(��%&��%$(�� .'(>�&*?@�� A$CB� "�#�!�� D)(�E��&� D)9FG &(�%H�>%I&!JK&( ,LM&��EFN�@O@'P�! "�E>w��|M��}�_�>qy�)�M¹�¹y��=0Q1,�54{��²{��³�qX~r��/M¹R7"��96!û"�V²_uwz}s{³�qXuv��:?q]uw�d��³_��RS9S966û

/6ûl¹�û{orz��s{°)��uwz}s{z ��ÿwûUT��>z}°)z}s{z �"��s{�@ë3û"<O��-;f��s{qX��}z%û¶or�K��u��_z}s[�0twz}��sC¼-qX°]±_s{��}��³�z}q)~2�Þ��u��´sKtwqXuv�s_qXtHÿy³�qXsVtw~ ûV1W&(�*$(��-X.&�Y�� D)(FQ&*?3��&(+ZJAY.�E�� .'��A[U\�/�]]�P��S(S9S6û

�!û1�qû_^hz ¶ ��uw�)�R�"qXuw�_³�q)s{�_�$��s{�íÿ<ûfºÌ��s_�0|"~¾·K�ûC^hq)~vz}³�s{z}s{³�� {��tv�Ýtw��}qXu��sKt��>�(;{z}�}qS~·�"~·�twq)�>~ û��sp�qûfºÌq)³�³�z}��µwûO��{qX�Äý<�O¸nû�ÿy~·twqX~vzd��s{�"�Oq��_z�tw��u��24D��! U�E� `V�a�� .'(�� D��!�!�� P'�?R&(��bW�c>! �E��Y.�#�%$dX.)(e�)fOVJ�JDF ��)(�E��&� ">�g�B� "�#�!�� D)��E��&( D)(F G &(�%H�>*IU&!JAh�ijB%baX(Bk�9��M�¶|M��_�>q��([98��0213�54_�{²{��³�qX~��R6�l�7V�(8V��û<�"²"uwz}s{³�q]uv�#:+qXuw��³"�f��898(/!û

lû ¶ ûZ^hz��WüHûyºy�U;{z}�_�y��s[�nm�û ¶ û�¼<uw��V�6ûo^hz}~·tvuwzp;{�"twq��.¹uw��³�u��>�>z}s{³à��z}tw±»�®þ<��³�z}°or±{��s{s_q)��;[��~vq)�Cor�K��u��"z�s{��twz}��s ¶ �V�"q)�%û-��&�+qJAY.�#�!�rX.&(Y.�! A)9F �"/9SU\·�R8�]]� �RS9S([!û

[6ûWm�û�üHû{��K�V�_qXs{��_³�±�û+¸*º"°)q)²"twz}��s/��s{�_�}z}s{³�ç"��~v~v�{q)~��s[�$�D¹¶uw��²f��~vq��$µ��t��twz}��s�ûW��&(+,+-YU U��)(�E��&( U>r&*?��cI"��Or�2Lp�P��6\·�0�(]~ç [(69/�7.[9S(["�¶��S�¹9lû

¹û1�qû�¹�û�¹¶z�°X°)��s{�R�qûOo��0t��}z}s_�¤ºÌ��s�ûvþ<z}�>q�ç�þ<z}s[�_�:�>q)qXtw~2�>�(;{z}�}z}t��û¶�´ss��*&��!��%$(�� P'(>-&*?B� U�#�!�! A)(�E��&( A)9F��&( �?��!�%�! D��3&( M4D&*?��EtV)��W�� .'(�� D��!�� P' ûO�·¸+¸?¸åor��>²{�_twq]uh�V�K°)z}qXt´�ì¹¶uwq)~v~)��RS9S9S6û

66ûlÿ<û{ºÌ��s{�0|V~¾·V�$��s[�sm!û[½�z}q)s{�X��q û]ÿÌ°Xtwz}��s_�¤��uwz�qXsVtwq)�/qQº"°)q)²"twz��sR±[��s[�"��z}s_³çz}sR°)�K��²fq]u��twz}|Mq��s[��°X��>²fqXtwz�twz}|Mqh°)��s_�¤°)�"uvuwq)sKt��9;.u·q)°Xtv�¤��uwz�qXsVtwq)�/~·�"~·twq)�>~ û¶�´séÿwû"ºy��s_��|V~¾·K�K�_oHûU^h��sK�K�m�û3þ<z}s{�_~¾·M�0|�½�sV�[�_~vqXs<�+��s{�Îÿ<ûr¼Puwz�²{��tw±_zÝ�?q��"z}tw��uw~)��O�$(e�)( A�!�!>�� v��w��!�#J"�E��&( yxa)� D$UF �c .'z �%��I. U��{�Y"�!>w�f|M��}�_�>q��(8��ç��j0Q1,�54{�_²[��³�q)~1�)�K¹R7[�R[9/!ûO�"²_uwz}s_³�qXuv��:+qXuw��³_�[�(8(8"� û

S6ûlÿ<û[ºÌ�0��~·tvuw��s(û ¶ �9;_z}��q�°)��u��_z}s[�0twz}��s(ç�¹¶uw�0|Vz��_z}s{³>� ��{��tv�Ýtw��}qXu��s{°)q�z}sRtw�{²{�}q1~v²[��°)qr;[��~vq)�°)��¤��u��_z}s{��twz}��s9��s{³��[��³�q)~ û��´sC¹�ûPorz��s_°��uwz}s{z+��s[�ìÿwû"|��Oq��_z�tw��uw~)�V��&�&(�%$(�c D)(�E��&� M02)( " '(YU)�'P�!>�)� D$ZL}&�$P��F >�~��&�&(�*$(�� D)��E��&( D�9��|M��}�{�>q��l�S��y��_0213�54_�0²[��³�q)~��RS9[�7V�V�R8!ûM�"²_uwz}s_³�qXuv�:+qXuw��³"�-��S(S9S6û

�>?


56

Primitives and Mechanisms of the Guardian Model forException Handling in Distributed Systems

Robert Miller and Anand Tripathi

University of Minnesota, Computer Science Department,,Minneapolis, MN 55455 USA

{rmiller, tripathi}@cs.umn.edu

Abstract. We believe the fundamental problem with distributed exception han-dling is invoking the semantically correct exception handlers in all the distrib-uted processes that are required to participate in the recovery. Existing distrib-uted exception handling techniques emphasize raising the same exception in allthe required processes with a transaction-like program structure. As useful asthat is, there are many applications that do fit easily into that paradigm. A singleraised exception must be able to represent adequately all concurrently signaledexceptions, and a transaction-like structure may be too rigid for an application.We present the primitives and mechanisms for an abstraction called guardianfor exception handling in distributed systems that can overcome those limita-tions. Using an example, we show how the guardian can be used to augmentand enhance an existing distributed exception model.

1 Introduction

This paper discusses the primitives and mechanisms of the guardian exception han-dling model for distributed systems. The conceptual foundations of the guardianmodel were presented in [6], and in [7] the initial set of guardian primitives was intro-duced. In this paper, the full set of guardian primitives and mechanisms are described,and an example using the guardian that shows how it can augment or enhance an ex-isting distributed exception handling model is shown.

Exception handling in distributed systems differs significantly from sequential ex-ception handling. In [9] two reasons are given: distributed systems need exceptionhandler communication and coordination, and multiple exceptions may be concur-rently signaled. Concurrent exception models have the capability of handling concur-rently signaled exceptions, and are based on exception resolution and a programstructure based on transaction-like semantics [1]. Exception resolution translates ormaps concurrent exceptions into one exception (a resolved or concerted exception).An exception that is to be signaled to the processes (the participants) of a distributedapplication is called an external exception. An exception that is handled locally in theprocess is an internal exception. Examples of concurrent exception models are CAactions [9], Arche [3], OMTT [4], and conversations [1].


57

Concurrent exception models assume that a semantically correct handler is invokedin each participant. To allow this, the exception is raised in all participants, includingthe signaling participant. Since a distributed system is asynchronous, it is possible forone participant to have a different exception handler enabled than another participant.Relying on handler communication to ensure the correct handlers are invoked may bea highly complex task. To simplify this, concurrent exception models assume a pro-gram is structured in such a way as to ensure that the correct handlers are invoked sohandler communication is not required. Typically, the structure is transaction-like thathas synchronized entry and exit points. Any external exceptions raised in a participantare within that boundary. Because all participants are executing within the sameboundaries, it can be assured that the correct handler is invoked in all participants.

The next section describes the limitations of the existing concurrent exception han-dling models. Section 3 describes the programming primitives and mechanisms for theguardian model. Section 4 presents an example using this model, and finally Section 5concludes this paper.

2 The Problem

Concurrent exception models have a defined behavior for concurrently signaled ex-ceptions, and exception handlers coordinate not by direct communication, but byhaving handlers for the same exception invoked in all the participants. However, thereare still three limitations with these models.

First, concurrently signaled exceptions are assumed to be related in some way sothat a meaningful resolved exception may be obtained. This is not always easy to do[8]. Secondly, external exceptions are signaled explicitly from a participant, so excep-tion conditions outside the participants may not be detected. Finally, there is the re-striction of a transaction-like program structure. Transaction-like structure is useful inmany applications, but there are also other applications that have an asynchronousaspect to them, such as management or monitoring applications, where such a struc-ture may be difficult to apply.

We believe the problem with distributed exception handling is invoking the se-mantically correct handler in each participant. Determining the correct handler is themain issue, and not the raising of exceptions. In the guardian model, determination ofthe correct handler is by using the guardian to direct each process to a correct excep-tion handler by raising in each process a possibly different exception and specifyingthe context in which it should be handled by the process. This is different from theapproach of concurrent exception models, in which the same exception is raised in allprocesses that need to participate in the recovery.

The purpose of allowing different exceptions to be raised in each participant is toallow the guardian to orchestrate the recovery action. A raised exception implies aspecific recovery action a participant is to do. For example, say there is a pipeline ofthree processes A, B, and C. Should B fail, the guardian would signal to A an excep-tion that its downstream neighbor has failed, and to C an exception that its upstreamneighbor has failed. With a guardian, participants are freed from the burden of main-


58

taining any configuration information and relating it to a process failure to determinethe semantically correct recovery action. No transaction-like structure is needed forthe correct exception handlers to be invoked (though that structure may be useful forother reasons).

3 The Guardian Model

The guardian exception handling model [6] [7] is based on the timed asynchronouscomputation model [2], global exception handlers, separation of global exceptionhandling from the exception handling local to a process, and an extended fault model.The guardian is a distributed global entity that orchestrates the exception handlingaction by directing each involved process. The directing is by raising in a process anappropriate exception, which may differ from the exception raised in another process.Application defined recovery rules determine the exception the guardian raises in eachparticipant, which in turn causes the correct exception handler to be invoked. Theguardian model has three elements: the concept of an exception context, a global en-tity called a guardian, and a set of guardian primitives that the participants use.

3.1 Exception Context

An exception context is an execution phase or region of a program. Contexts may benested by a process entering a new context reflecting the static structure of the pro-gram (as nested blocks), or the dynamic function call sequence. Contexts are applica-tion specified as a symbolic name, and so they may have different meanings based onthe application. A context may be used to represent a number of different abstractionssuch as an invocation stack frame, checkpoint, recovery block, transaction or conver-sation context, a barrier synchronization point, or an assert point.

The raising context is the context a process is in when an exception is raised in it.A target context is the context that an exception is to be handled in. There is a re-served context called Init, which is used as top-level context. Its purpose is to allow aprocess to have a context before it defines one, and to have a target context to preventa process from handling an exception, such as a terminate exception.

The purpose of contexts is to provide a mechanism to invoke correct exceptionhandlers. This is done in two ways. First, when an exception is raised in a process, atarget context is specified in the exception object, since the raising context and thetarget context may not be the same. Second, contexts provide a means to give a dy-namic meaning to an exception based on the current program flow, similar to a dy-namic call chain.

3.2 The Global Exception Handling Model

The basic elements of the guardian model are shown in Figure 1. Each process, suchas Pi., in the application is a participant. The guardian is logically replicated at all


59

participant environments Ei with a guardian member GMi as a co-process. Theguardian members form a process group implementing the global abstraction for itsguardian.

The members in this group communicate with each other using reliable groupcommunication primitives. Group messages are delivered and processed within timebounds; if the bound is not met then the message is considered lost [2]. Groups allowfor reliable and totally ordered message delivery within the bounds and support virtualsynchrony (i.e., membership change messages are ordered with all other messages).The guardian defines membership exceptions, which indicate a change in the member-ship of the guardian group. The guardian raises an exception when a participant joinsor leaves the activity.

The guardian supports global exception handling in the following manner:1. Using the guardian method enableContext, a participant defines a context and the

exceptions that the context can handle. The guardian member for the participantmaintains a stack of these contexts and the related set of exceptions. When acontext is returned from, the participant invokes removeContext which pops thelast context from the stack. A program typically has a small number of contexts,where each context represents a recoverable block, such as a try-catch. Each par-ticipant may have a different context stack.

2. When a participant signals a global exception, it invokes a guardian methodcalled gthrow. The participant blocks in gthrow until an exception is raised. Theassociated guardian member sends a message that represents the exception to theother guardian members through the guardian group. If exceptions are signaledsimultaneously by multiple participants, then group communication orders the re-spective messages for all guardian members

3. When a guardian member receives the exception message from its group, itchecks if its associated participant is suspended. If the participant is not, then theguardian member suspends the participant. This ensures that all concurrently sig-naled exceptions are known to the guardian.

4. To suspend a participant that supports interrupts, the guardian member interruptsthe participant, and the interrupt handler invokes a guardian method calledcheckExceptionStatus. The method checks if there are any exceptions that have tobe delivered to the participant. If not, the method returns, otherwise the methodblocks until an exception is raised from it. No group communication is used forthe check. To suspend a participant that does not support interrupts, the partici-pant periodically invokes checkExceptionStatus.

5. As each participant is suspended, the guardian assembles all the participant con-text lists together. Once all participants are suspended, the guardian invokes ap-plication-defined recovery rules, for example exception handling patterns [5].

6. The guardian provides to the recovery rules the exceptions signaled, and all con-text lists. A matching rule defines, for each participant, the target context and ex-ception to raise in that participant. The guardian members collectively raise intheir respective participants the exceptions defined by the rules.

7. After the exception is raised in a participant, exception handlers are searched inthe participant. Each handler is expected to invoke the guardian method propa-gate, which returns to the handler whether it should handle the exception or


60

orfoco

teasththgr

Wtirea itthre

3.

Arecurupaw

pa


if signaled exception is E then { for each specified identifier expression Pe do { let PL be the list of participants satisfying Pe; for each specified selection predicate S do { let Ps be the subset of PL satisfying S; for each participant p in Ps do {

someComputation();//insert exception object in Output Exception ListOEL.insert(p, Ep(Cp));

} } }}

Fig. 1. Single exception rule structure

propagate it. The method simply compares the exception target context with thehandler’s context.

The recovery rules may map a single signaled exception into a different exception target context on each participant. Typical exception resolution is possible by trans-rming all the concurrently signaled exceptions into the same exception and targetntext in all participants.The guardian also supports the notion of an interrupt with the methods enableIn-

rrupts and disableInterrupts. It is assumed a guardian member may interrupt itssociated participant, and the participant invokes an interrupt handler that can querye guardian to determine if the interrupt is from the guardian. If the interrupt is due toe guardian, then the interrupt handler can signal an exception to the participant pro-am. This is similar to the Java model of interrupt using the interrupt method.

If a participant has interrupts enabled, then checkExceptionStatus does not block.hen a participant receives an interrupt, the interrupt handler invokes checkExcep-

onStatus. If the interrupt is due to the guardian, then an exception message has al-ady been sent, and checkExceptionStatus will throw the exception received. Shouldparticipant execute gthrow with interrupts enabled, then gthrow returns after sendings exception message to the guardian. When an interrupt from the guardian occurs ine participant, checkExceptionStatus is invoked as explained above that signals theceived exception.

3 Recovery Rules

program extends the guardian with application-specific rules. The rules are logicallyplicated with each guardian member. The rules mechanism has as its input all con-rrently signaled exception objects, and the context stack for each participant. Theles mechanism outputs a list of exception objects: one object to be raised in eachrticipant that matches the rule. Each exception object contains the target context inhich the participant should handle the exception.

Participants are identified using their contexts rather than fixed symbolic names. Articipant identifier is a context list expressed as slash-separated context names. An

61

if (E is a subset of the signaled exceptions)OSL.insert(exceptionResolution(E));

Fig. 2. Concurrent exception rule structure

identifier represents a subset of participants whose current context matches the speci-fied identifier.

A fully qualified identifier includes the entire context as the identifier, while a par-tially qualified identifier is expressed as a regular expression of context names. Forexample, a context stack C1→C2→C3 has a fully qualified identifier as C1/C2/C3.Using a partially qualified identifier allows greater flexibility in identifying a subset ofparticipants, e.g., */C2 matches all participants whose current context is C2.

There are two kinds of rules, one for single exceptions, and the other for multipleconcurrent exceptions. Rules are searched in lexical order, with concurrent exceptionrules first. A rule for a single exception constructs a list of exceptions, one exceptionobject that the guardian will raise for each member of a set of participants.

The general structure of a single exception rule is in Figure 1. For a given signaledexception, one or more identifier expressions Pe are evaluated serially. The list PL ofparticipants is constructed for each Pe by matching the context lists of the current setof participants with Pe. For each selection predicate S, a subset PS of PL is computedusing S. Furthermore, for each participant in PS, the guardian may perform some ap-plication-specific computation to determine the exception to be raised in that partici-pant. The guardian then adds that exception to the Output Exception List (OEL). InFigure 1, for participant p an exception object of type Ep with target context CP isadded to the list.

After the guardian has completed building the OEL by executing all applicablerules, it raises each of the exception objects in this list in the correspondingly specifiedparticipant. Each exception object specifies the target context in which the participantshould handle the exception.

For concurrent exceptions, the guardian provides flexible exception resolution thatcan be used with existing exception resolution methods or new ones, such as the high-est priority exception or to serially apply the concurrent exceptions to the sequentialrules. The application defines N levels of priority, with level 0 the highest priority.Each exception that may be signaled is assigned a priority, with a default prioritybeing the lowest level (N-1). The conversation and Arche models would use only onelevel.

When exceptions are signaled concurrently, the exceptions are first sorted by pri-ority level. After the sort there is a vector of priority levels, with each level having aset of signaled exceptions for that level. Each level, in priority order with level 0 first,has the concurrent rules applied to the signaled exceptions at that level. Figure 2shows the general concurrent exception rule structure. Note that E in Figure 2 is a setof one or more exceptions, and all exceptions specified by E must be in the currentlysignaled set of exceptions. A concurrent rule for resolved or concerted exceptions usesa value of E or null, since null is a member of all signaled exceptions sets.

The concurrent rule uses an application-defined resolution function that outputszero or more exception objects that are put on the Output Sequential List (OSL). As


62

each priority level has the concurrent rules applied to it, the sequential exception ob-jects from that level are appended to the OSL. When all levels have been processed,there is one OSL that has all the exception objects in priority order that the sequentialrules are applied to serially. To the sequential rules, each exception object on the OSLappears as though an exception had been signaled by a participant.

The guardian defines a default rule of exception resolution by finding the root ofthe smallest sub-tree that contains all the concurrently signaled exceptions. This is thesame rule as conversations and CA actions use.

3.4 Guardian Model Comparison

As has been discussed above, the two main differences between the guardian modeland other models is that the guardian may raise different exceptions in each participantand a context is used to determine at what execution point a program is at. This hasseveral implications.

First, the guardian model is not meant to replace a program’s structure. Theguardian model can be used to implement an exception model in a rules-based way.For example, a context is not meant to replace a conversation, but rather can be usedto implement a conversation. Second, there is no known exception model that is suit-able for all known exceptional conditions. A guardian allows the exception model tobe changed during a program to better match the program’s exception handling to thecurrent execution phase of the program. Third, a model implemented using the guard-ian may be enhanced, such as with increased error detection capability (e.g., partici-pant death or other system-types of exceptions). Fourth, a guardian is rule-based,meaning the exception handling intelligence could be partially removed from a pro-gram and placed in a system repository, particularly for conditions that require so-phisticated actions. Programs that were not designed to have coordinated recoverycould through if the programs are using the same guardian. If some contexts and re-covery actions can be standardized or predefined, then a program gets these behaviorsthrough the system, and so different systems can tailor the behavior. Fifth, exceptionscould be used to indicate non-error situations, such as warnings of abnormal behaviorthat is not an error (such as an input being at a limit of the input’s range).

The guardian also has disadvantages. For contexts to be meaningful, a programstructure is needed that a context can be associated with. In order for different pro-grams to use the same guardian concurrently or for system-defined guardian rules thatcan augment a program’s rules, the context names need to be well-defined so that theguardian rules do not become confused.

4 An Example of Guardian Programming

The guardian model is not meant to replace existing exception handling models, butrather to enhance them. An example of this is with the conversation model. The nor-mal conversation model can only detect failures that are explicitly signaled by a par-ticipant. For example, unexpected participant termination is not detected. Using the


63

gu(smormia

enTtithra

sasi

thcoPOPes

wprTrepa

5

Tpa


Guardian myG;GuardianBarrier b;Context c1 = new Context("Conv", GlobalException); myG.enableContext(c1); try { myG.enableInterrupts(); b.barrier(myG); myG.disableInterrupts(); doWork(); if (error) myG.gthrow(new GlobalException(‘Error’); myG.enableInterrupts(); b.barrier(myG); return; } catch(GlobalException ge) { if (myG.propagate()) throw; doCleanup(); }

Fig. 3. Conversation using a guardian

ardian to implement conversations, failures detected by the guardian fault modeluch as unexpected participant termination) are signaled as global exceptions auto-atically. The guardian model can also sustain K of N failures at a synchronized entry exit point, while the conversation model can not. Lastly, implementing a relatedodel, such as CA actions or OMTT, is mostly accomplished by changing the guard-n rules.

Figure 3 shows how a guardian can implement a conversation. The conversationtry and exit points are implemented using a barrier that has been guardian-enabled.

he enableInterrupts method allows the barrier to be interrupted with a global excep-on. The barrier is modified to check for a global exception if it is interrupted. Aftere barrier, disableInterrupts is invoked to preserve the conversation semantics ofising an external exception at exit points.

Each conversation is represented by an exception context. In Figure 3, the conver-tion has the context Conv. If a nested conversation is used, then the nested contextmply has a different name, such as Conv2. The full context name is Conv/Conv2.

To see how contexts are used, say there are three processes P1, P2, and P3. Allree processes are in the outer conversation Conv, and P1 and P2 are in a nestednversation Conv2. Should P1 signal a global exception, it should only be raised in

1 and P2. When P1 signals the exception, it has a target context of Conv/Conv2.nly P1 and P2 are in that context (P1 is in Conv), so the exception is raised only in1 and P2. The target context could also be specified as */Conv2 to indicate all proc-ses that are in the conversation Conv2.

If the exception is unhandled in Conv2, then the guardian re-raises the exceptionith target context Conv (the next enclosing context). It can be seen that now all threeocesses will have the exception raised in them.he guardian recovery rules for conversations use the default rules. Multiple concur-ntly signaled exceptions are resolved into one resolved exception, and each partici-nt has the same exception raised in it as all other participants.

Summary and Conclusions

he conceptual foundations of the guardian model were presented in [6], and in thisper we have presented the details of its programming primitives and its runtime

64

execution model. To understand the limitations of the existing distributed exceptionhandling models, we have analyzed distributed exception handling requirements withrespect to sequential exception handling models. Three basic differences betweendistributed and sequential exception handling are identified. This leads to what weconsider is the fundamental problem with distributed exception handling: each af-fected process must invoke the correct exception handler.

We have shown how the guardian model for distributed exception handling ad-dresses this fundamental problem using the concept of exception contexts and a set ofprogramming primitives supported by a global exception handler called the guardian.We currently have a test implementation using multiple, distributed Java virtual ma-chines. Future work includes incorporating the guardian in a Java-based agent pro-gramming system, and formalizing the guardian model.

6 Acknowledgements

This work was partially supported by NSF grants ANI 0087514 and ITR 0082215.Sujay Patankar extended the guardian model to include multiple JVM instances.

References

1. Campbell, R. H., Randell, B.: Error Recovery in Asynchronous Systems. IEEE Transactionson Software Engineering, Vol. 12, (1986) 811-826.

2. Cristian, F., Fetzer, C.: The timed asynchronous distributed system model. IEEE Transac-tions on Parallel and Distributed Systems, Vol. 10, (1999) 642-657.

3. Issarny, V.: An Exception Handling Mechanism for Parallel Object-Oriented Programming:Toward Reusable, Robust Distributed Software. Journal of Object Oriented Programming,Vol. 6, (1993) 29-40.

4. Kienzle, J., Romanovsky, A., Strohmeier, A.: Open multithreaded transactions: keepingthreads and exceptions under control. 6th International Workshop on Object-Oriented RealTime Dependable Systems (2001) 197-205.

5. Klein, M., Dellarocas, C.: Exception handling in agent systems. Third International Confer-ence on Autonomous Agents (1999) 62-68.

6. Miller, R., Tripathi, A.: Exception Handling in Timed Asynchronous Systems. In: Ezhilchel-van, P., Romanovsky, A (eds): Concurrency in Dependable Computing. Kluwer (2002) 209-227.

7. Miller, R., Tripathi, A.: The Guardian Model for Exception Handling in Distributed Systems.Symposium on Reliable and Distributed Computing, (2002) 304-313.

8. Xu, J., Randell, B., Romanovsky, A., Stroud, R.J., Zorzo, A.F., Canver, E., von Henke, F.:Rigorous development of a safety-criticial system based on coordinated atomic actions. 29thInternational Symposium on Fault-Tolerant Computing, (1999) 68-75.

9. Xu, J., Romanovsky, A., Randell, B.: Concurrent Exception Handling and Resolution inDistributed Object Systems. IEEE Transactions on Parallel and Distributed Systems, Vol.11, (2000) 1019-1031.


65

Component Integration using Composition Contracts with Exception Handling

Ricardo de Mendonça da Silva, Paulo Asterio de C. Guerra, and Cecília M. F. Rubira

Instituto de Computação - Universidade Estadual de Campinas C.P. 6176, Campinas, SP, Brazil, 13084-971.

{ricardo.silva, asterio, cmrubira}@ic.unicamp.br

Abstract. The development of modern software systems usually needs to inte-grate autonomous component-systems which are developed independently from each other. Examples of such component-systems include COTS components, legacy software systems and Web Services. For developing this new kind of software system, we need innovative software engineering approaches that rely on the system's software architecture to achieve the desired quality properties of the resulting system, such as fault tolerance. In this paper, we propose an archi-tectural approach to the dependable composition of component-systems based on composition contracts and an exception handling scheme which considers the concurrent execution of architectural components.

1 Introduction

Modern software systems, such as e-commerce and e-banking, usually are developed integrating component-systems, which are autonomous systems developed, main-tained and concurrently operated by independent organizations. In a rapid changing world, these new software systems should be easily adaptable to changes in the busi-ness rules [6]. Moreover, many of these new software systems are becoming safety-critical because financial loss and even life loss can result from their failure [1].

In general, no assumptions can be made about the internal design and implementa-tion of a component-system. For instance, when integrating a web service [2] whose actual implementation is dynamically bound at run-time, the only information avail-able to the system integrator is the specification of the public interface. So, there are no guarantees about the quality attributes of the actual implementation, such as its correctness, availability and reliability. This implies that: in order to achieve quality properties, such as adaptability and dependability, we should focus on solutions mainly at the software architecture.

The proposed approach employs the C2 architectural style [4], which is a compo-nent-based style directed at supporting large grain reuse and flexible component com-position, emphasizing weak bindings between them. By architectural style we mean a set of design rules that identify the kinds of components and connectors that may be used to compose a system or subsystem, together with local or global constraints on the way the composition is done [5].


66

In this paper, we propose an architectural approach to the fault-tolerant composi-tion of concurrent component-systems, based on composition contracts. A composi-tion contract extends the concept of coordination contracts [6] to include an excep-tion handling scheme based on Coordinated Atomic Action (CA Action) [3]. A coordination contract is a connection that can be established between a group of ob-jects through which rules and constraints are imposed on their collaboration, thus en-forcing specific forms of interaction or adaptation to new requirements [6]. In es-sence, a coordination contract consists of a prescription of coordination effects that will be imposed on a collection of partners when the occurrence of one of the contract triggers is detected in the system. Coordinated Atomic Actions (CA Actions) [3] is a mechanism for structuring fault-tolerant concurrent systems that unifies the notions of forward and backward error recovery into its exception handling schema.

The rest of this paper is organised as follows. Section 2 gives a brief overview of how we have adapted the CA Action concept to obtain fault tolerance in component integration. Section 3 provides an overview of the C2 Architectural Style. Section 4 presents a software architecture that uses composition contracts with exception han-dling to build composite systems. Section 5 shows a case study illustrating the behav-ior of a fault-tolerant system. Finally, section 6 summarizes the conclusions of this work and discusses related work.

2 Exception Handling in CA Actions

A CA Action is designed as a multi-entry unit with roles which are bound to action participants which cooperate within the CA Action. The action starts when all roles have been activated and finishes when all of them reach the action end. If a partici-pant raises an exception within a CA action, appropriate recovery measures should be invoked cooperatively, by all the participants, in order to reach some mutually consis-tent exception handling. A resolution scheme is used to combine multiple exceptions into a single exception if they are raised at the same time. The participants may ini-tially apply a forward error recovery strategy aiming to mask the exception and com-plete the CA Action successfully, either with a normal result or a degraded (excep-tional) one. If this initial strategy fails then the CA action should trigger backward error recovery in their participants in order to undo the undesired effects. If the CA Action cannot complete successfully but is able to restore its initial state, then the ac-tion is aborted, otherwise it fails.

Composition contracts differ from CA Action in allowing the component-systems to interact with external objects that are not transactional. This implies that a composition contract will guarantee only atomicity and consistency of its services, not embracing the full set of the ACID properties (atomicity, consistency, isolation, durability) of a CA Action. Systems can be designed recursively using action nesting. Fault tolerance features are always associated with such units confining all errors. When an action is not able to mask an error an exception is propagated to the containing action. This exception may be an abort exception, when the participants are left in a state free of effects of the action, or a failure exception otherwise, when the undo fails. In this last case the containing action is responsible for recovering the system state.


67

3 The C2 Architectural Style

In C2 architectural style, components of a system may be completely unaware of each other. The components communicate only through asynchronous messages mediated by connectors that are responsible for message routing, broadcasting and filtering. Both components and connectors have a top interface and a bottom interface. Systems are composed in a layered style. The top interface of a component may be connected to the bottom interface of a single connector. The bottom interface of a component may be connected to the top interface of another single connector. Each side of a con-nector may be connected to any number of components or connectors.

There are two types of messages in C2: requests and notifications. By convention, requests flow up through the system's layers and notifications flow down. In response to a request, a component may emit a notification back to the components below, through its bottom interface. Upon receiving a notification, a component may react, as if a service was requested, with the implicit invocation of one of its operations.

4 The Proposed Architecture

The proposed software architecture is organized in three layers (Figure 1). The com-putational layer encapsulates the service interfaces of component-systems, called par-ticipant components. Examples of participant components include COTS components, legacy systems and Web services. The coordination layer consists of a composition connector that mediates the interactions between computational layer and the applica-tion layer. The top interface of the composition connector, or basic service interface, is the sum of all the participant service interfaces. The composition connector may impose business rules to the basic service interface providing new composite services. The bottom interface of the composition connector, or composite service interface, is the sum of the basic service interface and the new composite services provided by the composition connector. The composite service interface also adds fault tolerance to its new services. The application layer contains the components that implement the ap-plication logic (client components) and that may use the composite service interface.

Participant Component 1

Participant Component 2

Participant Component m

....

Composition Connectorcomposite service interface

basic service interface

Client Components

Computational Layer

Coordination Layer

Application Layer

participant service interfaces

Fig. 1. Software Architecture using C2 style

The composition connector is a C2 connector built from an interceptor component and a set of composition contract components (Figure 2). A composition contract de-fines a set of related composite services. In this context, a composite service specifies


68

an action that may be required to add new business rules upon a service. The compos-ite service can extends a single basic service or it can compose a more sophisticated service, which defines a coordinated action of two or more participant components. The composition contract components can be organized in various contract layers that are connected by specialised C2 connectors. Figure 2 shows a composition connector with two contract layers. The composition contract components are responsible for: (i) to provide new composite services; (ii) to impose the business rules upon basic and composite services; and (iii) to implement fault-tolerance for basic and composite services. This is done by means of the fault-tolerant composition of one or more basic services. The composition contract components of a contract layer can use composite services provided by contract components located at upper contract layers, allowing action nesting. The interceptor component is responsible for monitoring the events flow at the basic service interface and activating the composition contract components when needed.

Participant Connector

Interceptor Component

Interceptor Connector

Composition Contract 2_2

Contract Connector


Client Connector





composite services interface

basic services interface

Fig. 2. Basic Structure of the Composition Connector

4.1 The Composition Contract Component

A composition contract component implements a composition contract as a CA Ac-tion relaxed in its transactional requirements over the participant components to guar-antee the atomicity of the composite services. A composition contract is activated by a notification of an event associated with a contract trigger. This notification is sent by the interceptor component. The activation of a composition contract implies in the implicit invocation of an associated composite service. The invocation of a composite service normally results in one or more service requests accordingly with the coordi-nation rules defined by the composition contract. The service requests can be concur-rently executed. Moreover, they may activate composition contract components in-cluded in upper contract layers, creating nested CA Actions.

When a composite service completes successfully it ends either with a normal noti-fication or, if its result is degraded, an exceptional notification. If an exception is raised by a requested service, the composition contract component collects the re-sponses from the services and activates an exception handler component. The excep-


69

tion handler component resolves the raised exceptions and coordinates the appropriate recovery actions that should be taken by the participant components. If the excep-tional condition cannot be masked, the composition contract component reacts with: (i) an abort notification, if the participants are recovered successfully, or (ii) a failure notification, if one or more participants are left in an inconsistent state.

The composition contract definition is shown in Figure 3a. The attributes clause specifies the configuration parameters an instance of a composition contract. The co-ordination clause specifies a list of interactions which defines how the participant com-ponents cooperate to perform a particular composite service (Figure 3b). The condi-tion after the when clause specifies the contract trigger for this interaction. The do clause specifies a set of actions to be concurrently executed by the participant compo-nents. The raises clause specifies the types of exceptions that may be raised during the execution of the interaction.

contract <contract_name> { attributes <list_of_attributes> coordination <list_of_interactions> end contract

(a) The contract definition

<interaction name>: when (<condition>) do <set_of_actions> raises <list_of_exceptions>

(b) The interaction definition

Fig. 3. The composition contract definition

4.2 The Interceptor Component

The interceptor component acts like a proxy object intercepting the messages sent to the participant components. It is responsible for notifying the composition contract components that a contract trigger was enabled. Currently, we consider that only ser-vice requests enable contract triggers. These notification messages contain the service request and the parameters of the composition contract being activated.

4.3 The Exception Handler Component

In our model, an architectural component can be a participant component, an intercep-tor component or a composition contract component. It is composed of two subcom-ponents: a NormalActivity component and an ExceptionHandler component (Figure 4). The NormalActivity component implements the normal behaviour of an architectural component, when no exceptions occur. The ExceptionHandler component is responsible for: (i) handling exceptions raised by its associated NormalActivity component; and (ii) providing handler services.

More specifically, the ExceptionHandler component of a participant component im-plements handler services to undo operations that affect the participant's state. The ExceptionHandler component of the interceptor component can handle system configu-ration errors. The ExceptionHandler component of a composition contract component coordinates the activation of handler services of the participant components. The Ex-ceptionHandler component implements the exceptional contract defined for the compo-sition contract (Figure 5). The ExceptionHandler component of a composition contract tries to mask an exception and return the control flow to the NormalActivity component


70

using a forward error recovery strategy. If this strategy fails the ExceptionHandler com-ponent starts backward error recovery executing compensation action to undo unde-sirable effects over the participant components, when possible

Exception Handler Component

C2 Connector 2

Normal Activity Component

C2 Connector 3

C2 Connector 1

Fig. 4. Architectural Component

exceptional contract <contract_name> { attributes <list_of_attributes> coordination <list_of_handlers> end contract

Fig. 5. Exception Handler Component Definition

5 Case Study

This case study illustrates the behavior of a fault-tolerant banking account system ap-plying the software architecture described in this paper.This case study integrates two autonomous components: the Checking Account component and the Savings Account component, which wrap existing (off-the-shelf) components providing operations to withdraw and to get the current balance.

The system-specific business rules are enforced through a single composition con-tract that is the FlexibleContract. The FlexibleContract tries to avoid overdrafts in the CheckingAccoung using funds from an associated SavingsAccount, when needed.

Client Component FlexibleContract Interceptor CheckingAccount

SavingsAccount

withdraw, ca, 100

withdraw, sa, 25

withdraw, ca, 100

getBalance, ca getBalance, ca

balance = 75 balance = 75

withdraw, ca, 75

withdraw, ca, 75

withdraw, ca, Ok

withdraw, sa, 25

AbortException, sa

withdraw, ca, Ok

AbortException, sa

resolveException

SaWithdrawAbort, sa, 25

SaWithdrawAbort, ca, 25

SaWithdrawAbort, sa, 25

SaWithdrawAbort, ca, 25

withdraw, ca, 25 AccountOverdrawn, ca,

AccountOverdrawn, ca, AccountOverdrawn, ca,

request message

notification message

Fig. 6. Sequence diagram for the scenario


71

The sequence diagram in Figure 6 shows the processing of a request to withdraw an amount of $100 from a checking account "ca" which is associated with a savings account "sa" by means of a flexible contract. Initially, the FlexibleContract component checks the balance of "ca", which in this example is only $75. So, the FlexibleContract tries to satisfy the original request by means of two concurrent withdrawals: $75 from "ca" and $25 from "sa". In this example the SavingsAccount component refuses this second withdrawal and raises an AbortException. The FlexibleContract resolves the ex-ceptions and sends a SaOverdrawAborted exception to both SavingsAccount and Checkin-gAccount components. The SavingsAccount ignores this exception. The CheckingAccount handles this exception with a self-invocation of a $25 withdrawal. This recovery ac-tion leaves "ca" overdrawn. The Client component is notified of this degraded result by means of an AccountOverdrawn exception that is propagated by the FlexibleContract component.

6 Conclusions and Related Work

In this work, we propose an architectural solution for the development of dependable software systems out of concurrent autonomous component-systems. This solution favours the adaptability, extensibility and reliability attributes of the resulting system. The concepts of coordination contracts and CA Actions were adapted to a service-oriented approach applied to the system's software architecture.

The WSCA (Web Service Composition Action) concept also exploits the concept of CA Actions to enable the dependable composition of Web Services [7]. The pri-mary difference between our work and the WCSA concept is that our approach also includes concerns about coordination contract, which improves the adaptability, and an architectural design to be applied to a more general class of service-based systems, not only restricted to Web Services.

Similarly to our approach, Pires [8] proposes an architectural solution for providing reliable Web services compositions using a layered architectural style. However, this work only provides backward error recovery, not considering concurrent exception handling.

Acknowledgments

This work was supported by FAPESP/Brazil under grant no. 01/06064-3 for Ricardo Silva, and by CNPq/Brazil under grant no. 351592/97-0 for Cecília Rubira. Paulo Guerra is partially sup-ported by CAPES/Brazil

References

1. Knight, J.C. SafetyCritical Systems: Challenges and Directions (summary of state-of-the-art presentation). International Conference on Software Engineering, Orlando, FL (May 2002).

2. Kreger, H. Web Services Conceptual Architecture. IBM Software Group. May 2001.


72

3. J. Xu, B. Randell, A. Romanovsky, C. Rubira, R. Stroud, Z. Wu. Fault Tolerance in Concur-rent Object-Oriented Software through Co-ordinated Error Recovery. Proc. 25 th FTCS, pp 499-508, Pasadena, USA, 1995.

4. R. N. Taylor, N. Medvidovic et al. A component- and message-based architectural style for GUI software. In Proc. of the IEEE TSE, 22(6):390-406, June 1996.

5. M. Shaw and P. Clements. A Field Guide to Boxology: Preliminary Classification of Archi-tectural Styles for Software Systems. In Proc. of the COMPSAC'97, Washington DC, USA, August 1997.

6. L.F.Andrade, J.L.Fiadeiro et al. Coordination Patterns for Component-Based Systems. In Proc. of the SBPL'2001, pp. B29-B39, Curitiba,PR, Brazil, May 2001.

7. F. Tartanoglu, V. Issarny, A. Romanovsky & N. Levy. Dependability in the Web Services Architecture. In Architecting Dependable Systems. LNCS 2677. June 2003.

8. P. F. Pires at al. Building Reliable Web Services Compositions.In Proc. of the NET.Object Days Conference (WS-RDS'02), pp 551-562, Erfurt, Germany, October 2002.


73

1

Error Recovery for a Boiler System with OTS PID Controller

Tom Anderson, Mei Feng, Steve Riddle, Alexander Romanovsky

School of Computing Science University of Newcastle upon Tyne,

Newcastle upon Tyne, NE1 7RU, UK

Abstract. We have previously presented initial results of a case study which illustrated an approach to engineering protective wrappers as a means of detecting errors or unwanted behaviour in systems employing an OTS (Off-The-Shelf) item. The case study used a Simulink model of a steam boiler system together with an OTS PID (Proportional, Integral and Derivative) controller. The protective wrappers are developed for the model of the system in such a way that they allow detection and tolerance of typical errors caused by unavailability of signals, violations of range limitations, and oscillations. In this paper we extend the case study to demonstrate how forward error recovery based on exception handling can be systematically incorporated at the level of the protective wrappers.

1 Introduction

Although integration of Off-The-Shelf (OTS) components into systems with high dependability requirements (including those that are safety-critical) is becoming a viable option for system developers, care must be taken to avoid a deterioration in overall system dependability. OTS components are often of a lower quality than bespoke components, may not have been specifically intended for the environment in which they are to be employed, and may be poorly documented. These factors all contribute to a higher risk of failure for complex systems employing OTS components.

It must be accepted both that OTS components will be employed in such systems, and that their use will be a source of failure in spite of all efforts to improve the quality of OTS components and of the system in which they are to be integrated. The solution we advocate is to employ specialised fault tolerance techniques for integration of OTS components into complex systems.

1.1 Protective Wrappers

In previous work [1,7] we illustrated an approach to the development of protective wrappers, a bespoke software module which intercepts all information going to and from an OTS item. This approach is developed further in this paper using the same case study.

Fault tolerance techniques have three main phases: error detection, error diagnosis and error recovery [5]. The first phase identifies an erroneous state; error diagnosis is then used to examine and assess the damaged area, to enable it to be replaced by an error-free state during error recovery. We have previously concentrated on detection and diagnosis, providing only limited recovery actions.

Component wrapping is an established technique used to intercept data and control flow between a component and its environment [6]. A protective wrapper may detect errors or suspicious activities, and initiate appropriate recovery when possible, and must be rigorously specified, developed and executed as a means of protecting OTS items against faults in the Rest Of the System (ROS), and the ROS against faults in OTS items. Sources of information for wrapper development include specification of the OTS item behaviour, known “erroneous” behaviour of the OTS item, and specification of the correct behaviour of the ROS with respect to the OTS item.

1.2 Case Study

The case study used in this paper concerns the development of a protective wrapper for an Off-The-Shelf PID (Proportional, Integral and Derivative) controller. This case study is intended to illustrate how the approach could be applied in practice, employing software models of the PID controller and the steam boiler system rather than conducting a potentially risky experiment in a real-world


74

2

Outputs from OTS

Steam Load

Coal Quality Inputs to OTS

environment. Use of such software models is an active area of research and development carried out by many leading control product companies (including Honeywell [8]), and we use a third-party model of a steam boiler in this case study. We believe that this decision adds credibility to our results. The model simulates a real controller and steam boiler system, enabling us to investigate the effect of wrapping with a representative model. In the course of our work we have extended the model by incorporating protective wrappers.

1.3 Roadmap

The remainder of this paper is organised as follows. In the following section we describe the simulation environment, the controller and the boiler models we are using, and our approach to monitoring the model variables. Section 3 discusses the requirements for a protective wrapper to be developed and outlines the causes of errors to be detected and tolerated at the level of the wrapper. The next three sections discuss design and implementation of the wrapper to detect, diagnose and select an appropriate recovery action for errors caused by unavailability of signals, violations of range limits, and signal oscillations. Section 7 concludes the paper by discussing the generic error recovery strategy and the possible effects of wrappers executing on the overall execution of the integrated system.

2 Simulation

2.1 Simulink

Simulink (Mathworks) [10] is one of the built-in tools in MATLAB, providing a platform for modelling, simulating, and analysing dynamical systems. It supports linear and nonlinear systems modelled in continuous time and sampled time, as well as a hybrid of the two. Systems can also be multi-rate, i.e., have different parts that are sampled or updated at different rates. Simulink contains a comprehensive block library of sinks, sources, linear and nonlinear components, and connectors to allow modelling of very sophisticated systems. Models can also be developed through self-defined blocks by means of the S-functions feature of Simulink or by invoking MATLAB functions. After a model has been defined, it can be simulated and, using scopes and other display blocks, simulation results can be displayed while the simulation is running.

Simulink provides a practical and safe platform for simulating the boiler system and its PID control system, for detecting operational errors when boiler and control system interact, and for developing and implementing a protective wrapper dealing with such errors.

Fig. 1. Boiler System and Control System (including the PID Controller)

Boiler System

Feed Water Flow, Coal Feeder Rate and Air Flow

ROSConfiguration

Sensors

Actuators

PID controller (OTS item)

Drum Level, Steam Flow, Steam Pressure, Gas Concentrations and Coal Feeder Rate

Control System

O2 set-point and bus pressure set-point


75

3

2.2 The Structure of the Model

The abstract structure of the system we are modelling is shown in Fig. 1. The overall system has two principal components: the boiler system and the control system. In turn, the control system comprises a PID controller (the OTS item), and the ROS which is simply the remainder of the control system.

The ROS consists of :

• the boiler sensors. These are “smart” sensors which monitor variables providing input to the PID controller: Drum Level, Steam Flow, Steam Pressure, Gas Concentrations and Coal Feeder Rate;

• actuators. These devices control a heating burner which can be ON/OFF, and adjust inlet/outlet valves in response to outputs from the PID controller: Feed Water Flow, Coal Feeder Rate and Air Flow;

• configuration settings. These are the “set-points” for the system: oxygen and bus pressure, which must be set up in advance by the operators.

Smart sensors and actuators interact with the PID controller through a standard protocol. Simulink output blocks can be introduced into the model in such a way that the variables of the MATLAB working space can be controlled as necessary. Working with the Simulink model we were able to perform repeatable experiments by manipulating any of the changeable variables and the connections between system components so as to produce and analyse a range of possible errors that would be reasonably typical for the simulated system.

2.3 The Simulink Model

The Simulink model (shown in Fig. 2) actually represents the OTS item as three separate PID controllers that deal with the feed water flow, the coal feeder rate and the air flow. These controllers output three eponymous variables: Feed Water Flow (F_wf), Coal Feeder Rate (C_fr) and Air Flow (Air_f); these three variables, together with two external variables (Coal Quality and Steam Load) constitute the parameters which determine the behaviour of the boiler system. There are also several internal variables generated by the smart sensors; some of these, together with the configuration set-points, provide the inputs to the PID controllers. Table 1 lists all of the variables used in the model.

PID Controller 1 for Feed Water Flow

PID Controller 3 for Air Flow

CoalQuality

SteamLoad

F_wf F_wf

C_fr C_fr

Air_f Air_f

CoalQuality

SteamLoad

D_lD_l

S_f

P_dP_d

P_bP_b

O2eco

COeco

NOxecoNOxeco

D_l

S_fF_wfF_wf

Air_fAir_f

C_fr C_fr

O2_ref

O2_ref

COeco

PID Controller 2 for Coal Feeder rpm

C_frC_fr

P_b

P_ref

P_ref

Boiler System

O2eco

S_f

O2eco

P_d

Fig. 2. Simulink Model of the Boiler System with PID Controllers


76

4

2.4 Variable Monitoring

Simulink scopes and other display blocks enable us to develop modelling components that observe the intermediate results while the simulation is running. In our experiments we can monitor and display a total of 15 variables, comprising all of the variables listed in Table 1 (except for the two set-points), plus three internal variables which represent two internal air flows and one internal steam flow. The simulation time for all of our experiments is set to 12000 steps. Some monitoring results are presented in Fig. 3. In particular, this chart demonstrates the behaviour of the three PID outputs and two external inputs of the boiler system when at step 2000 the steam load is increased, and at step 5000 the coal quality changes: in both these scenarios the boiler system returns to steady operation reasonably soon.

Table 1. Variables used in the model

Variable Representation Variable Representation

Coal Quality Coal quality, ton per hour D_l Drum level

Steam Load Steam Load, fraction of pure combustibles

S_f Steam flow

F_wf Feed water flow P_d Steam pressure / drum

C_fr Coal feeder rate P_b Steam pressure / bus

Air_f Air flow (controlled air) O2eco O2 concentration at economizer

P_ref Bus pressure set-point COeco CO concentration at economizer

O2_ref O2 set-point NOxeco NOx concentration at economizer

0

10

20

30

40

50

60

70

80

90

100

0 2000 4000 6000 8000 10000 12000Simulation Steps

thre

e PI

D o

utpu

ts a

nd s

team

load

0.57

0.58

0.59

0.60

0.61

0.62

0.63

0.64

0.65

Coa

l Qua

lity

coal quality

steam load

air flow

coal feeder rate

feed water flow

Fig. 3. Normal Performance of the Boiler System with PID Controllers

2.5 Properties of the Boiler System and the PID Controllers

In this section we summarise the information which we collected to guide us in developing the protective wrappers. The basic boiler specification provides information on steam flow, bus pressure, output temperature and coal calorific value. As the OTS item (the PID controller(s)) is treated as a black box, any information about its properties must be deduced from the interface or from relevant sources where available. In an ideal world the system designer would have a complete and correct specification of the boiler system, the PID controller and the ROS. Unfortunately, we only had access to limited information about the boiler system and the ROS (which is typical for many practical


77

5

situations). From an investigation of the boiler model and information acquired from all available sources, we have formulated the following description.

Information from the documentation available to us is as follows:

• Output temperature 540 deg C • Coal calorific value 16-18 MJ/kg • Steam load 50-125 ton/hour • Coal quality is measured as a fraction of pure combustibles (where pure = 1; actual value about

0.55-0.7) • Three controlled outputs (F_wf, C_fr, Air_f) are given as a percentage

Information obtained by analysing the interface and by investigating the simulated model:

• Set-point of bus pressure ranges from 0 to 20 (usual value about 9.4) • Set-point of O2 concentration at economiser ranges from 0 to 0.1 (usual value about 0.03) • Internal variables input to PID controllers:

• Drum level: output value between -1 and +1 (usual value close to 0) • Steam Flow: 0 to 125 • Bus pressure: 0 to 20 • O2 concentration at economiser: 0 to 0.5

3 Requirements for a Protective Wrapper

In the previous section we presented an outline characterisation of the boiler system, as deduced from the model and other sources. In the following sections we consider the errors which could arise from integrating an OTS PID controller in the system, in order to derive requirements for a protective wrapper. We make the following assumptions:

• The value of each variable can be checked instantaneously through microprocessors. In particular, we assume that the values of input and output variables of the PID controller are available instantaneously. This (highly) simplifying assumption enables us to illustrate the method for protective wrapper development without regard to issues relating to response times.

• The wrapper program can be inserted into the control system, either by a partial hardware implementation which intercepts the physical connections, or purely in software. There are, of course, significant issues involved in deciding on the implementation of a protective wrapper, but we do not address these in this paper.

In order to clarify the requirements for a protective wrapper, it is necessary to form a view of what the PID controller and the ROS should, and should not, do at the interface between them. This view can be formulated as a collection of Acceptable Behaviour Constraints (ABCs) [7] defined from the perspective of the systems integrator. Once defined, these ABCs can be thought of as contracts [11] which a system designer could use as the basis for defining a protective wrapper, which can then employ conventional mechanisms for error detection, containment and recovery [2].

4 Safe Boiler Operation

Many aspects of the operation of the boiler and control system, such as the flow of gases, fuelling, pressures and levels, could lead to a failure of some type. However, some features are much more significant in terms of safety; in a steam boiler, the drum level is a key parameter. This parameter represents the quantity of water in the boiler more accurately than a direct measurement of the water level, due to changes in mass caused by differences in temperature. By monitoring and controlling the drum level we can maximize steam quality and maintain the proper water quantity to prevent damage to the boiler. Too low a level could expose the water tubes to heat stress and damage; too high a level could allow water to go over the steam header, exposing the steam turbines to corrosion and damage [12, 13]. Steam pressures on the drum and the bus are the two other key variables, since they indicate the balance between the supply and demand for steam. The consequences of excessively high steam pressures are obvious and explosive. Thus, any deviation from normal values of steam pressure and drum level must be corrected immediately, whereas abnormal values of the other variables can be tolerated for a time period (which must be defined by the system designer).


78

6

We classify the detectable variables into two loops, the control loop and the safety loop, which operate as follows:

• an alarm from the safety loop will shut the system down; • alarms from the control loop are processed on-line and either resolved or, if this is

unsuccessful, the safety loop is triggered.

The wrapper envelopes the PID controllers as shown in Fig. 4: it monitors the values of variables which go into and come out from the PID controllers. Three variables – the drum level and the steam pressures on the drum and bus – are classed as belonging to the safety loop, and all other variables (PID outputs to the boiler (via the ROS), set-points and other input variables) belong to the control loop.

Fig. 4. Variable categories around the PID controller(s)

5 Error Recovery

Error recovery transforms a system state that contains errors into an error free state. The transformation typically takes the form of either backward or forward error recovery [2]. Backward error recovery returns the system to a previous (assumed to be correct) state; typically, the techniques used are application-independent and often operate transparently for the application (e.g. atomic transactions and checkpoints). Forward error recovery aims to move the system into a correct state using knowledge about the current erroneous state; this recovery is application-specific by its nature. The most general framework for achieving forward recovery is exception handling [3]. It is not difficult to see that backward error recovery is not generally applicable in dealing with OTS items [4].

Protective wrappers offer a structured approach for incorporating fault tolerance measures in systems with OTS items. In previous work [1] we demonstrated how error detection can be developed in a wrapper by cyclically checking for each type of possible error identified during the analysis phase. We characterise these errors into three distinguishable types: (a) signal not available, (b) signal violating specifications, and (c) unacceptable signal oscillations. When the wrapper detects an erroneous situation it immediately initiates recovery action by classifying the error and invoking a corresponding exception handler. Three possible recovery actions are suggested here.

• Handler1: - Reset the signal to a standard normal value and send an alert to the operators.

• Handler2: - Wait ∆t, if error resolved, take no action; - Otherwise, send an alarm to the operators and wait ∆T, if error resolved, take no action; - Otherwise, invoke handler 3.

• Handler3: - Shutdown the system and send an alarm to the operators.

In Handler2, the delay times ∆t and ∆T would be determined by the wrapper designer after consulting the system specification. In the Simulink model we took ∆t as 500 steps and ∆T as 1500 steps, representing reasonable values for a genuine industrial application.

Analysis of the error types for different signals then enabled us to define a recovery strategy, which is discussed in the following subsection, and then illustrated in Fig. 5.

Wrapper

PID controller(s)

Set points

Variables from ROS (including drum level and steam pressure)

PID outputs to ROS


79

7

5.1 Recovery Strategy

In the case of an erroneous situation detected for a set-point value, whether it is missing, out of specification or oscillating is of secondary interest. The wrapper is aware of the appropriate range of set-point values, and Handler1 provides appropriate recovery by forcing the input to a suitable value, and alerting the operators (since the mistake could be theirs, or an internal corruption). The situation is rather different when a PID output value is detected as being erroneous, but the same response can be made; either by adopting standard operating output values, or by storing a recent history and using a smoothed average, the wrapper can apply Handler1 to impose a valid output signal which should result in stable, though suboptimal, performance from the boiler system. It would be possible to differentiate between the three error types in terms of determining the signal value to be imposed, but we have not exploited this in our simple demonstrator.

Now consider inputs to the PID controllers which are not set-points, and are not in the safety loop. When one of these is detected as erroneous there is little point in feeding a fixed value to the PID, since this will not reflect the actual conditions monitored by the ROS. However, given that there is no immediate safety concern, the optimistic strategy of “wait and see” may be successful; indeed for a short interval it may not be appropriate even to alert the operators, since the phenomenon may be completely transient in nature (it would, of course, still be logged for an off-line report). If the problem persists an alarm report to the operators may enable them to cure the problem, but if not an eventual shut-down is inevitable. So the wrapper can deploy Handler2; again, although differentiation of the response in line with error type is possible, we have not exploited this option.

Lastly, consider the variables in the safety loop: drum level, drum and bus steam pressures. Detecting an erroneous condition on one (or more) of these variables implies a risk to safety, and the natural response is to shut the boiler system down, despite the economic consequences. Handler3 provides this response, but to illustrate error category differentiation in our model we invoke Handler2 in the particular case of an oscillating value. The justification is that although a missing signal value or an out of specification value indicates a clear and present risk of accident, an oscillating value within specification does not necessarily pose the same immediate threat – the oscillations may die out or an operator response could stabilise the situation. If the oscillations persist then Handler3 will still be brought into play. Of course, in a real boiler system this strategy would only be acceptable if justified by a safety case.

Fig. 5. Recovery action implemented by exception handlers

5.2 Exception Handling

When any of the errors above is detected an exception is raised. Error diagnosis is performed to select the appropriate handler, depending on which variable caused the exception to be raised. The diagnosis is straightforward for variables in the control loop: in the safety loop, we differentiate between error categories.

Errors detected by the protective wrapper can be caused by malfunctioning of the OTS item, by faults arising in the ROS, or by misinterpretation between the OTS item and the ROS (Fig. 1). In the PID case study considered here, the exception handlers implemented in the protective wrapper always act at the level of the integrated system, which constitutes the exception handling context [4]; they can send an alert or alarm signal to the operator, replace an erroneous value with an alternative “normal” value, await a natural rectification, or (when safety requires it)) shut the system down.

Handler3

Handler1

Handler2

PID outputs and set points

Inputs to PID

Drum level and steam pressures

Control loop

Safety loop


80

8

Clear separation of the normal and abnormal system behaviour by employing exception handling in the wrapper facilitates the integration of the OTS PID into the composite system [4].

6 Implementation of the Recovery Actions in MATLAB

This section illustrates the operation of recovery when an error occurs, with the wrapper implemented in the MATLAB model. The example presented below applies error recovery by invoking Handler1. The error was introduced by artificially simulating an incorrectly valued pressure set-point. At step 5000 the operator “accidentally” recalibrates the pressure set-point to be 94 instead of the normal value of 9.4.

Fig. 6 shows the boiler system behaviour with no wrapper protection; note that the bus steam pressure is superimposed over drum steam pressure, so only one pressure variable is actually displayed.

The first chart of Fig. 6 shows that the faulty pressure set-point results in a huge drop in the drum level followed by a peak at too high a value before returning to a level close to normal. Similarly, the three PID outputs shown in the second chart jump up beyond their specified levels after step 5000 but return to normal performance by step 7000. Very much more serious is the steam pressure, which the first chart shows rising and remaining at an excessive level.

Fig. 7 shows the behaviour of the boiler system with wrapper protection active. The wrapper detects the incorrect value of the set-point and invokes Handler1. Consequently the set-point is very quickly corrected, and the impact on system behaviour and on the other variables is greatly reduced. From the two charts in Fig. 7 we see that although there are some alterations to the variables when the error occurs, the changes are actually quite minor, and lie within the range of the specifications for the system.

0

20

40

60

80

100

120

140

160

0 2000 4000 6000 8000 10000 12000simulation steps

stea

m p

ress

ure

on b

us

-4.0-3.5-3.0-2.5-2.0-1.5-1.0-0.50.00.51.0

drum

leve

l

drum level

pressure on bus

-500

0

500

1000

1500

2000

2500

3000


air f

low

and

coa

l fee

der r

ate

-100-50050100150200250300350400

feed

wat

er fl

ow

feed w ater f low

coal feeder rate

air f low

Fig. 6. Erroneous pressure set-point – boiler system with no wrapper. Drum level and feed water

flow are outside permitted ranges: steam pressure rises to an excessive level.

0

2

4

6

8

10

12

14


stea

m p

ress

ures

on

drum

&

bus

-0.08

-0.06

-0.04

-0.02

0.00

0.02

0.04

drum

leve

l

pressure on drum

drum level

pressure on bus

-10

10

30

50

70

90

110

130

150

0 2000 4000 6000 8000 10000 12000

simulation steps

coal

feed

er ra

te a

nd a

ir flo

w

0

5

10

15

20

25

30

feed

wat

er fl

ow

feed w ater f low

air f low

coal feeder rate

Fig. 7. Erroneous pressure set-point – error recovery by Handler1. Variables are corrected to be within permitted ranges


81

9

7 Discussion and Conclusion

7.1 Generic Error Recovery Strategy

Since an OTS item that has been integrated into a system is treated as a black box, only the inputs to and outputs from the OTS are available to be monitored for error detection. The inputs in a control system can be partitioned into two groups, where the first group consists of configuration variables (often under operator control as set-points), while the second group provides dynamic status information from the system under control. A wrapper providing protection in the system can monitor these two groups of inputs, and the outputs, and can attempt to distinguish different categories of erroneous behaviour. As three simple base categories we proposed: missing value, out of range value, and oscillating value.

In response to a detected error situation, over these groups of variables and categories of error, the protective wrapper can apply an exception handling framework to attempt to recover from the error. Simplistic generic recovery strategies that we have considered are: do nothing, alert the human operators, change variables to normal values, and stop the system. In our boiler system example we decided that erroneous outputs from the OTS could be over-ridden by the wrapper; in effect, the wrapper will take over the role of the OTS in erroneous situations, but can only provide a standard set of normative outputs. In the same way, the wrapper can over-ride configuration variable inputs to the OTS, particularly when these are input set-points. Our Handler1 is used to over-ride erroneous values.

We need to analyse in more detail the other input variables delivered to the OTS by the ROS, since forcing a change here could only have a very indirect influence on the variable itself, via the OTS and its outputs back to the controlled system. One important aspect is with respect to safety and we used this to apply a hierarchy of recovery. For variables with a direct impact on safety we “recover” by shutting the system down (Handler3); for other variables, not in the safety loop, we first wait to see if the error is transient, then to see if human intervention will achieve recovery, and if that too is unsuccessful then the system must be shut down in any case (Handler2).

Wrapper design in any specific case would proceed by analysis of the state space of variables, the errors that could be detected, the damage assessment that could be conducted, and the recovery strategies that could be devised, bearing in mind the implications on system operations from both a mission (economic) and a safety perspective.

7.2 Scope of the Wrapper

The essential characteristic of a protective wrapper is that all inputs to and outputs from the wrapped component are accessible to and modifiable by the wrapper. It might be argued that no other system variables should be accessible to the wrapper, since otherwise the intuitive image of “wrapping the component” would be distorted. We feel this is unnecessarily restrictive. If the system designer believes that improved performance of the wrapper can be achieved by utilising information from elsewhere in the system this should not be prohibited by an artificial limitation. When the wrapped component is an OTS item it may be very unlikely that the wrapper could make any effective use of internal state information within the OTS component, but valuable insight may perhaps be gleaned from variables in the ROS that are not visible to the component. An example of this is present in our case study. The drum steam pressure is not actually utilised by the PID controller (although it is made available), so it is debateable whether or not it constitutes an input. We gave the wrapper access to this variable without hesitation, since we suspect that any practising engineer would do the same.

7.3 Complexity of the Wrapper

A wrapper inserted into a system as a protective component performs an important role in improving the reliability of the integrated system. In discharging this role it is clearly essential that the wrapper does not itself contribute to an increase in failing behaviour from the overall system. Ideally, the wrapper should introduce no faulty behaviour itself, and should capture and rectify all faulty behaviour it encounters. Perhaps the best general guidance here is that the most reliable designs will usually be those that are simplest. The OTS PID controllers may, of necessity, involve highly complex algorithms to achieve the optimised boiler performance that is their goal. But in designing an effective wrapper we


82

10

are likely to find that a simple and effective recovery strategy will outperform something overly sophisticated. First, a simple design is more likely to be implemented correctly, and second, a more complex strategy may have unforeseen interactions with the control environment and these could detract from effectiveness.

9

10

11

12


stea

m p

ress

ure

on d

rum

-0.08

-0.06

-0.04

-0.02

0.00

0.02

0.04

drum

leve

l

drum level w ith three protected PID ouputs

drum level w ith tw o protected PID ouputs

pressure w ith three protected PID outputs

pressure w ith tw o protected PID outputs

Fig. 8. Comparison of effects on performance of boiler system with two kinds of wrapper designs

Fig. 8 shows a comparison of the impact on two of the variables in the safety loop for the boiler system, with two different wrapper designs responding to the situation described in section 6 (the pressure set-point changed from 9.4 to 94 at step 5000). One wrapper applies recovery by using Handler1 to reset all three PID outputs to standard values, while the other wrapper only resets the feed water flow and air flow, leaving the coal feeder rate at its computed value. We can see from Fig. 8 that the more simplistic strategy of only changing two of the variables leads to a swifter and more stable recovery.

This paper has summarised our recent work in the development of protective wrappers as a structured approach to providing error detection and recovery in systems utilising OTS items. This approach embodies error classification and corresponding recovery strategies implemented within an exception handling framework, building on the structure and error detection issues considered in earlier papers [1,7].

Acknowledgements

This work is supported by the EPSRC/UK project DOTS: Diversity with Off-The-Shelf Components. (http://www.csr.ncl.ac.uk/dots). This work has benefit from interaction with colleagues at City University within the DOTS project.

References

1. T. Anderson, M. Feng, S. Riddle, A. Romanovsky. Protective Wrapper Development: A Case Study. 2nd International Conference on COTS-Based Software Systems (ICCBSS 2003). Ottawa, Canada, February, 2003. pp. 1-14

2. P. A. Lee, T. Anderson, Fault Tolerance: Principles and Practice, Wien - New York, Springer-Verlag, 1991. 3. F. Cristian. Exception Handling and Tolerance of Software Faults. In M. R. Lyu (Ed). Software Fault

Tolerance. John Wiley and Sons, 1995, pp. 81-108 4. A. Romanovsky. Exception Handling in Component-Based System Development. 25th Int. Computer Software

and Application Conference (COMPSAC 2001), Chicago, IL, October, 2001. pp. 580-586. 5. J.-C. Laprie. “Dependable Computing: Concepts, Limits, Challenges”. Special Issue of the 25th International

Symposium On Fault-Tolerant Computing. IEEE Computer Society Press. Pasadena, CA. June 1995. pp. 42-54 6. J. Voas. Certifying Off-The-Shelf Software Components. IEEE Computer, 31(6), 1998, pp. 53-59. 7. P. Popov, S. Riddle, A. Romanovsky, L. Strigini. On Systematic Design of Protectors for Employing OTS

Items. In Proc. of the 27th Euromicro conference. Warsaw, Poland, September 2001 IEEE CS. pp. 22-29. 8. V. Havlena, Development of ACC Controller with MATLAB/SIMULINK. MATLAB ’99. Praha: VSCHT -

Ustav fyziky a merici techniky, 1999, pp. 52-59. 9. J-R. Abrial, E. Börger, H. Langmaack. Formal Methods for Industrial Applications: Specifying and

Programming the Steam Boiler Control. LNCS 1165, Springer Verlag, October 1996. 10. Mathworks, Using Simulink: reference guide, http://www.mathworks.com 11. B. Meyer. Programming by Contract. In D. Mandrioli, B. Meyer (eds.), Advances in Object-Oriented Software

Engineering. Prentice Hall, 1992. 12. Siemens, Boiler Control Overview, http://www.procidia.com 13. Minnesota Department of Labor and Industry, Your guide to safer boiler operation, http://www.doli.state.mn.

us/pdf/guide2saferboiler.pdf.


83

�� !#"%$��&'� �(&*)+&*��,�-&/.��0�12&*3&#24�)

5%687:9;7:6=<?>A@CBEDF>HGFBEIKJLJEJ;MON�G%6=<?PRQ=S�TUTUSWVX6RQHYE9;B;JCMF@CZCTU[\Y]<UI^_YED;QRQ8<`S:6aJ;MON�G%6=<?PRQ=BEbFG%SAcXBdIeZfJEJ

g�hji�kml:n�o*p*qHrtsvu�wduHx2yLzv{euHx|w%} ~�sv�Hx�ojn#��q�x�qHzvuH{\��zv�C�\�eu�i��]�2uHx�x�u�o*�t�,�:�� `�AuHx*o#�d�R��{eqHu_o*��:�X�X�t�,�:��X�:��d��uawEu8��zvqt� �Ert�dq=�drt{F�;�2�E��z�xm��u8s�svut� ��R�twdrE�F�]¡Esv¢:�:zv{O� £��:�d��zvu8�8¤�¥�x�z¦��u8o§uHu8��zvut� uH��E� ¨`�

gtg�hFkª©�y+y«o_¬a�E¬ ��du,~_we�Xo��A�ttlAyLrt{\��®;uHsvsvz�u=��o��d�R��{eqHu�o2��t��A��E¬X��:�wErt{\¡e¥�s�z¦��A�¯� Ü�

°!±K²H³H´�µC¶t³ ©�u8s�z��·ezvsvzv�¸¡!�:{CwA¨¹��es¦��oº��rtsvu8�R��{eqHu��R��z�x�u�{eu8»¼zvx�x��eu8x|z�{!�Ar]wdu8��{�x�r�Ü�ª»½��u,��q=�dzv��u8q8��d��uHx¾¹x��eqR�¯��x�qHr:�A®;rt{duH{\�|·C��x�uaw¯��qR�ez¦��uHq=��d��uHx_r:��es¦��z¦oª��¿tuH{\�_xm¡Exm��uH�AxRÀ½��x_��du8¡!�:zv�Á��zv{\��uH¿:�R��zv{e¿x�uH®C��R��uHs¦¡�wEuH¢�uHsvr:®;uawLx�r:¨`�ª»½��uXuH{\��zv��zvuHx��rW·e�dzvs`w¯s��¿tu8o§x�qa��s�u�xm¡Exm��uH�AxH�ek¸{L��ezvx�®C��®;u8�a�e»2uXxm��ewE¡u8ÂEzvxm��z�{d¿Lu8ÂEqHu8®d��zvrt{Ã�C��{Cwdsvzv{e¿�xm¡Exm��uH�Ax��x�x�r\qHz��uawÃ��r��du�¢:��zvrt�dx�qHrt�A®;r:{euH{\��Ar]wduHsvx��e�� qa��{·;u½¨?r:�e{CwWzv{�Äm�a¢t��o¸·e�:x�uaw�®es��Ür:��AxH�\Å½�dzvx�zv{eq8s��ewduHx'qHr:�A®;rt{eu8{]��x#�e�a¢Ezv{d¿�qHrt{\��R��q8��o§·C�:x�uHw�r:��uH¢�uH{\��o·C��x�uaw�zv{\��u8�R�:q8��zvr:{fx�q=�duH�AuHxX�:{ewxm¡E{eqR�d��r:{ert�dx,r:��:xm¡E{eqR�d��r:{er:�ex,qHrt�A��e{dz�qH��zvrt{x�q=�duH�AuHxH�FÆÇu��euH{Ã¨?r\qH�dx�r:{�»_�C��,»½uAqHr:{ex�z�wdu8�X��r¯·;u��duA�Artxm�,®E��rt·esvuH��zvqAz�x�x��dutÈOu8ÂEqHuH®d��zvr:{Ç�C��{Cwdsvzv{e¿!¨?r:��:xm¡E{eqR�d��r:{er:�ex�s¦¡Éq8rt�A��d{ezvqa��z�{d¿q8rt�A®;rt{duH{\��xH�*ÆÇuL��duH{É®E��uHx�uH{\�A¨?r:�d�L�]�e�:svz¦��zvuHxA»½u¯��ezv{dÊ��{p'Ë��L¨?r:� �L�½�½n¼x��er:�es�w+�C�a¢�u��:{ew+��e��»½u�»_zvsvs*qHrt{dx�z�wdu8�,��x��ua�\�ez¦��uH�Au8{]��x_¨?r�� ¨?�E��d��u,»½r:��Ê+r:{wduHx�zv¿:{ezv{e¿��{¯p*Ë ��e��_¨?�ds¦�CsvsF��duH�¯�

Ì ÍdÎ�Ï;Ð%Ñ ÒXÓXÔKÏ%ÕRÑ�Î

ÖfB;9;S:6=IÇ×�Y�ZCP�BEØ2Ù%DF<`T?9;<UI%ÚÃY]bFb%T`<?>�Y]Q=<UBEIFP�68S:ÛeD%<U68S�IFS�×ÝÜLStY]IFP�BEØ½P=B]Ø¹Q�×�Y]68SWS�I%Úd<ÌFS�S�68<UI%ÚFÞ;<`Q,<UP,I%B\×ßStYEP=<`S:6Q=BW68S�DFP=S�S�à;<UPRQ=<UI%Ú�b%<US:>�StP½B]ØOP=B]Ø¹Q�×�Y]68S�YEIF9!<ÌeQ=S:ÚE6HY\Q8S�Q8G%S�ÜáQ8BWÙ%D%<UTU9L>�BdÜLbFT`S�Q=S Y]b%bFT`<?>�Y]Q=<UBEIFP:âEN�BEÜ¯bOBdI%S�IeQ=ãÙFYdPRSt9äb%T?Y\Q=ØºBE68Ü¯P¯åmN�æ�ç�P8è!é¦ê\ë%MUìEìdM`ì�ítî|BE6WÜ�D%T`Q=<`ã�Y]ÚES:IeQ8PWPRZ;PRQ=S:Ü¯P¯å¸Öäï�@%èLé ë\î�YET`TUB\×ðQ=BÇÙ%D%<UT?9�P=DF>HG�YEb%b%TU<�ã>�Y]Q=<UBEIFPL× <`Q=G�PRS:bFY]6HY\Q8S�TUZñ9;S�[dS�TUBEbKS:9òP=B]Ø¹Q�×�Y]68SÃS:IeQ=<`Q=<US:P:â|ó�SÇÙKS�TU<`S:[ESQ=GFY]QLQ8G%<?P¯6=S:DFPRSÇY]IO9ò<UIeQ=S�Úd68Y]Q=<UBEIb%68B;>�S:P8P 6HY]<?PRStP I%S:×Ý68S�TU<?Y]Ù%<UT`<`Q�Z�<UP8PRDFS:P,YEIF9�Q=GFY]Q�68S�TU<UYEÙ%<UT`<`Q�ZÃÙKS:>�BEÜ¯S:P�Y+Ü¯BE68S�Y]IF9ÇÜ¯BE68S�>�6=<`Q=<?>�YET'YEP�PRZ;PRãQ=S:Ü+P¯ÚES�Q¯T?Y]68ÚES�6tâ2ô�IõBdD%6¯b%6=S:[C<`BdDFPL×�Bd6=öjM2×�S�GFY�[ESÇPRQ=DF9;<US:9õS�à%>�S�b;Q8<`BdIòGFYEIF9;TU<Ì%Ú÷<UIøÖùï�@;P+YEIF9¼GFY�[dSb%68BEbKBdP=S:9Y]IÇS�à%>�S:b;Q=<UBEI�GFYEIF9;TU<Ì%Ú+P=Z;P�Q8S�Ü/å§ú�û�@%è,9;S:9;<?>�Y]Q=St9ÃQ8B+Öäï�@;P�é`ìtü�îªâFô�IÃQ8G%<UP,bFY]bKS�6tM;×�SAYd9%9;68S:P8PS�à%>�S�b;Q8<`BdIòGFYEIF9;TU<Ì%Ú�<ÌýN�æ�ç�P¯Y]IF9¼ØºBC>�DFPLBEIõ× GFY\Q¯×�S�>�BdIFPR<?9;S:6�Q8B�ÙKSÃQ8G%SÇÜ¯BdPRQ!b%68BEÙ%TUS�Ü+Y]Q=<?>�<?P=P=D%SEÞS�à%>�S�b;Q8<`BdIGFYEIF9;TU<ÌFÚ!ØºBd6,>�BdIdQ868Yd>aQ=ãªÙFYdPRSt9#M;YEP=ZCIF>HG%68BEI%BdDFPRTUZ+>�BdÜLÜ!D%I%<?>�Y]Q=<UI%ÚL>�BEÜ¯bKBEI%S:IdQHP�â

þ�G%SW68S�Ü+Y]<UIF9;S:6�BEØ�Q8G%<?P�bFY]bKS�6 <?P�BE68ÚdYEI%<`ÿ:S:9YEP�ØºBETUTUB\×,P�â%@CSt>aQ=<UBEIfê!b%68S:P=S�IeQ8P�BdD%6,P�Q8DF9;Z�BEØ�S�à;>�S�b;Q8<`BdIGFYEIF9;TU<Ì%Ú�<Ì![\Y]68<`BdDFP*S�àC<?PRQ=<UI%ÚWN�æ�ç�P:â�ômQ�<UIdQ86=B;9;DO>�S:P'Q=GF6=S:S�>�Y]Q=S:ÚEBE68<US:P*BEØF>�BdÜLbKBEIFS�IeQ8P2Y]IF9�S�à%Y]Ü¯<UI%S:P'Q=G%S:<`6bFYE6RQ8�D%TUYE6=<`Q=<US:P�68S�ÚdYE689%<Ì%Ú�S�à%>�S:b;Q=<UBEIGFY]IF9%T`<UI%ÚFâ%@CSt>aQ8<`BdI��ØºBC>�DFP=S:P�BEI�Y�bFYE6RQ8�D%T?Y]6�>�Y\Q8S�ÚdBE68ZLBEØ�>�BdÜ¯bOBEãI%S:IdQHP!å¸>�BdIdQ868Yd>aQ=ãªÙFYdPRSt9ÇYEP=ZeIO>HG%6=BdI%BEDOPRTUZÃ>�BdÜ¯Ü�D%I%<?>�Y]Q=<UI%Ú>�BEÜ¯bKBEI%S:IdQHP8è�ØºBE6�× G%HGùS�à%>�S:b;Q=<UBEIfGFYEIF9;TU<ÌFÚ<?P�bFYE6RQ8�D%T?Y]68T`Z+9;<��>�D%T`Q�YEIF9+b%68S:P=S�IeQHP�× GFY]Q�×�SXQ8G%<UI%ö¯Q=B!ÙOS�Q=G%S�68S:ÛeD%<U6=S:ÜLS:IeQ8P|Q8GFY\Q Y]Iú�û�@Ã9;S:9%:Y\Q=St9Q=B�P=DF>HGf>�BdÜ¯bOBdI%S�IeQ8P P=G%BdD%TU9ØºD%T��FTUT¸âj@CS:>�Q=<UBEIÇë�>�BdIF>�TUDF9;StP,Y]IO9bF6=StPRS:IdQHP�×�Bd6=öÃ<ÌÇb%68BEÚd6=StP=P:ÞCG%B\×ß×�S�Y]68SQ=6HY]IOPRbKBdP=<ÌFÚäY]IF9ñYd9%Y]b;Q8<ÌFÚfBED%6!b%6=S:[C<`BdDFPA×�BE68öùBEIñS�à%>�S�b%Q=<UBEIñGFYEIF9;TU<Ì%Úù<Ì¼Öäï�@;P�Q=Bäb%68B\[C<U9%S�YÇØºD%TUT`ZØºD%IF>�Q=<UBEIFYET*ú�û�@�ØºBd6��eê]ú_ú�Ü¯S:P8P=YEÚES�ã�9;68<`[dS�I�ÙKS:YEIFP:â

� ��,Ô� �XÏ%Õ�Ñ�Î��|ÎXÒ��RÕ=Î�� ÕRÎ ÔjÑ��AÑ�Î��Î�Ï��'Ò��2Ï! HÑ_Ð"��

# D%6�P�Q8DF9;Z+BEØ'S�à%>�S:b;Q=<UBEIGFY]IO9;T`<UI%ÚL<UP�ÙFYdPRSt9+BEIÃQ=G%68S�S�öC<ÌF9B]Ø2>�BEÜ¯bKBEI%S:IeQ8P�Q=GFY]Q�>:Y]IÃÙKS�ØºBED%IF9<UI��eY�[�Y]ãÙFYdPRSt9ñb%T?Y\QRØºBd6=Ü+P�å§P=S:P8PR<UBEIòBE6LS�IeQ=<`Q�ZñÙOStY]IFP:M2ÜLStP=P8Y]ÚdS�ã�9;68<`[dS�I÷ÙOStY]IFP¯YEIF9$�eY�[�Ydæ�S:Y]IOP8è�â�þ�G%S:Z¼Y]68S�×�S:T`TöCI%B\× I*MeÚETUBEÙFYET`TUZ¯6=S:b%68S:P=S�IeQ8Y]Q=<U[ES,BEØ*Q=G%S�[\Y]68<`BdDFP�öe<UIF9ÃB]Ø�>�BEÜ¯bOBdI%S�IeQHP�Y�[\Y]<UT?Y]Ù%TUSX<UIÃS�àC<?PRQ=<UI%Ú!BdbOS:68Y]Q=<UBEIFYETb%T?Y\Q=ØºBE68Ü¯P:M%Y]IO9�Q8G%S�<U6,BEbKS�I�<UÜLbFT`S:ÜLS:IeQ8Y\Q8<`BdIÇÜ¯YEöEStP�<`Q,bKBdP8PR<UÙ%TUSWQ=BLØº6=S:S�TUZ�S�à;bKS�68<`Ü¯S:IdQtâ

% &(' )+*-,/.�*-021!0�354768391�:-*";�<=1!>N�BEÜ¯bKBEI%S:IeQ8P�>:Y]IñÙKSÃ9;<?P�Q8<ÌFÚED%<?PRGFS:9ñÙCZ�å§Y]Ü¯BdI%ÚfB]Q8G%S�6L>�68<�Q8S�68<UYÇI%BdIñÜ¯S:Y]IF<Ì%ÚEØºD%T�GFS�68Stè�Q8G%SÃ×�Y�ZäQ8G%S�Z<UIdQ8S�6HYE>�Q YEIF9�>�BEÜ¯Ü!D%I%<?>�Y\Q8SEâ


84

? 0�391@;A6B473C<=*"0D>94�E21!,$1!>@F Ü+Y]<UI<UIeQ=S:68Yd>aQ=<UBEI�Ü¯B;9;S:P YE6=S�GHN�BEIeQ=6HYE>�QRãmÙFYEP=S:9�H�YEIF9IG�ú_[dS�IeQRãmÙFYdPRSt9�HHâJ óý<`Q=G¼N�BEIeQ=6HYE>�QRãmÙFYEP=S:9Ç<UIeQ=S:68Yd>aQ=<UBEIOP!å¸>aØ�â#52<`ÚOâ2ìtY%M ÙOèaM#>�BEÜ¯bOBdI%S�IeQHP�P=S�IF9ù6=StÛeD%S:PRQ8P�Q=BB]Q8G%S�6A>�BdÜ¯bOBEãI%S:IeQ8PÃå¸YE>�Q=<UI%ÚùYEP!PRS:6=[C<?>�S+b%68B\[C<U9%S�6HP8è�Y]IO9÷S�à;bOSt>aQ¯Y]IFP=×�S:68PW<UI¼68S�Q8D%6=I¼YdP�P=bOSt>�<��FS:9ñÙCZÉ>�BEÜ¯bKBEI%S:IeQP=B]Ø¹Q�×�Y]68S�>�BdIeQ=6HYE>aQHP�éUìC�%M`ì�êtîªâjô�IùQ=G%<?P�bFY]bKS�6tMO×�S¯>�BEIOPR<?9;S�6�Q=GOY\QW6=StÛdDFS:PRQ=<UI%ÚY >C1�;�K <(4@1 Øº6=BdÜ Y�>�BdÜLãbKBEI%S:IeQ Q=68<`ÚdÚES�6HP�Q=G%SAS�àCSt>�D;Q8<`BdIÇB]Ø'Q8G%S�>�Bd6=68S:P=bKBEIF9;<UI%Ú 6B473C<LK <(3NM <Ì�Q=GFS�>�BEIO>�S�68I%St9Ã>�BdÜ¯bOBdI%S�IeQ:â

J óý<`Q=G¯ú_[dS�IeQRãmÙFYEP=S:9�<ÌeQ8S�6HYE>aQ8<`BdIFP:M�>�BEÜ¯bKBEI%S:IdQHP|Y]68S�Ü¯Bd6=S�TUBeBePRS:T`Z�>�BED%bFT`St9!YEIF9�<UIeQ=S:68Yd>aQ½[e<?YWY]ILS�[dS�IeQ9;<?P=bFY\QH>HG%S�6'Q=GFY]Q2>�BdÜ¯Ü�D%I%<?>�Y]Q=S_S:[ES:IdQHP*S:ÜL<`QRQ8S:9�ÙeZAY,>�BEÜ¯bKBEI%S:IdQ�Q=BXQ=G%BePRS_68S�Úd<UPRQ=S:6=St9WYEP�<�QHP'TU<UPRQ=S:I%S�6HP:âå¸>aØ�â%52<`ÚOâ#ì:>tèaâCô�IÃQ8G%<?P�>�BEIeQ=S�àCQ:MeQ=G%SWS:ÜL<`QRQ8<ÌFÚ¯>�BEÜ¯bKBEI%S:IdQ 9;BCS:P�IFB]Q�öeIFB\× × G%<?>HG>�BdÜ¯bOBdI%S�IeQ8P�TU<UPRQ=S:IQ8B+<�QHP�S�Ü¯<�Q=Q=St9ÇS�[ES:IeQ8P�Y]IF9Ç9;BCStP�I%B]Q,S�àCbKS:>�Q,Y]ICZÃY]IOPR×�S�6tâ

)+*",O,QPR02<=476839<(*-0O>94�E21!,$1!>@F >�BdÜLbKBEIFS�IeQ8P�Ü+Y�ZÃ>�BEÜ¯Ü�D%IF:Y\Q=SAP=ZCIF>HG%68BEI%BdDFPRTUZ¯BE6,YdPRZCIF>HG%68BEIFBEDFP=T`ZdâJ óý<`Q=G�P=ZCIF>HG%68BEI%BdDFP�>�BEÜ¯Ü�DFI%:Y\Q8<`BdIFP�M]P=S�68[C�S >�Y]TUTUS�6HP2YE6=S�Ù%TUB;>HöESt9�D%IeQ8<`TF>:Y]TUT`S:S:P½68S�b%TUZEâ # IFT`Z�YAP=<UI%ÚETUSS�àCSt>�D;Q8<`BdITSOB\×ß<?P S�à;S:>�D;Q=St9Y]QXYLÚE<U[ES�IQ=<UÜ¯SEÞ;Q8G%S�68SW<UP,I%B+>�BEIO>�D%686=S:IF>�Zäå¸52<`ÚOâ#ì:Y%M >:è�â

J óý<`Q=G÷YEP=ZCIF>HG%68BEI%BdDFPX>�BEÜ¯Ü�D%IF:Y\Q=<UBEIOP�MK6=StÛeD%S:PRQ�S:Ü¯<UP8PR<UBEI�<UP�I%BdI;ãmÙ%T`B;>HöC<UI%ÚFâjþ�GCDFP�S:YE>HGÉPRS:6=[C<?>�S!6=S�ãÛeD%StP�Q�Q86=<UÚEÚdS�6HP�Q=G%<?P�>�6=StY\Q8<`BdIÉBEØ,YfI%S�× Q8G%6=StYE9�Q=Bù6=D%I÷Q8G%SÃ>�BE686=StPRbKBEIF9%<Ì%ÚfYd>aQ=<U[C<�Q�Z�å§>�Ø�â�52<UÚFâ�ì:ÙOèaâþ�G%<?P�>�BEÜ¯Ü�D%IF:Y\Q=<UBEI÷Ü¯S:YEIFPA<?PA[ES:6=ZUSFS�à;<UÙ%T`SY]IF9÷P=D%<�QHPAbFYE6RQ8�D%TUYE6=TUZä×�S�TUT�Y]bFb%T`<?>�Y]Q=<UBEIFP�<Ì÷× G%<?>HGV BC@¯bOBdT`<?>�<US:P�GFY�[dS Q=B!ÙOS�<`Ü¯b%TUS�Ü¯S:IdQ8S:9�åºS�ÚOâ�W\b%6=B\[C<?9;SXY�6=StPRD%T`Q�BdIF>�S�Y�>�S�6=Q8Y]<UI V BC@Çé X%M ê7X�î#T`S:[ES�TKGFYdPÙKS�S:I�68S:Yd>HG%S:9"Y+BE6ZW\b%6=B\[C<?9;<UI%Ú�Q8G%SAÙKS:PRQ,6=StPRD%T`Q,BEÙ%Q8Y]<UI%St9ÃÙKS�ØºBd6=SAY¯PRbKS:>�<[�OS:9Ç9;S�T?Y�ZBY%èaâ

Event

RMI m()

Standard

Middleware

ObjectShared

writeread

MDB

m

return

m

response

Event

DispatcherJavaBean2JavaBean1

return

Event

return

CalleeComponentClient Client

(b) Contract−based interactionsusing asynchronous communications

(c) Event−based interactionsusing synchronous communications

(a) Contract−based interactionsusing synchronous communications

\^]`_8a ćb�d�e-f ��¢:��qHr:�A®;rt{duH{\��x½zv{]��u=�R�:q8��zvrt{¯�:{Cw!qHrt�A��e{ezvqa��zvrt{L�EqR�euH�AuHxg S:ÚdY]6H9;<UI%Ú�Q8G%<?P,>�T?YEP8PR<��O>:Y\Q=<UBEI'Me×�SWØºBEDFIF9Q=G%68S�SWöC<ÌO9%P�B]Ø½S�à;<?P�Q8<Ì%Ú+>�BEÜ¯bOBdI%S�IeQHP�Þ

J )Ihi47*-,/.�*-0R1�0�39> Þ;>�BEIeQ=6HYE>�QRãmÙFYEP=S:9+<UIeQ=S:68Yd>aQ=<UBEIOP�× <`Q=GfP=ZCIF>HG%68BEI%BdDFP�>�BEÜ¯Ü!D%I%<?>�Y\Q8<`BdIFP:MJ )+jk47*-,/.�*-021!0�39> Þ;>�BdIeQ=6HYE>aQ=ãªÙOYEP=S:9+<UIeQ=S�6HYE>�Q=<UBEIFP�× <`Q=GfYEP=ZCIF>HG%68BEI%BdDFP�>�BEÜ¯Ü!D%I%<?>�Y\Q8<`BdIFP:MJml 4@*",/.n*"0R1!0�3C> ÞdS:[ES�IeQ=ãªÙFYdPRSt9�<UIeQ=S�6HYE>�Q=<UBEIFP�× <`Q=GfP=ZCIF>HG%68BEI%BdDFP�>�BEÜ¯Ü�DFI%:Y\Q8<`BdIFP�â

% &o% l�p 6B,/.rq(1!>5*"sutv6@KB6w47*-,/.�*-021!0�39>�eY�[�Y�æ�S:YEIFP�é ê7��îFY]68S�úÉ>�BEÜ¯bOBdI%S�IeQHP å§>aØ�âd5�<UÚFâ;ìt>:è2Y]IO9!YE6=S�>�BdIF>�S:b;Q=DFYET`TUZ�P=<`Ü¯<UTUYE6�Q8BAÖf�6=BePRBEØ¹Q_ï >aQ=<U[ESAx�y!â

# Q=GFS�6 S�à%YEÜLbFT`StP�>�BEÜ¯SW× <�Q8GU�eê]ú_ú,Þz�{c|N|~}(�A� Y]IF9 {��}��i�N{N�A�B| Y]68S�N�@ñ>�BdÜ¯bOBdI%S�IeQ8P!× G%<?>HGò>�BdÜ¯Ü�D%I%<?>�Y]Q=S�[C<?YäÜ¯<?9%9;TUS�×�Y]68S:P�å=g,Öfô�Bd6

N # g,æ�ï�è�â�þ�G%SÜ¯<U9%9%T`S:×�YE6=S+S:IFPRDF6=StPAbFYE>Hö\YEÚE<UI%ÚFM#Q868YEIFP=bOBd6RQ�YEIF9÷D%I%bFYd>Hö\Y]ÚE<UI%ÚÇB]Ø ÙKB]Q8G¼Ü¯S�Q=GFBC9ò>�Y]TUT?PY]IO9Ã68S:P=D%T`Q8P�S�à%>HGFYEI%ÚESt9ÃÙKS�Q�×�S�S:I68S�Ü¯BEQ=SA>�BdÜLbKBEIFS�IeQ8P:â

52<ÌOY]TUT`ZdM-� {c|�|��C�@{��A�~}��A{c��{N��B|I�=�T��|�� Y]68SAN�ïÝ>�BdÜ¯bOBdI%S�IeQ8P�× G%<?>HG>�BEÜ¯Ü�DFI%:Y\Q8SX[C<UY!Ü¯S:P8P=YEÚE<UI%Úb%68B]Q8BC>�BET,>:Y]TUT`St9i�-�i��~� �A�A�w� {c|�|��C��}��!�/zv{c�~�9}(¡N{�¢ é ê%ìEM¦êEê�îmâ�ï Öäc�æ3× G%HGø68S:>�S:<`[dS:P+Y/�eÖù@õÜ¯S:P8P=YEÚESS�à;St>�D;Q8S:P�Q=GFSW>�BE686=StPRbKBEIO9;<ÌFÚ!YE>�Q=<U[C<�Q�Z�<UIÇYL9%S:9;<?>�Y]Q=S:9ÃQ=GF6=StYE9#ÞeQ=GF<UP,YET`TUB\×,P�Öäc�æ�P�Q8B+>�BEIO>�D%686=S:IeQ=TUZLbF6=BEã>�StP=P�[\Y]68<UBEDFPWYE>�Q=<U[C<�Q8<`StP�â#óýG%S:IÉYÇ>:Y]TUT`S:S!I%S:S:9%P�Q8BÇ6=S�Q=D%68IÉP=BEÜ¯S�Q=G%<UI%ÚQ=BÇ<�QHPA>�YET`TUS�6tMj<�Ø�Q=G%S+>:Y]TUT`S:6�<?PWI%BEQYÃ>�BEÜ¯bKBEI%S:IdQ�Q=GFY]Q�>:Y]Iä68S:>�S�<U[ESZ�eÖù@ÇÜ¯S:P8P8Y]ÚEStP�M%Q=G%S:ZfGFY�[ESAQ8BÃDFP=S!YPRGOY]68S:9ÇBEÙB£�S:>aQ¯å§>�Ø�âj52<UÚFâ2ì�ÙOèXYEP�YQ=S:Ü¯bOBd68YE6=ZL6=S:bOBePR<`Q=Bd6=Zdâ # Q=GFS�68× <UP=SEMdQ=G%S�>�YET`TUS�S�>�Y]IPRS:IF9�Y�IFS�×D�eÖù@¯Ü¯S:P8P=YEÚES Q8B�Úd<`[dS Q=G%S�Y]IFP=×�S�6tM]Q=GCDFP<UÜLbFT`ZC<UI%Ú¯Q=G%SA>�6=StY\Q=<UBEI�B]Ø½Y¯I%S�×ßQ=G%68S:Yd9#â

�eÖù@äYETUP=B�YET`TUB\×,PXQ=BÇÙ%68BdYE9F>�YEPRQ�Ü¯StP=P8Y]ÚdS:PXQ=BfYP=S�QABEØ�>�BdÜLbKBEIFS�IeQ8P�Q8GFY]I%ö;P�Q=B�Q8G%S¯I%B]Q8<`BdIùB]Ø ��N¤-}(¡å¹Q8B¯ÙOS�>�BEÜ¯bFY]68S:9+Q=B �7�(¥�{N¡c��A¦9¤"| éUì�ë\î*× G%<?>HGÇY]TUT`B\×ýQ8B¯ÚdY\Q8G%S�6 Y!ÚE68BED%bB]Ø2BEÙ8£�St>aQ8P�× GFHG�>�Y]I�ÙKSWP=S�S:IY]IO9Yd9%9;68S:P8PRSt9YdP�YLD%IF<UÛeD%SAS:IdQ8<�Q�Z%è�â%ô�I§�dÖù@#M%Y!Ü¯StP=P8Y]ÚdS�P=S�IeQ�Q=B�Y!Q=Bdb%<?>�<?P Ù%68BdYd9%>�YdP�Q8S:9¯Q8B�Y]TUT*Öäc�æ�P× G%<?>HG�PRDFÙFP=>�6=<UÙKS:9LQ=B�Q=G%SXÚE<U[ES�I¯Q8BEb%<?> Ù%D%Q�Q=GFS�P=S�IF9;S:6�<?P�Y�×�Y]68S�B]Ø*I%S:<�Q8G%S�6�Q=G%S�<U9;S:IeQ=<`Q�Z!I%Bd6_Q8G%S,ICD%Ü�ÙKS�6B]Ø½68S:>�S:<`[dS�6HP�â


85

Contract-based interactions Event-based execution interactionsSynchronous communications J2EE (RMI, Corba) JavaBeans, ActiveXAsynchrnous communications J2EE (JMS) none identified

\�]�_Ba ćb�¨Be �½��uH¿:r:��zvuHx�r�¨#qHr:�A®;rt{eu8{]��x

% &`© l�p 471�.R3C<=*"0ªER6B0R«2q=<(0R:þ�G%<?PWPRD%ÙOPRSt>aQ=<UBEIÉ9;S:P8>�68<UÙOStP�GFB\×ÁS�à%>�S:b;Q=<UBEIOP�>:Y]IäQ8B;9%Y�ZfÙOS+P=<`ÚdIFY]TUS:9ùY]IF9�GFY]IO9;T`St9fØºBd6�Q8G%SLQ=G%68S�S¯>�BdÜLãbKBEI%S:IdQ Ü¯B;9;S�T?P:âB¬*S�Q DFP�Ù%68<UScSFZ�68S:>:Y]TUTKQ=GFY]Q 1 p 4@[email protected]<=*"0i>9<(:-026Bq=<(0R: é í�îªM;<?P Y�Ü¯St>HGFY]I%<?P=Ü DFPRSt9�Q8B¯I%B]Q8<�ØºZD%IF9%S:P=<`6HY]Ù%TUS�P=<�Q8DFY\Q8<`BdIFPWQ=GOY\Q!GOY]Ü¯bOS:6AQ=GFSÃP�QHY]IF9FY]6H9�S�à;S:>�D%Q=<UBEIñB]Ø,YÇb%68BEÚd68YEÜ Q=B�>�BEIeQ8<ÌCD%Sdâ*óýG%S�I¼YEIS�à%>�S�b;Q8<`BdI�B;>�>�DF68P:ME68S�TU<UYEÙ%TUS�P=B]Ø¹Q�×�Y]68S <UP�Y]ÙFT`SXQ=B�68S:Yd>aQ�YEb%b%68BEb%68<?Y\Q=S:T`ZL<UI�BE6H9;S�6�Q=BL>�BEIeQ8<ÌCD%S�<�QHP�S�àCSt>�D;Q8<`BdIBE6tMjY\Q�TUS:YdP�QtMKQ=BÃ<UIeQ=S:6=68D%b;Q�<�QWb%68BEbKS�68T`ZÇ× G%<UT`SLb%68S:P=S�68[C<Ì%Ú9%Y\QHY�<UIdQ8S�Úd6=<`Q�Z�YdPXÜ!DF>HG�YdPXbKBdP8P=<`Ù%TUSEâjï,I 1 p�471�.R3C<=*"0®ER6B02«Rq(<=02:�>CM >�391�,°¯ l�± hR² é �%M í%M`ì9³;M`ì9�;M¦ê@´:î*B7µKS:68P�>�BdIeQ=68BETjP�Q86=DF>�Q=D%68S:P�S:IFY]Ù%TU<UI%Ú+9;S�[dS�TUBEbKS�6HP_Q8B9;S��FI%S,b%68BEÚd68YEÜáD%I%<`Q8P,å§SEâ ÚFâEQ=G%S,P=BED%6H>�S >�BC9%S B]Ø*YWb%68BC>�S:9;DF6=Sdé`ì9³tîªMEYA>�TUYdP=P|9%Sc�FI%<`Q=<UBEIfé ��îmâ�â:â8è|YdP|b%68B]Q=St>aQ8S:9ÙCZY¯P=S�Q,B]Ø 1 p 4@[email protected]<=*"0ªER6B0R«2q=1�;�> <UIfBE6H9;S:6�Q8B�>�YEb;Q=D%68SAS�à%>�S�b;Q8<`BdIFY]T*P=<�Q8DFY\Q8<`BdIFP�Q=GOY\Q,Ü+Y�ZÃÙKS�PR<UÚEIOY]TUS:9<UIñQ=G%StPRSÃb%6=BEQ=St>aQ=St9÷6=S:ÚE<UBEIFP:â*ú�Yd>HGñGFY]IO9;T`S:6�<?P!9;S��FI%St9ÉQ=Bù>:Y]b;Q8D%6=SÃBC>:>�D%6868S�IF>�S:PABEØ YäÚE<U[ES�I÷S�à;>�S�b;Q8<`BdIQ�ZCbOSdâdþ�G%S,P=<UÚEIFYET%B]Ø#Y]I+S�à;>�S�b;Q8<`BdI¯b%6=B\[dBEödS:P'Q=G%S,<UIeQ=S:6=68D%b;Q8<`BdILBEØ#× GFY\Q_<?P�>�D%6=68S�IeQ8T`Z�ÙKS�<UI%Ú�S�à;S:>�D%Q=S:9¯YEIF9Q=GFS�P=S:YE68>HG¯ØºBd6�YEIÃYE9;StÛeDFY\Q8S,GFY]IO9;T`S:6:âCûXYEIF9;TUS�6�PRStY]6H>HG+Ü¯S:>HGFYEI%<UP=Ü+P�YE6=S�ÜLBeP�Q8T`Z¯ÙFYdPRSt9+BEI·¶�BeB;9;S:I%BEDFÚEGb%68BEbKBdP8Y]T�é ítîAåºS:ÚFâ2<ÌýNu¸¹¸3Y]IF9$�eY�[\YdèW<UI¼× G%<?>HG¼S�à;>�S�b;Q8<`BdIFP�YE6=Sb%68BEbFYEÚdY\Q8S:9�Q=GF6=BdD%ÚEG÷Q8G%SÃS�àCSt>�D;Q8<`BdIG%<?P�Q8BE68ZEâ;5%68BEÜ YL>�BdÜLbKBEIFS�IeQ�bKBE<UIeQ B]Ø'[C<US�×AM;PRDO>HGY!ÜLSt>HGFY]IF<UP=Ü ×�BdD%T?9�b%68BEbFYEÚdY]Q=S,S�à;>�S�b;Q8<`BdIFP�PR<UÚEIOY]TUS:9ÙCZÉ>�BEÜ¯bKBEI%S:IdQLYE>aQ8<`[C<`Q=<US:PWQ8BfQ=GFS�<U6!>�Bd6=68S:P=bKBEIF9;<UI%Úf>�TU<US�IeQ8P�× G%HGñ×�BEDFTU9ÉQ8G%S�68S�ØºBd6=S+ÙKSÃY]ÙFT`S+Q8BäGFYEIF9;TUSS�à%>�S�b;Q8<`BdIFP�<Ì�Q8G%S�>�BdIdQ8S�àCQ B]Ø�Q=G%SWØ§YE<`TUS:9ÇP=S�68[e<?>�SW>�YET`T?P:âl�p 471�.239<(*-0ºE26B0R«Rq(<(0R:®s�*�;�)Ih»47*-,/.�*-0R1�0�39>�¯�1!:¼&½>C1!>9>C<=*"0»¾�1!6B0R>�²AF Q8G%S�<U6APRbKS:>�<[�O>:Y\Q8<`BdIòé¦ê�³�î�YEIF9BEDF6!S�àCbKS�68<UÜLS:IeQ8PLBEIñQ8G%S§� # IOï�@ñbFTUY]QRØºBE68Ü-é`ì�î,PRG%B\× Q8GFY\Q¯S�à%>�S�b;Q8<`BdIòGFYEIF9;TU<Ì%Ú�<UP¯Yd>HG%<`S:[ESt9÷Q=G%68BEDFÚEGPRQ8Y]IO9%Y]6H9Z�eY�[\YX>�BdIeQ=68BET;P�Q86=DO>aQ=DF6=StP�å �=�~�N¿v¡N�A�À¡�Á!Â¼��Á8�Ã�AÄ�Å9Å9Å è�âEþ�G%S�Ü¯<U9%9%T`S:×�YE6=SWå(g,Öäô'BE6�N # g,æ�ï�è'S:IFY]ÙFT`StPQ=B�Q=6HY]IFP=bFY]68S�IeQ8T`Z!DFPRS�PRS:6=[dS�6_>�BdÜ¯bOBdI%S�IeQ8P�YEP^�eY�[\YWBEÙ8£�St>aQHP�ÞEQ=G%S�ÜL<?9%9;TUS�×�Y]68S,Y]ÙOP�Q868Yd>aQ8P�9;<UPRQ=68<UÙ%D;Q=<UBEIäå¸>aØ�âP=S:>aQ8<`BdI�ê;â¦êEè,ØºBE6WPRQ8Y]IO9%Y]6H9fS�à;St>�D;Q8<`BdIùYEP�×�S:T`T|YdP,ØºBd6�S�à;>�S�b;Q8<`BdIùGFYEIF9;TU<ÌFÚYEP�>�BdÜ¯bOBdI%S�IeQ8P�DFP=S!Yb%68B�à;Z68S�b%68S:P=S�IeQ8Y]Q=<UBEILB]Ø*68S�Ü¯B]Q8S,>�BdÜLbKBEIFS�IeQ8P:âdþ�G%<?P_ú�û�@+P=S�S:Ü¯P_Q=B�P8Y\Q8<UPRØºZ¯9;S�[dS�TUBEbKS�6HP|I%S�St9%P�YdP|<`Q�YE9%BEb;QHP|Q=GFSÙKS�GFY�[C<UBE6�B]Ø�PRQ8Y]IO9%Y]6H9�Nu¸¹¸¹xA�eY�[\Y+T?Y]I%ÚdDFY]ÚdS:P ú�û�@;PW× G%<?>HGùb%68BEbOY]ÚdY]Q=S�S�à%>�S�b%Q=<UBEIFPXQ=G%68BEDFÚEGäS�àCSt>�D;Q8<`BdIG%<?P�Q8BE68ZEâ%þ�GCDFP:M%>�BdIdQ8S�àCQRã�P=S�IFP=<�Q8<`[dS�S�à%>�S�b%Q=<UBEI�GFY]IF9%T`<UI%Ú+<?P�bOBeP=P=<`ÙFT`SAYEP P=G%B\× I�<Ì·�FÚdD%68S:P��¯Y]IF9�ëdYFâ

...// A component invoking the buy methodthrough RMItry { utx.begin(); // Starts a first transaction t1.buy(10); //request on the bean utx.commit(); //Commits the transaction }catch (LimitedStockException exc) { int n = exc.getMessage(); println("Buying only" + n + "units"); t1.buy(n); }...

...// Remote Business method implementation.public void buy(int s) { if (stock>=s) { newtotal = newtotal + s; return; } else throw(new LimitedStockException(stock);)}...

\^]`_Ba ćbnÆ�e p#Âd�:�A®esvu�r�¨#�Au8��dr]w!zv{]¢�r\qa��zvr:{L»_z¦��¯©�yLk

l�p 471�.239<(*-0UER6B02«Rq(<=02:Ts�*"; l 47*-,/.�*-021!0�39>�¯�1!:¼&!t 6@KB68¾�1!6B0R>�²AF ômØFYEI�S�[dS�IeQ'S:ÜL<`QRQ8S:9�ÙeZAY�>�BEÜ¯bKBEI%S:IeQå�� @��{N��-Ç èWT`StYE9%P�Q8B�Q=G%S+P=<`ÚdIFY]T½B]Ø�Y]IÉS�à%>�S:b;Q=<UBEIÉ<UIÉYEI%B]Q8G%S�6�>�BEÜ¯bOBdI%S�IeQ�Q=GFY]Q�>�YEI%I%B]QA>�Y]Q8>HGÉ<�QtM#Q=GFSS�à%>�S�b;Q8<`BdI+<UP�PR<UÚEIOY]TUS:9LQ=B�Q=G%S�S�[ES:IeQ�9;<?PRbFY]Q8>HG%S:6�å¸>aØ�âC5�<UÚEDF6=S,ëe>:è�âeþ�G%<?P_S:[ES:IdQ�9;<UP=bFY]Q8>HG%S:6�>�YEI+BEI%TUZLÚES�IFS�6=ã<?>�Y]TUTUZLGOY]IF9;TUS�Q=G%S�S�à%>�S:b;Q=<UBEIÃ× <�Q8G%BED;Q b%68BEbOY]ÚdY]Q=<UI%ÚA<`Q�Q8B·� �A�A�7�N{N�A��Ç åº<`Qr£�DFP�Q�b%68<ÌeQHP�YLP�QHYE>HöLQ=6HYE>�Stè,é ê7��îªâþ�GCDFP:MCQ=G%SWS�à%>�S�b;Q8<`BdI�>:Y]I%I%BEQ�ÙKSAb%68BEbFYEÚdY]Q=S:9+Q=BLQ=G%SWS:ÜL<`QRQ8S�69È P >�BEIeQ=S�àCQ:âF@CDF>HG�<?PRBdTUY]Q=<UBEIÃBEØ2>�BEÜ¯bOBdI%S�IeQHP>�BdIF>�S:6=IF<Ì%Ú�S�à%>�S:b;Q=<UBEI+GFYEIF9;TU<ÌFÚ�<?P�>�BEG%S:6=S:IdQ�× <�Q8G�Q=GFSX<UIdQ8S�6HYE>�Q=<UBEI�P8>HG%S�Ü¯S,BEØ#Q=G%StPRS�>�BEÜ¯bKBEI%S:IeQ8P:Þd× G%S:II%BEQ=<`ØºZe<UI%Ú+Y]IS�[dS�IeQ�ú�>�BdÜ¯bOBdI%S�IeQ8P�S�àCbKS:>�Q I%B¯6=StPRbKBEIFP=SEMeS�<`Q=GFS�6 I%Bd6=Ü+Y]TjBd6�S�à;>�S�b;Q8<`BdIFY]T|å¸>aØ�âFP=D%ÙFP=S:>�Q=<UBEIê;âUìtè�âl�p 471�.239<(*-0ÉER6B0R«2q=<(0R:Qs�*";�)+jÊ4@*",/.n*"0R1!0�3C>T¯�1�:2&2ËmÌ�Í5>�²AF ï >:>�BE6H9;<UI%Ú�Q8B5�eÖù@PRbKS:>�<[�K>�Y\Q8<`BdIùé¦ê�³�îY]IO9ÃQ8B+BED%6 S�à;bOS:6=<UÜ¯S�IeQ8P�BdIQ8G%SÎ� # IFï�@b%T?Y\Q=ØºBE68Ü�M;S�à%>�S�b%Q=<UBEIÇGFY]IO9;T`<UI%Ú�P=D%b%bKBE6=Q <ÌfÖäc�æ�P,<?P�T`<UÜ¯<�Q8S:9#ÞY]I�S:6=68BE6�9;DF6=<UI%Ú¼Y/�eÖù@õÜLStP=P8Y]ÚdSfPRS:IF9ý>�YEIøÙKSäI%BEQ=<��FS:9õQ8BñQ=G%S�PRS:IF9;S�6ÃÙ%D;QYEIøS�à%>�S�b%Q=<UBEIýPR<UÚEIOY]TUS:99;D%68<UI%Ú¯Q=G%S�S�à;S:>�D;Q=<UBEIÇB]Ø½Q8G%S�>�Bd6=68S:P=bKBEIF9;<UI%Ú¯YE>�Q=<U[e<`Q�Z>:Y]I%IFB]Q,ÙKS�b%68BEbFYEÚdY\Q8S:9ÃQ=B+<`Q8P�>�Y]TUTUS�6tâ%ô�IF9;S:S:9#MFYEI


86

RMI m()

Event

Exception

Dispatcher

EventJavaBean2JavaBean1

return

Event

Middleware

ObjectShared

writeread

MDB

m (redelivered)

m

return

m

exceptionalresponse

(b) Contract−based interactionsusing asynchronous communications

(a) Contract−based interactionsusing synchronous communications

(c) Event−based interactionsusing synchronous communications

SessionBeanClient Client

\^]`_8a ćb�Ï"e �2rt�A��d{ezvqa��z�r:{ex|zv{¯®E��uHx�uH{eq8u r:¨#u8ÂEqHu8®d��zvrt{dx

S�à%>�S�b;Q8<`BdIÇP=<UÚEIFYET`St9Ã<UIÇBEI%S�Q=GFS�YE>�Q=<U[e<`Q�Z�BEØ½Y¯Öäc�æß× <`Q=GFBED;Q,ÙKS�<UI%Ú+GFYEIF9;TUS:9�T`B;>:Y]TUT`Z�<?P I%BEQ,b%68BEbFYEÚdY\Q8S:9Q=B�Q=GFS�>:Y]TUT`<UI%Úù>�BEIeQ=S�àeQtâ|þ�G%SÃBdI%T`ZñÜ¯St>HGFY]I%<?P=Ü bF6=B\[C<?9;S:9ÉQ8BÉYET`TUB\× Q=G%S�b%68BEÚE6HY]Ü¯Ü¯S�6�Q=B÷9;S�Q8S:>aQLQ=GFS:P=SP=<�Q8DFY\Q8<`BdIFPA<?PAQ=GOY\Q�Q8G%SÃÜ¯S:P8P8Y]ÚESLQ8GFY\Q�<UI%<`Q=<?Y\Q8S:9÷Q8G%SÃYE>�Q=<U[C<�Q�ZÉ<UP�6=St9;S�TU<`[dS�68S:9�åº× <`Q=G¼Y§SOY]ÚäP=S�Q�Q8BfQ=68D%S�èQ=BÇQ8G%SÃÖäc�æÁ<UIñ× G%<?>HG÷<�Q�<?P�S�àCSt>�D;Q8S:9�å§>�Ø�â�52<UÚFâ*ëdÙOèaâ'þ�GCDFP:M#Q8Bä9;<[µjS�68S�IeQ8<UY]Q=S+68S:>�S:<`[dS:9�Ü¯S:P8P=YEÚES:P�Øº68BEÜS�à%>�S�b;Q8<`BdIõI%BEQ=<��O>�Y]Q=<UBEIFP:M2Q=G%Sf9;S:[ES:T`BdbOS:6LGOYEP!Q=BÉQ=StP�QäåºØºBE6+S:Yd>HGòÜ¯S:P8P8Y]ÚESÇ9;S:T`<U[ES:6=Z%è�<�Ø�Q=G%SfÜ¯S:P8P8Y]ÚES<UP68S:9;S:T`<U[ES:6=St9äBE6AIFB]QÃå§>�Ø�â'52<`ÚdD%68S+ídèaâ'5F6=BdÜ BEDF6AbOBd<ÌeQ�B]Ø�[C<`S:×AMjQ=G%S+GOY]IF9;TU<UI%ÚfB]Ø�S�à%>�S:b;Q=<UBEIOPW<ÌÉQ=GFSN�ï>�BdÜ¯bOBdI%S�IeQ8P�×�SAP�Q8DF9;<US:9�<?P�Q=BCB¯bOBCBd6 ÙOSt>�Y]DOPRSdÞìEâ�ú|à%>�S�b;Q8<`BdIFPAY]68S¯I%B]QAb%68BEbFYEÚdY]Q=S:9fQ=G%68BED%ÚdGùQ8G%S¯S�à;S:>�D;Q=<UBEIÉG%<?P�Q8BE68ZEâ#ômQ�<?P�Q=G%S:6=S�ØºBE68S!IFB]QAbOBeP=P=<UÙ%T`SLQ8B9;S��FI%S�>�BEIeQ=S�àCQRã�PRS:IFPR<`Q=<U[ES�Q86=StY\Q=Ü¯S:IdQHP <UIfGFY]IF9%T`S:68P:âFûXYEIF9;TUS�6X>:Y]IÇBEIFT`Z�ÙOS�ÚES�IFS�68WY]IO9ÇÙOS�DOPRSt9#M%ØºBd6S�à;YEÜ¯b%T`SdMCQ=B�9;<?P=b%TUY�Z+S:6=68BE6�Ü¯S:P8P8Y]ÚEStPWå§>aØ�âO5�<UÚFâKíEèaâ%þ�GF<UP <?P8PRD%SW× <UT`T'ÙOS�9;S:[ES:T`BdbOSt9Ã<UI�P=S:>�Q=<UBEI§�%âUìEâ

ê;â þ�G%S:6=S�<?P�I%B¯ÜLStY]IFP�Q8B¯>�BCBE6H9;<ÌOY\Q=SW>�BdIF>�DF6=68S�IeQ�Yd>aQ8<`[C<`Q=<US:P�B]Ø½>�BdÜLbKBEIFS�IeQ8P:M;Y]IF9#MCQ8GCDFP�M;IFB!S�à;>�S�b;Q8<`BdI>�BeBd689%<ÌFY]Q=<UBEI*â;5FBE6,S�à;YEÜ¯b%T`SdM;× G%S�IfYEI�Yd>aQ=<U[C<�Q�ZÃ× G%HGÇ68S:ÛeD%StP�Q8S:9�PRS:6=[C<?>�S:P�P=<`ÚdIFY]T?P Y]I�S�à%>�S�b;Q8<`BdI*M%<`QP=G%BEDFTU9+ÙKSXbKBdP8P=<`Ù%TUS Q8B�Q=S:6=Ü¯<UIFY\Q8S Q=GFSXbKS�IF9;<UI%ÚLPRS:6=[C<?>�S:P_<�Q�6=StÛeD%S:PRQ=St9#âdþ�G%<?P_<?P8PRD%S�× <`TUTKÙOS�9;S�[dS�TUBEbKS:9<UIfPRSt>aQ=<UBEIÐ�%â¦ê;â

�%â þ�G%S:6=S�<?P½I%BWÜ¯S:Y]IOP2Q=BA>�BdIF>�S:6RQ½S�à%>�S:b;Q=<UBEIOP2Q=GFY]Q½B;>:>�D%6_>�BEIF>�D%6=68S�IeQ8T`Zdâ�þ�GF<UP½T?YE>HöAÜ+Y]ödS:P½<`Q|<`Ü¯bKBdP8PR<UÙ%TUSQ8Bä>�BE6868S:>aQ8T`ZfÜ+YEIFY]ÚdS¯P=<`Q=DFY]Q=<UBEIFPW× G%S:6=S¯Ü!D%T�Q8<`bFT`S�S�à%>�S�b%Q=<UBEI÷PR<UÚEIFYETUPW68S�[dS:YET½Y�D%IF<UÛeD%S+b%68BEÙFT`S:Ü�â'ômQYETUP=BWGFY]Ü¯bKS�6HP2Q=G%S b%68BEÚd68YEÜ¯ÜLS:6CÈ P'>:Y]bFYEÙ%<UT`<`Q�ZAQ=BAbF6=B\[C<?9;S V BC@�bKBETU<?>�<US:P å¹ØºBd6_S�à%YEÜLbFT`SdM\G%S�x]PRG%S >:Y]I%I%BEQ9;<?PRQ=<UI%ÚED%<?P=GÃD%IF9%S�6�>�68<�Q8:Y]TOØº6=BdÜ >�6=<`Q=<?>�YETFS�à;>�S�b;Q8<`BdIFPHèaâCþ�G%<UP�<?P=P=D%S�× <`TUTjÙOS�9;S�[dS�TUBEbKS:9+<UIP=S:>�Q=<UBEIT�Fâ �Fâ

public void onMessage(Message message) {

// Exceptional execution try { // The programmer tests if the message has been redelivered if (message.getJMSRedelivered()) { // The programmer handles the exception without information // about the execution context in which the exception has been signaled System.out.println("Error while handling" + message); return; } } catch(Exception ex) { System.err.println(ex.toString());}

//Standard execution try { ... } catch(HandledExceptionType ex) { System.err.println(ex.toString());}}

\�]�_Ba ćbnÑ�e p*Âd��A®esvu�r:¨ju8ÂEqHuH®d��zvr:{¯�C��{Cwdsvzv{e¿�zv{+�Ay5Ò �

Contract-based interactions Event-based execution interactionsSynchronous communications Typical EHS : satisfying Generic EHS: isolated componentsAsynchrnous communications dedicated EHS : unsatisfying none identified

\^]`_Ba ćbnÓ�e Å½�eu,��qHrt�A®;r:{euH{\��x|qa��uH¿tr��z�u8x


87

Ô Õi2Ö�Ó�Õ�ÐB2�×�Î�ÏB�w HÑ_Ðiv,Ô� �,Ï%ÕRÑ�ÎØ��|ÎXÒ��RÕRÎ�� Õ=ÎÚÙ�Û ÔjÑ��AÑ�Î�'Î�ÏB�ïXPXPRG%B\× IÇ<UI�Q=G%S�bF6=S:[e<UBEDOP PRSt>aQ=<UBEIñå¸>aØ�âO52<UÚÜXdè,N�ïÁ>�BEÜ¯bKBEI%S:IdQHP�å§P=DF>HGfYEP Öùc�æ�PHè Y]68S�Q=G%S�Ü¯BeP�Q,b%68BEÙ%ãTUS�Ü+Y\Q8�× G%S�IS�à%>�S:b;Q=<UBEIÃGFY]IF9%T`<UI%ÚL<UP�>�BdIF>�S:6=I%St9+ÙKS:>�YEDFP=SXB]Ø2YEP=ZeIO>HG%6=BdI%BEDOP�>�YET`T?P:âeþ�G%<?P�PRSt>aQ=<UBEI�Y]<UÜ+P�Y]Qb%68S:P=S�IeQ=<UI%Ú¯Q8G%S�68S:ÛeD%<U6=S:ÜLS:IeQ8P >�BdIF>�S:6=IF<Ì%Ú¯× GFY]QX×�SWQ=G%<UI%öÇPRG%BdD%T?9ÇGFY]b%bKS�I¼å¸Y]IF9�× G%<?>HGfS�àCQ868Y+>�BEIF>�S�b;QHP× <UT`T;GFY�[dS_Q8B�ÙKS >�BE6868S:>aQ8T`ZWÜ+Y]IOY]ÚESt9Fè#<UI¯PR<`Q=DFY]Q=<UBEIFP2<UI�× G%<?>HG¯Y]I!YdPRZCIF>HGF6=BdI%BEDFP=TUZX<UIe[dBEödS:9�P=S�68[C�S�>:Y]I%I%BEQÙKSWØºD%T[�OT`TUS:9�ÙKS:>�YEDFP=SAB]Ø'Q8G%SAB;>�>�D%6=68S�IO>�S�B]Ø|Y]I�S�à%>�S:b;Q=<UBEI*â

©¼&(' Ý§1!1!«®s�*�;T4@*"0�391 p 3CPR6Bq(<=Þ76839<(*-0ª;A1�>C.�1!4�3óýG%S:IÉY�>�YET`TUS:9�YE>aQ8<`[C<`Q�ZäPR<UÚEIOY]T?P�YEIùS�à%>�S�b;Q8<`BdIù<`QA>:Y]I%IFB]QWGFY]IF9%T`SdM <(3C>Ð476�q(q(<=02:i6B473C<LK <(3NM»<(>·39E21w¾�1!>C3.rq(6B4@1DßàE21�;A1ª39*áE26�02«Rq(1ª39E2<=>/1 p 471�.239<(*-0â.R;�*".�1�;AqLM Þ|<`Q+<UPLQ8G%SfBEIFT`Zñb%T?YE>�SÇ× G%S�68SÃQ8G%SfBEÙB£�S:>aQ8<`[dSQ8YE6=ÚdS�Q8S:9¼ÙCZñQ8G%Sä>�Bd6=68S:P=bKBEIF9;<UI%ÚÉPRS:6=[C<?>�SÇ>�Y]TUT <?P+öCI%B\× IõYEIF9¼Q8GCDFP¯Q=GFS�ÙKS:PRQ�b%T?YE>�SQ8B÷b%6=BdÚE6HY]Ü × GFY]QP=G%BED%T?9ÇÙKS!9;BdI%S�<UIù>�YdPRS�B]Ø_Y�9;S�ØºS:>aQtâjó�S�Q=GCDFP,ÙKS�TU<US�[ES�Q=GFY]QXQ8G%S!P=B]Ø¹Q�×�Y]68S�>�BdIdQ868Yd>aQ,<?P,Q8B�ÙKS�68S:P=bOSt>aQ=St9<UI�Q8G%S+>�YdPRS¯B]Ø�S�à%>�S:b;Q=<UBEIOY]T½6=StPRbKBEIOPRStP�YdPW<�QA<?PWØºBE6WI%Bd6=Ü+YET|BEI%StP�<UI÷BE6H9;S�6�Q8B�S:IFY]ÙFT`S+>�BdIeQ=S�àCQ=ãmP=S�IFP=<`Q=<U[ESQ=68S:Y]Q=Ü¯S�IeQHP B]Ø½S�à%>�S:b;Q=<UBEIOP�âFVXI;ØºBE6=Q=DFIFY\Q8S�TUZEM;Q8G%<UPXÙOS:GFY�[C<`Bd6 <UP,I%B]Q�YET`×�Y�Z;P�YE9;Bdb;Q=St9ÃØºBd6�N�ïÁ>�BEÜ¯bOBdI%S�IeQHPå§>�Ø�âFP=S:>aQ8<`BdIÇê%â �eè�S�[ES:I<`Ø�N�æ�ç�P�b%68B\[e<?9;SA9;St9;:Y\Q8S:9ú�û�@;P:â

ï,T`Q=S:6=IOY\Q=<U[ESWb%68BEbKBdP=<`Q=<UBEIFP:é êdídM ü]î*S�à;<UPRQ Q=GOY\QX9;B¯I%BEQ Yd9%9;68S:P8P�Q=G%<?P b%68BEÙFT`S:Ü¯Y]Q=<?>XÙKS:>:Y]DFP=SWB]Ø2Q=G%S:<`6,>�S�I;ãQ=6HY]TU<Uÿ�S:9WYdPRbKS:>�Q8P:â:5%Bd6*S�à%YEÜLbFT`SdM]é ê\îdb%68BEbKBdP=S:P#Y Q=6HY]IFP=bOBePR<`Q=<UBEIWBEØdQ8G%S |~¦9¤�{c�~�9}o|��A� ÜLB;9;S:TE× G%<?>HGA<`Q8P'YED;Q=GFBE6HPb%68S�[C<UBEDFP=T`Z+bF6=BdbOBePRSt9�<UIÃQ8G%SWØº68YEÜ¯S�×�BE68öLBEØ2Öäï�@;PWé ã%M ü�îªÞF<�Q,P=D%ÚEÚdS:PRQ8P�Q=G%SWDFP=SWB]Ø½Y]I�ú�û�@DFP=<ÌFÚ |�{��}��-{�ä¡N� � ¤B��-{��=| Q=B�9;S�Q=St>aQ�YEIF9�GFY]IO9;T`S!>�BEÜ¯bKBEI%S:IeQ8P�Ø§YE<`TUD%68S:P:âFç_68BEbFYEÚdY]Q=<UI%Ú¯S�à%>�S:b;Q=<UBEIFP Q=BÃP=DF>HGf9;S:9%:Y\Q=St9S�IeQ8<�Q8<`StP�9;BCS:PAIFB]QAb%68B\[e<?9;SLQ=GFS�>�Y]bOY]Ù%<UT`<`Q�ZäQ8B�Q=G%S�× 68<`Q=S+>�BdIdQ8S�àCQRã�P=S�IFP=<�Q8<`[dS¯GFY]IF9%T`S:68PAYEIF9#M#Q8GeDOP�M*TU<UÜL<`Q8PQ=68S:Y]Q=Ü¯S�IeQHP½<ÌLGFY]IO9;T`S:68P2Q8BWÚES�IFS�68�>�BdIdQ8S�àCQRãm<UIF9;S�bKS�IO9;S�IeQ|6=StYE>�Q=<UBEIFP�åºS:ÚFâ\S:6=68BE6½Ü¯S:P8P=YEÚES�9;<?PRb%T?Y�Z%èaâ\ÖfBd6=S�ãB\[ES:6:M]Q=G%S�>�S�IeQ868YET`<Uÿ:Y]Q=<UBEI¯B]ØjQ=GFSXGFYEIF9;TU<Ì%Ú�B]Ø*S�à%>�S�b;Q8<`BdIFY]T%S:[ES:IdQHP_Ü+Y�Z¯YAµjS:>aQ V Be@LÙKS:>�YEDFP=S,<�Q�Ü+Y�ZL>:Y]DFP=SÙKB]QRQ8T`S:I%S:>Hö;P�× G%<?>HGf>�YEI�P=T`B\× 9;B\× I�Q=G%SW× G%BdT`S�P=Z;P�Q8S�Ü YEIF99%S:>�68S:YdPRS�<`Q8P 68S�TU<UYEÙ%<UT`<`Q�ZäéUì:ü�îmâ

©¼&o% Ý§1!1!«®s�*�;T4@* *";�«R<(0R6839<(*-0É39* *-q(>ú��>�<US�IeQ8T`Z GOY]IF9;TU<UI%ÚõS�à%>�S�b%Q=<UBEIFP<ÌðP=ZCPRQ=S:Ü+PÃQ8GFY\QÇDFP=SÉYdPRZCIF>HGF6=BdI%BEDFP>�BdÜLÜ!D%I%<?>�Y]Q=<UBEIFP<`Ü¯b%TU<US:P�Q=GFS9;S��FI%<`Q=<UBEI BEØ�ÜLStY]IFPÃQ=BõÜ+Y]IFYEÚESäYE>�Q=<U[C<�Q8<`StP>�BeBdbOS:68Y]Q=<UBEI*â�é`ì9ã;MUìCX�îWb%68B\[e<?9;StP�Yò>�TUYdP=P=<[�K>�Y\Q8<`BdI�B]ØAQ=GF6=S:SQ�ZCbOStP�B]Ø|>�BdIF>�D%6868S�IF>�Z�Y]IF9�P�Q8DF9;<US:P�Q8G%S�<U6 <UÜLbOYE>aQ,BdIS�à%>�S�b%Q=<UBEIÇGFY]IO9;T`<UI%ÚOÞ

J c�<UP(£�BE<UIeQ�>�BEIF>�D%6=68S�IO>�Z!YEb%bKS:Y]6HP|<UIÃP=ZCPRQ=S:Ü+P|Q=GOY\Q�b%68B\[C<U9%S,I%B�>�BeBd689%<ÌFY]Q=<UBEI¯B]Ø*>�BEIF>�D%6=68S�IeQ�Yd>aQ=<U[C<�Q8<`StP�â5FBE6�S�à;YEÜ¯b%T`SdM#Q=GFS�68S+<UPAIFBäPRZ;PRQ=S�Ü T`S:[ES:T_Ü¯S:Y]IOPWQ=Bä>�BeBd689%<ÌFY]Q=S+Öäc�æ«Yd>aQ8<`[C<`Q=<US:PA× G%S:IñS�à%>�S:b;Q=<UBEIOPB;>�>�D%6�åºIFB+ÚETUBEÙFYETjYd>aQ8<`[C<`Q�Z�<UP >�BEIFP=<?9;S�68S:9ÃØºBE6,P=DF>HGÇ>�BEÜ¯bKBEI%S:IeQ8PHèaâ

J N�BdÜLbKS�Q8<�Q8<`[dS,>�BdIF>�D%6868S�IF>�Z�Y]b%bKS:YE68P½<UI+PRZ;PRQ=S�Ü+P2Q8GFY\Q_b%68B\[C<U9%S�Ü¯St>HGFY]I%<?P=Ü¯P2Q8B�Y�[EBd<U9�<ÌF>�BEIFP=<?P�Q8S�IF>�<`StP>:Y]DFP=S:9fÙCZä>�BEIF>�D%6=68S�IeQ�DFPRStPXBEØ�P=ZCPRQ=S:Ü 6=StPRBdD%6H>�S:P�åºÚES:I%S�6HY]TUTUZQ8GFY]IFöCP�Q8BÃTUBC>HöeãmÙFYEP=S:9äÜLSt>HGFY]IF<UP=Ü+P8è�â@CDO>HG!Ü¯S:>HGOY]I%<?PRÜ+P½S�àC<?PRQ½YEIF9!>:Y]ILBEb;Q8<`BdIFY]TUTUZAÙOS DFP=S:9!× <`Q=G¯Öäc�æ�P|<`ØR� å�æ � � �A�A� å �Ã�A��|c�@¡c��}(�A� æ�ç^è;èBd6Î�vå zO� � �A�A� å �Ã��B|��7¡��=}(�� zv{c�~�9}(¡N{À� <?P�DFP=S:9Q=B+9;S:T`<UÜ¯<�Q�9;<UPRQ=68<UÙ%D;Q=St9Q=6HY]IFP8YE>�Q=<UBEIFP:â

J N�BCBEbKS�6HY\Q8<`[dS�>�BdIF>�DF6=68S�IF>�Z�<?P'Q=G%S�öC<ÌF9�B]ØO>�BEIF>�D%6=68S�IO>�ZXDOPRSt9�ÙCZAPRZ;PRQ=S�Ü+P'Q=GFY]Q�b%68B\[C<U9%S�P=BEÜ¯S�P=D%b%bKBE6=QQ8BÜ+Y]IOY]ÚES!>�BETUT?Y]ÙKBE6HY\Q=<UBEIOP,ÙKS�Q�×�S�S�I�YE>aQ8<`[dS�S:IdQ8<�Q8<`StP�â#5FBE6WS�à%Y]Ü¯b%TUSEMK× G%S:I�Y]I�YE>aQ8<`[C<`Q�ZÇQ=S:6=Ü¯<UIFY\Q8S:P:MS:<�Q8G%S�6*IFBE68Ü¯YET`TUZXBd6#S�à%>�S:b;Q=<UBEIOY]TUT`ZdM�<�Q�Ü�DFPRQ*ÙOS�bOBeP=P=<`ÙFT`S½Q8B öe<UTUTdY]TUT]I%BdI;ãªQ=S�68Ü¯<ÌOY\Q=St9�bOS:IF9;<UI%Ú,YE>�Q=<U[e<`Q=<US:P<`Q_<ÌF<�Q8<UY]Q=S:9*â;é`ìA´:îO>�T?Y]<UÜ+P�Q=GFY]Q�PRDF>HGLYW>�BCBEbKS�6HY\Q8<`[dS�>�BdIF>�DF6=68S�IF>�ZAÜ+Y]IFYEÚES�Ü¯S:IdQ½68S:ÛeD%<U6=StP2YEI�S�àCSt>�D;Q8<`BdIÜ¯B;9;S�T½Q8GFY\QAS:IFY]Ù%TUS:P�>�BdT`TUS:>�Q=<U[ES¯YE>�Q=<U[e<`Q=<US:P�Q8B�ÙKSLS�à;b%TU�<�Q8T`Zä68S�bF6=StPRS:IdQ8S:9#âj5%68BEÜ BdD%6WbOBd<ÌeQAB]Ø�[e<US�×AMP=DF>HGYL68S�b%68S:P=S�IeQHY\Q=<UBEI+×�BEDFTU9ÃÜ¯YEöES�<�Q bKBdP8PR<UÙ%TUS 39*w6B>C>9* 4@<(68391·ER6B0R«2q=1�;�>+3C*�39E21·;A1�.2;A1!>C1!0�396B0�3C>*-s�>9P24�ED4@*"q=q(1!4�39<LK"1§6�4�3C<(K <L39<(1!> âFômQ,×�BdD%TU9ÃQ=GFS�68S�ØºBE68SWÙOSAbKBdP8P=<`Ù%TUSWQ=B+ÚdT`BdÙFY]TUTUZ+Ü¯YEIFY]ÚdS�Q=G%SA<UÜ¯bFYE>�QBEØ�Q8G%SWØ§Y]<UT`DF6=SWB]Ø2S�<`Q=G%S:6XY¯PR<UI%ÚdT`SWbFYE6RQ8�<`bFYEIeQ�Bd6 Y+PRS�Q�BEØ�Q8G%S�ÜÇâ

þ�BP=D%Ü¯Ü¯YE6=<Uÿ�SdM#N�æ�ç�PWP=G%BEDFTU9fbF6=B\[C<?9;S�P=D%b%bKBE6=Q�ØºBd6�>�BeBdbOS:68Y]Q=<U[ES�>�BEIF>�D%686=S:IF>�Z�<Ì�BE6H9;S�6XQ=BS�IFYEÙ%T`S!Q=GFS>�BCBd689;<UIFY]Q=<UBEIÃBEØ½>�BEÜ¯bKBEI%S:IdQHP YE>�Q=<U[e<`Q=<US:P:â

©¼&`© Ý§1!1!«®s�*�;T1 p 4@[email protected]<=*"0ª4@*"0R471�;�3C6B3C<(*-0ª>9P¼.R.�*";93# IF>�S�Yd>aQ8<`[C<`Q�Z�>�BCBE6H9;<UIFY\Q8<`BdI�<?P|PRDFb%bOBd6RQ8S:9¯Y]IO9�<UIeQ=S�Úd68Y]Q=StP2YEI!S�à%>�S�b%Q=<UBEILGFY]IF9%T`<UI%ÚAÜ¯S:>HGFYEI%<?PRÜÇM\YWÜ¯S:Y]IOPQ=Bä>�BETUT`St>aQ�S�à%>�S�b%Q=<UBEIFPWB;>�>�D%686=<UI%Úf>�BdIF>�D%6868S�IeQ=TUZùY]Ü¯BdI%ÚfbFY]6=Q=<?>�<UbFYEIdQHPWB]Ø Yä>�BdT`TUS:>�Q=<U[ES+YE>�Q=<U[C<�Q�Z�Ü�DFPRQ�ÙKSb%68B\[C<U9;St9#â]ï,I+Yd>aQ=<U[C<�Q�Z�× G%HG+>�BEIF>�D%6=68S�IeQ8T`Z�P=S�IF9FP|6=StÛeD%S:PRQ8P2Q8BWYAP=S�Q|BEØj>�BEÜ¯bOBdI%S�IeQHP|Y]IF9L× G%<?>HG¯6=St>�S�<U[EStPBEIFS�Bd6 Ü¯BE68S�S�à%>�S�b%Q=<UBEIFYETK68S:P=bKBEIFP=S:P�Øº68BEÜ Q8G%S�ÜÇÞ


88

J Ü!DFP�Q_IFB]Q�68S:Yd>aQ|<`Ü¯Ü¯S:9%<UY]Q=S�TUZ�× GFS�I+D%IF9%S�6=ãm>�6=<`Q=<?>�YET;S�à%>�S:b;Q=<UBEIFP å§× G%<?>HG�9;BAI%B]Q_GOY]Ü¯bOS:6_<`Q8P_PRQ8YEIF9%Y]6H9S�àCSt>�D;Q8<`BdIOè�Y]68SWPR<UÚEIFYET`St9#M

J Ü!DFP�Q2ÙOS�Y]Ù%TUS|Q8B,Q8YEöES_<UIeQ=BXYd>�>�BED%IeQ*Q8GFY\Q2S�à%>�S:b;Q=<UBEIFP'6=St>�S:<`[dS:9W>�BdIF>�D%6868S�IeQ=TUZXÜ+Y�Z�GFY�[ES_IFB,bOS:6RQ8<ÌFS�IF>�S<UIF9;<U[C<U9;DOY]TUT`ZLÙ%D;Q�Ü+Y�Z!ÙOS,Ü¯StY]I%<UI%Ú]ØºDFTF>�BdT`TUS:>�Q=<U[ES�TUZå§6=StPRDFT�Q_Øº68BEÜ Y]I¯D%I%<?ÛeD%S,b%68BEÙFT`S:Ü BE6�YWbOBCBE6 V Be@TUS�[dS�T¹èaâ

æ�YEP=S:9�BEI�Q8G%S:P=S�<?9;S:YdP�M*éé´tî½PRDFÚEÚEStP�QHP�Q=G%S�DFPRSABEØ_Y+>�BEIO>�S�6=Q8Y]Q=<UBEIÇÜ¯S:>HGFYEI%<?PRÜÇÞ%× G%S:IfS�IeQ=<`Q=<US:PX× G%<?>HG�bOY]6=ãQ=<?>�<UbFY]Q=S�Q=B¯Y!>�BETUT`St>aQ=<U[ES�YE>�Q=<U[e<`Q�Z+>�BdIF>�D%6868S�IeQ=TUZ+PR<UÚEIFYETOS�à%>�S�b%Q=<UBEIFP�Q=B!Q=G%S:<`6 >:Y]TUT`S:6:MCY ��{~|��Aä[¦8�=}(��ÎêN¦8�-¡��=}(��>�BdIFP=<U9;S:68PXQ=GFS¯P=S�QWB]Ø�PR<UÚEIOY]TUS:9fS�à;>�S�b;Q8<`BdIFP�<Ì�BE6H9;S�6�Q=BÇS:[�YET`DOY\Q=S¯Y�DFI%<UÛeD%S¯S�à;>�S�b;Q8<`BdIõå¸Y ¡N�A��¡N{c�~�À{N�U{Ãë@�¡N{�¤��=}(�� è�× G%<?>HGÉ68ScSOS:>aQHPWQ=GFS�ÚETUBEÙFYET_P�QHY\Q8S�B]Ø�Q=G%S>�BETUTUS:>aQ8<`[dS�YE>�Q=<U[e<`Q�ZEâ�þ�G%<UP�ì9í"î^ì�ï@ð@ñÃï�òáï7óvì9ïCô�ñöõ�í"î <=>PR>C1!«i<(0$.rq(6�471Ð*"s½39E21·ßàE2*-q(1·>91@35*"s�<=02«R<LK <=«2PR6Bq^1 p 471�.R3C<=*"0R>Z>9<(:-026�q(1!«$¾vM$;A1!÷vPR1�>C3C1!«i>C1�;�K <(4@1!>Q=B+P=S:YE68>HGÃØºBE6 GFYEIF9;TUS�6HP�<Ì�Q=GFS�>�BETUTUS:>aQ8<`[dSAYE>aQ8<`[C<`Q�ZEâ

©¼&�ø Ý§1!1!«®s�*�;T6w>C.�1!47<(ùR4·1 p 471�.239<(*-0ªE26�02«Rq(<=02:�.�*-q(<=4�MOs�*";Ü¾2;A*-6B«R476B>C3C1!«®;A1!÷vP21!>C3C>ô�I+PRSt>aQ8<`BdI5�Fâ ê%Mt×�S�I%B]Q8�S:9!Q=GFS I%S�St9�Q8B�>�BCBE6H9;<UIFY\Q8S�>�BETUT`St>aQ=<U[ES�>�BdIF>�DF6=68S�IeQ|YE>aQ8<`[C<`Q=<US:P½Q8BWb%6=BdbOS:6=TUZAGFYEIF9;TUSS�à%>�S�b;Q8<`BdIFP�â:ô�IZ�eÖù@+å§>�Ø�âtP=S:>�Q=<UBEI�ê%â êdèaM:P=DF>HG�Y�ÛdDOY]TU<�Q�ZW>�YEIAbFY]6=Q=<?Y]TUT`Z�ÙKS�68S:YE>HGFS:9�ÙCZ�Yd>aQ=<U[C<�Q�ZA>�BeBd689%<ÌFY]Q=<UBEIY]IO9AÜ�DFPRQ½ÙOS�>�BEÜ¯b%TUS�Q8S:9�ÙeZAYXb%6=BdbOS:6'GFYEIF9;TU<ÌFÚXB]Ø%ÙF6=BeYE9%>:YEPRQ=S:9W68S:ÛeD%StP�QHP�â:ômQ2Ü!DFPRQ'Q=GFS�68S�ØºBE68S�ÙKS�bKBdP8P=<`Ù%TUSEMØºBE6'Q=G%S�b%6=BdÚE6HY]Ü¯Ü¯S�6tMHQ=BXYdP=P=B;>�<?Y\Q8S2GOY]IF9;TUS�6HPjQ8B Q=Bdb%:P�âtïXP*Q=BEbF:P'Y]68S|I%BEQ�>�BdÜLbKBEIFS�IeQ8P�å¹Q=GFS�ZWY]68S|<`Ü¯b%TU�<�QI%BEQ=<UBEIFPAGF<U9%9%S�Iñ<UIñQ=G%S��eê]ú_úÁ>�BdIdQHY]<UI%S�6aèaM#×�S�b%68BEbKBdP=SLQ=BäS:Ü�ÙKB;9;ZùQ8G%S�Ü <UI¼Yä9;S:9%:Y\Q=St9÷>�BEÜ¯bKBEI%S:IeQQ=B�× G%<?>HG¼b%68BEÚE6HY]Ü¯Ü¯S�6HP�>:Y]IòYdP=P=B;>�<?Y\Q=SÃGFY]IF9%T`S:68P!Y]IF9ñ× GFS�68S�Q=GFS�Zñ>�YEIò>�BdI8�FÚEDF6=SÃ>�BEIF>�S�6=Q8Y]Q=<UBEI*â2þ�G%<UP>�BdÜ¯bOBdI%S�IeQ�<?P�DOPRSt9÷Q=BäÙF6=BeYE9%>:YEPRQ�6=St>�S�<U[ESt9÷6=StÛeD%S:PRQ8P�Q=Bä<`Q8P!6=S:ÚE<?P�Q8S�68S:9÷>�BdÜ¯bOBdI%S�IeQ8Påú£�DFPRQ¯T`<UöES+Q8BEb%<?>�P9;<?9Fè�Y]IF9ÃGFYEP�Q=GFSWYd9%9;<`Q=<UBEIFYETK>:Y]bFYEÙ%<UT`<`Q�Z 3C*�6B:-:�;A1!:-683C1Ð>C3C6B0R«26B;�«®6B0R«i1 p 4@1�.239<(*-026Bq�;A1�>C.�*-02>91!>Î<(06B0ªPR02<=÷vP21 ,$1!6B02<=02:-s�P2q^;�1!>C.�*-02>91 Q=6HY]IOPRÜ¯<`QRQ=St9�Q8B¯Q=G%S�P=S�68[C�S�>:Y]TUT`S:6:â

©¼&oû h M 0�3CER1!>C<=>52<`ÚdD%68S�´�P=ZCIeQ=G%StPR<Uÿ�StP�× GOY\Q�Y]68S�Q=G%S,>:Y]bFYEÙ%<UT`<`Q=<US:P|YEIF9!Q=G%S I%S:S:9%P:M]<UILQ=S�68Ü+P½B]ØjS�à%>�S:b;Q=<UBEILGFYEIF9;TU<Ì%ÚOM]B]ØKQ=GFSQ=GF6=S:S�>�Y]Q=S:ÚEBE68<US:P_BEØ�>�BdÜ¯bOBdI%S�IeQ8P�×�S�PRQ=DF9;<US:9Ã<ÌÃQ=G%<?P�bFY]bKS�6tâeômQ�ØºB;>�DOPRStP�BdI+Q=GFSXØºBdD%6�ÛeDFYET`<`Q=<US:P�b%68S:P=S�IeQ8S:9<UIõP=S:>aQ8<`BdIFPI�%âUìEMr�%â¦ê;Mr�%â �ùYEIF9O�Fâ ëOâ�ômQ�P=G%B\×,PAQ8GFY\Q+S�à%>�S�b;Q8<`BdI¼GFY]IO9;T`<UI%ÚÉ<ÌýN�@¼YEIF9¼ú >�BdÜLbKBEIFS�IeQ8P!<UPYE9%S:ÛeDFY\Q8S�YdP!Q=G%S�ú�û�@ø>:Y]bFYEÙ%<`TU<`Q=<US:PLÜ+Y\Q8>HGòQ=G%SfÛeDFYET`<`Q=<US:PLI%S:S:9;St9#â # I¼Q8G%Sf>�BEIeQ868YE6=ZdM*Q=GFSÇYEIFY]TUZ;PR<?P!B]ØS�à%>�S�b;Q8<`BdIfGFY]IF9%T`<UI%Ú+<UI�N�ï >�BdÜ¯bOBdI%S�IeQ8PXPRG%B\×,P Q=GFY]QX×�Bd6=öÃÜ�DFPRQXÙKS!9;BdI%SWQ=B�Ü+Y]Q8>HGfú�û�@f>�YEbFY]Ù%<UTU<�Q8<`StPY]IO9Ãb%68BEÚd68YEÜ¯ÜLS:68P�S�à;bKS:>�Q8Y\Q8<`BdIFP:â

CS components CA components E components

Quality Exist ? Needed ? Exist ? Needed ? Exist ? Needed ?Contextualisation respect yes yes no yes no no

Coordination support yes yes partial: transactions yes no no Exceptions concertation support no no no yes no noSupport for collective requests no no partial: forwarding yes partial: event dispatcher no

\^]`_Ba ćb½üBe njr:��u8{]��z��sOzv�A®d��r�¢�u8�AuH{\��x

ý Ù�Ñ�ÎXÔv�=Ó��CÕ�Ñ�Î��|ÎXÒþ HÓXÐ;ÏB��*ÐÉÿ÷Ñ_Ð��

ô�I¯Q=GF<UP�bFY]bKS�6tME×�SXPRQ=DF9%<`St9+Y�[�YE<`T?Y]ÙFT`S,>:Y\Q=S:ÚEBd6=<US:P½BEØ'>�BEÜ¯bKBEI%S:IeQ8P_YEIF9LQ=G%S:<`6�ú�û�@;P�â # I¯Q=GFS,BEI%SXGFY]IF9*ME×�SÙKS�TU<`S:[ESAQ8GFY\Q�Q�×�B�BdD;Q�BEØ½Q=G%68S�SL>�Y\Q8S�ÚdBE68<`StP�B]Ø�>�BdÜ¯bOBdI%S�IeQ8PXGFY�[ES�Yd9;S:ÛeDFY]Q=S�ú�û�@;P:â # IÇQ=G%S!B]Q=GFS�6XGOY]IF9#M×�S+G%<`ÚdG%TU<`ÚdGdQ8S:9÷T?YE>Hö;PW<UIñú�û�@;P!b%68B\[C<U9;St9ù× <`Q=G¼Q=G%S+Q8G%<U689ñ>�BEÜ¯bOBdI%S�IeQHP�>�Y]Q=S�ÚdBE68Zòå§>�BEÜ¯bKBEI%S:IdQHPA× G%<?>HG<UIdQ8S�6HYE>�Q�DOPR<UI%Ú+Y¯>�BEIeQ868Yd>aQRãmÙFYdPRSt9ÃP8>HG%S�Ü¯SAY]IF9�YEP=ZCIF>HG%68BEI%BdDFP�>�BEÜ¯Ü!D%I%<?>�Y\Q8<`BdIFPHèaâ

ô�I�bFY]6=Q=<?>�D%T?Y]6tM;×�S�Q8G%<UI%ö�Q8GFY\QXYEIú�û�@ÃØºBE6,P=DF>HGf>�BEÜ¯bKBEI%S:IeQ8P�Ü�DOP�Q GFY�[dS�Q8G%S:P=S�ØºBED%6,ÛeDFYET`<`Q=<US:P:Þ

J N�BdIdQ8S�àCQ=DOY]TU<`ÿtY\Q=<UBEIWÜ!DFP�Q*ÙKS�68S:P=bKS:>aQ8S:9�<UIABE6H9;S�6jQ8B,S�IFYEÙ%TUS|Q=G%S�× 6=<`Q=<UI%Ú B]Ø%>�BEIeQ=S�àeQ=ãmP=S�IOPR<`Q=<U[ES½GFYEIF9;TUS�6HPÙKS:>:Y]DFP=SÉYõPRS:6=[C<?>�SÉ9;S�Ü+Y]IO9;S�6�<UPQ8G%S�ÙKS:PRQÇS�IeQ=<`Q�Z�Q=BøGFY]IO9;T`S÷Y]IßS�à%>�S:b;Q=<UBEIßQ=GFY]Q�B;>�>�D%686=St9�<ÌÝY68S:ÛeD%StP�Q8S:9�PRS:6=[C<?>�SEâ


89

J N�BCBE6H9;<UIFY\Q8<`BdI�B]Ø2>�BEÜ¯bKBEI%S:IeQ8P�YE>aQ8<`[C<`Q=<US:P�Ü�DOP�Q�ÙOSWYE>HGF<`S:[ES:9�ÙeZ+S:IFY]ÙFT`<UI%Ú�Q8G%S�<U6�S�à;b%TU�<�Q�68S�b%68S:P=S�IeQ8Y]ãQ8<`BdIÇYEIF9ÙeZ9;Sc�FIF<Ì%Ú+Ü¯StY]IFP�Q8B�>�BEIeQ86=BdTOQ8G%S�<U6 S�à;St>�D;Q8<`BdI*â

J ç_68BEÚd68YEÜ¯ÜLS:68P*Ü�DFPRQ2ÙKS�Y]Ù%TUS�Q8B�>�BEI8�FÚdD%68S|Q=G%S�S�à;>�S�b;Q8<`BdI�b%68BEbFYEÚdY]Q=<UBEIWbOBdT`<?>�ZAÙCZA9;S��FI%<UI%Ú ��{~|��Aä[¦8�=}(��êN¦8��¡c��}(�A��| Q8Bñ<`Ü¯Ü¯S:9;<?Y\Q8S�TUZ¼GFYEIF9;TUSfS�à%>�S:b;Q=<UBEIFPLQ8GFY\Q�YE6=SÇ68S:Y]TUTUZ¼>�68<�Q8:Y]T�ØºBE6¯Q8G%SfS�à;St>�D;Q8<`BdIõ× G%<UTUSTUBEÚdÚE<UI%Ú�D%IF9%S�6=ãm>�6=<`Q=<?>�YETFS�à%>�S�b;Q8<`BdIFP_D%IeQ8<`TKQ=GFS�<U6�>�BEIA£�D%IO>aQ=<UBEIÃS�IFYEÙ%T`StP_Q8B!9;<?Y]ÚdI%BdP=S,Y�DFI%<UÛeD%S�b%68BEÙ%TUS�Ü68S�b%68S:P=S�IeQ8S:9�ÙCZ�Y ¡N��-¡N{c�~�À{N�T{�ë!¡�{À¤-��}(�A� â

J þ�G%SAú�û�@Ü�DFPRQ,Ü+Y]IFYEÚES�Ù%68BdYE9F>�YEPRQ=St9�68S:ÛeD%StP�QHP�<ÌfYLbOS:6RQ8<ÌFS�IeQ,×�Y�Zdâ

ô�Ifb%68S�[C<UBEDFP�×�BE68öjM;×�S�9;StPR<UÚEIFS:9fY]IO9<UÜ¯b%TUS�Ü¯S�IeQ=St9fY]IÇú�û�@Çb%68B\[e<?9;<UI%ÚLQ=G%StPRS�ÛeDFYET`<`Q=<US:P,ØºBE6XÖùï�@;P�åºQ=G%S@;Y�¶�úõú�û�@jéUì:ü\îºèaâ%þ�GFSWPRQ=DO9;Z�b%68S:P=S�IeQ=St9�<UIÃQ8G%<?P�bFY]bKS�6 <?P�BED%6½�F6HPRQ�PRQ=S:bÃQ8B\×�YE689%P�Q=GFSWYd9%Y]b%Q8Y\Q8<`BdIÃBEØ'Q=GFS9;StPR<UÚEI�Y]IF9Ã<`Ü¯b%TUS�Ü¯S�IeQHY\Q=<UBEI�B]Ø'Q=G%<?P�×�Bd6=ö¯<UIÃQ8G%SA>�BdIdQ8S�àCQ�B]Ø½N�æ�ç�P�× G%<?>HGÃ×�S�b%TUYEIÃQ8B!<UIeQ=S:ÚE6HY\Q=SXQ=BLQ=GFS� # IFï�@Ãb%T?Y\QRØºBd6=ÜÇâÕ® N*ÐB'Î�Ô�¼�

¬:�,�2�ds�s`�]r:Ü�a��2�\��®FÈ ��»|»|» � rt·]Ämu8q8�ª»2uH·O� r:��¿��Äªrt{C��x ��qH�E��uH{\��:wEr\q�� f�� {e~��\Æ¼nj� �\��As¹�l\�X�2�d��¡Ex��{]��r:x^Ò�uHsvs��r\qa��xH�_ÅKra»|��Rw¯u8ÂEqHuH®d��zvr:{¯�C��{Cwdsvzv{e¿�z�{EÜ�R��xm��eq8��E��uHx�Ür:��qHrt�A®;r:{euH{\��o§·C��x�uaw�x�r:Ü�¸»|��ut�|kª{

�� "!$#%�'& �(!)� � �*��!+�,��*�.-0/1� �32 #%��45��768��9:4;��(!,<)=��>�3�@?� ��!+AB� � �'CD�� EBF;G�!$#H& �%!)� � ��.<!+�,��.-I68�� *� ��J?� ��!+AB� � �:CD�� JK+&�6L?�CLM�EON'P.��!Q��EB��4;��%EIR�4 � �+-SF�T.<QF�U�EWV�X�X.Yt�O¬at:�E�

�]�X�2�d��zvxm��r:®e�euuÒ�rt{\¡\�'p*ÂEqHu8®d��zvrt{¯�e�:{ewdsvzv{e¿A��{Cw!r:·EÄªuHq8��o§r:��zvuH{\��uaw¯®E��rt¿��R�:�A�Azv{e¿�Èd��ra»|��Rwdx��xm¡E{\��euHx�zvxH�DR"6[Z?;&�\ �8] R_^`â��!+�,� ��Fl:�E¾m¬a�tÀ=È ��ltlcb]�:�t�E� � q8��r:·;u8�,¬a:t�E�"d0d � ? ] R`C:6Wd0d �fe X�G �� 3��;�X�;yLu=¡E��ra»_z¦��g¾¹uawEzv��r��=À=�

�E� f ��qa�\�euHx��eu8��·;u=�a� ] ��a�P��!)��9h��a91i;- !+�+<j�c��(!+�E�k�� ai��'�$�(!)�>-�- �l�� 1� � !+� m��>�,�>-�-l�"��! � �,=>i(n��=�½k¸{\��u8�Rp�wEz¦��z�r:{exH�¬a:��\�

�\� f r:�e{Ã��Oi�r\r]wdu8{ert�d¿t�F�,p*ÂEqHu8®d��zvrt{��C��{CwEs�zv{d¿dÈ%kªx�x��duHx ��{Cw��A®d��rt®;r:x�uaw�{er:�R��zvrt{O�o68��9�91i;�%�,��!+�,��%1� �1!$#(�R"6[Z��%¬a�E¾m¬�l:À=È �:�t��b]�t:�E��Ò�uHq8uH��·;u8� ¬H��:�]�

�]� f �d{�Ë�ut��y¯��z�~X�*Ë�zvsv��d{euH{F��yLrt�e�:{ù©��aÄ��¿trt®e�:s��:{F�|��{Cwä©�zvqR�C��RwUÒ��]q=�ds�zvqR�\��z�{d¿d�ùn#��r�¢Ez�wEz�{d¿Ç�\rtx�qH�exmo��rt�Azpga��zvrt{¯zv{+wEz�xm��zv·d�d��uawLr:·EÄªuHq8��xm¡Exm��uH�AxH�'kª{ �� 3��1� �a!$#(�:& qI& �Or R"6[Zs& �%!)� � ��!+�,��.-D68��c� � ��*� ��uta��! � �,=>i�!)�3�u?%P��!)��91 � -p��! �c� � 9�aK�ZJ�+��%-l��AB� � �0F�G�G�V�M�E ] �3�>!+i � ��â��!)��v68��9:4i�!)� � ?�>�Q��*� �:F�F;V�Yt�El:�:�E¬:�

�\� £��:svu8��zvu!k¸x�x��{\¡\��2rt{dqH�d��u8{]��u8ÂEqHuH®E��zvrt{f�C��{CwEs�zv{d¿d�Ãkª{ä~,�j©�rt��:{dr�¢Ex�Ê\¡\�K�� Ò�r:{]¡\� f �*h*�Lw {]�CwEx�uH{O�K�:{ew~X�\ÅO��zv®C��dz¹�duHwdz¦��r:��xH�R��k��*� ��0��hC8x�� )4!+�+��Hy'��%- ��Hz��3� #��(�,{>i(��dhO��|��¾ºhFuHq8��d��u��r��uHx½zv{¯�2r:�A®e�E��u8��Eq8z�u8{eqHu�À|l��l:l]�F�]®d��zv{e¿:u8��o§£�u8��s��¿d�Cl:�t�]¬t�

�]�Xy¯��Ê|w svuHzv{É�:{Cw��2�d��¡Ex��{]��drtx¹Ò�u8s�s��r\qa�:xH�¼p#ÂEqHuH®E��z�r:{��e�:{ewdsvzv{e¿�zv{��:¿:uH{\��xm¡dxm��u8�AxH��k¸{ � ��u8{Ép#��gHzvrt{dzº�f.} ��¿�nj�'yo~ds�svu8�a�'��{Cw f u>�;��u=¡ùy�'��R�twEx��C�H» �*uawEzv��r��xH� �D� �� 3��$��@�j��!$#(��z�#�� JR��%�(i%�.-:68��c�� J��R�i�!Q��*��9u��i�:RB��%!+uK�R"\BCB^�zO?<)X�X>Ma�e®C�:¿:uHx��l�b\�t�]�;��u8»��r:��Ê;�ey¯�H¡Ã¬ bE�!¬Htt]�%~��|y n*��u8x�xH�

]�Xy¯��Ê@w svuHzv{��:{Cw�2�d��¡Ex��{]��drtxuÒ�u8s�s��r\qa�:xH�A �x�zv{e¿¯wErt��z�{Eo§z�{ewduH®;u8{Cwdu8{]��u8ÂEqHuH®E��zvrt{��e�:{ewdsvzv{e¿�x�u8��¢]z�q8uHx ��ruH{e�:·esvuW��r:·e�exm�,r:®;uH{Ç��es¦��z¦oª��¿tuH{\� xm¡Exm��uH�AxHÈKÅ½�euAqH�:x�uAr:¨��¿tuH{\��wduH��O�J��i � �*��-�c� � R�i;!Q��*��9��i�1RB��%!+��ZJi;- !+�+<�RB��%!�?%P��!)��9��F�]¾m¬��:ltÀ=�%l��t�:�E�

¬a�]�,~X��©,��w�r\uH{ezv¿ä�:{ew÷��|�]��rt�dxm��e®F��p#ÂEqHuH®d��zvr:{÷�C��{Cwdsvzv{e¿ÇÜr:�¯�|� ��øk¸{ �� 6W�0��!�/1� �32;�68��c�� =�e®C��¿tuHx��l:l�b\�t�t�]�%��r�¢�uH��·;u8��¬Ht�t]�

¬t¬:�uÒ �a¢]z�w�ËX�%hOr��uH{(g��:{ewÃn#��uaw]�R�:¿!nju8��Ê�r�¢]z�q:�uÒ�uHx�zv¿t{Eoº��z��Au��:x�x�u8��·es¦¡+r�¨��d{\��z��Au,qHr:{\�R�:zv{e�AuH{\��qHrt�A®;r:{euH{\��xH�kª{!kª{dxm��zv��E��u r:¨'p*svuHq8��zvqa�:sj�:{CwLp'svuHq8��r:{ezvqHx�p'{d¿tzv{euHu=��xH�;uawdz¦��r��xH� �� 0!$#(��z��3� #��.-p��Po� �hdW=��3�>!,<d � �Q��(!)�3� ] ��i(�c��*�u?(P� !)��91�K zDd0d ] ?v�c� e G�G�Ma�;l:�t�:�E�

¬�l\�,��CyLu8¡\u8�a�'~�®e®dsv¡Ezv{e¿�} wduHx�zv¿t{L·]¡�qHr:{\��R�:q8�a}v�D&3CBC8C�68��9_4i�!)� � � � q8��rt·;u=�X¬Httl]�¬a�]�,�2u8��R��{CwLyLu8¡\u8�a�¼Ò�zvx�qHzv®esvzv{euHwLu8ÂEqHuH®E��z�r:{exH�'ÅKu8q=�d{ezvqa�:s%��uH®;r��o§uHz¦oªltl��u8Â%�dkª{\��u8�R��q8��zv¢�u,�Er�Ü�¸»|��uXp*{e¿:z�{duHu8��o

zv{e¿E�;i�r:s�u=�R�E�%�½~,�O¬Ht�:�E�¬H�E�Xy�%n#��z�{dr:oªy¯��zv{ducgt�;©,� f zv�AuH{ducg8o¸nju8��zvxH�%��{Cw��%�;~��uH¢:�:svrd��p#ÂEqHuH®E��z�r:{+Ë��{Cwdsvzv{e¿Azv{ÃÅO�R��{ex��:q=��z�r:{C��s � ·EÄªuHq8�

i��rt�d®exH�*k¸{JR��k��*� ��a��HCIx��)4(!+�,��@y'��%- ��E ] ^�6L?<,F;G�F�Ft�;®C��¿tuHx ¬a�t��be¬a�t�]�O�E®E��z�{d¿tu8�a�Cl:�:�E¬:�¬��\�,�2�\nju8x�q=�e�:{ex�Ê]z¹�F�2r:�Au8�aÈ\~É��u>�euHq8��zv¢�u|�Az�wewEsvu8»|��u��q=�dz¦��uHq8��d��u|Ür:�|�:we��®d��zv¢�u|qHr:�A®;rt{eu8{]��o§·e�:x�uawWwEzvxm��z�·d�d��uaw

xm¡Exm��uH�AxH�E�\��®OÈ �.��twdxH� qHr:�A®e�E��u8�a� r:��¿��wdx�r:{esvzv{eu��E¬a�t�.�a¨?ua��d��uHx ��®;uHx��E¬H��E� �\��¯�Kl:�t�]¬t�¬a�]�,~X��©�rt��{er�¢]x�Ê\¡\��cÒ�r:{]¡\� f ��h'��w {]�Cwdx�u8{O��{CwX~X� ÅO��zv®C��ez¹�%R��k��*� ��W��1CIx�� )4!+�,��ya��*�;- ��z��3� #��%�,{>i(��

hO��|�Ã¾ºhFuHq8��d��u��r:��u8x�zv{��2r:�A®e�E��u8��Eq8z�u8{eqHu�À_l��ltl\�F�E®E��zv{e¿tu=��o¸£'u8��s��:¿E�el:�t�]¬t�¬��\�,~�svu8Âd��{Cwdu=��©�rt��{er�¢]x�Ê\¡\�ep#ÂEqHuH®E��z�r:{A�C��{Cwdsvzv{e¿ zv{Wq8rt�A®;rt{duH{\��o§·C�:x�uHw�xm¡Exm��uH� wduH¢tuHsvrt®e�Au8{]�a�ekª{ �� 3��

� �WF�T�!$#�R��%�(i%�.-�& �(!)� � �*��!+�,��*�.-O68��9_4i�!)� � ?� ��!+AB� � �0��*�0RD4�4- �,��!+�,��%a68�� *� �1K�6WdBZ � ?;R"6 e G.V�Ma�]l:�:�E¬:�¬a�]�,~�svu8Âd��{Cwdu=��C©�rt��:{dr�¢Ex�Ê\¡!�:{ew f r��¿�w zvuH{%gHsvut�_~|q8��zvrt{Eo§r:��zvuH{\��uawLu8ÂEqHu8®d��zvrt{¯�e�:{ewdsvzv{e¿Azv{+qHr\rt®;u=�R��zv¢�uX�:{ew

qHr:�A®;u8��z¦��z�¢tu2qHr:{eqH�E��uH{\�#rt·]ÄmuHq=��o¸r��zvuH{\��uaw�xm¡Exm��uH�AxH�]k¸{uR��k��*� ��W��CIx�� )4!+�,��uya��*�;- ��uz��3� #��(�+{>i��:®C��¿tuHx¬H��be¬a�:�E�Fl:�:�t�]�

¬a]�,�2�]�]rt�dq=�drt{O�\��AÒ�r:{]¡\��\ ��R�twdrE�]�:{ewA�%��£2��d��zvu8�a�%~É®E��rt®;r:x�zv��zvr:{�Ür:�½u=Âdq8uH®d��zvrt{A�e�:{ewdsvzv{e¿ zv{A��dsv��z¦o¸�:¿:uH{\�xm¡Exm��uH�AxH�#k¸{v?;C ] ZoR0? e G��'4 � �� 3��Fl��t�:�E�


90

l:�]�X�E�d{ yLz�q=��rtxm¡Exm��uH�AxH� yLrt�e{\�R��z�{ £�zvu8» � �½�:svz¦¨ª� CD�%!)� � 4 � ��>� ��k��:�3��( K�CW��IM��\��®OÈ �.��Ä��a¢:�E� x��e{F� q8rt��®E��r]wd�dq8��x ��uªÄª·*�\�

l]¬:�X�E�d{ yLzvq8��rtxm¡Exm��uH�AxH�øyLrt�d{\�R�:zv{ £�zvu8» �ø�½�:svz¦¨ª� ��k��F � -p��! �>� � 91E`CD�%!)� � 4 � ��>��CW��!+�,��K)��F�CBCOMa��\��®OÈ �.��Ä��a¢:�E� x��e{F� q8rt��Ä�l�uHu:�

ltl\�X�E�d{ yLzvq8��rtxm¡Exm��uH�AxH�ÝyLrt�d{\�R�:zv{ £�zvu8» �Ý�½�:svz¦¨ª� ��k��F � -p��! �c� � 9�E�?%!Q��*�� CW��!+�+��KQ��F�?;COMa��\��®OÈ �.��Ä��a¢:�E� x��e{F� q8rt��Ä�lt�]ut�

l:�]�X�E�d{yLz�q=��rtxm¡Exm��uH�AxH�KyLrt�d{]�R��zv{�£�zvu8» �K�½��s�z¦¨¸�@��k��?� ��!_��k��:�3��%"R � &1?.4%�3�>� mB��!+�,��d��¬:� �]¬AuawEzv��zvr:{O� f �es¦¡¬a:��\�2�\��®OÈ ��Ä��a¢:�:x�r�¨U�a� qHrt��·;ua�:{dx �:wEr\qHx ��x�®;uHq:� �\��¯�

l��E�X�2svuH�AuH{dxA�;g=¡d®;u=��x�ÊEz¹��68��9:4;��*��(!'?*�j��!+AB� � ��W�_��P��d�=��3�>!,<�d � �,��(!)�3� �D� �� 919��:�ä~��|y n*��u8x�xA�:{ew~_wewEz�x�r:{doºÆÇu8x�s�u=¡\�]��u8»��r:��Ê;�E�_��%¬Htt�]�

lt�\�,~�{e�:{ew�ÅO��zv®C��eze�:{CwW©�rt·;u=��½yLzvsvsvu8�a�Fp#Âdq8uH®d��zvrt{A�e�:{ewdsvzv{e¿ zv{A�:¿:uH{\�2r��zvuH{\��uawWxm¡Exm��uH�AxH�Ck¸{A~X�t©�r:��:{er�¢]x�Ê\¡\��Ò�r:{]¡\� f �Eh'��w {E�ewdx�uH{F�\��{Cw�~X�]ÅF��z�®e��dzº�]uHwdz¦��r:��xH�(R��k��*� ��_��CIx�� )4!+�,��ya��%- ��oz��3� #��(�,{>i(��dhO��|�¾ºhOu8q8��d��u��r:��uHx_zv{+�2r:�A®e�E��u8��EqHzvuH{dqHu�À_l:�tltl\�%�E®E��zv{e¿tu=��o¸£'u8��s��:¿E�;l��t�:�E�

l:�]� ��Æf��{e¿E��Ò��\�EqR�e�Az�wE�a��wW�\n#��R�:�AuHxm»½��R��{O�]��{CwAy��w z¦��qR�eu8�a�;ÅKra»|��RwEx2��u��CuHq8��zv¢�u_�Az�wewEsvu8»|��u_¨`�R�:�Au8»2r:��Ê¨?r��]r:xmo§uH{C��·esvuawLqHr��·C�WqHr:�A®;rt{duH{\�_�Ar]wduHsF�:®d®esvzvqa��zvr:{exH�;zvuHuHuXwEz�xm��zv·d�d��uaw�xm¡dxm��u8�Ax|rt{esvzv{eu,x�®;uHq8z`��sKzvx�x��eu,r:{��u>�euHq8��zv¢�u��Az�wewEsvu8»|��ut�;l��t�]¬t�

lt�\�uÒ ��{ezvuHs;h*��ÆÇuHzv{E��uH·O�F�]zv¿t{C��svs�zv{d¿��{CwA�C��{Cwdsvzv{e¿ q8rt{CwEz¦��z�r:{exH�KÅKuHqR�e{dz�qH�:se��uH®;r��a�E�]¡E��·;rtsvzvqHxH��k¸{eqt�v�E�½��·d��z�wE¿tut�y¯~X� f ��{]�C��¡Ã¬a:�t�]�


91

Exception Handling in Object Oriented Systems: Towards...

Documents

Transcript of Exception Handling in Object Oriented Systems: Towards...