Object Oriented Middleware: An Analysis

grapedraughtΛογισμικό & κατασκευή λογ/κού

2 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

76 εμφανίσεις


1


Object Oriented Middleware: An Analysis


Introduction


As intelligence moves more and more away from the network and into the hosts, a means is
needed for ‘wiring’ objects on different hosts in a way in which they can interact with each other
and use the
capabilities of the network to accomplish their tasks.

The first proposition was Inter
-
process Communication (IPC). This mechanism allowed
processes to pass messages to each other. It handled resource contention, distribution of shared
memory, etc. Exampl
es of this were files, pipes, sockets, and semaphores. IPC mechanisms
operate at bit and byte level. Implementing complex interactions on top of such mechanisms is
very tough. Remote procedure calls were implemented next. The caller calls a local stub that

marshals parameters and sends them to the remote end. The remote stub receives these
parameters and unmarshals them.

To automate the creation of stubs, the Distributed Computing Environment (DCE) introduced the
Interface Definition Language (IDL). They al
so introduced the concept of UUIDs, which are
universally unique names.

An interface is a collection of named operations, each with a defined signature and return type.
All interfaces are specified using IDL. Interfaces are named differently according to d
ifferent
standards. COM uses GUIDs. CORBA uses a globally unique repository IDs.

The purpose of this document is to analyze the different architectures and to present an unbiased
view on the best features of each.

The various architectures we will discuss

are CORBA, COM/DCOM, JAVA/RMI and
XML/Aglet.


CORBA


The original implementation of CORBA was to solve the problem of different distributed object
oriented systems implemented in different languages interact. CORBA was designed to solve the
following prob
lems:

1.

Code generated by two compilers on the same platform was incompatible with each
other.

2.

Differing object models from language to language.

3.

Platforms communicated using low level sockets or binary RPCs.


The goal behind CORBA is to enable “open” inter
connection of a wide variety of languages,
implementations and platforms. There is a disadvantage that CORBA compliant products cannot
interoperate on a binary level efficiently. They must use expensive high
-
level protocols. Hence,
they use a standardized
protocol called IIOP (internet inter
-
operability protocol). Any ORB that
claims interoperability compliance must support IIOP.



Architecture of CORBA


CORBA has three Parts:


2

1.

A set of invocation interfaces

2.

The Object Request Broker

3.

A set of individual obje
ct adapters


Invocation interfaces enable various degrees of late binding. They also serialize the arguments
such that the ORB core can locate the receiver object and the invoked method and transport the
arguments. For invocation interfaces and object adap
ters to work two requirements must be met.

a.

All object interfaces need to be described in a common language

b.

All languages used must have bindings to the common language.


The first condition enables construction of generic marshaling and unmarshaling mechan
isms.
The second allows calls from or to a particular language to be related to the common language.
This common language is called the OMG IDL.

There was still one problem
-

the communicating ends may be on different machines and may be
implemented in di
fferent languages. But they still need to share many conventions to
interoperate. Hence the Object Management Architecture adds three new areas of
standardization:

1.

A set of common object service specifications (CORBA Services)

2.

A set of common facility spec
ifications (CORBA facilities)

3.

A set of application object specifications.

Object services support all CORBA
-
based programs in a way that is independent of specific
domains or application models. They concentrate on the fundamental building blocks of any
di
stributed solution for example event propagations, transactions or licensing.


CORBA Services


There are currently 16 services specified. Important services are those that support large
-
scale
operations. This is the first category:


Naming service


Objects

have a unique id internally. The service allows arbitrary names to be associated with an
object. Names are unique.


Object security service


A strong security service is very important for distributed systems spanning more than a single
trusted organizati
on domain. Since the ORBs do not support this a common trend is to rely on
SSL i.e. Transport security mechanisms.


Object Trader Service

This allows providers to announce their services by registering offers. Clients can search for
services based on parts

of descriptions or keywords. The trader returns a list of offers that match
the query.


Object Transaction Service



3

OTS implementation must support flat and nested transactions. It is possible to integrate a non
-
CORBA transaction that complies with the X/
Open distributed transaction
-
processing standard.
Integration with transactions spanning multiple and heterogeneous ORBs is also possible. The
OTS uses transaction begin, commit and rollback.


