Introduction:
I view this Midterm #1 as two major parts.
First, the investigation of different types of middleware in terms heterogeneity,
distribution, communication, security, concurrency, performance, scalability, and fault
tolerance.
There are three types of middleware- Transaction-Oriented middleware, MessageOriented middleware and Object-Oriented middleware (OOM is highly influenced by
Remote procedure calls). Their contrast and comparison will undoubtedly go towards
Object-Oriented middleware, as we will discuss below.
The second part is my favorite, which is the comparison of different Object-Oriented
middleware's. There are four major and popular types viz. OMG's (Object Management
Group) CORBA, which is based on the OMA (Object Management Architecture).
I will be going through discussion and critique phase for both the parts and try
concluding some abstract out of it.
Microsoft's DCOM/COM (Distributed Component Model), which is based, and highly
relied on OSF/DCE's (Open Software Foundation's Distributed Computing Environment).
Java/RMI (Remote Method Invocation) which is Object-Oriented language developed by
the Sun Microsystems which uses API (Application Programming Interface) which is
called the RMI. And the fourth and the final is IBM's XML/Aglets (eXtended Mark-up
Language/AGent appLETs). Aglets is though a non-mainstream product unlike the above
architecture specifications. XML-DBMS is middleware for transferring data between
XML documents and relational databases. Aglets use J-AAPI (Java Aglet Application
Programming Interface) for interfacing aglets and its environment. Since, this so-called is
very new, not much work is done so far.
The analytical comparison of these four major types would be very interesting. Though I
have been given Java/RMI as my topic of concentration, I am not very much convinced
with it fully, or with any architecture for that matter. Let's go on with this process of
analyzing and comparing these stuff and may be later in this paper, I can have a mindset
on something.
Discussion (Part I): Middleware is the middle layer between the network operating
system and the components.
1
Fig. 1 Middleware in Distributed Systems
In the figure, it's seen that the middleware sits between the Network Operating Systems
and the components to solve the problem of heterogeneity and distribution. Distributed
system constructed directly on the top of a transport layer is difficult therefore we use
object-oriented middleware to resolve this issue. Middleware simplifies distributed
systems construction by implementing the presentation and session layers of the ISO/OSI
reference model. To go into little more detail, middleware these vary important things
among others. It maps complex parameters passed to service requests into a transmittable
form; resolves heterogeneity; resolves logical component address to Internet domain
names and port address; and synchronize client-server objects.
The available middleware can be divided into three major categories: Transactionoriented, Message-Oriented and Object-Oriented Middleware. Let me go over these in
detail and try comparing/contradicting each other. Lets find out why I feel object-oriented
middleware is better than others.
Transaction-Oriented Middleware: This supports the integration of transaction across
distributed databases. The systems in this category include, IBM's CICS, BEA's Tuxedo
and Transare's Encina. They are used where components are database applications. They
use 2-phase commit protocol to implement distributed transactions. They are capable of
integrating updates in distributed databases and provide the foundations for faulttolerance and load balancing. They use distributed transactions to maintain replicated
databases on different servers. Updates to these databases are synchronized using
distributed transactions. Load balancing is used to direct queries to least-loaded replica.
This system is scalable too as many transactions can processed and many databases can
be networked in this distributed schema.
A transaction follows ACID (Atomicity, Consistency, Isolated, Durability) properties.
This means that the transaction is performed completely or not at all, thus each state are
consistent to one another, it is executed isolation with one another and after completion
they are durable. The combination of consistency and durability means that the
transactions are stored in a persistent way. The combination of atomicity and consistency
means that a transaction can always be recovered. The combination of isolation and
consistency means that no non-concurrent can see any inconsistent information in the
course of a transaction. The combination of consistency and durability means that the
2
information storage is persistent. The problems deadlocks and the livelocks are solved
using some techniques, thus making the system fault-tolerant.
Two major problems of concurrency controls: lost updates and inconsistent analysis are
taken care of. Concurrency control is transparent to client designers but is not transparent
to server designers. All transactions are Serializable i.e. results of serialization is same as
when done by sequential order.
Concurrency control manager detects deadlocks and they are resolved by aborting the
transaction, which is involved in the deadlock.
The two-phase commit protocol consists of a voting phase and an implementation phase.
In voting phase, the transaction coordinator checks whether every participant transaction
server is able to commit the transaction. During commit, the servers save their changes to
persistent storage and thus implements durability. The phase after the commit and
receiving of the commit request is called server uncertainty. It has to be covered by
storing the modifications of the transaction on temporary persistent storage.
The Open Group has adopted a standard for Open Distributed Transaction Processing
(DTP). The latest standard is called The X/Open DTP standard. This architecture defines
application programming interfaces and interactions among transactional applications
(APs), transaction managers (TMs) and resource managers (RMs). The architecture is
drawn is the diagram as in Figure 2.
Fig 2. Transaction-Oriented Middleware Architecture
3
These distributed object transactions build on the XA-Protocol of the DTP standard are
available in object-oriented middleware too. Object-oriented middleware provides
services for the implementation of transactions, the CORBA Transaction service, MTS
(Microsoft Transaction Server) and the Java Transaction API.
Message-Oriented Middleware: These middleware systems enable the exchange of
reliable message traffic across distributed components. Some of the products for this
middleware are: IBM's MQSeries, the DEC message Queue, Sun's ToolTalk, NCR's
ToEnd or the Java Message Queue. Message-Oriented middleware is used when reliable,
synchronous and asynchronous communication is the dominant form of distributed
system interaction and is event driven rather than procedure driven.
Fig3. Message Oriented Middleware architecture
They support communication between distributed systems components through message
exchange. The greatest thing is that it supports asynchronous message delivery very
easily and elegantly. The client continues to process as soon as the middleware grabs the
message. The server sends the message result to the client, which it collects at an
appropriate time. This de-coupling of client/server leads to a more scalable system. Data
is exchanged by message passing and/or message queuing supported by both
synchronous and asynchronous interactions between distributed computing processes.
The MOM system ensures message delivery by using reliable queues and by providing
the directory, security, and administrative services required to support messaging.
The second big advantage is able to multi-tasking i.e. passing the same message to
multiple clients in a way it seems transparent to the client. This is very useful in
implementing event notification and publish/subscribe-based architectures.
The MOM achieves fault-tolerance by implementing message queues that store message
temporarily on persistent storage. Object-oriented middleware initially did not supported
fault-tolerance and used only synchronous way to communicate with the objects with atmost-once semantics (Errors is passed, if requests is failed. Otherwise, do nothing).
The biggest difference between MOM and object-oriented middleware is:
4
MOM supports messages and therefore is primarily designed to support deferred
communication while peer-to-peer and remote procedure calls (RPC) are designed to
support synchronous communication. Under RPC, the receiving server must be available
to accept messages sent. If the server is down, the message cannot be delivered at that
time. MOM, on the other hand, can send messages to servers that are down without
having to resend them. Messages under a MOM system are placed into a queue and
retrieved whenever the server requests them. Whether the server is available at the time
the message is sent is irrelevant.
But now, the integration of MOM and OOM make it possible to achieve reliable and
asynchronous message requests.
Object-Oriented Middleware: Remote procedure calls (RPC) were standardized by the
OSF, which supported the invocation of procedures across boundaries. They were
developed by sun Microsystems as a part of their Open network Computing (ONC)
platform. Object-oriented middleware has its basis and was very much influenced with
the RPC's. Examples of the products may include popular mainstream products such as
CORBA, Java/RMI, (D)COM and some non-mainstream products such as Aglets,
implementation of tuple spaces that distributed threads can use to communicate and
others unpopular ones. The idea was to make the principles of object orientation such as
identification through references and inheritance available for distributed systems.
The object-oriented middleware contains all aspects of above of middleware architecture,
plus it implements the idea of object-orientation, which makes it a really cool
specification.
Fig 4. Object-Oriented Middleware
5
Interface Definition Language: Every OOM has an IDL. IDLs are language constructs to
which help in communicating between different environments. Thus, OOM systems
support heterogeneity. IDL supports the concepts of object types as parameters; failure
handling; and inheritance. IDL has language constructs for all concepts of the respective
object models.
There are 2 main disadvantages to RPC's. First, they are not reflexive i.e. Procedures
exported to by one RPC program cannot return another RPC program. Second, RPC does
not handle in an amicable way; they return null pointers whenever error is encountered.
These 2 disadvantages are removed in OOM.
OOM are fault-tolerant, as they handle failures in a real sophisticated manner using atmost-once semantics. It uses exception to tell clients about the details of the failures.
Session-layer Implementation: This layer is little complex than RPC layer. Session layer
needs to map object references to hosts. Session layer uses object adapters to locate
server objects and to activate/deactivate them when ever needed. Object adapters need to
start up the server, which register in an implementation repository or registry. Session
layer needs to implements operation dispatch and synchronization.
Server and Client Stubs generation: They perform (un)marshalling for the transport layer
and revolve the problem of heterogeneity of data representation. This constitutes
presentation layer implementation. Client and server stubs are derived from interfaces.
Stubs are generated to implement session and presentation layers. Object requests which
are executed remotely uses marshalling and un-marshalling of parameters to resolve the
heterogeneity and the synchronization of client/server objects. In RPC, a hardware stack
does the parameter passing.
Implementation of client objects: It follows static request definition i.e. request is fully
defined at the time when source code is compiled. Object requests have always has to be
type-safe i.e. the requests promised at the compile time should be similar to that the runtime. Stubs have access and location transparency though it depends if the architecture is
CORBA, RMI or COM.
Implementation of server objects: Like the client objects, the server objects supports
type-safe (no run-time errors). Type safe can be implemented in 2 ways: Inheritance,
middleware develops an abstract class for the server stub. This abstract class has abstract
operations but is not implemented by the class. The class implementing this server object
is defined as the subtype of this abstract class. Server stub is statically referenced to the
abstract class. The server stub is dynamically referenced to the server object. Second
approach is using interfaces. The IDL generates a programming language interface that
includes all operations exported by the IDL interface. The approach achieves type-safety
as the compiler used for translating the implementation of the server object checks that it
correctly implements the interface that was derived by the IDL compiler.
6
Server Registration: Once the server object is compiled, it needs to be registered with the
object-oriented middleware. The purpose of registration is to help the object adapter to
locate the reference of the server objects and to (de)activate them as and when needs.
Critique (Part I): Lets have a comparison of these three middlewares on the basis on
heterogeneity, distribution, communication, security, concurrency, performance,
scalability, and fault tolerance and find out why OOM is better than other middlewares in
most of the scenarios.
Transaction Middleware:
Network Communication: Transactional middleware enables application engineers to
define the services that server components offer, implement those server components and
then write client components that request several of those services within a transaction.
Client and server components can re-side on different hosts and therefore requests are
transported via the network in a way that is transparent to client and server components.
Coordination: The client components can request services using synchronous or
asynchronous communication. Transactional middleware supports various activation
policies and allows services to be activated on demand and deactivated when they have
been idle for some time. Activation can also be permanent, allowing the server
component to always re-side in memory.
Reliability: A client component can cluster more than one service request into a
transaction, even if the server components reside on different machines. In order to
implement these transactions, transactional middleware has to assume that the
participating servers implement the two-phase commit protocol. If server components are
built using database management systems, they can delegate implementation of the twophase commit to these database management systems. For this implementation to be
portable, a standard has been defined. DTP is widely supported by relational and object
oriented database management systems. This means that distributed components that
have been built using any of these database management systems can easily participate in
distributed transactions. This makes them fault-tolerant, as they automatically recover to
the end of all completed trans-actions.
Scalability: Most transaction monitors support load balancing, and replication of server
components. Replication of servers is often based on replication capabilities that the
database management systems provide upon which the server components rely.
Heterogeneity: Transactional middleware supports heterogeneity because the components
can reside on different hardware and operating system platforms. Also different database
management systems can participate in transactions, due to the standardized DTP
protocol. Resolution of data heterogeneity is, however, not well supported by
transactional middleware, as the middleware does not provide primitives to express
complex data structures that could be used as service request parameters and therefore
also does not marshal them. The above discussion has shown that transactional middleware can simplify the construction of distributed systems. Transactional middleware,
however, has several weaknesses. Firstly, it creates an undue overhead if there is no need
to use transactions, or transactions with ACID semantics are inappropriate. Secondly,
marshalling and un-marshalling between the data structures that a client uses and the
parameters that services require needs to be done manually in many products. Thirdly,
7
although the API for the two-phase commit is standardized, there is no standardized
approach for defining the services that server components offer. This reduces the
portability of a distributed system between different transaction monitors.
Message-Oriented Middleware
Network Communication: Client components use MOM to send a message to a server
component across the network. The message can be a notification about an event, or a request for a service execution from a server component. The content of such a message
includes the service parameters. The server responds to a client request with a replymessage containing the result of the service execution.
Coordination: The strength of MOM is that this paradigm supports asynchronous
message delivery very naturally. The weakness, at the same time, is that the
implementation of synchronous requests is cumbersome, as the synchronization needs to
be implemented manually in the client. A further strength of MOM is that it supports
group communication by distributing the same message to multiple receivers in a
transparent way.
Reliability: MOM achieves fault-tolerance by implementing message queues that store
messages temporarily on persistent storage. The sender writes the message into the
message queue and if the receiver is unavailable due to a failure, the message queue
retains the message until the receiver is available again.
Scalability: MOMs do not support access transparency very well, because client
components use message queues for communication with remote components, while it
does not make sense to use queues for local communication. This lack of access
transparency disables migration and replication transparency, which complicates
scalability. Moreover, queues need to be set up by administrators and the use of queues is
hard-coded in both client and server components, which leads to rather inflexible and
poorly adaptable architectures.
Heterogeneity: MOM does not support data heterogeneity very well either, as the
application engineers have to write the code that marshals. With most products, there are
different programming language bindings available. In assessing the strengths and
weaknesses of MOM, we can note that this class of middleware is particularly well-suited
for implementing distributed event notification and publish/subscribe-based architectures.
However, message-oriented middleware also has some weaknesses. It only supports atleast once reliability. Thus the same message could be delivered more than once.
Moreover, MOM does not support transaction properties, such as atomic delivery of
messages to all or none receivers. There is only limited support for scalability and
heterogeneity.
Object Oriented Middleware
Network Communication: Object middleware support distributed object requests, which
mean that a client object requests the execution of an operation from the server object
that may reside on another host. The client object has to have an object reference to the
server object. Marshalling operation parameters and results are again achieved by the
stubs that are generated from an interface definition.
Coordination: The default synchronization primitives in the object middleware are
synchronous requests, which block the client object until the server object has returned
8
the response. However, the other synchronization primitives are supported, too. CORBA
3.0, for example, supports both deferred synchronous and asynchronous object requests.
Object middleware supports different activation policies. These include whether server
objects are active all the time or started on-demand. Threading policies are available that
determine whether new threads are started if more than one operation is requested by
concurrent clients, or whether they are queued and executed sequentially. CORBA also
supports group communication through its Event and Notification services. This service
can be used to implement push-style architectures.
Reliability: The default reliability for object requests is at-most once. Object middleware
support exceptions, which clients catch in order to detect that a failure occurred during
execution of the request. CORBA messaging, or the Notification service can be used to
achieve exactly-once reliability. Object middleware also supports the concept of
transactions. CORBA has an Object Transaction service that can be used to cluster
requests from several distributed objects into transactions. COM is integrated with
Microsoft’s Transaction Server, and the Java Transaction Service provides the same
capability for RMI.
Scalability: The support of object middleware for building scalable applications is still
somewhat limited. Some CORBA implementations support load balancing, for example
by employing using name servers that return an object reference for a server on the least
loaded host, or using factories that create server objects on the least loaded host, but
support for replication is still rather limited.
Heterogeneity: Object middleware supports heterogeneity in many different ways.
CORBA and COM both have multiple programming language bindings so that client and
server objects do not need to be written in the same programming language. They both
have a standardized data representation that they use to resolve heterogeneity of data
across plat-forms. Java/RMI takes a different approach as heterogeneity is already
resolved by the Java Virtual Machine in which both client and server objects reside. The
different forms of object middleware interoperate. CORBA defines the Internet Inter-Orb
Protocol (IIOP) standard, which governs how different CORBA implementations
exchange request data. Java/RMI leverages this protocol and uses it as a transport
protocol for remote method invocations, which means that a Java client can perform a
remote method invocation of a CORBA server and vice versa. CORBA also specifies an
inter-working specification to Microsoft’s COM. Object middleware provides very
powerful component models.
Discussion (Part II): Now that we have establish a deal in the object-oriented
middleware. Lets see and compare the different Object oriented middleware products
(CORBA/COM/RMI/Aglets) in terms of specifications, Meta-object model, objects,
types, attributes, operations, requests, failure handling, Multiple Inheritance (Sub-typing),
polymorphism, stubs & skeletons, object activation, and architecture. I believe this
comparison would be quite interesting.
OMG's CORBA:
0. Assumption: Servers stubs are called the server skeletons in CORBA. IDL compiler
generates 4 files - two for client stubs and two for server stubs. For each, one is class
definition and other is class implementation.
9
1. Specification: There are four different types of OMG (Object Management Group)
specifications.
a. OMA (Object Management Architecture) - It has a reference model for
distributed objects and classifies objects into different categories.
b. CORBA (Common Object Request Broker Architecture) - This is the most
popular OMG architecture. CORBA supports heterogeneous and distributed
objects. Communication between objects is achieved through an ORB (Object
Request Broker). It has an IDL (Interface Definition Language). It identifies a
number of programming binding (how client-server objects can be implemented
in different programming languages). It also has object adapters where is
executable code object and to activate/deactivate them).
c. CORBAservices Specification: It is a basic mechanism that enables the
construction of distributed systems. We have almost a dozen services like locating
objects, creating & moving objects, push-type communication between objects,
managing relationships between objects, controlling concurrent access to objects,
managing distributed transactions between objects, securing access to objects etc.
d. CORBAfacilities Specification: They have interfaces for distributed help systems
and a facility for operating systems independent printing & spooling.
2. Meta Object Model: The object model uses IDL (Interface Definition Language).
OMG has various standard languages binding between IDL and other OO programming
language.
3. Objects:
 It has a unique object identifier.
 Object references are opaque to clients (i.e. they do not know the content).
 Object references support location transparency (i.e. they do know/care for the
location of the invoking object).
 Physical hostname is embedded to enable CORBA implementation to locate the
