Distributed Objects and Components

NJIT
1
10/15/01

Distributed Objects

The benefits of an object oriented approach to software development are greatly enhanced when they can be distributed over a network. A classical object encapsulates code and data. A distributed object is an object that can live anywhere on a network, and can be invoked by remote clients via method invocations.
10/15/01

Components

Distributed objects are independent software components. Components are not bound to a particular program, computer language, or implementation. Components are packaged as the basic unit of work and distribution for an application made up of distributed objects.

10/15/01

Key Characteristic

Possibly the most important distinguishing characteristic between an application and a component is that components can be used in unpredictable combinations, while applications tend to be focused on a particular task or environment.

10/15/01

Why Components?

Interoperability between:

Different Languages Different Compilers Different Vendors Different Operating Systems Different Tools Different Networks Different Applications Different Address Spaces (Microsoft doesnt believe in Vendor independence.)
5
10/15/01

Properties of Components

A marketable entity Not a complete application Usable in unpredictable combinations Well specified interface Toolability Event notification Configuration and property management Scripting Metadata and Inspection Interoperability Ease of Use
10/15/01

Server Side Components

Components on the Server side need added intelligence. They need to be more concerned with Security, Licensing, Versioning, Life Cycle Management, Transaction Control and Locking, Persistence, Relationships, Self-Testing, Semantic Messaging and Self-installation than Client side components.
10/15/01

Server Security Issues

Distributed Objects create special security problems for Servers: They can play both Client and Server roles Distributed objects evolve constantly Their interactions are not well understood Distributed objects are less predictable Distributed objects are polymorphic Distributed objects can scale without limit Distributed objects are very dynamic Most of these problems can be solved by moving security into the CORBA ORB.
10/15/01

Distributed Object Technologies

CORBA Enterprise Java Beans COM+ Object Oriented Databases JINI

10/15/01

Component Standards

On the desktop, Java Beans and ActiveX are competing component standards. On the server, component standards include Enterprise Java Beans, CORBA Beans, and COM+. CORBA Internet Inter-ORB Protocol (IIOP) provides a transactional pipe for EJBs, linking Java and CORBA.
10/15/01

10

Distributed Object Topics

Object Brokers Object Services Object Transaction Monitors Object Groupware Object Databases Object Web Technology Object Linking Object Frameworks
10/15/01

11

Object Request Brokers

An Object Request Broker (ORB) provides the connections that allow components to interoperate. An ORB must be augmented with a highlevel component infrastructure that defines how the objects can work together. This component infrastructure defines how object operate within containers (or frameworks).
10/15/01

12

Object Transaction Monitors

OTMs are the state of the art in component management. Instead of the ORB approach, where you need to write separate code to call each needed service separately, an OTM provides a suite of services with a common call structure.

13

10/15/01

Enterprise Java Beans

Possibly the most fashionable components today are Enterprise Java Beans, a component structure in Java that has been designed from the ground up to be compatible with CORBA. EJBs use the RMI/IDL CORBA subset for their distributed object model, and the Java Transaction Service, a subset of the CORBA OTS, for distributed transactions.
10/15/01

14

An EJB Application Example

15

10/15/01

Internet Inter-ORB Protocol

Enterprise Java Beans use the CORBA IIOP (Internet Inter-ORB Protocol) to

Operate across multi-vendor servers Propagate transaction and security contexts Service multilingual clients Support ActiveX clients with DCOM to CORBA bridges

16

10/15/01

JavaBeans Component Model

BeanInfo

Customizer Methods JavaBean Component Events

Properties JAR (.jar)

17

10/15/01

The Promise of Distributed Objects

Assemble complex client/server applications with reusable software components Objects can be modified or replaced without affecting the rest of the components in the system or their interactions.

18

10/15/01

Packaging Distributed Objects

Components will be delivered in suites that run within application frameworks. Within an application framework, all pieces are known to work together to perform domain level applications.

19

10/15/01

Benefits of Distributed Objects

Visual tools and other applications can discover an objects interfaces, events, and properties dynamically. Granular components can be visually assembled with tools, interoperate across networks, run on different platforms, and manage themselves and their resources.

20

10/15/01