Change management service


This service is to manage version tr
acking and manage compatibility in an evolving system.


Concurrency Service


This service supports acquisition and release of locks on resources. A lock can be a read, write or
shared or upgrade. Each protected resource holds a lockset from which locks are

acquired.


Event notification service


This service allows event objects that can be sent from event suppliers to event consumers to be
defined.


Externalization Service


This service supports mapping of an object web into a stream and back. The objects n
eed to
implement a “streamable” interface.


Licensing Service


This service supports a variety of licensing models. This is to allow licensing of objects to
restrict their use to authorized users only.


Lifecycle service


This service supports creation, d
eletion and various other operations definable on objects and
groups of objects.



Object collections service


This service provides collections of various abstract topologies.


Object Query Service


This service helps to locate objects by attributes.


Per
sistent Object Service, Properties Service, Relationship Service and Time service

are the
other services offered by the CORBA.

As we can see from the above services, CORBA offers a lot of important interfaces to the
designers of the distributed system. All

that the designer must ensure is that his systems

4

conforms to the X/Open distributed systems standard. This is important so that the system is
interoperable with other systems implementing the distributed interfaces using CORBA. Various
implementations of

CORBA and compliant services include Orbix, Visibroker and System
Object Model (SOM).


COM/DCOM


COM is a binary standard. It does not specify what a component or an object is. It doesn’t
require the use of objects to implement components. COM only define
s an interface. An
interface is represented as a pointer to an interface node.

A COM component is free to contain implementations for any number of interfaces. The entire
implementation can be a single class. A component can contain many classes that are u
sed to
instantiate objects. Then objects can collectively provide the implementation of interfaces
provided by the component. A COM object can be implemented using a single class using
multiple inheritance.

To enable every object to learn about the other i
nterfaces, every COM object has a common first
method called “
QueryInterface
”. There are two further methods shared by all interfaces.

QueryInterface
” takes the name of an interface, checks whether the current COM object
supports the named interface. And

if so, returns the corresponding interface reference pointer.
Interfaces are named using IID (interface identifiers). An IID is a GUID: a 128
-
bit number
guaranteed to be globally unique. There is another interface called “
IUnknown
” which
identifies a COM
object in the most abstract manner. It is the only interface guaranteed to be
present. It supports three methods for any COM interface. The first method is the

QueryInterface
” method. The other two are called “
AddRef
” and “
Release
”. These
control an objec
t’s lifetime.


Every COM object performs reference counting. It is a form of cooperative garbage collection.
As long as the components play by the rules, that is, they act according to the protocol and
cooperate, memory is safely deallocated. Reference cou
nting however, cannot deal with cyclic
references. Since cyclic structures are very common, COM defines a set of rules that govern the
use of AddRef and Release in the presence of cycles. But these rules are complex and subject to
errors. Also, they differ

from situation to situation. The basic idea is that at least one of the
objects in the cycle has a method that breaks the cycle, making objects in the cycle collectible.





COM Object Reuse


COM does not support any form of implementation inheritance. Bu
t a COM component may
consist of objects that internally use inheritance. COM supports two forms of object composition
to enable reuse: containment and aggregation.


Containment is a simple object composition technique: one object holds an exclusive refere
nce
to another. Thus, the outer object contains the inner object. If requests to the outer object need to
be handled by the inner object, they are simply forwarded to the inner object. Containment is

5

completely transparent to the clients of an outer object
. If the hierarchy is too large, that is there
are too many nested objects, the performance issues can arise and cause problems.


Aggregation is used to solve this problem. Instead of forwarding requests, an inner objects’
interface reference could be hand
ed out directly to the inner object saving the cost of forwarding.
With containment, the inner object is unaware of being contained; but with aggregation the inner
object needs to collaborate. A COM object has the choice of whether or not to support
aggreg
ation. The collaborative effort is required because all COM interfaces support
QueryInterface. If the inner objects’ interface is exposed to clients of the outer object, then the
QueryInterface of that inner objects’ interface must still cover the interfac
es supported by the
outer object. Aggregation can go any levels deep. Inner objects at whatever level, always refer to
the IUnknown interface of the outermost object. In this way, the outer object can still query for
an inner objects’ interfaces without be
ing referred to its own IUnknown. Aggregation is not so
important in COM because of its complexity and because it is only meaningful for deeply nested
constructions.


