Transparent Mobility of Distributed Objects using .NET
•Als PPT, PDF herunterladen•
0 gefällt mir•290 views
These slides presents a research line where we explored the support for code mobility and runtime software migration among systems. We developed a prototype in .NET Remoting (in 2006) to support transparent code mobility of distributed objects. Our approach was based on separating the distribution and mobility concerns from the source code that contains the application logic in entities called attachments. Thus, attachments were high-level proxies responsible for creating communication channels and that were capable of managing dynamic location changes without affecting the objects in the case of mobility. This approach was implemented using a case study. The response time of distributed communication provided by our approach has been tested and compared with the remote communication provided by the primitives of .NET Remoting. This work was presented in the 4th International Conference on .NET Technologies, Pilsen, Czech Republic, May-June 2006. The paper is available here: http://issi.dsic.upv.es/publications/articles_table?view=188
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Transparent Mobility of Distributed Objects using .NET
Ähnlich wie Transparent Mobility of Distributed Objects using .NET (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Transparent Mobility of Distributed Objects using .NET
- 1. 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í
- 2. Contents > Background & Motivation > Search Agents case study > OOAttachments approach > Conclusions 2 30/05/200 .NET Technologies 2006
- 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 Node1 Node2 Component1 Component2 Attachments 3 30/05/200 .NET Technologies 2006
- 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 4 30/05/200 .NET Technologies 2006
- 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 5 30/05/200 .NET Technologies 2006
- 6. 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 6 30/05/200 .NET Technologies 2006
- 7. Strong vs Weak Mobility Strong Mobility Weak Mobility Agent processes are interrupted in The programmer must take care a transparent way of their processes In order to implement strong mobility It is the programmer who saves the ability of thread serialization is processes information before moving required. and restores it after moving. Two main alternatives: As no customization is needed, the By extending the Framework solution is more portable (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 7 30/05/200 .NET Technologies 2006
- 8. Contents > Background & Motivation > Search Agents case study > OOAttachments approach > Conclusions 8 30/05/200 .NET Technologies 2006
- 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 A B E C D > 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) 9 30/05/200 .NET Technologies 2006
- 10. 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) 10 30/05/200 .NET Technologies 2006
- 11. Contents > Background & Motivation > Search Agents case study > The OOAttachments approach > Conclusions 11 30/05/200 .NET Technologies 2006
- 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 12 30/05/200 .NET Technologies 2006
- 13. The OOAttachments approach > Objects are connected through entities called Attachments Host A Host B [Serializable] [Serializabl e] Attachment «generated-code» AttachmentServ er Serv er-AttClient objectName: string IDeserializationCallback 1 «NonSerialized» objRef: object Search Search [Serializable] objType: T ype AttachmentClient attClientsURLs: string [0..*] (ArrayList) methodInformation: MethodInfo [1..*] serverIsMovi ng: bool parentType: stri ng serverURL: string AttachmentServer(objRef, objectName, objType) Agent 1 Agent 2 serviceIsConsum ing: bool[] BeginServerMobility() : void EndServerMobility(objectReference) : void Process(methodID, args) : object BeginClientMobility() : void EndClientMobili ty() : void [NonSerialized] 1 StopProcessingServices() : void MarshalByRefObject AttachmentServ erMediator [NonSerialized] 1 methodsList: Delegate[] MarshalByRefObject AttachmentClientMediator RegisterClient(attClientURL) : MethodInfo[1..*] ServerM obilityBegan() : void UnRegisterClient(attClientURL) : void ServerM obilityEnded(newURL) : void RedirectService(methodID, args) : object Client behaviour: Server behaviour: It invokes “NotifyNewLocation” Object layer It offers the “NotifyNewLocation” service Client behaviour: Server behaviour: provided by the AttachmentClient Attachments layer provided by the AttachmentServer .NET Remoting layer > Attachments are created through the AttachmentsManager class 13 30/05/200 .NET Technologies 2006
- 14. How it works: Communication Host A Host B Attachment Search Search Agent 1 Agent 2 > Server-behaviour is defined by > Server-behaviour is defined by AttachmentServ er [Serializable] the AttachmentServer object the AttachmentServer object objectName: string «NonSerialized» objRef: object objType: Type Incoming request services are forwarded Incoming request services are forwarded attClientsURLs: string [0..*] (ArrayList) serverIsMoving: bool towards the server object towards the server object AttachmentServer(objRef, objectName, objType) It notifies about mobility to its connected It notifies about mobility to its connected BeginServerMobility() : void EndServerMobility(objectReference) : void objects objects One entity is serializable (Marshal By One entity is serializable (Marshal By [NonSerialized]1 MarshalByRefObject Value), so its state can be migrated, and Value), so its state can be migrated, and AttachmentServ erMediator the other is accessible remotely (Marshal the other is accessible remotely (Marshal methodsList: Delegate[] By Reference) By Reference) RegisterClient(attClientURL) : MethodInfo[1..*] UnRegisterClient(attClientURL) : void RedirectService(methodID, args) : object 14 30/05/200 .NET Technologies 2006
- 15. How it works: Communication Host A Host B Attachment Search Search Agent 1 Agent 2 [Serializable] «generated-code» Serv er-AttClient > Client-behaviour is defined by the > Client-behaviour is defined by the IDeserializationCallback 1 [Serializable] AttachmentClient object AttachmentClient object AttachmentClient methodInformation: MethodInfo [1..*] > Composed by: > Composed by: parentType: string serverURL: string A runtime generated proxy (MSIL) of the A runtime generated proxy (MSIL) of the serviceIsConsuming: bool[] remote object remote object Process(methodID, args) : object BeginClientMobility() : void A remote accessible object which allows A remote accessible object which allows EndClientMobility() : void StopProcessingServices() : void to be notified about server mobility to be notified about server mobility [NonSerialized] A serializable object that A serializable object that 1 MarshalByRefObject manages the attachmentClient state, manages the attachmentClient state, AttachmentClientMediator forwards services to the attachmentServer forwards services to the attachmentServer ServerMobilityBegan() : void ServerMobilityEnded(newURL) : void 15 30/05/200 .NET Technologies 2006
- 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 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% 16 30/05/200 .NET Technologies 2006
- 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 17 30/05/200 .NET Technologies 2006
- 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 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 18 30/05/200 .NET Technologies 2006
- 19. Contents > Background & Motivation > Search Agents case study > The OOAttachments approach > Conclusions 19 30/05/200 .NET Technologies 2006
- 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 20 30/05/200 .NET Technologies 2006
- 21. Questions 21 30/05/200 .NET Technologies 2006
Hinweis der Redaktion
- Good morning, I’m Cristobal Costa. I come from the Polytechnic University of Valencia, Spain And I’m going to present our work about “Transparent Mobility of Distributed Objects using .NET “
- First, I’ll present the background and motivation of this work. Then, I describe the case study on which we have applied our approach, and which illustrate the concepts Next, I’ll give you the main implementation details of our appproach Finally, I’ll present you the conclusions
- In our research group we are working in component-based, aspect-oriented software architectures. A characteristic of components in Sofware Architectures is that they neglect distributed nor local references of their partners. Therefore, specific entities called Attachments are responsible of interconnecting components and providing transparent mobility and communication.
- As a result, we have thought of transferring our experience in attachments to connect objects, instead of aspect-oriented components So, our objective was to provide a library, to the object-oriented community, to support the development of distributed objects capable of moving in a transparent way. These features must be provided in a non intrusive and transparent way of programming, the code should not be precompiled nor preprocessed, and the efficiency must be taken into account.
- For example, imagine that in a Client & Server architecture, a server needs to change dynamically its location. With our library we want to achieve that the client objects of the server don’t have to worry about the change of location. Why the client object has to worry about its server?
- As there is no focused in the same way, there are several approaches to provide mobility in the area of mobile agent systems. However, most of them are built on Java, such as Aglets, JADE or ProActive. In .NET, there are a few approaches that are still in development. However, only EtherYatri.NET has a downloadable prototype. The common characteristics of these approaches are these: Agents are defined by means of inheritance In most of them, the agent has to define all its functionality in one method, whith a specific signature (usually called “Run”, with no parameters) Events are captured by overriding inherited methods Communication among agents is realized by several ways: by using generic proxies, by passing messages, or by implementing specific services NOTE: We have to mention MAPNET as a worse and inexistent platform, Aglets (the oldest one) and ProActive (as the best now, but in Java), Nomad (not a library), Etheryatri (no public documentation (papers), but well effort of porting).
- There are two ways of implementing mobility: there is Strong Mobility and WeakMobility. In Strong Mobility, agent processes are interrupted in a transparent way. This is the better one to perform mobility. However the ability of thread serialization is required. There are two main alternatives in current research works, mainly for Java Frameworks: By extending the Framework, like JavaThreads did. The problems arises when new releases of the framework appears, so new adjustements may be needed. By preprocessing the source or binary code, like Brakes did. The problem here is, as there are no direct access to Thread information, the eficiency is worst than in the previous approach. On the other hand, in weak mobility is the programmer who saves and restores processes information before and after mobility. Although it is less transparent than strong mobility, it’s more portable, so we have chosen this approach.
- From now on, i’m going to explain our approach using the case study of Search Agents. There are a lot of distributed resources among the Internet on which we want to collect information from. However, a characteristic of these resources is that the search grows as a tree. We need to explore the resources dynamically in a distributed way. Instead of sending one agent to each database (as there can be a lot of them), there will be better to use only a pair of agents capable of establishing mobile communications, that is, the ability of communicate with the others without taking into account where the others are. By this way, we won’t overload network resources, as there will only be a few agents travelling through the network. Moreover, agents will be able to exchange new subsearches: the others can perform the new subsearch before moving to another host. The manager doesn’t need to remain connected, as the agents can work in an autonomous way. When they finish, they can synchronize the results and wait till the manager is connected.
- For example, here is the implementation of a simplified version of the SearchAgents case study using our approach. Here, the agents only synchronize its new search location, in order to avoid that two agents performs the search in the same resource. One important difference is that the inheritance is not limited as in other approaches. Mobility and communications are provided entirely by an external object, as a pluggable library. An object is made accessible to others by registering through the AttachmentsManager. A specific interface can be specified to restrict offered services. To establish a mobile connection an object only has to invoke the ConnectTo service by specifying the current address of the object to which it wants to connect to and its ID. An object of the same type is obtained, which is a transparent proxy of the remote object. Calling this service an object can be moved in an autonomous way, by specifying any method to be executed when mobility finishes. There are no method signature restrictions. So you can see that an application can be easily adapted to support transparent mobility and communication.
- So, with our library, objects can move autonomously among computers without realize how distributed communications with other objects are performed. When a connection is established, location-awareness is provided. Moreover, there are no need for a centralized infrastructure to manage mobility and object registration services. Dynamic Code Generation has been used to be able of calling code dynamically. There are a few constraints to consider: Only 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 And each mobile object must be marked as Serializable
- Let’s suppose that Search Agent 2 offers the service “NotifyNewLocation”. It provides a Server Behaviour. Search Agent 1 invokes this service, so it has a client behaviour. The role of each one is important in order to understand the following concepts. Then, we say that both objects are connected through an attachment, which in fact is divided in smaller, specific entities. The ServerBehaviour is provided by the AttachmentServer object, and the ClientBehaviour by the AttachmentClient object. We can say that these objects constitute the AttachmentsLayer, built over .NET Remoting. The attachments are created by invoking the corresponding services of the AttachmentManager class, that is, the middleware that must be running in each computer where mobility can take place.
- On the one hand, the AttachmentServer object is responsible for forwarding incoming request services from the AttachmentClient to the Server object, that is, “SearchAgent2”. It also notifies about mobility to its connected objects. It is also divided in two entities: one is serializable so its state can be migrated to other computers, and the other is accessible remotely. This is because of in .NET Remoting an object can not be both serializable (marshal by value) and accessible remotely (marshal by reference).
- On the other hand, the AttachmentClient is responsible for collecting client requests and forwarding to the other side, the Attachment Server. It is composed by a runtime generated proxy of the remote object, a remote accessible object which allows to be notified about server mobility, and a serializable object that manages the attachmentClient state and forwards services to the attachmentServer.
- As inter-object communication is a very frequent operation, it must be as faster as possible. However, as communication is created dynamically on demand, our infrastructure must rely on dynamic code invocation. There are several ways of doing that, but the better performance is achieved by direct call invocation, of course. For this reason, we preferred to dynamically generate code in order to make direct calls. The total introduced communication costs are not expensive, as there are only 3 direct calls and 1 dynamic ¡nvocation by using delegates, with an average cost of 11%.
- Mobility is performed in several steps, as stated here: First, the object to be moved and its communication processes (the attachments) are packaged This package is serialized and transferred to the target host The next step is to check out whether the required assemblies are available. If not, they are downloaded from the source host. The information is unpacked and, when the attachments are restored, the specified method of the transferred object is executed If anything fails, all information is restored properly. Moreover, simultaneous mobility is also supported. That is, an object can move to another host while the other objects, which are connected to it, are being moved at the same time. However, the mobility process depends on the role of the object to be moved.
- On the one hand, when the object has a client behaviour, mobility will not take place until all its service requests being processed are finished properly. When mobility finishes are restored both the object state and all remote connections with mobile objects On the other hand, if the object has a server behaviour, new requests from client objects are blocked (at the attachment level) until mobility finishes. Then, when all the service requests being processed finish, the mobility takes place. Finally, all communication processes are restored and client requests are unblocked and processed. By this way, clients don’t realize about the mobility of the server. Total mobility costs: Communication costs (transference of attachments + object state) Code migration, if needed (transference of required assemblies) Processing costs (deserialization of data & communication restablishment)
- Finally, we can conclude that an application can be easily adapted to benefit from these features: Objects don’t have to take into account what communication technology is being 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 As a further work, it has to be considered the possibility of adaptation to Service-Oriented infrastructures, such as Windows Communication Foundation (or “Indigo”) Moreover, security is an important subject to take into account once the infrastructure is designed. For instance, we have considered the possibility of signing assemblies in order to validate what incoming code is acceptable or not. We are going to release our library as an OpenSource project, available in the following address. Nowadays it’s in Alpha state, but we planned to have our first release this summer.
- Thanks by your attention. Any question?