Benefits of Distributed Objects (2)

Object Oriented client server applications can be more flexible than traditional approaches. Components can be mixed and matched without sacrificing robustness. Interfaces are separated from implementations, so you can use an object wrapper to make an existing legacy application look like an object.
10/15/01

21

Defining Standards

The Object Management Group and Microsoft Corporation are the key competitors that are driving the movement toward distributed objects. OMG is the force behind CORBA and its integration with Java. Microsoft is trying to establish its own proprietary standard based on DCOM, ActiveX, COM+ and .NET
10/15/01

22

What is CORBA?

CORBA is a middleware that that sits between the application and the system. CORBA is based on the OO model. CORBA allows software reusability. CORBA uses a broker to handle messages. The broker provides the ability to choose servers that best fill the clients request.
10/15/01

23

Comparing CORBA to DCE

DCE uses a procedure-oriented distributed model (RPC), while CORBA is based on objects. DCE clients need to know what servers are available. CORBA clients request from the ORB, which connects them to a server. CORBA provides a more abstract level of programming
10/15/01

24

OMA (Orfali, Harkey, Edwards, Figure 22-2)

Common Facilities Vertical Common Facilities Application Objects

Horizontal Common Facilities

Distributed Information Systems Task Documents Management Management Management

Object Request Broker

Naming Persistence Security Trader

Life Cycle Externalization Startup

Collection Properties Concurrency Events

Time

Relationships

Transactions

Licensing

Query

Common Object Services (CORBA Services)

25

10/15/01

The Object Request Broker (ORB)

ORB is the object bus. ORB is the middleware that establishes the client/server relationship between objects. ORB lets objects communicate transparently without concern for :

the hosts where the objects run the operating systems the programming languages
10/15/01

26

RPC vs. ORB

(Orfali, Harkey, Edwards, Figure 22-4)

Client

Server

Client

Server
Object X Object Y

Call foo

Code

Data

Invoke foo on Object X

Invoke foo on Object Y

foo

foo

RPC link

Object Request Broker

27

10/15/01

Structure of a CORBA 2.0 ORB (Orfali, Harkey, Edwards, Figure 22-4)

Client

Object Implementation

Interface Dynamic ReposInvocation itory

Client IDL Stub

ORB Interface

Static Skeletons

Dynamic Skeleton Invocation

Object ImpleAdapter mentation Repository

Object Request Broker Core 28

10/15/01

CORBA Beans

The CORBA 3.0 Components model will include an extension of Enterprise Java Beans to CORBAs language independent model, so that you are not locked into Java for all your components.

29

10/15/01

CORBA Beans Component Model

Component Info/IDL

Customizer Methods CORBA Component Events

Properties CAR (XML) (.car)

This model should look familiar! 30

10/15/01

General Inter-ORB Protocol

Key to the interoperability of CORBA is the bus structure that allows different Object Request Brokers on different hosts in different networks to communicate with each other. The CORBA specification anticipates several of these, all based on the General Inter-ORB Protocol. (GIOP) GIOP specifies seven message formats to cover all ORB request reply formats and a Common Data Representation (CDR).
10/15/01

31

Internet Inter-Orb Protocol

The first implementation of a CORBA GIOP is the Internet Inter-ORB Protocol. (IIOP). The IIOP specifies how GIOP messages are to be exchanged over a TCP/IP network. Future specifications may cover other networks, but all CORBA implementations after 2.0 must either support IIOP or connect to it via a half bridge.

32

10/15/01

A CORBA/EJB application

33

10/15/01

COM+
The Component Bus From Microsoft

NJIT
34
10/15/01

The other component model

Microsoft, as one of the worlds largest and most profitable companies, must protect and increase its revenues to survive. Its primary approach has been to attempt to make all computing within most corporations dependent upon proprietary products for which high fees must be paid to Microsoft. It has already succeeded in capturing the desktop with Windows and Microsoft Office. Now it wants to capture the Network and the Internet.
10/15/01

35

Server, COM+, and .NET

