Enterprise integration of intelligent business objects
Business Object Redefined
The business object may be redefined as a digital implementation of a real world item,
which contains information and behavior needed to perform a specific task at a specific
point in time. Other information and behavior, which also define and comprise this
object, may be defined such that the object may assume these properties as needed.
Why would someone propose such a definition? Object definitions change over time, as
real objects do. Many telecommunication devices could at one time only exist in a
central office. Important attributes included a limited temperature operation range and
the device heat output per unit of time. They could only operate in a climate-controlled
environment. Due to the utilization of integrated circuits and the use of different
materials, temperature tolerances have grown and heat production has diminished. This
has occurred to such an extent, that for most devices these attributes or properties are no
longer of interest.
Change within an object, although important, is only one driver for change. Fifteen to
twenty years ago attempts were made to have Engineering Models support taxation
requirements. Software and procedures to count and measure facilities within tax
districts were developed. Due to the large volume of facility data, the complexity of
political boundaries, the brute force algorithms deployed, and the speed of 1/0 and
processors at the time, this failed. The decision then became one to require Engineers or
records people to break conductors into multiple records at political boundaries and insert
one or more tax codes into each record. Today, the volume of facilities is much higher
and tax boundaries are no less complex. However, better algorithms and processor
speeds no longer require this established practice. In spite of the ability to easily do today
what failed a decade ago, conductors are still being broken into new features at tax
boundaries and "hard coded" with taxation designators. This results in more facility
items than need to exist to represent the engineering model. This also requires
considerable rework of existing facilities when a tax boundary moves. This creates
additional arbitrary data or results in miscoded data, or, more probably, both.
The problem of tax boundary to facility data is a good example of why business objects
and practices should change over time. Changing data is not itself the greatest reason for
the variable and distributed definition of business objects. The most important reason is
object size.
Original silo implementations were on large computers, mainframes, and mini-computers
with attached terminals. These terminals depended on the main computer processing
power, even when they contained sufficient memory to store a bit mask for a display or
text for a form. The slowest area of processing was then 1/0 or the ability to get the data
from a storage device into the processor and to put any changes back to storage. From
there, technology advanced to where the distance from the storage to an intelligent
terminal, with some processing power, could be increased. The age of client/server was
born. Still, the gating factor on performance was 1/0. The size of the feature was still
important.
As multi-tier architectures become dominant, one factor remains. The ability to provide
performance is most affected by 1/0. In this environment, 1/0 includes initial retrieval
from permanent storage, bandwidth requirements for communication to an application
server, and bandwidth requirements for communication to the client. In spite of
tremendous enhancements in processing speed, device controllers, and the speed of
storage devices themselves, object size is still an issue. An object, which must be
everything to everyone, is obviously much larger than one that serves a single role, at a
point in time. This is true as the object relates to 1/0 requirements. In another sense a
distributed object is actually larger due to its need to exist in multiple parts, all of which
must be maintained with a common access key and the knowledge of how to reach all
parts. However, this can be implemented in a manner to not impact 1/0 for time sensitive
operations.
Technology Today
At one time, distributed database was a concept. Today databases, whether relational or
object, can deal with an object split across multiple storage mediums and processors.
These increasingly can support attributes or properties, which do not fit into a simple data
type of the row and column implementations of the past. We have the ability to move to
an Aristotle view of an object.
What technology is required to support this? The hard part in the support of distributed
database was ensuring that all parts of a transaction completed successfully or else none
did. Transaction support is an item needed to support distributed business objects today.
This is why Java and NT 5.0 both offer transaction capability. Just as separate database
vendors offered incompatible distributed algorithms originally before moving to the
ability to integrate, so today the language versus operating system implementations are
incompatible. In the past, one had to decide whether to use DB2, Oracle, or Sybase as
their sole database, if they wanted distributed capability. Today one must decide whether
to have distributed objects implemented as DCOM or Java. In the future, language or OS
implementations should become more compatible, just as today a distributed database can
cross Informix and DB2, for example.