Interfaces and Polymorphism


COM interfaces can be derived from other COM interfaces usi
ng interface inheritance. The
nature of polymorphism in COM is the support of its sets of interfaces by COM objects. The type
of the COM object is the set of interface identifiers of the interfaces it supports. A subtype is a
superset of interfaces. One wa
y to test whether a COM object satisfies all requirements is to call
QueryInterface once for each required interface.


Categories


It is very inefficient to instantiate a COM object and issuing a large number of QueryInterface
requests just to verify that
all the requested interfaces are implemented. To support the efficient
handling of sets of interfaces COM supports categories. A category has its own unique identifier,
which is also globally unique. A COM object can be a member of any number of categories

and
the categories among them are totally unrelated. COM allows a component to return an

E_NOTIMPL
’ error code for any of the methods of an interface. A client has to be prepared for
a provider despite its announced support for an interface, to choose no
t to implement one or
more methods. A category specifies not only which interfaces must at least be supported, but
also which methods in these interfaces must at least be implemented. A category can specify not
only that an object provide the universal dat
a transfer interfaces but also that it knows about the
specific data formats or media. Categories also have problems as to who maintains the list of
categories. If these are produced in large numbers they become useless. Categories make sense
only if the p
rovider and a client agree in advance.


Interfaces and Versioning


A COM interface and its specification must not be changed in any way once it has been
published. This addresses both the syntactic and semantic base class problem by avoidance. That
means,

an IID in COM serves also to identify the version of an interface. As interfaces are
always requested by IID, all participants in a system agree on the version of an interface. A

6

component may choose to implement several versions of an interface but these

are handled like
any other set of different interfaces. Using this, a COM based system can concurrently support
the old and the new while allowing for a gradual migration.


COM Object Creation and the COM library


As long as COM components are self
-
suffi
cient and follow the rules, no further runtime support
is needed. But some extra information is required for an executing program to request a new
COM object. Class should request the service. To identify classes of COM objects, COM defines
class identifie
rs. A CLSID is also a globally unique identifier. COM defines a procedural library
interface to request new object instances based on their CLSID. This interface is static and
procedural so bootstrapping problems are avoided. Programs can ask for objects w
ithout having
to know about an object that knows how to create objects. When creating a COM object that
instantiates a COM class, COM needs to map the given CLSID to an actual component that
contains the requested class. COM supports a system registry for
this purpose (similar to the
CORBA repository). The registry specifies which servers are available and which classes they
support. Servers can be of three types:
inter
-
process

servers support objects that live in the
clients’ process.
Local servers
support

objects on the same machine but in a separate process.
Remote servers
support objects on a different machine. The method used is
CoCreateInstance
, which consults its registry to locate the server and, unless already
active, loads and starts it. For an in
-
process server, involves loading and linking a DLL. For a
local server, a separate executable is loaded. For a remote machine, the service control manager
on the remote machine is contacted to load and start the required server on that machine. A COM
serve
r has a defined structure. It contains one or more classes that it implements. For each class,
it also implements a factory object. A factory is an object that supports interface
IClassFactory
. COM needs to use factories because COM objects need not be a s
ingle
object nature and their creation needs to be specified by the component and not be a system
service. When it starts up, a self
-
registering server creates a factory object for each of its classes
and registers it with COM.
CoCreateInstance

uses the fa
ctory objects to create instances.
CoGetClassObject

allows the client to ask for direct access to the factory. This is useful in
cases where many new objects are required. COM also allows one class to emulate another.
Emulation configurations are kept in t
he system registry.


DCOM


Distributed COM expands the concepts and services of COM. DCOM builds on the client side
proxy objects and the server side stub objects already present in COM.


Meta Information and Automation


COM does not require the use of a
specific Interface Definition Language, as it is a binary
standard. But to use the MIDL compiler, it is necessary to use COM IDL. COM IDL and OMG
IDL (for CORBA) are two different languages. Once interfaces and classes have been defined
using COM IDL, and
the MIDL compiler is used to create stubs and proxies, but also to create
type libraries. A type library is used by COM to provide runtime information to all interfaces and
classes described in the type library.


