Business Object Design and Implementation II

OOPSLA'96 Workshop Report


OOPSLA'96 Workshop on Business Object Design and Implementation II. 11th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications Addendum to the Proceedings. OOPS Messenger, ACM/SIGPLAN, 1997 (in press).


Overview:

The Second Annual OOPSLA Workshop on Business Object Design and Implementation was jointly sponsored by the Accredited Standards Committee X3H7 Object Information Management Technical Committee and the Object Management Group (OMG) Business Object Domain Task Force (BODTF) for the purpose of soliciting technical position papers relevant to the design and implementation of Business Object systems.

X3H7 Object Information Management

The International Standards Organization (ISO) has approved a new work item to refine and extend the current international standard Reference Model for Open Distributed Processing (RM-ODP). X3H7, the U.S. technical committee for this new international work item, is tasked with the following:

X3H7 has determined that to ensure a common understanding, it is necessary to define the concept, application architecture. The following comments on application architectures is excerpted from the US contribution to the ISO/WG7 Canberra meeting on Enterprise Viewpoint Language [JM96]:

 From RM-ODP we have: "architecture (of a system) a set of rules for the structure of the system, expressed in terms of the parts of the system and their interrelationships." [ODP2] From a recent work on software architecture we have: "…software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among those components." [SG96]

 Steps in preparing an application architecture for a distributed system:

For example, if several users will be working on a case at the same time, a model of the case might best be kept on a departmental machine. On the other hand, if only one user at a time will change data about the case, it may be better to bring the model of the case to the workstation. (Tradeoff of performance and network traffic vs. complexity of maintaining consistent state across workstations. Keeping the model on a departmental machine may slow response a bit, but greatly simplifies shared access.)

As another example, if the model of a case is small, it can be efficiently instantiated on the workstation; on the other hand, if a very large model must be available to the user, it may be better instantiate the model on a departmental machine. (Tradeoff of network delays vs. workstation delays. If the object model required for the user to do her work is so large that it exceeds the workstation main memory, swapping will affect performance. This effect appears suddenly at a certain model size, and response slows dramatically when it appears.)

In the above examples, 'case' means some small, unified business process, like handling an inquiry, order, or claim. There is, however, a relation to the idea of a use case. The scenarios of a use case provide the test cases for all the steps of the design of an application architecture. [MI 95]

OMG Business Object Domain Task Force (BODTF)

The Object Management Group's central mission is to establish an architecture and set of specifications, based on commercially available object technology, to enable distributed integrated applications. Primary goals are the reusability, portability and interoperability of object-based software components in distributed heterogeneous environments. To this end, the OMG adopts interface and protocol specifications that define an Object Management Architecture (OMA) that supports applications based on distributed interoperating objects.

 The current focus of OMG BODTF is the review of responses to a Request For Proposal (RFP) to address the OMA component called Common Facilities. The RFP solicits proposals for the following:

The Component Interoperability Facility should provide the abstraction which hides computational complexities, and enables business objects to interoperate efficiently and reliably in multi-user, concurrent, distributed, heterogeneous environments.

Goal of the Workshop

Papers addressing issues related to component interoperability and common business objects were solicited from academia, government, and industry for the workshop.

Workshop Presentations:

Analysis Patterns and Business Objects

Martin Fowler

As a consultant who does analysis and design of business systems, Martin kept running into the same analysis patterns while working on many different applications. His growing experience allowed him to take a model from a previous project and adapt it the needs of a new one. This store of previous models became a key set of skills. Documenting some of these useful models brought him into contact with the patterns community who saw his work as a way of bringing the idea of patterns into analysis. This work has led to a book on analysis patterns [Fowler 96].

Business Objects, Business Patterns

Paul Evitts

Christopher Alexander's notion of 'patterns' as a way of seeing and building the world in a manner that is natural, self-reinforcing, self-maintaining and (ultimately) good has influenced information systems design practices a great deal recently. And, even though systems pattern thinking has been (largely) a bastardization of Alexander's underlying concepts, the results have been powerful.

