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

The Business Component Approach

Peter Herzum and Oliver Sims - 13 July 1998

This paper describes the business component approach to large-scale distributed business system development. The business component is a single unifying concept that starts at system definition and requirements and continues through deployment and customization to subsequent system evolution. It does this with minimal transformations across the development life-cycle, and is supported by appropriate processes, architectures and tools.

Current software component initiatives are aimed essentially at build-time components for developers, and fall broadly into two categories: GUI or PC/NC-oriented components, and components aimed at enterprise object model implementation. However, if we are to address the multi-dimensional systems development problem for mission-critical, large-scale, multi-user, distributed business systems, we need a component concept that addresses the entire development life-cycle, as illustrated in Figure 1.

Figure 1

The business component approach requires, of course, a sophisticated software component technology for deployment and interoperability. We introduce such a technology, oriented to distributed systems, and which can exploit existing initiatives, later in this paper.

Also, a successful component model needs a strong concept of minimal dependencies not only at run-time but throughout development. A large business system cannot evolve if its software components have a large number of cross-cutting dependencies at any development phase. Current component initiatives seem to do little to address this.

The business component approach has at its core the concept of cooperating components at several different levels of granularity, that are autonomous and medium-to-large-grained, and which have minimal dependencies - from requirements analysis right through to system deployment and evolution. This approach builds nicely on today’s capabilities (including OO and basic component technology), providing an evolutionary path toward the industrialization of software.

The business component approach has four major dimensions:

The Business Component Concept

A business component is defined as follows:

A business component is the IS representation, from requirements analysis through deployment and run-time, of an "autonomous" business concept or process. It consists of all the software artifacts necessary to express, implement and deploy the given autonomous business concept as an equally autonomous, reusable element of a larger information system. What does this definition imply? Well, consider for example the business concept of "customer". A "customer" business component would appear as a single cohesive set of deliverables at each stage of development, along the following lines: The business component starts as a single concept that maps directly to the business domain space, stays a coherent unit throughout the development life cycle, emerging at the end as a set of software components that can be independently evolved as business requirements change and develop.

The Business Component System

Suppose that within some enterprise we identify the management of invoices as a useful autonomous business concept (the rules, techniques and heuristics for this identification are beyond the scope of this paper). We would then consider "Invoice management" as a useful process business component. However, the process alone is insufficient – we also need such things as the Invoices themselves(!), Vendors, etc.

The Business Component System (BCS) model expresses the whole of the business concept system being developed in terms of the set of business components needed to provide autonomy. It is a "high level" view of the autonomous business concept, , abstracting out the internal architecture of individual business components (described below) and the detail of the exact dependencies between business components.

For example, the grayed area in Figure 2 shows the graphical representation of the Business Component System for a simplified Invoice Management system. Each box is a separate business component. (later, we’ll address the distribution aspect of a business component). The Invoice Management process business component appears at the top. Underneath are the various business components – each independently-developed - that Invoice Management needs to use.

This figure illustrates two important aspects of a business component system:

The set of business components upon which a given business component actually depends (as defined by its dependency graph) constitutes a unit called a "business component package". Indeed, a BCSM can be seen both as a set of business components and also as a set of business component packages.
Figure 2

Figure 5 also illustrates the overall categorization of business components:

Business process components represent business activities in the domain itself. Examples are Invoice Mmanager, Order Manager (that is, supporting the Order Entry process), Inventory Manager and Credit Checker.

Business Entity Components represent the business concepts on which business processes operate. These include both data and repository objects and also the services that support them and their business usage (i.e. manage, maintain, group, link, select, present and convert). Examples are Invoice, Order, Product (as in a Product Data Management system), and Customer.

Utility Components are used by all higher-level kind of business components. Examples are Number Generator, Address Book, Currency Book and Calendar.

Note that these categories concentrate on the business components most relevant to the business viewpoint, and does not include other types of components, such as a database integrity manager, or a simple calculator. See also [OMG1].

Furthermore, business components at different layers tend to have certain characteristics: the lower in the BCSM, the more relevant the persistent aspects are, and the less relevant the processing and UI aspects. The opposite is true for higher level business components. This is illustrated by Figure 3.

Figure 3

 
Business component internal architecture

The architecture defines the separation of concerns relevant to distributed business systems, so that a business component is designed from the start for distribution. The key to how this is done is two mutually-supportive design points:

  1. A structural model that addresses directly the core design challenges of distributed business systems
  2. A distributed component technology that is the basis for autonomous development and deployment.
The structural model

As shown in Figure 4, a single business component consists of up four layers or tiers of application-level function. These layers are the user layer, the workspace layer, the enterprise layer and the resource layer. Each corresponds with a different logical area of responsibility - a separate area of concern [Sims].

Figure 4

The user layer is responsible for presenting the business component on the screen. Note that not all business components are necessarily presented to the user. For example, the user interface for the Order component may in reality be provided by the user interface of the Order Entry business process. Physically, the User layer is positioned as close as possible to the underlying screen system software - that is, on a PC or NC (or on the server for green screen).

