A Position Paper for the OOPSLA '96 Workshop on Methodologies for Distributed Objects

Methods for Distributed Object Computing --- DRAFT --Cris Kobryn, Technology Group, MCI Systemhouse Hernn Astudillo, Technology Group, MCI Systemhouse

Introduction MCI Systemhouse (formerly SHL Systemhouse) is a recognized leader in enabling business transformation through client/server computing. The Gartner Group, an independent research organization, has described MCI Systemhouse as "the leader in client/server consulting and development." We attribute a large part of our success in client/server computing to our emphasis on robust architectures and rigorous development methods. Our development methods, architectures and best practices for client/server computing are maintained in our corporate knowledge repository, SHL TRANSFORM . We are now in the midst of a major computational shift toward distributed object computing (DOC). While the particular implementations that we use may still be uncertain (there are several competing DOC standards, including OMG's CORBA and Microsoft's ActiveX/DCOM), our overall direction is becoming clear. It is not happenstance that the hugely popular Java language is not only object-oriented, but is also multi-threaded and secure in a networked environment. Neither is it coincidence that Netscape ONE's "network-centric" architecture uses both Java as a programming language and CORBA Internet Inter-ORB Protocol (IIOP) as a messaging protocol. The momentum toward DOC is increasing and inexorable. Although DOC technology offers unprecedented computing power, few organizations have yet been able to harness it. Commonly cited obstacles to the adoption of DOC include closed legacy architectures, incompatible protocols, inadequate network bandwidth, and security issues. To this list we add a less frequently mentioned barrier, the lack of methods for distributed object computing. MCI Systemhouse recognizes the importance of matching rigorous software engineering methods to advanced technologies. This was our guiding principle when we applied object technology to large client/server systems. We will follow a similar

approach for enterprise distributed object computing, which we refer to internally as networked object computing. The following sections provide an overview of the current state of object-oriented methods, and describe how they need to be extended to support DOC. They also discuss several MCI Systemhouse initiatives related to methods for DOC.
Back to Top

Current Object-Oriented Methods: What's Missing? In order to assess the state of current object-oriented methods, it is useful to first distinguish between several different types of object modeling. In the OMG's recent Object Analysis and Design Facility RFP-1 [OMG 96], the OMG Analysis and Design Task Force differentiated distinguished between the following types of object models:

static models (also known as structural models; e.g., class models, type models, instance models) dynamic models (also known as behavioral models; e.g., state transition models, object interaction models) usage models (e.g., use-case models) architectural models (also known as system composition models; e.g., subsystem models, modules-component models, process maps)

Of these four types of object models, the static and dynamic models stand out as being the most mature. The static and dynamic models of most methods tend to be similar in constructs and semantics. Although there may be significant notational differences among them, static and dynamic models can often be translated from one method to another in a straightforward manner. The same cannot be said for usage models and architectural models. Although most object methodologists have adopted use-case models as the basis for user-centered requirements analysis, there is considerable variance in how they adapt the use case concept and how they are integrate it with the rest of their object models. (We remark on this primarily for completeness. Since it is not directly relevant to DOC, a further discussion of use-case models is beyond the scope of this position paper.) Architectural models are the least mature of the various object models. These are also the models that are most relevant for distributed processing, since they are concerned

with system partitioning and process allocation. This is the modeling area which needs to address the special distributed processing requirements related to performance, reliability, scalability and security. DOC architectural models must be able to define schemes for concurrent communications, load balancing, fault tolerance, and security enforcement. These are hard problems that are difficult to specify. While many of the well known object-oriented methods support basic techniques for system partitioning (e.g., [Booch 94], [Jacobson 92], [Rumbaugh 92] and [Wirfs-Brock 90]), most of them only consider distributed processing issues peripherally. Few methods support basic techniques for process allocation; [Booch 94] is a noteworthy exception. Although distribution and concurrency issues are beginning to be addressed in the Unified Modeling Language [1] [Booch 96] and MOSES [Rasmussen 96], much work remains to be done. There is a wide modeling gap between simple two and three-tier client/server architectures and the fine-grained, peer-to-peer architectures associated with DOC.
Back to Top