Emboldened by the success of systems patterns, and prompted by an interest in revisiting Alexander's ideas directly, Paul Evitts has been working with some colleagues on applying pattern thinking to business strategy, modeling, and analysis, thus extending the idea of Business Objects in a variety of ways. While still exploratory, the results have been encouraging.

In particular, they reinforce the recent efforts by Booch, amongst others, to formalize the role of patterns in the world of object orientation. His proposal to classify patterns into 'frameworks', 'mechanisms' and 'idioms', and then to incorporate patterns within Use Cases and to use Use Cases to detail patterns is very much in synch with the conceptual framework Evitts has been using.

Models of Business Objects: Accounts

Ralph E. Johnson and Kazuki Yoshida, University of Illinois at Urbana-Champaign.

For business objects to be reusable, they must be at the right level of abstraction. Classes like Customer and Invoice will not be very reusable because they are too specific, and each company will have its own version of them. On the other hand, classes like Business Object and Business Transaction are too general. We don't need another general-purpose object model.

Reusable business objects will have to thread the gap between solutions that are too specific and too general. There will not be a single model of business objects. Instead, there will be a set of specialized models that work together. The major research priorities include: determining which models are needed, defining each model, and learning how they can be used together.

This paper describes Accounts, a framework for business transaction processing, which is an example of the kind of business object model that is needed. It also describes the general problem of integrating different models of business objects, and uses Accounts to explore this problem.

An Object Model for Business Applications

Fred A. Cummins, Electronic Data Systems

This presentation focused on defining a model for objects--a generalized representation to be used in the development of business applications. A "business application" includes any application used in the operation of an enterprise. The enterprise might be a commercial business or it might be a government agency or an academic institution.

Cummins purpose is to define a level of abstraction to be supported by the Business Object Facility (BOF) that is the subject of the RFP issued by the OMG Business Objects Domain Task Force. His concern is that the BOF should greatly simplify the effort required by application developers to develop solutions to business problems. This presentation will help potential submitters understand the requirements for the BOF from an application developer's perspective.

Services of Workflow Objects and Workflow Meta-Objects in OMG-compliant Environments

Wolfgang Schulze, Markus Böhm, Klaus Meyer-Wegener, Dresden University of Technology, Database Group

After the definition and adoption of basic object services (CORBAservices [OMG95a]), time has come for the Object Management Group (OMG) to address more abstract parts of the Object Management Architecture (OMA). The roadmap for the next standardization efforts and the restructuring of its organization clearly show that the OMG is preparing for this challenge: The OMG has introduced four groups of horizontal common facilities: Interface, Information Management, System Management, and Task Management (CORBAfacilities [OMG95b]). The main responsibility of the Task Management Facilities shall be rule management, object automation, agents, and workflow.

The OMG's goal, that "...the Workflow Facility provides management and coordination of objects that are part of a work process [...]" (see [OMG95b], p.5-3) is very vague and leaves much work to be done in order to arrive at a rigorous definition. Up to now, the OMG has not presented a precise definition of what they understand as a "workflow" in this context. Even worse, the placement of workflow functionality within the OMA is in debate, too. The publications of the OMG BODTF (Business Object Domain Task Force) clearly identify workflows as a special form of business objects, consequently calling them "business process objects." This leads to the effect that they are either located inside a Business Object Facility or under the "applications" section of the OMA but not inside the Task Management Facilities.

Shulze et. al. hold the view that the original plan to introduce a dedicated workflow facility is the right choice and its rapid availability is of vital importance for the OMG. The perspective of this workflow facility, a clarification of the functions of workflow objects and their inseparable workflow meta-objects, is the key issue of this paper.

The Evolution of Enterprise Information Systems -- From Sticks and Jars Past Journals and Ledgers Toward Interorganizational Webs of Business Objects and Beyond

William McCarthy, Julia Smith David, and Brian S.Sommer, Michigan State University

This paper was a provocative discussion on the evolution of accounting systems. Discussion in the workshop focused on McCarthy's contribution in the 1995 Workshop on the REA accounting model [GM96].

