Handbook of Local Area Networks, 1998 Edition:LAN-based Application Development Issues and Solutions Click Here! Search the site:   ITLibrary ITKnowledge EXPERT SEARCH Programming Languages Databases Security Web Services Network Services Middleware Components Operating Systems User Interfaces Groupware & Collaboration Content Management Productivity Applications Hardware Fun & Games EarthWeb sites Crossnodes Datamation Developer.com DICE EarthWeb.com EarthWeb Direct ERP Hub Gamelan GoCertify.com HTMLGoodies Intranet Journal IT Knowledge IT Library JavaGoodies JARS JavaScripts.com open source IT RoadCoders Y2K Info Previous Table of Contents Next CORBA Version 2.0 The definition of technical standards in object services was achieved in 1993 with the agreement on volume 1 of OMG’s Common Object Services Standard (COSS). This standard defines the four common services of CORBA: •  Object naming. •  Object events. •  Life cycle. •  Persistent Object Services. Most of the 16 other OMG-identified object services depend on these four common services. The CORBA2 technical specification, which is now available, is likely to be a determining event in the establishment of object technology. CORBA2 was adapted from a joint proposal by Digital Equipment Corp., Hewlett-Packard Co., HyperDesk Corp., NCR Corp., Object Design, Inc., and SunSoft, Inc. CORBA2 provides a framework for defining a “core CORBA” specification, which every ORB should support to claim CORBA2-compliance branding. Thus, unlike CORBA1, the CORBA2 specification provides a framework for ORBs from different vendors to provide common ORB services and interfaces to support portable clients and implementations of objects. There are likely to be two categories of CORBA2-compliant ORBs emerging in the future: 1.  CORBA2 standalone ORBs, which will be single-node ORBS that would support the CORBA2/core and some set of CORBA2 programming language mappings. Interoperability between ORBs would be provided via bridges. 2.  CORBA2 networked ORBS, which would support the CORBA2/core and some set of CORBA programming language mappings and would also provide multinode operations using either: •  The Internet Inter-Object Protocol (IOP). •  An environment-specific Inter-ORB protocol (ESIOP), such as DCE IOP. •  A proprietary protocol. According to the OMG, interoperability with other networked ORB domains would be provided by means of the Internet IOP, supported natively or via a half bridge. Whether defining CORBA1 or CORBA2, the OMG reference model needs to be understood. OMG’s Object Reference Model The OMA will act as a layer above existing operating systems and communication protocols that are supported by such standard RPCs as DCE RPCs. The OMA is defined by the OMG’s object reference model (see Exhibit 6-4-6); its key elements are discussed next. Exhibit 6-4-6.  The Object Management Group Reference Model The Object Request Broker As defined by the OMG, the ORB provides the mechanisms by which objects can transparently make requests and receive responses. It provides interoperability between application segments on different machines in heterogeneous environments and seamlessly interconnects multiple object systems. To provide a linkage to other OMA components, the ORB uses its Interface Definition Language (IDL), an OMG-developed language with roots in C++. IDL mappings to C were provided in the CORBA1 specification. In CORBA2, in addition to the C mappings, mappings for C++ and Smalltalk were added. In CORBA2, interoperability between ORBs was designed to be networked with other compatible ORBs (as opposed to bridged or standalone) and is accomplished via the Internet IOP specification. To achieve optimized interoperability between ORBs running in different environments, a set of ESIOPs is being developed. The first ESIOPs will be based on DCE. The client makes a request to the ORB for the object. The ORB is responsible for all the mechanisms required to find the object, to prepare the object to receive the request, and to communicate the data needed to perform the request. The interface that the client sees is completely independent of where the object is located,how it is implemented (e.g., programming language), or any other aspect not explicitly stated in the interface. Interfaces to objects can be implemented in one of two ways: Interfaces may be defined statically in IDL, which are known to the client at compile time, or the client may interrogate the interface repository, which allows run-time binding and access to these objects. Object Services These utility-like objects provide basic object-oriented housekeeping chores. They also provide for the consistency, integrity, and security of objects and the messages that are passed between objects. Common Facilities Common facilities comprise facilities that are useful in many application domains and will be made available through OMA-compliant class interfaces. Common facilities may include such things as print services, error handling, or help services. They may be user interface objects or background objects. Previous Table of Contents Next Use of this site is subject certain Terms & Conditions. Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.