Distributed Object-Oriented Methods: What's Needed? What makes distributed object computing so different from non-distributed object computing? Stated otherwise, what makes object computing in a virtual address space that is spread across networked processors different from object computing in virtual memory associated with a single processor? If the technology is available to make interprocess communication between objects transparent and secure (as CORBA ORBs are purported to do), conceptually there is not much difference. A client object sending a message to a server object need not concern itself about whether the server object is located at a nearby physical memory address or is located somewhere remote in cyber-space. The ORB (or comparable interprocess communication mechanism) should handle the inter-object communication as transparently as telephone companies manage the routing of directdial international calls. Although conceptually the differences between distributed and non-distributed object computing may seem small, in practice they are substantive. Many of these differences result from the hardware and software constraints imposed by limitations in current networking and DOC implementations. These include, but are not limited to, closed legacy architectures, incompatible protocols, limited network bandwidth,

and security issues. Since architectural modeling is part of the physical design process, these constraints must be factored into architectural models. For example, network bandwidth and latency issues must be considered when determining process allocation schemes. What is needed are methods that address the distribution and concurrency issues associated with DOC. There are two possible approaches: 1) extend existing objectoriented methods for non-distributed software (perhaps reusing existing method parts); and 2) develop new object-oriented methods based on distributed processing concepts from the beginning. Whatever approach is chosen, the methods need to address the following areas:

Concepts. We need to unambiguously define the object modeling concepts associated with DOC, and map them consistently to concepts related to emerging distributed object computing standards, such as CORBA and DCOM. These include basic concepts such as active objects, passive objects, synchronous messages, and asynchronous messages. They also include more advanced concepts such as process partitioning, allocation, and migration. Notation. We must develop simple, but expressive diagramming techniques for modeling distribution and concurrency. These diagram techniques should be the backbone of the architectural modeling process. Development process. We need rigorous software development processes to guide architectural modelers. These development processes should be able to address the (relatively) modest needs of 2-tier client/server architectures as well as the difficult demands of fine-grained, peer-to-peer, distributed object architectures. Interface specifications. We must be able to specify the interfaces between distribution units is a straightforward, unambiguous, language-independent manner. The UML notation for interface class stereotypes and CORBA Interface Definition Language (IDL) are promising beginnings. Architectural patterns. We need to develop architectural patterns that can be reused across domains (e.g., banking, insurance, manufacturing) and across implementation strategies (e.g. CORBA, ActiveX/DCOM, Java ORBs). The pattern-oriented software architecture approach described by [Buschmann 96] provides a good foundation for architectural patterns. Testing. We must develop testing methods that address the non-determinism associated with DOC. This non-determinism results when more than one component is able to operate asynchronously. Consequently, all possible orders of operations/events cannot be tested via conventional dynamic testing approaches.

Meta-object models. We need to develop meta-object models that can be refined and extended as the needs of DOC evolve.

The following section describes several MCI Systemhouse initiatives for addressing some of these areas.
Back to Top

Future Directions We recognize the importance of matching rigorous software development methods to advanced technologies. Consequently, we are committed to providing our systems integration experts with robust distributed object methods to design and build enterprise distributed object systems. The following are some initiatives underway at MCI Systemhouse that are related to methods for DOC:

Corporate Standards. We are adopting object-oriented methods and CASE tools standards which can be adapted to support DOC. In those areas where our selected methods and CASE tools are inadequate for DOC (such as architectural modeling), we are refining and extending methods and techniques based on the collected experiences of our leading computer scientists, architects and designers. Industry Standards. We are continuing to work closely with standards organizations and strategic vendors to develop industry standards for commercial DOC. In particular, we are continuing to work with the OMG's Object Analysis and Design Task Force to develop tool interoperability and notation standards for DOC. We are also collaborating with the Distributed Systems Technology Centre to better understand how we can use the ISO Reference Model of Open Distributed Processing (RM-ODP) [Raymond 95] to improve our architectural models. Architectural Models and Patterns. We are developing architectural models and patterns that can be reused across diverse domains and implementation strategies (e.g. CORBA, ActiveX/DCOM, Java ORBs). At MCI Systemhouse we refer to system architecture models as model architectures, and consider a specific implementation of one of them (e.g., a CORBA implementation of a model architecture for financial trading) to be "an instance of" a model architecture. We are particularly interested in architectural patterns related to fault tolerance, dynamic load balancing, and trader services.

Distributed object system testing. We are exploring new techniques and processes for testing distributed object systems. Both static and dynamic testing techniques are being considered. Knowledge and object Repositories. We are updating TRANSFORM to serve as our knowledge repository for development methods, architectures and best practices for DOC. We are also evaluating object repository technologies, policies and procedures.

