Fusion: A System For Business Users To Manage Program Variability

570

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING,

VOL. 31,

NO. 7, JULY 2005

Fusion: A System For Business Users To Manage Program Variability Sam Weber, Hoi Chan, Lou Degenaro, Judah Diament, Achille Fokoue-Nkoutche, and Isabelle Rouvellou Abstract—In order to make software components more flexible and reusable, it is desirable to provide business users with facilities to assemble and control them without their needing programming knowledge. This paper describes a fully functional prototype middleware system where variability is externalized so that core applications need not be altered for anticipated changes. In this system, application behavior modification is fast and easy, making this middleware suitable for frequently changing programs. Index Terms—Web site management/development tools, middleware/business logic, specialized application languages, domainspecific architectures, human factors in software design, user interfaces.

æ 1

INTRODUCTION

O

NE side-effect of the World-Wide-Web is that companies expect their web applications to undergo modifications at a rate that would generally have been considered unthinkable for mainframe applications. Furthermore, even short periods of downtime can cause significant losses. A major source of Web application flux is the changing of “business rules.” Business rules [1] describe a company’s policies and procedures. For example, a mortgage company will have a business rule describing under which circumstances an application needs special approval, and other companies will have policies and, therefore, rules, about how long after purchase a product can be returned.1 Business rules can change frequently, and are usually determined by nontechnical staff or by law. Rules are often unexpectedly complex and made without consideration of the impact upon application programmers. It is therefore highly desirable to insulate applications from business rule changes, and to allow such changes to be made and managed easily. The reverse also holds: when the application undergoes modification, we want the impact upon the business rule logic to be minimal and easily managed. A core philosophy of ours, and one that distinguishes us from others, is that application and business rule modifications are expected, not exceptional.

1. The term “business rule” is standard in the literature, despite the unfortunate possibility of confusion with Artificial Intelligence rule processing. As will be described later on, it is arguable whether there is any nonsuperficial connection between the two areas.

. The authors are with IBM’s T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598. E-mail: [email protected], {hychan, degenaro, djudah, achille, rouvellou}@us.ibm.com. Manuscript received 8 Dec. 2004; revised 4 Apr. 2005; accepted 21 June 2005; published online 26 July 2005. Recommended for acceptance by W. Frakes and K. Kang. For information on obtaining reprints of this article, please send e-mail to: [email protected], and reference IEEECS Log Number TSESI-0275-1204. 0098-5589/05/$20.00 ß 2005 IEEE

One of the obstacles to business rule technology adoption lies in the communication barrier between the people who decide business rule changes (usually marketing, legal and human resource staff) and those usually responsible for implementing such changes (programmers). Business people often conceptualize their company’s operations very differently from programmers, and they find that explaining desired changes to technical people is frequently time-consuming and error-prone. For this reason, there is a strong desire to have business rules expressed in a way that is accessible and approachable to nontechnical users. The Fusion project’s aim was to produce middleware and supporting tools for business-rule processing. During this work, we conducted numerous engagements with various companies to determine and refine our goals and priorities. Ultimately, our priorities, and the focus of this paper, were: to allow applications to efficiently invoke reusable business rule logic, with minimal programmer effort, . to allow the program variability caused by business rule changes to be planned and efficiently managed, and . to allow business-oriented people to manipulate the system using terminology and processes appropriate for them. In the following section, we will describe our methodology. Our major design challenges will be described in Section 3. In Section 4, we describe our overall architecture. In Sections 5, 6, 7, and 8, we describe, in detail, the major Fusion components. We identify remaining outstanding issues and interesting future research directions in Section 9. After reviewing related products and research activities in Section 10, we conclude in Section 11. .

2

METHODOLOGY

Previous work [2] by two of the coauthors (Degenaro and Rouvellou) resulted in a commercial product: the BRBeans Published by the IEEE Computer Society

WEBER ET AL.: FUSION: A SYSTEM FOR BUSINESS USERS TO MANAGE PROGRAM VARIABILITY

middleware, sold as part of IBM’s WebSphere Server Enterprise Edition. BRBeans provided basic support for application customization by allowing variable logic (expressed in Java) to be changed and managed independently of the application. It was used both as an end-user product and as infrastructure for other projects. Feedback indicated that there was significant market need for a system that better enabled business rule management and use. The Fusion project was started to address the necessary research issues. Over the course of the BRBeans and Fusion projects, more than 30 companies were consulted. These companies were concentrated in the banking and insurance industries, and the scope of these engagements ranged from severalhour-long meetings to several-month-long intensive interactions. We observed that business processes, training, and development assumptions varied widely between companies. Whereas some companies were only interested in products that could be deployed “out-of-the-box,” complete with all necessary tools, others actively refused to consider such products. The latter organizations had created a unified “look-and-feel” for their software, including their internal applications and, therefore, insisted on developing all tooling themselves to ensure compliance. Also, some companies assumed that all their business users would be able to program spreadsheets, or to demonstrate the equivalent computational ability, while others felt that their business users could not be expected to undertake such tasks, or any others requiring formal reasoning. We also observed that nontechnical users, more so than developers, were often reluctant to state that anything perceived as a potential feature was undesirable or not important. After our customer consultations, we attempted to prioritize our requirements. We found, however, that the disparity among our user community meant that we could not reliably do so. We responded to this problem by adopting a strategy of successive iteration. We implemented a complete executing system, including both developer and end-user tooling, with basic functionality. Thereafter, we engaged in successive rounds of refinement, always maintaining a complete executing system. This approach proved to have a number of advantages, some unanticipated. A running system proved to clarify the trade-offs between user groups, which allowed us then to resolve further requirement priorities. Also, as expected, building a complete system revealed unanticipated issues. The disadvantages of this process should not be overlooked, however. In particular, components that were subject to frequent and large changes experienced a certain amount of “code-rot.” We mitigated this by enforcing the general policy of making sure that the back-end components were ahead of, and more general than, the front-end components. In the next section, we will describe the core issues and design choices that shaped our overall architecture.

3

MAJOR DESIGN ISSUES

Two major design choices determined Fusion’s overall architecture. The first concerned how the business rules

571

should be integrated with applications, while the other concerned how business rules should be expressed and implemented.

3.1 Externalization As stated before, one of Fusion’s primary goals was to isolate applications from business rule variability and viceversa. As managing variability and code reuse have been concerns since the early days of the industry, there are many techniques available for addressing such problems, including object-oriented techniques, various design patterns, and so forth. Unfortunately, both details about the Web application environment and practical business rule concerns impose constraints that render most of these techniques ineffective. The performance of Web application servers is extremely dependent upon the size (in bytes) of the data structures maintained by the applications it runs. This is because http (the protocol underlying the World-Wide-Web) is stateless and, so, the server has to maintain in memory the application state for every user currently interacting with the application. The size of this application state determines how many users can be simultaneously using the application without the system performance degrading sharply and drastically because it is forced to move user state to secondary storage. Unfortunately, business rule changes often impact what data is needed for the computation (for example, giving a discount formerly available to all customers only to “gold” customers requires the introduction of customer status information) and, thus, globally impacts the application performance. Although some performance cost is inevitable (after all, the computation has to be performed somehow), this cost should only be incurred when and if the new business rule is used, not pervasively through the system as a whole. This complements the standard practice of Web application designers who attempt to only perform potentially expensive operations when users will tolerate delays. Most variabilityhandling techniques do not control for this issue and, thus, could not be used by us. Another important constraint was imposed by the nature of business rules themselves. As they are decided upon by legal or marketing staff, new rules almost always must take effect instantaneously at some real-world time, such as the start of the new tax year, or the Thanksgiving weekend. It would be highly undesirable if the process of updating a business rule made the application unavailable, especially as rule changes frequently correspond to peak usage times, as application users attempt to take advantage of the old or new rules. This need for dynamic updates contrasts with the the norm for application feature updates or bug-fixes, which are typically done by reinstalling the application during a low-usage period. Once again, this need for dynamic updates proved to restrict our design options. The design that best fit our constraints made use of the externalization pattern: We mutually isolated the application and the business rule processing by physically isolating them into separate address spaces (in typical deployments, separate machines). In order to use Fusion, application developers identify the points in their application (the “points of variability”)

572


