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
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:
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  [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.
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 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:
The following section describes several MCI Systemhouse initiatives
for addressing some of these areas.
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:
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
 We note that the Unified Modeling Language is an object modeling notation, not an object method.
|[Booch 94]||G. Booch. Object-Oriented Analysis and Design with Applications, Benjamin/Cummings, Redwood City, CA, 1994.|
|[Booch 95]||G. Booch and J. Rumbaugh. Unified Method for Object-Oriented Development: Document Set, Version 0.8, Rational Software Company, Santa Clara, CA, 1995.|
|[Booch 96]||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.|
|[Buschmann 96]||F. Buschmann, et al. A System of Patterns: Pattern-Oriented Software Architecture, John Wiley, New York, 1996.|
|[Jacobson 92]||I. Jacobson, et al. Object-Oriented Software Engineering, Addison-Wesley, Wokingham, England, 1992.|
|[OMG 96]||Object Analysis and Design Facility RFP-1, Object Management Group, Document ad/96-05-1, 1996.|
|[Rasmussen 96]||G. Rasmussen et al. Extending the MOSES Methodology to Distributed Systems, Journal of Object-Oriented Programming, 8 (4):39-46, 1996.|
|[Raymond 95]||K. Raymond and L. Armstrong. Open Distributed Processing: Experiences with distributed environments, Chapman & Hall, London, 1995.|
|[Rumbaugh 91]||J. Rumbaugh, et al. Object-Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, NJ, 1991.|
|[Wirfs-Brock 90]||R. Wirfs-Brock, et al. Designing Object-Oriented Software, Prentice Hall, Englewood Cliffs, NJ, 1990.|
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.
Hernán 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.
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 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.