Reflective Middleware

wirelessguideΚινητά – Ασύρματες Τεχνολογίες

24 Νοε 2013 (πριν από 3 χρόνια και 4 μήνες)

78 εμφανίσεις

Reflective Middleware


Hailiang Mei, TU/e



Page
1

of
15

Reflective Middleware

(Its definition and current research activities)

Hailiang Mei, H.Mei@tue.nl

System Architecture and Networking

Eindhoven University of Technology


1

Introduction


Nowadays, component
-
based middleware architecture is being more emphasiz
ed by
numerous of researchers. The direct motivation is to
realize easier middleware
modification
. To update a component
-
based middleware, we do not need to change the
entire source code. The flexibility and scalability of component
-
based architecture allo
ws
developers to modify the existing functions or integrate new functions in the middleware
much easier. Moreover, the significant reducing on time
-
to
-
market can lead to more
profit and better business competitive ability.


Some major problems need to be s
olved when we are concerning a new component
-
based
middleware architecture are:


1.

The explicit definition of all the relevant terminologies. For example the
definition of component, service and application. (Should be solved already in
Robocop project)


2.

We
need the clear knowledge on the behaviors of components and the
dependencies among components, which is very important for maintaining the
system integrity when we update the components.
Reflective Middleware

is
definitely the topic of interest here.


3.

The
ability of self
-
maintenance and self
-
healing is a very interesting research
direction. We want our middleware architecture to be intelligent and robust
enough to against most of the unforeseen errors. The fault tolerant idea is relevant
here.


4.

Some necessa
ry monitoring functions are required, and the designed architecture
should allow either local management or remote management. If the remote
management problem is solved, we could easily integrate the loading function of
the new component into the remote l
inks. And then together with issue 2, the
middleware layer can be modified through the remote link.


Among these four issues, issue 2 will be highlighted during this report. To understand
Reflective Middleware

clearly is the first key, therefore, the basic

idea of Reflective
Middleware will be introduced in section 2. Some related works have been done so far
are presented in section 3, where we expect part of the existing designs could be reused
into our aiming component framework, such as Robocop/Space4U f
ramework.



Reflective Middleware


Hailiang Mei, TU/e



Page
2

of
15

2

Reflective Middleware


2.1

What is Middleware


Middleware

is a kind of software. It refers to a distributed platform of interfaces and
services that reside ‘between’ the application and the operating system (including drivers)
and aim to facilitat
e the development, deployment and management of distributed
applications. In the component
-
based system, the components are located both in the
application layer and middleware layer. Each component may have different
functionalities and contain one or mul
tiple services.


Hardware
OS & Drivers
Middleware
Application


Figure
1

Layered structure of software architecture


This platform plays the role like a bridge between the application layer and the OS &
Driver layer. It offers the recognized inter
face to other parties who might develop the
application software. These third parties do not need to know the detail technical
properties of the OS & Driver layer. In other words, the main function of middleware is
to mask the inherent heterogeneity of dis
tributed systems and provide a standard set of
interfaces and services which distributed applications can assume present in any
participating language, operating system or machine environment.


Three different types of middleware are named
object
-
based mi
ddleware,

event
-
based
middleware

and
message
-
oriented middleware

(MOM), which refer to platforms based
on object
-
oriented, event
-
oriented and message
-
oriented computational models,
respectively. Among them, the object
-
based platforms are of the most intere
st now. Some
examples of the object
-
based platforms are the OMG’s CORBA, Microsoft’s DCOM
and .NET or Java
-
based series of technologies (RMI, Jini, and EJB).


2.2

What does reflection means


Abstractly, reflection refers to the capability of a system to reason

about and act upon
itself. More specifically, a reflective system is one that provides a representation of its
own behavior that is amenable to inspection and adaptation, and is causally connected to
the underlying behavior it describes. "Causally
-
connect
ed" means that changes made to
Reflective Middleware


Hailiang Mei, TU/e



Page
3

of
15

