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.
2 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.
3 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.
4 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 doesn’t 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
6 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.
7 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.
8 10/15/01
Distributed Object
Technologies
CORBA
Enterprise Java Beans
COM+
Object Oriented Databases
JINI
9 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 10/15/01
Distributed Object Topics
Object Brokers
Object Services
Object Transaction Monitors
Object Groupware
Object Databases
Object Web Technology
Object Linking
Object Frameworks
11 10/15/01
Object Request Brokers
An Object Request Broker (ORB) provides
the connections that allow components to
interoperate.
An ORB must be augmented with a high-
level component infrastructure that defines
how the objects can work together.
This component infrastructure defines how
object operate within containers (or
frameworks).
12 10/15/01
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.
14 10/15/01
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 object’s 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.
21 10/15/01
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
22 10/15/01
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 client’s request.
23 10/15/01
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
24 10/15/01
OMA (Orfali, Harkey, Edwards, Figure 22-2)
Common Facilities
Vertical Common Facilities
Application Horizontal Common Facilities
Objects Distributed Information Systems Task
Documents Management Management Management
Object Request Broker
Naming Persistence Life Cycle Collection
Properties Concurrency
Security Trader Externalization Events Time Relationships
Transactions Startup 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
26 10/15/01
RPC vs. ORB
(Orfali, Harkey, Edwards, Figure 22-4)
Client Server Client Server
Object X Object Y
Invoke Invoke
foo on foo on
foo foo
Call foo Code Data Object X Object Y
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
Client Dynamic
Interface Static Object Imple-
Dynamic ORB Skeleton
Repos- IDL Skeletons Adapter mentation
Invocation Interface Invocation
itory Stub 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 CORBA’s 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)
This model should (.car)
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).
31 10/15/01
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 world’s 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.
35 10/15/01
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.
36 10/15/01
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
object’s implementation methods.
38 10/15/01
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.
Plug-in Jack
Client Component
Application Object
Interface Pointer
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.
40 10/15/01
DCOM Objects
A COM object, also known as an ActiveX
object, is a component that supports one
or more interfaces defined by the object’s
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).
41 10/15/01
IUnknown
All COM objects must implement the
IUnknown interface to control the lifetime
of the object and handle interface
negotiations.
IUnknown
Interface A
DCOM
Interface B
Object
Interface C
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.
43 10/15/01
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.
45 10/15/01
DCOM Client Server
Boundaries (Figure 23-5)
Client Process Local Server Process
In-Process
Object
Stub Local Local
Client In-Process Server Object
DCOM Server
Application
Local
Object LRPC
Proxy
Remote Machine
DCOM Remote Server Process
Remote Server Process
Remote RPC Stub Remote
Object Remote
Object
Proxy DCOM 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 interface’s 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.
48 10/15/01
.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
49 10/15/01
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 CORBA Java/RMI
Supports multiple interfaces for objects Supports multiple inheritance at the Supports multiple inheritance at the
and uses the QueryInterface() interface level interface level
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. Every interface inherits from Every server object implements
CORBA.Object 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 a remote server Uniquely identifies remote server Uniquely identifies remote server
object through its interface pointer, objects through object objects with the ObjID, which serves as
which serves as the object handle at references(objref), which serves as the object handle at run-time. When
run-time. the object handle at run-time. These you .toString() a remote reference,
object references can be externalized there will be a substring such as
(persistified) into strings which can "[1db35d7f:d32ec5b8d3:-8000, 0]"
then be converted back into an objref. which is unique to the remote server
object.
Uniquely identifies an interface using Uniquely identifies an interface using Uniquely identifies an interface using
the concept of Interface IDs (IID) and the interface name and uniquely the interface name and uniquely
uniquely identifies a named identifies a named implementation of identifies a named implementation of
implementation of the server object the server object by its mapping to a the server object by its mapping to a
using the concept of Class IDs (CLSID) name in the Implementation URL in the Registry
the mapping of which is found in the Repository
registry.
The remote server object reference The remote server object reference The remote server object reference
generation is performed on the wire generation is performed on the wire generation is performed by the call to
protocol by the Object Exporter protocol by the Object Adapter the method
UnicastRemoteObject.exportObject(
this)
Tasks like object registration, skeleton The constructor implicitly performs The RMIRegistry performs common
instantiation etc. are either explicitly common tasks like object registration, tasks like object registration through
performed by the server program or skeleton instantiation etc the Naming class.
handled dynamically by the COM run- UnicastRemoteObject.exportObject(
time system. this) method performs skeleton
instantiation and it is implicitly called in
the object constructor.
Uses the Object Remote Procedure Uses the Internet Inter-ORB Uses the Java Remote Method
Call(ORPC) as its underlying remoting Protocol(IIOP) as its underlying Protocol(JRMP) as its underlying
protocol remoting protocol remoting protocol (at least for now)
When a client object needs to activate When a client object needs to activate When a client object needs a server
a server object, it can do a a server object, it binds to a naming or object reference, it has to do a
CoCreateInstance()- (Note:There are other a trader service - (Note:There are other ways that lookup() on the remote server object's
ways that the client can get a server's interface pointer, but we
won't go into that here)
the client can get a server reference, but we won't go into that
here) URL name.
The object handle that the client uses The object handle that the client uses The object handle that the client uses
is the interface pointer is the Object Reference is the Object Reference
The mapping of Object Name to its The mapping of Object Name to its The mapping of Object Name to its
Implementation is handled by the Implementation is handled by the Implementation is handled by the
Registry Implementation Repository RMIRegistry
The type information for methods is The type information for methods is Any type information is held by the
held in the Type Library held in the Interface Repository Object itself which can be queried
using Reflection and Introspection
The responsibility of locating an object The responsibility of locating an object The responsibility of locating an object
implementation falls on the Service implementation falls on the Object implementation falls on the Java Virtual
Control Manager (SCM) Request Broker (ORB) Machine (JVM)
The responsibility of activating an The responsibility of locating an object The responsibility of activating an
object implementation falls on the implementation falls on the Object object implementation falls on the Java
Service Control Manager (SCM) Adapter (OA) - either the Basic Object Virtual Machine (JVM)
Adapter (BOA) or the Portable Object
Adapter (POA)
The client side stub is called a proxy The client side stub is called a proxy or The client side stub is called a proxy or
stub stub
The server side stub is called stub The server side stub is called a The server side stub is called a
skeleton skeleton
All parameters passed between the When passing parameters between the When passing parameters between the
client and server objects are defined in client and the remote server object, all client and the remote server object, all
the Interface Definition file. Hence, interface types are passed by objects implementing interfaces
depending on what the IDL specifies, reference. All other objects are passed extending java.rmi.Remote are
parameters are passed either by value by value including highly complex data passed by remote reference. All other
or by reference. types objects are passed by value
Attempts to perform distributed Does not attempt to perform Attempts to perform distributed
garbage collection on the wire by general-purpose distributed garbage collection of remote server
pinging. The DCOM wire protocol uses garbage collection. objects using the mechanisms bundled
a Pinging mechanism to garbage collect in the JVM
remote server object references. These
are encapsulated in the IOXIDResolver
interface.
Allows you to define arbitrarily complex Complex types that will cross interface Any Serializable Java object can be
structs, discriminated unions and boundaries must be declared in the IDL passed as a parameter across
conformant arrays in IDL and pass processes.
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 Will run on any platform as long as Will run on any platform as long as
there is a COM Service implementation there is a CORBA ORB implementation there is a Java Virtual Machine
for that platform (like Software AG's for that platform (like Inprise's implementation for that platform
EntireX) VisiBroker) (provided by a whole lot of companies
in addition to JavaSoft and Microsoft)
Since the specification is at the binary Since this is just a specification, Since it relies heavily on Java Object
level, diverse programming languages diverse programming languages can be Serialization, these objects can only be
like C++, Java, Object Pascal (Delphi), used to code these objects as long as coded in the Java language
Visual Basic and even COBOL can be there are ORB libraries you can use to
used to code these objects code in that language
Each method call returns a well-defined Exception handling is taken care of by Allows throwing exceptions which are
"flat" structure of type HRESULT, Exception Objects. When a distributed then serialized and marshaled across
whose bit settings encode the return object throws an exception object, the the wire.
status. For richer exception handling it ORB transparently serializes and
uses Error Objects (of type marshals it across the wire.
IErrorInfo), and the server object has
to implement the ISupportErrorInfo
interface.
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 sub-
language 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();
}
//exception handling would go here ...
61 10/15/01
Reference
Robert Orfali, Dan Harkey, Jeri Edwards,
Client Server Survival Guide, Third
Edition, Wiley, 1999.
62 10/15/01