The workspace layer is responsible for supporting the user layer, implementing local business logic, and for knowing who to "talk to" to get and put data. This layer works as a single-user buffer - the "workspace" for that user. It may contain business state and have non-shareable persistent aspects. It does not necessarily reside on a client machine; it could be on a departmental or central server.

The User and Workspace layers together form the "Presentation Logic Domain". This is responsible for supporting a single person through a presentation device (GUI or green screen). It represents the user’s object model of the system. This is the domain mainly addressed by publicly available component technologies like ActiveX and JavaBeans. It is also the less relevant domain from the point of view of large-scale, mission critical systems.

The enterprise layer is responsible for the main application processing aspects of a given business component. It implements most of the business rules of the system, the validation, the interaction between enterprise components and manages the business and several aspects of the data integrity of the system. This is the most critical layer from the point of view of large-scale, mission critical systems, is the least addressed by publicly-available component technologies, and is very often confused with the business component itself.

The resource layer is responsible for physical access to shared resources. Data in shared databases is the most common form of resource, and this layer is responsible for the persistence aspects of a business component. For example, SQL would be issued against relational data by code in the resource layer. Note that this layer does not make much sense without the Enterprise Layer.

The Enterprise and Resource layers together form the "Shared Resource Domain". This is responsible for the integrity of shared resources and for providing services based on those resources to multiple concurrent authorized requesters. The boundaries of the shared resource domain are defined by the boundaries of the underlying transaction management infrastructure software in its ability to manage ACID transactions.

The business component architecture solves some of the more pressing problems of distributed business systems, and provides a number of design guidelines. Two examples are:

Clearly real systems are more complex than the scope of the structure described above. For example, where is workflow, where are virtual enterprise aspects, where are business-specific views of the enterprise layer? These aspects and others are also addressed by the business component structure, but are beyond the scope of this paper.

The distributed component technology

Business component layers are implemented by "distributed components". A distributed (in the sense that it can be re-located) component is an independently-developed executable module [see OMG2]. It directly supports and enables autonomous development of the business component layer, and hence of the business component itself at build- and deployment-time.

For the application developer, the distributed component technology hides several computational complexities such as thread management, communications programming, concurrency management. These are handled by a run-time infrastructure which forms a "separation layer", and which also makes the distributed component technically independent of underlying software such as ORBs, MOMs, operating systems, etc. Thus the underlying technology can be changed without necessarily affecting deployed application code.

At run-time, and based on directives defined at design-time, the infrastructure composes one or more a distributed components into instances of network-visible "distributed objects". Each object type has an interface that is defined at design-time. Hence the set of composed distributed components comprises the implementation of the distributed object. This composition is illustrated in Figure 5, where we also see how a Distributed Component is normally (but not necessarily) constructed using an OOPL (OO Programming Language), so that language objects are visible only within the confines of the distributed component.

Composition of more than one: Optionally, the infrastructure can compose several distributed components into a single distributed object. This is generally appropriate where common application-neutral code (such as a model-view framework, persistence management or technical event handling) can be separated from business logic. It can also be used as a way of customizing a distributed component through specialization.

Figure 5

Messages sent from other distributed objects are routed by the infrastructure (plus underlying system software) to the distributed component code. (If more than one business component, then the message is routed to the bottom-most, which may then pass the message to the next higher one. This provides a useful "inheritance" mechanism.)

Discussion at greater depth is beyond the scope of this paper. However, one final point should be mentioned: messages between distributed objects carry metadata about message parameters. The receiving distributed object is responsible for message interpretation. This enables interfaces to be evolved without necessarily requiring client distributed objects to be re-built and re-deployed.

The Distributed Component approach provides significant advantages, including:

In summary, the distributed component approach provides, for each layer of the business component, both physical plug/play software components, separation from underlying computational complexities, and a distributed object capability that greatly reduces inter-object dependencies. It does this by providing a clear differentiation between distributed objects and other OOPL objects that are not distributed.

Business component-centered development process

This section expands on some important aspects of the business component as a unifying concept throughout the whole software-product life cycle, taking a 20,000-foot overhigh-level view of the development process.

In a business component approach, the development process is centered on autonomy - of the BCSM, of the business component packages, of the business components themselves, of the business component layers, of distributed components, etc. However, there is a continuing tension and dynamic [OS: What does "tension and dynamic" mean? Also, your note against this para said "continuous integration and testing".] between the integrity of the system as a whole and the various units of autonomy. Hence a crucial aspect of project management is to maintain system integrity (at all levels) while preserving the independent development of the various autonomous artifacts.

From the beginning, the software life-cycle is supported either by an in-house business component system model, or by one acquired from the market (or a combination of both). If the project is started from scratch, the candidate components of the system are identified, and a candidate BCSM is drawn up - before requirements gathering. But how can the components be known before requirements gathering? The answer is that the candidate business components follow patterns known from experience, and can be identified with minimal information (guidelines for this are beyond the scope of this paper). An analogy is found in the design of a new computer: the exact characteristics of each computer component may not be known, but the kinds of components that make up a computer are certainly known at an industry level.