the self
-
representation are immediately mirrored in the underlying system’s actual state
and behavior, and vice
-
versa. Therefore, a reflective system should support the causally
connected self
-
representation (CCSR). For adapt
ation, it refers to the possibility of
changing the underlying structure or modifying the real state data.


2.3

What is Reflective Middleware

Reflection enables both
inspection

and
adaptation

of systems at run time. Inspection
allows the current state of the s
ystem to be observed and adaptation allows the system’s
behavior to be altered at run time to better match the system’s current operating
environment. An example of inspection is to determine the currently configured garbage
collection policy. The current
operating environments include the systems is being
debugged, is operating in a real
-
time environment or in a secure environment etc.

Inspection and adaptation are the essential aspects of a reflective system. But we need to
point out that sometimes the sy
stem is also called reflective while inspection is provided
but not adaptation. An example is Java’s java.lang.reflection package which is of
particular interest because Java is possibly the most widely known environment in which
reflective techniques have

been applied. Briefly, Java’s reflective facilities allow the
programmer to extract, at run time, the names of methods in some target class together
with the types of their arguments and return values. This makes it possible to write code
that can call me
thods in objects whose class was not known to the programmer when the
program was written. Now, in comparing this sort of capability with our CCSR based
definition of reflection, it is clearly seen that Java is not ‘fully’ reflective in our sense.
Because
only inspection is supported by this package and the real adaptation cannot be
done yet.


Therefore, a concise concept of reflective middleware in general can be defined as:
Reflective Middleware

is simply a middleware system that provides inspection and
adaptation of its behavior through an appropriate CCSR (
[1]
).
Microsoft’s
COM/DCOM can be a good example of Reflective Middleware, because DDL is the
major part to consist component and it can be dynamically changed or updated.


2.4

Importance of reflective middleware

Why should middleware be reflective? The most general answer to this question is that
reflection does for middleware what it does for any system: it makes it more adaptable to
its environment and better able to cope wit
h changes. In a middleware context, the need
to cope with change particularly arises when middleware based applications are deployed
in dynamic environments such as multimedia, group communication, real
-
time and
embedded environments, handheld devices and
mobile computing environments.

Moreover, the precise description of reflective mechanism is helpful on implementations
of remote controlling and fault tolerance. Because those extended functionalities require
suitable handles to collect necessary data and

interfaces in reflective middleware seem to
be good candidate as the handle.

Reflective Middleware


Hailiang Mei, TU/e



Page
4

of
15

2.5

An example of reflective middleware functioning

Here is an example from the area of mobile multimedia computing. Distributed
multimedia applications running in a mobile environ
ment are often subject to widely
varying QoS from the underlying infrastructure. For example, they may receive a high
throughput, low delay service when the mobile host is plugged into an office network
outlet but receive significantly lower quality connec
tivity when the user is on the move
and the terminal must communicate over wireless channel.

In the work at Lancaster University, researchers have applied the concept of reflection to
such scenarios by providing a component
-
based CCSR for the communicatio
ns path
traversed by packets in a multimedia middleware environment. More specifically, they
model the communications path as a graph of nodes (representing components such as
protocol layers and compression filters) and links (representing bindings betwee
n
components). Through this CCSR they can insert monitoring components into the data
path and thus detect when the connection quality changes in significant ways. They can
then adapt to such changes by manipulating the graph and thereby, via the property o
f
causal connection, adapting the underlying delivery system. For example, we can insert a
more aggressive compression component to a video connection when moving to a slower
network or add a jitter
-
smoothing buffer to an audio connection when moving to a

network with erratic delay characteristics.

3

Related works


3.1

CodA (
[2]
)


Pioneering work in the general area of reflection in distributed systems was carried out by
Jeff McAffer, who developed the CodA platform, which features ext
ensive support for
behavioral reflection through the reification of several facets of communication. There is
also now a growing corpus of work in the area of reflective middleware.


3.2

Open ORB2 (
[3]
)


Open ORB is
a
reflective
,
component
based middleware platform developed at Lancaster
University. The Open ORB architecture builds on two complementary technologies:
components and reflection. Before going to detail, we first take a look at the general
function of ORB
in CORBA.


