Enforcing Business Policies through Automated Reconfigurationi L.Andrade1 , J.L.Fiadeiro1,2 and M.Wermelinger1,2
[email protected],
[email protected],
[email protected] ATX Software SA, Alameda António Sérgio 7, 1C, 2795-023 Linda-a-Velha, PORTUGAL 2 LabMAC, Dep. Informatics, Fac. Sciences, Univ. Lisbon, Campo Grande, 1749-016 Lisboa, PORTUGAL 1
Abstract In this paper, we address dynamic reconfiguration from the point of view of the enforcement of the policies that organisations wish to see imposed through the way information systems support business. We address the process of evolution by proposing a primitive – coordination context – for modelling the circumstances in which reconfiguration can and should take place. The idea is for business policies to emerge as properties of process executions when controlled through the coordination contexts that will have been defined for supporting business activities.
1. Introduction In recent papers [e.g. 2], we have argued that, in order to endow systems with the levels of agility that are required for operating in environments in which business requirements change very rapidly – which is the case of most organisations operating in the e-Economy – it is essential that the rules that determine the way the components that model basic business entities need to interact in order to fulfil these requirements, be externalised from the way these components are implemented, and given an explicit representation in architectural models of systems as connectors. The idea is to implement these connectors in ways that allow for the architecture to evolve in terms of the reconfiguration of the connectors in place without being intrusive on the code that implements the components. In this way, we can make system evolution to be directly compositional over business evolution, i.e., through the architecture, changes in the business domain can be mapped directly to the configuration of the system. For this purpose, we have proposed the extension of current conceptual modelling languages and approaches like the UML [3] with a new semantic primitive – coordination contracts – that builds on well established concepts and practices of Software Engineering, namely superposition as known for Parallel Program Design [8], coordination principles as developed in the context of Coordination Languages and Models [6], and the notion of architectural connector as developed within Software Architectures
[1,11]. This primitive has been proposed together with methodological principles [2], a mathematical semantics [4], and implementation micro-architectures that use known design patterns [7]. The use of coordination contracts for representing business rules leads to an approach to the evolution process that is based on reconfiguration techniques as known from Configurable Distributed Systems [10]. More precisely, we have shown in [12] how architectures, as graphs, can be rewritten in order to reflect changes occurring in the application domain. However, having mechanisms for evolving systems is not the same as prescribing when and how these mechanisms should be applied. Evolution is a process that is subject to rules that aim at enforcing given policies of organisations over the way they wish or are required, e.g. through legislation, to see their businesses conducted. The purpose of this paper is, precisely, to address the modelling of the evolution process. More concretely, we propose a modelling primitive – coordination contexts – through which the reconfiguration capabilities of the system can be automated, both in terms of ad-hoc services that can be invoked by authorised users, and programmed reconfigurations that allow systems to react to well identified triggers and, hence, adapt themselves to changes brought about on their state or configuration.
2. Coordination contracts Our approach provides methodological and technological support for a clear separation between the computations performed by system components and the mechanisms that coordinate their interaction. Components encapsulate collections of services that determine specific system functionalities that are made available through computations performed on local states. They correspond to “core”, “stable” business entities in the sense that they provide basic services that are likely to remain invariant throughout evolution or, at least, have a different dynamics in what concerns changes occurring at the levels of business requirements. Coordination contracts are the new semantic primitive through which we provide
i This research was partially supported by Fundação para a Ciência e Tecnologia through project POSI/32717/00 (FAST).
mechanisms for establishing interactions between components; a coordination contract is put in place among a set of components to ensure that required global properties of the system will emerge from the functionalities of the components and the interaction established between them through the contract. Coordination contracts capture more volatile aspects of the domain like the business rules that regulate the possible ways in which the system can be used. Hence, it is important that we make it possible for the system to be reconfigured in terms of revising which contracts apply to which components without interfering in the way components are implemented. The microarchitecture that we developed in [7] supports, precisely, this degree of dynamic, non-intrusive reconfiguration. A coordination contract makes available the expressive power of a connector in the terminology of software architectures. It consists of a prescription of coordination effects (the glue of the connector in the sense of [1]) that will be superposed on a collection of partners (system components) when the occurrence of one of the contract triggers is detected in the system. In the description of a contract (type), the partners are identified as class interfaces that act as types that can be instantiated with components of the system when the contract is activated on a particular configuration. We are going to illustrate our approach with a very simple example from banking. As a core concept of banking, we assume that an account offers three basic services – balance():money, credit(n:money), and debit(n:money). The methodology that we are building around coordination contracts suggests that, in order to model specific business activities that involve bank accounts, we should superpose whatever coordination mechanisms are required as external entities, rather than specialise the class with new, “hard-wired” features each time a new business rule, or changes to existing business rules, come into play. For instance, restrictions on debits should not be “hard-wired” as pre-conditions on the basic method that performs the debit but, rather, as contracts that coordinate specific interactions that involve the method. As a business activity, a withdrawal by a given customer is an operation that involves both an account and a customer, regardless of the way that the customer is represented in the system, i.e. of whether it is a software component in the information system, an interface object that captures an external agent of the system, etc. Hence, we model customers again through a class interface that is agnostic with respect to any specific form of representation and allows for such representations to evolve as new decisions are made during the lifetime of the system. In terms of our example, we assume that customer interfaces include owns(a:account):Boolean, and with-
any change on the interactions to be intrusive on the code that implements the components. The alternative that we propose through coordination contracts consists in providing an explicit representation of the interaction outside the components that can be superposed on them when needed without their knowledge Superposition imposes synchronisation points in the lives of the components involved in the contract: each trigger-reaction clause in a contract identifies a point of “rendez-vous” in which the components are brought together to synchronise their lives. In execution terms, the “rendez-vous” is seen as an indivisible, atomic action. Each partner participates in it according to what is specified in the clause. This decoupling of roles in an interaction is essential for supporting non-intrusive changes by letting the partners evolve independently. The contract that provides the standard coordination mechanism that regulates withdrawals is as follows: coordination contract standard-withdrawal partners a:account, c:customer coordination when c.withdrawal(n,a) with a.balance() n and c.owns(a) do a.debit(n); end contract
Each coordination rule identifies, under the “when” clause, a trigger to which the contract will react – a request by the customer for a withdrawal in the case at hand. The reaction to be performed to occurrences of the trigger is identified under the “do” clause – a debit for the amount and on the account identified in the trigger. Under the “with” clause, we include conditions that should be observed for the reaction to be performed. If any of the conditions fails, the reaction is not performed and the occurrence of the trigger fails. The whole interaction is handled as a single transaction, i.e. it consists of an atomic event in the sense that the trigger reports a success only if all the operations identified in the reaction execute successfully and the conditions identified under the “with” clause are satisfied. In order to illustrate how contracts can be used for supporting changes in business rules, consider the situation in which the bank decides to make a VIP-package available to selected customers through which they can use a credit-facility to overdraw designated accounts. The contract that models VIP-withdrawals can be defined as follows: coordination contract VIP-withdrawal partners a:account, c:customer attributes credit:money coordination when c.withdrawal(n,a) with a.balance()+credit n and c.owns(a) do a.debit(n); end contract
drawal(n:money,a:account).
In the traditional, object-oriented way, withdrawals are modelled by direct calls to the debit operation of the corresponding account. That is to say, as part of the design of the system, withdrawal(n,a) establishes a call a.debit(n). This form of direct invocation leads to systems in which components are too tightly coupled, making
In this contract, we have included a local attribute – credit – that takes the value that has been negotiated between the customer and the bank for overdrafts on the specific account over which the contract is superposed.
–2–
This means that the same customer may subscribe different contracts for different accounts and that different customers that own the same account can subscribe different contracts as well. In fact, we have not included in the model any information on the conditions under which a given customer can subscribe a VIP-withdrawal for a given account. This is left for the “coordination contexts” through which the management of the configuration of the system, in terms of establishing, at each state, which contracts apply to which components, is performed. The definition of such coordination contexts is, precisely, the main subject of this paper as discussed in the next section.
3. Coordination contexts In general, the evolution of the system is not the result of a completely ad-hoc process of reconfiguration. Normally, in order to enforce specific business policies of the organisation, reconfiguration steps are either programmed or take place in contexts that set constraints on the nature of the operations that can be performed on given configurations and states. Such contexts capture business activities that can be described in terms of collections of components, coordination contracts that can be superposed on them, and the rules that define the ways in which this superposition can or must take place. What we will be proposing is this section is a first step towards a primitive for modelling such coordination contexts. For instance, in the banking domain that we have been using as an example, a coordination context normally exists for each customer. The purpose of this context is to manage the relationships that the customer may hold with its various accounts according to the packages that the bank offers. Such contexts are made available to bank managers each time the customer goes to a branch, or to the customer directly through the Internet or ATMs. The syntax that we are developing for contexts can be illustrated around this example as follows: coordination context customer(c:customer) workspace component types account, customer contract types standard-withdrawal, VIPwithdrawal, pensioner-package, homeowner-package constants min-VIP: money attributes avg-balance = … services new_account(a:account): pre: not exists a post: exists’ a and c.owns(a)’ and exists’ standard-withdrawal(c,a);
subscribe_VIP(a:account,V:money): pre:
exists a and c.owns(a) and avg-balance ≥ min-VIP and not exists home-owner-package(c,a) post: exists’ VIP-withdrawal(c,a) and VIP-withdrawal(c,a)’.credit=V
subscribe_home(a:account): pre:
not exists a and not exists pensionerpackage(c) post: exists’ a and c.owns(a)’ and exists’ home-owner-package(c,a)
subscribe_pensioner: pre:
not exists pensioner-package(c) and not exists home-owner-package(c,a) post: exists’ pensioner-package(c)
rules VIP-to-std: whenexists VIP-withdrawal(c,a) and avg-balance < min-VIP postnot exists’ VIP-withdrawal(c,a) and exists’ standard-withdrawal(c,a)
end context
Besides the contracts that we introduced in the previous section for managing withdrawals, we have added the names of a few other ones just to make the example more “interesting”. These account for other financial packages such as those concerned with retirement pensions and credit for home-purchase. We leave their specification to the reader as an exercise! Each instance of a coordination context is “anchored” to a component or set of components. In the example, the anchor is a customer instance, referred to as c in the definition of the context (type). Under “workspace” we identify the component and contract types that are made available for evolving the way the anchor interacts with the rest of the system. Configuration services correspond to operations for adhoc reconfiguration, i.e. they are performed on demand from users of the system. Notice that we include in this category operations that, in traditional OO modelling, are assigned to classes like object creation. The rationale is that, by interfering with the population of the system, such operations address the evolution of its configuration and, hence, their use should be regulated in the scope of a coordination context. Configuration services involve both components and contracts. In the example above, besides the creation of new accounts, three other services are provided for each of the contracts that models a financial package that can be offered to the customer. These services have pre-conditions through which business policies are enforced. For instance, VIP-withdrawals are not available on accounts that support a home-owner package. Pensioners are not allowed to subscribe home-owner packages. Configuration rules correspond to different ways of programmed reconfiguration, i.e. to the ability of the system to reconfigure itself in reaction to external events or internal state changes. In the example above, a VIPpackage is replaced by a standard one when the average balance of the customer falls below the minimum value set up for being a VIP. Typically, the programmed configuration rules capture more dynamic properties that require specific actions to be taken in reaction to certain state changes, for instance to restore consistency with respect to policies like the ones that regulate VIP-status for customers. Notice the use of a post-condition in the configuration rule instead of a specific (trans)action to be performed as a reaction. Together with the use of pre/post-conditions in the definition of services, this allows us to separate context interfaces from their implementations, which adds to flexibility by allowing the choice of the actual reconfigu-
–3–
ration operations to depend on “lower level” issues like the physical distribution topology. The pre/postconditions capture business policies that should be elicited during analysis, like eligibility conditions as illustrated in the example, or dependencies that regulate the subscription of different business products, as well as legislation that becomes applicable, etc. When writing postconditions, we use primed expressions to denote the value that they take in the state that is obtained by executing the service or rule. Contexts should not be treated as "normal" components in the sense that they are not used in configurations to add new functionalities to the system. That is to say, they are not defined in order to contribute to the functional properties that the system can exhibit but only to manage the way the system is allowed to evolve; they model actors as in use cases, i.e. the mechanisms through which "users" (regardless of whether they are human, physical, software, etc) have access to the system, except that, now, such users can interfere with the configuration of the system, not just with its state. Indeed, although the example above does not illustrate it, contexts can also make available operations that act on the states of the components through the methods that these offer through their public interfaces. Different contexts may even make use of different implementations for the same operations, for instance reflecting the fact that access to the system may be provided through different channels. Hence, for instance, the withdrawal service of customer is typically offered in a coordination context that models access over the counter at the local branch, but not if the access is via the Internet, whereas the amount that can be requested will be limited for accesses via an ATM. From a methodological point of view, coordination contexts become necessary, and come into play, during the transition from a business model to a conceptual/logical model of the intended software system. This should be the first time in the process that a boundary starts to be drawn between the information system and the business environment, leading to the need for deciding on the interface in which this boundary will be managed. Basic reconfiguration actions like creation and deletion of component and contract instances can be formalised directly in an algebraic graph-rewriting setting, for instance using the double-pushout approach, by identifying configurations with (categorical) diagrams. More details on the graph-rewriting based operational semantics can be found in [12]. In the rest of this section, we address the relationship between coordination contexts and business policies. For simplicity, we shall take policies to be cast as properties of system configuration that are required to be invariants of the evolution process. The language that we use for representing business invariants is a first order language over the observable attributes of components (methods that return values) extended with a predicate exists that indicates whether a given component or contract instance is part of the current configuration, i.e. of the subsystem defined by the context.
Examples of business policies expressed in this language are “forall a:account, not (exists VIP(c,a) and exists home-owner(c,a))” and “forall a:account, not (exists home-owner(c,a) and exists pensioner(c))”. Both these properties can be proved to be invariants for the coordination context that we defined above. Once a property is proved to be an invariant of every coordination context defined for the application, it will be an invariant for the whole system, meaning that it will emerge as a property of every configuration that can be reached during the evolution of the system. Work on the methodology that supports the definition of policies and contexts is progressing, mainly through the application of the approach to a number of test cases [e.g. 9]. Even at this early stage, it is clear that coordination contexts provide an effective means of defining the way in which the evolution process can be controlled and the enforcement of business policies automated. We are now extending tool-support [7] and logical analysis [5] to this particular activity.
4
References
1. R.Allen and D.Garlan, "A Formal Basis for Architectural Connectors", ACM TOSEM, 6(3), 1997, 213-249. 2. L.F.Andrade and J.L.Fiadeiro, "Interconnecting Objects via Contracts", in UML – Beyond the Standard, R.France and B.Rumpe (eds), LNCS 1723, Springer 1999, 566-583. 3. G.Booch, J.Rumbaugh and I.Jacobson, The Unified Modeling Language User Guide, Addison-Wesley 1998. 4. J.L.Fiadeiro and A.Lopes, "Semantics of Architectural Connectors", in TAPSOFT'97, LNCS 1214, Springer-Verlag 1997, 505-519. 5. J.L.Fiadeiro, N.Martí-Oliet, T.Maibaum, J.Meseguer and I. Pita,, “Towards a Verification Logic for Rewriting Logic", in Recent Trends in Algebraic Development Techniques, D.Bert and C.Choppy (eds), LNCS 1827, Springer 2000, 438-458. 6. D.Gelernter and N.Carriero, "Coordination Languages and their Significance", CACM 35, 2, pp. 97-107, 1992. 7. J.Gouveia, G.Koutsoukos, L.Andrade and J.Fiadeiro, “Tool Support for Coordination-Based Software Evolution", in Technology of Object-Oriented Languages and Systems – TOOLS 38, W.Pree (ed), IEEE Press 2001, 184-196. 8. S.Katz, "A Superimposition Control Construct for Distributed Systems", ACM TOPLAS 15(2), 1993, 337-356. 9. G.Koutsoukos, J.Gouveia, L.Andrade and J.L.Fiadeiro, “Managing Evolution in Telecommunications Systems”, in Proc. IFIP Working Conference on Distributed Applications and Interoperable Systems, Kluwer, in print 10. J.Magee and J.Kramer, "Dynamic Structure in Software Architectures", in 4th Symp. on Foundations of Software Engineering, ACM Press 1996, 3-14. 11. D.Perry and A.Wolf, "Foundations for the Study of Software Architectures", ACM SIGSOFT Software Engineering Notes 17(4), 1992, 40-52. 12. M.Wermelinger, A.Lopes and J.L.Fiadeiro, "A Graph Based Architectural (Re)configuration Language", in Software Engineering – ESEC/FSE’01, ACM Press 2001, 21-32.
–4–