7


Uniform Data Transfer


This allows for the
uniform implementation of all sorts of data transfer mechanisms. Examples
are drag and drop, clipboards, etc.


Dispatch Interfaces and Dual Interfaces


A dispatch interface combines all the methods of a regular interface into a single method.

These interf
aces have one principal advantage: it is very easy to implement services that
generically forward or broadcast
dispinterface

calls. The most obvious disadvantage is
performance penalty.


Outgoing interfaces and connectable objects


An outgoing interface is

an interface that a COM object would use if it were connected to an
object that provides this interface. To become a connectable object a COM object has to declare
its outgoing interfaces. Connectable objects provide a uniform way to implement change
prop
agation.


XML/AGLET


Aglet Technology: an overview

With mobile agent technology, a developer is not bound by more traditional distributed
computing models, for example, two
-
tier client
-
server models, three
-
tier middleware
-
oriented
models, and so on. The s
oftware agent framework facilitates flexible code distribution that is,
factoring functionality and communications using the most appropriate strategies for the task at
hand. The AGLET framework provides an event model that supports mobility
-
oriented and
m
obility
-
triggered operations. Aglets can be dispatched to and retracted from remote aglet
contexts; and, upon arrival at a remote host, aglets can perform any Java operation, assuming that
security privileges have been granted. Because an aglet is a Java c
lass, it is executable in any
aglet environment operating within any Java environment that allows its form of network
communication (typically, using the agent transfer protocol, ATP).

Aglets themselves are often dispatched from host to host. As mentioned,

the AGLET SDK uses a
URL
-
based communication protocol, ATP. When a program dispatches an aglet to a remote site,
the destination is specified as a URL. The Java runtime software handles the low
-
level data
transport (an aglet instance) to the specified hos
t and port. Upon arrival, the aglet
-
aware program
at the specified port automatically parses and interprets the data stream using the registered ATP
content handler.

There are times when two application components need to communicate, for example,
exchangi
ng a message. If these two components are implemented as aglets, they can use the
AGLET SDK’s built
-
in messaging facility, which supports synchronous and asynchronous
communication. If these two components are not aglets, they can instantiate aglets that p
erform
the communication for them. Application partitioning can be based on static versus dynamic
issues. Static, stay
-
put functionality is perhaps best implemented as one or more Java classes.

8

Operations that need to be performed systematically at multipl
e sites are better implemented as
aglets.


XML as middleware

A middleware application is a server program. Its main function is to receive requests from
clients and respond appropriately. The server middleware requests information from yet another
server
to satisfy its clients' requests.

There are two performance characteristics that every server program must have:

1.

It must survive errors:

If something goes wrong in processing a request, the server can't
shut down. It must continue running so as to servic
e the next request. An example would
be transaction rollback.

2.

It must return to a stable state after each request is completed:

Whether or not the
request was serviced successfully, the server should return to a steady state. Fault
tolerance is essential.

The basic anatomy of a server is simple:



The startup routine establishes the service and any resources it needs.



The request service loop receives requests and responds to them.



The shutdown routine cleans up any open resources and shuts down the server
.


XML Databases


We can build components that can serve as middleware for transferring data between XML
documents and relational databases. The component views the XML document as a tree of data
-
specific objects in which element types are generally viewe
d as classes and attributes and
PCDATA as properties of those classes. It then uses an object
-
relational mapping to map these
objects to the database. An XML
-
based mapping language is used to define the view and map it
to the database.

Data versus Document
s


The most important factor in choosing a database is whether we are using the database to store
data

or
documents
. If we want to store data, we will need a database that is tuned for data
storage, such as RDBMS or object
-
oriented database, as well as mid
dleware to transfer data
between the database and XML documents. But if we want to store documents, we will need a
content management system, which is designed specifically to store documents.

Although it is possible to store documents in a relational or o
bject
-
oriented database ourselves,
we would be duplicating the work of a content management system. Similarly, although a
content management system is usually built on top of an object
-
oriented or hierarchical database,
trying to use it as a database will
probably prove to be frustrating.

Whether we need to store data or documents can be answered by simply looking at the XML
documents. The reason for this is that XML documents fall into two rough categories:
data
-
centric