3.2.1

Basic idea of ORB in CORBA


ORB stands for
Object Request Broker

in CORBA architecture. In CORBA, IDL is
compiled into client stubs and object skeletons. Stubs and skeletons serve as proxies for
clients and servers, respectively.


Because IDL de
fines interfaces so strictly, the stub on
the client side has no trouble meshing perfectly with the skeleton on the server side, even
if the two are compiled into different programming languages, or even running on
different ORBs from different vendors.


Reflective Middleware


Hailiang Mei, TU/e



Page
5

of
15


In CORBA, every object instance has its own unique
object reference
, an identifying
electronic token. Clients use the object references to direct their invocations, identifying
to the ORB the exact instance they want to invoke (Ensuring, for example, that
the books
you select go into your own shopping cart, and not into your neighbor's.) The client acts
as if it's invoking an operation on the object instance, but it's actually invoking on the
IDL stub which acts as a proxy. Passing through the stub on the c
lient side, the invocation
continues through the ORB, and the skeleton on the implementation side, to get to the
object where it is executed.


Figure
2

An object request in CORBA architecture
[4]
1



3.2.2

Ope
n ORB architecture


In Open ORB 2 architecture, a component is defined as "a unit of composition with
contractually specified interfaces and explicit context dependencies only."(
[5]
) In
addition, a component "can be deployed ind
ependently and is subject to third
-
party
composition."



The main features of the component model, which is designed to support multimedia
programming, are:



Components are described by a set of required and provided interfaces.



Interfaces for continuous m
edia interaction are supported.



Explicit bindings can be created between compatible interfaces i.e. where the
defined required and provided interfaces match.



Components offer a built in event
-
notification facility.


This model provides access to the underl
ying platform

and by implication the
associated component structure

through reflection. In particular, every application
-
level
component offers a meta
-
interface that provides access to an underlying metaspace,
which is the support environment for the compo
nent.
(Too general, how the metaspace
works for the purpose of reflection is not clear yet)

Metaspace is itself composed of
components. Such metalevel components also have a meta
-
interface that offers access to
their support environment. This approach is t
herefore recursive, potentially leading to
infinite towers of reflection. To overcome the problem of infinite towers, this model



1

IDL is to CORBA what HTML is to the WWW; IIOP is to CORBA what HTTP is to
the WWW.

Reflective Middleware


Hailiang Mei, TU/e



Page
6

of
15

instantiates metacomponents on demand; unless accessed, they exist in theory but not in
practice.


In this design, metaspace is

partitioned into several distinct metaspace models. The
benefit of this approach is to simplify the interface the metaspace offers by separating
concerns between different system aspects. This is particularly important in distributed
systems given the wid
e range of concerns that must be considered (in comparison to
designing a single language, for example).
Figure
3

illustrates the structure of metaspace.


Figure
3

The structure of metaspace in Open ORB v2


Generally, the metaspace contains two models: metaspace models for structural reflection
and metaspace models for behavioral reflection.


In reflective systems, structural reflection deals with the content and structure of a given
component. In this arc
hitecture, this aspect of metaspace is represented by two distinct
metamodels, namely the interface and architecture metamodels. The two metamodels
represent a separation of concerns between the external view of a component (its set of
interfaces) and the
internal construction (its software architecture).


Meanwhile, behavioral reflection deals with activity in the underlying system. Open ORB
distinguishes between actions taking place in the system and the resources required to
support such activity. These
two aspects are represented by the interception and resources
metamodels.


3.3

DynamicTAO middleware platform
[6]


3.3.1

TAO, ACE and Dynamic TAO


TAO

(
The ACE ORB
) is developed based on
ACE

components framework and ACE is a
freely availa
ble, open
-
source object
-
oriented (OO) framework that implements many core
Reflective Middleware


Hailiang Mei, TU/e



Page
7

of
15

patterns for concurrent communication software.
TAO is a portable, flexible, extensible,
and configurable ORB that conforms to the CORBA standard and utilizes a
strategy
design patte
rn