where business rules might need to be consulted. At each of these locations, they insert a triggerpoint: a line of code that invokes Fusion. Each triggerpoint is supplied the necessary arguments to determine which business rules should be invoked and the necessary data for the rule engine to perform the necessary computation. (The details of this will be described later.) For example, a shopping application might invoke a triggerpoint to determine discounts, and this triggerpoint might reasonably need the customer’s id number and current shopping cart as arguments. A triggerpoint will do a remote invocation to the Fusion server, and return the results to the application. The intended semantics of a triggerpoint invocation is that of a side-effect-free query: An invocation is expected to return a result but not mutate any globally observable state. (A business rule might invoke application code, and it is impossible for Fusion to prevent this code from performing a database write, send e-mail, or other such operation, but we strongly discourage programmers from doing so.) This provides an easily understood programming model to the application developer. Additionally, it avoids a serious source of application/business-rule interaction: transaction contexts. If a triggerpoint is invoked within a transaction context, then any side-effects performed by business rule invocations would have to be unwound if the transaction aborted. Correctly handling this would require application developers and business rule writers to know details about each other’s transactional assumptions, defeating our goal of isolation. Since with externalization the data structures needed by the business rule logic are confined to a separate address space than the Web application per se, the impact of changes to these data structures are felt only when processing business rules. The details of how business rule updates are performed will be described in Section 6, but conceptually externalization simplifies this process because the system can ensure that references to potentially outdated data-structures cannot escape into application code. Externalization does offer other significant advantages. First, multiple applications can make use of the same Fusion server, allowing the same business rules to be reused between applications. This architecture also allows easy migration of existing applications into Fusion use—triggerpoints can be incrementally added to a legacy application. In many cases, externalization has the potential of improving performance. This is because a major factor of Web application server performance is cache effectiveness. Business rule processing usually involves a different data set than other application components and, so, isolating said computation allows the system to cache better.

3.2 Business Rule Language Our second major design issue revolved around what business rule language (and associated object model) Fusion should use. A number of different approaches have been tried by previous work in the area. These approaches can be seen to be making a trade-off between business user accessibility and application performance/integration, with the various options chosen being:

VOL. 31,

NO. 7, JULY 2005

Business rules are expressed in the same language as the application. 2. Business rules are expressed in a language tailored toward business users, with its own object model. The application has to interpret these objects. 3. Business rules are expressed in a custom language, but operate on the same objects as used by the application. 4. Business rules are expressed in a custom language, using only simple data types (usually just strings and numerical values). Clearly, the first choice eases integrating business rules into an application. Unfortunately, two serious problems arise. First, application classes are rarely suitable for use by business users: They use null values as indicators for special values, raise exceptions, and have various side-effects, all of which nonprogrammers have difficulties with. Application classes also are structured in a way that reflects the application’s internal architecture, making explicit details about such things as data persistence. For example, often applications represent customers simply as their id numbers and require the use of a suite of static methods to retrieve customer information. This rarely corresponds to the mental model of a marketing representative or lawyer. Second, there is no isolation between the application and the business rules: when the application data structures change, so do the business rules, and when a business rule change needs additional data to be available, the application has to be changed accordingly. The second choice seems to be ideal from the business user viewpoint: rules can be expressed in a manner that suits the way that they think about their work. Unfortunately, in practice, this is not so clear-cut: People in both different companies and different job roles within the same company often have very different ways of viewing the same entities. A general-purpose solution is necessarily forced to make compromises between user groups. Additionally, the burden of this approach falls heavily upon the application developer and the system maintainer. In order to invoke business rules, the application must create the required business objects, call the rule engine, and then translate the resulting objects back into its own data structures. The code to do these creation and translation steps is not only burdensome to the developer, but expensive and, therefore, degrades application performance. In order to prevent unnecessary data retrieval and copying operations, the application developer’s temptation is to apply pressure to keep the business object model minimal. The result of this, however, is that business rules are more likely to need additional functionality in the future, requiring modification of the business object model and, in turn, the business-rule/application adapter code. The third choice eases the integration between application and business rule engine, by making both use the same objects. This faces the same problem as the first solution: Often application objects are unsuitable for use by nonprogrammers. In addition, since the application objects are written in a different language than the rules, there is the problem of the semantic mismatch between the two languages. As an example of this, the Quickrules 1.


573

Fig. 1. Fusion System—Runtime.

product [3] allows Java methods to be invoked. However, it is possible, in general, for a Java method to mutate an arbitrary number of other objects currently being used by Quickrule’s engine, and users have to explicitly instruct the engine whether this possibility should be taken into account—a decision that is hard for nonexperts to comprehend or make. This fundamental semantic problem seems to be inescapable. By keeping the data model trivial, the last choice keeps application developers from having to write adapters. Additionally, the simplicity of this model can make it easy for nonprogrammers to deal with. The drawback is obvious: The power of the business rules is severely reduced. In practice, systems that take this approach allow business rules to do operations like directly accessing databases —increasing the system’s power at the cost of making the database schema visible to the business rule author, or require the use of programmers whenever the simple data model fails. The Fusion team felt that none of these four alternatives would allow us to meet our goals. Instead, we embarked upon a fifth, novel, approach. We observed that the benefits of a business-user-centric model occur only at business-rule development time, while at runtime using only application classes is clearly optimal. Therefore, Fusion allows nontechnical users to write business rules in a reasonably suitable language which will be compiled into Java before execution. Instead of forcing business users to use object models created for use by programmers, or trivial data types, we decided to allow users to users to construct object models of business entities, called resources, which correspond closely to their mental models. In other words, we provide tools by which a customized vocabulary can be constructed, suited for the particular needs of the customer. Naturally, this approach does pose significant challenges. Fusion has to maintain enough information to be able to translate references to resource instances into Java code referring to application objects, and to do so in a way that is not unduly burdensome to its users. Additionally, we want to maximize the ability of the resources to be customized to suit their users’ needs.

4

FUSION COMPONENTS

In this section, we will describe Fusion’s overall architecture. For clarity, we will first consider the system at runtime and then consider the design-time components and tools. For illustrative purposes, we will use a running example: The fictional company “Aardvarks ‘R’ Us” has a Website whereby customers can place orders. Text describing this example will be set-off from the regular text, as done here.

4.1 Runtime Fig. 1 shows Fusion’s runtime architecture. It shows a typical configuration where all the Fusion runtime components (except the stub code) are colocated and deployed upon one or more servers. (Since Fusion is implemented using standard J2EE [4] technology, individual system maintainers are able to partition and replicate the various components among the available hardware resources as appropriate considering the particular site’s needs.) The dashed arrows show the flow-of-control of an application’s business rule invocation, while the thick arrows show the flow-of-control of a dynamic update. Designers of Fusion-enabled applications identify points of variability in their programs, where business rules may need to be invoked. At these points, they invoke triggerpoints, which are contained in the Fusion stub code. The stub code was generated by the Fusion tools. Each triggerpoint is named appropriately, describing the desired rule functionality, and is passed application data structures as arguments. The Aardvarks ’R’ Us Website is a standard J2EE application. It contains data structures representing customers, orders and lines of the order. Fig. 2 shows relevant portions of these data structures. Notice that the Customer class is quite trivial, only containing the person’s id number and a name (to be shown on the screen). This is because Web-apps, for performance reasons, are written to use as little memory as possible, and the id and name are all that are necessary for the

574


VOL. 31,

NO. 7, JULY 2005

Fig. 2. Aardvark’s ‘R’ Us Java classes.

