Transparent Mobility of Distributed Objects using.NET Cristóbal Costa, Nour Ali, Carlos Millan,...

Transparent Mobility of Distributed Objects using .NET

Cristóbal Costa, Nour Ali, Carlos Millan, Jose A. Carsí

4th International Conference in Central Europe on .NET Technologies

230/05/2006 .NET Technologies 2006

Contents

> Background & Motivation

> Search Agents case study

> OOAttachments approach

> Conclusions


Background

> Previous work in Component-Based Aspect-Oriented Software Architectures

> A characteristic is that the components neglect distributed nor local references of their partners

> Transparent entities called Attachments are responsible of:

Interconnecting components Providing transparent mobility and communication

Node2Node1

Component1

Attachments

Component2


Motivation

> To transfer previous experience in attachments to connect objects, instead of aspect-oriented components

> To provide a library to support the development of transparent mobility of distributed objects

> These features must be provided: A non intrusive and transparent way of programming Code should not be precompiled nor preprocessed Efficiency


Motivation

> For example, it can be used by Client & Server architectures to manage both location changes in a transparent way

ServerClient

> Why the client object has to worry about its server?


State of the art

> This problem has been dealt in Mobile Agent SystemsMost of them are built on Java:

Aglets, Nomads, MobJeX, Voyager, JADE, ProActive, …

> There are few approaches on .NET but still in development

MAPNET, Nomad, EtherYatri.NET

> Common characteristics of these approaches: Agents are defined by means of inheritance. In most of them, the agent has to define all its functionality in one

method (usually “Run”) with a specific signature Events are captured by overriding inherited methods Communication among agents is realized: by using generic proxies

(like “AgentProxy”), by passing messages, or by implementing specific services


Strong vs Weak Mobility

In order to implement strong mobility the ability of thread serialization is required.

Two main alternatives:

By extending the Framework (e.g. JavaThreads [Bouchenak03])

New releases of the Framework would make it useless

By preprocessing the source or binary code (e.g. Brakes [Truyen00]) Less eficiency

The programmer must take care of their processes

Agent processes are interrupted in a transparent way

Weak MobilityStrong Mobility

It is the programmer who saves processes information before moving and restores it after moving.

As no customization is needed, the solution is more portable


Contents



> OOAttachments approach

> Conclusions


> Our solution: to send only a few agents capable of establishing transparent mobile communications

Network resources are not overloaded, as there only are a few agents travelling through the network

Agents can exchange new subsearches without realizing where the others are

They are completely autonomous: they only come back with the results, so the sender could have been disconnected during the process (e.g. mobile clients)

> There are a lot of resources over the Internet from which we want to collect distributed information

> The search grows as a tree, so we need to be able to explore the resources dynamically in a distributed way

SearchAgents case study

BE C

D

A


SearchAgent implementation

> The inheritance is not limited: we do not have to inherit from a specific class to benefit from mobility

> By this way, an object is made remotely accessible to others

> A specific interface can be specified to restrict offered services

> An object obtains a reference of a remote object by specifying its ID and current location

> The remote reference is a transparent proxy that provides all the remote methods

> By this way, an object moves itself to another host

> There are no need to use specific methods and signatures for being called when object mobility finishes

> Parameters can also be provided (e.g. for providing initialization information)


Contents



> The OOAttachments approach

> Conclusions


The OOAttachments approach

> Features: Objects can move autonomously among computers without

having to take into account how distributed communications with other objects are performed

Since a connection is established, location-awareness is provided No need for a centralized infrastructure to manage mobility and

object registration services Dynamic code generation and reflection is combined in order to

be able of calling code dynamically, so code precompilation is not needed

> Constraints: Weak mobility is provided, so objects must take care of their threads

before moving In order to establish the first connection, a client object needs to

know where the server object is located Each mobile object must be marked as Serializable The middleware must be running in each computer


The OOAttachments approach

> Objects are connected through entities called Attachments

SearchAgent 2

SearchAgent 1

Host A Host B

Server behaviour: It offers the “NotifyNewLocation” service

Client behaviour: It invokes “NotifyNewLocation”

Attachment

AttachmentServerMediator

methodsList: Delegate[]

RegisterClient(attClientURL) : MethodInfo[1..*]UnRegisterClient(attClientURL) : voidRedirectService(methodID, args) : object

AttachmentServer

objectName: string«NonSerialized» objRef: objectobjType: TypeattClientsURLs: string [0..*] (ArrayList)serverIsMoving: bool

AttachmentServer(objRef, objectName, objType)BeginServerMobility() : voidEndServerMobility(objectReference) : void

[Serializable]

MarshalByRefObject1[NonSerialized]

«generated-code»Serv er-AttClient

IDeserializationCallback

AttachmentClient

methodInformation: MethodInfo [1..*]parentType: stringserverURL: stringserviceIsConsuming: bool[]