Workflow Meets Business Objects

Mark Baker, Northern Telecom Network Services Management, 8 Sep 1996

The Workflow Management Coalition (WFMC), defines workflow as: "The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules."

Workflow tools are typically composed of two parts. The first is process execution. This is the runtime portion of process management, responsible for controlling and monitoring all the process instances currently active in the system. The other part is process creation, a graphical tool for constructing (defining) processes, and support tools for deploying them.

Business objects automate business processes. They need workflow capabilities by definition, as the OMG has identified with its task management facility (which has since been dissected into other distinct, but related facilities).

Business Object Facility

Texas Instruments Business Object Architecture Team (Ed. Tom Digre), Texas Intruments, Inc. 28 March 1996 (presented by Glenn Hollowell)

This paper was prepared by the Business Object Architecture (BOA) team as part of the TI SC Enterprise Framework strategy. BOA is the information technology architecture used to implement the TI SC Enterprise Framework Business Object Model. A key element of BOA is the Business Object Facility, which is the focus of this document.

OMG has issued an RFP for "Common Business Objects and Business Object Facility." BOA has adopted this RFP as a statement of requirement for a key element of the architecture. The remainder of this document has been prepared and formatted as a response to the RFP. The BOA team, which includes members from many internal TI development organizations, is not authorized to develop a commercial product and consequently can not directly respond to the RFP. However, this paper will facilitate:

Texas Instruments experience in transforming requirements to OMG specifications, and representing those specifications in the format required for the RFP response will enable the OMG to quickly evaluate and articulate relative merits and shortcomings of RFP responses.

General Discussion and Conclusions:

The variety of papers presented and the high level of expertise at the workshop led to a consensus on several important issues:

Analysis patterns could be of enormous benefit

Participants in the Workshop viewed patterns as the best way to introduce high quality analysis and design artifacts into the development environment. This is because they are design ideas, not prescriptions, and are more readily adopted by developers.

In order to effectively use them, we need to capture and document many more of them. The Workshop encourages the documentation of patterns and work with the pattern community, particularly PLoP '97, the Pattern Languages of Programming conference September 2-5, in Monticello, Illinois.

 The general consensus was that patterns should precede standardization of object frameworks. The OMG Business Object Facility may be the next place to standardize as this will be a very generic set of patterns.

It is better to buy than to build.

Businesses cannot afford to build everything in-house today. A business object architecture and component model should allow purchase of off-the-shelf components. This is also the preferred approach to integration of legacy monolithic systems. They should be encapsulated as business objects.

The current Workflow Coalition (WFC) standard is not suitable for OMG standardization.

The current WFC standard is not object-oriented. The WFC must find a place in the OMG Object Management Architecture (OMA) as a CORBA service (required) or facility (optional). Workflow is recursive and workflow is an object not an engine.

 Generic pattern considerations for Workflow demonstrate that it is not a common business object or part of the Business Object Facility. It is more than an entity object. It is an object that manages relationships and it is a process object. However, workflow is a separate facility, not just a Business Process Object. It belongs at the same level as BOF, OOAD, or Metaobject facilities in the OMG OMA. It is ubiquitous, everywhere in the environment.

The REA Accounting Pattern should be implemented as a prototype for the next workshop.

There are specific design patterns that should be implemented throughout business systems that will substantially improve reusability and rigor in business systems logic. The "Give/Take" REA pattern that has been standardized by accounting research should be rigorously implemented in all business systems and mandated in all accounting systems [GM96]. As much as 50% of the typical business application could be built from recursively implementing this pattern. Many companies (even banks) have trouble balancing their books or accurately determining the current status of business operations because of failure to implement this pattern properly in their business software systems.

 Interconnectivity between Business Object components is needed.

The feasibility of implementation of interconnectivity is a problem. The right people to implement it are very hard to find. It is a long term effort and is a functional, organizational and cultural problem, not just a technical problem. The Internet is good example of connectivity and standard packages. It has the power to alter organizational culture which is a prerequisite to implementation of a Business Object Architecture.

