Chapter 3 Introduction to Distributed Objects Distributed object support all of the properties of an object created in compiled object oriented language, namely,data and code encapsulation, polymorphism and inheritance and can be kept on multiple heterogeneous platform to remote users in the such way that users can invoke the methods without the knowledge about the platform on which the object is supported.distributed object systems helps developers to run their programming objects on a remote host rather.than the local host. The objective of most distributed object systems is to let any object reside anywhere on the network, and allow an application to interact with these objects exactly the same way as they do with a local object. Additional features found in some distributed object schemes are the ability to construct an object on one host and transmit it to another host, and the ability for an agent on one host to create a new object on another host. Key Definition: Distributed Computing Environment: - The Distributed Computing Environment is a set of standard pioneered by the open software foundation (OSF), includes a standard for RPC. Although the DCE standard has been around for some time, and was probably a good idea, it has never gained wide acceptance and exists today as little more than an historical curiosity. CORBA: The Common Object Request Broker Architecture (CORBA) from the Object Management Group (OMG) provides a platform-independent, language-independent architecture for writing distributed, object-oriented applications. CORBA objects can reside in the same process, on the same machine, down the hall, or across the planet. IDL: It is a standard language used to define the interfaces used by CORBA objects. The IDL specification is responsible for ensuring that data is properly exchanged between dissimilar languages. A language mapping: - It is a specification that maps IDL language constructs to the constructs of a particular programming language. COM: - COM defines application programming interface (API) to allow for the creation of components for use in integrating custom applications or to allow diverse components to interact. COM also defines a binary interface standard. This standard helps to promote language-independence. DCOM: - DCOM allows COM objects executing on one computer to create COM objects on other computers and access their methods. The location of the remote object is 1
transparent. Using DCOM, remote objects are accessed in exactly the same manner as local objects EJB: - Enterprise JavaBeans (EJB) is a managed, server-side component architecture for modular construction of enterprise applications. Or it is an architecture for setting up program component, written in the Java programming language, that run in the server parts of a computer network that uses the client/server model. Theory: Distributed Objects Ø In a distributed object system, an object's data should be accessible only via its methods. Objects can be accessed via object references. Ø It is an action is initiated by an object invoking a method in another object. The state of an object consists of the values of its instance variables. Remote invocations are method invocations for objects in different processes (in the same machine or not). Distributed object technologies Ø DCOM (Distributed Common Object Model), developed by Microsoft, but also available on other platforms. Built on top of DCE's, RPC's interacts with COM. Ø CORBA (Common Object Request Broker Architecture), defined by the Object Management Group, an industry consortium. CORBA is available for most major operating systems. Ø JINI is developed on top of Java. JINI was released by Sun in January 1999. OMG (Object Management Group) Ø The OMG is a non-profit consortium created in 1989 to promote the theory and practice of object technology for the development for distributed operating systems. Ø The goal is to provide a common architectural framework for object oriented applications based on widely available interface specifications. With a membership of over 800 members, representing large and small companies within the computer industry, OMG leads the specification development efforts of CORBA, OMG IDL, OMA, UML, MOF and CWM specifications. Ø Object Management Group (OMG) is a consortium, originally aimed at setting standards for distributed object-oriented systems, and is now focused on 2
modeling (programs, systems and business processes) and model-based standards. Ø OMG provides only specifications, and does not provide implementations. But before specification can be accepted as a standard by OMG, the members of the winning submitter team must guarantee that they will bring a conforming product to market within a year. This is an attempt to prevent unimplemented standards. OMG products Ø Common Object Request Broker Architecture (CORBA) At its beginning OMG set out to create the initial Common Object Request Broker Architecture (CORBA) standard which appeared in 1991. As of 31 March 2003, the latest standard is CORBA 3.0. OMG has also developed a core set of standards adapting CORBA for embedded and real time systems. Implementations of real time CORBA are widely used in control systems in ships and aircraft Ø Data Distribution Service Data Distribution Service for real-time systems (DDS) is a specification of a publish/subscribe middle ware for distributed systems created in response to the need to augment CORBA with a data-centric publishsubscribe specification Ø Model Driven approach OMG evolved towards modeling standards by creating the standard for Unified Modeling Language (UML) followed by related standards for Meta-Object Facility (MOF), XML Metadata Interchange (XMI) and MOF Query News transformation (QVT), These together provide the foundation for Model Driven Architecture (MDA), Ø Architecture Driven Modernization Architecture Driven Modernization (ADM) is the reverse of MDA. ADMTF is an OMG group similar to ADTF with high potential. Ø Business models - OMG manages a number of standards for business modeling including BPMN, the Business Motivation Model (BMM) and the Semantics of Business Vocabulary and Business Rules (SBVR) specification. Ø Verticals - Considerable progress has also been made in developing vertical model based standards in the healthcare, finance, telecommunications, manufacturing, software-defined radio, space/ground systems communications and some dozen other technology areas. Ø Certification OMG offers three professional certifications: 3
OCRES - OMG certified real-time and embedded systems specialist. 2. OCUP - OMG certified uml professional. 3. OCEB - OMG certified expert in business process management (BPM). Ø The OMG does not produce software or implementation guidelines, only the specifications to which OMG members respond to in Request for Information (RFI) and Requests for Proposals (RFP).By managing these specifications, the OMG supports the adoption process for the member companies interested in advancing the uses and applications of distributed object-oriented computing. Overview of CORBA The Common Object Request Broker Architecture (COREA) is an emerging open distributed object computing infrastructure being standardized by the Object Management Group (OMG). COREA automates many common network programming tasks such as object registration, location and activation, request demultiplexing, framing and error handling, parameter marshalling and demarshalling, and operation dispatching. Application object Domain specific Horizontal Facilities Common Object Service Object Request Broker Overview of CORBA Technology Ø The Common Object Request Broker Architecture (COREA) is a standard developed by the Object Management Group (OMG) to provide interoperability among distributed objects. CORBA is the world's leading middleware solution enabling the exchange of information, independent of hardware platforms, programming languages and operating systems. Ø CORBA is essentially a design specification for an Object Request Broker (ORB), where an ORB provides the mechanism required for distributed objects to communicate with one another, whether locally or on remote devices, written in different languages, or at different locations on a network. Ø The CORBA Interface Definition Language, or IDL, allows the development of language and location-independent interfaces to distributed objects. 4
Ø Using CORBA, application components can communicate with one another no matter where they are located, or who has designed them. CORBA provides the location transparency to be able to execute these applications. CORBA is often described as a software bus because it is a software-based communications interface through which objects are located and accessed. Ø Common Object Request Broker Architecture is the result of the work done by major actors of the hardware and software industry to set up a communication framework. Ø The goal is to facilitate the development of distributed applications over a heterogeneous network. In a distributed environment, clients are talking to objects. Ø The services that can be delivered to a client by an object are described in an interface. The means of communication are handled by an Object Request Broker (ORB). Ø The idea behind CORBA is to provide an intermediary layer that handles access requests on data. It frees the developer from most of the portability issues. It enables the development of distributed objects. Ø Objects that are somewhere on a network, some place that will not always remain the same. CORBA defines a two-fold set of specifications. Ø To be CORBA compliant, a vendor must implement at least the CORBA core: the CORBA Object Model, the CORBA architecture, the Interface Definition Language (IDL) syntax and semantics, an ORB (which supports the Dynamic Invocation Interface, Dynamic Skeleton Interface, the Interface Repository) and one language mapping. In addition, the vendor is free to implement a number of services. Those services, if implemented, are granted a separate compliance point. Ø The main CORBA services are lifecycle, events, naming, persistent object service and relationships. CORBA is already in reality industry standard. We strongly believe that it will become a standard in the bioinformatics community. The long term goal is to allow a true and productive interoperation between distributed programs and databases. CORBA developments can be featured as follows: Ø Object oriented technologies give the best model to capture the richness of data in biology. 5
Ø The data and methods to operate an object are described by means of the Interface Definition Language (IDL), a strongly typed language. Ø The IDL compiler generates a stub for the client side and a skeleton for the object implementation side. The ORB must store the IDL definition of each object in the interface repository. It means that a client can possibly access a CORBA object with no prior knowledge of its implementation scheme. It is the foundation for interoperability. Ø CORBA provides a set of services that prevents one from reinventing the wheel. The Object Management Group, the large industry consortium which accredits CORBA products, guaranties the benefits from industry standards: scalability, robustness, support, long-term future. It is commonly admitted that bioinformatics developments suffered from a lack of consistent standards. Overview of COM /DCOM Model Overview of COM Ø Component Object Model (COM) is a binary-interface standard for software component introduced by Microsoft in 1993. It is used to enable interprocess communication and dynamic object creation in a large range of programming languages. The term COM is often used in the software development industry as an umbrella term that encompasses the OLE, OLE Automation, ActiveX, COM+ and DCOM technologies. Ø The essence of COM is a language-neutral way of implementing objects that can be used in environments different from the one they were created in, even across machine boundaries. Ø For well-authored components, COM allows reuse of objects with no knowledge of their internal implementation, as it forces component implementers to provide well-defined interfaces that are separate from the implementation. The different allocation semantics of languages are accommodated by making objects responsible for their own creation and destruction through reference counting.. Ø Although the interface standard has been implemented on several platforms, COM is primarily used with Microsoft Windows. For some applications, COM has been replaced at least to some extent by the Microsoft.NET framework, and support for web services through the Windows Communication Foundation (WCF). However, COM objects can be used with all.net languages through.net COM. Ø COM is very similar to other component software interface standards, such as CORBA and Java beans, although each has its own strengths and weaknesses. 6
The characteristics of COM make it most suitable for the development and deployment of desktop applications, for which it was originally designed. The Component Object Model (COM) is a component software architecture that allows applications and systems to be built from components supplied by different software vendors OLE. Component object model foundation with high-level OLE application services These services provide distinctly different functionality to the user; however, they share a fundamental requirement for a mechanism that allows binary software components, supplied by different software vendors, to connect to and communicate with each other in a well-defined manner. It provides following capabilities Ø Defines a binary standard for component interoperability. Ø Is programming language-independent. Ø Is provided on multiple platforms (Microsoft Windows, Microsoft Windows, Apple Macintosh). Ø Provides for robust evolution of component-based applications and systems. Ø Is extensible. Ø Communications between components, even across process and network boundaries. Ø Shared memory management between components. Ø Error and status reporting. Ø Dynamic loading of components. 7
DCOM Ø DCOM (Distributed Component Object Model) is currently being developed by Microsoft Corporation as a follow-up to its COM implementations. DCOM is an application level protocol for object-oriented remote procedure calls (RPC' s) intended for a distributed system. Ø It is based on the distributed computing environment (DCE) RPC specification developed by the Open Software Foundation (OSF). Through the use of COM,DCOM will support standard functionality of any distributed environment, including the web, regardless of computer platform, communication protocol and operating system. Ø Networked DCOM uses binary proprietary formats, while WCF encourages the use of XML-based SOAP messaging. The vision of Microsoft for COM, as previously described in this chapter, is a universal infrastructure for implementing highly portable, object-oriented software that can be used by any of its operating systems, including future versions of Windows 95 and Windows NT. Ø All software, including operating system modules, applications and networking, will be written so that they conform to the COM specification and therefore can be easily transplanted to any platform without customization. Ø DCOM is an extension of this idea. Just as future software implementations will use COM to access the local features of a computer, DCOM allow these same software implementations to use remote features of other connected computers. Any resource, barring security restrictions, available to a local PC can then also be made available to remote PCs over a connection. A perfect implementation would be on the World Wide Web. DCOM keys features DCOM implementation is synonymous to an RPC implementation that conforms to the DCE specification. Ø Key features of DCOM are portability, runtime binding across the network, transparency to requesting applications, and most importantly, a well-defined interface to allow remote task execution. Some details of DCOM features follow. Ø DCOM utilizes the network data representation (NDR) for any arbitrary data types supported by DCE RPC. 8
Ø This implementation eliminates the need for increased complexity required with the development to support the growing number of formats and task-specific syntax. Ø With today's explosion of new formats and syntax, the effort to upgrade existing software for these features is tremendous. DCOM allows one common method to support these and future technologies. Ø Another feature of DCOM is the inherent support for a secure distributed environment. Ø DCOM implements the security provided by DCE RPC, including its capability for authentication, authorization and data integrity. This is an absolute requirement in today's Web, due to the popularity of applications to transmit confidential data and the adoption of intranets by companies requiring limited, monitored access to confidential information. Ø Today, information is updated on the web by simply overwriting existing data and programs. To keep the integrity of the existing interface, both server and client software must be updated simultaneously. With DCOM, this is not necessary. You can label an interface version with universally unique IDs (UUIDs). Ø You can then update an existing interface by publishing a new UUID with the interface, so that both the old and new interfaces can be supported. And two parties can simultaneously update an existing interface without fear of conflict between the two updates. Ø To understand the implementation of DCOM, one must first understand the RPC protocol as defined by the DCE. The following is a list of terminology that requires definition and clarification: Ø Binding - Establishing a connection between a client and a server that facilitates the actual calling of the RPC. Ø Endpoint - A protocol-specific interface used by servers to listen for RPC requests. Ø Entry Point Vector (EPV) - Entry points to the operations supported by managers within the application. Ø Manager - A set of routines that implements the operations of an interface Multiple managers for the same interface can coexist to facilitate multiple revisions. 9
Ø Name Service - The RPC API that allows applications, on both client and server, to transfer binding information. Ø Universally unique identifier (UUID) - An identifier used by RPC to determine the characteristics of an RPC interface or object. The basis for RPC protocol is in a client/server implementation. An RPC is the protocol by which a client can call a resource available at a remote node (server) through its local RPC manager DCOM functionality Ø A DCOM call, also called object RPC (ORPC), is actually an RPC call as specified by the DCE. With this implementation, DCOM inherits the security, reliability and robustness inherent in the RPC protocol. This section discusses the few minor differences between DCOM and RPC. Ø DCOM utilizes an interface pointer identifier (IPID). This 128-bit identifier is synonymous with the UUID of RPC and is used to identify a specific interface of an object on a server. In fact, the static type of IPID is a UUID. Ø In a DCOM implementation, the interface ID contains two additional arguments: ORPCTHIS and ORPCTHAT. An ORPCTHAT argument may also be present in a fault, which is the result of calling an ORPC on a server that does not support the specified interface to the requested object. Ø The IPID may contain pertinent information to identify the server, object and interface requested with a ORPC, but it cannot specify the binding information required to execute the ORPc. Overview of EJB Sun Microsystems' definition of Enterprise JavaBeans is: The Enterprise JavaBeans architecture is component architecture for the development and deployment of component-based distributed business applications. Ø Applications written using the Enterprise JavaBeans architecture is scalable, transactional and multi-user secure. Ø These applications may be written once, and then deployed on any server platform that supports the Enterprise JavaBeans specification. Ø Enterprise JavaBeans is a standard server-side component model for distributed business applications. Ø This means EJB offers a standard model for building server-side components that represent both business objects (i.e., customers, items in inventory, and the like) 10
and business processes (i.e., purchasing, stocking, and so on). Once you have built a set of components that fit the requirements of your business, you can Ø Combine them to create business applications. Ø On top of that, as distributed components, they don't all have to reside on the same server: components can reside wherever it's most convenient: a customer component "live" near the customer database, a part component can live near the inventory database, and a Purchase business-process component can "live" near the user interface: you can do whatever's necessary for minimizing latency, sharing the processing load, or maximizing reliability. Ø The EJB control is an extensible control, and you do not use it directly. To create an EJB control for an EJB, you would create a control extending the EJB Control. An extended EJB control can only represent one EJB, so you must create one for each EJB. Ø Enterprise JavaBeans architecture is the standard component architecture for building distributed object-oriented business applications. Ø Enterprise JavaBeans architecture makes it possible to build distributed applications by combining components developed using tools from different vendors. Ø Application developers do not have to understand low-level transaction and state management details, multi-threading, connection pooling, and other complex low level APls Ø The Enterprise JavaBeans architecture addresses the development, deployment and runtime aspects of an enterprise application's life cycle. Ø Enterprise JavaBeans architecture defines the contracts that enable tools from multiple vendors to develop and deploy components. Ø Enterprise JavaBeans architecture is compatible with the CORBA protocols. This allows remote invocations on session and entity beans from J2EE components that are deployed in products from different vendors. Benefits of EJB 1. Defines the integration of EJB with the Java Message Service. Introduces message-driven beans (MDB) - a stateless components that are invoked by the container as a result of the arrival of a JMS message (MDB does not have home/home - local or remote local interfaces). 2. Provides a local client view and support for efficient, lightweight access to enterprise beans from local clients. 11
3. Provides improved support for the persistence of entity beans. 4. Provides improved support for the management of relationships among entity beans (Local CMP Beans only). 5. Provides query syntax (EJB QL) for entity bean finder and select methods (CMP only). 6. Provides support for additional methods in the home interface (i.e., business logic methods via ejbhome). Objective Questions: Multiple Choice Questions 1. Which of the following promotes interoperability between cells? a. CDS b. GDS c. GDA d. Interface 2. Interoperability between DCE RPC and MS RPC is facilitated through a. CDS. b. GDS. c. GDA. d. nsid. 3. Which of the following offers procedure oriented interface? a. DCOM b. Sun RPC c. RMI d. CORBA 4. Which of the following offers object-oriented interface? a. DCE b. Sun RPC c. RMI d. Both a and b 5.. Marshalling data in RMI uses a. CDR. b. XDR. c. Java object serialization. d. NDR. 6. Which of the following allocates/deallocates buffers? a. RRL 12
b. Stub/skeleton layer c. Transport layer d. Networking layer 7. Which of the following in RMI manages connections? a. RRL b. Stub/skeleton layer c. Transport layer d. Networking layer 8. The method that registers a Java object in RMI registry is a. Naming.rebind. b. Naming. lookup. c. Naming. bind. d. both a and c. Fill in the Blanks 1. Registration and location of remote objects is done using 2. provides the semantics for method invocation, whereas provides the semantics for object invocation. 3. provides the methods needed to create remote objects and export them. 4. The default port for RMI registry is 7. enforces exactly once semantics. 8. is used to bring about asynchronism in MOM. Answers to Multiple choice questions Q1 c Q.2. d Q.3. b Q.4. c Q.5 c Q.6. a Q.7. c Q.8 d Answers to fill in the Blanks 1. RMIRegistry 2. RPC; RMI 3. Remote Object 4. 1099 5. Database 6. SPX 7. Transactional RPC 13
8. Queues; Storage Subjective Questions: Q 1 Explain Object Management Group (OMG) in detail. Q. 2 Explain Component Object Model (COM) in brief. Q. 3 Explain Distributed Component Object Model (DCOM) in brief. Q. 4 Explain the key features of DCOM. Q. 5 What are the benefits of EJB? University Exam Questions: Q.1 Mention and explain the different features of distributed computing environment. 14