../oopsla97/OOPSLA'96OOPSLA'98 Business Object Workshop IV

A Business Object Framework Architecture

Hans Albrecht Schmid (schmidha@fh-konstanz.de), FB Informatik, University of Applied Sciences, Konstanz, Germany
Matthias Riebisch, Deutsche Post AG, Duesseldorf, Germany
Torsten Heverhagen, Informatik, University Essen, Germany
Harald Liessmann, Wirtschaftsinformatik, University Erlangen-Nuernberg, Germany

with particular input from

A.Bechtel, Haenchen&Partner, Leinfelden; W.Beneke, SD&M, Duesseldorf; A.Chugtai, Systor, Basel; R.Hefter, Kantonalbank, Zuerich; R.Knoll, RWG, Stuttgart; M.Lefering, DKV, Koeln from the working group on frameworks of the GI, Germany

1 Introduction

We advocate a 5-layer architecture for business object frameworks with the layers: presentation, business process, business entity, data access, and data storage, instead of the more common 3-layer architecture, and give reasons why the 5 layers are required. We have collected and list, for each of the layers, the responsibilities it must fulfill and problems which may arise, together with a reasoning.

The architecture layers should not be mixed up with tiers. A clean layer structure of an application is a precondition for distributing the application on different tiers. For example, the five-layer architecture might be distributed on a two-tier client-server system with a cut either between the business process and the business entity layer (resulting in a thin client), or the business entity and the data access layer, or the data access and the persistent storage layer (resulting in a very fat client). Similar considerations apply to a three-tier system.

2 Separation of Business Process and Business Entity Layer

Both a business entity and a business process is a business object, that means it represents a thing from the business domain [OMG97]. A business entity provides services embodying business rules, which are common to and used in different applications. For example, a banking account provides a service "deduct amount from balance", which checks if the given amount can be deducted from the balance, under the rules governing this kind of account. A business process, or, as a smaller part, a business procedure or a business activity, is a processing sequence that requests services from business entities; it is specific for an application. For example, the business procedure "teller-application withdraw money" uses the service: deduct amount of the business entity: banking account.

Business entities and business processes have, except for the taxonomic classification (both represent things from the business domain), very little in common. To list a few high-level differences:

1. A business process requests services from business entities. But a business entity cannot request services from a business process.

2. A business entity has typically a permanent state, which may be changed by the execution of a business process. A business process has, once its execution is terminated, no permanent state and even no permanent lifetime.

3. The sharing of business entities involves elaborate transaction mechanisms to prevent that parallel requests of state changing business services lead to wrong results. A (reentrant) business process may be executed multiple times in parallel without any particular provisions.

From these and more detailed differences we conclude that business entities and business processes should be separated since they have practically completely different responsibilities. A separation into a business process layer and a business entity layer is easily to be done, since business processes use business entities but not reversely.

3 Separation of Data Access and Data Storage Layer

As stated in section 2, the responsibility of a business entity is to provide services related to the business domain. A business entity should not be concerned with the storage and retrieval of its data. The data storage layer encapsulates the access to a specific data base. Thatmeans it hides the design of the data base as well as the specifics of the data base access and retrieval language. With a relational data base, the storage layer consists mainly of SQL-statements, either of dynamically SQL-statements that are interpreted, or of prepared statements, or of stored procedures which preprocessed and stored in the data base management system. With a IMS host database, the storage layer may consist of CICS transactions that contain IMS statements.

The objects of the data storage layer encapsulate this code. They provide methods like a method "retrieve account". The data access layer is the link between the business entities and the storage layer. It provides services to the business entity layer for creating a new business entity, for creating a business entity that exists already in the data base, and for updating and storing business entities. For the implementation, it uses services of the data storage layer.

In addition to the explicit creation of business entities (on a request from the business entity layer), the data access layer needs to perform an implicit creation when resolving references. The problem is that a business entity, which is being created, may contain references to other business entities, which are not yet created.

The business process layer requests the service from the data access layer to start a transaction or to terminate it. The data access layers is responsible for the transaction management. Typically, it will not implement it on its own, but use the transaction management of the database management system or of the DC-system like CICS.

4 Responsibility of Each Layer

We allocate to each layer the responsibilities it has to fulfill, and refer (when existing) to proven concepts or patterns that indicate how to implement a responsibility. Here, we give just a few examples, in addition to the items presented regarding the separation of the layers.

For example, consider consistency checks. Field-related consistency checks are a responsibility of the presentation layer. The reason is that a user should have fast feedback after entering a wrong input in a field. A user should not have to wait for feedback till all fields, or a group of fields of a business entity are entered. This responsibility should be implemented by providing domain-specific editors as data-entry and -display widgets. For example, for each kind of accounts with a differently structured account number, a specific account number editor should be provided.

Both field-related checks and cross-field consistency checks are a responsibility of the business entity layer. A service that changes the state of a business entity has to check both the field-related consistency of each parameter (field) and the cross-field consistency of all parameters. The justification for repeating field-related consistency checks is that data to be checked need not necessarily be passed from the presentation layer, but also come from other sources like batch data entry.

Another example are the responsibilities of the business process layer. As described in detail in the companion paper [SS98], the business process layer has the responsibility to provide constructs for modeling business procedures and their composition by a possibly non-strict or conditional sequence of business activities and subactivities.

As a last example, we describe some problems related to the responsibility: implicit creation of business entities, of the data access layer. One point is that a newly created business entity may reference other business entities, and so on, such that a large web of business entities may need to be created when all references are resolved. This causes two problems: first, the explicit creation of a business entity takes a long response time when connected with the implicit creation. Second, many, or even all, of the business entities implicitly created might even not be accessed in many cases. The problem is that the effort spent for business entity creation is wasted.

A similar problem occurs when a set of business entities with a large number of elements is created. Even if no reference resolution is done or required, it may take a large effort to create all business entities of the set. On the other hand, for example in a list box displaying the set, only a small number of business entity attributes, and a small number of business entities are displayed. So the response time and wasted effort are the problem.

One solution, the use of partial business entity proxies for all implicitly created business entities or members of a set, solves both problems. The partial business entity proxies contain only a few main business entity attributes like customer number and name, but no other attributes and no references. When another attribute is accessed, the proxy is replaced by the complete business entity and references are resolved.

Another solution for the resolution of references is to resolve them only to a certain depth, and to use smart reference proxies when terminating the resolution.

5 Conclusions

The business framework architecture describes with the architecture layers, the list of associated responsibilities and the reasoning the basic structure and services that a business object framework should provide. It allows the evaluation and comparison of business objects frameworks without considering the implementation.

6 References

[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

[SS98] H.A.Schmid, F.Simonazzi: Business Procedures are not Represented Adequately in Business Applications and Frameworks!

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

../oopsla97/OOPSLA'96OOPSLA'98 Business Object Workshop IV