presentation layer to display properly and to make backend requests. At one program point, the application wants to compute the current discount that should be applied to the customer’s order. This is done via the following invocation: discount = Fusion.computeDiscount(customer, order); In this case, the current time is an implicit argument to the triggerpoint. At a second program point, tax has to be computed. Since the tax rate depends upon geographic region, the order’s location is passed to the triggerpoint. Taxes also depend upon the effective date of the order (not the current time) and, so, this is also an argument. discount = Fusion.computeTax(effectiveDate, location,order); The Fusion triggerpoint mechanism is designed to have a minimal impact upon the Web-app programmers: They merely add a short invocation at each point of variability. The Fusion stub code invokes the scheduler component. The scheduler acts as a generalized look-up table, using the triggerpoint parameters to determine which logic should be invoked to process the invocation. The logic itself is executed by the execution engine. Aardvarks ‘R’ Us has had, over time, a number of promotions and plans still more. When the computeDiscount triggerpoint is invoked, the scheduler uses the current time to decide which logic should be used: during December 2005 it will use the “Holiday05” logic, at all other times since February 2005 it will use the “ValuableCustomerDiscount” logic (which gives certain

customers a 5 percent discount) and, before February 2005, the “legacyDiscount” logic (which is the discount code written before Fusion became available). The scheduling for the computeTax triggerpoint is more complicated. Since different countries, provinces and states do not change their tax rates simultaneously, the Aardvarks ‘R’ Us staff have set up the scheduler to first use the geographic location and then, secondarily, the date to determine the correct tax computation to perform. In the simplest case, the logic executed by the rule engine, as directed by the scheduler, consists of a single node: A computation which takes specified inputs and returns specified outputs. Commonly, a node will consist of compiled Java code that was automatically generated by the Fusion development tools. However, the execution engine is extensible, and a node could also consist of programmer-written Java code, a script that should be run by a specified interpreter, or many other possibilities. More generally, nodes can be arranged into flows: a data flow network of nodes. The scheduler associates triggerpoint invocations to flows, and the same node can be reused by multiple triggerpoints. The “Holiday05” logic and the “ValuableCustomerDiscount” logic both are trivial flows of one node a piece, both of them automatically generated Java classes. The “legacyDiscount” logic consists of a single node which invokes the legacy Java code that was written before the Web application began to use Fusion. The computeTax logic is more complicated. Every Canadian customer has to pay both federal and provincial sales tax and, therefore, the logic for each province consists of three (simple) nodes: A node to determine the specific province’s tax rate, a node to compute the federal tax, and a node to sum the two. The


575

Fig. 3. Fusion System—Design Time.

latter two nodes are shared among all of the flows: There is no need to implement the federal tax rate logic more than once. The execution engine executes nodes and flows in parallel: many concurrent threads can invoke the same triggerpoint, or triggerpoints whose associated flows share the same node, simultaneously without blocking. Updates to the Fusion runtime state are encapsulated into update files. These files describe changes to both the scheduler state (the associations between triggerpoints and execution engine flows) and the engine state (the engines flows and nodes). The deployment manager processes an update by first checking that, if the update were to be applied, the resulting state would be consistent: No flows refer to nonexistent nodes, no triggerpoint is associated with a nonexistent flow, every flow takes the correct number and type of inputs, and returns the correct number and type of outputs, etc. If these checks succeed, then the update is made in a transactionalized fashion: each triggerpoint invocation that is being processed while the update is being performed will be executed as if that invocation were performed entirely before or after the update operation. How business rules are developed and maintained will now be described.

4.2 Design-Time Fig. 3 shows the major Fusion design-time tools and data, and their relationships. The rectangles represent tools or components, and the ovals represent data objects. The scheduling tool modifies the scheduler’s relationship between triggerpoints and flows. Fig. 4 is a picture of our prototype’s scheduling tool. As stated above, execution engine nodes can consist of logic authored by non-Fusion tools: custom Java code, interpreter scripts, etc. Nodes of these types can be incorporated into update files in a fairly trivial process. One of the main goals of Fusion, however, is the ability for nonprogrammers to author business rule logic in a fashion appropriate to them. This process has three steps. First, a set of resources is constructed, which describe the various entities to be manipulated by business rules (such as customers and orders) in a fashion that corresponds

closely to the manner that the nonprogrammers think of them. Second, rulesets (groups of business rules) are authored that use these resources. Finally, these rulesets are compiled into Java code and inserted into an update file. We’ll now describe this process in more detail. Recall that at runtime, triggerpoints are passed application objects representing the entities that the business rules will manipulate. As these objects were written in Java by programmers for use by the application, it is highly unlikely that these objects are usable as-is by marketing people. Therefore, the development staff in association with the business staff use a resource tool to generate a set of resource definitions: a simple object model of the business entities. This model does not support inheritance, the names of methods and fields can consist of arbitrary naturallanguage text, and method arguments can be infixed. The Java code from Fig. 2 is clearly unsuitable for use by the company’s nontechnical staff. Therefore, the staff has constructed a more appropriate model, part of which is displayed in a prototype navigator in Fig. 5. Notice, for example, that a “make effective as of now” method has been added to the Order object and a “has good credit?” method has been added to the Customer

Fig. 4. Ruleset scheduling tool.

576


Fig. 5. Example resources.

object. Both of those methods are of use to business users, although they were not present in the original Java objects (presumably because they were not needed for the core application). On the other hand, methods or attributes in the original Java objects that were irrelevant in the business world (e.g., session id) have been removed. Finally, note that the method names are more readable since they do not have to correspond to Java’s naming system. Of course, it is not sufficient to merely produce the resource definitions—these objects must be implemented somehow. The resource mapping information states how the resource attributes should be implemented in terms of the original application’s Java objects. Once resources have been created, there are a number of possible ways in which Fusion rulesets can be authored.

Fig. 6. Prototype calliope editor.

VOL. 31,

NO. 7, JULY 2005

Fusion defines a language, called Calliope, with which resources can be manipulated to implement business rules. A Calliope ruleset is a self-contained logical unit that takes inputs and produces outputs. Calliope is designed to be quite expressive, but to still avoid situations that nonprogrammers find difficult to understand and cope with. A prototype Calliope editor is shown in Fig. 6. This editor allows users to drag-and-drop resource members in order to ease rule construction. Calliope is deliberately targeted toward nontechnical users with more than average programming skills, and therefore we offer two other means of creating Calliope rulesets, for other audiences. First, we provide an API for manipulating Calliope rulesets, in order to facilitate creation of custom GUIs for Calliope subsets. Second, we offer template functionality, which allows users constrained, but still nontrivial, ability to create, destroy, and reconfigure rules within the limits set by a programmer. In Fig. 7, we show a prototype template tool. Regardless of how Calliope rulesets are generated, Fusion provides a compiler which translates each ruleset into a Java class that, in turn, will be used by the execution engine as a node. The compiler consults the resource mapping information to determine how each reference to a resource member should be implemented. Recall that one of Fusion’s core assumptions is that application modification is expected, not exceptional. A business rule modification can be handled by implementing the new rule, deploying it onto the server, and then scheduling it to take place at the appropriate time. It is also possible for the application itself to be modified. Usually such changes do not affect the business rule processing, but occasionally the data structures representing entities manipulated by the business users will be changed. Since the Fusion runtime directly manipulates these data structures, the execution engine’s nodes will have to be correspondingly updated.


577

Fig. 7. Prototype template authoring tool.

The first step in handling these changes is detection of a possible problem. The resource mapping information describes the dependencies upon the application classes. This information was designed to enable the infrastructure to cope with the changes in the application classes. When any classes used by the mapping information change, they can be compared against their former state. If an inconsistency is found (for example, a method now takes a different number or types of arguments) then developers can be alerted and given a problem description. Finally, the affected rule sets are recompiled and redeployed on the server. (Note that this process is currently not automated in our prototype.) At this point, we will now describe the major aspects of Fusion in detail.

5

SCHEDULER

As described previously, the major purpose of the scheduler component is to associate triggerpoint invocations with execution engine flows, according to specified criteria. Additionally, its associated design-time tooling creates the application’s stub code. At first glance, the scheduler’s functionality might seem to be redundant: Fusion possesses an execution engine capable of executing arbitrary logic, and it would be possible to perform scheduling using the engine rather than having a separate component. However, we maintain that doing so would make it harder to manage variability and harder for nonprogrammers to manage the system and, thus, poorly satisfy our design goals. Consider our previous example of scheduling the computeTax triggerpoint according to both time and geographical location. This scheduling is not fictional—it is one of the common situations faced by one of the companies that we interviewed. Notice that the computeTax logic, if considered as a single unit, is subject to extreme flux: It is changed whenever any region in any country

