Post on 04-Jan-2016
transcript
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
330/05/2006 .NET Technologies 2006
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
430/05/2006 .NET Technologies 2006
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
530/05/2006 .NET Technologies 2006
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?
630/05/2006 .NET Technologies 2006
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
730/05/2006 .NET Technologies 2006
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
830/05/2006 .NET Technologies 2006
Contents
> Background & Motivation
> Search Agents case study
> OOAttachments approach
> Conclusions
930/05/2006 .NET Technologies 2006
> 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
1030/05/2006 .NET Technologies 2006
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)
1130/05/2006 .NET Technologies 2006
Contents
> Background & Motivation
> Search Agents case study
> The OOAttachments approach
> Conclusions
1230/05/2006 .NET Technologies 2006
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
1330/05/2006 .NET Technologies 2006
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
1430/05/2006 .NET Technologies 2006
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)
1530/05/2006 .NET Technologies 2006
How it works: Communication
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
1630/05/2006 .NET Technologies 2006
How it works: Communication
> 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%
1730/05/2006 .NET Technologies 2006
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
1830/05/2006 .NET Technologies 2006
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
1930/05/2006 .NET Technologies 2006
Contents
> Background & Motivation
> Search Agents case study
> The OOAttachments approach
> Conclusions
2030/05/2006 .NET Technologies 2006
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
2130/05/2006 .NET Technologies 2006
Questions