Requirement gathering and use cases are organized around components. A business process analysis normally fits easily into a well-conceived business component model. For example, system-wide use cases and system-wide processes are naturally owned by a business process manager component, while generic use cases (in the Jacobson sense) correspond to utility process business components.

Similarly, analysis, design, implementation and testing are organized by business component for all aspects (modeling, conceptual, organizational, file structure, repository , etc.). Each layer of a given business component (or, more precisely, of a given business component package) can be tested independently from the business components using it. With the distributed component technology, a business component can also be tested independently of other business components on which it depends.

The application architecture (the set of available generic application-level services) is centered on business components. For example, errors and error handling, reusable classes, application types and, database architecture, are designed to take into account the nature of distributable components and business components, together with and the need to preserve autonomy of development and system-level development integrity.

All these aspects result in:

Although a more detailed discussion of the full role of business components in the software development process is beyond the scope of this article, one aspect that has proven critical is the "project management model". This section is concluded with a brief discussion of this vital aspect of system development.

Project Management Model

The Project Management Model This includes everything related to the organization of the project, its management, the development environment, configuration management and versioning, team composition and size, etc.

Project management is organized around business components. For example, starting from the business component system model, the project is sized, estimated, planned and tracked in terms of:

  1. Business component system view: the highest level view, in which the system can be seen as a list of business components, abstracting the details of individual business components and their architectural structure. This is the level at which an "executive summary" project plan and progress tracking is shown. A good time scale for this view is at the month level.
  2. Business component package view: this defines what is required to develop an individual business component, and also defines its proper development sequence. This view concentrates on the component’s external dependency graph with less attention to the system view and the internal architecture of a given business component. That is, the package view enables evaluation of the availability and dependencies of required software artifacts produced by other teams. A good time scale for this view is at the week level.
  3. Business component view: how to develop the individual parts of the business component - primarily its distributed components. A good time scale for this view is at the day-to-day level.
The development organization is organized to support the "top-down driven" bottom-up development, which implies: This organization enables business process reengineering of the software development itself, organizing it around development units that give value to the end users, where the value is the complete implementation of given functionality (i.e. requirements) with minimal external intervention. Business components have the proper granularity such that a small team (1-4 people) could implement it from requirements to deployment.

The development environment is structured around business components, including the repository and the directory structures for non-repository-based deliverables from requirements to deployment. For example, the requirements and feature lists, the table schema and initialization data, source code and test drivers, configuration files, etc. are all considered integral parts of the business component, including their physical storage.

Given the intrinsically iterative nature of the development, configuration management aspects of a business component development are more critical than in any other development technology. For example, since it becomes possible to easily develop, modify, enhance any aspect of the internal aspect of a business component with minimal impact on the system, it becomes critical to properly manage the dependency graph of a given business component and of the versions of the dependent business components that makes up a given business component package.

Conclusion

In this paper we have presented the business component approach to system development. In this approach, the application becomes a set of independently developed and deployed business components, independently addressable and accessible at run-time by other business components. These collaborate to deliver the desired functionality.

The business component approach is centered on a set of concepts and technologies (the business component, the business component system model, the business component package, the distributed component, etc.) that address the multi-dimensional aspects of large-scale distributed system development. We anticipate that this approach may result in a decrease of one order of magnitude in the costs and complexity of software development.

Some might argue that business components are just a re-arrangement of existing technologies. However, the business component approach is not simply a refinement of the object-oriented approach, but introduces a revolutionary mindset - with new technologies, new challenges and new solutions - where all aspects of development and deployment are centered around a unifying concept: the business component.

In this paper, many aspects have been simplified and generalized. For example, no mention is given to the various levels of standardization required to truly enable an industry-wide business component-based development. Again, an important aspect of the business component revolution is that the shape of the application changes, to the point that the whole concept of "application" needs to be redefined and with implication on all aspect of software development, including how the "application" is sold and marketed.

Finally, we would note that the business component approach may not be the silver bullet that will magically resolve all the issues in the software industry. But perhaps it is the silver from which an appropriately skilled software manufacturer could build the bullets…

References
 
Eeles  Peter Eeles, oliver Sims, "Building Business Objects", Wiley 1998, ISBN 0-471-19176-0 
OMG1  Peter Herzum et al., "Standardizing Business Components" (OMG Manufacturing Domain Task Force response to BODTF RFI), OMG Document bom/97-10-05 
OMG2  SSA’s "BOF" Submission (to OMG BODTF RFP-1 "Common Business Objects and Business Object Facility"), OMG document number bom/97-11-03 
Orfali  Robert Orfali, Dan Harkey, Jeri Edwards "The Essential Distributed Objects Survival Guide", John Wiley 1996, ISBN 0-471-12993-3 
Sims  Oliver Sims, "Business Objects - Delivering Cooperative Objects for Client/Server", McGraw-Hill 1994, ISBN 0-07-707957-4 
Szyperski  Clemens Szyperski, "Component Software - Beyond Object Oriented Programming", Addison Wesley 1997, ISBN 0-201-17888-5 

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