The Microsoft product to drive Unix out of corporations is MS Windows Server. To capture the Internet, Microsoft is deploying the Microsoft Component Object Model (COM) and extending it to the Internet and Client/Server in general with COM+ and .NET If Microsoft succeeds, a lot of companies will go out of business as dBase, Netscape, and Word Perfect did, and everyone will pay a lot more for software. They use low prices and good features to kill the competition, then raise prices.
10/15/01

36

Parallels between COM and CORBA

CORBA and COM provide competing Object Request Brokers (ORB). Both attempt to provide a universal approach to connecting components Both require interfaces to be standardized through an IDL. The COM IDL is based on DCE and is not CORBA compliant.

37

10/15/01

COM Interfaces

A COM interface is a collection of function calls (methods or member functions) based on a table of pointers. A COM client uses pointers to a virtual table or vtable, which is an array of function pointers. The functions addressed through those pointers are the server objects implementation methods.
10/15/01

38

COM Plug-in Jacks

COM traditionally uses bullet-and-stick diagrams, or plug-in jacks, to represent the vtable in Interface descriptions, because they are less intimidating.
Client Application
Plug-in Jack Interface Pointer

Component Object

39

10/15/01

COM IIDs

By convention, an interface in COM is given a name beginning with I, such as IFoo. This name is only a symbol for a source level programming tool. At run time each interface is known by a unique Interface Identifier (IID). An IID is a COM generated 128-bit globally-unique identifier (GUID) for interfaces.
10/15/01

40

DCOM Objects

A COM object, also known as an ActiveX object, is a component that supports one or more interfaces defined by the objects class. A COM interface refers to a predefined group of related functions. A COM Interface implements one or more interfaces and has a unique 128 bit Class ID (CLSID).
10/15/01

41

IUnknown

All COM objects must implement the IUnknown interface to control the lifetime of the object and handle interface negotiations.
IUnknown Interface A Interface B Interface C

DCOM Object

42

10/15/01

A Key Difference

In CORBA, Objects have unique IDS. COM does not support Object IDs. With COM, clients obtain a pointer to an interface. DCOM clients cannot reconnect to the same object instance at a later time with the same state. This greatly reduces the role of object instances in COM as opposed to classic object systems.
10/15/01

43

COM Server Functions

Implement a class factory interface Register the supported classes Initialize the COM Library Verify compatibility of the library Provide an unloading mechanism Uninitialize the COM library after use

44

10/15/01

Variations of COM Servers

In-process Servers execute in the same process space as clients, and are implemented as Dynamic Link Libraries (DLL) Local Servers execute in a separate process and use DCOMs Lightweight RPC (LRPC) mechanism to communicate. Local servers have their own EXE file. Remote Servers execute in a separate process on a remote machine and use a DCE-like RPC mechanism to communicate.
10/15/01

45

DCOM Client Server Boundaries (Figure 23-5)

Client Process
In-Process Object

Local Server Process

Stub
In-Process Server Local Object Proxy Local Object

Client Application

DCOM

Local Server

LRPC

Remote Machine Remote Server Process Remote Server Process

DCOM
Remote Object Proxy

RPC

Stub

DCOM

Remote Object

Remote Server

46

10/15/01

IUnknown member functions

Every COM interface must implement three key IUnknown functions:

QueryInterface for interface negotiations AddRef to create an interface instance Release to destroy an interface instance

IUnknown is the base interface from

which all other interfaces inherit.

47

10/15/01

MIDL, the COM IDL

To develop a COM interface, you create a file that describes the interfaces methods and their arguments and run that file through the Microsoft IDL (MIDL) Compiler. The MIDL Compiler is actually a precompiler that turns text descriptions of the interface into code for proxies and stubs, and creates header files with the interface definition.
10/15/01

48

.NET Products and Services

Microsoft offers: Visual Studio .NET, a web development platform using multiple languages, but the programs will only run on .NET .NET myServices, that developers can use to create services. Microsoft will use those as a base to offer user experiences that will capture data and get people to subscribe. A .NET version of Office by subscription bCentral for small business by subscription
10/15/01

49

A Comparison of 3 most popular distributed object paradigms

Microsoft's Distributed Component Object Model (DCOM), OMG's Common Object Request Broker Architecture (CORBA) and JavaSoft's Java/Remote Method Invocation (Java/RMI).