These initiatives will provide a robust foundation for developing rigorous methods for DOC. We will use these methods along with proven DOC technologies to enable the next generation of business transformation.
Back to Top

Footnotes [1] We note that the Unified Modeling Language is an object modeling notation, not an object method. References
[Booch 94] [Booch 95] G. Booch. Object-Oriented Analysis and Design with Applications, Benjamin/Cummings, Redwood City, CA, 1994. G. Booch and J. Rumbaugh. Unified Method for ObjectOriented Development: Document Set, Version 0.8, Rational Software Company, Santa Clara, CA, 1995. G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Language for Object-Oriented Development: Document Set, Version 0.9 Addendum, Rational Software Company, Santa Clara, CA, 1996. F. Buschmann, et al. A System of Patterns: Pattern-Oriented Software Architecture, John Wiley, New York, 1996. I. Jacobson, et al. Object-Oriented Software Engineering, Addison-Wesley, Wokingham, England, 1992. Object Analysis and Design Facility RFP-1, Object Management Group, Document ad/96-05-1, 1996. G. Rasmussen et al. Extending the MOSES Methodology to Distributed Systems, Journal of Object-Oriented Programming, 8 (4):39-46, 1996. K. Raymond and L. Armstrong. Open Distributed Processing: Experiences with distributed environments, Chapman & Hall,

[Booch 96]

[Buschmann 96] [Jacobson 92] [OMG 96] [Rasmussen 96] [Raymond 95]

[Rumbaugh 91] [Wirfs-Brock 90]

London, 1995. J. Rumbaugh, et al. Object-Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, NJ, 1991. R. Wirfs-Brock, et al. Designing Object-Oriented Software, Prentice Hall, Englewood Cliffs, NJ, 1990.

About the Authors Cris Kobryn is a Chief Scientist for MCI Systemhouse's Technology Group, where he specializes in distributed object architectures and methods. Cris has extensive experience in the application of object technology to solve business and scientific problems, and is an expert in object-oriented analysis, design, and programming. He has broad international experience in advanced software development and project management, and has led high-productivity software development teams in the US and Europe. Cris is MCI Systemhouse's primary Technical Representative to the Object Management Group, where he is a member of the Object Analysis and Design Task Force. He has made technical presentations in the US, Europe and Asia, and is a former computer science instructor at the University of California, San Diego Extension. Cris is a member of the ACM, the IEEE and AAAI. Hernn Astudillo is a Senior Software Engineer for MCI Systemhouse's Technology Group, and a member of the Object Architecture Team. He has an extensive research background and development experience in object-oriented programming and design, and particular interest in methodological and modeling issues. He is a member of the ACM, IEEE and ASD. Hernn is a former computer science instructor at the Universidad Tcnica Federico Santa Mara and the Georgia Institute of Technology. He is also presenting a paper at the OOPSLA technical seesion, on work related to his dissertation on reorganization of object-oriented models. Last but not least, he makes awesome coffee.

Introduction :The definition of an object as an entity that has a distinct identity, state, and behavior, and, it is claimed, the principle of encapsulation, can be carried over to the realm of distributed computing. Paradoxically, encapsulation does not extend to an object's behavior since they (or even their method names) are

not serialized along with the data. A number of extensions to the basic concept of an object have been proposed that share these common characteristics: Distributed objects are "ordinary" objects (objects in the usual sense - i.e. not OOP objects) that have been set up at a number of distinct remote locations, and communicate by exchanging messages over the network. Examples include web services and DCOM objects. Protocol objects are components of a protocol stack that enclose network communication within an object-oriented interface. Replicated objects are groups of distributed objects (called replicas) that run a distributed multi-party protocol to achieve high consistency between their internal states, and that respond to requests in a coordinated way. Referring to the group of replicas jointly as an object reflects the fact that interacting [dubious discuss] with any of them exposes the same externally visible state and behavior . Examples include fault-tolerant CORBA objects. Live distributed objects (or simply live objects) generalize the replicated object concept to groups of replicas that might internally use any distributed protocol, perhaps resulting in only a weak consistency between their local states.
[3]

Some of these extensions, such as distributed objects and protocol objects, are domain-specific terms for special types of "ordinary" objects used in a certain context (such as remote invocationor protocol composition). Others, such as replicated objects and live distributed objects, are more non-standard, in that they abandon the usual case that an object resides in a single location at a time, and apply the concept to groups of entities (replicas) that might span across multiple locations, might have only weakly consistent state, and whose membership might dynamically change.