Introducing Contracting in Distributed Transactional ... - CiteSeerX

2 downloads 14 Views 122KB Size Report
email: {egon, mikep} Abstract. In this paper ... Workflow systems automate the movement and execution ...... Sending and receiving of messages is done.

Introducing Contracting in Distributed Transactional Workflows E.M. Verharen, M.P. Papazoglou Infolab, Tilburg University, Pobox 90153, 5000 LE Tilburg, The Netherlands email: {egon, mikep} Abstract In this paper we describe a flexible transactional workflow environment based on an extensible object-oriented framework built around class libraries, application programming interfaces, and shared services. To enforce coordination in workflow communications and model real-life business applications, the concepts of 'obligation' and 'contract' are introduced. A contract is a semantic agreement between two or more collaborating workflows in terms of a protocol-oriented specification of obligations. It is used to describe the communication between systems by means of nested transactions associated with the provision of services. An example from the banking world illustrates this approach.

1. Introduction

ess-oriented actions. Database-like transactions interact with the processes to further the progress of the workflow or are used alternatively for interrogatory purposes. Transactions in workflow applications should be nested, they should interact, are rolled back, and do not become final until committed much in the same way as with conventional database systems. Workflow systems, therefore, require sophisticated (non-conventional) transaction mechanisms to support the sharing of uncommitted data between concurrently active processes. Although this approach is quite flexible it does not enforce the coordination of business activities in workflow communications according to business policies and/or agreements. We therefore propose to extend transactional workflows with a "contracting" component to deal with such cases. Fig.1 provides a high-level overview of the proposed architecture for workflow environments. APPLICATIONS

Business applications rely increasingly on the coupling of local applications with applications running on remote servers. They require the use of information services that are designed to provide coherent and reliable information access to shared and mutable data originating from disparate information sources in order to support greater workgroup and organizational productivity. The ultimate goal is to provide a richer information creation and analysis environment for the user by integrating the user's desktop facilities with an information exchange and collaboration infrastructure including mail, messaging, groupware platforms, shared databases, and document servers. In a business setting these information services are typically part of an organizational workflow management system. Workflow systems automate the movement and execution of a number of units of work, across one or more servers, according to business defined rules and routes. A workflow defines the individual business activity steps, the order and the conditions under which the activities must be executed, the flow of data between activities, the users responsible for the conduct of these activities, and the tools used. Workflows are, generally speaking, long-lived activities that are characterized by a well-defined set of proc-

Workf low Environment _ consist s_ of

Transact ional Workf low

Transact ions

Cont ract ing pre-cont ract ual phase ( cont ract spec.)

f ulf ilment phase



Figure 1. Workflow environment architecture Fig.1 illustrates our view of a workflow environment consisting of a transactional workflow and a contracting component. The transactional workflow component comprises a number of interacting and possibly nested transactions while the contracting component couples flexible transactions with contracts. The proposed contracting mechanism consists of a pre-contractual and a fulfillment phase. In the pre-contractual phase, (possibly cross-organizational) systems exchange information about services to

1060-3425/98 $10.00 (c) 1998 IEEE

be provided, evaluate the information, and finally enter into a commitment phase in which final agreement is reached by mutual agreement about the services and conditions under which these are provided. A special precontractual language must be used for this purpose. The result of the pre-contractual phase is the specification of a contract. A contract describes the mutual obligations of the interacting systems. Obligations are types of mutual commitments to the delivery of business related services which are carried out by means of transactions. A contract is an advanced form of transaction which describes a semantic agreement between interacting systems. A contract comprises three parts. Firstly, it defines a protocoloriented specification of obligations, in terms of serviceoriented transactions, which lead to the fulfillment of a contract. Secondly, it specifies a set of conditions that might lead to a re-evaluation of the contract and finally a violation-sanction part, in case that a contract is not fulfilled (the obligations are violated). Overall a contract specifies the exchange of a special set of synchronization messages at predefined activities or events mediating between two different workflow enactments. In broad terms the fulfillment phase describes the transactions that have to be carried out in order to fulfill the obligations, according to the contract. Hence the arrow connecting the fulfilment phase to the transactions in fig.1. The transactional workflow environment extended with contracts is built on top of a distributed platform which provides an infrastructure of communication and data access services. In this paper we will assume that the pre-contractual phase has concluded successfully and will concentrate only on the obligation phase, and describe contract specifications and the fulfillment of contracts in terms of transactions. In the remainder of this paper we describe how contracts and obligations can be integrated in the workflow environment, providing contractual abilities on a semantic level. This paper is organized as follows: section 2 provides an overview of background and related work, while section 3 discusses our contracting framework, including its consequences for transaction semantics. Section 4 describes the framework's application in workflow settings by using a banking application. Section 5 discusses development of this framework. Our summary and future work can be found in section 6.

