A position paper presented at the 1998 International Workshop on Component-Based Software Engineering

Abstract

In this paper, I analyze the technological trends of component architecture used for business applications. By architecture, I am referring to the software elements and the relationships among them. The two important technical goals are (1) separating business logic from implementation logic and (2) mapping business models for implementation. I also explain the difference between object orientation and component orientation in building business application systems.

keywords: component architecture, business application systems, business logic, business modeling

1. Introduction

This paper discusses business application systems (information systems) such as sales management systems and manufacturing systems. Business logic in such systems is very important. Business logic is usually embedded in source code and is thus not clearly visible. Finding specific portions of business logic is a very time-consuming task for people who maintain the systems.

Object orientation has not contributed as much to the development of business application systems as it has to others such as operating and simulation systems. One reason is that most objects in business modeling are data rather than active objects. Object modeling does not give us good insights about software architecture, although it does give us good entity relationships for database schema. A 3-tiered architecture is widely employed for business application systems in which the data and process parts are assigned to a database server and an application server, respectively. Another claim against object orientation is that it does not enable good business process modeling, which is at the heart of business process reengineering [3].

Introducing object technology into business application systems is different from other types of software. In this paper, I analyze the technological trends that researchers and industry technology developers will follow.

2. Separating Business Logic from Implementation Logic

The separation of business logic from implementation logic is important for several reasons.

(1) Business logic changes frequently and thus the corresponding code often needs to be found and modified.

(2) Business logic is the heart of the system; it explains what and how the system performs.

(3) Implementation logic portions should be modified separately for many different reasons, one of which is the need to upgrade middleware. This may be a long-term goal, but it is aimed at the component-based software development of business application systems. This is the core idea of Enterprise JavaBeans [4]. The next, more difficult problem is how to separate business logic into its constituent components. Although Enterprise JavaBeans currently only distinguishes the process-centric component "session enterprise bean" and the data-centric component "entity enterprise bean", OMG BODTF recognizes more elements relating to business logic such as "events" and "business rules." OMG BODTF discusses these elements by specifying the interface of components rather than by implementing components.

Events and business rules are means to describe business logic at a more abstract level. For instance, procedure call is a mechanism by which a client specifies a specific server. Conversely, by issuing an event, a client may invoke multiple cooperative servers. An event such as "issuing a purchase order" is an element that models a real world business, and its associated business rules and processes are initiated to execute the appropriate process. Other elements can also be used to model business logic. These elements are not usually discussed in object-technology communities.

3. Construction of Components for Business Logic

(1) Enterprise: A system of business objects that cooperate to accomplish a desired goal. The business objects of an enterprise include people, machines, buildings, processes, events, and information.

(2) Business function: A group of activities which, taken together, support one aspect of furthering the mission of the enterprise.

(3) Business process: A specified activity in an enterprise that is executed repeatedly.

(4) Business rules: The conditions, constraints, and policies that control the operation of an enterprise.

4. Conclusion

In this paper, I have discussed the "separation" of business logic and implementation logic and the "mapping" of a business model for implementation. All are closely related to future component architectures and the development technology for business application systems. Note that this claim is not applicable to other types of software and that object technology will not support these goals. The techniques we desire for business application systems are for the "separation of business logic" and the "mapping of business models" via a business modeling vocabulary, in which object technology only suggests real world modeling using classes with an inheritance mechanism.

References