Hans Albrecht Schmid* (schmidha@fh-konstanz.de)and Fernando Simonazzi#
*FB Informatik, University of Applied Sciences, Konstanz, Germany
#LIFIA, UNLP, La Plata, Argentina

Recently, the business community discovered the importance of business process engineering, and the object-oriented community (see e.g. [OMG97][S97]) has put much emphasis on the structuring of business applications, often in the context of client/server computing. However, there is a gap between the two efforts. Our claim is that state of the art business application structures and frameworks do not represent business procedures adequately. Business procedures are not modeled naturally, i.e. in principally the same way as they are described by the business community.

To prove this claim, we determine the most important characteristics of business procedures. We analyze several prominent examples for state of the art business applications structures and framework: client/server application development [OH97], systematic application development with strategies and patterns [CNM97] [F97], and the business framework San Francisco [IBMSF98]; and we show that they do not represent adequately important characteristics of business procedures. Concludingly, we will give an outlook on a system that represents these characteristics adequately.

A business process consists of a, usually non-strict or conditional, sequence of business procedures. A business procedure is triggered by an external event. For example, "changing a customer address" is a business procedure triggered by the event of receiving an address-has-changed letter from a customer.

A business procedure consists of a (often non-strict or conditional) sequence of business activities. For example, the procedure "changing a customer address" consists of one activity, changing the customer address.

A more complex business procedure, "canceling a health insurance", triggered by a customer giving notice, consists of four business activities: check validity of notice; check if policy is a good risk; if notice is valid and risk is good, approach customer to take notice back; if required, cancel policy. An activity is mainly triggered by the termination of a preceding activity (and not primarily by an external event like a business procedure).

Another difference between a business procedure and a business activity is that an activity is a logical unit of work: it is atomic. That means it is either performed completely, or it has no effects at all. A business procedure is not atomic.

A business activity is often composed by subactivities. For example, the business activity "checking validity of notice" consists of the subactivities "searching the customer", "selecting the correct customer from search result", "selecting the policy", "displaying the policy", and "comparing policy and notice". The difference between a business activity and a subactivity are that

-a subactivity is not a logical unit of work, -a subactivity presents typically one window or screen -within a subactivity, the sequence of processing is mainly driven by user input events.

The examples also show that a business activity or subactivity may create new business entities or access existing ones, like a customer or a policy, and request services from them.

We conclude that the important characteristics of a business process which need to be modeled by business applications and frameworks are -the hierarchical decomposition in a (often non-strict or conditional) sequence of procedures, activities and subactivities, -the creation of new and access to existing business entities, and -the services it requests from the business entities.

3.1 Club-Med Example

Orfali [OH97] presents, as an example, a complete travel agency mini-application. An applet on the client contains the presentation layer and the business logic. The server contains the business entity layer and the database access.

The application is, in our terminology, a business procedure that consists of one business activity, booking of vacations with a club med. The activity consists of several subactivities: presentation of all club villages and selection of a club, selection of a vacation week in the selected club, booking the selected week for the desired number of persons, displaying the bookings, and canceling a booking. Each of the subactivities presents a screen of its own for data display and data entry. There are two execution sequences to each of which a subset of the subactivities belongs.

One panel is associated with the application (i.e., the activity), in which all subactivity screens are presented by a card layout manager, each screen being like a card in a stack of cards, only the topmost one being visible. One user input handler handles all user events originating from the screens of all different subactivities. The handler switches the screens, when required, and thus switches implicitly from one subactivity to the next. The application design does not represent statically and explicitly the one-level hierarchy of activities and subactivities, nor the conditional sequencing of subactivities, nor which screen belongs to which subactivity. Though the application code is quite well structured, one has to analyze the dynamically control flow in order to get an understanding of subactivities, the screens which belong to them, and of the business entities each one accesses.

3.2 Fowler's Application Logic Tier

Fowler [F97] recommends to introduce an application logic tier in addition to the presentation tier and domain tier and describes the application logic tier as follows: "A selection and simplification of the domain model for an application. Contains no user interface code but provides a set of facades of the domain tier for the user interface. Converts .. types...". He proposes to "prepare a facade for each presentation. The facade has a feature for each element on the corresponding user interface. Each presentation thus has a simple interface to the domain model that minimizes any processing for the presentation other than the user interface."

A facade method is called from a presentation event handler. The method may contain a sequence of calls to business entity services, for example in order to calculate a result that is to be displayed by the presentation object. Such a sequence of requests of business entity services is business logic. However, it represents only a very small and detailed piece of a business procedure, typically only a piece of a business subactivity.

The application logic tier does neither represent business activities nor subactivities, nor the creation of new business objects nor the access to existing ones, since this is done from the presentation classes. Though application logic facades may be a very valuable mechanism for the mapping from presentation objects to business entities, they do not meet our requirements.

3.3 Coad

similar results from analyzing [CNM97]

3.4 San Francisco

The San Francisco [IBMSF97] user interface framework covers the presentation and business logic. It provides different views for a presentation of business entities and a mechanism, called maintainer, to couple views to business entities.

The business logic does not form a separate layer. Commands (similar to the command pattern) are an encapsulation of business logic which may affect different business entities. A command is called from a maintainer.

A command corresponds to a business subactivity and makes subactivities reusable. However, the San Francisco user interface framework does not provide any business logic construct on a higher level, such as business activities or business procedures (though it provides a transaction construct in the transaction framework).

The examples presented seem to be representative for well-structured business applications and frameworks. The state of the art is to represent, as a business logic unit, the piece of a business subactivity that is called by an event handler. It does not represent business activities and subactivities, nor does it relate the business logic pieces statically and explicitly. The only relation is by the dynamically control flow. No business objects are created, nor existing ones are made accessible in the business logic pieces. Thus, it is not statically visible and explicitly represented which business objects are used by which business logic pieces.

For business applications that are completely driven by user-input events, and for which no business procedures are defined as a sequence of activities and subactivities, the state of the art representation of business logic is adequate.

In many or most business areas, business procedures are not only driven by user-events. For these cases, business applications and frameworks should represent business procedures, activities and subactivities and their composition explicitly.

This can be done efficiently. We have implemented a simple and lean business activity tree client framework in Java and validated it in cooperation with a German insurance company. The business activity framework contains abstract classes for business procedures, activities and subactivities with methods for building a (static) business activity tree. It has a business procedure as the root and business subactivities as leaves. A business subactivities creates or accesses, and contains business objects and their views, and the business logic that is performed during the subactivity.

The business activity tree may be executed dynamically. Methods of the business procedure, activity and subactivity classes allow to start, commit or cancel each of them. When started, the view of an action is made visible in the parent view, when finished, it is made invisible.

[CNM97] P.Coad, D.North, M.Mayfield: Object Models; Prentice-Hall, Englewood Cliffs, NJ, 1997

[F97] M.Fowler: Analysis Patterns; Addison-Wesley, Reading Mass., 1997

[IBMSF97] IBM Technical Support Organization: San Francisco Concepts and Facilities, IBM Redbook, SG24-2157-00, 1998

[OH97] R.Orfali, D.Harkey: Client/Server Programming with Java and Corba; John Wiley & Sons, Chicester, UK, 1997

[OMG97] Object Management Group OMG: Business Object DTF, Common Business Objects; 1997

[S97] J.Sutherland, D.Patel, C.Casanave, G.Hollowell, J.Miller (eds.): Business Object Design and Implementation; Springer, Berlin, 1997