Component based architectures will be built from replaceable units of functionality that reduce the surface area of systems that are doubling in complexity each year. Large grain components will have clear sets of responsibilities or roles, and expose semantics of the business as well as syntax of interfaces [Digre95].

Major issues worthy of further discussion:

Year 2000 is a major issue. Expect 10% of systems worldwide to fail.

Electronic Data Interchange is worthy of strong support as a strategy for reduction of costs and integration of systems across enterprises.

Goals for Next Year:

Participants felt that the Workshop continued to be worthwhile. There was interest in having a more interactive format that included less formal presentation of papers and more group discussion.

The following specific items are of interest:

The group expressed an interest in having a third annual workshop next year and voted to publish the proceedings in a book as soon as possible.


References

[ELKC­06] ISO/IEC JTC1/SC21/WG7 Statement of Work ­ RM­ODP Enterprise Language and Application Architecture ­ Approved by Interim Rapporteur Group 1 May 1996

[GM96] Guido L. Geerts and William E. McCarthy . Modeling Business Enterprises as Value-Added Process Hierarchies with Resource-Event-Agent Object Templates. In Proceedings of OOPSLA'96 Workshop on Business Object Design and Implementation. Springer (in press).

[GRM] ISO/IEC 10165­7, ISO/IEC JTC1/SC21, Information Technology ­ Open Systems Interconnection ­ Management Information Systems ­ Structure of Management Information ­ Part 7: General Relationship Model, 1995.

[JM96] Joaquin Miller (Ed.). US contribution to the ISO/WG7 Canberra meeting on Enterprise Viewpoint Language. X3H7-96-20.

[K96] Haim Kilov, "Business rules for the Enterprise Viewpoint of RM­ODP", X3H7­96­07­R1

[MA96] Frank Manola, "Comments addressed to Clause 2. Rationale," X3H7­96­15.

[MI95] Joaquin Miller, "Steps in preparing an application architecture for a distributed system," MCI Systemhouse internal publication. © 1995, MCI Systemhouse, reproduced with permission.

[N10387­1] ISO/IEC JTC1/SC21 N10387 Rev 1, ISO/IEC JTC1/SC21, Open System Interconnection, Data Management and Open Distributed Processing. Proposed New Work item: RM­ODP Enterprise Language and Application Architecture, 1996­05­23, and Attachment (KC EL 06): Outline for Draft New Standard.

[ODP2] ISO/IEC 10746­2|ITU­T X.902

[OMG95a] Object Management Group: "CORBAservices: Common Object Services specification", revised edition, March 31, 1995, OMG Document 95-3-31.

[OMG95b] Object Management Group: "CORBAfacilities: Common Facilities Architecture", Revision 4.0, November 1995.

[SG96] Mary Shaw and Davie Garlin, Software Architectures, ISBN 0-13-182957-2.

[TI96] Glenn Hollowell, "Texas Intruments Enterprise Framework Overview", X3H7­96­11

[UK96] "Starting Point for Enterprise Language work" (draft for UK contribution)

Workshop Attendees:

Jeff Sutherland, Organizer, jeff.sutherland@idx.com
Glenn Hollowell, Co-Organizer, glenn@hollowell.org
Dilip Patel, Co-Organizer & Editor, dilip@sbu.ac.uk
 
Mark Baker, markb@interlog.com
Fred Cummins, cummins@ae.eds.com
Pranab K. Baruah, praab@atc.boeing.com
Paul Evitts, evitts@inforamp.net
Martin Fowler, 100031.3311@compuserve.com
Kitty Hung, hungks@sbu.ac.uk
Ralph Johnson, johnson@cs.uiuc.edu
Bill McCarthy, 21777wem@msu.edu
Paul Moran, paul.moran@fmr.com
R. Sellers Smith, rssmith@mitretek.org
Wolfgang Shulze, schulze@is2201.inf.tu-dresden.de
Kazuki Yoshida, kyoshida@cs.uiuc.edu