server objects, but this information is hidden from client.
 Object references are managed by ORBs. The broker stores it all time even if that
object might be currently deactivated.
4. Types:
 CORBA object model are statically typed as it enables type-safety.
 Object type has a unique name.
 Complex types can be constructed using type construction mechanism.
 Interfaces name should be unique
 The concept of modules (which are declared in IDL) can have nested modules.
 They have a concept of scoped identifiers (access for declaration types to other
modules). They are defined in CORBA IDL.
5. Attributes:
 CORBA Object model have a concept of attributes (use to make the state of
server accessible to clients).
 Attributes are treated as operations.
 Attributes are defined in CORBA IDL using keyword Attribute.
 Attribute type has to be known.
10

CORBA object model uses interface definition. Thus, they don't need
public/private attributes. All attributes are accessible to clients. Hidden attributes
as not declared in IDL but are in object type implementation.
 It supports the idea of read-only attribute.
 It supports the idea of constants. They are read-only attributes and not even
changed by server object implementation.
6. Operations:
 CORBA object model support idea of operations (for object types).
 An operation has a return type an operation name, list of parameters and a list of
exceptions.
 Does not believe in public/private operations. Everything is available to the client
object. The operations that are not supposed to be made available to clients are
not declared in the interface of the object request.
 Operations can have three different parameters:
1. 'in' : Clients submits an actual value not modified by the server.
2. 'out' : Server object has produced a parameter value during the object
request.
3. 'inout' : The client passes the actual parameter value that is modified by
the server during the required execution. Explicit parameters kinds used
for signal memory allocation and de-allocation, obligation to client-server
programming. No overloading concept because it makes IDC more
complex.
7. Requests:
 A request in the CORBA object model identifies server object by an object
reference to that object. It also has name and the actual parameters of the
requested operations.
 They might also pass information about the environment in which they are
executed.
 Definition of requests can be for compile time (static request) and for run time
(dynamic request).
 Static request can be determined by invoking by invoking a client stub and
dynamic request by using a standardized dynamic invocation library.
 Object requests have at-most-once semantics (i.e. an error is indicated to the
client if the requested is not executed at the server).
8. Failure handling:
 CORBA has 25 or more exception handlers to inform client about failures.
 They are raised by ORB's when errors occurs.
9. Multiple Inheritance:
 CORBA object model supports multiple inheritances.
 Inheritance is public (i.e. all subtypes of the attributes are exported).
 Inheritance is virtual (Operations are bound dynamically and what is used to
implement an operation is only decided at run-time).
 Multiple inheritance might lead to clashes and is up to the designer to resolve
them.
 The inheritance hierarchy has a predefined single root called interface object.