2. Background and Related Work This work relates to activities in three areas, namely transactional support for workflow systems, programming languages and contracting systems. Most of the recent attempts to provide transactional support for workflow systems by extending the classical

work (collectively referred to as open nesting) have only concentrated either on conceptual transaction models, concurrent versions of algorithms and theoretical results on model correctness, and lack proper implementations. Moreover, flexible transaction models used for workflows have adopted a strictly data-centric approach [1]. In contrast to flexible transaction models, workflow management systems, due to their very nature, are process-centric. Their aim is to provide modeling support and mediate communication, interaction and coordination among collaborating people and business activities within and between organizations. In this respect they are concerned with automatically routing the work from one process to the next. Script-based sub-language approaches, such as ConTracts [2] and Interactions [3], are also closely related to transactional workflows. ConTracts were proposed as a mechanism for grouping transactions into a coherent unit of work. ConTracts are scripts of steps, where steps are mapped into transactions on local databases. ConTracts provide mechanisms for relaxed atomicity and isolation by controlling the flow of long-lived activities. Interactions are also open nested flexible transactions used to define long-lived tasks that access multiple databases. Interactions provide the ability to backtrack when a transaction aborts and causes its subtasks to fail. The previous approaches provide only very limited language support. They provide only a handful of special purpose primitives and control mechanisms mainly tailored around opennested transactions and modeled primarily after blockstructured programming languages. In contrast to the approaches outlined above, our previous work [4] places more emphasis on providing the run-time environment in which workflow processes are coordinated and executed based on concurrent object-oriented (OO) programming support for transactional workflows. In particular, we addressed this issue by providing unified programming and distributed system support necessary to program workflow applications. Support given for describing the interaction between transactions and workflow is based on the use of object libraries that implement transaction extensions of an OO programming language coupled with distributed system support. On the programming language front there have been attempts to capitalize on the correlation between the notion of modularization in modern programming languages and transaction nesting. E.g., Argus [5] provided linguistic support for implementing the execution of distributed programs based on the closed-nested transaction philosophy of Moss [6], however, it lacked the proper database and operating system support, and permits only a single thread of control to execute within one transaction. These limitations have been addressed, at least partially, by the

1060-3425/98 $10.00 (c) 1998 IEEE

work of Haines [7] which describes a modular language for supporting transactions based on high-order functions. This work proposes a general purpose control abstraction mechanism through which one can compose flexible transactions. Our work differs from the above activities by providing a richer variety of semantic-oriented transaction primitives in the form of an extensible/specializable class library combined with an object-oriented language and distributed system support. Work on contracts in workflow systems has been mainly focussed on extending the Petri-net model for workflows. For instance, in his research on systems for supporting electronic contracting, Lee uses Petri Nets for specifying contracts [8]. At this moment it is not clear however how the obligations that are included in the places in the Petri Net are specified. In [8], [9] a variant of deontic logic is used as formal framework for specifying contracts, similar to our previous work [10]. [11] and [12] describe work on interoperable transactions, in which also a separation of tasks and contracts is made. Contracts are specified using Petri-nets where the places contain deontic logical formulas describing the obligations of the communicating systems. Transaction are made up of messages that are specified using performatives based on speech act theory. In both approaches the emphasis is on the logical modelling of contracts and the contracting process and not on providing an execution environment for workflow and electronic contracts. Some similarity exists between our treatment of contracts and that of Action Workflow of Action Technologies [13]. Action Workflow is a generic workflow analysis and modeling framework which divides a workflow into four phases: preparation, negotiation, performance and acceptance. The first two phases correspond to our notion of a pre-contractual arrangement and the last two deal with contract enactment and correspond to our notion of contract fulfillment. Communication in Action Workflow is based on speech act models whereas in our case we concentrate mainly on transactional communication and synchronization aspects. More elaborate work on contracting and speech act modeling can be found in the previous work done by one of the authors [10].