Source: A Detailed Comparison of CORBA, DCOM and Java/RMI by Gopalan Suresh Raj

DCOM
Supports multiple interfaces for objects and uses the QueryInterface() method to navigate among interfaces. This means that a client proxy dynamically loads multiple server stubs in the remoting layer depending on the number of interfaces being used. Every object implements IUnknown.

CORBA
Supports multiple inheritance at the interface level

Java/RMI
Supports multiple inheritance at the interface level

Every interface inherits from CORBA.Object

Every server object implements java.rmi.Remote (Note : java.rmi.UnicastRemoteObject is merely a convenience class which happens to call UnicastRemoteObject.exportObject( this) in its constructors and provide equals() and hashCode() methods) Uniquely identifies remote server objects with the ObjID, which serves as the object handle at run-time. When you .toString() a remote reference, there will be a substring such as "[1db35d7f:d32ec5b8d3:-8000, 0]" which is unique to the remote server object. Uniquely identifies an interface using the interface name and uniquely identifies a named implementation of the server object by its mapping to a URL in the Registry

Uniquely identifies a remote server object through its interface pointer, which serves as the object handle at run-time.

Uniquely identifies remote server objects through object references(objref), which serves as the object handle at run-time. These object references can be externalized (persistified) into strings which can then be converted back into an objref. Uniquely identifies an interface using the interface name and uniquely identifies a named implementation of the server object by its mapping to a name in the Implementation Repository The remote server object reference generation is performed on the wire protocol by the Object Adapter

Uniquely identifies an interface using the concept of Interface IDs (IID) and uniquely identifies a named implementation of the server object using the concept of Class IDs (CLSID) the mapping of which is found in the registry. The remote server object reference generation is performed on the wire protocol by the Object Exporter

The remote server object reference generation is performed by the call to the method UnicastRemoteObject.exportObject( this)

Tasks like object registration, skeleton instantiation etc. are either explicitly performed by the server program or handled dynamically by the COM runtime system.

The constructor implicitly performs common tasks like object registration, skeleton instantiation etc

The RMIRegistry performs common tasks like object registration through the Naming class. UnicastRemoteObject.exportObject( this) method performs skeleton instantiation and it is implicitly called in the object constructor. Uses the Java Remote Method Protocol(JRMP) as its underlying remoting protocol (at least for now) When a client object needs a server object reference, it has to do a lookup() on the remote server object's URL name.

Uses the Object Remote Procedure Call(ORPC) as its underlying remoting protocol When a client object needs to activate a server object, it can do a CoCreateInstance()- (Note:There are other
ways that the client can get a server's interface pointer, but we won't go into that here)

