Business Object Workshop IIIBusiness Object Workshop IIIBusiness object facilities should be designed to enable businesses to implement distributed, object-oriented business applications that reflect the natural structure of the business. They should also provide structures that allow different views on the system to be faithfully captured in its design. For example, information technology experts and business experts have different but equally valid ways of looking at a business application system; both must be captured faithfully if the system is to be useful, flexible, and durable.
Among the many areas of design an application development team must deal with is business rules. This paper focuses on that area. It outlines a patterned extension to a commercially available component architecture that enables enterprise applications to systematically externalize business rules. The architecture, though still in the proof of concept phase, has been sufficiently implemented in several IBM engagements with business customers to demonstrate the feasibility of the approach. The paper describes the architecture described at three levels -- the managed object level, the business object level, and the business component level -- each of which builds on what went before. Each of the levels is built to conform to a well-known architecture:
The architecture draws a clear separation line between the programmer's world and the business person's world by placing them in different levels of abstraction or frames of reference. Each level is a "closed world" in the sense that the system can be understood purely in terms of the given level.
The paper explores the model proposed for applications that conform to this architecture starting at the bottom and working up. That is, we begin with the application's managed objects and show how these are used to build the higher level application constructs. For other -more requirement level- aspects of business rules see [KS97].
The lowest level of objects in an application are concerned with data persistence and define mostly getters and setters. By implementing support for the instance manager pattern (a variation on the strategy pattern [GHJV95]), the IBM Component Broker Connector (CBC) allows us to define and build instance-managed objects where the technical strategies for object persistence are cleanly separated from application logic. At this level, rules are mostly "intrinsic" rules. That is, they are mostly business-context-independent constraints having to do with programming-oriented concerns, e.g., internal data consistency. The relevant participants are:
A rule is a managed object. A "rule class" defines a parameterized,reusable reusable evaluation method (e.g., range(x, y, z) returns true if x < y < z). Each instance of such a class defines a specific rule which expects a certain number of input parameters, and knows how to compute the values to be fed to the parameterized evaluation: it knows how to map the parameters provided by a control point (see below) into the parameters expected by the evaluation to be executed. For example, a rule "age between 0 and 80" is an instance of the Range class which expects a parameter "age" as input and does the following mapping: x=0, y = age, z = 80.
Rules can be compound. A compound rule is a composite consisting of other rules. The compound rule acts from the outside as a single rule: in particular, a single set of parameters is associated with it. The composition patterns vary: some of them are meaningful for assertion rules only and others only for derivation rules. We provide common ones such as:
Control points are the hooks for rules. A control point provides a well-defined set of parameters to the rule(s) it triggers. Control points know how to marshal the list of parameters to be given to the rules attached to them. When a control point is reached, it triggers all the rules attached to it. We distinguish two kinds of control points.
These are very common control points. They trigger rules at the beginning or end of a given method invocation. They are used to attach constraint rules as pre- or post-conditions of methods.
Business objects are built upon the lower level, managed objects discussed above. The construction of business object uses the composite pattern [GHJV95]. Each represents a cohesive and coherent business concept. Each conforms to the Enterprise Java Beans architecture, and is itself a component broker connector instance-managed, persistent object. Collectively, the business objects represent the state and behavior required for a business application, but not its GUI -- together they are the application's "model&yagequot; in model-view-controller terms. Rules can be attached to control points on business objects. Those rules may be intrinsic rules or "real" business rules -- extrinsic rules that, in general, depend on business context. The relevant concepts are:
What defines "a business context&nquoquot; varies from one business to another. Example components of the context include the type of the agent performing the work (e.g., manager, field agent, "Joe&gp;quot; ,....), the type of activity being done, etc. Whatever form it takes, the business context for an application is classifiable. That is, there exists a space of named classifications and, given a business context instance C and an element of the classification name space E, it is possible to say whether or not C is properly classified as an E.
Some rules are applicable only in specific business contexts, while others, such as general integrity rules, are applicable in all or nearly all business contexts.
The fact that most rules involve being able to determine how a thing is classified and/or which properties it has at any moment in time, leads to the need to carefully design classification/properties determination strategies. The choice of those strategies is partially determined by technology usage strategies, which in turn are determined by the usage characteristics of the system. As such, we need ideally to be able to formulate business rules before and independently of these various strategies.
The rules architecture adopts the view that rules are asserted by logical entities called "jurisdictions" that provide:
The jurisdictions applicable to an application are collected together into a "jurisdiction group&ns&aquot; which collaborates with control points of business objects (see below) to select, order, and attach the appropriate rules to the control points. E.g., a U.S. insurance application could have rules issued by the state, by the federal government, and by the insurance company, each of which forms a jurisdiction. The collection of all of them is the jurisdiction group. Organizing rules into jurisdictions has two advantages.
First, it makes it apparent in the rule model that most business rules have a specific source (owner) and that different sources might want to assert different things in the same business context. This provides a natural, organized way for business people to understand and manage the enterprise's business rules.
Second, it provides a structured way to implement a common derivation pattern. In this pattern, one jurisdiction specifically relies on another jurisdiction's computation result as input of its own computation. For example, in the computation of the minimum premium for policy, the final premium computation could be done by the insurance company jurisdiction which sets the premium value to be the value imposed by state plus some computed additional dollar amount. In general, a common derivation pattern is one where a more general context feeds its result to a more specific context.
Units of work provide structural support for "work" (i.e., business tasks and processes). Units of work represent an application-level structure. They follow the structures of the work done by the employees and associates of an enterprise. This provides a natural structuring, whether or not each unit of work is totally or even partially automated. A UOW may be started, and once started, it may be suspended and subsequently resumed. It continues to exist until it completes, which it may do by committing or by aborting.
Our approach introduces a "unit of work&lylequot; (UOW) object that represents a piece of business work and defines the business context in which it is carried out ([S94] mentions alternative approaches).
The UOW maintains a list of the objects modified by processing carried out on a thread associated with it. Until (and unless) the UOW commits, state changes made to those objects are not visible to processing on threads associated with other UOWs (from a business perspective, this is work in progress!). If a UOW completes by aborting, state changes to persistent objects made as a part of its processing disappear. If it completes by committing, the state of the system is changed so that all of the changes to persistent objects made during the UOW become visible to all subsequently-started UOWs.
We distinguish typed and untyped UOWs. Each typed UOW carries data (which often defines part or all of the business context) that distinguishes it from UOWs of other types. A typed UOW also has associated with it a list of objects that participate in it. This list can be conveniently referred by rules.
The UOW provides several commonly used "control points: One that occurs just after the UOW is started, one that occurs just before it commits, and one that occurs just before it aborts. These control points provide convenient places to implement rules that check for integrity constraint violations point (see below).
Rules are defined exactly as for the managed object level. I.e., they are persistent objects composed of some parameterized evaluation code defined by the class and some instance variables which determine how the mapping is done between the input and the parameters expected by the evaluation.
A rule is attached to a control point as in the lower level, but now attachment is contingent on whether its jurisdiction applies to the instance in question and on the business context.
Most of the rules at this level are extrinsic -- rules that customize the generic behavior of the business objects to implement business practices that have been decided on by the enterprise. Such rules are generally quite specific with respect business object, control point, and business context.
Some rules (mostly intrinsic ones) are invariant or general integrity rules which have to be "always true&.ndsquot; (i.e., always except during some specific "rule free&.ndsquot; periods such as the middle of a business operation or a unit of work). Often, we are able to identify time points at which it is appropriate to check for potential violations. Such a time point is generally at the beginning or end of a high level business operation, a typed UOW operation or a simple method invocation. The rules are then attached to constraint control points on the objects defining the method: this assumes that it is possible to get an exhaustive list of the relevant methods. While this is possible in many cases (e.g., internal data consistency check following a single field change), it might be tedious in other cases. Another option, to be used cautiously, is to infer possible applicability of the rules at defined integrity moments (e.g., commit of every unit of work, user initiated check,...), "smart&tysqquot; control points are used at those integrity points (see below). Using this approach needs to be approached cautiously because it trades off runtime speed for doing additional analysis.
The control points at this level are "smarter&sqququot; versions of the lower level control points in that they know how to work with the application's jurisdiction group to select, order, and attach rules according to context. Both constraint and derivation control points are supported. Derivation control points are extended to support several rules: in particular, working with the jurisdiction group to unambiguously and naturally ensuring that a single result always emerges. In addition, a new kind of control point, refered to as "commit control point&lysqquot; is provided. A commit control point is a constraint control point that occurs just before a UOW commits. It uses the list of participants maintained by its UOW (see III.C) to select the relevant rules (e.g., according to the participants classes). Commit control points therefore provide convenient "catch all" check for general integrity constraints which could not be attached to more specific control points.
Note that since we want to reuse the same machinery across layers whenever possible, the collaboration with jurisdiction groups is, in fact, built into all control points. This capability can actually be put to good use in the lower level for error reporting. If a rule fails at the lowest level of the object model, the end user is ignorant of the object and method involved: Using the business context to tailor the error message (or any other action taken upon rule failure) can greatly help with usability.
To allow business objects to be manipulated as graphical entities both at run time when users interact with them and at assembly time when business users assemble applications from them, either directly or using visual tools, the rules architecture introduces a layer above the business object layer: The business component layer. Business components are high-level business objects that conform to the Java Beans architecture. This allows tools to inspect the business components' events, methods, and properties using "standard&uotoquot; facilities. That is, making the business components conform to the Java Beans architecture allows them to fit into the "component based&e;uquot; visual tools now being shipped.
A business component is composed of three types of object: A bean object that conforms to the Java Beans architecture, a "model&e;uquot; object, and zero or more "view" objects. The "model" object is a business object as defined in section III.
The component model is composed of the business objects and their associated control points. It provides in some sense the business context "relating" the underlying business objects. This is a "bottom up" view of a business component, but there are (at least) two others.
From the business expert's point of view, business components are the building blocks from which applications are made. They are business level software constructs which are visible to their users at appropriate times as directly manipulable graphical entities. The components provide the visual, behavioral, and state maintaining aspects of the applications built using them. Business components map closely to the business entities business users think about -- both in terms of what they are and how they relate to each other.
Business components are -- to their users -- persistent entities. Each comes into existence as the result of some business operation and continues to exist until some other business operation destroys it. In fact, in most cases, the apparent persistence is "faked"-- business component are synthesized from the underlying business objects. (But then, again, the persistence of the underlying business objects is somewhat illusory since they are often "rehydrated&uotuquot; as needed from the enterprise data by the CBC instance manager.)
The important thing here is that to the people who assemble applications built from business components and to those who use them, the components -- at least the ones they can see -- are the application. That is, the entire user interface is provided by components and assemblies of components.
We describe below the different elements involved in dealing with rules from a component point of view.
Every business operation meaningful to a business expert is defined by some component. Put another way, if there is a business operation that is required but not available, that need can only be met in two ways. First, it can be built from existing business operations by "compounding" a number of existing business operations using a visual development tool, a process often called "scripting". The range of operations it is possible to construct this way is limited by the vocabulary of available business operations. Second, when it is not feasible or reasonable to implement the required business operation using the first approach, one or more of the components will need to be changed internally. To do this, requires programming skill and programming tools -- exactly what sort of skill and what sort of tools depends on how the component was developed originally.
A component instance always executes within a unit of work which, in turn, has a business context associated with it. The current business context is part of the component's execution environment. It is set (often unknowingly) by the user through the GUI or by a business operations.
There is definitely an end user perception of the UOW. The user starts a piece of work, can decide to stop it for a while and resume it later, etc. The way the UOW is surfaced to the user is not imposed by the architecture. A common way to do it is though a form, or a folder (i.e., by adopting the case metaphor).
Rules are business components. As in lower levels of this model, they are said to be "attached&;oquot; to component at control points. The model part of the rule component is a rule object as defined in the previous sections.
The control points in a component occur at specific, semantically meaningful points in the behavior of the component. When the state of execution corresponding to a control point is reached, the rules attached to the control point are fired. As with the lower levels, both constraint and derivation control points can be defined. Component-level constraint control points often correspond to business-level state transitions. These are represented as pre- and post-operation constraints on business operations.
Component-level control points are implemented as business object-level control points.
Business Object Workshop III