Exception Handling in Component – Based Software Systems
TERM PAPER
(CSC 532:Adv. Topics in Software Engineering; Fall – 2003)
- By Rahul Goutham Gundala.
LouisianaTechUniversity
Table of Contents
ABSTRACT
Exception Handling:
The Frame Work of Exception Handling:
1.Local Exception Handling and Error detection:
2. Structuring of Atomic Actions into an Integrated system:
3. Action Oriented Structuring and Exception Handling:
Proposed Practical Implementation:
Conclusion:
REFERENCES
ABSTRACT
Component – Based SoftwareEngineering is attracting substantial interestin today’s software engineering community. Plenty ofresearch efforts have been made towards the analysis anddesign methods for component-based software. But,only a few research prospects address the runtimeand maintenance problems of component-basedsoftware. This paper focuses on the causes and problems due to theexceptions generated by the componentbased software development methodology. It also tries to give an account of some strategies to overcome these problems.
Themajor concentration here is on the fact that component-based softwaredevelopment introduces additional sources of riskbecause,
(i)Independently developed componentscannot be fully trusted to perform to their publishedspecifications.
(ii)Very often, software failures aredueto the unintelligible patterns of interaction that cannotbe localized to any individual component.
Here a framework is proposed which is strives to solve the problem in 3 steps.
Step1: Individual components are combined in such a way that the wrappers perform activity related to localerror detection and exception handling, and signal, if necessary, external exceptions outside the component.
Step2: The execution of the overall system is configured as a set of dynamic actions in whichcomponents take part. Such actions have important properties which facilitate exception handling like: they areatomic, contain erroneous information so serve as recovery regions; and actions can be nested so that we can develop recursive systems.
Step3: It is designing the action levelexception handling i.e.each action (including all components participating in it) handles exceptions signaled by the individual wrappedcomponents.
Keywords: Exception, Interface Exceptions, Wrappers, Atomic actions, Recovery.
Exception Handling:
Exception: An exception is an unusual event which usually occurs at runtime. All exceptions are not necessarily erroneous but exceptions are detectableeither by hardware or software and may require specialprocessing.
Exception Handling: Exception handling is a structuring mechanism that allows theseparation of normal behavior from abnormal behavior in the software system.
Exception handling separates the code for normal executionfrom the code for exception handling. It separates normal flowof control from the exception flow of control. In reality,components have sophisticated means of handling exceptionsthat are propagated across the external interface boundary ofthe component. Any component using other componentsmust therefore be aware of these exceptions and be capableof handling them when they appear.
The important feature of any exception handling mechanism is its ability to differentiate between internalexceptions to be handled inside the context and the external exceptions which are propagated outside thecontext.These exceptions are not clearly separated in many languages as many languages treat the program as an exception context. It is obvious that they areintended for different purposes.
This separation can be done provided the following conditions are met:contexts are associated with program units which have interfaces and the concept of context nesting isdefined. Several models clearly separate these two types of exceptions; e.g. Java, Modula-3, CoordinatedAtomic (CA) actions.
Interface Exceptions: In the component-based software development (CBSD) interface exceptions are an important part ofthe component interfaces, which are used by component providers/developers to inform the environment (i.e. platform)that uses the component about situations in which the component cannot provide the required service. Thesignaled exception can be accompanied by some information about the reasons for it and about the state inwhich the component has been left to allow the environment to take appropriate actions.
As already discussed many programming languages consider a program unit as a context so their exception handling mechanism uses dynamic exception context nesting i.e. the execution of context can be considered as completed just by passing an interface exception. Here it is considered as an internal exception raised inside a context.
Ex: Nested procedure calls, Client-Server RPC’s.
External Exceptions: External exceptions allow developers to pass differentoutcomes to the containing contextin a disciplined, unified and structured fashion. So this can be used to extract the information of the reasons for abnormalbehavior and of the state in which the context has been left, to pass partial results, etc. The state in which the context is leftwhen an external exception is propagated is another importantissue which exception handling models have to address.
Exception handling is an important part of any general structuring technique used in system design because it adds new ways of concern separation which are vital for dealing with abnormal situations. It allows us to separate normal code from exception handlers during system design and structuring, introduces a dynamic separation of the execution of normal code and handlers, and provides two ways of returning the control flow after the execution of a component.
The Frame Work of Exception Handling:
As explained above the framework is a three step process.
- The local exceptions and errors are detected and wrapped up with individual components in such a way that they perform their functions locally.
- The whole system is structured as a combination of actions in which components take parts.
- Here the local exception handling schemas are combined with the Atomic level actions so that a whole integrated system is achieved.
1.Local Exception Handling and Error detection:
In Local error detection and exception handling phase, the following needs, are performed at the level of the standard component interface, they are:
- Disciplined exception handling.
- Enhanced application – specific error detection.
- Additional exceptional handling local to each component.
These are all "local" as they are developed for eachcomponent and do not involve other components. Although we call them "local" we consider it to be a higherlevel context than the internal context of the component, within which the component developers mighthandle or might try to handle exceptions before returning information through the component interface. But here in this paper we propose a model which looks as like the following figure:
Fig.1
Here we can observe a special "higher" (wrapper) level, which hides the component. This is awell knownObject oriented structuring mechanism and a number of implementation techniques have been developed tosupport it. In this context wrappers perform local error detection and exception handling.
Local Error Detection:
The wrappers collect errors by performing component error detection i.e. by catching all exceptions and errorreturn codes, and by checking predicates. These predicates describe the correct or expected behavior ofthe component and are made executable. Theyare to be developed in the course of wrapperdevelopment as an important part of system integration. They include known restrictions on the way the component isused in the integrated system.
Ex:In an Internet travel agency system using an existingflight reservation service we might decide not to use APEX flight tickets at all as these cannot be cancelled.
The wrapper prevents the component from misuse by checking that calls and input parameters arecorrect; some parts of the interface are not used (application specific); non-standard parts of the interfaceare not used; and by intercepting calls which can cause known component faults (based on injection,testing, bug reports). On the output the wrapper checks correctness of outputs and, if possible, makes surethat the component is in a known correct state.
Wrapper development is acomplex engineering process which has to be supported by rigorous techniques and by a clear descriptionof the engineering steps to be undertaken. Ad hoc development is not acceptable here. Wrapper designincorporates the system integrator's view on what the component can do, should do and should not do in theintegrated system. This development uses existing (but often incomplete and unreliable) knowledge of thecomponent functionality and the application-specific knowledge about the context in which the component
is to be incorporated (e.g. restrictions on the use depending on the application profiles).
System integrators design contracts between the environment and the component in the form of predicates on component inputs and outputs, and, possibly, on the component state (when it is assessable through the standardinterface) used for detecting latent errors. These predicates are incorporated into the component wrapper in the form of executable assertions.
Local Exception Handling:
Local exception handling begins when either an exception is raised by a component (or, an error return code)or an assertion detects a violation of the specified component or environment behavior. This handling caninclude another attempt to provide the required service, search for more information about the exceptionsand the reasons for it, checks of the state in which the component has been left, its recovery or operationsputting it into a correct known state. The wrapped component should have a set of interface exceptionswhich it can signal in such a way that it can give guarantees (or, attempts to give them) that the componentis left in a state which corresponds to the exception being signaled.
It is vitalto always leave the component in a known consistent state but experience shows that this is not always thecase. It is the responsibility of the wrapper to check that this has been done properly and, if it has not,to execute appropriate operations. Guaranteeing "nothing" semantics is the most useful approach, a numberof the interface exceptions can have such semantics (e.g. Resource_Cannot_Be_Used orIlligal_File_Format). It is important to introduce, a special failure interface exception to use it whenthe state is which the component has been left is unknown and to advice the system not to employ itwithout appropriate recovery.
Key Features:
- incorporate damage assessment (e.g. by calling component methods and analyzing information aboutthe detected error).
- try to handle an exception locally through the standard interface of the component. Including,recovering the component, retrying the operation, moving the component into a known and consistentstate (e.g. using standard abort, initialize interface operations).
- signal an exception to the environment without executing the requested component function (if therequest is erroneous).
- signal all exceptions in a unified way augmenting the exceptional outcomes with additionalinformation (e.g. component name, function name, name of the illegal parameter, etc.).
Before concluding the section I would like to emphasize that errors should ideally be detected at the level of components by the wrappers and when they are detected anattempt should be made to handle them locally.
2.Structuring of Atomic Actions into an Integrated system:
Atomic actions form the sound basis of integrated systems mainlybecause they offer a recursive approach to building complex systems and for incorporating exceptionhandling into them. Several participants (threads, objects, etc.) enter such an action and cooperate inside itto achieve joint goals (Figure 2). Its participants share work and explicitly exchange information in order tocomplete the action successfully. Actions are structuring units hiding intermediate steps of state andbehavior changes.
- Atomic actions structure dynamic system behavior.
- Noinformation is allowed to cross the action border.
- Actions can be nested (a subset of the participants of thecontaining action can join a nested action).
Participants leave the action together when all of them havecompleted their job. If an error occurs inside an action all participants take part in a cooperativerecovery because the action is the damage area. The main reason behind this is processes have exchangedpotentially erroneous information while performing a joint activity.
Atomic actions provide a frameworkfor developing schemes intended for tolerating faults of different types: hardware faults, software designfaults, transient faults, environmental faults, etc. Thegeneral exception handling model can easily be applied here to allow internal exceptions and correspondinghandlers to be associated with such structuring unit. Atomic actions have interfacesenriched by externalexceptions which the unit can propagate into the containing exception context (i.e. into the containingstructuring unit). Atomicity of actions (i.e. of exception contexts) is vital for dealing with abnormal events (i.e. exceptions) as it guarantees the containment of all (potentially erroneous) information whichshould be involved in exception handling and recovery.
Fig 2.
Clearly, the atomicity of action execution has ageneral importance for all phases of system development: it facilitates reasoning about the system,
system understanding, verification and development, tolerating faults of different types, etc.
Atomic actions is a general approach applicable for different software architectures and applicationareas. First of all, because we employlocal handling at the level of individual components, in our framework if a local handling does not succeedan exception is propagated to the level of an action in which this component is involved to be handledcooperatively. When action level handling is not possible an exception is propagated to the containingaction.
3. Action Oriented Structuring and Exception Handling:
As emphasized before the integrated systems should be structured in such a way that the units ofstructuring are the exception contexts. Here the proposal is to develop such units as atomic actions. Severalwrapped components are dynamically involved in the execution of the same action (Figure 3). These
actions form the dynamic structure of the integrated system as they can be recursively nested. For thesystem level fault tolerance it is important that such actions form the recovery areas and that all participantsare involved in cooperative exception handling when any wrapped component signals an exception.
Fig 3.
In real systems there are situations when complex error detection should be used to allow theintegrators to check complex conditions which involve the states of a number of interrelated components.In our framework this type of error detection is applied within an atomic action. When an error is detectedall participants are involved in the action level exception handling as the local exception handling cannotresolve the problem. Action level handling can include compensation for (unnecessary) updates committedby individual components or, even, for mistakenly taken actions at the component level.
Action level recovery suits well to recovering component systems because the component results areusually committed and it is not always possible to abort them, so there is a need in using system levelcompensation.The approach proposed is recursive and when the action participants are not able to handle anexception they pass the responsibility for recovery to the higher system level. Handling at this levelinvolves all components participating in the containing action. If several exceptions have been raised in anaction they all have to be taken into account so that all action participants are involved in handling aresolved exception.
To apply the framework proposed system integrators should design cooperative component activities usingnested atomic actions, describe how each individual component is involved in such activities, and developcooperative exception handing for all participants of each actions.
Proposed Practical Implementation:
It is clearly understood what is the importance of implementing a support for the framework. The challengehere is to develop these functionalities for existing component technologies. Here focus is put ondeveloping features supported by the framework proposed in CORBA. They rely on introducing wrappersusing legal ways of call interception and on adding new services which allow components to take part inatomic actions and, in particular, in a cooperative exception handling.
Local error detection and handling are implemented as component wrappers. There are manywrapping techniques. Component technologies use the ideas of wrappers to transparently insert calls toservices. These are termed interceptors in CORBA and DCOM+, and proxies in CORBA3 and EnterpriseJavaBeans. The CORBA2 specification allows for interceptor services that can be inserted into the normalinvocation path for CORBA objects. The interceptor service is registered with the ORB that then ensuresthat when the client sends a request to an object the request is passed through the interceptor service and onreturn the result also passes through it. CORBA3 generates proxies that stand in place of the targetcomponent and allow interception of method invocations sent to the component.
In implementing a newservice for controlling actions and for cooperative exception handling within the standard componentenvironment we rely on previous experience in designing similar services for distributed Ada and Javasettings. To do this we introduce an action coordinator object, one for each action, that keepsreferences to (or is referenced by) all action participants, as well as, to all active nested actions. New APIwill have to be provided to include operations of action entry and exit, as well as, exception raising to allowthe coordinator to involve all action participants into handling. The activity of the individual componentswithin the integrated system (including their participation in actions and cooperative exception handling) is
described by system integrators and implemented using these services (Figure 4).
Fig 4.
Conclusion:
The ideas presented in this paper can be given the following touch up to get to the conclusion. This Paper:
- Describes about a framework for embedding structured exception handling into component-based systemdevelopment that relies on two level exception handling: the component level and the integratedsystem level.
- Highlights local error detection as a part of the framework and discusses the specific sources oferrors to help in developing software to perform this functionality.
- Proposes an idea of developing local error detection and local exception handling using the existing wrappertechniques.