Business Object Design and Implementation Workshop
Business Object Design and Implementation Workshop
Position Paper Object
Management Group RFI Response: Common Facilities Request for Information
#2 
Cory
Casanave (cbc@gate.net)
Organization
Date/Place: 16 October 1995/Austin, TX
Financial Services and Accounting Facilities are found in virtually every business, enterprise and organisation that utilises computer technology for operational purposes. These services are the backbone of an enterprises information system, they contribute to or are effected by almost every information processing application.
As such, Financial Services and Accounting facilities should not be considered as a vertical application that may exist independently of other parts of the information system but as components of that system interacting and interoperating with other application components.
Information system components, such as Financial Services and Accounting facilities, may be distinguished from the more general CORBA interfaces which have universal applicability. These components may also be distinguished from computational components (such as nuclear simulation) which tend to have minimal interaction with the information system. Information system components are data centric in that they represent information about things in or actions of an enterprise. Information system components deal with the general area of computing known as "data processing".
It is our contention and the purpose of this response that all OMG information system components, including Financial Services and Accounting facilities should exist within a common component architecture and framework inorder to promote interoperability of those components across domains, products, applications and enterprises. We intend to set out the requirements of such a component infrastructure in the hopes that it will lead to an RFP. Once the infrastructure is in place the interfaces for specific financial and accounting components may be specified in terms of the common framework.
The vision of this RFI is that of a component based information system. Components in this sense are high-level objects that directly represent entities in the enterprise. These exist within a common framework with well defined interfaces to each other, the system and user interface components.
These components exist in a distributed, object oriented computing environment such that the information system is potentially world-wide, using objects to integrate the enterprise across wide-area networks.
In such an environment components are independent entities that may be implemented, evolved and/or replaced as the information system as a whole evolves. Ultimately, these components should be "hot swapable", meaning that they can be replaced while the system is running, allowing for high-demand system to evolve as well.
The components should interact with each other using a high-level interaction protocol that only exposes the interfaces required to use and manipulate that object in keeping with the principles of encapsulation of implementation and inheritance of common semantics. The components should be loosely coupled so as to provide for maximum flexibility.
Our expectation is that out of these components a level of reuse will be achieved at the business level, allowing an open market in components for general and specific requirements. While this objective is not new, it is yet to realised. Standard components may lead the way.
Given this high level infrastructure we see tools evolving to make the construction and use of these components easily expressed and understandable. In this way the entire lifecycle of the information system may be manipulated through tools dealing with a common framework.
Such a vision fits exactly with the mission of OMG, that of promoting application interoperability through open standards for distributed object computing.
Due to the above stated lack of boundaries between the Financial services and Accounting facilities and the rest of the information system, this response is wider in scope than the RFI. However, due to the same lack of boundaries the requirements for the framework and standards apply to Financial services and Accounting facilities within the context of OMG's Common facilities architecture. As the first "application objects" to be defined under OMG they will set the standards for all other such objects.
The approach to defining the standard component architecture and framework is to derive subclasses of CorbaObject to represent information system components. All application components are then derived from the standard components.
Interfaces are then described in IDL to specify the interaction protocol between standard CorbaComponents. Such interfaces must provide for the requirements stated above. Many of the interfaces of components will either use or implement the standard interfaces as described in CorbaFacilities or CorbaServices.
For example: Components must work together in terms of transactions. The Corba transaction services will be used in a prescribed way to facilitate inter component transactions. In this way components will extend and specialise the standard interfaces. Implementations of the standard framework may well hide the details of these interfaces and expose a higher level interface to the component builder.
Components are specialised for a particular application by specifying the object model of the application. Each type of object within the application domain is a subclass of CorbaComponent, this class hierarchy becomes the applications object model.
The object model of the application is the set of component objects that represent the application. These components will take on the vocabulary of the domain. Examples of these are: Purchase, Sale, Part, Customer, ledger...
Relations represent the logical connections between components as well as the rules associated with these relations.
Attributes are publicly visible representatives of the component objects state. These attributes may be physical or computed, no assumption is made about the attributes implementation.
Events are atomic actions that may serve to change an objects state.
Special interfaces are extensions to the component object interfaces for special application requirements.
It is the reasonability of the component to enforce all rules that may be associated with the component.
Given the standard framework; financially related components may then be defined as a subclass of the standard components. The object model representing financial components is beyond the scope of this paper and may be suggested by other submissions, the following is intended as a simple example.
Given the common CorbaComponent the interfaces required for the domain specific components would largely be related to the accessing and alteration of the components relations and attributes leaving it up to the component to enforce rules and side effects. This provides a much simpler interaction model for components and one in which specialised interfaces beyond relation and attribute manipulation and event response would be the exception rather than the norm. Simplifying component interaction serves to enhance interoperability and decrease complexity. Specialised interfaces need only be defined for special needs.
The reasons to standardise components 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 co-ordination 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 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 components interoperable with a minimum of effort.
To allow diverse information systems to be integrated.
To make the information understandable in business terms and easily meet business needs.
To foster an open market in related components. Both in pre-built components and in tools for using and building components.
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 information systems because of the extreme importance of data processing and because of the high degree of commonality among 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 information systems; it may not even be possible. Applications outside the information system domain may still use these standards where appropriate, but it is not the design intent.
The existing OMG standards are required to implement a distributed-object information 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 an information system). The proposed component 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.
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 (see below under "Basic architectural framework").
Answering these questions and building the infrastructure to support them is the process of designing the architecture of the application infastructure 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 - If the user changes data in a user interface component, how is that change communicated to the component representing the entity? If that change violates a business rule, how is that violation communicated to the user interface? Which object is responsible for side effects of that change and how and when are the side effects made visible to the presentation? How do objects find each other?
Information system applications are very "state-" (or data-) oriented. That is, information 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.
As part of the architectural framework, each of the following must be addressed:
The protocol is the standard IDL interfaces between information system components. Anything done to these objects is done through these standard interfaces. A 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 information system components and 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 of interoperability 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. W cane identify common Financial and Accounting facility components like customers, accounts, products and orders and derive common names, attributes and relationships for those objects.
The ideas expressed in this response are not unique. They represent a view of information systems that is being explored and developed by multiple companies and standards groups. Among them are:
A common framework for information system components is the natural way to extend the OMG vision to Financial and Accounting Facilities. Making such a framework part of the definition of such facilities will serve to integrate them into the interoperable system that is the reason for OMG to exist.
Business Object Design and Implementation
Page hits
since 8/27/95