(
[8]
) to encapsulate different aspects of the ORB internal engine. TAO
contains a configuration file that specifies the strategies the ORB uses to implement
aspects like concurrency, request de
-
multiplexing, s
cheduling, and connection
management. When the ORB is initiated, the configuration file is parsed and the selected
strategies are loaded. Notably, TAO is mainly used in static real
-
time applications.


DynamicTAO

extends TAO to support on
-
the
-
fly reconfigur
ation; this is achieved by
reifying DynamicTAO’s internal structure, i.e., keeping an explicit representation of the
ORB internal components and of the dynamic interactions (binding or dependencies)
among them. The reification allows the ORB to change spec
ific strategies without having
to restart its execution.


3.3.2

DynamicTAO’s reification


DynamicTAO

is reflective because it allows inspection and adaptation of its internal
engine. It achieves this by exporting an interface for (1) transferring components acr
oss
the distributed system, (2) loading and unloading modules into the ORB runtime, and (3)
inspecting and modifying the ORB configuration state.


Furthermore, reification in DynamicTAO is achieved through a collection of entities
known as component confi
gurators. A component configurator maintains the
dependencies between a component and other system components (
The knowledge of
self
-
model, which could be accessible from outside of the terminal
). Each process
running the
DynamicTAO

ORB contains a componen
t configurator instance called the
DomainConfigurator
, which is responsible for maintaining references to instances of the
ORB and to servants running in that process. In addition, each instance of the ORB
contains a customized component configurator calle
d the
TAOConfigurator
that contains
hooks to which implementations of D
ynamicTAO

strategies are attached. Hooks work as
“mounting points” where specific strategy implementations are made available to the
ORB.
Figure
4

illustrates t
he reification mechanism within a process containing a single
instance of the ORB.

Reflective Middleware


Hailiang Mei, TU/e



Page
8

of
15


Figure
4

DynamicTAO Component Configurator


DynamicTAO is an extension of the C++ TAO ORB, enabling on
-
the
-
fly reconfiguration
of the ORB internal

engine and of applications running on top of it. In DynamicTAO,
component configurators represent the dependence relationships between ORB
components and between ORB and application components. A component configurator is
a C++ object that stores the depe
ndencies as lists of references, pointing to other
component configurators, creating a directed dependence graph of ORB and application
components as shown in Figure 4.


Here is an example to show how the component configurator works. When a request for
re
placing a component C arrives, the middleware examines (
then, what?
) the dynamic
dependencies between C and other middleware and application components using the
component configurator object associated with C. Programmers can extend the
component configur
ator class by inheritance to provide customized implementations
dealing with different kinds of components. Middleware developers use this feature to
write the code that takes the proper actions to guarantee the consistency of the ORB
internal structure in

the presence of dynamic reconfigurations. DynamicTAO supports
(
how?)

safe dynamic reconfiguration of the middleware components that control
concurrency, security, and monitoring.


3.3.3

DynamicTAO framework


The
DynamicTAO

architectural framework is depicted i
n
Figure
5
. The
Persistent
Repository
stores category implementations in the local file system. Once a component
implementation is stored in the local repository, it can be dynamically loaded into the
process runtime. A
Network Bro
ker
receives reconfiguration requests from the network
and forwards them to the
Dynamic Service Configurator
. The latter contains the
Reflective Middleware


Hailiang Mei, TU/e



Page
9

of
15

DomainConfigurator

(
Figure
4
)

and supplies common operations for dynamic
configuration of compone
nts at runtime.



Figure
5

DynamicTAO component framework


We can see that DynamicTAO achieve this adaptation through the use of configurators
that maintain dependencies among components and provide a set of hooks for the
attachme
nt or detachment of components dynamically. They are also currently interested
in configurability of platforms for mobile devices (the LegORB Project). In associated
work, they have developed a task control model to support QoS management in their
platform
s. In general, reflection is fairly realized in their approach by supporting the
customization of key parts of the platform.