changes its policies, and frequently multiple regions will simultaneously be modified. This flux increases the likelihood of omitted updates and regression errors. Separating the logic allows users to more easily verify that the appropriate updates were made and that no other regions were affected. In general, we maintain that by partitioning business rule logic into smaller fragments, we increase the reuse potential and restrict variability into more easily manageable units. The scheduling component also makes managing business rules easier for nontechnical users. We observed that all triggerpoints must undergo a scheduling phase, if only to determine the current business rule version. Selection is an easier concept to understand and explain to users than general-purpose logic and, therefore, by separating scheduling from logic execution we increase Fusion’s accessibility to nonprogrammers. Each triggerpoint can have an arbitrary number of arguments to be used for selection, each one being a string, date, or numeric value. The scheduler uses a general and flexible system for determining for each triggerpoint invocation, which flow the execution engine should run based upon the selection arguments. Say that a certain triggerpoint t can be associated with flows f1 ; f2 ; . . . ; fn . Flow fi will have a higher priority than fj if i < j. Each flow has associated with it a set of logical conditions. A condition consists of a set of equality comparisons (“does argument x equal the constant value v?”) to be applied to a subset of the triggerpoint arguments, and . a set of range comparisons (“is argument x between the constant values u and v?”) to be applied to a subset of the triggerpoint arguments. When triggerpoint t is invoked, flow fi is selected if it is the highest-priority flow which has one of its conditions satisfied by the actual selection arguments to the triggerpoint. Using this mechanism, quite general selection criteria .

578


VOL. 31,

NO. 7, JULY 2005

Fig. 8. Fusion execution engine nodes and flows.

can be specified easily and efficiently. The tooling ensures at development-time that every triggerpoint invocation will be handled by some flow.

6

EXECUTION ENGINE

AND

DEPLOYMENT

We will now describe the design and implementation of Fusion’s execution engine. Many aspects of this engine concern correctness when dynamic updates are performed and, so, the deployment manager is described here as well.

6.1 Design Fusion’s execution engine is designed to efficiently, reliably and concurrently execute triggerpoint invocations. Additionally, it supports updates to its state while it is actively processing, ensuring that all clients observe a consistent system view. We expect that most Fusion customers have some legacy code used to implement business rules. We wish to allow them to gracefully migrate to Fusion by supporting the reuse and execution of this code. Additionally, in any programming system, there is an intrinsic trade-off between usability and expressive power: There will always be some functionality that cannot be implemented without significantly decreasing usability. Therefore, we have to expect that some business rule logic will have to be authored by programmers using Java or some other programming language. For these reasons, the execution engine is not specifically tuned toward executing our own tool-generated logic. Instead, it is designed to be general-purpose, with a plug-in mechanism so that it can support different interpreters or execution environments. Furthermore, nonFusion authored logic is given a first-class status: There are no operations or functionality that is only accessible to Fusion-generated code.

A general principle in handling variability is to isolate and limit it as much as possible: The smaller the affected code and the fewer implicit interconnections between it and other components, the less likely for mistakes or unexpected side-effects to occur. Allowing logic to be built up from small units also encourages reuse, as it is more likely that commonality can be discovered and taken advantage of. These considerations led us to decide that the execution engine will support logic implemented as small computational units (nodes), interconnected by data-flows.

6.2 Implementation Details As stated above, Fusion’s runtime engine’s basic unit of computation is the node. A node is just an object which, when invoked with a certain number of inputs, produces a certain number of outputs. Nodes are organized into flows, as shown in Fig. 8. A flow is a set of nodes connected acyclically: It must be possible to execute each node sequentially so that the input of each node comes from either the flow’s inputs or from the output of a previously executed node. (A flow’s execution sequence is precomputed during deployment, for efficiency.) A node can appear in more than one flow, allowing the reuse of common logic. Flows can contain smaller flows, which also can be shared. Although usually a node is implemented by Java code, it is important to support logic written using other engines and languages. Therefore, Fusion’s runtime engine supports a plugin mechanism. Each node states which plugin supports it. (“Java” is a built-in plugin as is “ABLE”, which supports the ABLE [5] inference engine.) Each plugin states .

What data is needed for the node to be created. (For Java, this is the class and method names. A plugin for a scripting language might take either text or a sequence of bytecodes.)


A verification method, which is used to check that all its nodes have been properly created, so that errors like missing classes can be caught when the system is started, and . If the plugin itself needs any initialization to be done before execution of any of its nodes. (This is a common interpreter requirement.) Since reliability is critical, each node and flow’s inputs and outputs are typed. It is not possible to construct a flow which would violate Java’s type system. Optionally, type checks are also performed at runtime to ensure that no node returns an object of a different type than it stated it would. In order to be efficient, each node can be instantiated multiple times, and node instances are cached. In this way, triggerpoint invocations will rarely require new node instances to be created. An important consideration is how to deal with system updates that occur while the system is running. We recommend and expect that newly introduced flows and nodes will be scheduled by the selector to take effect in the future, so it will be rare that an update will affect any currently running flows. However, in the event that such an update does happen, we enforce the rule that any triggerpoint invocation must be evaluated as if it occurred entirely before or after any updates. In other words, updates are transactionalized. The effect of this is that when the system is being updated, no intermediate states or strange behavior will be observable by the Web application. Since update events will be extremely rare as compared to triggerpoint invocations, for reasons of efficiency we use an optimistic algorithm which does minimal locking in the expected case. The engine maintains an always-increasing count of the number of updates that have been processed so far. The algorithm for flow invocation is: .

1. 2.

Check the current update number, atomically. See if instances of the correct flow and its nodes are in the cache. If so,

check if they were instantiated with the current update number. If so, begin flow execution. If not, flush the cache. 3. If the flow and node were not found in the cache, or were outdated, then create new instances. This process fetches flow and node data from a database, and requires consulting the appropriate plugins. We do not lock the database during this step. 4. Recheck the update number. If the update number has changed since the first check, an update must have either occurred or be in progress. In this case, the instances we have obtained might be inconsistent, so we throw them away, wait until the update completes, then retry. In this way, our transactionality requirements impose a minimal overhead when no system updates are in progress. As described above, care is taken when an update is performed upon a running Fusion system to ensure that any concurrent computation is performed correctly. In addition, numerous checks are performed to ensure that the deployment file was not corrupted, or that it was built assuming a different state than that existing on the target system. Checks that are done include ensuring that: .

579

The classes of any node and flow inputs and outputs exist and are loadable on the target system. . Any flows contained in the update are correctly sequenced (that is, no node takes as input a value that was not previously computed or supplied). . All flows are correctly typed (that is, any value used as an input to a node must be of a compatible type) . If a node is changed that is used by any flows already existing on the system, then the new version is still compatible with those flows. . If a flow is removed, then it must not be used by any selector or by any other flow. . If a node is removed, then it must not be used by any flow. If any of these checks fail, the deployment process is rolledback, leaving the system state unchanged. .

7

RESOURCE

AND

LANGUAGE DESIGN

A major portion of the Fusion project was devoted to investigating how to implement business rules so that nonprogrammers would be able to author and manipulate them effectively. This work had two facets: the model and features that we would present to business users and the manner in which this would be implemented. Although the business user functionality was limited by the need to be implementable, for clarity we will discuss the facets separately—the business-user model in this section and the implementation in the next.

7.1 Major Design Decisions As explained in Section 3, we decided to allow users to create customized object models, “resources,” representing the entities which business rules will manipulate and refer to. Business rules will be written in a custom language, Calliope, that uses these resources, and the rules will be compiled into Java for execution. Naturally, in order to do this we had to not only determine the capabilities that will be provided to resources, but also design an appropriate business rule language. As we have previously observed, the expected abilities of nontechnical people varied widely between organizations. Although a significant percentage of those interviewed felt that their business staff would be able to understand and author logic equivalent in difficulty to basic spreadsheets, an equally significant number felt that their staff would be unable to author any nontrivial logic themselves, but would merely be able to modify parameters of pre-existing rules. In order to satisfy these diverse needs, we decided to target Calliope toward the more skilled business users, but provide two mechanisms for supporting others: .

.

a “template” mechanism, which provides users a limited, but still nontrivial ability to manipulate Calliope rulesets in a safe fashion, and an API for creating graphical editors for Calliope subsets. Any such editor would be compatible with our Calliope compiler.

580