Process(methodID, args) : objectBeginClientMobility() : voidEndClientMobility() : voidStopProcessingServices() : void

AttachmentClientMediator

ServerMobilityBegan() : voidServerMobilityEnded(newURL) : void

MarshalByRefObject

[Serializable]

[Serializable]

1[NonSerialized]

1

Server behaviour: provided by the AttachmentServer

Client behaviour: provided by the AttachmentClient

Object layer

Attachments layer

.NET Remoting layer

> Attachments are created through the AttachmentsManager class


How it works: Communication

SearchAgent 2

SearchAgent 1

Host A Host B

Attachment

AttachmentServ erMediator

methodsList: Delegate[]

RegisterClient(attClientURL) : MethodInfo[1..*]UnRegisterClient(attClientURL) : voidRedirectService(methodID, args) : object

AttachmentServ er

objectName: string«NonSerialized» objRef: objectobjType: TypeattClientsURLs: string [0..*] (ArrayList)serverIsMoving: bool

AttachmentServer(objRef, objectName, objType)BeginServerMobility() : voidEndServerMobility(objectReference) : void

[Serializable]

MarshalByRefObject1[NonSerialized]

> Server-behaviour is defined by the AttachmentServer object

Incoming request services are forwarded towards the server object

It notifies about mobility to its connected objects

One entity is serializable (Marshal By Value), so its state can be migrated, and the other is accessible remotely (Marshal By Reference)

> Server-behaviour is defined by the AttachmentServer object

Incoming request services are forwarded towards the server object

It notifies about mobility to its connected objects

One entity is serializable (Marshal By Value), so its state can be migrated, and the other is accessible remotely (Marshal By Reference)



SearchAgent 2

SearchAgent 1

Host A Host B

Attachment

> Client-behaviour is defined by the AttachmentClient object

> Composed by: A runtime generated proxy (MSIL) of the

remote object A remote accessible object which allows

to be notified about server mobility A serializable object that

manages the attachmentClient state, forwards services to the attachmentServer

> Client-behaviour is defined by the AttachmentClient object

> Composed by: A runtime generated proxy (MSIL) of the

remote object A remote accessible object which allows

to be notified about server mobility A serializable object that

manages the attachmentClient state, forwards services to the attachmentServer

«generated-code»Serv er-AttClient

IDeserializationCallback

AttachmentClient

methodInformation: MethodInfo [1..*]parentType: stringserverURL: stringserviceIsConsuming: bool[]

Process(methodID, args) : objectBeginClientMobility() : voidEndClientMobility() : voidStopProcessingServices() : void

AttachmentClientMediator

ServerMobilityBegan() : voidServerMobilityEnded(newURL) : void

MarshalByRefObject

[Serializable]

[Serializable]

1[NonSerialized]

1



> Inter-object communication is a very frequent operation: it must be as faster as possible

> Communication is established dynamically on demand, so dynamic code invocation must be used Its performance is:

Reflection < Delegates << Direct Calls (code generation)

> We dynamically generate code on establishing a connection in order to reduce these costs

> Total introduced communication costs: 3 direct calls + 1 dynamic invocation (through delegates) ≈ +11%


How it works: Mobility

> The MoveObject service performs several steps: The object to be moved and its communication processes

(attachments) are packaged in a MobilityPackage object This is serialized and transferred to the target host Before unpacking, it is checked whether the required assemblies are

available. If not, they are downloaded from the source host The information is unpacked and, when communication processes

are restored, the transferred object runs by invoking its specified method

If anything fails, all information is restored properly

> Simultaneous mobility is also supported An object can move to another host while other objects, that are

connected to it, are being moved at the same time

> The mobility process depends on the role of the object to be moved


How it works: Mobility

> Client behaviour: If it has service requests being processed, the mobility process waits

until they finish properly (weak mobility) When mobility finishes, object state is restored, including its

connections with remote objects

> Server behaviour: Before moving, pending requests from client objects must

finish first New requests from client objects are blocked (at the attachment

level) until mobility finishes. When mobility finishes, all communication processes are restored

and client requests are processed


Contents



> The OOAttachments approach

> Conclusions


Conclusions & Future work

> An application can be easily adapted to benefit from these features:

Objects do not have to take into account what communication technology is used

Objects benefit from transparent (weak) mobility and distributed communications in a non-intrusive way

After establishing a connection, location-awareness of connected objects is provided

> Further work: Adaptability to Service-Oriented infrastructures, such as WCF To provide security features to validate incoming code, such as by

signing assemblies and by establishing trusted relations

> OpenSource project home page: http://workspaces.gotdotnet.com/OOAttachments


Questions

Transparent Mobility of Distributed Objects using.NET Cristóbal Costa, Nour Ali, Carlos Millan,...

Documents

Transcript of Transparent Mobility of Distributed Objects using.NET Cristóbal Costa, Nour Ali, Carlos Millan,...