Similar to Open ORB, DynamicTAO exports a meta
-
interface for loading and unloading
modules into the system runtime, and for inspec
ting and changing the ORB configuration
state. This meta
-
interface can be accessed by developers for debugging and testing
purposes, by system administrators for maintenance purposes, or by other software
components that can inspect and reconfigure the int
ernals of the ORB based on
information collected from other sources, such as resource utilization monitors [6]. In
addition, to support the reconfiguration of a large collection of distributed ORBs,
DynamicTAO exports a similar meta
-
interface for mobile ag
ents. In this case, system
administrators use a graphical interface to build mobile agents and inject them in the
Reflective Middleware


Hailiang Mei, TU/e



Page
10

of
15

network; the agents travel from ORB to ORB, inspecting and reconfiguring them
according to the instructions the administrator programmed.


3.3.4

Res
earch trend on TAO


Firstly, the robustness will be increased. Researchers are enhancing TAO to support the
coming CORBA Fault Tolerance specification, which defines policies and mechanisms to
ensure that client applications are largely insulated from mana
gement of redundant copies,
failure masking, and recovery. TAO's ORB
-
level fault
-
tolerance features are also being
integrated with higher
-
level services provided by DOORS (
[12]
) and Eternal (
[13]
).


Secondly, new features are still being added to ACE+TAO, for example, supports for the
complete Real
-
time CORBA, Messaging, and CORBA Security Service. Moreover,
selected part of the CORBA Component Model (CCM) that pertains to high
-
performance
and real
-
ti
me computing systems is going to be implemented.


3.4

Universally Interoperable Core (UIC)
[9]


The Universally Interoperable Core (UIC) is a reflective middleware infrastructure
designed to support ubiquitous computing environment
s, addressing the problems that
other middleware platforms have in this area. UIC is a collection of components designed
to follow the principles introduced in the previous sections.


UIC aims at personal devices and permits customization of the skeleton
(both statically
2

and dynamically
3
) for heterogeneous devices and environments. The possible
configurations range from minimal functionality versions with minimal memory and
resource requirements to fully functional versions.


Two key principles drive the

design of UIC

simplicity and What You Need Is What
You Get. The simplicity principle requires a clear and easy to understand decomposition
of the UIC into modules (components). The modular design provides separation of
concerns and encapsulates the mechan
isms required for each specific task in different
components. This modularity minimizes unwanted dependencies, therefore allowing easy
customization. The second principle, WYNIWYG, requires that only the required
functionality is present in an instance of
the UIC.


It is important to note that this customization in UIC is rather broader, or more than we
expect. It applies to the implementation of the components, the interfaces, and the
structure of the skeleton. Therefore, while the UIC defines a standard
skeleton structure
targeted to object
-
oriented request brokers (CORBA, Java RMI, and DCOM), nothing
prevents the application developer from changing the structure to meet other
requirements (for example, non object
-
oriented RPC platforms and RTP streaming)
.





2

Rebuilding the UIC with the new f
unctionality

3

Adding/removing the new/old functionality at runtime, which needs more resources

Reflective Middleware


Hailiang Mei, TU/e



Page
11

of
15

3.4.1

Personality in UIC


The UIC is an abstract entity that must be specialized to meet the particular application's
requirements. This specialization defines the core's behavior and determines the type of
entities with which it will be able to interact (fo
r example, CORBA servers or Java RMI
servers). The term of personality is used to refer to the particular instance of the UIC
obtained after the specialization.


Personalities can be classified as client
-
side, server
-
side, or both, depending on the
functio
nality they provide. A client
-
side personality provides functionality to send
requests and receive replies, while a server side
-
personality is capable of receiving
requests and sending replies. This classification can be mapped directly to devices that
sim
ply need to access remote functionality, devices that need to export functionality, and
devices that require both.



Figure
6

Personalities