and
document
-
centric
.


9


Data
-
Centric
Documents


Data
-
centric documents are characterized by fairly regular structure, fine
-
grained data (that is,
the smallest independent unit of data is at the level of a PCDATA
-
only element or an attribute),
and little or no mixed content. The order in which

sibling elements and PCDATA occurs is often
not significant. Some examples are XML documents containing sales orders, flight schedules,
restaurant menus, and so on. Data
-
centric documents are usually designed for machine
consumption and the fact that XML
is involved may be superfluous
--

it is often simply the data
transport.


Document
-
Centric Documents


Document
-
centric documents are characterized by irregular structure, larger grained data (that is,
the smallest independent unit of data might be at the l
evel of an element with mixed content or
the entire document itself), and lots of mixed content. The order in which sibling elements and
PCDATA occurs is almost always significant. Some examples are books, email, advertisements,
and almost any XHTML docume
nt. Document
-
centric documents are generally designed for
human consumption.


Comparison with Java as Middleware


After seeing the above approaches to implementing middleware, let me now focus on my topic
i.e. Java (RMI) as middleware. I will be discussing

the features offered by Java and comparing
them to COM, CORBA and XML/Aglets.


XML limitations



No support for transactions, security, error handling, session management, inheritance,
object identity and state, plus text is inefficient compared to machine
-
readable packets



Method calls are more useful than tagged text



Application cannot understand the semantics



Everything is a string in XML (DTD is limited)



Lose object model in forced tree hierarchy

XML Advantages Versus CORBA




XML can handle very large
data files as it need not build an object in memory (SAX)

o

CORBA approach is piece at a time as necessary



XML Schema versioning

o

CORBA has no versioning of IDL



XML can easily “serialize” data

o

Output XML file as persistent storage


10



XML using HTTP overcom
es firewall problems


Solution



Simple Object Access Protocol (SOAP)



Protocol to exchange XML data between applications



Greater compatibility of Windows 2000 and COM with other systems

o

CORBA
-

COM bridge


Uses of XML in CORBA systems



Configuration (CORB
A Components)



Portable document format



Design metadata (XMI)



Some in
-
system application data


We come across the first distinction when we compare Java as a language to C++. It has been
shown that in many ways,
Java is a better choice

than C++ to implem
ent COM components.
Java has also entered into the field of Object Linking and Embedding (OLE) in addition to COM.


We have discussed about Interfaces and versioning under COM. Here lies the advantage of
COM. Versioning would be difficult to implement in s
ystems in which the multiple interfaces
implemented by a single object are merged into the namespace of a single class. This is
the
problem

with approaches to binary compatibility that are based on conventional object models
such as Java.


Java has a
very
strong plus point

as far as security is concerned. The compiler itself checks the
applet code for safety. This means that if an applets code passes through the compiler, it cannot
be considered as a security threat. Authentication techniques can be used to

make sure that a
received applet has not been tampered with and indeed comes from the announced vendor. A
major
disadvantage

is that no one will trust the large number of small developers providing the
web with applets. Hence a combination of the two appr
oaches is now supported by Java i.e.
signed applets. If a downloaded applet is signed and authenticated to come from a trusted source,
it can be given more privileges than an applet that does not pass this test.


The other major
advantage

of Java is the J
ava Virtual Machine. This is the heart of the so
-
called
platform independence that Java boasts about. The JVM compiles the program into bytecode that
is understood by a JVM. Different JVMs on different platforms will thus interpret the bytecode
the same wa
y.


Java is a pure object
-
oriented language. All java classes and interfaces belong to packages.
Packages introduce a level of encapsulation on top of that introduced by classes. Outer packages

11

merely serve to manage namespaces. This is in direct
contrast
to COM where there can be
nesting of objects and the inner objects can implement the methods of interfaces of outer objects.


Java separates interfaces and classes. This separation permits single implementation inheritance
combined with multiple interface
inheritance. Thus, there
cannot be any conflicts

except name
clashes in a class that implements multiple interfaces. Java does not offer any complete solution
to the name conflict problem. If two interfaces introduce methods of the same name and
signature
but of different return type, then no class can simultaneously implement both
interfaces.


Java Components


Java Beans