7.2 Resource Details Resources are Calliope’s basic types. Resources that correspond to strings and numbers are predefined. All others represent business entities and are created by development staff using our resource tooling. Resources present a simple object model to users, with resources being able to possess both fields and methods, but do not support inheritance or exceptions. The names of resources and members are arbitrary, unlike Java: “The next business day” is a perfectly legal method name. Method arguments can be infixed, so that “Cancel orders pending more than _ days” is a legal name, where “_” represents an argument. Commonly, users have to refer to groups of objects (the customers whose accounts are in default, for instance). Therefore, besides resources, Calliope’s type system includes collections. Collections are multisets of instances of a single resource. That is, all elements of the collection have to be of the same resource, the same value can appear more than once, and collections are unordered. Collections can be method arguments, return values or field values. However, you cannot have collections of collections—we found that recursive definitions quickly became confusing. Also, unlike languages like Java which have reference types, all collections are independent: If x and y are both collections of Customers, then changes to x cannot affect y. The fact that resources do not support inheritance might be surprising to programmers. In programming languages, inheritance commonly serves two purposes: as a mechanism for code reuse and as a way of specifying subsumption (sometimes known as the is-a relationship). Since business users do not implement resources, the former use is irrelevant here. As for subsumption, we found that although upcasting (saying that a Manager is-a Employee) was easy to explain to our users, the reverse operation, downcasting, was not. 7.3 Calliope Initially, when designing our business rule language, we anticipated supporting inference. We found, however, that the customers we interacted with universally rejected this, on the grounds that results obtained by inference are not necessarily repeatable. For this reason, Calliope is strictly procedural. A precise Calliope specification has been written. Since we anticipate that all Calliope editors will be graphical, this specification describes Calliope’s abstract syntax tree and detailed semantics, but does not define a textual form. Unfortunately, due to space-limitations, we are unable to present Calliope’s AST here. The basic structure of a Calliope ruleset is simple: A ruleset consists of a set of typed inputs, a set of typed outputs, and an ordered set of rules. The rules are executed in order, resulting in the outputs being given values. Calliope supports nontrivial computation. In particular, in Calliope one can: . . .

evaluate expressions, with the expected arithmetic and logical operations; set and get fields of resource instances; invoke methods of objects, providing objects and expressions as arguments;

VOL. 31,

NO. 7, JULY 2005

evaluate conditionals (if-then-else’s); iterate over collections, doing operations on each element; . provide a property, and find any elements of a collection with that property. More controversial is the list of language features which we decided not to support. It should be noted that although these features are not provided by Calliope, in most cases their functionality is available via resources. The list of such features, as well as justification for their omission, is: . .

Null values: Although programming languages typically need a “null” value that refers to no object, we found that this concept was difficult to explain to our intended users. They are comfortable with the notion that they have an object which has certain properties, but the idea that the object might not exist and that they should test for this occurrence is not intuitive. We provide enough functionality in our resource construction tools so that null values can be handled inside the object model, not by the Calliope-user. . Nested conditionals and iterations: Although we do allow rules to be conditionals (if-then-else), and allow rules that iterate over a collection, we do not allow such structures to be nested. Nested statements require users to keep in mind the conditions under which the inner statement will be evaluated, and this quickly becomes a barrier to understanding. . Unbounded iteration: Unbounded iteration (like while-loops) were omitted from Calliope because termination conditions are extremely easy to get incorrect, causing infinite loops. . Controlled collection mutability: Calliope offers collections of resources and users can add elements to and delete elements from collections. However, we take steps to avoid situations that are difficult to understand. In particular, if x is assigned to y and x is a collection, then y becomes a copy of x’s collection, so that adding or deleting elements from x will not affect y, or vice-versa. Also, you can iterate over the elements of a collection, but cannot add or delete elements to that collection while doing so. . Side-effect-free expressions: Expressions in Calliope do not have side-effects. That is, you cannot change the values of variables and fields while evaluating an expression. Side-effects are only possible in the places in the rules where users would expect them. . Control-flow modifications: Calliope does not offer exceptions, gotos, or other methods of affecting the control-flow other than simple if-then-else conditions and iteration over collections. Another important consideration in Calliope’s design was that we wanted to provide as many design-time error checks as possible. Calliope is a strictly typed language: it must be determinable at design-time that any object members that are referred to actually exist. We prevent programs from using unassigned values, or leaving output values unassigned by the end of the ruleset. .


581

Fig. 9. Data structures maintained by Fusion.

7.4 Templates A template is essentially a Calliope rule with “holes” —places where parameters such as discount amounts can be filled in. By filling the template holes with correctlytyped values users can create template instances, which function like ordinary rules. A ruleset, then, can contain rules, templates, and template instances. Using our tools, users are allowed to:

implemented. Although each instance of a resource must correspond to an application object, each member just has to be implemented by a type-correct series of operations performed upon application objects. For example, the vocabulary might include “Customer” and “Order” entities, with Order objects having the method “Does this order’s value exceed the customer’s limit?” This might be implemented by the code

add new template instances to the ruleset by supplying parameters to one of its templates, . modify the parameters of a template instance, or . delete a template instance from the ruleset. All of these operations must be able to be performed without any errors. In other words, as long as the users supply properly typed parameters to the templates when creating or modifying template instances, the outcome must be a valid ruleset.

(Client.getMaximumOrderLimit (this.getClient()) > this.getTotalPrice())

.

8

RESOURCE

AND

LANGUAGE IMPLEMENTATION

In this section, we describe how programmers can create resources that correspond to business entities, and how the compilation of Calliope rulesets into execution engine nodes is performed.

8.1 Resource Implementation Naturally, it would be impossible for us to translate arbitrary resources into arbitrary Java data structures. The key fact that makes our translation possible is that developers and business personnel are cooperative: If a business rule manipulates a customer resource object, for example, then it is expected and required that the associated triggerpoint supply an application object corresponding to the same customer. We allow resources to differ a great deal from the application classes by which they are ultimately

where “Client” is an application class that maps roughly to the resource “Customer.” As illustrated by Fig. 9, Fusion’s tools maintain four data structures: The resource definitions. A model of a subset of the application classes. Specifically, we keep track of information about all the application classes and members that are either going to be passed to or from Fusion, or which are necessary to implement the vocabulary model. . The “mapping information” which states how each vocabulary business entity, member and relationship is implemented. . The set of triggerpoint descriptions, defining the triggerpoints and their arguments. The association between resources and Java classes is a many-to-one relationship: several resources can correspond to the same Java class. This fact is very useful: For instance, programmers often represent Social Security numbers, customer names, and part numbers identically as Strings. We can make distinct resources for each of these uses, reflecting the fact that business users do not want to confuse part numbers with Social Security numbers, and that the rules to determine whether a Social Security number is valid are different from those to check part number validity. . .

582


VOL. 31,

NO. 7, JULY 2005

Fig. 10. Member mapping information BNF.

Because many resources can correspond to the same Java class, we have to maintain enough information so that when application objects are passed into Fusion by a triggerpoint, we can determine which Calliope-types they have. Surprisingly enough, similar information has to be kept when Fusion returns values to the invoking triggerpoint. The reason for this is collections: if each LineItem corresponds to the Java class OrderLine, then a collection of LineItems might correspond to an array of OrderLines, or a Vector, or any other subclass of java.util.Collection—we cannot tell, and java.util.Collections are used frequently enough in Java code that it would be unacceptable for us to prevent their use. The second, and most complicated part, of the mapping information is the data about each member. For each member we have to state how the member is implemented in terms of the application and helper classes. In detail, the mapping information keeps for each resource member an abstract syntax tree (AST) describing its implementation. This AST is rich enough to include all the computational power of Java expressions. The AST refers only to information found in the application class model, so that if the application classes are modified, we can determine the impact of these changes upon the mapping information. Likewise, when the vocabulary model is changed, we can determine what mapping information is affected. The BNF grammar corresponding to the AST is shown in Fig. 10. Each method has an associated AST, while fields have two, corresponding to getter/setter pairs. The sMethodCall node describes the invocation of a static method, while nsMethodCall describes a nonstatic method call. Similarly, nsFieldRead is a nonstatic field read, and sFieldRead is for static fields. There is no node for static field writes because the rule engine is run inside a J2EE Enterprise Java Bean environment, which disallows changing the values of static fields.2 The thisRef node describes a reference to the “this” pointer, cast describes a type cast operation, instanceof is the instanceof operation, argument refers to one of the method’s arguments, 2. The reason for this J2EE restriction is that an EJB environment may span several JVMs, and changing a static field in one JVM will not affect the other JVMs, leading to inconsistent behavior.

and operation describes a Java primitive operation. The ifExpression node corresponds to Java’s if-expression operation.

