Business Object Management Special Interest GroupObject Management Group, Inc. Framingham Corporate Center 492 Old Connecticut Path Framingham, MA 01701-4568 (508) 820-4300
This white paper has been produced by the Business Object Management Special Interest Group (BOMSIG) of the Object Management Group (OMG). It is available in paper or PDF format from the OMG server as document 95-4-1. See http://www.omg.org/.
Cory Casanave, Data Access Corporation
Doris L. Owen, 3M
Carol Burt, BellSouth
Ken Burrows, Eastern Electricity
Martin Anderson, Integrated Objects
Timothy Hung, IBM
BOMSIG members (listed)
For more information on OMG business objects, the OMG Business Application Architecture, BOMSIG, or the OMG, please contact the OMG at the above address or
Table of Contents 3
What Are OMG Business Objects? 6
Business Objects Are Not DBMS Tables 10
Business Objects and Legacy Systems 10Existing Business Objects 12
What Is the OMG Business Application Architecture? 13
How Does the BAA Fit with Tools and Languages? 13
How does the BAA fit with other application architectures? 14
Advantages of OMG Business Objects and the BAA 15
How the BAA fits into a business 18
Your business model 18
Business objects and implementation components 18
Presentation and system interfaces 19
The outdated concept of "application" 19
The Requirement for OMG Standards 20
Options for an application architecture and framework 20
Goals of standardization 21
What needs to be standard? 22
Existing OMG Standards 22
Required New Standards 23
What Does Not Need to Be Standard 24
Domain (Application) Object Interfaces 24
OMG Business Application Architecture Reference Model 25
The BAA Protocol 29
Specification of the Interfaces 30
Specialization Of Business Objects 31
Terms Used 31
Further Reading 32
The quality of a company's information system has become recognized as a strategic corporate advantage. Information systems have become the backbone of the modern enterprise and as such are crucial to its functioning. An organization with the appropriate information tools can take advantage of business opportunities quickly and can adapt itself to changing business requirements.
Despite advances in hardware, software, client/server, right-sizing, distributed computing and better methodologies, corporate information processing continues to fight the complexity, inflexibility and poor performance of its current mix of solutions.
As the enterprise has become more dependent on its information-processing capability, this same growth of dependence has put stress on that very capability. Poor performance, software backlogs and inflexible systems are, unfortunately, the norm.
Many solutions have come (and some have gone) to help with this problem. Some of these solutions- the ones that hold the most hope- are difficult to integrate and move to from existing technologies. Client/server and distributed-object computing in particular are seen as hopeful solutions- and are hard to integrate.
Products, services and techniques that help overcome these problems can be critical to the success of the enterprise. OMG Business Objects and the Business Application Architecture are intended to enable such products, services and techniques by creating a standard framework for business applications, using OMG's CORBA.
It is not the intent of this paper to define or specify a the business application architecture or a business object protocol. Rather, it is our intent to identify the advantages, need and practicality of such standards inorder to foster further work in this area. In this paper we outline the general shape of such an architecture so as to foster a better understanding of our intent.
Object oriented systems have been around for about 20 years, but have only gained widespread acceptance in the last five years. In particular, objects have come to dominate the user interface and system programming. Objects are visible to users as icons, boxes and windows on a screen that they directly manipulate. This style of user interface (originally developed by Xerox PARC) has spawned a huge advance in the ease of use, esthetics, and power of end-user software.
Objects have also been used extensively by advanced programmers in systems software and applications. Objects are now part of the implementation of almost every major piece of software. While not fully exploited, object-oriented programming is currently helping make software more reliable and reusable.
Paradoxically, objects have not been widely used to represent the business itself. A business can be "modeled" in terms of objects that make up and reflect it. Objects can represent inventory and invoices, customers, and salespeople. Objects can also represent events in a business, such as purchases, sales, and other types of transactions.
Modeling the world as objects and then implementing them in an object-oriented system is the basis of object-oriented technology. It is time that the power and ease of understanding inherent in objects be applied to the business itself. Anything that is related to the finances, products, or customers of an enterprise can be a business object and work as part of a cooperative business object system.
Put another way, business objects represent things, processes or events that are meaningful to the conduct of the business. Business objects can be distinguished from programming objects such as arrays and I/O channels or from user interface objects such as buttons and windows. Business objects can also be distinguished from system objects such as your word-processing program. Business objects make sense to business people.
The following Description of an OMG Business Object has been adopted by OMG BOMSIG, and is included here for reference.
OMG Business Objects are representations of the nature and behavior of real world things or concepts in terms that are meaningful to the business. Customers, products, orders, employees, trades, financial instruments, shipping containers and vehicles are all examples of real-world concepts or things that could be represented by Business Objects.
Business Objects add value over other representations by providing a way of managing complexity, giving a higher level perspective, and packaging the essential characteristics of business concepts more completely. We can think of Business Objects as actors, role-players, or surrogates for the real world things or concepts that they represent.
Business Objects can act as participants in business processes, because as actors they can perform the required tasks or steps that make up business processes. These Business Objects can then be used to design and implement systems in such a way that these systems exhibit and continue to maintain a close resemblance to the business that they support. This alignment is maintained because object technology allows the development of objects in software that mirror their counterparts in the real world
Business Objects allow an enterprise to communicate, model, design, implement, distribute, evolve and market the software technology that will enable them to run their business. The implications of Business Objects include:
Communication: Business Objects provide common terms and ideas at a level of detail which can be shared among business and technical people to articulate and understand the business in business terms.
Modeling: Business Objects have certain characteristics and behavior which enables them to be used naturally in modeling business processes, and the relationships and interactions between business concepts.
Design: Business Objects represent real world things and concepts which enable design effort to be concentrated in manageable chunks.
Implementation: Business Objects have late and flexible binding and well defined interfaces so that they can be implemented independently.
Distribution: Business Objects are independent so that they can be distributed as self-contained units to platforms with suitable installed infrastructure.
Evolution: Business Objects can be used in a variety of roles and evolve with the needs of the business. They provide a means for integrating, migrating and evolving existing applications.
Marketability: Business Objects have the potential to be commercially distributed and combined with Business Objects from other sources to facilitate a market in Business Objects.
More formally, a Business Object and its component parts are defined as:
Business object: a representation of a thing active in the business domain, including at least its business name and definition, attributes, behavior, relationships and constraints. A business object may represent, for example, a person, place or concept. The representation may be in a natural language, a modeling language, or a programming language.
Business name: the term used by business experts to classify a business object.
Business definition: a statement of the meaning and purpose assigned to a business object by business experts.
Attributes: facts about the business object relevant to fulfilling its business purpose.
Behavior: the actions a business object is capable of performing to fulfill its purpose, including: recognizing events in its environment, changing its attributes, and interacting with other business objects.
Relationship: an association between business objects that reflects the interaction of their business purposes.
Business Rules: constraints which govern the behavior, relationships, and attributes of a business object.
Background: The Description of a Business Object as adopted by BOMSIG characterizes a business object, its parts and the domains in which it may exist. The current definition is missing some components which should be considered prerequisites to having a "formal" definition.
Purpose: This proposal recommends candidate areas for extension of the existing definition. These are areas in which the existing definition could be made more complete and "formal" through specifying things not yet addressed in the base definition. This proposal does not recommend change to the base definition included on the previous two pages.
Discriminating Tests (i.e. how to identify a business object when you meet one)
In order to differentiate Business Objects from non-Business Objects, these tests may be applied:
Absence of Behavior: Data structures or attributes devoid of tightly-coupled behavior are not Business Objects. Entities (as used by data modelers) or tables (as used by data base designers) may for the basis for identifying or designing Business Objects, but alone they are not Business Objects.
Process Only: Program code devoid of tightly-coupled data structure is not a Business Object.
Noun-Centricity: Business Objects represent things or concepts, not process or actions. They tend to represent nouns, as opposed to verbs.
Technology Objects: An object which represents software or computer technology is not a Business Object. Examples of software or computer technology objects include (1) any object which implements part or all of the Object Request Broker, Object Services or Common Facilities components of the OMG Object Management Architecture; (2) components of a graphical user interface, such as menus, buttons or data-entry or display fields; (3) parts or services of an operating system, data base or network interface. Technology Objects would be Business Objects only as instances of the product sold by a software or computer technology vendor.
Application Objects: Applications are not Business Objects, though they may exhibit object-like properties by way of an application program interface (API) and may be composed in part of Business Objects. Software applications are clients of the services of Business Objects.
Required Properties (i.e. characteristics a business object must exhibit)
To qualify as a Business Object, the following required properties must be present
Encapsulation: logical or physical tight coupling of concept-related behavior and constraints with concept-related attributes.
Business Identity: Each instance of the type must be identifiable in business terms as a member of that type, and as an instance distinct from other instances.
Business Objects may, at first, seem much like tables in a relational DBMS, since tables also represent business information. In some simpler cases there may be a direct correspondence between a business object and a DBMS table. But in most cases the business objects will be implementing rules and processes beyond the capability of a DBMS. They may be combining multiple tables, managing distribution or managing information that is not even stored in a DBMS (like the NYSE ticker line). Business objects represent multiple tables, processes and rules at a higher level than the DBMS table.
Business objects can be built using any form of new development tool or they can be built on top of existing software.
For example, let's assume you have an application with 800 users running on a proprietary DBMS and there is just no way for you to flip a switch and have these users run on a newly designed system. However, you would like to add some new functions today and then transition to a new, more powerful DBMS over time-HOW?
A business object "wrapper" is written in the language of the existing DBMS (business objects do not have to be implemented in an object-oriented language) using a business object framework. The relationships, rules, and procedures for using the object are implemented as part of the business object using the existing libraries and methods of the legacy application. This new business object can then be used as part of the new business object architecture while still using the existing legacy application. Critical new functions can be added on top of the business objects-using object techniques without changing the legacy application. Conceptually, the user interface of the old program is replaced by the Business Object framework.
New presentations are designed with a business object toolkit or another language to give users a consistent view of their applications through the business objects. These new presentations can be used at the same time as the original programs.
As time permits, the legacy application can be replaced-piece by piece, until it is gone. Once the legacy application is gone, you are free to re-implement the business object with more current DBMS systems and tools without changing the other business objects or applications (presentations) that depend on it.
Legacy applications may be wrapped at the DBMS level (as in the above example) or at the application level. Business object wrappers my communicate directly with the legacy programs which may or may not store information in a DBMS.
It is a unique feature of the business object architecture that it works so well for building new applications and providing a transition strategy for legacy applications or data.
Frameworks, adapters and re-engineering tools can be produced to assist with the transformation of legacy systems in any language, on any DBMS or transaction processor.
Not all business applications are candidates for being wrapped by business objects. Considerations for wrapping business objects are as follows:
In wrapping a legacy application we are making the assumption that the application fills the needs of the business. As the analysis of the business needs progresses it may be found that the legacy application is so dated in regards to the enterprise needs that attempting to wrap it as part of a new solution is impractical. A system that does not properly model the business needs tends to complicate the design of other components that must compensate for the design flaws.
Re-engineering legacy applications can be as much as 10 times more expensive than re-implementing from scratch, anything but the most minor change may invalidate the cost savings of using the existing system.
If however, the existing application is functional and meeting the needs of the business, it should be maintained, at least until more urgent needs are addressed with the new technology.
Many existing applications depend on costly support environment and staff. Consider the economic return of expediting the cross-over to a more efficient environment.
Due to their more reusable nature, existing business objects may be available that can replace older legacy systems. Purchasing components is almost always cheaper than building from scratch.
The costs for implementing business objects from an existing design tends to be much lower than the cost of traditional application development. However, the learning cure and initial costs must be considered when making a re-use Vs buy Vs build decision.
A relatively stable application area is more of a candidate for re-use of legacy code than is one that is constantly changing. A business object system is designed to be much more resilient to change and as such should be used first in very dynamic situations.
Business objects wrapping a legacy application will have performance penalties. The degree of those penalties can only be determined on a case-by case basis that considers environmental factors, application factors, use factors and the tools used to wrap the application.
Traditional "monolithic" applications tend to implement and control sets of business objects. The business objects that are tied together in this way will probably need to be re-implemented at the same time. Identify the dependent and independent business objects by examining the legacy applications.
In all probability, all non-business object legacy systems will eventually be re-implemented directly as business objects. But, this transition can be gradual. By targeting the high-impact and/or costly legacy applications first a smooth transition can be made.
Many existing applications are built (or being built) on the principles of business objects:
These existing business object systems may be constructed with a custom or proprietary application framework. Such systems will be very easy to convert to the BAA once it is available. Businesses may want to review existing applications and development projects to see where such techniques are being used. Application built with business object methods can be expected to have a longer life and shorter development cycle than other applications due to their use of object design an implementation techniques such as encapsulation and polymorphism.
The OMG BOMSIG is surveying such existing systems; we hope businesses will provide us with information on theirs. Please contact the OMG BOMSIG for a copy of the survey questionnaire.
Note that there is no direct correlation between using an object-oriented language and building a business object system. Many business object systems have been implemented in procedural languages and, unfortunately, object-oriented languages have been used to implement non-object-oriented designs. An object-oriented language makes it easier and more natural to build business objects, but it is not required.
The OMG Business Application Architecture (BAA) represents an application architecture and a protocol for cooperative business. The BAA, together with an appropriate implementation, will provide a architecture in which business object attributes, relationships, business rules and application rules can be implemented. Objects implemented in this way will then be interoperable with other business objects.
All information systems have an architecture. That architecture may be formalized and structured, or it may be informal and implied. But for a system to operate, there must be agreed-to conventions, structures and protocols - this is the architecture. Most "application development systems" combine an application architecture with tools and sometimes a language to help implement that architecture. The architecture becomes part of the way you use the system.
The application architecture can be thought of as that layer between the high-level business objects being implemented and the low-level languages, operating systems, object request brokers and DBMS systems. As part of the architecture, a "protocol" exists for the components of that architecture to interact. For the architecture to be standardized, the interfaces must be defined. Within OMG, interfaces are defined in IDL.
The BAA is not a standard business model, it does not attempt to specify the standard or common components, object structures or processes in a business. It is a standard way to represent any business model as a structure of objects.
The business application architecture does not attempt to specify the correct or best method for implementing business objects. Any combination of computer languages, 4GLs, design tools, frameworks, rule-based systems, and expert systems may be employed to create the business object. Frameworks and other forms of tools and components are anticipated as products which assist the developer or user in defining and implementing business objects that enable the business object protocol. The BAA and underlying technologies provides an interoperably layer that allows these differing systems to work together.
It is expected that higher level interfaces will be provided so as to shield application experts from the highly technical IDL interfaces. These higher level tools and frameworks will provide the BAA IDL interface standard interfaces as a "package" that application developers can use more easily. The high level frameworks and tools will provide interfaces appropriate for directly defining business objects, attributes, relations and business rules. In that these high level interfaces may interoperate via the BAA protocol, we do not expect these interfaces to require standards.
Note: It is possible for developers to create business objects that directly implement the BAA protocol; however, this protocol must expose some of the complexities inherent in a distributed-object system and for this purpose, implementation frameworks and intermediary components are useful in simplifying the job of the application developer. However, developers are free to use (or extend) the BAA protocol directly for special needs.
For support of legacy systems, business object frameworks may be built for COBOL, RPG-II, IMS and CICS. While the "source code" for these systems would appear completely different, the resultant application architecture would be the same and the objects would be interoperable.
Many applications architectures exist for both business and non-business applications. In that such architectures must be able to co-exist with each other and the BAA, the BAA must be sufficiently general to facilitate the interaction of applications with other architectures. The "wrapping" facility previously discussed provides the capability to implement the BAA protocol in conjunction with other architectures-it is not an exclusive option. Thus the BAA in intended to be the interaction protocol for application components in a variety of architectures.
Architectures for applications outside of the business domain generally become part of the implementation of business concepts represented as business objects. For example; a software development company may have the source code to its application in a configuration management system using its own application architecture (such as PTCE), the business system may refer to a single entity which is the software project. The implementation of the "project" business object may use the configuration management system to provide business information (such as project status) to the business application.
It is unclear at this time whether the BAA can be sufficiently general to represent ALL business applications. It is our hope that other architectures can be built as extensions to the BAA as opposed to alternatives to the BAA. Such a determination can only be made after further work is done in this area.
By maintaining a simple, standard interface to objects relevant to your business, your information facility becomes much more flexible. Changes in your business policies or structure can be reflected directly by the business objects, and applications based on these will frequently adapt automatically to the changes. New business objects and business structures can be developed and deployed while still maintaining the old interfaces for a cross-over period.
Since the implementations of business objects directly reflect the structure of your business, the business objects and applications are easier to produce and maintain, giving you a more responsive information-processing facility.
The rules, policies and procedures of an enterprise can become quite complex and interrelated. By having a single, known place to put each rule (and express it only once!) the management and evolution of your rules, procedures and policies become much less complex.
The business objects operate at a "high" level, one that is understood by business people. Your entire organization-and in particular top management, can participate in the design of its information model and business rules without having to be burdened by implementation details. Business Objects use business names and terms.
Legacy systems and data can be "wrapped" as business objects to become part of the new generation of applications without discarding the value of the legacy applications.
Standards which were intended to insulate the business from becoming dependent on a particular vendor tend to be insufficient for real-world implementations. As a result, the information systems department must depend on proprietary extensions and features that again "lock you in". With business objects, the enterprise's own information model becomes the standard, insulated from the DBMS or tool "du jour". Advances in technology and new standards can be more easily integrated with your working system.
The business object architecture is open and extensible. Interfaces and capabilities can be added as required for the business's need. Even the business architecture itself can be implemented on top of any distributed-object standard. As standards come into place, business objects become interoperable and tools can be provided to create and maintain them.
Any type of tool can be used to implement business objects or exploit their existence. Advanced Business Process Re-engineering tools, Workflow systems, CASE tools, 4GLs or 3GLs can all be employed to create or use business objects. The high-level nature of business objects makes them ideal for advanced decision-support systems and report writers.
Since business objects can employ advanced distribution mechanisms "behind the scenes" and the same or a related business object can be distributed across multiple systems, the architecture is infinitely scaleable. The applications are insulated from changes made to scale the system.
Business objects represent well-defined reusable components for application development. Reusable components leverage design and development efforts, increasing responsiveness and reducing costs. Some business objects may even be purchased from third-party vendors and integrated into an existing system.
Since business objects directly represent the business model, reuse becomes natural. The business model and objects (which have a natural order) become the library of reusable components.
Since business objects are visible to the "desktop," any program or user can access and safely manipulate the objects of the business. Power users and end users get unprecedented accessibility to enterprise resources.
Business objects are safe to manipulate because data integrity and business rules are enforced by the business objects.
Business-process re-engineering (BPR) is heavily dependent on a strong and flexible information system. Business objects are an ideal way to implement an information system that supports BPR. The type of analysis done to "re-engineer" a company can produce the kind of business model that business objects can implement.
Ivar Jacobson, in his excellent book Object Advantage, shows how BPR and object-oriented analysis can be combined and complementary.
By providing a pre-built application framework, the user is in a better position to concentrate on the application problems. Users who are forced to build an application framework "from the ground up" can face a huge effort in design and implementation that has nothing to do with their business problems. A well-thought-out, proven and standard framework can save massive amounts of work. Combine this with the possibility of purchasing pre-built objects and pre-built tools and the user's work is really leveraged!
Business objects use business terms in ways that business people understand. Keeping the terminology in line with the business makes the entire system more understandable.
Business objects are a hot topic. The press is talking about them, standards bodies, like the Object Management Group (OMG), are talking about them. IS professionals are asking for the functionality. Vendors are implementing them. Users who currently are trying to use "two-level" client/server systems know they need them.
While products based around this architecture are attractive, standards will make it an industry. By standardizing on the Business Object Architecture, objects created in diverse systems can interoperate and companies can provide specialized tools to create and maintain the business objects.
The lower "technology" layer is already available and standard. The next layer of standardization can provide the higher-level business object protocol.
We expect the infrastructure and interface to become standardized by the OMG sometime next year. Once this happens, the now-uncoordinated efforts being put into business objects can become cooperative technologies supporting a common application architecture.
The basis for any business object system is the "model" of your business. This model is built using abstract business objects and processes and/or more specialized versions of these abstract objects.
This model should include every person, place, thing event or transaction that needs to be captured in the information system.
The business processes are likewise identified and modeled as business process objects.
Once complete, this business model becomes a valuable reference to how your business is organized and operates.
Each object in your business model is used to create an executable representation of that object in your computer system. This executable object will contain and encapsulate the information and rules associated with that object and its relationships to other objects.
Some business objects may be implemented on top of existing applications as "wrappers", exposing the legacy application as business objects. Other objects may be implemented using Workflow tools, computer languages or 4GLs. Provided all of the tools and wrappers can "speak" the BAA protocol, consistency of implementation environment is not required.
When used with a traditional DBMS the executable objects sit between the DBMS and the user interface providing an object oriented 3-tier client/server system.
Given the executable business objects, user interfaces are generated to allow users and other applications to view and manipulate the business objects. The business object user interface becomes the new "look and feel" for your applications. Desktop application may also interface with the business objects through interfaces such as OPENDOC and OLE-II.
The direct representation of the business model as executable and user accessible objects is the essence of the business object concept!
With a system comprised of a set of cooperative business objects, the outmoded concept of monolithic applications becomes unnecessary. Instead, you information system is comprised of semi-autonomous but cooperative business objects which can be more easily adapted and changed. This type of component assembly and reuse has been recognized as a better way to build information systems.
Given that an organization wishes to implement a business application, there must be an application architecture. That architecture may be custom, proprietary, or standard. Each approach has its advantages and disadvantages.
A custom architecture provides maximum flexibility to the enterprise. The applications can be designed and tuned to the organization's needs. Since the organization has developed much of its own infrastructure, it is not dependent on as many external suppliers (unless such dependencies are built into the custom framework).
Creating a custom architecture is not a small job. Experience has shown that a highly capable and specialized development team requires one to two years to field a stable infrastructure for applications development in a distributed environment.
The application infrastructure, like all software, will also require costly maintenance and future development. Of course, the application created in a custom environment will not interoperate with external software - considerable effort must be expended to integrate other software and data.
A proprietary application framework may be purchased from a vendor, frequently with some standard business applications. This solves the problems of producing a custom framework, but it does not solve the problems inherent in integrating the system with software that uses another framework.
Many organizations are also concerned about being locked in to a proprietary-framework vendor, since the organization may become very dependent on the provider. However, with a good provider relationship, a proprietary framework may be very productive.
A standard framework solves the problems of creating a custom framework and vendor lock-in. The organization may deal with multiple vendors to supply and support the standard framework.
The standard framework will have a much larger support base and as such will probably be worked-out and debugged to a greater degree.
The most important factor in a standard framework is commercial support. Given a standard framework it is practical to purchase pre-built business objects in an open market. Pre-built objects can be used as-is or enhanced using standard object oriented techniques vastly leveraging development. On the tool side - the organization can purchase design and implementation tools, data analysis tools, languages, libraries and utilities to help use and build applications in a standard framework. Standard desktop applications can interface with the architecture components.
A standard framework also leverages training. A development organization will be better able to find employees and consultants who already understand how the business system operates.
The only down-side to a standard framework may be flexibility. The framework may not do just what is required in very special conditions. But, the object oriented paradigm helps here as well, since the standard framework can be extended as can all object systems.
In short, a standard framework can foster an industry of business objects.
The reasons to standardize components of the BAA are directly reflected in the purpose of the OMG...
(a) to promote a single object-oriented applications integration environment based on appropriate industry standards;
(b) to promote a framework for compatible and independent development of applications;
(c) to enable coordination among applications across heterogeneous networked systems in a multinational, multilingual environment;
(d) to adopt a core of commercially available implementations of this framework and to promote international market acceptance and use;
(e) to actively influence the future direction and development of these core products and technologies; and
(f) to foster the development of tools and applications that conform to and extend this framework and to provide a mechanism for certifying compliance with the core technologies.
(Article I of the OMG by-laws)
Such a purpose for OMG and the BAA will have a range of advantages...
To synergize the work being done in creating business applications and distributed object components into a cooperative industry effort.
To make independently developed business objects interoperable with a minimum of effort.
To allow diverse business systems to be integrated.
To make the information understandable in business terms and easily meet business needs.
To foster an open market in business object related components. Both in pre-build business objects and in tools for using and building business objects.
With all the advantages of a standard, there is a dark side also. Restrictive standards can stifle innovation and poor standards can do more harm than good. To minimize the inherent problems of standardization, standards should be minimal. That is they should provide a sufficient level of standardization to meet the goals but no more. Simple, minimal standards are also easier to adopt to future innovation.
Another question of a standard is its scope. We are targeting business applications because of the extreme importance of business data processing and because of the high degree of commonality among business applications. Business applications represent billions of dollars of expenditure worldwide and directly impact the productivity of society - they deserve special attention. Trying to design a framework for all applications may not sufficiently benefit business applications; it may not even be possible. Applications outside the business domain may still use the BAA where appropriate, but it is not the design intent of the BAA. The term business application is intended in its more general sense, the data processing of governments and organizations fall within the domain of the BAA.
The existing OMG standards are required to implement a distributed-object business system. They provide the basic mechanisms for creating and using objects in a distributed network.
The existing and proposed OMG standards provide the necessary interfaces for transactions, User interface, events, object lifecycle and object query (all are required for a business system). The proposed application architecture must build on and work with the existing standards. For example, the IDL interface to the user interface should conform or work with the user interface component adopted by OMG common facilities.
The application architecture should build on this existing foundation.
Are the existing standards sufficient? If the existing standards were given to two development teams with the charter of producing the same application, it is unlikely that the above goals would be achieved. Both teams would have to come up with answers to fundamental questions like:
Answering these questions and building the infrastructure to support them is the process of designing the application architecture and framework. Given that no two groups are going to come up with the same rules, the requirement for Interoperability will not be achieved, and considerable effort will have been duplicated.
Two elements are essential to an application architecture and protocol. The architecture represents the components that are used to "model" the business problem and build the system, while the protocol is the set of rules that govern how these components behave and communicate with each other.
For example - in our reference model, we have presentations and business objects. If the user changes data in the presentation, how is that change communicated to the business object? If that change violates a business rule, how is that violation communicated to the presentation? Which object is responsible for side effects of that change and how and when are the side effects made visible to the presentation?
Business application are very "state-" (or data-) oriented. That is, business systems are driven by actions changing data and properly propagating the effects of that change. The protocol must provide very clear rules for dealing with that state and propagated effects.
The basic framework outlined in the reference model has three components - business objects, business process objects, and presentations. These are the building blocks of the applications. The same building blocks are used to model the business and to build the application. Each component of the BAA application becomes a subclass of one of these components.
As part of the architectural framework, each of the following must be addressed:
The protocol is the standard IDL interfaces between presentations, business objects and business process objects. Anything done to these objects is done through these standard interfaces. The primary purpose of the interface to business objects will be to make and respond to changes in the objects' states. As part of the protocol, business objects should present their metadata. Metadata is information about the business object. By having the object present its own metadata, applications can change their behavior based on changes in the metadata - making the entire system more friendly, flexible and dynamic.
As part of the protocol, each if the following issues must be dealt with:
Anything that has to do with the expression or implementation of business objects or presentations does not need a standard. The best and most proper way to express business objects and business rules is still growing and changing; we do not need to lock that down in a standard. As long as the objects can implement the desired protocol, our goals are achieved. The following are some of the elements that do not require standards.
Once the application architecture has a sufficient level of standardization, the question of commonality of specific objects arises. Can we identify common objects like customers, accounts, products and orders and derive common names, attributes and relationships for those objects? Standards for common business objects are not required for the BAA to work, but they would enhance the ability for the objects to interoperate. Standards for business-domain objects is a separate issue from the BAA and is not covered in this paper.
The reference model is a general model for business objects intended to encompass multiple interpretations and implementations of this concept. Diagram BAA-2 shows the abstract components of a business-object system and their interrelationships. Specific business-object systems may implement a superset or a subset of this model.
In this diagram, we can see that the tools used to build "traditional" programs, DBMS systems, technology components, and non-object programs are encapsulated, as shown by the inner circle. Only Business Objects will interface with this layer. The Business Objects are encapsulated and made accessible to the user by visual presentations and desktop programs. The Business Objects and their presentations comprise the Business Application Architecture.
Applications in this context are programs that are composed of a set of cooperative business objects. A program may implement one or many presentations and processes that work with business objects.
Any number of applications may be expected to share and reuse a common class of business objects. It is implementation specific as to whether multiple applications share an instance of a business object.
Note: Not all applications are business application architecture applications. Other types of applications may exist for other purposes and architectures.
Business objects encapsulate the storage, metadata, concurrency, and business rules associated with a thing, process, or event in a business. Multiple independent but related business objects may cooperate to service one application. Implementations may require different "flavors" of business objects for differing roles, such as: client-local objects and server objects.
Business Objects are a representation of a thing active in the business domain including, but not limited to, its name and definition, attributes, behavior, relationships, and constraints. They are responsible for all aspects of implementation including enforcement of business rules, application rules, data validity, concurrency, and storage.
Processes represent the flow of work and information throughout the business. These processes act on the business entities to cause the business to function. Business processes may be long-lived (such as an order life cycle) or may be short-lived (such as an end-of-year report). Long-life-cycle business processes are typically part of Business Process Re-Engineering (BPR) analysis.
Business process objects may be implemented with Workflow systems, business process managers, object oriented languages, procedural languages or interactive process definition systems. The only requirement on the process implementation/definition environment is that the resulting business process supports the standard BAA interfaces or can be "wrapped" to provide such interfaces.
The executable business process objects which represent the process in the information system should not be confused with a Workflow definition that may take a part in implementing a business process object. A Workflow definition, like any other business rule, is part of defining & implementing the object, not using it.
Business objects have a companion-the Business Object Presentation, or "Presentation" for short. Each business object can have multiple presentations for multiple purposes. The presentation is the user's view to the business object for a given purpose. The presentations communicate with the business object in two ways: 1) To transfer information between the presentation and the business object on behalf of the user. 2) To learn how to display and manipulate the business object (called "metadata" or, data about the data).
Having the presentations learn about the data from the business object makes them very simple and flexible. If anything about the business object is changed, that change is immediately reflected in the presentations.
Presentations are one type of application that can make use of business objects. Custom applications and automated processes (like Agents) can be part of a business object system.
Presentations are always run on users' systems but, thanks to the distributed-application architecture, the business objects and DBMS systems can run on the client machine, the servers, or both. In large systems, the implementation of a single business object can be split into multiple pieces to better optimize performance across large networks. Since the mechanisms of implementing the business object and storing the data are encapsulated "behind the scenes", advanced DBMS distribution, object-oriented DBMSes, concurrency, and replication systems can be added to scale performance without changing the interface to, or use of the business object. Business objects can "scale" to the capacity of the underlying systems.
The implementation components are encapsulated by the business objects. They are not accessed directly by users, processes, or presentations. The business objects use and manipulate DBMS systems, technology components, and non-object programs to implement their functionality.
The DBMS (or similar repository) is expected to store the representations of business objects and aid in their retrieval and concurrency. Many but not all business objects will use a DBMS to store their state.
Business objects can encapsulate non-object or legacy programs so as to provide these older applications with the business object interface. Existing non-object programs can also be modified to replace their user interface with a business object interface.
Object technology components are the other pieces of technology required to implement the business objects. In the OMG model, these include CORBA, CORBAservices and CORBAfacilities. They also include other applications used to support the business objects.
The architecture of a business object system is one in which the data, data storage, business rules and operations relating to each business entity are "encapsulated" (contained in and hidden by) a business object. These business objects have a simple, standard interface that allows them to communicate with other business objects and with business object presentations (presentations are what you see on terminals and reports). This represents the standard notion of object-oriented encapsulation applied to the business domain.
Each business object is responsible for managing its own storage (usually in a DBMS), security, maintaining its relationship with other objects, and implementing and enforcing the policies, procedures and rules of the business as they relate to that business object. Business objects are information-centric in that they expose and manipulate business information. Business objects are encouraged to, but not required to utilize OMG object services and common facilities for implementation.
Business Objects are implemented on top of a standard distributed-object broker such as CORBA (OMG), DSOM (IBM) or COM-OLE2 (Microsoft). These distributed-object systems have only recently become available as industrial-strength products and this technology is key to the business application architecture. The object broker allows any program (even your word processor or spreadsheet) to access and manipulate the business objects. Since rules are maintained by the business objects, complete control is exercised over the integrity and validity of the enterprise data. The object broker also allows any object to exist on any computer system and still integrate with the total information-processing infrastructure.
Each interface is part of the protocol between components of a business object application. A particular business object framework must require and/or specify all or a subset of these relationships. It is inherent in the business object concept that no relationship exists directly between the presentation and the implementation. These components and relationships taken together are considered the "OMG Business Application Architecture".
A specification of a business object (or framework) will provide the IDL interface, protocol and semantics of each relationship. Within a given business application architecture, some of these relationships may be standardized or specialized within Business Objects, presentations, and Business processes. In all cases, relationships may be bi-directional.
Applications are programs that use or are composed of sets of cooperative business objects to implement business functions.
Applications may interact with business objects for purposes such as creation, destruction, navigation, and event handling.
This interface should be specified in OMG IDL and must include all semantics, requirements, and ordering constraints of that interface.
Business objects may interact with other business objects for purposes such as creation, deletion, execution, coordination, data manipulation, concurrency, and enforcement of business rules. The relationship between business objects may be that one uses, extends, or consists of another object, depending on the business context. This relationship will probably be specialized.
This interface should be specified in OMG IDL and must include all semantics, requirements, and ordering constraints of that interface.
The presentation maintains a relationship with business objects for purposes such as invocation, creation, deletion, editing, and event handling. The presentation is responsible for connecting the business objects with the user.
Interfaces other than presentations may also direct business object operations (e.g., an EDI interface, Bar-Code interface, desktop programs etc.). The presentations and other interfaces communicate with the business object via a standardized protocol.
This interface should be specified in OMG IDL and must include all semantics, requirements, and ordering constraints of that interface.
The generic Business Objects, Business Processes, and Presentations defined in the Business Application Architecture are specialized through common, industry, company, and user business objects.
For example, "Business Object" may be specialized to create an "order" object in a general business suite. This order may then be further specialized to be an "order for consulting" services in a consulting company. A particular consulting company may add rules and attributes to that consulting order to enforce company policy. Finally, a particular department may further specialize the company's consulting order for a particular type of service.
The facility for specialization is inherent in the use of objects to represent the business in the information system. The degree of specialization required is driven by the business requirements of the user and the degree to which specialization will enhance business practices.
Terms used in the Business Object domain correspond to terms used for similar (but lower-level) concepts in other disciplines. The following table relates terms used in this model to the other domains.
Business Objects Object-Oriented Software SmallTalk Engineering Business Object Entity Model Presentation Interface Presentation Business Process Controller Control Object
Business Objects Oliver Sims McGraw-Hill 0-07-707957-4
Object Advantage Ivar Jacobson Addison-Wesley 0-201-42289-1
The Object-Oriented Enterprise Rob Mattison McGraw Hill
The OMA Guide OMG Wiley