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

Methods for Distributed Object Computing

Cris Kobryn, Technology Divsion, MCI Systemhouse
Hernán Astudillo, Technology Division, 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 will 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 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 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], [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 (e.g., Object Request Brokers (ORBs)), 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 direct-dial 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 object-oriented 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 partitioning, allocation, and migration.
• Notation. We must develop simple, but expressive diagramming techniques for modeling distribution and concurrency. These diagramming 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 testing approaches.
• Meta-object models. We need to develop meta-object models that can be used to refine and extend object models as the needs of DOC evolve. The OMG's Meta-Object Facility will standardize meta-object models in support of IDL interfaces.

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

About the Authors

Cris Kobryn is a Chief Scientist for MCI Systemhouse's Technology Division, 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, IEEE and AAAI.

Hernán Astudillo is a Senior Software Engineer for MCI Systemhouse's Technology Division, 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 methodology and modeling issues. He is a member of the ACM, IEEE and ASD.

Hernán is a former computer science instructor at the Universidad Técnica Federico Santa María and the Georgia Institute of Technology. He is presenting a paper at the OOPSLA technical session on work related to his dissertation on the reorganization of object-oriented models. Last but not least, he makes awesome coffee.