8.2 Resource Tooling In order to ease the task of creating the mapping information, we provide tools for constructing basic resource models (and their associated mapping information). One tool (shown in Fig. 11) inspects Jar files containing Java class files (no Java source is necessary), and constructs a resources corresponding precisely to these classes. By starting from Java class files instead of the Java sources, we eliminate one possible source of error: Using source files that do not correspond to the class files deployed on the server. The user is given the ability to: omit classes which business users should not use, omit members which are not appropriate, and rename entities and members to be more appropriate. Using the full power of the AST mechanism, it is possible to do tasks such as . . .

create a new method not corresponding to any existing Java methods of the class, . add a new field, and . provide default values to method parameters. These more complicated tasks can be performed using lower-level programmer tools. .

8.3 Calliope Compilation Since Calliope is not a complex language, the major challenge of compiling rulesets into nodes is handling the difference between the Java and Calliope type systems. As stated earlier, there is a many-to-one relationship between resources and Java classes. If r is a resource, then let mapðrÞ be the corresponding Java class. Consider the translation of a Calliope ruleset which has n inputs with Calliope types i1 ; i2 ; . . . ; in , and m outputs of types o1 ; . . . ; om . To begin with, let us consider the translation if this ruleset does not use any collections. Then, the compiler will produce a node which will expect n inputs with Java types


583

Fig. 11. Fusion resource management tool.

mapði1 Þ; . . . ; mapðin Þ and produce m outputs with types mapðo1 Þ; . . . ; mapðom Þ. Calliope’s compiler implements each instance of a resource r with an object of Java type mapðrÞ. In order to translate invocations of resource members, it consults the mapping information. As described earlier, the mapping information contains an AST describing the member in terms of the available Java classes—the compiler uses this information to generate the correct Java instructions. Implementing Calliope’s control-flow and operations is not a challenge. The situation becomes much more complex if the Calliope ruleset contains collections. Say that one of the ruleset inputs is a Collection of Customers—what Java type should correspond to this input? There are a number of reasonable possibilities: an array of mapðCustomerÞ, a java.util.Vector, a java.util.Set, and others. Doing as we did before and insisting a-priori that there must only be one Java type corresponding to the Collection of Customers presents two problems. First, it would force the application programmer to be strongly aware of the Fusion implementation, which is antithetical to our goals. Second, the semantics of the Java object would become visible to the Calliope user—one can’t change the size of an array, or have duplicate objects in a java.util.Set —and, therefore, the business users would have to be far too aware of the Web application’s implementation. Clearly, this was not acceptable.

Instead, we decided that if a Calliope ruleset took as input a Collection of R, then the Web application could supply it an array of mapðRÞ-type objects or any instance of java.util.Collection. Similarly, if a ruleset outputs such a collection, then an application is allowed specify that the value should be returned to it as any one of the above types. The Fusion infrastructure is responsible for any necessary transformations. Internally, the compiled Calliope ruleset will implement its own collection data structure. When the compiled ruleset receives as input a collection, it has to create one of its own collection objects. If the application supplied a java.util.Collection instance, then this code also has to ensure that all the objects contained in it are of the correct type, at runtime. Similarly, if a resource method takes or returns a collection, conversion takes place, possibly along with the requisite runtime type-checks. It should be noted that this solution is not ideal: when a triggerpoint passes a collection to Fusion it incurs a cost linear in the number of elements in the collection. However, we maintain that this cost is not large.3 Furthermore, the alternatives—severely limiting either the application programmer or breaking the business vocabulary abstraction—were obviously unacceptable. 3. The cost of the transformation is linear in the number of elements in the collection. This will usually be dwarfed by the cost of transmitting the structure between the application and Fusion which is, due to the J2EE architecture, usually linear in the size of the collection in bytes.

584


8.4 Templates Templates pose another problem for compilation. The correctness rule with respect to templates was: A ruleset that contains templates is only correct at design-time if all of the many rulesets that could be created via the template operations are correct. For example, say that a ruleset has an output discount, but this output is only assigned to by a template instance. This ruleset would be illegal since this instance could later be deleted, leaving the output unassigned. Since a template can produce an infinite number of rulesets, this is in general a hard condition to ensure. We constrained Calliope’s design so that this check can be done in linear-time.

9

FURTHER WORK

As with any other system, we expect to respond to comments and requests from our users. However, we also have a long-range vision of our future work, along with many shorter-term goals.

9.1 Rule Management Our long-term vision of our work centers around businessuser management of business rules. We see a progression: Many companies do not explicitly define their business rules—they exist only in the minds of the staff. Eventually, companies go through the process of making their rules explicit. This usually occurs as a result of having to train new employees, or as a result of regulatory compliance. At this point, companies usually find that their business rules are deeply embedded in application code and, therefore, difficult to modify. Fusion represents another step in this progression: Business users are now able to quickly see what rules are in effect and which will be in effect in the future, without having to consult application programmers. The process of externalization also makes rules easier to modify in response to the rapidly changing world. We aim for yet another step: allowing business people to control and manage their business directly via business rules and to obtain important business feedback about their business’ operations. Instead of rules being tied to specific applications, every application should be able to consult a common set of rules. Business users should be able to monitor the business effects of their rules, and modify them in response. When considering rule changes, they should be able to detect inconsistencies with other rules, or regulation violations. Additionally, they should be able to document which rules enforce such regulations, in order to satisfy inspectors. Naturally, there are many issues to be dealt with before this vision can become reality. We have identified various shorter-term issues and problems. 9.2 Ruleset Flows The current Fusion system fully supports deploying and executing flows, and enables technical people to construct flows, but does not provide business-user-oriented tools for such construction. This is because flows raise major rule-management issues, and we consider business-user

VOL. 31,

NO. 7, JULY 2005

support for them to be a major milestone in our longerterm vision. The introduction of flows allows significant reuse potential. An existing ruleset can be reused in another environment with slightly different input and outputs simply by connecting data transformation rulesets to the old ruleset in a flow. Also, common behavior in multiple rulesets can be identified and made an independent ruleset. This is clearly very desirable. Unfortunately, human-factors issues arise when modifying rulesets that can involved in multiple flows. If a user edits a shared ruleset, they can mean to change its behavior only in one specific flow or in all flows in which that ruleset occurs. Also, they can mean their changes to be in effect only until a certain prescheduled change, to define a new change, or to be made independently of other changes. The simple solution of asking the user what should be done does not work in practice: It can be very unclear what the impact of each option will be to nontechnical people. Appropriate ways to present this information to users are a topic of investigation.

9.3 Aspect-Oriented Techniques Recent work on aspect-oriented programming has great potential when combined with our work. We believe that code-weaving could assist in the process of inserting triggerpoints into applications. Additionally, there are many legacy applications in which business rules are deeply embedded. We would like to provide tools to help identify and isolate such rules, and migrate the applications to a more flexible system. 9.4 Custom Business Languages We created Calliope as a general-purpose business-useroriented language. Although this is a large step, it is clear that the needs of companies involved in different areas of commerce vary greatly. Although it would be ideal to provide many languages tuned for specific commercial areas, it is clearly impractical to have to build compilers and editors for each such language from scratch. We believe that a promising area of future work would be in the creation of a common framework with which one could create custom business-oriented languages, reusing a common infrastructure. Our mapping information and associated artifacts are a step in this direction: Our mapping infrastructure describes how business vocabularies should be implemented by a compiler without refering to any Calliope constructs. We forsee using this infrastructure with multiple languages.

10 RELATED WORK A short overview of the Fusion system was previously given in [6], and built on the previous work “Extending Business Objects with Business Rules” [2]. The Fusion system can be classified using the taxonomy introduced in “On the Notion of Variability in Software Product Lines” [7] as providing “open variation” points following the “multiple parallel variants” pattern. Our system relates to work in a number of areas, each of which we will briefly survey.


10.1 Commercial Business Rule Systems There are a number of commercial products offering rulebased software [3], [8], [9], [10], [11] as a way to enable nonprogrammers to specify application logic. Most of these rule-based systems execute using inferencing engines. The claim made by these systems is that declarative rules are considered “natural” to business users. As we described earlier, our experience does not support this, especially as performing general logic with these systems requires knowledge of inferencing concepts (e.g., working memory, implicit iteration, etc.). Many of these products support an English-like presentation of business rules. Some offer a spreadsheet paradigm, but with a corresponding limitation on expressiveness. Although many of these products use business vocabulary and a high-level language to map rule artifacts to underlying business objects, the target audience is still required to be fairly sophisticated with a moderate to deep understanding of object oriented programming technology.

585

