Download COMPARING AGLET/XML WITH OTHER DISTRIBUTED OBJECTS

COMPARING AGLET/XML WITH OTHER
MIDDLEWARE APPOACHES
1. Introduction
Distributed system has become more and more pervasive nowadays. A distributed system
normally has more than one component running on more than one host, and a distributed
system normally resolves heterogeneity and distribution by middleware that is layered
between distributed system components and network operating system. CORBA, JAVA
Beans/JAVA RMI(Remote Method Invocation) and Microsoft’s COM(Component Object
Model) are three very popular middleware products. Moreover, although Aglet/XML is not
mainstream middleware yet, but it is already becoming more and more recognized because
its attractive features, such as agent mobility.
In this paper, we will discuss above four middleware approaches specifically, compare
Aglet/XML with the other three methods from various aspects.
2. Discussion
The intention of this paper is to compare Aglet/XML with other three middleware
approaches. In order to give the audience a better and clearer idea, we will first discuss
each of the approach specifically, Aglet/XML will be the last one and with more detail,
then we will make a comparison together.
2.1. CORBA
CORBA is actually the acronym of Common Object Request Broker Architecture. It is
defined by the Object Management Group (OMG), a non-profit organization that has more
than 800 members.
CORBA has inherited and expanded the traditional Client/Server structure, one major
enhancement and difference is the client does not know where the server (actual service
provider) is. The basic intention of CORBA is to enable open interconnection of a wide
variety of languages, implementations, and platforms. In order to realize this goal, CORBA
is formed by three major parts: a set of invocation interfaces, the object request broker
(ORB), and a set of object adapters.
Each CORBA object has a unique object identifier, but may have many references. To
make an object request, i.e. request the execution of an operation from a server object, a
client has to obtain a reference to the server object, then use this object’s predefined
interfaces and this reference to request operations. The client does not need to know where
the object is physically located. Actually, the physical location is embedded in the
reference, but is opaque for the client. When a object reference is used for a request, the
CORBA object request broker will use this reference to locate the server object. At the
server side, the object adapter retrieves the arguments and invokes the requested method on
the referenced server object.
Object
Implementation
Client
Dynamic
Invocation
Client
Stubs
ORB
Interface
Impl
Skeleton
Object
Adapter
ORB Core
Figure 2.1 (cited from textbook)
Figure 2.1 shows the architecture of CORBA. The central component of the CORBA is
ORB. An ORB receives a request to invoke an operation from a client object and forwards
that request transparently to the server object. In particular, the ORB locates the server
object reference provided by the client, transmits the request parameters to the server and
returns the request results to the client object. (Cited from textbook)
CORBA currently provides 16 object services:
