11
10. Polymorphism:
 CORBA attribute/variable has a static type (which is defined at run-time).
 CORBA object has a dynamic type (the object type for which the object was
initiated).
 CORBA object model supports a restricted type of polymorphism (i.e. attributes
whose static type is an object type may refer at run-time to objects which are of
different types). In short, dynamic types have to be subtypes of the static types.
 Polymorphism is used with redefined types (i.e. they are restricted with
operations).
 It is not possible to redefine the static type of an attribute.
 The signature of an operation cannot be changed. This ensures "type-safe".
11. Architecture: The Figure 5 shows a detailed CORBA architecture.
Fig5. The CORBA Architecture
[Note: IDL are same as client stubs; IDL skeleton and Dynamic Skeleton are also called
Object Implementation]
a. ORB Core:
 It is the central component of the CORBA architecture.
 It receives a request from the client based on reference provided by the client.
 It passes all parameters to server and returns results to the client object.
b. Server Stubs:
 Marshalling and un-marshalling of request parameters are done by servers stubs
(comprise of dynamic invocation, client stub and implementation skeleton).
c. Client Stubs & Server Skeleton: They are generated by IDL compiler.
d. Dynamic Invocation: It supports the definition of requests at run-time.
e. Object Adapters: Two major types:
12

BOA (Basic object adapter): It defines the registration of server objects with an
ORB. It generates references for server objects and are responsible for their
activation & de-activation.
 POA (Portable object adapter): It responsible for registration,
activation/deactivation of server objects and also support responsible objects.
f. ORB Interface: A set of types that both client/server objects for initialization
purposes.
g. CORBA ORB:
 It achieves access transparency (client stubs has exactly the same interface as
server stubs).
 It achieves location transparency (all client object needs to know just the
reference of the server objects).
 It also supports other types of transparencies when used with CORBAservices.