Uses the Internet Inter-ORB Protocol(IIOP) as its underlying remoting protocol When a client object needs to activate a server object, it binds to a naming or a trader service - (Note:There are other ways that
the client can get a server reference, but we won't go into that here)

The object handle that the client uses is the interface pointer
The mapping of Object Name to its Implementation is handled by the Registry The type information for methods is held in the Type Library The responsibility of locating an object implementation falls on the Service Control Manager (SCM) The responsibility of activating an object implementation falls on the Service Control Manager (SCM)

The object handle that the client uses is the Object Reference
The mapping of Object Name to its Implementation is handled by the Implementation Repository The type information for methods is held in the Interface Repository The responsibility of locating an object implementation falls on the Object Request Broker (ORB) The responsibility of locating an object implementation falls on the Object Adapter (OA) - either the Basic Object Adapter (BOA) or the Portable Object Adapter (POA) The client side stub is called a proxy or stub The server side stub is called a skeleton

The object handle that the client uses is the Object Reference
The mapping of Object Name to its Implementation is handled by the RMIRegistry Any type information is held by the Object itself which can be queried using Reflection and Introspection The responsibility of locating an object implementation falls on the Java Virtual Machine (JVM) The responsibility of activating an object implementation falls on the Java Virtual Machine (JVM)

The client side stub is called a proxy The server side stub is called stub

The client side stub is called a proxy or stub The server side stub is called a skeleton

All parameters passed between the client and server objects are defined in the Interface Definition file. Hence, depending on what the IDL specifies, parameters are passed either by value or by reference. Attempts to perform distributed garbage collection on the wire by pinging. The DCOM wire protocol uses a Pinging mechanism to garbage collect remote server object references. These are encapsulated in the IOXIDResolver interface. Allows you to define arbitrarily complex structs, discriminated unions and conformant arrays in IDL and pass these as method parameters. Complex types that will cross interface boundaries must be declared in the IDL. Will run on any platform as long as there is a COM Service implementation for that platform (like Software AG's EntireX) Since the specification is at the binary level, diverse programming languages like C++, Java, Object Pascal (Delphi), Visual Basic and even COBOL can be used to code these objects Each method call returns a well-defined "flat" structure of type HRESULT, whose bit settings encode the return status. For richer exception handling it uses Error Objects (of type IErrorInfo), and the server object has to implement the ISupportErrorInfo interface.

When passing parameters between the client and the remote server object, all interface types are passed by reference. All other objects are passed by value including highly complex data types Does not attempt to perform general-purpose distributed garbage collection.

When passing parameters between the client and the remote server object, all objects implementing interfaces extending java.rmi.Remote are passed by remote reference. All other objects are passed by value Attempts to perform distributed garbage collection of remote server objects using the mechanisms bundled in the JVM

Complex types that will cross interface boundaries must be declared in the IDL

Any Serializable Java object can be passed as a parameter across processes.

Will run on any platform as long as there is a CORBA ORB implementation for that platform (like Inprise's VisiBroker) Since this is just a specification, diverse programming languages can be used to code these objects as long as there are ORB libraries you can use to code in that language Exception handling is taken care of by Exception Objects. When a distributed object throws an exception object, the ORB transparently serializes and marshals it across the wire.

Will run on any platform as long as there is a Java Virtual Machine implementation for that platform (provided by a whole lot of companies in addition to JavaSoft and Microsoft) Since it relies heavily on Java Object Serialization, these objects can only be coded in the Java language

Allows throwing exceptions which are then serialized and marshaled across the wire.

Object Databases
The Next Step in Components?

NJIT
54
10/15/01

Object Databases

An Object Database Management System provides a persistent store for objects in a multi-user client/server environment. The intent is to avoid mangling objects and tearing them apart to store their data in relational tables by storing objects in their natural form.

55

10/15/01

ODBMS Features

Freedom to create new forms of information Fast access Flexible views of composite structures Tight integration with OO Languages Support customizable information structures with multiple inheritance Support versioning, nesting, long-lived transactions Repositories for distributed objects Life cycle management for composite objects

56

10/15/01

ODMG

There is an Object Database Management Group that is working on a standard that will be the ODBMS answer to SQL for Relational Databases. They have already released standards for ODBMS built on the OMG object model.

57

10/15/01

ODBMS Standards

Object Definition Language (ODL) Object Query Language (OQL) C++, Smalltalk and Java Language bindings

58

10/15/01

Example: Java code accessing ODBMS

This example uses the ODMG Java Binding and the ODMG Object Query Language (OQL). Notice that all the code is Java, with the exception of the query string. You will not find a database sublanguage in this example.
import org.odmg.*; import java.util.Collection; Implementation impl = new com.vendor.odmg.Implementation(); Database db = impl.newDatabase();

59

10/15/01

Example: Java code accessing ODBMS

Transaction txn = impl.newTransaction(); try { db.open("addressDB", Database.OPEN_READ_WRITE); txn.begin(); // perform query OQLQuery query = new OQLQuery( "select x from Person x where x.name = \"Doug Barry\""); Collection result = (Collection) query.execute(); Iterator iter = result.iterator();
60
10/15/01

Example: Java code accessing ODBMS

// iterate over the results while ( iter.hasNext() ) { Person person = (Person) iter.next(); // do some addition processing on the person (now shown) // now traverse to the address object and update its value person.address.street = "13504 4th Avenue South"; } txn.commit(); db.close();
61 } //exception handling would go here ...
10/15/01

Reference

Robert Orfali, Dan Harkey, Jeri Edwards, Client Server Survival Guide, Third Edition, Wiley, 1999.

62

10/15/01