Naming Service
Object Security Service
Object Trader Service
Object Transaction Service
Change Management Service
Concurrency Service
Event Notification Service
Externalization Service
Licensing Service
Lifecycle Service
Object Collections
Object Query Service
Persistent Object Service
Properties Service
Relationship Service
Time Service
2.2. COM/DCOM
COM is the acronym of Component Object Model, and DCOM is actually Distributed
COM. COM is Microsoft’s foundation on which all component software on its platforms is
based.
COM supports binary encapsulation, which means the machine code representation of
server objects can evolve independently from its clients. Also, COM defines memory
layout of objects to force different compilers to produce interoperable binary code. It
provides the ability to use the machine code of an object that was created using one
program development environment when developing client code in a different
environment. This feature is called binary compatibility. The principal mechanism of COM
for achieving both binary encapsulation and binary compatibility is the separation of
interfaces from implementations. In fact, the fundamental entity that COM does define is
the interface. On the binary level, an interface is represented as a pointer to an interface
node. The only specified part of an interface node is another pointer held in the first field of
the interface node. The second pointer is defined to point to a table of procedure variables.
Figure 2.2 shows a COM interface on the ‘binary’ level. (cited from textbook)
Client
Variable
Interface
Node
Op 1
Op 2
.
.
.
Component
.
.
.
Op n
Figure 2.2 (cited from textbook)
As shown in Figure 2.3, there are three principal ways that COM implements operation
execution requests. If the server object is available in a local DDL, the DLL is loaded if
necessary and the object request is implemented as a local method call. If the server object
is located on the same host, but executes in a different process, COM users a light-weight
remote procedure call mechanism, but does not use the network as a transport. Finally, if
the server object is not available locally, COM implements the object request using full
blown remote procedure calls. This becomes the Distributed COM (DCOM).
DCOM transparently expands the concepts and services of COM. DCOM builds on the
client-side proxy objects and the server-side stub objects already present in COM, where
they are used only to support inter-process communication. To support transparent
communication across process boundaries or across machine boundaries, COM creates
proxy objects on the client’s end and stub objects on the server’s end. (cited from
Component Software page 207)
Inter-Process call with
Light-Weight RPC
Local Object in
EXE Server
Client Object
Method Call
Local Object in
In-Process DLL
Remote call with
real RPC
Object on
Remote Host
Figure 2.3 (cited from textbook)
2.3. Java Beans / Java RMI
Java is an object-oriented programming language developed by Sun Microsystems. Java
RMI is actually Java’s API known as Remote Method Invocation. RMI enables a client
object that resides in one Java Virtual Machine (VM) to invoke a method from a remote
server object that resides in a different Java VM. As these VMs may actually execute on
different hosts, Java RMI must be regarded as an object-oriented middleware and we can
consider RMI in Java to be object requests between Java objects that are distributed across
different Java VMs. On the other hand, Java Beans is a software component model for Java.
Java Beans API provides a framework for defining reusable, embeddable, modular
software components. Using this API, a Java Bean becomes a component with a set of
classes and resources, it provides the service requested from a client object via Java RMI.
Figure 2.4 show an overview of the architecture of Java RMI. Clients start remote method
invocations through a local method call to a stub. Like client stubs in CORBA and interface
proxies in COM, stubs are type specific and include 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, which is implemented in the registry. Server objects register
their object references with the registry so that clients can locate them. Server objects may
be activated explicitly by some administrator or implicitly when a remote method
invocation is made for that object. In the latter case, the object has to be able to be activated
and use activation interfaces to register itself. During activation, the activation interfaces
call the object’s constructor and enable the object to restore its state. Once an object is
activated, control is passed to the skeleton, which invokes the desired remote method.
Client
Stub
Server (Java Bean)
Registry
Interfaces
Skeleton
Activation
Interfaces
RMI Runtime
Figure 2.4 (cited from textbook)
On the component side, Java Bean has following 5 main aspect:
 Events. Beans can announce that their instances are potential sources or listeners of
specific types of events. An assembly tool can then connect listeners to sources.
 Properties. Beans expose a set of instance properties through pairs of getter and setter
methods. Properties can be used for customization or programmatically. Property
changes can trigger events and properties can be constrained.
 Introspection. A bean can be inspected by an assembly tool to find out about the
properties, events, and methods that a particular bean supports.
 Customization. Using the assembly tool, a bean instance can be customized by setting
its properties.
 Persistence. Customized and connected bean instances need to be saved for reloading
at the time of application use.
(cited from Component Software page 230)
2.4. Aglet / XML
In today's network-oriented computing environments it's common to find applications that
distribute their workload over multiple hosts. In some cases, distributed applications are
composed of tightly knit components, each component capable of residing on any arbitrary
host that provides the requisite services. In other cases, a system of loosely knit
applications works together to provide a single (point of) interface for an application or a
user. So what is called mobile agent comes out at this background. Mobile agent
technologies support common solutions to implementing cooperating, distributed
application components. Just as a graphical toolkit is useful for developing multiple
graphical applications, a mobile agent framework facilitates the development of multiple
distributed applications, as well as the ongoing enhancement of existing distributed
applications. (cited from Distributed Computing with Aglet)
The Aglets Software Development Kit (ASDK) framework is a lightweight mobile agent
technology from IBM's Tokyo Research Laboratory. With aglets, it's straightforward to
develop stand-alone distributed applications that are independent of large-scale application
server frameworks. That is, application components can be truly distributed, and not
dependent on a centralized application server that provides a host of distributed
middleware services. With mobile agent technologies, a developer is not bound by more
traditional distributed computing models, for example, two-tier client-server models,
three-tier middleware-oriented models, and so on. The mobile agent paradigm supports a
powerful programming style. In many cases, the challenge for programmers is to resist
viewing the "world" in terms of the traditional client-server paradigm. Instead,
programmers should look for opportunities to empower Java classes with the capability of
relocating themselves on various hosts and performing the requisite work. There are at
least three ways to view the role of aglet technology:
 As a communication mechanism

As a data transport vehicle among hosts
 As a framework for partitioning application functionality