Sun Microsystems's Java/RMI:
0. Assumption: Since this technology is exclusive java it is assumed to possess all the
properties that java has like, it is portable. It is a hybrid language i.e. can be both
compiled and interpreted and so on. It assumes that both client/server are written in java
and executes in a java VM. Even before RMI, java has included distinction between
interfaces and classes.
1. Specification: [Java] Java is an OO language developed by the Sun Microsystems. Java
compiler creates a byte stream, which is interpreted by the virtual machine. The
communication between two objects on different VM (virtual machine) could be done
through JDK1.1+.
[RMI]:
 Java includes an API (Application Programming Interface) known as Remote
Method Invocation. It enables the invocating of client object from one VM to call
the server object on another VM.
 Its design includes object communication, integration with java object model and
for resolution of heterogeneity.
 It includes abstraction of UDP datagrams and TCP streams.
 Sun has provided some high level services on top of RMI like, JINI (It supports
application constructs for portable hosts like transaction and event-notification
services. And EJB (It provides component based development by combining Java
beans with RMI and adding services such as transactions, persistence and
security).
2. Meta Object Model:
 No IDL is needed (client/server are in java).
 For restricting the visibility of declarations, there is a scooping mechanism called
"packages". (This is similar to CORBA). There is need to identify the packages
file to which the declarations exists. Declarations contained in other packages
need to scoped with the package name.
3. Objects:
 Both client/server objects are in java and thus invoke each other.
 "Local procedure calls" are governed by class definition & RMI by Interfaces.
13

RMI does not support location transparency - Client object need to know the
reference of the server object and the type (local or remote) call.
 The client object gets references from Java/RMI registry for server objects. This
registry is based on the naming service (server objects bind there object through a
name).
4. Types:
 It is strongly typed language.
 It has a static type system.
 It supports atomic types (they are int, float, double and char).
 Java object types includes both classes and interfaces.
 Server objects that wants to be accessible remotely needs to implement at least
one interface.
5. Attribute:
 Interfaces cannot define attributes (for remote calls, the attributes has to be
marshaled & transformed and attribute access may fail). It is similar to COM, in
CORBA, they support as attributes are treated as operations). Thus, the designers
of remote objects have to write access operations.
6. Operations:
 Operations in java are called methods. A client object can request execution of all
those methods that are declared in all remote interfaces of server objects.
 Operations should only have atomic; non-remote object types; and remote
interfaces.
 The mechanism for passing objects to a remote object is different from local
procedure call.
 There is no location transparency unlike in CORBA.
a. Parameter passing of atomic type: Call by Value
(For both local and remote calls.)
b. Object passing: Call by reference
(For local calls.)
c. Object passing: Serializable (Passed by Value)
(For local hosts and for remote calls.) Client copy the object before
passing.
d. Object passing: Call by reference
(For remote objects to remote method.) Object is copied but should be
kept on the same host.
Application designers should be aware of the following 3 scenarios.
Scenarios:
a. For non-remote objects to pass to remote object, we need to use
serialize interface. We have to know object has to be passed to the remote method.
b. When passing non-remote object to remote method, any changes made
at remote method to the object will not reflect at the local end.
c. When passing remote object to remote method, any changes made at
remote object will be seen at the local end.
7. Requests:
 Objects requests in java are RMI.
 It supports at-most-once semantics requests like CORBA and COM.
14

Java only supports static RMI (i.e. Java RMI can only be defined at the time when
client object is compiled). It does not support dynamic RMI as it does have
reflection API.
8. Failure Handling:
 If failure occurs, java throws exception.
 Any interface that extends remote has to declare to throw RemoteException.
 Remote methods throw additional exceptions, which may be useful to developers.
9. Multiple Inheritance:
 Java supports inheritance.
 It does not support multiple inheritance for classes but supports MI for interfaces.
 Remote inheritance can inherit from remote and non-remote interfaces at the same
time as long as remote interfaces are allowed to throw RemoteException error.
10. Polymorphism:
 Java supports polymorphism that is statically restricted by inheritance.
 It ensures type-safety (possible if static type is a supertype of static type to be
assigned).
 With multiple interface inheritance, it became possible to have polymorphism
between remote and non-remote objects.
11. Architecture:
Figure 6. shows the RMI detailed architecture.



15
Fig6. RMI Architecture
The client starts a RMI through a local method call to the client stub (clients stubs are
similar to CORBA and interface process in COM, stubs are type-specific and include
object all the remote methods that are available from the remote object on the server
side).
Clients obtain references of remote objects by means of naming through the RMI
registry.
The server can register their objects to the registry so that client stubs can locate
them.

During execution, activation interface call the object's constructor and enable the
object to restore its state.
 Once the object is activated, the control is passed to the skeleton which invokes the
desired remote method.
a. Stubs & Skeleton:
 They are specific to the type of a remote server object that implements as RMI
 It does marshalling and un-marshalling of invocation parameters (implements
presentation layer).
 It is generated by rmic compiler (they are not similar to IDL in CORBA and
COM thus the byte code needs to be shipped to client instead of interface
definition).
 They are partially location transparent (as client need to know of the invoking
method is local or remote).
b. Object activation:
 Object reference follows the concept of faulting tolenrance.
 It locates the server object and activates/deactivates them depending among the