The UIC can be classified as single
-
personality and multipersonality. A single
-
personali
ty UIC is capable of interacting with a single middleware platform, while a
multi
-
personality UIC can interact with more than one platform at the same time. Note,
however, that a multi
-
personality UIC is not equivalent to having a collection of single
-
pers
onality UICs. Having several single
-
personality UICs implies that applications have
to decide which UIC personality to use depending on the object they want to interact with.
On the other hand, with multi
-
personality UICs, applications always use the same
UIC
instance and the same method invocation interface regardless of the type of the remote
object. In this last case, the UIC is responsible for automatically choosing the right
personality.





3.4.2

UIC Multipersonality Core


Reflective Middleware


Hailiang Mei, TU/e



Page
12

of
15

The UIC Multipersonality Core is o
ne specialization of the UIC that provides reflection
tools. These tools let us inspect the internal architecture of the Multipersonality Core and
also introduce modifications in the Core. As in the case of DynamicTAO, reflection is
applied to the dependen
cies among the components that compose the Multipersonality
Core (Component Configurator pattern). Therefore, changes on those dependencies are
translated into changes on the Multipersonality Core's behavior. For example, attaching
SOAP specialized compone
nts to a multipersonality core leads to a behavior change of
the ORB, allowing it to interact with SOAP objects. Due to the diversity of functional
aspects, it is important to make sure that the type of a component matches the type of the
hook where it is
attached. We can achieve this by using runtime type information.


Figure
7

illustrates the Multipersonality Core's architecture, which is divided into two
parts: the
Core Configuration

and the
Dynamic Configurator
(dynamic reconfig
uration
tool). The Core Configuration is the collection of UIC components that defines the
Multipersonality Core's behavior. The Dynamic Configurator implements the reflective
mechanisms and stores the information about dependencies among components. The
D
ynamic Configurator is implemented as a servant object that runs on top of the current
Multipersonality Core configuration. This approach contains two main advantages:




It allows dynamic modification of the reflective mechanisms using different
instances
of the Dynamic Configurator.



It registers the same Dynamic Configurator servant with more than one
personality at the same time, therefore allowing different types of clients (for
example, CORBA and SOAP) to reconfigure the Core.


Figure
7

The UIC Multipersonality Core


3.5

K
-
ORB
[10]


K
-
ORB is the general term used to describe a family of customized and confi
gurable
ORBs that are based on the minimumCORBA specification being developed at Trinity
College, Dublin. K
-
ORBs are instantiations of a minimumCORBA (a subset of OMG's
CORBA 2.2 specification that is targeted at resource constrained environments)
Reflective Middleware


Hailiang Mei, TU/e



Page
13

of
15

framewor
k that allows developers to build ORBs for domains such as embedded systems,
PDAs, intelligent devices and real
-
time systems.


The K
-
ORB framework is an extension of the Mobile IIOP Engine developed in the Alice
Project (
[11]
).

The K
-
ORB framework allows developers to build ORBs where the
environment and set of resources available to the ORB are subject to change at runtime.
Mobile devices, for example, use the dynamic reconfiguration of the network protocol to
select the most a
ppropriate underlying network transport at runtime. For example, when a
PDA with a GSM modem disconnects from the fixed network (an Ethernet or Wireless
Ethernet connection), its transport protocol is dynamically reconfigured to Mobile IIOP
(TCP/IP over GS
M) to enable CORBA clients and servers on the PDA to recommence
communication with hosts on the fixed network. Similarly, when a PDA with a GSM
modem connects from the fixed network, its transport protocol is dynamically
reconfigured from Mobile IIOP to II
OP to provide higher bandwidth connections for
CORBA clients and server on the PDA.



Figure
8

K
-
ORB reference architecture


Reflective Middleware


Hailiang Mei, TU/e



Page
14

of
15

4

Summary


Within this paper, the concept of reflective middleware and its importance to our works
are desc
ribed. Then, several related works are introduced. To our interest, we found most
of the works done so far are based on CORBA architecture, although CORBA is rather
complicated and with less interoperability. Another problem is being faced is that the
defi
nitions of component in the above
-
mentioned CORBA
-
based project are not unified
yet. Generally speaking, the component in CORBA is corresponding with the “service” in
Robocop project. In the other words, the concept of component in CORBA is smaller
than th
e one in Robocop.


