A Comparison Framework for Middleware Infrastructures
Apostolos Zarras, University of Ioannina, Greece
|
 |
REFEREED
ARTICLE
PDF Version |
Abstract
Middleware is a software layer standing between the operating system
and the application, enabling the transparent integration of distributed
objects.
In this paper, we propose a framework that facilitates the comparison of middleware
infrastructures. Our approach serves for identifying similarities and differences
between middleware infrastructures and revealing their advantages and disadvantages
when facing the question of choosing one that satisfies the application’s
requirements. Based on the proposed framework, we compare CORBA with J2EE and
COM+, three of the most widely used infrastructures in both industry and academia.
1 INTRODUCTION
Middleware is a current trend in the development of open
distributed systems; it stands between the operating system and the
application
and enables the transparent integration of distributed objects [Bernstein96].
Middleware consists of reusable functionality that offers solutions
to frequently encountered problems like heterogeneity, interoperability,
security, dependability, etc. This functionality is offered either
by the core of a middleware infrastructure, or by complementary services.
The former mediates the interaction between distributed objects, while
the latter deal with issues like fault tolerance, transactions, naming,
trading, security, etc.
In the early 90s, there have been efforts to
come up with standards describing the semantics and the structure of
middleware infrastructures,
capable of supporting a wide range of applications. The CORBA (Common
Object Request Broker Architecture) specification [CORBAv3.0.2] is
among the most successful results of those efforts. Except for infrastructures
that comply with the CORBA standard (e.g., [Henning et al.98, Lo et
al.98, ORBIX, Schmidt et al.98, Puder et al.00]), there exist others,
which are also quite famous and widely used in both industry and academia.
Among the most popular, we find J2EE (Java 2 Enterprise Edition) [J2EEv1.4]
and COM+ [COM+v1.5].
Given this wide variety of solutions, what is
still missing, from a software engineering point of view, is a methodology
that facilitates
selecting the one that better tackles the particular requirements of
a distributed application. Recently, the OMG architecture board made
a statement concerning the coordinated use of existing standards towards
Model Driven Architecture development (MDA) [MDA]. The MDA development
process relies on the specification of models of the application’s
architecture. In a first step, the models are infrastructure-independent
(i.e., they abstract away technological details that do not relate
to the fundamental functionality of the application). The application’s
architecture specification may further include a description of technological
requirements, which serve for choosing among different infrastructures
that may satisfy them. The step that follows consists of refining infrastructure-independent
models into infrastructure-specific ones. The MDA development process
completes with turning infrastructure-specific models into code.
Concerning
the issues discussed above, we propose a framework for the systematic
comparison of middleware infrastructures, which facilitates
the first step of the MDA development process. The framework aims at
systematically exploring similarities, differences, revealing advantages
and disadvantages of middleware infrastructures, when facing the question
of choosing one that better satisfies the application’s requirements.
The
remainder of this paper is structured as follows. Section 2 presents
previous work and requirements related to our main objective. Section
3 details the comparison framework. Section 4 presents the framework
in action, comparing CORBA with J2EE and COM+. Finally, Section 5 summarizes
our contribution.
2 BACKGROUND & REQUIREMENTS
Most of previous approaches to the
comparison of middleware infrastructures rely on purely functional
criteria. In [Plasil et al.98], for instance,
the authors compare CORBA, Java RMI and DCOM (a predecessor of COM+)
regarding a number of basic concepts (e.g., request/response, remote
reference, interface, proxy, marshaling, etc.) and patterns (e.g.,
the broker pattern, the proxy pattern, etc.), traditionally used for
the integration of distributed objects. The overall comparison is faithful
from a technical point of view. However, the comparison framework proposed
by the authors does not establish relationships between functional
concepts, patterns and typical requirements imposed by distributed
applications. Hence, given the results from their comparison we cannot
reason about which infrastructures are capable of satisfying the requirements
of a particular application. Moreover, we cannot reason about which
specific concepts and patterns we should use to satisfy those requirements.
In [Roman et al.99] and [Gopalan98] the authors also rely on functional
comparison frameworks. Comparing middleware infrastructures strictly
from a functional point of view can be misleading as it is more than
difficult to check all the features of one infrastructure against corresponding
features of another one. In general, there is no perfect middleware
infrastructure; every one of them has its weak and strong points. Even
if a particular infrastructure has less weak points than another does,
it may not be suitable for the specific application that we implement
because its weak points may be exactly the ones we have to employ to
satisfy the application’s requirements.
In [Emmerich00], the
author follows a requirement-based approach. More specifically, the
author identifies typical requirements of distributed
applications over the middleware and examines whether or not different
types of middleware infrastructures support those requirements. However,
the comparison framework used does not establish the relationship between
the requirements and the specific middleware functional concepts we
should use to satisfy them.
Based on the issues raised above, we propose
a comparison framework which combines both the requirements-based and
the functional-based
approaches. More specifically, our framework consists of a set of key
requirements typically imposed by distributed applications over the
middleware. Satisfying the requirements depends on the particular architectural
style (i.e. the different types of elements that can be used for building
an application on top of the infrastructure and constraints on the
use of those elements) assumed by a middleware infrastructure and the
services the infrastructure provides. In the proposed framework:
- We define a generic architectural style that satisfies
the key requirements; if the particular architectural style of a
middleware infrastructure
conforms to this generic architectural style, the infrastructure
is capable of satisfying the key requirements.
- We identify fundamental services that should be offered
by a middleware infrastructure towards satisfying the key requirements.
3 COMPARISON
FRAMEWORK
Figure 1 gives the overall structure of our comparison framework,
which consists of key requirements imposed over the middleware, a
generic
architectural style for middleware infrastructures and fundamental
middleware services.
Key Requirements over the Middleware
The RM-ODP (Reference Model for
Open Distributed Processing) standard [RMODP] discusses the issue of
typical requirements on the integration
of distributed objects. Moreover, in [Emmerich00] the author further
deals with this issue. Based on these approaches, we consider the following
requirements:
-
Openness: The middleware infrastructure should enable extending
the applications built on top of it in various ways. (e.g., adding,
removing,
upgrading, composing services, etc.).
-
Scalability: The middleware infrastructure should facilitate
the effective operation of the applications at many different scales.
-
Performance: The middleware infrastructure should enable
the efficient and predictable, if needed, execution of the applications
that are
built on top of it.
-
Distribution transparency: is the property that determines
if the application is perceived by users, or developers as a whole
rather than as a collection
of independent constituent elements. The requirement for distribution
transparency is quite generic and it is usually refined into a
number of more specific transparencies including:
- Access transparency: the
infrastructure should enable accessing local and remote application
elements in the same way.
- Location transparency: the infrastructure
should enable accessing the application elements without knowledge
of their physical location.
- Concurrency transparency: the infrastructure
should allow concurrent processing on resources, without interference.
- Failure transparency: the infrastructure should
enable service provisioning despite the occurrence of failures.
- Migration transparency: the infrastructure
should provide means for changing the location of elements
of the application without compromising
the application’s correct operation, i.e. without affecting
the elements that depend on the migrated elements.
- Persistence transparency:
the infrastructure should provide means for concealing the
deactivation and reactivation of elements from other
elements that are using them.
- Transaction transparency: the infrastructure
should provide means for coordinating the execution of atomic
and isolated transactions.
A Generic Architectural Style
In general, every middleware infrastructure
assumes an architectural style that must be followed by applications
using the infrastructure.
Three basic principles must hold for this architectural style to support
the development of open and scalable applications:
- Modularity: The application should consist of a collection
of elements, each one providing services, used by the others. Modularity
enables
the identification of dependencies between the elements that make
up the system. Consequently, it allows determining, which elements
are
affected by the eventual addition, removal or upgrade of services.
-
Encapsulation: For each constituent element, there is a clear separation
between the element’s interface and implementation. The interface
is a well-defined specification of the provided services, the contract
between the element and the entities using it. The implementation is
the realization of the provided services. In general, it is safe to
change the implementation of an element as long as the element’s
interface is preserved. Changing an element’s interface without
compromising the overall application integrity requires that the
rest of the application does not depend on this particular interface,
at
the time of the change.
- Inheritance: An interface specification (resp. implementation)
may be derived from another one. The derived interface (resp. implementation)
provides at least the services of the base interface (resp. implementation).
Inheritance enables the vertical and horizontal composition of services.
Figure 1: The basic concepts of the comparison framework.
The generic architectural style we assume in the comparison framework
respects the aforementioned principles. It further relies on the
architectural style proposed in RM-ODP for open distributed systems.
More specifically, the basic elements that make up an application
are engineering objects, i.e. units of data or computation, which
we integrate transparently using functionality of a middleware infrastructure.
An engineering object can be instantiated multiple times within an
application. Instances have state and collaborate towards the accomplishment
of specific tasks. An engineering object provides one or more interfaces.
Furthermore, an engineering object may require one, or more interfaces.
Interfaces may be of the following kinds [RMODP]:
- Signal interfaces: defining asynchronous stimuli
that can be handled by instances of engineering objects, providing
these interfaces.
- Operation interfaces: defining operations that
can be invoked on instances, providing these interfaces. Invoking
an operation causes a request
message to be sent by the invoker to the invoked instance. Invoking
an operation may further result in a reply sent from the invoked
instance to the invoking instance.
- Stream interfaces: defining operations that can
be invoked on instances, providing these interfaces. The result of
invoking a
stream operation
is the continuous conveyance of information from the invoked instance
to the invoking instance.
Following RM-ODP, we assume that engineering
objects are organized into clusters for the purpose of activation,
deactivation, checkpoint,
recovery, etc. Each cluster is associated with a cluster manager, i.e.
an engineering object that coordinates the aforementioned activities.
Clusters are organized into capsules for the purpose of encapsulation
of processing, storage, and request flow. A capsule is associated with
a capsule manager, i.e. an engineering object that coordinates the
cluster managers of the constituent clusters.
Engineering objects that
belong to different capsules communicate through channels. More specifically,
two or more collaborating objects are
associated with a channel, which provides access transparency, i.e.
it masks differences in data representation and communication mechanisms
enabling the inter-operation of the associated objects. A channel is
a compound element consisting of proxies, skeletons, binders and protocol
objects.
A proxy is an engineering object that bridges the semantic
gap between local (i.e. elements belonging to the same capsule) and
remote elements
(i.e. elements belonging to different capsules). Invoking an operation,
(or sending a signal) on an object involves holding a reference to
that object. If both the invoker and the invoked object reside in the
same address space, the reference is a typical implementation-language
specific pointer (e.g. a C++ pointer). On the other hand, if the invoker
and the invoked object reside in different address spaces, the reference
is a pointer to a representative of the invoked object (i.e. a proxy)
in the invoker’s address space. Upon the invocation, the proxy
constructs and forwards a request to the remote object, through the
rest of the objects that make up the channel. Requests and replies
must be converted into a form that is suitable for transmitting over
the network. Technically, the previous is achieved through serialization
of requests and replies into a byte stream. The serialization procedure
is usually called marshalling. Several conversions may take place during
marshaling, to deal with data representation differences between the
invoker’s and the invoked object’s execution environments
(e.g., little-endian, big-endian).
A binder is an engineering object
that maintains the integrity of a channel (e.g., it monitors communication
failures and round-trip times
and sets appropriate time-outs; it multiplexes connections to multiple
remote objects to optimize resource usage). A protocol object provides
basic communication functionality (e.g., it writes a request to a TCP/IP
socket, it performs retransmissions based on time-outs set by the binders,
etc.). A skeleton is the representative of all objects requiring an
interface provided by a remote object, in the capsule of the remote
object. The skeleton accepts as input requests built by proxies and
uses information that is encapsulated in those requests to perform
local invocations on behavioral features (i.e. operations, signals)
provided by the remote object. The skeleton may further encapsulate
the result of the request into a reply, which is delivered back to
the invoker.
Fundamental Middleware Services
So far, we have seen that openness,
scalability and access transparency of an application depend on the
particular architectural style assumed
by the middleware infrastructure used for building it. Performance,
on the other hand, mainly depends on the realization of the infrastructure’s
communication channels. A basic performance criterion is the communication
overhead introduced by the use of the channels. This overhead is usually
not negligible; it is the penalty for dealing with communication in
distributed applications, executing on heterogeneous execution environments.
Achieving the rest of the requirements, identified at the beginning
of this section, relies on the use of complementary services offered
by the infrastructure. The use of the complementary services should
be transparent to the application, whenever possible. More
specifically, the infrastructure should provide means that relief the
developers
from explicitly using complex functionality of the services within
the code of the application. The ideal is that developers just setup
properties that characterize the objects of the application. Then,
the middleware used for integrating the objects implicitly combines
functionality of corresponding services to impose those properties
(e.g., the developer just sets the replication-style to be active-replication;
based on the style, appropriate functionality is used within channels,
for multicasting requests sent by clients to groups of replicated objects).
The fundamental services offered by an infrastructure can be divided
into three categories: repository, coordination, and security services
[RM-ODP].
Repository services provide functionality that allows managing
information regarding objects, interfaces, locations, etc. This category
includes
trading and naming services. A naming service defines a name
space and provides interfaces through which we associate names with
references
to objects. Client capsules may then use names to obtain the associated
object references. A trading service is a more sophisticated mechanism.
The client capsules do not need to know specific names of server objects,
they just hold a reference to a trader and use it to request for a
required service. The trader maintains a registry that contains references
to objects, providing specific services. A client request to the trader
is specified in terms of a required interface and additional quality
of service properties. The trader looks in the registry for a reference
to an object that can fulfill the client’s requirements and if
there exists one, the trader returns it to the client. Naming and trading
services can be used to provide location transparency. Moreover, we
can use the trading service to satisfy scalability requirements
as it can serve as a mechanism for load balancing.
Coordination services include services that can
be used to achieve concurrency
transparency (e.g. locking). Failure transparency regarding
accidental faults is realized using coordination services for replication,
checkpoint and recovery [Laprie85]. Replication may be employed both
at the level of engineering objects (use of groups of replicated
objects instead of simple objects) and at the level of communication
channels
(use of request retry and redirection mechanisms). Failure transparency concerning
intentional/malicious faults relies on the use of security services
for authentication, access control and encryption [Laprie85].
Migration transparency is achieved using coordination services
that allow copying or moving an object from one location to another,
without
affecting other objects that use it. Persistence transparency
relies on two key issues: (1) references to persistent objects must
remain
valid despite the deactivation and reactivation of those objects,
(2) the state of the objects must persist to their deactivation and
reactivation.
In principle, the creation and maintenance of references is a responsibility
of the infrastructure. On the other hand, persistent state involves
using a complementary checkpoint and recovery service. Transaction
transparency involves using coordination services that realize
atomic commitment protocols (e.g. two-phase commit protocol) and
concurrency
control protocols that guarantee isolation (e.g. two-phase locking).
4
THE COMPARISON FRAMEWORK IN ACTION In this section, we demonstrate
the use of the proposed framework for comparing CORBA with J2EE and
COM+.
Openness
All three platforms that we assess in this paper support the
development of open systems. More specifically, each one of them
relies on a particular architectural style, which is aligned with the
basic
principles
and
concepts of the generic architectural style we detailed in
the previous section.
CORBA forces developers to build applications
that comply with the CORBA object model [CORBAv3.0.2]. According
to that model,
the basic
engineering objects are called CORBA objects. Each CORBA
object provides a single interface; it is a conceptual entity
realized
by an implementation
language-specific entity (e.g. a C++ object, a Java object,
etc.), named servant. In principle, the servant may realize
more than
one CORBA objects. By default, CORBA interfaces are operation
interfaces, as defined in the generic architectural style.
An operation may
return
a reply or not; in the latter case it is called a one-way operation.
In order to realize a signal interface we have to use the
CORBA
Event Service [CORBAServices]. Stream interfaces are not
supported. The
specification of interfaces relies in CORBA IDL (Interface
Definition Language),
a purely declarative language that supports interface inheritance.
Implementation inheritance depends on the implementation
language used for the realization of servants.
CORBA objects
that have common properties regarding activation, deactivation,
etc. can be organized into clusters managed
by a POA element (Portable
Object Adapter). Capsules are called CORBA servers. CORBA
objects that belong to different servers communicate
using channels,
which rely
on the GIOP communication protocol. A more sophisticated
approach for clustering objects that have common properties
consists
of building CORBA components instead of typical CORBA
objects [CORBA-CCM].
Components
extend the semantics of simple objects in that they can
register to
containers, i.e. objects that implicitly manage object
activation and deactivation, transactions, security and persistence.
To achieve the
previous containers combine functionality of standard
CORBA services like PSS (Persistent State Service) and OTS (the
Object Transaction
Service) [CORBAServices]. Technically, each container
is associated with a properly configured POA. CORBA components
provide more
than one interfaces divided into two categories: (1)
external interfaces
used by other components of the application, and (2)
callback interfaces, used by the container towards managing object
activation and deactivation,
transactions, security and persistence. 
Table 1: CORBA, J2EE and COM+ regarding
openness.
J2EE imposes the use of
the Java object model [J2EEv1.4] for developing J2EE applications. According
to that model, an application comprises a collection
of Java objects, each one providing a number of Java interfaces. Java interfaces
are operation interfaces. To realize signal interfaces we have to use the
Java Message Service (JMS) [J2EEv1.4]. As with the
case of CORBA, stream interfaces
are not supported. Interfaces are specified using Java language-specific
constructs (instead of employing a separate IDL language).
Java allows both interface
and implementation inheritance. ActivationGroup objects can be used to cluster
objects with common properties regarding activation and deactivation. A capsule
in J2EE is called a server. Objects that belong to different servers communicate
through channels that rely on the Java RMI communication protocol. Alike
CORBA, J2EE further provides a more sophisticated approach
for clustering objects,
which involves building Enterprise Java Beans (EJBs) instead of typical Java
objects. EJBs extend the semantics of simple Java objects in that they can
register to EJB containers, i.e. objects that systematically manage the activation/deactivation,
transactional processing, persistence, etc. of the registered objects.
In
COM+, the basic engineering objects are called COM+
objects and provide one, or more interfaces [COM+v1.5].
COM+ objects are conceptual entities
realized by one or more implementation objects written in a conventional
programming
language like C++, Java, etc. COM+ interfaces are in principle operation
interfaces. Signal interfaces can be realized using the COM+ event service
[COM+Events].
As with the previous two infrastructures, stream interfaces are not supported.
Interfaces are specified using Microsoft IDL (MIDL), a purely declarative
language that supports inheritance. Capsules in COM+ are named processes.
COM+ objects
are organized into clusters, named contexts, regarding common properties,
having to do with the objects’ activation, deactivation, transactions,
security etc. COM+ objects interact through channels that rely on DCE RPC
[DCE-RPC].Table
1 summarizes the comparison of the three infrastructures regarding openness.
Scalability
As we detailed previously, the architectural
styles assumed by all three infrastructures we examine
here
support the development of scalable applications.
CORBA further
provides a trading service that can be used for load balancing [CORBAServices].The
CORBA Trader provides a registry of publicly known services. Clients may
query the trader for a particular service, providing the specification of
the service,
in terms of a CORBA IDL interface. Client queries may further include quality
of service requirements that must be satisfied by the service provider. The
trader answers the clients’ queries with references to objects that
can successfully offer the required service, while fulfilling the clients’ quality
requirements.
COM+ supports static load balancing [COM+v1.5]. More
specifically, a COM+ system can be configured to assign
certain clients to certain servers
that
execute
the same logic. However, the mapping between clients and servers does not
change dynamically to reflect changes in the servers’ workload. This
technique is an easy way for dealing with predictable loads. A more sophisticated
solution
involves using referral COM+ objects that assign clients to component objects
dynamically. J2EE also does not provide a standard trading service [Roman
et al.99]. However, it provides means for implementing proprietary ones.
Table
2 summarizes the comparison of CORBA, J2EE and COM+ regarding scalability.
Table 2: CORBA, J2EE and COM+ regarding
scalability.
Performance
Regarding efficiency, several performance
evaluation efforts [CORBABench, EJBBench, DCOM] show
that
the communication overhead is similar in orders
of magnitude
for COM+, J2EE and various CORBA compliant middleware infrastructures
(e.g. OmniORB [Lo et al.98], ORBacus [Henning et al.98], ORBIX
[ORBIX], TAO [Schmidt
et al.98], MICO [Puder et al.00]). In CORBA, we should expect
spending from 0.6 to 3.5 ms to send data of a basic
type (e.g. long, char,
float, double,
short etc.) from a client to a server object1.
J2EE, also seems to be expensive; we should count spending from
4 to
5 ms1. Finally, in COM+
2.5 to 3.5 ms
are needed1. The communication overhead grows for more complex
data types like
arrays, sequences, etc.
CORBA is the only one among the infrastructures
we consider here that facilitates the predictable execution
of applications. In
particular, the Real-Time
CORBA [CORBA-RT] is an extension of the standard CORBA specification,
enabling clients of an application to create priority-banded
connections to server
objects.
Clients can send prioritized requests through those connections.
Servers
may specify priorities on a per object basis, (e.g., requests
targeted to
a particular
object may have higher priorities compared to requests targeted
to other objects encapsulated by the same server). Request
processing takes place
according
to either the client, or the server priority model, depending
on specific properties set on the server-side. Clients may
further setup
timeouts
on requests and
servers can precise on the number of threads used for request
processing.
Clients and servers can also customize certain properties of
the underlying TCP/IP
communication protocol (e.g. the sizes of the communication
buffers used). Real-Time CORBA infrastructures come
along with scheduling
services, facilitating the execution of activities (i.e. sets
of requests) according
to various
scheduling policies (e.g., EDF, rate-monotonic, etc. [Schmidt
et al.98]). Table 3 summarizes
the comparison of CORBA, J2EE and COM+ considering efficiency
and predictability. 
Table 3: CORBA, J2EE and COM+ regarding performance.
Access
Transparency
CORBA, J2EE and COM+ channels provide access
transparency. More specifically, in CORBA, proxies and
skeletons are
called stubs and skeletons, respectively.
Requests are marshaled into byte streams according to the standard CDR
format (Common Data Representation), which deals with
byte ordering differences
between the machines that host the client and the server
object. CDR further deals
with the alignment of primitive CORBA data types within messages. Stubs
and skeletons are automatically generated using a CORBA
IDL compiler.
CORBA binders manage connections according
to the GIOP protocol. Connections in GIOP v1.0, v1.1 are
asymmetric;
the client can issue requests through
the connection, while the server can receive requests and send replies
but can
not issue requests. This restriction is relaxed in GIOP v1.2 and v1.3,
where connections are bidirectional. Connection shutdown can be initiated
either
by a server-side binder, or by a client-side binder. Server-side binders
can not initiate connection closure if there exist client requests
that are pending.
Client-side binders are responsible for multiplexing connections to
objects encapsulated by the same server to optimize resource
usage. If client-side
binders do not support the previous feature, a new connection is created
for every server object used by the client. CORBA protocol objects
rely on TCP/IP.
Other protocol objects may also be used within CORBA channels, as long
as they conform to certain transport protocol assumptions specified
in the CORBA
standard. 
Table
4: CORBA, J2EE and COM+ regarding access transparency.
J2EE channels rely
either on Java RMI [JavaRMI] or on GIOP. According to RMI, at the
time when a client obtains a reference, a new proxy is created.
Consequently,
multiple proxies in the address space of the client may represent the same
remote object. Marshaling is based on the Java Serialization Protocol [JavaRMI].
Proxies and skeletons are automatically generated, using the rmic compiler.
RMI binders manage the opening and closure of bidirectional connections.
Moreover, they are responsible for multiplexing connections according to
the Java Multiplexing
Protocol [JavaRMI]. RMI protocol objects are based on TCP/IP. Other kinds
of protocol objects are also supported.
COM+ channels are based on DCE RPC
[DCE-RPC]. When a client process obtains a reference to an interface for
the first time, a proxy is created. The proxy
is reference-counted to avoid creating multiple proxies, representing the
same remote object. Request and reply marshalling relies on the DCE NDR
(Normal Data Representation) format. Stubs and skeletons are automatically
generated
using the MIDL compiler. Binders manage the opening, closure and multiplexing
of bidirectional connections. Finally, the protocol objects rely on TCP/IP.
Other kinds of protocol objects may also be included in COM+ channels.
Table 4 summarizes the comparison of CORBA, J2EE and COM+ concerning
access transparency.
Location Transparency
CORBA provides both naming and trading services
that can be used to achieve location transparency [CORBAServices].
J2EE provides
two different naming
facilities: a daemon process, called RMI-Registry that realizes a flat
namespace and the
Java Naming and Directory Interface (JNDI), which is similar to the CORBA
Naming service [J2EEv1.4]. The distinctive feature of JNDI over CORBA Naming
is that
the former generates events, upon request, whenever a namespace changes
due to the addition, removal, or update of a name binding. Clients using
JNDI
can then register event listeners to receive such events. J2EE does not
provide, for the time being a trading service.
Table 5 : CORBA, J2EE and COM+ regarding location transparency.
As in the
case of J2EE, COM+ provides naming facilities, but it does not offer
any trading service. More specifically, in COM+ there exist two basic
global
name spaces. The first one contains GUIDs (globally unique identifies),
which are bound to COM+ interfaces, or to classes of COM+ objects. The
second name
space contains names of monikers, i.e. persistent COM+ objects used for
storing the state of other COM+ objects.
Using the naming and trading
services is typically not a complex task; thus, the middleware infrastructures
we assess here do not provide any
means to
further facilitate it. Table 5 summarizes the comparison of CORBA,
J2EE and COM+
concerning location transparency.
Concurrency Transparency
Table 6 : CORBA, J2EE and COM+ regarding concurrency
transparency.
CORBA enables the concurrent execution of requests.
However, the particular request processing models that can be employed
are not
precisely defined
in the standard. Following, we give typical models that may be supported
by CORBA
compliant infrastructures:
- The thread-per-request model: a new thread
is created for every request
delivered to a server.
- The thread-per-client model: a new thread is created for every
new client that requests services from a server.
- The thread-pool model: a fixed number of threads are used for
serving requests (this model should be provided by infrastructures
that comply
with the Real-Time
CORBA specification [CORBA-RT]).
Concurrency control can be achieved
using the CORBA Concurrency Control Service (CCS) - a basic locking
mechanism [CORBAServices]. The use
of CCS is not
transparent to the application; locks should be explicitly acquired
and released by the
application.
In J2EE, multiple requests may be delivered simultaneously
to a Java object. These requests are served in separate threads.
Concurrency
control is based
on standard Java synchronization mechanisms, whose employment can
be hidden under the use of the Java synchronized clause
(if we characterize operations
op1, op2 of a Java class with the synchronized keyword,
J2EE guarantees that upon the concurrent arrival of requests for
op1 and op2, op1
shall
start
after the end of op2, or the inverse).
COM+ allows the concurrent
execution of requests in the following sense. COM+ objects within
a server are organized into apartments,
depending
on the request-processing
model they use. There are two types of apartments: single-threaded,
and multi-threaded. A single-threaded apartment consists of exactly
one thread,
so requests to
COM+ objects that belong to it are served sequentially. A multi-threaded
apartment comprises more than one thread, assigned to requests
targeted to the objects
that belong to the apartment. Concurrency control in multi-threaded
apartments can be based on COM synchronization mechanisms (e.g.,
functionality that
realizes the IBlockingLock interface), whose use, however, is
not transparent to the
application. Table 6 summarizes the comparison of CORBA, J2EE
and COM+ regarding concurrency transparency.
Failure Transparency
CORBA was recently extended to support fault
tolerance. More specifically, the standard specification for Fault
Tolerant
CORBA [CORBAv3.0.2]
defines basic mechanisms and interfaces for replication,
checkpoint and recovery
of CORBA
object groups. From the client perception, the employment
of the fault tolerance mechanisms is transparent since groups
are used
as normal
CORBA objects.
Clients hold a group reference instead of an object reference
and request services
provided by the group. 
Table 7: CORBA, J2EE and COM+ regarding failure transparency.
Depending
on the particular replication style used, the CORBA infrastructure
either forwards a client request to one member (called primary object)
of the
group (passive replication), or multicasts the request to all members, while
guaranteeing totally ordered request delivery (active replication). In active
replication, whenever a member fails, the remaining replicas are used to guarantee
correct service provisioning. In passive replication the state of the primary
is either periodically stored in a log (cold-passive replication),
or loaded into one or more backup replicas (warm-passive replication).
Upon the occurrence of a failure, a backup object becomes the new primary.
CORBA further defines
mechanisms employed at the level of CORBA channels for request retry and redirection.
Fault tolerance support in J2EE and COM+ is limited; channels include mechanisms
for network/hardware fault detection and connection recovery.
Regarding intentional
faults, all three infrastructures provide security services for authorization,
authentication and encryption. The functionality provided
by those services is embedded in the communication channels. Hence, the use
of security services, in all three cases, is transparent to the application.
In CORBA, different kinds of secure channels may be employed, relying on
security protocols like SSL, GSS Kerberos and CSI-EKMA (those protocols
differ mainly
regarding the flexibility they provide in the delegation of identities and
privileges; SSL appears to be the least flexible protocol, since delegation
is not allowed). Security in J2EE and COM+ is based on SSL channels. However,
channels relying on other security protocols (e.g. Kerberos) are also supported
[Roman et al.99].
Table 7 summarizes the comparison of CORBA, J2EE and COM+
regarding failure transparency.
Migration Transparency
In CORBA there are two possible ways of migrating
an object. The primitive way is to invoke an operation on another object
that resides at the target
location and pass a copy of the object that is to be migrated as a parameter.
Then, the original copy can be destroyed. The migrated object must be passed
by value. The previous is possible in CORBA only if the migrated object is
a valuetype (i.e. a special kind of object, whose specification comprises
the definition of both the object’s interface and the object’s
state). CORBA channels can redirect requests issued by clients that hold
references
to the original copy of the migrated object. Consequently, the integrity
of the application is preserved. Passing objects by value is also possible
in
J2EE.
However, this primitive approach to object migration does not deal
with dependencies that may exist between a migrated object and other objects.
Such dependencies
may further impose the migration of the dependent objects. To deal with
these cases, CORBA provides a more sophisticated service called CORBA
LifeCycle
[CORBAServices].
Passing objects as parameters in CORBA and J2EE and using
the CORBA LifeCycle service is not transparent to the application.
Table 8 summarizes the
comparison of CORBA, J2EE and COM+ regarding migration transparency.
Table 8: CORBA, J2EE and COM+ regarding migration transparency.
Persistence
Transparency
In CORBA, references to an object may be either persistent,
or transient depending on the policies of the POA that manages the
lifecycle of the
object. Moreover,
CORBA provides the Persistent State Service (PSS) [CORBAServices], for
logging (resp. restoring) objects’ states to (resp. from) persistent
storage. Checkpoint and recovery of objects’ states is not transparent
in the sense that it is the responsibility of the application to log periodically
the state of its constituent objects. To achieve fully transparent persistence
we have to build persistent CORBA components instead of simple CORBA objects
and register them into CORBA containers. Upon registration, the containers
take over the responsibility of logging and restoring the components’ state.
Table 9: CORBA, J2EE and COM+ regarding persistence
transparency.
In
J2EE, object references can be persistent. More specifically, if
a client tries to contact an object that can be activated, but is currently
not
active, the RMI Registry responsible for the object is contacted instead.
The daemon
shall reactivate the object and provide the client proxy with an updated
object reference. Regarding persistent storage, objects can use JDBC
or SQL/J to access
a database. The use of the previous facilities is not transparent,
unless
we built EJBs, instead of simple Java objects, and register them to
EJB containers that systematically log in database storage the state
of the
registered EJBs.
References to COM+ component objects are not persistent.
The state of component objects can be stored to a database, using
ADO or OLE-DB
interfaces. However,
the use of the aforementioned facilities is not transparent to the
application [Roman et al. 99]. Table 9 summarizes the comparison
of CORBA, J2EE and
COM+ concerning persistence transparency.
Transaction Transparency
CORBA comes along with the Object Transaction
Service (OTS) [CORBAServices], which realizes the well-known 2-phase-commit
protocol. Most implementations
of the OTS specification support the execution of both flat and
nested transactions. The use of OTS alone does not guarantee
isolation. To achieve the previous
we have to combine OTS with CCS. The use of OTS and CCS is not
transparent
to the application. More specifically, application objects that
participate in a transaction must register the resources they
use to a transaction
coordinator. Moreover, before serving transactional requests,
the participating objects
must try to acquire locks on their resources. When the transaction
completes, OTS releases all locks that have been acquired. Hence,
the first phase
of the well-known 2-phase-locking protocol is a responsibility
of the application, while OTS transparently performs the second
phase,
using
CCS functionality.
To achieve fully transparent transactional
processing we have to implement transactional CORBA components and
register them
into
CORBA containers.
Then, the containers handle client invocations appropriately
(e.g., they may implicitly
acquire locks, register resources, etc.). 
Table 10: CORBA, J2EE and COM+ regarding transaction
transparency.
J2EE
provides a service, named JTS (Java Transaction Service)
that is similar to OTS. One significant difference is that
JTS only supports the flat transaction
model. Moreover, container-managed transactions are supported for EJBs.
COM+ provides OLE transactions for the atomic and isolated
execution of invocations
on COM+ objects. Both flat and nested transaction models are supported.
Moreover, COM+ provides MTS (Microsoft Transaction Server),
a container for COM+ transactional
objects. Table 10 summarizes the comparison of CORBA, J2EE and COM+,
regarding transaction transparency.
Overall Assessment
Figure 2: Overall comparison of CORBA, J2EE and COM+,
regarding their standard specifications.
Figure 1 gives an
overall view of the results we obtained from the comparison
of CORBA, J2EE, and COM+. More specifically,
we counted one point-in-favor
of an infrastructure for every ( ) mark we gave in the detailed
comparison (for openness and access transparency we only counted
an overall
point-in-favor for each infrastructure because they all
have common features regarding
those properties). Figure 1(a) gives the points-in-favor per-requirement,
while
Figure 1(b) gives the total number of points-in-favor for each
infrastructure. From
both figures, we can come into conclusion that CORBA, in general,
provides more facilities for satisfying typical requirements
imposed by distributed
applications. To be fair with the other two infrastructures we
have to highlight that this conclusion is based on the comparison
of the standard
CORBA specification
with the specifications of J2EE and COM+. However, not all implementations
of the CORBA standard specification provide all of the CORBA services
and facilities we identified during the detailed comparison.
Based
on the previous remark, we examined a number of available
implementations of CORBA (omniORB, ORBacus, ORBIX, TAO, MICO),
regarding the availability
of the CORBA services and facilities we identified in the detailed
comparison. Then, we calculated the points-in-favor for each
implementation
and compared
them with those for J2EE and COM+. Figure 2 gives the results
from this comparison. With the exception of omniORB, all CORBA
implementations
appear better than
COM+. However, they are all quite close to J2EE.
Figure 3: Overall comparison of available
CORBA implementations, J2EE and COM+.
5 CONCLUSION
The main contribution of this paper is twofold:
(1) it proposes a comparison framework for middleware infrastructures
and (2)
presents a detailed
comparison of three widely used infrastructures in both industry and
academia: CORBA, J2EE and COM+. The comparison framework we propose
constitutes a foundation for further research we perform in the field
of MDA. More specifically, we currently work towards a developer-oriented
environment for MDA development, which relies in the approach proposed
in [Issarny et al.02]. The core element of our environment is a UML-based
representation for the specification of infrastructure independent
models of distributed applications. The comparison framework presented
here serves for specifying the applications’ technological requirements
and selecting a middleware infrastructure that provides functionality,
which can be used for satisfying those requirements. Our environment
further comprises automated procedures for: (1) refining infrastructure
independent models into infrastructure specific ones and (2) generating
code from infrastructure specific models.
Footnotes
1 These are representative
measures taken from extensive experiments performed in the
context of the CORBA comparison project [CORBABench], the EJB
comparison project [EJBBench] and [DCOM]. We consider that
these measures are sufficient to give an idea of the performance
overhead introduced by the infrastructures we examine. An extended
performance evaluation of CORBA, J2EE and COM+ is out of the
context of this paper. REFERENCES
[COM+v1.5] COM+ v1.5. Microsoft Corporation. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgcontexts_1p0z.asp
[COM+Events]
COM+ Event Service. Microsoft Corporation. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgservices_events_5x4j.asp
[CORBAv3.0.2]
Common Object Request Broker Architecture (CORBA/IIOP) v.3.0.2.
OMG Document, formal/2002-12-06 http://www.omg.org/technology/documents/for
mal/corba_iiop.htm
[CORBABench] CORBA Comparison Project Web site. Distributed
systems Group, Charles University. http://nenya.ms.mff.cuni.cz/projects.phtml?p=cbench&q=3
[CORBA-CCM]
CORBA Component Model (CCM). OMG Document formal/2002-06 65.
http://www.omg.org/technology/documents/formal/components.htm
[CORBA-RT]
Real-Time CORBA v1.1. OMG Document, formal/2002-08-02. http://www.omg.org/technology/documents/formal/real-time_CORBA.htm
[CORBAServices] CORBAServices Specification. OMG Document.
http://www.omg.org/technology/documents/corbaservices_spec_catalog.htm
[DCE-RPC]
DCE 1.1: Remote Procedure Call. Open Group, 1997. http://www.opengroup.org/onlinepubs/009629399/toc.htm
[DCOM] DCOM Technical
Overview. Microsoft Corporation. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgservices_events_5x4j.asp
[EJBBench] EJB Benchmarking Web site. Distributed Systems
Group, Charles University, Prague. http://nenya.ms.mff.cuni.cz/projects.phtml?p=ejbc&q=4
[Emmerich00]
W. Emmerich. Software Engineering and Middleware: A Roadmap.
The Future of Software Engineering, ed. A. Finkenstein,
pp.117-129
2000.
[Issarny et al.02] V. Issarny, C. Kloukinas and A. Zarras.
"Systematic Aid for Developing Middleware Architectures". Communications
of the
ACM (CACM), vol. 45, no. 6, pages 53-58, 2002.
[J2EEv1.4] The Java 2
Enterprise Edition (J2EE) Specification v.1.4. Sun Microsystems.
http://java.sun.com/j2ee/
[JavaRMI] Java Remote Method Invocation
(RMI). Sun Microsystems. http://java.sun.com/j2se/1.4.1/docs/guide/rmi/spec/rmiTOC.html
[Henning et al.98] M. Henning and S. Vinosky. Advanced
CORBA Programming with C++. Addison Wesley, 1998.
[Gopalan98] S. R.
Gopalan. A Detailed Comparison of CORBA, DCOM, and Java/RMI.
OMG whitepaper, 1998. http://my.execpc.com/~gopalan/misc/compare.html
[Laprie85]
J-C. Laprie. "Dependable Computing and Fault Tolerance: Concepts
and Terminology". In Proceedings of the 15th International
Symposium on Fault-Tolerant Computing (FTCS-15), pp. 2-11, 1985.
[Lo
et al.98] S. Lo and S. Pope. "The Implementation of a High
Performance ORB over Multiple Network Transports". AT&T
Labs Cambridge, Technical Report 98.5, 1998. http://www.uk.research.att.com/abstracts.html
[MDA]
OMG: Model Driven Architecture. OMG Document ormc/2001-07-01, 2001.
http://www.omg.org/mda.
[ORBIX] ORBIX v.3 Web site. http://www.iona.com/products/orbix3_home.htm
[RMODP] ISO/IEC. Open Distributed Processing Reference Model
(RM-ODP) Part 3: Architecture, 1995.
[Roman et al.99]
E. Roman and R. Oberg. "The Technical Benefits of EJB and
J2EE Technologies over COM+ and Windows
DNA". The MIDDLEWARE
Company,
1999.
http://www.middleware-company.com
[Plasil et al.98] F.
Plasil and M. Stal. "An Architectural View of Distributed
Objects and Components in CORBA, Java RMI and
COM/DCOM". Software Concepts
and Tools, vol. 19 no.1, 1998.
[Puder et al.00] A. Puder and
K. Romer. MICO and Open Source CORBA Implementations. Morgan
Kaufmann Editions, 2000.
[Schmidt et al.98] D. C. Schmidt,
D. L. Levine and S. Mungee. "The Design of the TAO Real-Time
Object Request Bromer".
Computer Communications,
vol. 21 no. 4, pp. 294-324, 1998.
About the author
Apostolos Zarras got his Ph.D. in the year
2000 from the University of Rennes I, France. From 2000 to
2002, he worked as a research engineer at INRIA-Rocquencourt,
France. Currently he is a visiting assistant professor at the
University of Ioannina, Greece. His current research interests
include model driven architecture development, adaptive middleware,
and quality analysis of software systems. He can be reached
at zarras@cs.uoi.gr.
Cite this article as follows: Apostolos Zarras: "A Comparison
Framework for Middleware Infrastructures", in Journal
of Object Technology, vol. 3, no. 5, May-June 2004, pp. 103-123. http://www.jot.fm/issues/issue_2004_05/article2
|