need.
Microsoft's COM:
0. Assumption: COM is relied on OSF/DCE's RPC model. Com proxy is similar to
CORBA client stub.
1. Specification: It is technology based on network/OLE, DCOM and ActiveX. Com
follows Binary encapsulation (machine code representation in server objects are evolved
independently of the client objects) and binary compatibility (machine of the C/S objects
are developed in different in different environments).
2. Meta Object Model: It uses MIDL (Microsoft's Interface definition language).
3. Objects:
 It uses concepts of interfaces, implementation and classes.
COM Interface:
 To communicate between C/S objects.
 They are type-level abstraction.
 Always starts with "I". They are 128-bit physical names referred to as UUID's
(which is unique in time and space).
COM Implementation:
 It is a class of programming language that implements one or many interface.
 Programming language binds to C++, VB and MS version of Java. These binding
tell how to use MIDL.
 Instances of COM implementation are called COM objects. They are instances of
classes in their respective programming languages.
 It does not support object references as in CORBA. Objects, here are identified by
pointers to main-memory locations. Pointers are called interface pointers.
Com Classes:
 They are named implementations that represent instantiable types.
 They expose one or several interface and often provide the principal mechanism
to create or locate objects.
16
 They are initiated in class objects and have to have atleast one class object.
 COM class has a unique physical name called as CLSID's.
The Figure 7 shows the following relations:
 An implementation can be instantiated by several COM object which are
referred in main memory.
 Class object instances of COM objects and they used to create/locate COM
objects.
 COM object model distinguishes logical and physical identifiers. COM does
not module a mechanism, as we needed in CORBA.
 Since no modules are used in COM, UUIDs and CUSID's are generated by
128-bit integers to the interfaces and object implementation. This is real
cumbersome.
Fig7. Relationship between interfaces, implementation and classes
4. Types:
 COM object model are statically typed, MIDL checks for any static semantic
errors.
 Interface pointers are dynamic typed.
 COM supports base types and a number of type constructors.
 COM base types are atomic types and are defined in a platform neutral manner.
 There are fewer Type primitives in COM than in CORBA.
 COM supports 3 forms of arrays depending on it will be used in input/output
parameters.
5. Attributes:
 Unlike CORBA, Com does not support the specification of attributes for
interfaces. Instead, COM supports use of property operations.
 COM allows the use of [propget] and [propput] to obtain or modify an attribute.
Some programming language bindings then map these operations to instance
variables access and modifications.
6. Operations:
17

Like CORBA, COM does not have any primitives to define the visibility of
operations. All operations that are declared in COM interface are available to
clients.
 COM has flexible interface mechanism that can be used to provide client-specific
views on COM objects. We use Multiple Inheritance to do this in CORBA.
 Operations can have parameters. [in] parameters are supplied by clients, [out]
parameters are returned by the COM object to a client and [in,out] parameters are
supplied parameters that are modified by the COM objects.
7. Requests:
 COM operations return a 32-bit integer that encodes whether or not operations
have successfully executed or not. This is unlike CORBA.
 An object request in COM is an operation invocation.
 Like CORBA, COM operations invocations have at-most-once semantics.
 Like CORBA, COM supports static definition of requests when the client is
compiled. It also supports dynamic definition of requests.
8. Failure Handling:
 COM handles failures by means of results of COM operations.
 COM includes predefined type HRESULT to successful or fault execution of
operations. HRESULT is a 32-bit integer value that is returned from server to
client objects.
 It has 4 fields: Severity code (indicates success by zero and error by one),
reserved (internal use, not use c/s programmers), facility code (success or failures
of Microsoft's technologies) and Information code (to pass error information).
 The good thing about HRESULT is that they are less expensive than exceptions in
java or CORBA.
9. Inheritance:
 COM supports interface inheritance. One interface inherits from another and there
is one root interface in the hierarchy called "IUnknown".
 IUnknown has 3 operations that every COM object needs to inherit:
QueryInterface (checks if object reference supports a particular reference), Addref
and Release (increase and decrease of references that are to the object).
10. Polymorphism:
 COM supports polymorphism, similar to any other object model.
 The distinction of interfaces and implementation in COM enables a further form
of polymorphism, because COM interfaces can have multiple implementations.
 When using polymorphism, it became necessary to use the same object through
different interface. This is supported by type coersion, which is form of dynamic
type cast and is supported by QueryInterface operation.
11. Architecture:
Marshalling and un-marshalling are performed by object proxies, interface proxies, object
stubs and interface stubs. Activation and deactivation are implemented by service control
manager. COM supports access and location transparency, like CORBA.
I have found COM architecture highly complicated and confusing. No wonder, its
Microsoft!! There are 3 principles ways that the COM implements operation requests.
18
COM chooses this transparency for the client programmer depending on the location of
the server object. If the server object is available in a DLL (dynamic link library) on the
same host, the DLL is loaded and object request is implemented as a local procedure call.
If the server is located on the same host, but executes a different process (EXE Server),
COM uses 'light'-RPC, which perform (un)marshalling but does not use network as a
transport. Finally, if the server object is not available locally, COM using 'heavy'-RPC,
which I am afraid I found very complicated. It's good to be honest, sometimes!!
Fig8. COM Implementation for Object requests
IBMS's Aglets:
0. Assumption: Aglets are Java objects that can move from one host on the Internet to
another. That is, an aglet that executes on one host can suddenly halt execution, dispatch
to a remote host, and resume execution there. When the aglet moves, it brings along its
program code as well as its state (data). A build-in security mechanism makes it safe to
host untrusted aglets.
First came the applet, allowing a graphical agent to be downloaded into a client
environment (browser) and execute with impunity there. Next the servlet, another Java
technology that allows a client program to upload program code to a server, which then
instantiates and executes on the server for the benefit of any client wishing to see any
results. Now Aglets have been created as the agents that can run on client or server,
anywhere on the Internet or Intranets connected.
1. Specification: Aglets are a mobile agent technology developed at IBM research
laboratories in Japan. Aglets where developed as one implementation of a mobile agent
system based on the Java API. The Java Aglet Application Programming Interface (JAAPI) is a standard for interfacing aglets and their environment
2. Meta Object Model: The Aglet API defines the fundamental functionality of mobile
agents.
3. Objects: The following figure shows the major interfaces and classes defined in the
Aglet API and the relationship between these interfaces.
19
Fig9. Relationship between Interfaces
com.ibm.aglet.Aglet: The Aglet abstract class defines the fundamental methods like
dispatch(URL) used to control the mobility and life cycles of mobile agents. All mobile
agents defined in Aglet have to extend this abstract class. The Aglet.dispatch(URL)
primitive causes an aglet to move from the local machine to the destination specified as
its argument. The Aglet.deactivate(long time) primitive allows an aglet to be stored in
secondary storage, and the Aglet.clone() primitive spawns a new instance of the aglet that
has the same state as the original aglet.
com.ibm.aglet.AgletID: All aglet instances have their own unique identities that are
immutable throughout the life cycle of the aglet. The AgletID is an object that keeps an
unique identifier for the given agent, while encapsulating its representation details.
com.ibm.aglet.AgletProxy: The AgletProxy interface object acts as a handle of an aglet
and provides a common way of accessing the aglet behind it. Since an aglet class has
several public methods that should not be accessed directly from other aglets for security
reasons, any aglet that wants to communicate with other aglets has to first obtain the
proxy object, and then interact through this interface. When invoked, the proxy object
consults the SecurityManager to determine whether the caller is permitted to perform the
method. Another important role of the AgletProxy interface is to provide the aglet with
location transparency. If the actual aglet resides at a remote host, it forwards the requests
to the remote host and and returns the result to the local host.
The runtime library is responsible for providing the implementation of the AgletProxy
interface; thus, aglet programmers do not have to implement this interface.
com.ibm.aglet.AgletContext: The AgletContext class provides an interface to the
runtime environment that occupies the aglet. The runtime library is responsible for
providing the implementation of this interface; thus, aglet programmers do hot have to
implement this interface.
com.ibm.aglet.Message: Aglet objects communicate by exchanging objects of the
Message class. A message object has a String object to specify the kind of the message
and arbitrary objects as arguments.
com.ibm.aglet.Ticket: A Ticket object is used to specify both of a destination and a
quality of transfer. In other words, it defines the way in which an aglet is transferred. It
may include the destination, the protocol to be used, and quality such as timeout, the level
of integrity or confidentiality that must be secured. This object is used where URL were
used as the way to specify the destination.
20
com.ibm.aglet.FutureReply: An object of the FutureReply interface is returned by the
asynchronous message-passing and used as a placeholder to receive the result later
asynchronously. With this interface, the receiver can determine whether a reply is
available, and can wait for the result with a specified timeout value so that it can continue
its execution if a reply was not returned within the specified time.
11. Architecture:
The Aglets architecture consists of two layers, and two APIs that define interfaces for
accessing their functions.
The Aglets runtime layer is the implementation of the Aglet API, and defines the
behavior of the API components, such as AgletProxy and AgletContext. It provides the
fundamental functions for aglets to be created, managed, and dispatched to remote hosts.
The communication layer is primarily responsible for transferring a serialized agent to a
destination and receiving it. It also supports agent-to-agent communication and facilities
for agent management.
Aglets Runtime Layer: The Aglets runtime layer implements Aglets interfaces such as
AgletContext. It also consists of a core framework and subcomponents. The core
framework provides the following mechanisms fundamental to aglet execution:
 Serialization and deserialization of aglets
 Class loading and transfer
 Reference management and garbage collection
The subcomponents are designed to be extensible and customizable because these
services may vary depending on requirements or environments.
 PersistenceManager: The PersistenceManager is responsible for storing the
serialized agent, consisting of the aglet's code and state into a persistent medium
such as a hard disk.
 CacheManager: The CacheManager is responsible for maintaining the bytecode
used by the aglet. Because the bytecode of an incoming aglet needs to be
transferred when the aglet moves to the next destination, the CacheManager
caches all bytecode even after the corresponding class has been defined.
 SecurityManager: The SecurityManager is responsible for protecting hosts and
aglets from malicious entities. It hooks every security-sensitive operation and
21
checks whether the caller is permitted to perform it. There is only one instance of
SecurityManager in the system, and it cannot be altered once it has been installed.
Communication Layer: The Aglets runtime itself has no communication mechanism for
transferring the serialized data of an aglet to destinations. Instead, the Aglets runtime uses
the communication API that abstracts the communication between agent systems. This
API called MASIF (Mobile Agent System Interoperability Facility) which defines
methods for creating and transferring agents, tracking agents, and managing agents in an
agent-system- and protocol-independent way.
The current Aglets uses the Agent Transfer Protocol (ATP) as the default implementation
of the communication layer. ATP is modeled on the HTTP protocol, and is an
application-level protocol for transmission of mobile agents. To enable remote
communication between agents, ATP also supports message-passing.
Critique (Part II):
Lets compare CORBA, COM, RMI and Aglets on one-to-one bases.
Type
CORBA
COM
RMI
Stub
IDL generates
MIDL
It provides a
Generation
C/S stubs.
generates C/S
compiler that
stubs.
generates stubs
from java class
definition
without using
interface
definition.
Implementation They do have a Relies on
Java provides
Repository
repository
registries that
activation
though not
is part of the
interface that
specific. This is windows OS.
are used with
implemented
RMI. They are
with object
implemented
adapters.
with java RMI
daemon.
Meta Object
Uses IDL.
Uses MIDL
NO IDL used.
Model
All C/S VM
uses java.
Location
Yes
Yes
Not fully.
Transparency
Client has to
know if the
call is for local
or remote.
Parameter and
Does not
Uses
Depends
object passing
depend on
light/heavy
extensively on
remote/local
weight RPCs.
remote/local
hosts.
Extensive
calling and
usage.
passing.
At-most-once
Yes
Yes
Yes
22
AGLETS
ATP is used to
do work as
stubs.
They have
abstractions
called as
message,
message
manager and
itinery.
Uses com.ibm.
aglet.AgletProxy
Yes
Does not depend
on remote/local
hosts.
Yes
semantics
Static RMI
Yes.
Yes
Yes. Proxy takes
care.
No
No.
Yes
Yes, but the
process to
complicated
and
cumbersome.
No
Yes
Yes
Yes
Yes
Yes
Yes
Restricted form
of
polymorphism.
(Statically
typed)
Yes, through
IDL.
Restricted
form of
polymorphism.
(Statically
typed)
Yes, through
MIDL.
Restricted
form of
polymorphism.
(Statically
typed)
No
Object
(de)activators
(to identify
server objects)
Object
adapters.(Object
references)
By faulting
reference
which is very
complex.
Who generates
Stubs &
skeleton
(presentation
layer)
Access
Transparency
IDL. Uses
Client stubs and
server Skeletons
SCM (Service
Control
manager
through
Interface
pointers).
MIDL. Uses
interface
proxies and
interface stubs.
Restricted form
of
polymorphism.
(Statically
typed)
Yes. The code &
state are
transferred to
client.
com.ibm.aglet.
AgletContext
does that work.
Yes
Not fully. As
clients needs to
know if it’s a
local/remote
call.
Integrates nonremote objects
into object
model (it
modifies
Dynamic RMI
Multiple
Inheritance
class
Multiple
Inheritance
Interface
Polymorphism
Language
independency
Yes. JRMI can
be defined at
compilation
time.
Yes. Defined at
run time.
Yes
Object model & They have
non-remote
separate
models
language to
define interface
and interface
23
They have
separate
language to
define
interface and
Rmic compiler. Communication
Uses Stubs and layer in the
Skeleton.
Aglets
architecture.
Yes
No separate
language is
needed, the code
is passed to the
client side.
Inheritance
Attributes
Failures
Binary
Encapsulation
Binary
Compatibility
Object
References
Passing to
executable code
to remote
system
can be written
in different
programming
language.
interface can
be written in
different
programming
language.
Yes. Root is
Object
Treated as
operations
(implicit)
Standard
exceptions &
support type
exception as a
part of IDL.
Yes
Yes. Root is
IUnknown
Treated as
operations
(explicit)
Defines
HResult (32bit integer)
Yes
parameters
passing
mechanism
into the model
& by passing
non-remote
objects by
value).
Yes. Root is
Remote
Treated as
operations
(explicit)
Standard
exception &
support type
specific
exception.
No
Yes
Yes
No
No
Does support
through rmic.
Yes. Java
objects are
passed and
returned as
parameters.
?
Does support
Does not
support
No. Allows only Code is never
primitive types
passed.
and structures to
be passed. Code
is never passed.
Yes. Root is ??
Treated as
operations
(?)
Standard Java
Exceptions
No
Yes. Through an
Mobile Agent.
Future Work:
 Java does not support dynamic RMI as it does have reflection API. The reflection
API in JDK1.2 is not integrated with RMI. Thus, it is not possible to pass meta-data
that is needed for dynamic request across a remote object, as it does not implement
Serializable. Thus, I see a future work to make the Java requests a dynamic RMI.
 We can see pros and cons for Java/RMI and CORBA below and our work could be to
try & convert cons to pros.
JAVA/RMI:
Pros
Cons
Portable across many platforms.
Tied only to platforms with Java support.
Can introduce new code to foreign JVMs.
Security threats with remote code
execution, and limitations on functionality
enforced by security restrictions.
Java developers may already have
Learning curve for developers that have no
experience with RMI (available since
RMI experience is comparable with
JDK1.02).
CORBA.
24
Existing systems may already use RMI the cost and time to convert to a new
technology may be prohibitive.
Can only operate with Java systems - no
support for legacy systems written in C++,
Ada, Fortran, Cobol, and others (including
future languages).
CORBA:
Pros
Services can be written in many different
languages, executed on many different
platforms, and accessed by any language
with an interface definition language (IDL)
mapping.
Cons
Describing services require the use of an
interface definition language (IDL) which
must be learned. Implementing or using
services require an IDL mapping to your
required language - writing one for a
language that isn't supported would take a
large amount of work.
IDL to language mapping tools create code
stubs based on the interface - some tools
may not integrate new changes with
existing code.
CORBA does not support the transfer of
objects, or code.
With IDL, the interface is clearly separated
from implementation, and developers can
create different implementations based on
the same interface.
CORBA supports primitive data types, and
a wide range of data structures, as
parameters
CORBA is ideally suited to use with legacy The future is uncertain - if CORBA fails to
systems, and to ensure that applications
achieve sufficient adoption by industry,
written now will be accessible in the future. then CORBA implementations become the
legacy systems.
CORBA is an easy way to link objects and Some training is still required, and CORBA
systems together
specifications are still in a state of flux.
CORBA systems may offer greater
Not all classes of applications need realperformance
time performance, and speed may be traded
off against ease of use for pure Java
systems.
To come up pros and cons with COM is Cumbersome tO Model. COM just works fine
with the Microsoft products and environment, that’s its problem. What Microsoft needs is
a 'Think Global' motto!
Conclusion: I would be in fix if somebody asked me, which one of these
architecture/technologies is "The Best". I wanted to include some (snapshots of)
programs to show to speculative differences and (dis) advantages of each these
architecture using a similar example, but I guess this would be too much for this paper (I
am already on the 26th page!). I think each of these technologies has their own advantages
and disadvantages depending upon the user perspective, and the designers & developers
(both the server side and the client side) should decide on their priorities before picking
any of these. I believe, I would look at the potential scenario to pick which works best!!
References:


25
Chapter 10: Objects, Components, and Frameworks with UML
Chapters 3, 4, 6, 7, 8, 10, 11: Engineering Distributed Objects




26
CORBA and Java Implementations: An Analysis
Web Sites, White papers and online articles.
Yugi's web links for middleware details and comparison.
http://theserverside.com Message boards (chat)