Transcript B19 - NET Technologies

4th International Conference in Central Europe
on .NET Technologies
Transparent Mobility of
Distributed Objects using .NET
Cristóbal Costa, Nour Ali, Carlos Millan, Jose A. Carsí
Contents
> Background & Motivation
> Search Agents case study
> OOAttachments approach
> Conclusions
30/05/2006
.NET Technologies 2006
2
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
Node1
Node2
Component1
Component2
Attachments
30/05/2006
.NET Technologies 2006
3
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
30/05/2006
.NET Technologies 2006
4
Motivation
> For example, it can be used by Client & Server
architectures to manage both location changes in a
transparent way
> Why the client object has to worry
about its server?
Client
30/05/2006
Server
.NET Technologies 2006
5
State of the art
> This problem has been dealt in Mobile Agent Systems
Most 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
30/05/2006
.NET Technologies 2006
6
Strong vs Weak Mobility
Strong Mobility
Weak Mobility
Agent processes are interrupted in
a transparent way
The programmer must take care
of their processes
In order to implement strong mobility
the ability of thread serialization is
required.
It is the programmer who saves
processes information before moving
and restores it after moving.
Two main alternatives:
As no customization is needed, the
solution is more portable
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
30/05/2006
.NET Technologies 2006
7
Contents
> Background & Motivation
> Search Agents case study
> OOAttachments approach
> Conclusions
30/05/2006
.NET Technologies 2006
8
SearchAgents case study
> 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
A
E
D
B
C
> 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)
30/05/2006
.NET Technologies 2006
9
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)
>
30/05/2006
.NET Technologies 2006
10
Contents
> Background & Motivation
> Search Agents case study
> The OOAttachments approach
> Conclusions
30/05/2006
.NET Technologies 2006
11
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
30/05/2006
.NET Technologies 2006
12
The OOAttachments approach
> Objects are connected through entities called
Attachments
Host A
[Serializable]
«generated-code»
Serv er-AttClient
IDeserializationCallback
Search
Agent 1
1
[Serializable]
AttachmentClient
Host B
[Serializable]
AttachmentServ er
Attachment
objectName: string
«NonSerialized» objRef: object
objType: Type
attClientsURLs: string [0..*] (ArrayList)
serverIsMoving: bool
methodInformation: MethodInfo [1..*]
parentType: string
serverURL: string
serviceIsConsuming: bool[]
AttachmentServer(objRef, objectName, objType)
BeginServerMobility() : void
EndServerMobility(objectReference) : void
Process(methodID, args) : object
BeginClientMobility() : void
EndClientMobility() : void
StopProcessingServices() : void
1
[NonSerialized] 1
MarshalByRefObject
AttachmentServ erMediator
[NonSerialized]
methodsList: Delegate[]
MarshalByRefObject
AttachmentClientMediator
RegisterClient(attClientURL) : MethodInfo[1..*]
UnRegisterClient(attClientURL) : void
RedirectService(methodID, args) : object
ServerMobilityBegan() : void
ServerMobilityEnded(newURL) : void
Client behaviour:
It invokes “NotifyNewLocation”
Client behaviour:
provided by the AttachmentClient
Search
Agent 2
Object layer
Server behaviour:
It offers the “NotifyNewLocation” service
Attachments layer
Server behaviour:
provided by the AttachmentServer
.NET Remoting layer
> Attachments are created through the AttachmentsManager class
30/05/2006
.NET Technologies 2006
13
How it works: Communication
Host A
Search
Agent 1
Attachment
> 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)
30/05/2006
Host B
.NET Technologies 2006
Search
Agent 2
[Serializable]
AttachmentServ er
objectName: string
«NonSerialized» objRef: object
objType: Type
attClientsURLs: string [0..*] (ArrayList)
serverIsMoving: bool
AttachmentServer(objRef, objectName, objType)
BeginServerMobility() : void
EndServerMobility(objectReference) : void
[NonSerialized]
1
MarshalByRefObject
AttachmentServ erMediator
methodsList: Delegate[]
RegisterClient(attClientURL) : MethodInfo[1..*]
UnRegisterClient(attClientURL) : void
RedirectService(methodID, args) : object
14
How it works: Communication
Host A
Attachment
Search
Agent 1
[Serializable]
«generated-code»
Serv er-AttClient
IDeserializationCallback
1
[Serializable]
AttachmentClient
methodInformation: MethodInfo [1..*]
parentType: string
serverURL: string
serviceIsConsuming: bool[]
Process(methodID, args) : object
BeginClientMobility() : void
EndClientMobility() : void
StopProcessingServices() : void
1
Host B
[NonSerialized]
MarshalByRefObject
AttachmentClientMediator
Search
Agent 2
> 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
ServerMobilityBegan() : void
ServerMobilityEnded(newURL) : void
30/05/2006
.NET Technologies 2006
15
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%
30/05/2006
.NET Technologies 2006
16
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
30/05/2006
.NET Technologies 2006
17
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
30/05/2006
.NET Technologies 2006
18
Contents
> Background & Motivation
> Search Agents case study
> The OOAttachments approach
> Conclusions
30/05/2006
.NET Technologies 2006
19
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
30/05/2006
.NET Technologies 2006
20
Questions
30/05/2006
.NET Technologies 2006
21