OOPSLA'97 Workshop on Business Object Design and Implementation III. 11th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications Addendum to the Proceedings. OOPS Messenger, ACM/SIGPLAN, 1998 (in press).
Part 2 of the ODP Reference Model defines an object modeling language; this language is a set of precisely defined concepts which provide a foundation for specification of distributed systems. Part 2 also specifies a general framework for the assessment of conformance.
Based on this foundation, Part 3 of RM-ODP specifies an architectural framework comprising:
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 Resource-Event-Agent (REA) pattern [McCa82] is a domain-specific pattern for the analysis and design of accounting information systems. The REA pattern lacks reusability and extendibility. In this paper we transform one of REA’s domain primitives, economic event, into a new pattern using modeling techniques described in [Hay96] and [Fowl97]. The resulting ‘Activity Pattern’: (i) illustrates the timeless way of building accounting information systems, (ii) integrates reusable procedures, and (iii) preserves the strengths of REA as a domain theory and integrates REA elements with non-REA elements.
An Object Implementation of Network Centric Business Service Applications
(NCBSAs): Conversational Service Transaction, Service Monitor and an Application
Style
Asit Dan & Francis Parr
The Internet stretches traditional strict transaction processing concepts in several directions. First, transactions spanning multiple independent organizations may need to address enforcement of pairwise legal agreements rather than global data consistency. Second, a new transaction processing paradigm is required that supports different views of unit of business for all participants, i.e., service providers as well as end consumers. There may be several related interactions between any two interacting parties dispersed in time creating a long running conversation. Hence, persistent records of business actions need to be kept. Additionally, some actions and groups of actions may be cancellable (however, this may not mean that all effects are undone, e.g., non refundable payments). Finally, the greater variability in response time for network computing creates a need for asynchronous and event driven processing, in which correct handling of reissued and cancelled requests is critical. This paper presents a framework for development of NCBSA using CORBA services while satisfying the above requirements.
Business Object Modelling Approach to develop a Customer Services
Framework to Enable Horizontal Reuse across Industries
Islam Choudhry & Dilip Patel
This paper briefly describes an approach to build a domain framework for customer services. A ‘customer services domain framework’ (CSDF) is a collection of customer services design patterns which work together to form the framework. CSDF is a conceptual model that accurately specifies the business knowledge in the form of an object-oriented model. The CSDF is built using the generic reusable business object modelling (GRBOM) approach which has five dimensions; genericity, reuse, change, business object modelling and patterns.
Accounting as Romance: Patterns of Unrequited Love and Incomplete
Exchanges in Life and in Business Software
Guido L. Geerts and William E. McCarthy
In the REA accounting model, the flow of value creation exchange within economic enterprise is represented by linked instantiations of one object pattern within and between business processes. This instantiation and linking is explained in micro-economic terms by Geerts and McCarthy [GM94]. The acronym REA derives from the primitive components of the domain theory underlying this representation which are its economic resources, its economic events, and its economic agents. A simple example of an REA schema and its abstraction to different levels of detail for a simple retail fish trading company is given in Geerts and McCarthy [GM97]. Full REA modeling is very difficult to achieve in practice and for a variety of reasons, some of which are practical and the sense that technology is the constraint and others in which are ontological in the sense that full definition and representation of the appropriate phenomena are the constraints.
The traditional business applications (Customer Orders, Purchase Orders, Accounts Receivable, Accounts Payable, etc.) are cultural artifacts -- not really necessary to doing business, but only to a particular historical form and stage of business. In a world of distributed business objects engaging in electronic commerce, a very different form of business system is possible: one composed of self-similar software components, dynamically linked in flexible configurations, managing multi-company supply chains. The Resource-Event-Agent (REA) template is a good basic building block for such a system [GM97]. By merging REA with some ideas from Manufacturing Resource Planning (MRP) , Work Flow Management (WFM) and Constraint-Based Scheduling (CBS) systems, it is possible to design a unified template that can be multiplied and composed to manage any business process.
Essential Requirements for a Workflow Standard
S Paul, E Park & J Chaar
The OMG BODTF has issued an RFP for a workflow standard, and by the time this workshop is held, the initial responses to the RFP will be in. We outline a set of important requirements that can be used to evaluate the responses. We also analyze the current version of the dominant workflow standard from the Workflow Management Coalition (a workflow industry consortium), and enumerate its weaknesses in the context of workflow execution across a heterogeneous, distributed infrastructure. The OMG BODTF needs to be aware of these weaknesses in order to avoid them in its own upcoming workflow standard.
A "light" distributed OO Workflow Management System for the creation
of Enterprise Architecture in BPR environments
M Beedle
BPR and object oriented technology are - and have been for the last few years - two of the most important business and technical currents. However, it is often seen that applications developed independently for each business process result in "system architecture silos". Therefore, the implementation of OO enterprise architectures brings ample business benefits in BPR environments such as: increased "enterprise conceptual integrity", reusability, generativity, and increased business effectiveness (cost, quality, service or speed). However, the simultaneous implementation of OO architectures and BPR also demands many changes in the business organization, its software development organization and its enterprise architecture. This paper briefly presents a "light" OO workflow management system for such an environment, and a brief description of: 1) a "business engineering" method, 2) a collection of business architecture patterns, and 3) a collection of software development patterns, that work together synergistically.
Fitting the Workflow Management Facility into the Object Management
Architecture
Wolfgang Schulze
Ever since publication in 1995, the Common Facilities part [OMG95] of the Object Management Architecture (OMA) had a placeholder for an architectural component that "provides management and coordination of objects that are part of a work process" - the Workflow Facility. In January 1997, the Object Management Group (OMG) established a workgroup to create and issue a Request For Proposals (RFP) for this Workflow Facility. After several meetings and intensive discussion, the group adopted a draft of the RFP [OMG97a] at the OMG Technical Meeting in March 1997 (Austin, Texas). This draft has been presented to the OMG Architecture Board for approval at the OMG Meeting in Stresa, Italy. With some minor modifications, the final RFP [OMG97b] has been issued on May, 9th 1997. The appointment of a workgroup to issue a Workflow Management Facility RFP overturned the Workflow Management Coalition’s initiative [Work96] to submit their non-object-oriented technology through a fast-track process (RFC) without further discussion.
Essentially, the Workflow Management Facility RFP has two key requirements: Submissions shall provide a semantic definition of a workflow metamodel and specify a set of interfaces for workflow enactment. The RFP states that the Workflow Management Facility "defines interfaces and their semantics required to manipulate and execute workflow objects and their metadata" (see [OMG97a], p.1). This means that the OMG starts from the assumption that in a CORBA environment, each workflow instance is realized as an individual object that exposes an interface.
This paper describes a set of concepts by which an enterprise may be modeled. The purpose of the enterprise is defined by its vision, missions, goals and objectives. Business processes define the way in which this purpose is achieved. Resources are the things created and used to perform business processes, and organizations provide the framework within which business processes and resources are managed. This approach ensures that processes focus on achieving purpose through optimal management of available resources. The concepts have been implemented in Java to illustrate the feasibility of the approach.
X3H7 ODP Update: Open Distributed Processing and Business Objects
Joaquin Miller
The reference model of open distributed computing (RM-ODP) provides a framework for specifying a system. It is directly applicable to the specification of a business object. This paper presents a very brief overview of ODP, a discussion of the current ODP enterprise viewpoint work, and a sketch of an ODP specification of a business object.
Business Process and Workflow Management in an Enterprise Resource
Planning Context
M. G. (Riné) le Comte
The research described in this paper is related to business processes and workflow management in an ERP context. Today there is a poor integration between ERP applications and workflow management systems. However, a combination of both worlds could lead to very powerful applications. Our research is working towards such integration.
EMPOWER: An Object-oriented Business Information Systems Framework
for Learning Organisation
N Phillips & D Patel
Object-oriented frameworks offer businesses the opportunity to greatly improve the flexibility and responsiveness of their information systems development effort. Application level frameworks provide generic solutions to well understood tactical problems, interface design, peer-to-peer communications, client-server data manipulation etc. Although successful exploitation of these frameworks is of considerable strategic importance, application frameworks are essentially tactical tools, they address the question 'how' not 'what'. Domain level frameworks fall into two categories, those that support the implementation of well defined strategic options, e.g. SEMATECH's Computer Integrated Manufacturing (CIM) 'Works' [Tali94], and those that support information architecture development, e.g. [Hert97]. This paper addresses some fundamental problems with architectural frameworks.
Here we go a short way beyond my OOPSLA'96 Business Object Workshop paper [Spot96], which was already "where angels fear to tread".
"Oh no - here's that fool stumbling in yet again!"
"But how has he avoided the mines on that plain?"
Now you see him, now you don't...
Fingers prodding, fingers burnt...
"We'll just plant this fertile field with simple grain."
More specifically in this paper: Where are we in Business Objects headed? And how do we get there better?
Business Objects and Business Rules
D Ehnebuske, B McKee, I Rouvellou & I Simmonds
Business object facilities should be designed to enable businesses to implement distributed, object-oriented business applications that reflect the natural structure of the business. They should also provide structures that allow different views on the system to be faithfully captured in its design. For example, information technology experts and business experts have different but equally valid ways of looking at a business application system; both must be captured faithfully if the system is to be useful, flexible, and durable.
Among the many areas of design an application development team must
deal with is business rules. This paper focuses on that area. It outlines
a patterned extension to a commercially available component architecture
that enables enterprise applications to systematically externalize business
rules. The architecture, though still in the proof of concept phase, has
been sufficiently implemented in several IBM engagements with business
customers to demonstrate the feasibility of the approach. The paper describes
the architecture described at three levels -- the managed object level,
the business object
level, and the business component level -- each of which builds on
what went before.
Revisiting Sims
Mark Baker
Oliver Sims' is regarded as the father of today's business object movement, in large part due to the success of his book, "Business Objects; Delivering Cooperative Objects for Client/Server" [Sims94]. Yet, despite the attention given business objects today, much of his insight is apparently going unnoticed. This paper contrasts attributes of the current popular view of distributed object systems, with Sims' vision.
Business Objects for Front-Office Applications: Making Domain
Experts Full Partners
J Bonar
"Front office" applications are support tools for people interacting with customers. They include applications like Help Desks, Customer Call Centers, and Sales Force Automation. Front office applications are distinguished from other applications commonly treated in the business object literature in requiring 1) much higher levels of flexibility after they are installed, 2) administration by domain experts rather than MIS personnel, and 3) more extensive runtime browsing capabilities. This paper discusses the use of business objects for implementing front office systems. It concludes that business object architectures are well suited to front office applications, particularly if the domain experts designing and administering the business logic details can do so directly, without requiring programmers. The paper discusses what compromises could be made in a business object specification that was simple enough for non-programmer domain experts but still useful. The paper concludes with a strawman description of Easy Business Objects (EBOs) with examples of how they would work in a front office application.
Modelling Domain Specific Application Frameworks with a Dynamic
Business Object Architecture: An Approach and Implementation
K Hung & D Patel
This paper describes the approach of a Business Object Architecture (BOA) development and implement it through a Dynamic Systems Development Method (DSDM) life-cycle environment with emphasis on end-user's involvement and iterative prototyping. The Dynamic Business Object Architecture (DBOA) is used for supporting and embracing the conceptualisation and design approaches for specific application domains. Distinctively, the DBOA is treated as skeletal support and life-cycle basis for OO modelling construction. This paper is in response to assist the review of the initial submissions of OMG BODTF's RFP for Common Business Objects and Business Object Facilities to model domain specific application frameworks.
Significant work has been done on the Resource-Event-Agent (REA) accounting model since the last workshop. The REA model is viewed as the core model for state-of-the-art accounting systems, and the appropriate pattern for automation of any exchange of resource in a business object system. Geerts and McCarthy discovered a new and better object design for REA implementation based on work presented by Fowler in last year's workshop [Fowl96]. Haugen is building an application using the REA pattern. SAP is moving towards it, as are other institutions.
Building application frameworks that enable horizontal reuse across domains and products is a challenging problem. Choudhry and Patel built upon the experience of Hertha et al [HBPP96] and others to design a domain framework for customer services. Critical issues are business modeling and segmentation of business models into stable fragments, and public release of models useful across domains which are usually considered proprietary if developed by a commercial institution. An organization like the OMG is the best place to assemble the required expertise in a public forum to solicit and evaluate domain frameworks.
Dan presented his work with the Coyote transaction monitor which evolves the design of TP systems into solving general business problems where there are several related interactions between any two interacting parties dispersed in time creating a long running conversation. This set the stage for the following Workflow presentations which generated some exciting new ideas.
Questions that still need answers:
1. How do you implement a reusable pattern?
2. How do you deal with application transactions vs. TP transactions?
Long transactions? Contracts between clients and servers?
3. How do you work with domain business object models? And allow dynamic
change?
4. How do you handle more difficult REA patterns (the ones that make
accounting interesting and useful)?
5. How do you differentiate between businesses and their processes?
6. How would you build a BPR datablade?
Dynamically generated heterogeneous distributed workflows were discussed in some detail by several workshop participants. Haugen discussed "radically distributed supply chains" appearing in many manufacturing operations. For example, the order of a Dell computer over the Internet results in spawning workflows which must be asynchronously executed by Dell's suppliers, resulting in pieces of the computer arriving at a central location for assembly and shipment on the same day. Paul described his work at IBM T.J.Watson Research Center in developing requirements for these systems as well as implementation of a Java prototype of a distributed workflow system running on the Internet [PPC97]. Schulze described current work within the OMG on an object-oriented workflow standard and noted that further work was necessary to support the dynamically generated heterogeous distributed workflow systems of the future.
Schulze emphasized that the four initial submissions to the RFP do not address a number of requirements of the RFP, especially considering a rigorous definition of a kernel workflow metamodel. It would be a good idea if the workflow community would make a serious attempt to come to a common view with the business object community. Since service orthogonality (Bauhaus principle) is a major design goal within the OMA, an integration of both concepts is essential in order to come to an acceptable workflow-management standard. Different ways to address workflow-management within the OMA will surely hurt its overall acceptance for users and developers.
Internet based, distributed workflow systems were viewed as an exciting area of research. The field has advanced significantly since last year's Business Object Workshop. If we are moving to radically distributed supply chains, virtual inventories, autonomous suppliers, Internet-based tasks, and transient assembly, how do we think about business objects? Is this the killer app for the REA pattern? Many questions need further investigation:
1. Implementation of real time, event driven
2. Generative process planning
3. Automated routing, roles of resources
4. Workflow as solution to reach goal, or to generate achievable goal
using subservient workflows
5. Hierarchies of workflow
6. What systems can learn from one another
7. Peer to peer workflow - workflow between organizations
8. Goal directed behavior - create value through exchange
9. Workflow services, level of persistent services
10. Systems with emergent properties
11. Disaster response as workflow
12. Explicit experience reports
13. What could workflow be? What would the impact be?
14. Who does what? How should systems be partitioned?
15. What patterns are useful for end users?
16. What about mobile agents, process engines, just in time workflows?
17. How enable learning organizations - complex adaptive systems, emergent
behavior
18. How evolve systems through workflow by moving through evolutionary
adaptive fitness state space?
Enterprise architectures based on business objects are evolving rapidly. There is increasing integration of Business Process Engineering with implementation of a Business Object Architecture which enables reuse of more than implementation artifacts. Marshall provided an excellent report on implementing a Java BOA in practice [Mars97]. The approach and implementation of a DBOA model presented by Kitty Hung is to achieve the of right granularity of Business Object reuse not only on code level but rather the reuse of business expertise and business knowledge. The Dynamic Systems Development Method is to provide a project management approach coupling with the Business Object Architecture in response to the dynamic change of business climate.
Baker discussed implementation of these architectures on the Web and
noted that there are currently two opinions on how to build a standard,
composition-centric distributed infrastructure; the "Web", and the more
traditional "distributed object" view. XML is blurring the
lines even further between these visions, giving compositional capabilities
to both the transport level, and
layers above [Mano97].
In summary, there is significant work and progress in design and implementation of business object systems and rapidly expanding domains of interest where further work needs to be done.
References
[HBPP94] Hertha , William F., Bennett, Jim E., Post, Frank J, Page Ian M. An Architecture Framework: From Business Strategy to Implementation. In Business Object Design and Implementation: OOPSLA'95 Workshop Proceedings. Sutherland J., D. Patel, C. Casanave, G. Hollowell and J. Miller (Eds.), Springer, 1997.
[GM94] Geerts, G. and W.E. McCarthy. The economic and strategic structure of REA accounting systems. 300th Anniversary Program, Martin Luther University, Halle-Wittenberg, Germany. September, 1994
[GM97] Geerts, G. and W.E. McCarthy. Modeling business enterprises as value added process hierarchies with resource-event-agent object templates. In Business Object Design and Implementation: OOPSLA'95 Workshop Proceedings. Sutherland J., D. Patel, C. Casanave, G. Hollowell and J. Miller (Eds)., Springer, 1997.
[Fowl97] Fowler,M. Analysis Patterns: Reusable Object Models. Addison Wesley, 1997.
[Hay96] Hay, David. C. Data Model Patterns: Conventions of Thought. Dorset House Publishing, 1996.
[McCa82] McCarthy, W. E. The REA accounting model: a generalized framework
for accounting systems in a shared data environment. The
Accounting Review (July): 554-78.
[Mano97] Manola, Frank. Towards a Web Object Model. Object Services and Consulting, Inc., 1997.
[Mars97] Marshall, Chris. BOMA Business Object Management Architecture. SES Software, 1997.
[OMG95] Object Management Group. CORBAfacilities: Common Facilities Architecture, Revision 4.0. November, 1995.
[OMG97a] Object Management Group. Workflow Facility RFP, Revised Draft approved by Workflow Workgroup on March 14th, 1997. OMG Document cf/97-03-14
[OMG97b] Object Management Group. Workflow Management Facility RFP, issued on May 9th, 1997. OMG Document cf/97-05-06
[OOPSLA95] OOPSLA'95 Workshop on Business Object Design and Implementation. http://jeffsutherland.org/oopsla/oo95wrkf.html, 16 October 1995.
[OOPSLA96a] OOPSLA'96 Workshop on Business Object Design and Implementation II. http://jeffsutherland.org/oopsla96/index.html
[OOPSLA96b] Sutherland, J. OOPSLA'96 Workshop Report on Business Object Design and Implemention II. 11th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications Addendum to the Proceedings. OOPS Messenger, ACM/SIGPLAN, 1997.
[OOPSLA97] OOPSLA'97 Workshop on Business Object Design and Implementation III. http://jeffsutherland.org/oopsla97/index.html
[PPC97] Paul, Santanu, Park, Edwin, and Chaar, Jarir. RainMan: A Workflow System for the Internet. IBM T.J. Watson Research Center, 1997.
[Sims94] Sims, Oliver. Business Objects : Delivering Cooperative Objects for Client-Server. McGraw-Hill, 1994.
[SPCHM97] Sutherland J., D. Patel, C. Casanave, G. Hollowell and J. Miller (Eds). Business Object Design and Implementation: OOPSLA'95 Workshop Proceedings. Springer, 1997.
[SPCMH98] Sutherland J., D. Patel, C. Casanave, J. Miller, H. Kilov (Eds). Business Object Design and Implementation: OOPSLA'96-97 Workshop Proceedings. Springer (in press).
[Spot96] Christopher Spottiswoode. The emperor's new clothes -- an outsider's perspective. OOPSLA'96 Workshop on Business Object Design and Implementation II. http://jeffsutherland.org/oopsla97/index.html - October, 1996.
[Suth95] Sutherland, Jeff. Business Object Design and Implementation. 10th Annual Conference on Object-Oriented Programming Systems, Languages, and Applications Addendum to the Proceedings. OOPS Messenger 6:4:170-175. ACM/SIGPLAN October, 1995.
[Tali94] Taligent. Taligent Inc. White Paper: Building Object Oriented Frameworks. 1994.
[Work96] Workflow Management Coalition. Workflow Facility Specification. Document Number WFMC-TC-2101, Working Draft, November 1st, 1996.
Workshop Attendees:
Jeff Sutherland, Organizer, jeff.sutherland@idx.com Dilip Patel, Co-Organizer & Editor, dilip@sbu.ac.uk Joaquin Miller, Co-Organizer, miller@shl.com Zhi An, zan@privbiz.com Bruce Anderson, bruce_anderson@uk.ibm.com Mark Baker, markb@iosphere.net Michael A. Beedle, beedlem@fti-consulting.com Jean Bezivin, jbezivin@acm.org Jeffrey Bonar, jbonar@mindspring.com Islam Choudhury, choudhia@sbu.ac.uk Fred Cummins, cummins@ae.eds.com Tilak Dissanayake, tilak@netscape.com Guido Geerts, geerts@pilot.msu.edu Bob Haugen, linkage@interaccess.com Kitty Hung, kitty.hung@btrinc.com Steve Marney, steve.marney@eds.com Chris Marshall, chris_marshall@sesh.com William McCarthy, 21277wem@ibm.cl.msu.edu Giuseppe Menga, menga@polito.it Francis Parr, francis@watson.ibm.com Santanu Paul, santanu@us.ibm.com Nigel Phillips, phillinp@vax.sbu.ac.uk Isabelle Rouvellou, isabelle@watson.ibm.com Wolfgang Schulze, Wolfgang.Schulze@inf.tu-dresden.de Christopher Spottiswoode, cms@metaset.co.za