Business objects -- SanFrancisco framework

Instructor's Guide

intro, objects modeling, simulation, visualization, legacy summary, Q/A, literature
What are business objects? From the perspective of typical business end-users, that is accountants, engineers, managers, business objects provide access to corporate information. Traditionally, corporate information resides in legacy databases, and access means looking at tables and pasting these into documents.

Business objects

Designer -- define data model

Business user -- deploy views
slide: Business objects
 Even within this kind of limited usage, it makes sense to speak of business objects, as a way to shield the user from the actual structure of the underlying (relational) database and the use of query languages such as SQL to obtain the actual data, see  [BO]. Business objects, as a metaphor for bringing information to the desktop, allow for accessing corporate databases in a transparent manner, and for building the tools that allow business end-users to extract information from the database in a flexible way, and to use this information for further analysis and manipulation. In  [BO], a distinction is made between three types of end-users involved in the construction and use of business objects. The designer, who creates the objects that act as an interface to the database, the actual end user, who uses these objects to obtain information (and thus implicitly creates queries), and the supervisor, who provides users with access to the various regions or universes defined for the database. The actual business objects toolset, described in  [BO], provides a GUI-based drawing tool to create queries by composing objects and creating relations between objects.

Business objects, then, are a means to access corporate data. This is a first, but nonetheless important, step. An immediate advantage, obviously, is that business objects may be defined according to actual business needs, instead of being dictated by (relational) technology. More generally, business objects may be regarded as abstractions underlying the definition of business processes. In the following we will explore whether we can generically define business processes and whether there is a collection of abstractions that we may denote as business objects.

The SanFrancisco framework

\label{San Francisco} The SanFrancisco framework (IBM) is an example of a framework meant to develop business applications. A business application, as we understand it here, is an application that deploys business objects to (partially) automate business processes, such as order or warehouse management.

(Business) frameworks
slide: Business frameworks
 A framework is a collection of components, but may also be considered as a generic solution for a class of problems. It sets a frame of mind for solving problems and provides the means to realize solutions in software. In practice, adopting a framework means accepting a set of architectural constraints.
slide: The SanFrancisco framework
 As a framework, SanFrancisco aims at providing both a software solution for implementing business applications, as well as a collection of concepts or strategies to develop effective business applications.

In the white paper accompanying the introduction of the SanFrancisco framework, we read that the project was started when several software vendors asked IBM to help in modernizing their application products. These vendors asked for help because there were several barriers that prevented them from modernizing their applications themselves. Barriers such as (1) the risk in moving to new technologies (such as client/server and the Web), (2) the need to retrain their development staff to effectively use an object-oriented approach, (3) the cost of change. As the white paper states, as software developers they needed some basic infrastructure, and most companies could not afford to develop this infrastructure themselves. The SanFrancisco framework provides such an infrastucture, and moreover, the white paper claims, an object-oriented infrastructure that provides a consistent application programming model, with many well-tested services and a collection of core business process components and common business objects.

core business processes
  • Accounts Receivable/Payable
  • General Ledger
  • Sales Order Management
  • Purchase Order Management

common business objects
  • Business Partner, Address, Number, Currency

foundation object model classes
  • Command, Entity, Dependent, Collection/Iterator, Factory
slide: SanFrancisco object layers
 The SanFrancisco framework offers three layers of functionality, business processes, business objects, and foundation classes, each of which may be used and extended by developers to build their applications. The process layer itself may be regarded as a collection of frameworks, as indicated in slide sf-layers, which build upon the business objects and foundation layers. Note that the foundation layer contains realizations of the by now familiar patterns, see chapter 2.
slide: Refining quality control
 The SanFrancisco framework is an object-oriented framework. It allows for the classical way of extending the framework, by inheritance. As an example, think of a Receipt object which may contain an arbitrary number of Purchase Order Line instances, see slide sf-example. Purchase Order Line has an attribute Quality inspect which is read by Receipt to determine whether quality control is needed. This reflects the default (business) logic for processing orders as defined by the framework.

To enhance this logic, that is to be able to execute more strict quality control, one may derive a new Receipt class from the old Receipt class and override the method by which to determine whether quality inspection is required, for example by including a check on the supplier, previous outcomes of quality control, or whether it concerns hazardous materials or high-value products.

As a remark, note that this approach assumes that the business logic is to a large extent hardwired in the (structure of the) classes of the framework, whereas a decoupling of the logic and the actual processing might be preferable.

Discussion

The SanFrancisco framework is based on Java technology. Its introduction marks the transition towards client/server and Web technology, and clearly addresses the need for many companies to migrate to the new technology. Apart from technological considerations, however, the major issue in adopting a framework such as the SanFrancisco framework is whether it sufficiently reflects emerging consensus and standards concerning the definition and utilization of business objects and processes. Related efforts of business object standardization are undertaken by the OMG. On the technology side, it is difficult to establish who will win the component war, Java, OMG CORBA, or Microsoft (D)COM and ActiveX.