techniques used in SBA do not extend easily to less datacentric applications and the advocated “query by example” paradigm essentially requires business users to learn a programming language. The Variation Point Model [22] represents variation within a model. Complementary to our work, the technique presented could be used for identifying, within core applications, points of variability (triggerpoints) and information available at them (i.e., context). Our work further suggests that the variability need not be programmed by a programmer, but can be authored by a business user. “Support for Business-Driven Evolution with Coordination Technologies” [23] recognizes that software development techniques, such as object oriented ones, do not effectively address software evolution. A coordination contract discipline is introduced that helps in this domain, but it targets software developers, not business users.

10.2 Other Business Rule Research A lot of business rule work, especially that done earlier in the field, has been devoted to assisting the identification and classification of business rules. The books [12], [13] are recommended references. Notable papers include [14], [15], [16]. Our work assumes that our users have already identified their business rules and, thus, builds on this body of knowledge. “Evaluating Expert-Authored Rules for Military Reasoning” [17] enables subject matter experts to manage knowledge directly without formal logic training. The focus is on writing sensible rules by nonlogicians for an inference engine, while our concentration is on enabling authoring of simple, autonomous, and memoryless statements. “Naked Objects: A Technique for Designing More Expressive Systems” [18] describes a toolkit to expose object methods using a noun-verb style. It uses reflection to compose a lone user interface view. It allows for just one language based upon the subject Java object collection. It requires that participating Java objects implement the Naked Objects interface, which contrasts with our work, which does not place any constraints upon objects. JAsCo [19] is a set of aspect-oriented techniques for programmers to connect business rule implementations with business rules-driven applications. These techniques could automate the insertion of variability points in applications.

10.4 Ontologies With Fusion programmers use our resource tooling to create an object model with appropriate functionality for their business users to express their business rules. This is not intended to capture business domain knowledge, which is the aim of various ontology projects, such as Prote´ge´ [24], [25]. However, such ontologies hold promise for future work, both for detecting business rule conflicts, but as a way to construct Fusion-like resources. Many ontology languages and meta-models for capturing knowledge have recently been proposed for standardization in various consortia. In the context of the semantic Web, the Web Ontology Language (OWL) specification [26] has proposed three increasingly expressive sublanguages as the standard way to represent knowledge that would be manipulated by the next generation of Web agents. Unlike ongoing efforts in Object Management Group (OMG) [27] to define a metamodel to capture, from the business perspective, the semantics of business vocabularies, the OWL approach, although complete, is not specifically targeted to business users. However, in these proposed knowledge representation languages and metamodels, the trade-off between expressiveness and ease of use, especially by business people, has been made in favor of expressiveness. The OMG BSBR RFP [27] acknowledges this by stating that the required metamodel is not intended to be directly manipulated by business people, and a mapping from a “business user friendly notation” needs to be provided.

10.3 Variability OCL [20] is recommended by the Object Management Group for defining constraints in UML models. OCL is a pure specification language—expressions are side-effect free, and implementation issues are not addressed. This wasn’t suitable for us since we need to express computation including data modifications. Additionally, although easier to use than most specification languages, OCL still requires significant understanding of formal concepts. SBA [21] allows nonprogrammers to describe and manipulate information using tables, business forms, and reports. Automation is accomplished by giving “examples” to the system on how to manipulate information. The

10.5 Adaption Our resource framework can be considered a method for creating adapters[28]. Given the long history of adapters and the problem of software maintenance, there is a large body of prior work. We will highlight some of the most illustrative examples here. One approach recently popular approach for communicating between entities that expect different object models is to use XML and XML-processing tools such as XSLT. One can convert one entity’s data structures into XML and then use XSLT to translate this document into a schema understood by the second entity. Unfortunately, this is not applicable to Fusion because the Web-application data

586


structures often do not contain data that is required by the business rules. There are also a number of products such as IWay’s Adapter Factory [29] that provide support for a large number of specific interfaces. Although useful, these products are limited to a fixed number of interfaces. Burstein et al. [30] describe their method for automatically constructing adapters between components. These adapters can be quite complex, but their system requires that a formal semantics of both components be written. That requirement makes this approach unsuitable for us: Not only is the ability to write formal mathematics very rare among professional programmers, but our interfaces are subject to frequent change which would require this work to be done repeatedly. Abiteboul and Bonner [31] describe their work on a very similar problem occurring with Object-Oriented databases. They argue that restructuring or integrating databases often requires different views of the same underlying data, with each view possibly having significantly different classes. Although the similarity to our problem should be clear, their mechanism is very specific to object-oriented databases and, so, could not be used by us. Keller and Ho¨lzle [32] describe their adaption technique for Java components. In order to adapt a class A, they produce a file describing the modifications they wish to make upon the class. These modifications can include things like the addition of new methods and fields, member renaming, addition of interfaces, etc. At runtime, when class A is loaded, their special classloader reads in the description of the desired changes and modifies the binary class file appropriately. The power of their mechanism is probably comparable to ours; however, we were unable to make use of it, for two main reasons. First of all, Keller and Ho¨lzle’s technique changes the old classes into the new ones, necessitating changing all occurrences of the old classes. This might be feasible if the application was only executing in one JVM, but in a distributed enterprise J2EE environment ensuring this becomes problematical. Second, doing binary modifications of class files means that there is no source that accurately reflects the executing code. Our customers would almost certainly not be willing to accept this for business-critical Web applications.

NO. 7, JULY 2005

Our prototype system provides generic UIs that employ these frameworks for defining vocabularies and mapping terms onto runtime artifacts; for defining templates, rulesets, and rules; and for generating artifacts deployable to a runtime engine. Performance. The Fusion system provides application connection componentry which makes integration with existing and future rule-driven applications fairly simple. The Fusion system introduces minimal runtime overhead. Fusion does not introduce a new layer of runtime objects to support business user vocabularies which might adversely affect performance, but rather uses existing objects unmodified. Fusion does provide a level of indirection for rule set selection through a connection registry which does have some performance cost, but with the added advantage of increased flexibility. Maintainability and Reliability. We have shown how our Fusion system embraces dynamic changes in fast paced environments, in contrast to application programming changes which are usually more deliberate and evolutionary in nature. Our prototype allows transactionalized updates to running systems, insuring a consistent and reliable view to client applications.

ACKNOWLEDGMENTS The authors would like to thank the many contributors from IBM Research and Software Group who contributed to the Fusion project.

REFERENCES [1] [2] [3] [4] [5] [6] [7]

11 CONCLUSIONS Fusion addresses several core objectives: usability, performance, maintainability, and reliability. We have shown the architecture of a prototype middleware that is aimed at making it possible for business users to control exposed aspects of applications in a systematic and manageable way without the need for programmer assistance, but without burdening application programmers or sacrificing efficiency or reliability. We have shown both development and runtime components of our middleware, describing the purpose and, at a moderate level of detail, the operational characteristics of each. Usability. We have shown that business users can author business logic using terms familiar to them by means of the Fusion provided resource and rule authoring frameworks.

VOL. 31,

[8] [9] [10] [11] [12] [13] [14] [15] [16]

A. Perkins, “Business Rules = Meta-Data,” Proc. Technology of Object-Oriented Languages and Systems Conf. (TOOLS ’00), p. 285, 2000. I. Rouvellou, L. Degenaro, K. Rasmus, D. Ehnebuske, and B. McKee, “Extending Business Objects with Business Rules,” Proc. Technology of Object-Oriented Languages and Systems Conf., June 2000. QuickRules Standard Edition, YASU Technologies, www. yasutech.com/products/index.htm, 2005. B. Shannon, M. Hapner, V. Matena, J. Davidson, J. Davidson, L. Cable, and The Enterprise Team, Java 2 Platform, Enterprise Edition: Platform and Component Specifications. Pearson Education, 2000. J.P. Bigus, “The Agent Building and Learning Environment,” Proc. Fourth Int’l Conf. Autonomous Agents, 2000. I. Rouvellou, L. Degenaro, J. Diament, A. Fokoue, and S. Weber, “Business Users and Program Variability: Bridging the Gap,” Proc. Eighth Int’l Conf. Software Reuse, July 2004. V. Gurp, J. Bosch, and M. Svahnberg, “On the Notion of Variability in Software Product Lines,” Proc. Working IEEE Conf. Software Architecture (WICSA), 2001. Corticon Business Rules Management, Corticon Technologies, Inc., www.corticon.com/home.html, 2005. Blaze Advisor, Fair Isaac Corporation, www.blazesoft.com, 2005. JRules, ILOG Software, www.ilog.com, 2005. E. Friedman-Hill, Jess in Action: Java Rule-Based Systems. Manning Publications, 2003. B. vonHalle, Business Rules Applied. Wiley Computer Publishing, 2002. R.G. Ross, The Business Rule Book: Classifying, Defining and Modeling Rules. Business Rule Solutions, 1997. R.G. Ross, “Expressing Business Rules,” Proc. 2000 ACM SIGMOD Int’l Conf. Management of Data, pp. 515-516, 2000. W.M.N. Wan-Kadir and P. Loucopoulos, “Relating Evolving Business Rules to Software Design,” J. Systems Architecture, vol. 50, no. 7, pp. 367-382, 2004. L. Lin, S. Embury, and B. Warboys, “Business Rule Evolution and Measures of Business Rule Evolution,” Proc. Sixth Int’l Workshop Principles of Software Evolution, p. 121, 2003.