Although applets can be arranged to appear together on a web page, there is nothing that allows
these to interact. Any interaction has

to be performed at the server end. An applet is a degenerate
component because it cannot come with all the resources it needs to execute, not even all the
classes. The beans model highlights events, properties, introspection, customization, and
persistenc
e.



Events

Event based communication has multicast semantics. However, it is possible to flag an event
source as requiring unicast semantics.

Properties

A bean can define a number of properties of arbitrary types. It is a discrete attribute that can
affec
t a bean’s instance’s appearance or behavior.

Introspection

Events and properties are supported by a combination of new standard interfaces and classes.


The disadvantage of applets is that the browser has to repeatedly request the server for applet
resou
rces such as classes. Beans use JAR files, which are zipped archives. Everything that a bean
needs is contained in a JAR. The Bean model also supports

1.

Delegation
-
based event model

2.

Data transfer and clipboard support

3.

Lightweight user interface framework

4.

Pri
nting


Distributed computing


Java supports object serialization into byte streams. It defines interfaces and methods that allow
the object to be written to a web stream. The object serialization service and the Remote Method
Invocation Service (RMI) suppo
rt distributed computing. A distributed object is handled via
references of interface type. A remote operation can always fail as a result of network or remote
hardware problems. All methods of a remote interface are required to define exceptions that
hand
le this situation. Also, fully distributed garbage collection is supported.
Distributed
garbage collection is the most outstanding feature of Java RMI
as compared with any other
approach.


12


There are a number of drawbacks in the model as well.

1.

Java RMI int
erfaces with the idea of object identity in Java.

Java RMI affects object identity as a result of its model of implementation of remote
references. If a remote reference is passed around, proxy objects are created on remote
sites. Thus, a reference to a r
emote interface, once passed in a remote method invocation,
is not a reference to the remote object but a local proxy of that object.

2.

Java RMI interfaces with the Java locking systems semantics, which prevents self
-
inflicted deadlocks.

Self
-
inflicted deadl
ocks are caused by locking systems that do not allow a thread to re
-
enter a locked area. In Java RMI, the idea of a thread identity does not span multiple
machines. If a remote invocation performs a nested remote invocation back to the original
requester,
then a distributed deadlock can occur.


Java Native Interface (JNI) specifies the native calling conventions when interfacing to native
code outside the scope of the JVM. The actual layout is not exposed to native code. All access is
through JNI interface
pointers. These are similar to that of COM. But these are not automatically
compatible with COM despite the closeness. A JNI interface pointer is used to refer to a thread
specific context and does not correspond to an individual Java object. It also does
not include
standard COM functions.


Conclusions


All approaches rely on late binding mechanisms, encapsulation and dynamic polymorphism. All
approaches also support interface inheritance. COM has a binary standard at its core. The JNI is
based on COM but
is quite java specific. CORBA does not define binary standards. But CORBA
is strong in standardizing language bindings that ensure source code compatibility across ORB
implementations. For java, it is alright as long as no other languages are used. COM doe
s not
have any concept of source
-
level standards. CORBA has a full set of services most of which lack
commercial implementations. COM has been supplemented by a number of key services. Java
services are neither standardized nor available. XML and Aglets ar
e an emerging standard but
there are quite some issues that need to be resolved in order to successfully incorporate these
technologies into mainstream middleware.


References


0.

References on the CS 551 Class website

http://www.cstp.umkc.edu/~yugi/class/CS551/cs551.html


1. XML Journal

http://www.sys
-
con.com/xml/archives/0104/Baker/index_b.html


2. XML and Databa
ses

http://www.rpbourret.com/xml/XMLAndDatabases.htm


3. Component Software


beyond object
-
oriented programming


13


-
Clemens Szyperski


4. XML as middleware

http://industry.ebi.ac.uk/~senger/ws
-
corba/home/talks/XML
-
CORBA/tsld013.htm


5. XML and DBMS

http://www.rpbourret.com/xmldbms/


6. XML as middlewar
e between CORBA and COM

http://www.oasis
-
open.org/cover/tigueWebBroker.html


7. Integrating Java, XML, and middleware

http://technetcast.ddj.com/tnc_program.html?program_id=58


8. Slide show

http://webware.princeton.edu/howard/slides/xml/sld018.htm