Menu
Home Solutions Services Partners Developers Company News and Events Menu

CAPS
CAPSupphandling
CAPScase
Real-Time Monitoring
More information
CAPS™
Business Overview
Architecture Overview
White Papers

7. CAPS™ Layer 3: Business Logic Modules (BLMs)

The operation of the BL subsystem is highly modular. On top of the BL infrastructure proper, which constitutes Layer 2, a further logical layer runs (as part of the same process) any number of application specific business-logic modules. The BL loads (from the database, via the IFC™) the set of "Business Logic Modules" (BLMs) that define the business objects and business rules of one or more applications.

BLMs are coded in a simple but powerful "declarative" language, syntactically similar to Python. The "BLM language" lets the application programmer express all of the fundamental properties of the application, resulting from Entity-Relationship analysis. The BLM language's first-class concepts include the Entities involved in an application, the Attributes of each Entity, and the (binary) Relations that hold between Entities.

The BLM language lets the application programmer declare the most important characteristics of these high-level objects. For example, in the case of a Relation, the programmer declares the "N-Arity" of each "end" of the Relation, that is, whether it is one-to-one, one-to-many, or even "optional" for that end (an N-arity of "zero or one" on that end of the Relation). The BLM language itself allows direct declaration of many typical results of analysis, such as the Types of Attributes, and a variety of Constraints that Attributes must respect (one simple kind of Business Rules). Entities can use (single ) inheritance, and can be organized across multiple Modules and code Libraries, with multiple-leveled structured ("package-like") names.

The "procedural" aspects of business objects and rules are expressed by embedding Python source code in the BLM sources. Such embedded code is executed either when requested by downstream subsystems, or when certain conditions occur. For example, some attributes of an entity can be specified as being "computed". The value of such an attribute is not actually stored in the database; rather, embedded Python code runs, and computes the attribute's value on the fly, on the basis of other data, each time the value is requested.

CAPS™ operations include full transactional "ACID" guarantees (Atomicity, Consistency, Isolation, Durability), and internally operate in highly-asynchronous, multi-programmed ways. However, the BLM Language supplies a library that application programmers can use to structure their code in ordinary, sequential ways, while transparently supporting such multi-programming and ACID guarantees.

Each BLM can be associated with sets of descriptive data, "decorating" each Entity, Relation, Attribute, and so on, with presentation-related meta-information. The CAPS™ framework comes with general-purpose front-ends ("clients"). The "presentation guidelines" associated with each BLM let the application programmer easily customize these clients to properly display the data relevant to each given CAPS™-based application. Since several such customizable clients exist, each BLM can be associated with several parallel sets of "presentation data", each tagged with a different structured name.




© 2002-2007 Open End AB