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.
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.
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.
The SanFrancisco framework
(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.
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.
core business processes
common business objects
foundation object model classes
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.
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.
Discussion
[11]
-
[up]
[top] -
[I]
[II]
[III]
[IV] -
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12] -
[A]
[R]
|
Hush Online Technology
hush@cs.vu.nl
12/30/99 |
|
|