3. Contracting in workflow environments We view an information system (IS) in a workflow* environment as an autonomous system providing a list of exported (information) services (from the IS's service repository) which can be combined with other such services *

This work concentrates on workflows with transactional properties only. Hence we use the word ‘workflow’ informally to denote these types of systems.

as part of a transaction or a contract. A contract is specified in those cases where we wish to be explicit about the obligations of interacting workflows and the violation of agreements described in these workflows. Whenever a workflow client application requires a service (crucial to one's business or financial conducts) provided by a server it can only request that service as part of a contract. Such interactions may, for example, include the provision of goods or business services together with a financial agreement about the terms of provision. This activity then becomes a semantic-agreement (predefined order of specialized messages) between collaborating systems as it involves a precise protocol-oriented interaction. The mutual agreement describes the respective obligations of both systems in the cooperation. An obligation here is a mutual promise to the conduct of a compound activity relating to the delivery of services. The obligations that are agreed upon are specified in the contract which describes the behavior of receivers and providers of services in terms of interoperable transactions. Although task specification is the key ingredient of extended and flexible transaction models (cf. [1]), none of them attempts to model the effect of transactions in terms of obligations. This means that transactions can only be classified as either a success/failure in those models; it is not possible to enforce and reason over violation of obligations or to re-adjust the original goal to avoid the failure. The use of contracts also provides the possibility to elegantly specify failure and exception handling. Other approaches to transactional interactions specify failure and exception handling as an integral part of a transaction [1]. This simplistic approach does not deal with contractual violations or any other type of more complicated failures. Moreover, it muddles transaction specification and hinders transaction reusability. Our framework supports efficient re-adjustment of interoperable applications as compared with traditional interoperable database systems, e.g. [14].

3.1. Contracting phases A contract is set up by two or more systems when interacting. In this section we take a closer look at our contracting mechanism based on a variant of the Business as Action game Theory (BAT) [15]. This approach describes a generic framework for business transactions between two (human) parties. It describes the role of a supplier providing, and a customer receiving a service, and their activities in an interchange process. As already mentioned in the introduction our contracting model consists of two phases: the pre-contractual phase and the fulfillment phase the design of which have been largely influenced by this approach. These are briefly described in the following:

1060-3425/98 $10.00 (c) 1998 IEEE

Pre-contractual phase. This is the initial phase in which parties (in our case ISs) exchange information about the services to be provided, evaluate the information, and reach final agreement. The results of this phase are obligations and a contract describing transactions that have to be carried out in order to fulfill the obligations. This phase can be seen as a condensation of the first two phases of BAT. Where BAT is based on a market situation in which two organizations want to set up a business relation, the focus in our approach is on the interaction between two known ISs as part of a workflow. In BAT emphasis is placed on the negotiation process. As the notion of contract, in our work, is mainly used to structure the interaction between systems we do not deal with negotiation herein. Our notion of contracting can be augmented with negotiation primitives along the lines of [10]. Fulfillment phase. After the contract describing the mutual obligations has been set up we enter into a phase in which transaction enactments are to be carried out. Besides the transaction specification the contract can contain a specification of what should happen if one of the systems does not adhere to the obligations it agreed upon. In contrast to BAT the focus in this phase is not on satisfaction or dissatisfaction of both the (human) provider and customer of a service and for instance appeals to warranty, but more on the completion of the service execution, and possible sanctioning actions in case of a failure.

3.2. Elastic transactions In this paper we view a workflow application as a long-lived activity that coordinates the execution of multiple process-oriented tasks. These tasks have inter-related dependencies capturing both data and control flow requirements and constraints. A long-lived activity is divided into a number of work units, nested to multiple levels, which may execute sequentially or concurrently. Work units that can be found only on the leaf-level of an activity tree are referred to as actions. Actions are a form of process some of which may execute at remote (component database) sites where they are mapped to native transactions, viz. exported services. The intermediate nodes in a workflow hierarchy are normally (atomic) compound actions or activities which comprise a set of elementary actions. A contract is a special type of activity involving normal actions and special types of actions which specify (financial or other) obligations. We refer to the combination of all these different types of actions and activities as elastic transactions. To indicate the process nature of activities, actions, and contracts, we frequently use the term process to describe them.

4. Workflow application Transactional workflows are used to automate business systems that have definable, repetitive, and well understood policies and procedures. For example, purchasing a residential property is a high level workflow process that consists of securing a mortgage loan and maintaining the property. A mortgage loan approval application is a well understood process that goes through a prescribed set of procedures. The processing of a loan goes through standard phases regarding the processing and routing of intermediate units of work. A mortgage loan plan is a long-duration activity which may span from hours to several days, and requires interaction with several financial institutions. This application must outline specific procedures and protocols to be carried out, preserve ongoing work, coordinate inter-related pieces of work, respond to business events, schedule further work and so on. To illustrate the workflow features of our proposed approach, we model a mortgage loan planning activity according to the graphical notation depicted in fig.2. This notation (found in [4]) models a workflow activity as an acyclic directed graph in which leaf nodes (ovals) represent actions; nodes representing intermediate activities are symbolized by either rectangles or pentagons; nodes representing contracts are symbolized by hexagons; and finally, edges represent the flow of control while specialized arc symbols represent the flow of data and synchronization modes between simple and compound actions, and between actions and contracts. The different kinds of data flow and synchronization modes are described in section 4.2. Loan_ Request

lending_ inst it ut ion


Find_ Credit _ Union

Find_ Bank

Mort gage_ Loan cont ract

A ppr ov al w or kf low

Bank_ name

Of f er_ Home_ Loan

Support _ Home_ Loan

Figure 2. Activity tree for a home loan application involving contracts Rectangles symbolize a serial activity where the actions are executed synchronously one after the other whereas a doubly-lined rectangle indicates a parallel activity where the actions are executed completely asynchronously. A pentagon symbolizes a serial alternative activity which attempts actions sequentially until one produces

1060-3425/98 $10.00 (c) 1998 IEEE

the desired outcome, whereas a doubly-lined pentagon represents a parallel alternative activity where alternative actions are pursued in parallel until one succeeds. In fig.2, we assume that a mortgage loan application seeks loan approval from a number of lending institutions which may potentially finance a customer purchasing a residential property. The application, viz. a serial activity called Loan_Request, tries to secure a home loan by obtaining funding from banks (in terms of preferences specified by the customer) and alternative funding sources, e.g., credit unions. This involves interaction with funding institutions in geographically distributed locations and is shown by means of a high-level activity called Appraisal which spawns two processes Find_Bank and Find_Credit_ Union. We assume that this activity can execute its units of work in parallel and can succeed if both of its children succeed, irrespectively of which one finishes first. If the customer is successful in securing funds, then a contract is established. This situation is shown by means of a complete arrow directed from Appraisal to Mortgage_Loan_Contract signifying a contractual dependency on the object lending_institution. The contract contains the activities which need to be conducted for the provision of the loan and purchase of the property, and the obligation of the customer to pay back the loan. The contract Mortgage_Loan interconnects two workflows: the Loan_Request and the Approval, which may run on different servers. lending_ inst it ut ion


Home_ loan

Pay_ of f _ Loan

Open_ Home account Local_ Loan Updat e_ Tit le Organize_ Finances

Transf er_ Money

Wit hdraw

Insure_ Propert y

need more f unds



Reassess_ applicat ion


Fund_ Alt ernat ives

Add._ Pers._ Loan

Home_ Equit y_ Loan

Addit ional Cont ract

Figure 3. A contractual activity tree for a home loan application Fig.3 depicts the serial activity Approval with all its constituent processes. The contract oblibation (shaded oval) Pay_off_Loan represents the obligation part of the Mortgage_Loan contract with regard to Approval. The synchronizing parameter lending_institution needs to be supplied

from the activity Loan_Request to trigger the execution of the obligation Pay_off_Loan. The Approval process forks a series of sequential processes which open a home loan account first, organize finances, insure the property (only if the activity Organize_ Finances has succeeded), and finally update the title. Attention is drawn to Organize_Finances which is a parallel activity. Its first process transfers funds from remote account(s) to the home loan account to buy a residential property. Its second process is the conditional connector More_Funds_ Needed which detects situations where a customer needs more funds to cover other expenses such as stamp duty, solicitor fees, etc. In this case other options may be attempted, e.g., a personal loan or a home equity loan (a line of credit secured by a registered mortgage over a residential property), both possibly leading to new contracts with those financial institutions.

4.1. Using elastic transactions to model contracts The flow of control and data between the work units of an activity needs to be explicitly specified and scheduled. Scheduling is required since the actions that run on remote databases access and change shared data items and require synchronization to avoid corrupting these data items. If actions fail, their effects must be retracted and other actions in other remote databases which have ‘observe’ their effects must also be retracted. To achieve these effects we based our work on extending workflow constructs that we introduced in [4] where we described a TransactionOriented Workflow Environment (TOWE) for programming workflow activities. In this paper we extend TOWE with contractual activities and name it TransactionOriented Workflow Environment with Contracts (TOWEC). TOWE provides facilities for the construction and programming of long-lived concurrent, nested, multi-threaded activities for workflow applications. These combined facilities come in the form of class library facilities that implement transactions on the basis of a symbiosis of object-oriented programming and interprocess communication concepts. The following two subsections describe synchronization aspects and constructs of TOWEC and a partial specification of the activities described by means of the TOWEC language.

4.2. Synchronization and dependencies Our design unites the constructs of class and process types as they both support local variables, persistent data, encapsulated behavior, message passing mechanisms and restrictions on how modules exchange information. We provide scheduling library classes which run on each com-

1060-3425/98 $10.00 (c) 1998 IEEE

ponent database. Instances of specialized scheduler classes are created for every long-lived contractual (or noncontractual) activity. This allows the construction of concurrent functions to be performed separately from task scheduling and leads to increased concurrency in application programs. In TOWEC, the concurrency abstractions are represented by process objects, a type of active objects acting as processes, which involve asynchronous, locationindependent, and application specific process invocations. All scheduling and synchronizing objects are process (active) objects. These should be distinguished from passive objects which are the TOWEC data objects, such as Accounts, Customers, Property, various types of Loans, on which the process objects operate. We distinguish between four types of scheduler processes, implemented as scheduling classes these come in addition to contractual activities. Scheduling and contracting classes are sufficient to program the various types of activities by means of an elastic transaction in a workflow application. 1. A serial activity whose actions are submitted and committed sequentially, e.g., the Approval activity in fig.3. Serial schedulers establish a begin-on-commit dependency with each other, i.e., one cannot begin unless the previous one commits. If any of them fails, their parent transaction aborts including all of its tentatively committed descendants. All actions should commit in order to make their parent transaction commit. 2. A parallel activity which allows all of its actions to be submitted and executed in parallel as independent activities. These actions also commit independently. It is expected that all actions should commit before their parent commits. 3. A serial-alternative activity is a scheduler which attempts actions sequentially until one produces the desired outcome, e.g., the Find_Bank process in fig.2. The parent only aborts if all its descendent actions were tried unsuccessfully or if the transaction is timed out. 4. A parallel-alternative scheduler where alternative choices are pursued in parallel. This is the case with the Find_Credit_Union process. As soon as any one of the actions succeeds, the scheduler commits and the effects of all other parallel actions are discarded. Scheduler process may also have conditional actions which get activated if certain conditions hold at run time, see the activity Need_More_Funds in fig.3. The activities described above introduce a number of important scheduling dependencies which are particularly suitable for the programming of workflow activities. These include:

1. Data object dependencies may be introduced in a serial activity. Data object dependencies correspond to passing an argument in the form of a referenced object between consecutive actions. This is indicated by the presence of a bold dashed arrow in fig.3 where actions Insure_Property, Update_Title, and Pay_off_Loan need the data object Home_Loan_Account. 2. Value dependencies are introduced when a receiver process blocks to wait for a specific attribute value to arrive before it starts executing. This blocking may occur at some point when the receiver needs a particular attribute value produced by a sender process, e.g., in fig.2 the Find_Credit_Union process needs a bank-name from the Find_Bank process to complete its computation. 3. Commit dependencies may be introduced when two activities may go in parallel but one may not commit unless the other commits first. This indicates that an activity waits for a signal from another, i.e., blocks, before it is allowed to commit. This is illustrated by the dotted doubly-headed arrows in fig.3 where the actions Additional_Personal_Loan and Home_Equity_Loan cannot commit unless the activity Transfer_Money has committed first. 4. Contractual dependencies may be introduced if a contractual process requires an argument (or sets of arguments) to proceed. Consider for example the case of Contractual_Approval, shown in fig.2, which requires the argument lending_institution to proceed. 5. Version dependencies may be introduced in case where a process may alter its computation course depending on which version of a data object arrives. To provide a rich environment for workflow applications additional salient features are needed. These include such mechanisms as: compensating actions to undo, from a semantic point of view, the effects of an action at a particular site; exception handlers normally implemented by invoking compensating actions; contingency actions that may be introduced in case that a given transaction fails; distinction between vital and non-vital transactions. These are part of TOWE and are described in some detail in [4].

4.3. Programming of elastic transaction objects In the following we describe the programming of the activity Approval in fig.3 which is the expansion of the contractual process in fig.2. Each activity class encapsulates state and behavior describing processes. The state encompasses the data structures needed for the communication, scheduling and synchronization events that take place during the lifetime of a process object. After instantiation a process object exe-

1060-3425/98 $10.00 (c) 1998 IEEE

cutes its work routine which describes the process script, i.e., the sequence of actions it executes over its lifespan. The work statement materializes the behavioral part of a process object which provides the means to create other processes, actions, and objects at remote sites; and to request asynchronous execution of their features and to communicate with them. class FINANCE {loan, property_value, loan_acct, applict_acct} is PARALLEL with const name: STR:= "finance"; fail: BOOL:= FALSE; work is -- -- transfer loan from financial institution to applicant's acct"transfer").arg(loan_acct, applict_acct, loan); -- -- need to borrow additional funds ? borrow:REAL := property_value - loan; if borrow > 0 then -- -- conditional transaction work is SERIAL-ALTERNATIVE with -- -- name of workpackage const work-name: STR:= "fund_alternative"; -- -- hosts on which actions run hosts := "city_bank:personal_loan", "halifax:home_equity_loan";"personal_loan").arg(applict_acct, borrow);"home_equity_loan").arg(applict_acct, borrow); status("fund_alternative") := commit_depend("transfer"); if status("fund_alternative") == COMMIT then"add_contract").arg(lending_inst, customer); end(status); -- -- work

-- -- Commit dependency between actions -- -- personal loan, home_equity & money transfer need to be resolved if status("transfer") == COMMIT then status("fund_alternative") := COMMIT; else action is cancel("fund_alternative"); fail := TRUE; end; -- -- cancel if (fail) then compensate("finance"); else"assess_applict").arg(applict_acct, loan, borrow); end; -- --work end;

of a communication between two process contexts, e.g., applict_acct, borrow, are passed by reference and not by copy. The run-time system routes a client request via a proxy object to a target object that may reside in a remote address space. A proxy object is an object (similar to a client stub) that represents a server object on a client side, i.e., it runs on the same address space as the client. Class Finance is a parallel scheduler as it spawns in its work statement actions that can run concurrently. These include an instance of the class Transfer as well as the conditional activity Need_More_Funds, see fig.3. This activity is conditional because the applicant may not need a personal loan. The user-defined class Finance may thus be defined as in fig.4. Class Finance introduces a serial alternative (see Fund_Alternatives in fig.3) activity nested within the parallel activity finance. The serial alternative activity semantics specifies that either of the two activities is to succeed (in the specified sequence) for this scheduler to succeed. Notice that one may specify the sites on which the activities Personal_Loan and Home_Equity_Loan may run. The variable hosts is set to the hosts where the transaction may run. There is also a commit dependency between the activity Fund_Alternatives and Transfer. In other words the status of the activity Fund_Alternatives is forced to take the status of Transfer, i.e., they both either succeed or fail. Failure means that activity Finance must also fail. contract class MORTGAGE_LOAN {customer, lending_institution, interest_rate, fine} blocked_parameters := get_value("appraisal".lending_institution); obligation -- -- name of obligation const obligation-name: STR:= "pay_off_loan" in"approval"); blocked_parameters := get_value("open_home_loan".home_loan_acct);“pay_loan”).arg(home_loan_acct, interest_rate); changed_by"change_interest_rate").arg(interest_rate);

Figure 4. The Finance process object. Fig.4 shows the coding of the activity Finance, referred to as Organize_Finances in fig.3, and presents some of the important features of the TOWEC class library. The operations name() and arg() are used to supply the name and arguments of an action which may run at a local or remote site. The TOWEC language supports location-independent process invocation: local and remote process calls are equivalent on the syntactic level, i.e, we do not distinguish whether actions such as personal_loan and home_equity_loan are executed locally or remotely. Since processes share memory, objects that appear as parameters

violation last_payment.time + 3 months

Suggest Documents