Communication can be viewed at two levels. First, aglets themselves are often dispatched
from host to host. As mentioned, the ASDK uses a URL-based communication protocol,
ATP. Typically, when a program dispatches an aglet to a remote site, the destination is
specified as a URL, for example, atp://<host>:<port>/<context>. If the ATP protocol
handler is properly registered with the Java environment, the Java runtime software
handles the low-level data transport (in this case, an aglet instance) to the specified host
and port. Upon arrival, the aglet-aware program at the specified port automatically parses
and interprets the data stream using the registered ATP content handler. (cited from
Distributed Computing with Aglet)
Second, there are times when two application components need to communicate, for
example, exchanging a message. If these two components are implemented as aglets, they
can use the ASDK's built-in messaging facility, which supports synchronous and
asynchronous communication. If these two components are not aglets, they can instantiate
aglets that perform the communication for them. In this scenario, aglets are the best way
for communication in lieu of more traditional network programming facilities, for example,
RMI, sockets, and so on. (cited from Distributed Computing with Aglet)
The third role, using aglets to partition application functionality, is arguably the most
important. In particular, application partitioning can be based on static versus dynamic
issues. Static, stay-put functionality is perhaps best implemented as one or more Java
classes. On the other hand, operations that need to be performed systematically at multiple
sites are good candidates for implementation as aglets. When fully utilized, aglet
technology leads to a rethinking of how applications are designed(cited from Distributed
Computing with Aglet).
Figure 2.6 (cited from Distributed Computing with Aglet)
Aglets must exist in a place, an aglet context. Aglet contexts can be implemented within
stand-alone applications, or within special-purpose aglet servers, such as the Tahiti server
that's shipped with the ASDK. Also, in an Aglet context, the aglet is actually managed by
and referenced through its proxy. The proxy provides location transparency for the aglet.
That is, an aglet can be manipulated via its proxy, regardless of whether its current location
is local or remote. Another advantage of the proxy layer is that it allows the aglet
framework to impose security checks. That is, the proxy employs the security manager to
verify whether or not a method invocation is valid in the current context. Figure 2.6 depicts
a general structure of Aglet. (cited from Distributed Computing with Aglet)
Mobile agents, such as Aglet, basically is able to move code and data together between
hosts. It has been considered the highest level of mobility that can be achieved in a logical
context. However, several application domains need a more flexible approach to code
mobility than can be achieved with mobile agents in general. The extensible Markup
Language (XML) happens to have some interesting characteristics, mainly related to
flexibility that allow its use for code migration, although XML has not been designed for
code mobility.
DTD
XML
Document
Interpreter
HOST 1
HOST 2
Figure 2.7(cited from Implementing Incremental
Code Migration with XML)
XML is the basis for next generation markup languages for the Internet. XML is a subset of
the Standard Generalized Mark-up Language (SGML). Unlike HTML, both XML and
SGML allow users to define their own set of mark-up tags for structuring documents.
These user-defined mark-up tags are defined in document type definitions (DTDs). A DTD
is a grammar that defines the syntax of documents. XML is not only useful for publication
of documents on the World-Wide-Web, but can also be used as an application-specific
transport protocol in distributed system construction. XML provides a flexible approach to
describe data structures, XML can also be used to describe code. XML DTDs are, in fact,
very similar to attribute grammars. Each element of an XML DTD corresponds to a
production of a grammar. The contents of the element define the right-hand side of the
production. Contents can be declared as enumerations of further elements, element
sequences or element alternatives. These give the expressive power to DTDs. The markup
tags define terminal symbols. Elements of XML DTDs can be attributed. These attributes
can be used to store the value of identifiers, constants or static semantic information, such
as symbol tables and static types. Thus, XML DTDs can be used to define the abstract
syntax of programming languages. When XML programs are sent from one host to another,
we effectively achieve code mobility. XML programs are transferred as source code and
then interpreted on a remote host by interpreter. Figure 2.7 shows how XML provides the
code mobility. (cited from Implementing Incremental Code Migration with XML)
XML does not confine us to sending coarse-grained units of code; XML documents do not
need to begin with the root of the DTD, they can also start with other symbols of the
grammar. This enables us to specify sub-programs and even individual statements. We
refer to such code fragments as XML program increments. Hence, we can specify complete
programs as well as arbitrarily fine-grained increments in XML. (cited from Implementing
Incremental Code Migration with XML)
Based upon the discussion above, both Aglet and XML are able to provide the mobility of
component in distributed environment.
3. Comparison
We have discussed the four distributed system middleware approaches in above section. In
this section, we will compare the Aglet/XML approach with other three approaches.
3.1. General
CORBA, COM and Java/RMI enable client objects to request operation executions from
distributed server objects. These server objects are located on a remote host and providing
service for client, the actual code is executed remotely and the results will be returned to
the client. Aglet components are providing the service in a different way, the server
component is mobile, the client object is also mobile, server Aglet can be dispatched from
server host to client host, provide some service, then be retracted back to server host, client
also can dispatch Aglet to server, get some service (such as information query), then come
back to client. Also, XML is able to provide the same mobility. In addition, XML also
provides the ability to send code incrementally instead of resending the complete updated
version of code. From certain point of view, CORBA, COM and Java/RMI can be
considered as static approach, while Aglet and XML are dynamic approaches in a
distributed system. This is the most significant difference between Aglet/XML and other
three approaches.
Next we will compare Aglet/XML with other three approaches in each phase of software
engineering.
3.2. Software Engineering Perspective
During software engineering lifecycle, there are requirement analysis, design,
implementation, integration, testing and maintenance 6 phases.
In Requirement Analysis phase, there should not be much difference between Aglet/XML
and other three approaches. Because this phase is only to identify the functional and
non-functional properties that users demand from a system.
Due to the tremendous native difference (static vs dynamic) between Aglet/XML and other
three approaches, the distributed system’s design will be in different ways. Using CORBA,
COM or Java/RMI, the system design should take care of the plan of server distribution,
interface definition, object model and reference, workload balance, etc. While using
Aglet/XML, because the flexibility and mobility, the design should be much easier. For
example, the ASDK framework facilitates flexible code distribution. That is, factoring
functionality and communications using the most appropriate strategies for the task at hand.
Moreover, this functionality can move to the most appropriate network host, as needed, on
demand. Because the functionality or component is not fixed at certain place, we don’t
need to worry about the distribution plan, we only need to worry about how to implement
the functionality itself.
Figure 3.1 shows the implementation procedure of CORBA, COM or Java/RMI. Interface
Definition, Stub Code Generation are very complicated. For example, CORBA is usually
developed by C/C++, it needs a lot of effort to develop. And a lot these efforts are only for
interface, not functionality. However, using Aglet/XML, it is much simpler. For example,
Aglet is developed by ASDK, the interface stuff has been taken care of already, Aglet is
developed by Java, which is also much easier than C/C++.
In integration phase, CORBA and COM have existed for a long time, they support
applications from different platforms, so it should be easier to integrate new application
with legacy systems. Java/RMI needs both client and server objects are written in Java, in
this respect, it is inferior comparing to CORBA and COM. In similar situation, Aglet needs
to be developed by ASDK, XML approach needs to define DTD and implement interpreter,
they are both a little bit weak in the respect of integration with legacy systems.
Design
Interface
Definition
Server Stub
Generation
Client Stub
Generation
Server
Coding
Client
Coding
Server
Registration
Figure 3.1 (Cited from textbook)
In testing phase, there should not much difference between all these approaches. However,
with Tahiti server, it would be a little easier to test Aglet.
In maintenance phase, because of the simplicity of implementation of Aglet and XML,
they are also easier to be maintained than the other three approaches.
4. Conclusion
In previous sections, we have discussed four object-oriented middleware approaches in
distributed environment: CORBA, COM, Java/RMI and Aglet/XML. The conclusion we
have achieved is Aglet/XML is superior comparing with CORBA, COM and Java/RMI
because of its mobility, flexibility and simplicity.
This conclusion is mainly based upon the middleware’s architecture and software
engineering procedure. However, the reliability and performance are also keys to
determine a good middleware approach. CORBA, COM and Java/RMI have been used for
a relatively long time already, while Aglet/XML are kind of brand new technology, so we
are not sure the reliability of Aglet/XML yet. Also, we don’t have the performance test
result of these middleware. We still need to work further to find out which one is the best.
5. Reference
[1] Wolfgang Emmerich Engineering Distributed Objects
[2] Wolfgang Emmerich, Cecilia Mascolo and Anthony Finkelstein Implementing
Incremental Code Migration with XML
[3] Distributed computing with Aglet
[4] Clemens Szyperski Component Software - Beyond Object-Oriented Programming