[17] M. Pool, K. Murray, J. Fitzgerald, M. Mehrotra, R. Schrag, J. Blythe, J. Kim, H. Chalupsky, P. Miraglia, T. Russ, and D. Schneider, “Evaluating Expert-Authored Rules for Military Reasoning,” Proc. Int’l Conf. Knowledge Capture, 2003. [18] R. Pawson and R. Matthews, “Naked Objects: A Technique for Designing More Expressive Systems,” ACM SIGPLAN Notices, vol. 36, no. 12, Dec. 2001. [19] M.A. Cibran, M. D’Hondt, D. Suve´e, W. Vanderperren, and V. Jonckers, “Jasco for Linking Business Rules to Object-Oriented Software,” Proc. Int’l Conf. Computer Science, Software Eng., Information Technology, e-Business and Applications, June 2003. [20] M. Penker, M. Penker, and H.-E. Eriksson, Business Modeling with UML. Wiley and Sons, 2000. [21] M.M. Zloof and S.P. Jong, “The System for Business Automation (Sba): Programming Language,” Comm. ACM, vol. 20, no. 6, June 1977. [22] D. Webber and H. Gomaa, “Modeling Variability with the Variation Point Model,” Proc. Seventh Int’l Conf. Software Reuse: Methods, Techniques, and Tools, 2002. [23] L. Andrade, J.L. Fiadeiro, J. Gouveia, G. Koutsoukos, and M. Wermelinger, “Support for Business-Driven Evolution with Coordination Technologies,” Proc. Fourth Int’l Workshop Principals of Software Evolution, 2001. [24] N.F. Noy, W. Grosso, and M.A. Musen, “Knowledge-Acquisition Interfaces for Domain Experts: An Empirical Evaluation of Prote´ge´-2000,” Proc. 12th Int’l Conf. Software Eng. and Knowledge Eng., 2000. [25] J.H. Gennari, M.A. Musen, R.W. Fergerson, W.E. Grosso, M. Crube´zy, H. Eriksson, N.F. Noy, and S.W. Tu, “The Evolution of Prote´ge´: An Environment for Knowledge-Based Systems Development,” Int’l J. Human-Computer Studies, vol. 58, no. 1, pp. 89-123, 2003. [26] M.K. Smith, C. Welty, and D.L. McGuinness, “Owl Web Ontology Language Guide,” World Wide Web Consortium,” W3C Recommendation, 2004, http://www.w3.org/TR/2004/REC-owl-guide20040210. [27] “Business Semantics of Business Rules Request for Proposal,” Object Management Group, http://www.omg.org/techprocess/ meetings/schedule/Bus_Semantics_of_Bus_Rules_RFP.html, 2005. [28] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [29] Adapter Factory, IWay Software, www.iwaysoftware.com, 2005 [30] M. Burstein, D. McDermott, D.R. Smith, and S.J. Westfold, “Derivation of Glue Code For Agent Interoperation,” Proc. Fourth Int’l Conf. Autonomous Agents, C. Sierra et al., eds., pp. 277-284, 2000. [31] S. Abiteboul and A. Bonner, “Objects and Views,” Proc. ACM SIGMOD Conf. Management of Data, pp. 238-247, 1991. [32] R. Keller and U. Ho¨lzle, “Binary Component Adaptation,” Proc. 12th European Conf. Object-Oriented Programming, pp. 307-329, 1998. Sam Weber received the BSc and MSc degrees in computer science from the University of Toronto, and the PhD degree in computer science from Cornell University. After being a faculty member at Cornell University and the University of Pennsylvania, he joined IBM’s T.J. Watson Research Center. His research interests include programming languages and security.

587

Hoi Chan works in the Autonomic Computing Science and Standard Department at IBM’s T.J. Watson Research Center. His work is to create and study Autonomic Computing-based system system management applications. He focuses especially on various types of rules and knowledge technologies and applications, and strategies for building autonomic systems. He worked with Professor Benjamin Grosof (now MIT Sloan School of Management) to develop IBM CommonRules and its application piloting for rule-based XML agent contracting in EECOMS, a $29 million NIST industry consortium project on manufacturing supply chain management. Lou Degenaro received the MS degree in computer engineering from Syracuse University in 1985 and the BS degree in computer science from the State University of New York Oswego in 1979. He has been a software engineer at IBM since 1981, shifting to IBM Research in 1988. His interests are in the areas of systems, distributed computing, and middleware. He has been an integral part of many successful projects, including WebSphere Partitioning Facility for Extended Deployment, Business Rule Beans, Accessible Business Rules (the foundation for WebSphere Personalization), Life Underwriting Workstation, MPIF/6000, Load Leveler, DFSMS/VM, and Distributed Dirmaint for VM. He holds several US patents and has many pending. He has coauthored papers for prestigious conferences. Judah Diament received the MS degree in computer science from New York University. He is a software engineer at IBM T.J. Watson Research. His interests include intelligent tools for both developers and “laymen” as well as dynamic service oriented middleware architectures. He has coauthored several patents and papers.

Achille Fokoue-Nkoutche received the MS degree in computer science from Ecole Centrale Paris in 1999. He is currently a software engineer at IBM’s T.J. Watson Research Center. His research interests include rule systems, program analysis, information and knowledge representation, and information integration.

Isabelle Rouvellou received the PhD degree from Columbia University. She is a research staff member and manager of the Advanced Enterprise Middleware department at IBM’s T.J. Watson Research Center, working on the design and implementation of middleware enabling the next generation of distributed applications. She holds several IBM awards for the contributions she made to IBM’s Websphere family of products. She is also a coauthor of several papers and patents in the field of distributed object technology, messaging, and software engineering.

. For more information on this or any other computing topic, please visit our Digital Library at www.computer.org/publications/dlib.

Fusion: A System For Business Users To Manage Program Variability

Fusion: A System For Business Users To Manage Program Variability

Suggest Documents

Business Users and Program Variability: Bridging the Gap - CiteSeerX

Empowering end-users to manage business rules: the ... - Springer Link

Multi-Agent Information Fusion System to manage ... - Semantic Scholar

A framework to manage multimodal fusion of events for advanced

Using Dynamic Software Variability to Manage ...

Using a Workflow Management System to Manage

A Users Search History based Approach to Manage ...

Information Fusion in a TV program Recommendation System

ontology-based multi-agent system to support business users and ...

Application of an Interactive Computer Program to Manage a Problem ...

A framework for evaluating business lead users

FMC: a one-liner Python program to manage ... - Meeting Organizer

Page 1 A MEDICAL INFORMATION SYSTEM TO MANAGE A ...

ECOISLAND: A SYSTEM FOR PERSUADING USERS TO ... - CiteSeerX

Equipping small business retailers to manage

SAP & MapmyIndia Empower Enterprises to Manage Business ...

Supporting Users to Manage Breaking and ... - DSM Forum

Empowering Users to Specify and Manage Their Privacy ... - CiteSeerX

learning to manage accounts receivable: system

A CORPORATE CULTURE PATTERN TO MANAGE BUSINESS ... - RUA

Supporting dairy business managers to manage for future climates

Using Product Lines to Manage Variability in Mobile Context-Aware ...

A Web-based System to Manage Primary Students ...

HandSpy â a system to manage experiments on cognitive ... - DROPS

Fusion: A System For Business Users To Manage Program Variability