DynamicTAO seems to be the most valuable design among all the mentioned projects. It
defines a clear architecture and related mechanisms and its future developments include
fault tolerance specification and CORBA Component Model (CCM). T
he materials on
Open
-
ORB and K
-
ORB are too general or too few to give a clear understand. The first
one emphasizes adding meta
-
space module to extend the functionality of ORB
framework, and the latter one is built up based on the minimum version of CORBA.
The
configurable personality makes UIC a more flexible framework, which offers the
optimized component setting and requires more modification when the environment is
changed. A comparison among three major architectures (projects) is presented in the
table

below.



DynamicTAO

Open ORB

UIC

Keywords

Reification

Metaspace

Personality

Main concerning

Explicit internal
description

Good reflective
architecture and
interface

Simplicity and
WYNIWYG

Basic architecture

CORBA

CORBA

Object oriented
middleware (bit
b
roader than
CORBA)

Reflection

Inspection and
adaptation

Inspection and
adaptation

Inspection and
adaptation

Development status

Still going

Stop

Stop

Component oriented

High

High

Middle

Resource quality

High

Middle

High

Table
1

Comparison among three Reflective middleware architecture


The next step of this research could be focus on the corresponding relationship between
Robocop and CORBA, and then we could try to implement part of the reflective idea in
CORBA into Robocop to ex
tend the functionality of it.


5

Reference

[1]

Geoff Coulson, “what is Reflective Middleware”,
http://dsonline.computer.org/middleware/RMarticle1.htm
, 8
th

August, 2003.

Reflective Middleware


Hailiang Mei, TU/e



Page
15

of
15

[2]

Jeff McAffer, Documen
tations of Coda architecture,
http://web.yl.is.s.u
-
tokyo.ac.jp/members/jeff/research/availdoc.html#coda
, 8
th

August, 2003.

[3]

Gordon S. Blair, Geoff Coulson, Anders And
ersen, “The Design and
Implementation of Open ORB 2”,
http://dsonline.computer.org/0106/features/bla0106_print.htm
, 8
th

August, 2003.

[4]

CORBA FAQ,
http://www.omg.org/gettingstarted/corbafaq.htm
, 10
th

August,
2003.

[5]

Szyperski, C. “Component Software, Beyond Object
-
Oriented Programming”,
ACM Press/Addison
-
Wesley, 1998.

[6]

Kon, F., Roman, M., Liu, P., Mao, J., Yamane, T., Maga
lhaes, L., and Campbell,
R. "Monitoring, Security, and Dynamic Configuration with the DynamicTAO
Reflective ORB", in Proceedings of the Middleware 2000 Conference, ACM/IFIP,
April 2000.

[7]

Overview of ACE,
http://www.cs.wustl.edu/~schmidt/ACE
-
overview.html
, 20
th

August 2003.

[8]

Gamma, E., Johnson, R., Helm, R. and Vlissides, J. “Design Patterns: Elements of
ReusableObject
-
Oriented Software”, Addison
-
Wesley, 1995.

[9]

Roman, M., Kon, F., Campbell, R.,

“Reflective Middleware: From Your Desk to
Your Hand”,
http://dsonline.computer.org/0105/features/rom0105_print.htm
, 20
th

August 2003.

[10]

K
-
ORB,
http://www.dsg.cs.tcd.ie/research/minCORBA/currentWork.html
,
Trinity
College, Dublin, 22
nd

August 2003.

[11]

Haahr, M., Cunningham, R. and Cahill, V. “Towards a Generic Architecture for
Mobile Object
-
Oriented Application
s”, SerP 2000: Workshop on Service
Portability. San Francisco, December 2000.

[12]

DOORS,
http://www.cs.wustl.edu/~schmidt/corba
-
research
-
reliable.html
, 20
th

August 2003.

[13]

Eternal sys
tem,
http://alpha.ece.ucsb.edu/eternal/Eternal.html
, 20
th

August 2003.