Transparent Mobility of Distributed Objects using 'NET

1
Transparent Mobility of Distributed Objects using
.NET
4th International Conference in Central Europe
on .NET Technologies

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

2
Contents

• Background Motivation
• Search Agents case study
• OOAttachments approach
• Conclusions

3
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

4
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

5
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?

Server
Client
6
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

7
Strong vs Weak Mobility
Weak Mobility
Strong Mobility
The programmer must take care of their processes
Agent processes are interrupted in a transparent
way

• 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

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
8
Contents

• Background Motivation
• Search Agents case study
• OOAttachments approach
• Conclusions

9
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

• 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)

10
SearchAgent implementation

• 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)

11
Contents

• Background Motivation
• Search Agents case study
• The OOAttachments approach
• Conclusions

12
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

13
The OOAttachments approach

• Objects are connected through entities called
  Attachments

Host A
Host B
Search Agent 2
Search Agent 1
Attachment
Server behaviour It offers the
NotifyNewLocation service
Client behaviour It invokes NotifyNewLocation
Object layer
Server behaviour provided by the
AttachmentServer
Client behaviour provided by the
AttachmentClient
Attachments layer
.NET Remoting layer

• Attachments are created through the
  AttachmentsManager class

14
How it works Communication
Host A
Host B
Search Agent 2
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)

15
How it works Communication
Host A
Host B
Search Agent 2
Search Agent 1
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 allowsto be
  notified about server mobility
• A serializable object that
• manages the attachmentClient state,
• forwards services to the attachmentServer

16
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 isReflection lt Delegates ltlt
  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

17
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

18
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 mustfinish 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

19
Contents

• Background Motivation
• Search Agents case study
• The OOAttachments approach
• Conclusions

20
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

21
Questions