A Framework for Exception Handling in Web-based. Applications ... applications assume a mission-critical role within the enterprise and they cannot be .... browser; thus reaching the page of the Loan Search activity, and may try to navi- ..... tion, or the user denoted by the “Managed By” connection as the responsible to han-.
A Framework for Exception Handling in Web-based Applications Marco Brambilla, Sara Comai, and Christina Tziviskou Politecnico di Milano, Dipartimento di Elettronica e Informazione, Via Ponzio 34/5, 20133 Milano, Italy {mbrambil, comai, tzivisko}@elet.polimi.it
Abstract. In the context of B2B and intranet applications, the development paradigm is moving towards more complex applications, typically based on workflow specifications for implementing business processes. Since applications are becoming more and more business-critical, the problem of granting safety and robustness arises. In the Web context, this issue is particularly critical and not investigated in its peculiar aspects, such as loose control of Web applications upon the behavior of their Web clients, typically leading to incoherent user’s behavior. This paper presents a high level approach to the management of exceptions that occur during the execution of processes on the Web. We present a classification of exceptions that can be raised inside workflowdriven Web applications, and a set of three models for managing exceptions: capturing model, notifying model, and handling model. These models rely on a simple conceptual representation of the Web application and on a metadata model for keeping track of the status of the system. The paper provides also a detailed comparison of our approach to exception handling mechanisms of well-established standards for workflow, Web services choreography and Web applications.
1 Introduction In recent years, the Web is more and more being used as the implementation platform for B2B applications, aiming at supporting business processes, content management, document approval flows, value-added services, and so on. This leads to the integration of several technologies, which go far beyond the simple implementation of Web interfaces for content publishing to the users. This is confirmed by current efforts towards the modeling of this specific type of applications [3]. In this context, Web applications assume a mission-critical role within the enterprise and they cannot be considered as mere content-browsing interfaces any more. Therefore, the need arises of solid approaches to users’ behavior modeling, to fault management, and to exception handling. Contributions from software engineering and other fields can partially address these issues, although the Web context introduces new and original problems, due to the powerful interaction options provided by browser-based interfaces, which are more oriented to free navigation than to strict processes adherence (e.g., users are enabled to jump back and forth on navigated pages). This means that users cannot be
forced to perform any action or task, since Web architectures are meant to provide loosely coupled interactions between peers. In this paper, we offer an approach to exception handling in this context. We identify the exceptions that may arise in Web applications, we classify them along various dimensions (e.g., type, scope, detection time), and we provide a framework for exception handling based on the proposed classification. Our approach is based on a metadata model that describes the process enacted by the Web application and its status. A set of three models is built upon it: capturing model (describing the mechanisms for capturing the exceptions), notifying model (describing the options available for notifying the user about an exception occurrence), and handling model (describing compensation actions that may be taken). Finally, we compare our framework with existing exception handling mechanisms in standards like BPMN[1], BPEL4WS[2], and XPDL[14]. Many works have addressed the problem of exception discovery and compensation. They mainly studied transactional properties for activities, which is not in our scope. However, some works deal with weaker properties. For example, [8] is based on the concept of spheres, to make use of only those transactional properties that are actually needed; [9] is one of the first works that addresses the problem in the Web context, but it provides only a classification of exceptions. For the definition of the scope and the expressive power of workflow primitives, our work is inspired by pattern based workflow analysis by Van Der Aalst [10], and by industrial and academic standards like BPML /BPMN [1] and YAWL [11]. Other works on activity composition and coordination related to the Web have been considered; for example, [6] and others propose solutions on Web services interaction, for which we will propose some exception handling techniques. Our previous work [5] has focused on studying the basic issues of the problem, with a specific focus on a Web application modeling language called WebML[7], while now we offer a more general approach, that can be applied on any underlying technology or design method. The paper is structured as follows: in Section 2 we introduce the main characteristics of the exceptions occurring in typical Web applications. Section 3 describes our approach for representing, capturing, notifying and handling the exceptions. Section 4 compares our approach with existing standards, while in Section 5 we draw the conclusions.
2 Exceptions in workflow-driven Web applications The management and recovery of exceptions in a workflow-based Web application requires identifying the typical failures in this context. After introducing a case study and a hypertext model that will be used throughout the paper, in this section we provide a characterization of the exceptions that may arise in a Web application. In particular, we will present the possible exceptions by example and classify them according to different dimensions.
2.1 The Case Study
Employee
Manager
Customer
In the sequel, we will exemplify the proposed approach on a case study consisting of a Web application implementing a business process. For specifying business processes, we use the Workflow Management Coalition terminology [13] and the BPML/BPMN [1] notation. The workflow model is hence based on the concepts of Process (the description of the business process), Case (a process instance), Activity (the elementary unit of work composing a process), Activity instance (an instantiation of an activity within a case), Actor (a user role intervening in the process), Event (some punctual situation that happens in a case) and Constraint (logical precedence among activities and rules enabling activities execution). Processes can be internally structured using a variety of constructs: sequences of activities, gateways implementing AND, OR, XOR splits, respectively realizing splits into independent, alternative and exclusive threads; gateways implementing joins, a convergence point of more activities; activity iterations; and pre- and post-conditions of activities. The workflow depicted in Fig. 1 describes a loan brokering Web application, providing users with the possibility to search for available loan options, fill loan applications, and be notified of their acceptance/rejection by the loan provider. The desired Web application should cover the whole process, by allowing the broker agent to evaluate the loan request, by giving a preliminary validation, and then checking the details of loan applications (such as the applicants’ financial status and job history), and finally registering their final decision on approving or rejecting a given application. If the request is approved, the customer can accept it and proceed with the loan cashing and periodic installment payments.
Loan Search
Loan Request
Loan Acceptance
Preliminary Validation
Final Approval
+
+
Financial Check
Job Check
Fig. 1. Workflow modeling of the “Loan Request” process
The case study is a simplified process executed through the Web by three actors: customer, brokering manager, and company employee. However, exceptional situations may happen during the normal execution of the process and lead the system to an uncertain state. Possible exceptions will be presented in details in the next sections.
2.2 Hypertext Modeling The structure of a Web application based on such a process may be described by an hypertext model extended with the activities and the constraints that drive the navigation of users, as it has been proposed, for example, in [4]. To study in a simple and effective way the exception handling, we introduce a simple hypertext model describing the structure of activities performed by a user. An activity is represented as a piece of hypertext made of pages, links between pages, and, possibly, side effects on the links. Pages are univocally identified within an activity. Side effects can be chains of operations (depicted as small circles), executed at server-side, thus not interesting for Web exceptions analysis and will be omitted in further representation of process hypertexts. Between two subsequent pages, there can be a Web Service call whose unsuccessful execution can raise critical situations. In this case, the hypertext model is extended considering the Web Service interaction as a page within the activity. As shown in Fig. 2, the Loan Search activity is composed of two steps: a hypertext page, allowing the user to insert his search criteria for a loan, and a Web Service call to a service which is outside of the bank offering the loans; the Loan Request activity is modeled with three different pages, allowing the user to look at the results, see the details of a specific loan, submit a request for that type of loan, and receive a confirmation. Loan Search Activity Home page
Search Criteria
First Page
WS
Loan Request Activity Available Loans
Second Page First Page
Loan Details
Second Page
Loan Ack
Some page
Third Page
Fig. 2. Process hypertext modeling presenting server side operations and pages numbering
2.3 Exceptions in Web-based Applications In order to handle exceptions, we try to clarify the conditions under which failures occur. We present, by example, the different kinds of exceptions that may occur, and provide a classification of such exceptions, that have been used for defining the capturing mechanisms, the user notification patterns and the handling policies in our framework. 2.3.1 Examples of Events Generating Exceptions in Web Applications Exceptions in process-centric Web applications may be caused be events generated from external sources (e.g., an incoming message of a Web service invocation), from data inconsistencies in shared data sources, or may be generated within the process
execution from inconsistent user navigation, or from server and client infrastructure failures. In our framework, we consider all such types of events to define the exceptions that can be handled by the system. Possible events that are not part of the normal flow of the Loan Request process Fig. 1, and the corresponding resulting exceptions are presented in the following scenarios: • Within the Loan Request activity, the user may press the back button of the browser, thus reaching another page within the same activity, and may try to navigate a link repeating part of the Request or restart its execution (see Fig. 3). This user navigation leads to a Wrong Starting Page exception. Loan Search Activity Home page
Search Criteria
WS
Loan Request Activity Available Loans
Loan Details
Cached Page
Loan Ack
Some page
Last Requested Page
Fig. 3. User navigation that generates the Wrong Starting Page exception
•
Once the Loan Request activity is completed, the user navigating some page outside the process hypertext, may press the back button of the browser, thus reaching a page of the activity, and may try to navigate a link repeating part of the Request or restart its execution (see Fig. 4). This navigation leads to an Action By Completed Activity exception. Loan Search Activity Home page
Search Criteria
WS
Loan Request Activity Available Loans
Loan Details
Loan Ack
Cached Page
Some page
Last Requested Page
Fig. 4. User navigation that generates the Action By Completed Activity exception
•
Within the Loan Request activity, the user may press the back button of the browser; thus reaching the page of the Loan Search activity, and may try to navigate a link repeating part of the Search (see Fig. 5). This navigation occurring between two activities of the process and exiting an active activity raises an Activity Already Active exception, since an activity in progress is exited. Loan Search Activity Home page
Search Criteria
Cached Page
WS
Loan Request Activity Available Loans
Loan Details
Loan Ack
Last Requested Page
Some page
Fig. 5. User navigation that generates the Activity Already Active exception
• • •
•
•
A notification for the discount rate variation of a country may require changes in the loan conditions of requests fulfilled with the corresponding installment plans. In such a case, a Discount Rate Variation exception is raised. Anytime during the process execution, the user may ask the cancellation of the loan request. A Cancel exception is raised. In the Loan Search activity, when the Web Service is called to get the loans satisfying the criteria specified by the user, the loan amount may exceed the limits for which the loan can be approved. In such a case, a failure response is received from the Web service and an Invalid Loan Amount exception is raised. Anytime during the process execution, a modification of the expiration date of an installment plan may require that all the customers whose requested loans fulfilled the corresponding installment plan should revisit their loan options. In such a case, an Expiration Date Modification exception is raised. Within one of the activities, the user may stand on a page for a long time after which a timeout may occur (see Fig. 6); thus, the user session ends generating a Session End exception. Loan Search Activity Home page
Search Criteria
WS
Loan Request Activity Available Loans
Loan Details
Loan Ack
Some page
Last Requested Page
Fig. 6. User navigation that generates the Session End exception
•
•
Within the Loan Request activity, the user may press the back button of the browser, thus reaching a page outside the process, possibly belonging to another application. This case can be treated like the case shown in Fig. 6 as a Session end exception. Within the Loan Request activity, the user may not be able to send his acknowledgement on the selected loan because of network unavailability. Therefore, a timeout occurs, generating a Session End exception.
2.3.2 Classification of the exceptions according to their Type Exception handling may differ according to the characteristics of the exceptions introduced in the previous sections. At this aim, we classify the exceptions into three main categories: 1. Behavioral (or user-generated) exceptions are driven by the improper execution order of process activities. The free user navigation through Web pages results in the client visiting older pages, trying to explore the hypertext of activities that have already been executed. The Wrong Starting Page, the Action By Completed Activity and the Activity Already Active exceptions belong to such category,
2.
3.
Semantic (or application) exceptions are driven by the unsuccessful logical outcome of activities execution. For example, the Discount Rate Variation, the Cancel, the Invalid Loan Amount and the Expiration Date Modification exceptions are semantic exceptions. System exceptions are caused by the malfunctioning of the workflow-based Web application infrastructure both at server and at client side. Events that result in such exceptions are network failures and system breakdowns. In the current work, we do not consider server-side failures, since proposals for such an exception context already exist for traditional data-storage and workflow technology. Client-side exceptions are caused either by data storage and client breakdowns, browser crashes, and network unavailability or by elapsed time between user interactions within a process (like in the last scenarios presented in the previous subsection). A client-side failure results either in the client not sending a request to the server, or in the server not responding to the client. Client-side failures are indistinguishable at application level and are recognized as Session End exceptions.
2.3.3 Classification of the exceptions according to their detection time Another important characterization of the exceptions in process-centric Web applications is related to the detection time: exception may occur while the users involved in the process are navigating through the activities of the workflow, or while they are visiting pages not belonging to the workflow, or, possibly, when they are disconnected. Exceptions can be therefore classified as synchronous or asynchronous as follows: 1. Synchronous exceptions occur within an activity of the process, when a page representing the interface for that activity is requested to the server, or more in general, when the user clicks on a link within an activity. In this case, the user session is on, and therefore the exception can be immediately handled. 2. Asynchronous exceptions occur at any time during the process execution, independently of the state of activities in the case. In this case, the user session may be still on (and thus the user may be warned) or may be off (and the exception handling may be deferred). According to these definitions, behavioral exceptions are always synchronous, because they occur during the navigation of an activity; semantic exceptions may be either synchronous or asynchronous; system exceptions may occur any time during the process execution (for example, when the user disconnects) and are therefore asynchronous. 2.3.4 Classification of the exceptions according to their Scope The scope identifies the part of the workflow that is affected by an exception occurrence. The ability to specify exceptional situations in individual or group of activities / cases within a process provides us with information about the exception context that will drive the exception handling. Upon a faulted condition, the recognized exception is caught at the following scope levels:
•
•
• •
Activity scope: it refers to a specific activity instance. For example, the Wrong starting Page, Action By Completed Activity and Session End exceptions are raised for the appropriate instance of the Loan Request activity, and the Invalid Loan Amount exception occurs for the current instance of the Loan Search activity. Activities scope: it encloses a group of activities instances. For example, an Expiration Date Modification exception occurs for every instance of the Loan Acceptance activities of the cases in which the loan proposals have been fulfilled on the basis of the corresponding installment plan. Case scope: it refers to a specific case. For example, the Cancel exception is raised for the case of the Loan Request process to be cancelled. Cases scope: it encloses a group of cases. For example, a Discount Rate Variation exception occurs for every case of the Loan Request process in which the proposals have been fulfilled on the basis of the installment plans affected by such a variation.
Table 1 summarizes the characteristics of the exceptions of the Loan Request Process according to the three classifications. Table 1. Classsification of the Loan Request Process exceptions Exception Wrong Starting Page Action By Completed Activity Activity Already Active Discount Rate Variation Cancel Invalid Loan Amount Expiration Date Modification Session End
Type Behavioral Behavioral Behavioral Semantic Semantic Semantic Semantic System
Detection Time Synchronous Synchronous Synchronous Asynchronous Asynchronous Synchronous Asynchronous Asynchronous
Scope Activity Activity Activities Cases Case Activity Activities Activity
3 A Framework for Exception Handling In order to handle all the exceptions classified in the previous sections we propose a framework based on three models built upon a metadata model, which interact as described in Fig. 7: 1) the workflow meta-data model, is used to store and retrieve state information about workflows and exceptions; it resides locally at the application premises; 2) the capturing model, is used to capture the events generating the exceptions in the exceptions data model; such events may be triggered by remote services or by internal data (or metadata) values; 3) the notifying model, is in charge of notifying the occurred exceptions to the user inside the hypertext model; 4) the handling model, used to resolve the exceptions, by applying a recovery policy, which typically impacts on the data model itself. As we will see, the metadata to be stored and the mechanisms for capturing, notifying and handling the exceptions depend on the different categories of exceptions.
Web client
Exception management models
Remote services
Capturing model
Notifying model
Process & exception metadata + application information
Handling model
Process Metadata
User Metadata
Group
Name 0 ... : 1 N : N User
0 : N
0 : N
0 : N
1 : 1
0 : 1 N : 1
Username Password FirstName LastName Email
1 : 1
ActivityType
Name 0 Description : Instan N ceOf 1 : 1 Activity Instance
1 : 1
1 : N
1 : 1
1 : N
Process
Name 0 : N1 : 1 Case
Status StartTimeStamp EndTimeStamp 0 : 1
Instan ceOf
Status Name StartTimeStamp EndTimeStamp
Fig. 7. Representation of exception management models and their interactions
Workflow Metadata Model. The data model describing the data of the Web application is extended with workflow and exception metadata. In this paper we consider as conceptual model the Entity-Relationship model. Consider, for example, the application data of our case study, represented in the bottom part of Fig. 8. It consists of LoanProposals, whose conditions are imposed from a Country; each loan proposal can be fulfilled based on various InstallmentPlans; the customer may choose one of these plans and submit a LoanRequest; finally, if the request is approved, he can proceed with the periodic payment of the instalment plans, which are recorded by the InstPayment entity. WORKFLOW AND EXCEPTION META-MODEL Group
Activity Type
Name ...
1:1
Part Of
0:N
0:N
1:N
1:1
1:1
Type
0:1 Assigned To 0:N 1:N
Username Password ...
0:N
1:1
ExecutedBy
Created
0:N
InstPayment
APPLICATION MODEL
1:N
1:1
1:N Part Of 1:1
Exception Instance
Status StartTimeStamp EndTimeStamp
0:N 1:1 Affects
Status StartTimeStamp EndTimeStamp
1:1
0:N Affects Created 1:1
Loan Request 1:1
0:N Type
Case 1:1
0:N
RelatedTo
1:1
InstID Amount Date
Status StartTimeStamp EndTimeStamp
Name
Current Page
Activity Instance
0:N 0:N
ManagedBy
Exception Type
Page Url Starting_Page
Current
1:1
User
Process Name
0:N
Default
0:N
1:N
Name
OID Email Established Rate ...
Installment Plan 0:1
0:N
Rate Expiration_Date ...
Loan Proposal 1:1 1:N
ID Max_amount Min_amount Conditions ...
Country 1:1 1:N
ISO_code Discount_Rate LastVariation ...
Fig. 8. Workflow and Exception metadata modeling
The application model is extended with the entities of the upper part in Fig. 8, containing the entities representing the basic concepts of a workflow on the left-hand side, both at type level (Process, ActivityType, and Group of users) and at instance level (Case, ActivityInstance, and User). This metadata is inspired by the WFMC specification [13] and is described in detail in [4]. Exception execution context is captured by the exception metadata on the right-hand side. Entity Exception denotes the classes of known exceptions that may occur during the process execution and are described by a name (e.g., Wrong Starting Page, Discount Rate Variation, and so on). The actual occurrence of an exception is presented in the entity Exception Instance
and is described by start time, end time and status which can be: active (i.e., the exception has occurred and has not been addressed yet), resolving (i.e., the exception is currently being solved by a predefined policy or a compensation chain) and resolved (i.e., the exception has been solved by some exception handling mechanism). Exceptions may affect activities or cases. Further objects in the exception metadata are introduced for exception handling. The executor of the appropriate exception handler is either the user who has actually performed the affected activity instance and is recognized by the “Executed By” connection, or the user denoted by the “Managed By” connection as the responsible to handle exceptions for the specific case. For each activity in progress, we keep track of the CurrentPage, defined as the last page that the server has generated after a request by the client. The current page allows checking if the client uses the back and forward buttons of the browser and enables resuming capabilities after breakdowns. The capturing model incorporates all the mechanisms used to capture events and generate exceptions to be stored in the workflow meta-model. In our framework the model remains apart from the normal workflow design allowing the identification of exceptions independently of the process state, thus even when the process is not active. We propose two different mechanisms (see Fig. 7) for the exceptions classified in Section 2, namely: (a) triggers, used for capturing exceptions caused by data modifications, and (b) Web services 1 , used for capturing exceptions explicitly notified by external entities. Once an exception is captured, the corresponding trigger and Web service are responsible to generate new exception instances into the database and to connect them to the affected activity instances or cases, thus taking into account the scope level. Behavioral exceptions can be captured by means of triggers defined on the workflow meta-data. While the user navigates within an activity, an automatic update in the workflow meta-data keeps track of his current position (in the CurrentPage entity). Therefore, an improper navigation is followed by an invalid modification on workflow data that can be captured by a trigger. Semantic exceptions can be captured either by means of triggers defined on the application data, or through Web services when they are notified by external sources. For example, the modification of the expiration date of an installment plan can fire a trigger defined on the entity Installment Plan in the database. The Invalid Loan Amount exception may be raised after calling the Loan Search Web service in the loan search activity, and the notification of the discount rate variation for a country may be notified by an external application by means of a notification Web service. System (client-side) exceptions can be captured by means of Web Services as well. The external source that notifies the appropriate Web service at server-side is the Web Server when it detects the client’s unavailability because of an unsuccessful communication between the server and the client. The notifying model incorporates all the mechanisms used to present the captured exception (stored into the database) to the user. Synchronous and asynchronous exceptions require different mechanisms. Indeed, if the exception occurs synchronously during the execution of the workflow activities, it can be notified immediately inside 1
Our choice of using Web services as opposed to other inter-process communication mechanisms is motivated by our focus on interoperability and portability. Web services can be invoked either by the workflow application itself or by external applications.
the affected activity: this means that in this case the notifying model can be integrated directly into the workflow design. If the exception occurs asynchronously the notification should take place outside the process flow and be represented apart of the workflow design. In both cases, exceptions can be detected by querying the exception and workflow meta-data. Within the workflow, synchronous exceptions can be captured when the user navigates a link. In order to support synchronous exceptions the process hypertext modeling introduced in Section 2.2 is extended with the concept of exception-aware link, which is a navigational link used within an activity extended with the ability to check the exceptions occurrence in the database and to redirect the process flow to the recovery mechanisms (see the example in Fig. 9). In order to support asynchronous exceptions an exception-control mechanism is defined to be included in a generic hypertext page, possibly outside the process: exceptions occurrence in the database is checked before the page is loaded so that a hypertext link is activated to allow the recovery mechanism. The handling model represents the mechanisms used to recover the exceptions. It consists in recovery operations that take place on the affected activities or cases after the user notification in order to bring the application to a consistent state, so that the process execution can proceed. The recovery policies can be either predefined or user-defined. Predefined policies are server-side automated operations that can be applied to different exception types. The process execution, after the exception is handled, is implicitly specified and routed from the predefined policy. We have identified five predefined policies, which can automatically update the corresponding workflow/exception metadata (see Fig. 7): • The Accept policy: it accepts all the operations done by the affected activity/case and concludes the activity/case execution. • The Reject policy: it deletes all the data created by the affected activity/case and enables its re-execution. • The Abort policy: it accepts all the operations done by the affected activity/case and concludes the activity/case execution. • The Ignore policy: it informs the user of the occurred exception with a message and resumes the flow execution. • The Resume policy: it resumes the user navigation from the last visited page generated by the server for the affected activity; all the data created by the affected activity/case after the last visited page navigation are deleted (see the example in Fig. 9). User-defined policies are defined from the application designer to manage critical situations when automated mechanisms cannot restore the process state. For example, the exception caused by the discount rate modification may require the revision of the conditions of the loan proposals: such variations need to be explicitly modeled by the designer. User-defined policies specify explicitly the pages/operations to be executed to handle the exception and the process flow after the exception handling. Example. Fig. 9 shows the extension of the hypertext for the notification and handling of the synchronous exception Wrong Starting Page presented in Fig. 3. It is achieved through exception-aware links (marked with an “E”) exiting the pages within the loan request activity. The improper user navigation is handled with the
automatic application of the predefined Resume policy; the user is directed to the last generated by the server page, the LoanAck page. Loan Request Activity Available Loans
Cached Page
E
Resume
Loan Details
E
Loan Ack
E
Some page
Last Requested Page
Fig. 9. Notification and Handling for the Wrong Starting Page exception
4 Comparison with Existing Standards Our primary objective is the handling of exceptional situations that are not part of the normal flow of a Web-based process and may drive its execution to an uncertain state. The advantage of the present work is the ability to handle external and internal errors that may occur independently of the process state and therefore, their detection time and place cannot be expected. As we will see in the following paragraphs, existing standards base their approach on block-structured or graph-structured programming techniques. In particular, we will present the process definition notation BPMN [1] and the process definition languages BPEL4WS [2] and XPDL [14], we will examine their behavior in the situations of Table 1 and we will evaluate their ability to handle the exceptions presented in Section 2.
4.1 Standards Overview The Business Process Modeling Notation (BPMN) provides a business-oriented framework for describing the internal implementation of a business process as well as its interactions with other processes or participants; therefore, it is used for modeling both abstract and executable processes. The basic components in a BPMN model are called Tasks (atomic activities); they may be grouped to form a compound Activity, and are always part of a Process element. The order of execution of the activities will in a process is modeled as a sequence flow controlled by gateway elements. Every activity – atomic or compound - is associated with an event context that keeps track of specific events occurrence during its execution. While the activity is running, the event context captures events and redirects the user through the exception flow to the appropriate event handler. BPMN handles various types of exceptions either triggered from messages, timers, process data evaluations and application errors within the activity context, or thrown with the throw construct from any point of the process execution. Events that are triggered or thrown when the activity is not active, are not captured, neither are handled. Once an event is handled, the process execution con-
tinues with the sequence flow outgoing the exception handler. Every activity may be associated with compensation logic in order to undo its outcome only after its completion. Like the exception flow, the compensation flow occurs outside the normal process execution and is activated by a transaction rollback request. The Business Process Execution Language for Web Services (BPEL4WS) is an XML-based process definition language; in particular, provides a process-oriented Web services invocation. A process definition is composed of basic activities corresponding to WSDL operations for Web services calls, and compound activities used to group complex structures. The order that activities will be performed is based on flow dependencies called links, and is controlled by basic control structures like in BPMN. The state of one or more activities, or even the state of the process as a whole is recorded at an enclosing scope level. Each scope has its own fault handlers that are called to take control when exceptions occur. Situations that may raise exceptions in BPEL4WS are distinguished in application errors, in fault responses to invoke activities that correspond to WSDL operations, and in internal errors generated explicitly by the throw activity. Such faults are either captured and handled by the current scope or implicitly re-thrown to the scope of the upper level. The fault handling aims to recover the state of the affected activity before the error occurrence, and does not make part of the normal processing. Therefore, the enclosing scope ends abnormally even if the fault is handled. In case the fault propagates to the process scope, the process terminates abnormally; otherwise, if the fault is handled within a scope, the scope execution ends abnormally but the process execution continues the normal flow that follows the current scope after the fault handling mechanism is applied. Compensation handlers may be also associated to a scope to undo the output of an already completed enclosed activity. They are called explicitly from the application or implicitly by enclosing compensation handlers. They are used to communicate to external entities and reverse the activity results, but do not affect the state of the process instance. Each scope may be also associated to event handlers. These are enabled when the associated scope starts, triggered when a message arrives and disabled when the associated scope ends. The Xml-based Process Definition Language (XPDL) is the WfMC proposal for a process definition language. Unlike BPEL4WS, XPDL is a graph-structured language in which nodes and edges represent the main work elements, called activities and transitions between activities respectively. A process definition is contained in a Package element; it may retain workflow relevant data and may support complex activities constructed with the BlockActivity element. The state of work items (activities and processes) remains at package or process level but there are no exception handlers attached to these levels. The exceptions captured by an XPDL process are deadlines and other exception conditions that are controlled during the transition from one activity to the following. If an exceptional condition holds, the transition explicitly follows the appropriate exception flow. Exception activities are integrated into the workflow design in order to handle the undesired event. There are no constructs for compensation and transaction support.
4.2 Comparison In our framework described in Section 3 exception capturing is modeled apart from the workflow design. This separation allows us to capture events even when the process is inactive or complete. A further separation focuses on the notification of the user and the handling of the unexpected event. The combination of the last two models with the workflow design introduces further flexibility: the user gets notified and handles the exception within the process execution when they occur synchronously, or outside the process flow when they are asynchronous. In the following, we will examine the behavior of BPMN, BPEL4WS and XPDL for the handling of the different exceptions presented in Table 1: • In BPMN, behavioral exceptions for an atomic activity instance may be captured by rule events attached to the boundary of the activity. The current page may be declared as process data within the activity and gets evaluated by the rule after user navigation within the activity. If an exception is raised, the user is directed to the appropriate event handler. After exception handling, the process execution continues with the exiting link of the handler. In a similar way, in BPEL4WS the current page may be declared as process data in the scope enclosing the basic activity. Within the activity, an explicit control is made on the current page after user navigation. If a condition for improper user navigation holds, an exception is thrown and then captured by a fault handler in the enclosing scope. Unfortunately, after exception handling, the affected activity cannot continue or resume its execution; it can only end abnormally. The process execution may continue the flow that follows the current scope. XPDL does not support exception controls within an activity instance, but only within a transition between activities; therefore, a behavioral exception cannot be captured. • The semantic synchronous exceptions (like the Invalid Loan Amount) occur within a particular activity and affect the current process instance. In BPMN, they may be captured as a message event attached to the boundary of the process. The exception flow is then executed, the event handler is activated and the process execution continues explicitly with the outgoing link of the handler. In BPEL4WS, the exception may be raised as a fault response to an invoke activity, propagated and captured at process level by a fault handler. Although the exception is caught, the process cannot repeat its execution and ends abnormally. XPDL is not oriented to web services and requires additional constructs in order to handle events notified by external sources. • The semantic asynchronous exceptions (like the Discount Rate Variation, Cancel and Expiration Date Modification) may occur anytime during the process execution. In BPMN, the Discount Rate Variation and Cancel exceptions may be captured as message events, attached to the boundary of the process. If the process is active, incoming messages will trigger the events and the exception flow will be followed. Otherwise, if the process is complete or inactive the events will not be triggered and the exceptions will not be handled. In BPEL4WS, event handlers that correspond to a notification operation in WSDL may be implemented at process level for the notification of the Discount Rate Variation and Cancel events. Incoming messages trigger the handlers, the appropriate actions are taken and the process continues its normal flow. If the process execution ends
•
normally before the messages arrive, the events handlers are disabled and therefore, the exceptions are not caught. The Expiration Date Modification exception occurs anytime during the process execution but there is not a way for BPMN, BPEL4WS and XPDL to get notified for a modification in the application database. The event may be notified explicitly by a receiving message in BPEL4WS and BPMN. The system exception Session End occurs asynchronously; the user session is off. Timer events in BPMN and event handlers of type alarm in BPEL4WS raise an exception upon the expiration of a fixed period of time for the associated activity and scope respectively. Deadlines in XPDL are defined on a specific period of time that may be computed using workflow data for an associated activity. The mechanisms are enabled when the execution of the associated construct starts, and therefore, they cannot be used to check the expiration of a period of time that is being set dynamically, e.g., after user requests. An extended version of these constructs could be used to capture a session end exception. Although the exception would be captured, it could not be handled immediately because of user’s unavailability. BPMN, BPEL4WS and XPDL do not allow exception handling to be separated from the exception trigger and to take place asynchronously. Table 2. BPMN, BPEL4WS and XPDL support for exception handling Exception Behavioral Semantic synchronous Semantic asynchronous System
Capture BPMN BPEL4WS BPMN BPEL4WS BPMN (partially) BPEL4WS (partially) -
Notification BPMN BPEL4WS BPMN BPEL4WS BPMN BPEL4WS -
Handling BPMN BPEL4WS (partially) BPMN BPEL4WS (partially) BPMN BPEL4WS -
The existing standards partially resolve the problem of exception handling in Webbased applications. We have found several limitations in the presented standards either to capture, notify, or to handle the exceptions. In particular, system exceptions cannot be captured, and behavioral and semantic exceptions can be captured in BPMN and BPEL4WS. Semantic asynchronous exceptions can be modeled only if they are notified by external sources and the process is active at their occurrence time. For the captured exceptions, the process in BPMN successfully handles them and follows the normal flow. In BPEL4WS not all the recovery policies introduced in our framework can be applied: indeed, behavioral, and semantic synchronous exceptions can be handled by means of fault handlers that terminate the corresponding activity abnormally. Instead, the semantic asynchronous exceptions, detected by of event handlers, can be handled successfully and therefore the process execution may complete normally. Additional structures in XPDL are required to capture and handle the above exceptions. Table 2 summarizes the above conclusions: for each exception type it shows the possibility to be captured, notified and handled by the presented standards.
5 Conclusions In this paper we have presented the characteristics of the exceptions in a Web-based application driven by a workflow. We have seen that due to the nature of Web applications, new kinds of exceptions arise in such context, and that different ways for notifying and handling them should be possible. We have provided some classifications of the exceptions, useful for the definition of a framework based on workflow and exception meta-data, on a capturing, notifying and handling model for handling such exceptions. We have also compared our framework with existing standards that can be applied in the Web context, such as BPMN, BPEL4WS and XPDL: from our analysis it results that only some kinds of typical Web exceptions can be handled by such process modeling languages. Our framework has been defined at an abstract level and therefore can be mapped either into more detailed designs based on Web modeling languages, or directly on the implementation level. As an example, in [5] we have applied it to the WebML modeling language [7].
References 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
BPML and BPMN site http://www.bpmi.org/. BPEL4WS site http://www-128.ibm.com/developerworks/library/specification/ws-bpel/ Brambilla, M.: Extending hypertext conceptual models with process-oriented primitives. In Proceedings of ER 2003, 22nd International Conference on Conceptual Modeling, Chicago, IL, USA, October 13-16, 2003. LNCS 2813, Springer, pp. 246-262. Brambilla, M., Ceri, S., Comai, S., Fraternali, P., Manolescu, I.: Specification and Design of Workflow-Driven Hypertexts. Journal of Web Engineering (JWE), vol.1, number 2, 163-182, April 2003. Brambilla, M., Ceri, S., Comai, S., Tzivisko, C.: Exception Handling in Workflow-Driven Web Applications. Int. Conf. WWW’05. Chiba, Japan, May 2005. Bultan, T., Fu, X., Hull, R., Su, J. : Conversation specification: a new approach to design and analysis of e-service composition. WWW 2003, 403-410. Ceri, S., Fraternali, P., Bongio, A., Brambilla, M., Comai, S., Matera, M.: Designing Data-Intensive Web Applications, Morgan-Kaufmann, 2002. Hagen, C., Alonso G.: Exception Handling in Workflow Management Systems. IEEE TSE 26(10), 943-958, 2000. Miller, J. A., Sheth, A. P., Kochut, K. J., Luo Z. W.: Recovery Issues in Web-Based Workflow. CAINE-99, Atlanta, Georgia, 101-105, November 1999. Van der Aalst, W. M. P., ter Hofstede, A. H. M., Weske: Business Process Management: A Survey. Business Process Management 2003. Van der Aalst, W. M. P., Aldred, L., Dumas, M., ter Hofstede, A. H. M..: Design and Implementation of the YAWL system, CAiSE 04, Riga, Latvia, June 2004. Springer Verlag. WebML Web site http://www.webml.org . Workflow Management Coalition site http://www.wfmc.org XPDL site http://www.wfmc.org/standards/XPDL.htm
