Local-Remote Transparency Framework for Passing Mutable Objects to Remote Operations

Transcription

1 Local-Remote Transparency Framework for Passing Mutable Objects to Remote Operations Boydens, Jeroen 1 Steegmans, Eric 2 February 11, KHBO Dept Industrial Science & Technology Zeedijk 101, B 8400 Oostende, Belgium 2 K.U.Leuven Dept Computer Science Celestijnenlaan 200A, B 3001 Leuven, Belgium {Jeroen.Boydens, Eric.Steegmans}@cs.kuleuven.be Abstract This paper focuses on the fact that a developer should not be concerned whether his application will be distributed or not. Because the current remoting infrastructures use serialisation to pass parameters, synchronisation problems exist. We will elaborate on a transparent framework to pass mutable objects to remote operations, in the same way as they are passed to local operations. A number of solutions will be proposed to provide this transparency. Finally, a solution based on a caching mechanism will be implemented using annotations. 1 Introduction In this introduction, we will first identify the transparency problem. Next, we will discuss the mutability of the objects, which is causing the transparency problem. Following this Section, we will discuss the different problem scenarios. Finally, in Section 1.4, we will provide a sample that illustrates the most serious synchronisation problem. J. Boydens is an affiliated researcher at K.U.Leuven, dept CS, research group SOM prof E. Steegmans is head of the research group SOM

2 1.1 The Transparency Problem This paper concentrates on problems appearing in situations where remoting and object distribution is used with mutable objects. These exist in both the Java 2 Enterprise Edition (J2EE) [3, 18, 11] world, where Remote Method Invocation over Internet Inter-Orb Protocol (RMI-IIOP) [6] is used, and in the.net [13, 5] world, where.net Remoting [12, 16] is used. When passing parameters to operations on remote objects the boundary of the executing virtual machine is crossed. The virtual machine uses a serialisation mechanism to pass parameters to remote operations. When parameters with reference semantics are passed to remote operations, the referenced objects are serialised. At the remote side, the serialised version of the parameters is de-serialised, to create a new copy of the objects in the remote program space. In most situations, the remoting mechanism is working fine. In Section 1.3, a number of problem situations will be identified. These are situations in which performance degradation is noted, and one situation in which dirty data can exist. There are no problems when the parameters are immutable during the execution of the remote method. When these parameters are mutable, as is mostly the case, a different version of the parameter is used in local and remote program space. This is not quite the equivalent of the local-calling scheme, since in the local scheme we are actually referring to the same object. In the remote scheme we are referring to two completely different objects in different program spaces. The callee is using a new object with the same initial state as the caller s object. When developing applications the focus should be on the functional requirements of the application, not on its distribution. Passing parameters to local or remote operations is implemented in different ways. Local-remote transparency is required since developers should not worry whether their applications will be distributed or not. To support local-remote transparency, this paper focuses on the caching of objects during remote method calls. It proposes a pattern, which is implemented using annotations, to prevent the use of outdated data. The implementation validates each object request to the cached version, this way providing the mutability of the objects at the remote side. 1.2 Mutability of Objects The problems caused by serialisation, as explained in Section 1.1, depend on the nature of the object passed as a parameter. We can distinguish objects that are immutable and others that are mutable. Immutable objects may be replicated as many times as necessary as syn-

3 chronisation problems will never occur. Their state does not change at the local side, and neither does it at the remote side. Mutable objects are those objects whose state changes during the execution of the operations. These mutable objects are causing trouble. In the following sections, we will provide a mechanism to inform the developer whether or not he is using outdated data. To protect data during remote method calls, we could use distributed transactions. During these transactions, the data is locked as temporary. The heavy machinery of transactions, and the discussion of isolation levels to solve locking, is overkill for this problem. In this paper we want to provide a lightweight solution for knowing whether synchronisation issues occur. 1.3 Problem Scenarios Let us consider all possible scenarios of mutable and immutable, local and remote objects passed as parameters to local and remote operations, as illustrated in Table 1. Nr Object Locality Object Mutability operation Problem 1 local immutable local call No 2 local immutable remote call No 3 local mutable local call No 4 local mutable remote call out-of-sync 5 remote immutable local call No 6 remote immutable remote call degradation 7 remote mutable local call No 8 remote mutable remote call degradation Table 1: Parameter passing scenarios Only the problem scenario where an out-of-sync occurs will be further discussed in detail in this paper. In two scenarios there is possibly a performance degradation, namely in case number 6 and case number 8. Both cases are based on a comparable scenario, in which a remote object is passed to a remote method call. Remote objects are accessed through a stub. When the object is passed to a remote method, not its contents but the stub is serialised. The object can be accessed locally if the remote method resides in the same program space as the remote object. Instead of directly accessing the object, it is now accessed through a stub-skeleton pair. This performance degradation does not lead to incorrect access of information, since the original object is still referred to.

4 1.4 Synchronisation Problem Illustrated #$! " % #& $ '#( ) *+, -. /012 Figure 1: Mutable Local Object in Remote call The illustration in Figure 1 visualizes the problem scenario. A mutable local object z of type Z is created. A remote object y is used through its local stub ry. This remote object has an operation f which takes an object of type Z as a parameter. When a call ry.f(z) is made, the object z is passed to the remote operation as a value, not as a reference. Technically, the value of z is serialised in a byte stream by the remote object-stub ry, and the value is pushed over the network to the remote object skeleton. At the remote side, the value of z is de-serialised out of the byte stream. A second instance of the value of object z is created at the remote side. This causes the out-ofsync problem. The state β at the local side can change after the value is serialised, causing a changed state β at the local side and a state β at the remote side. As a result, any changes made to the local copy of z will not be reflected in the de-serialised copy of z at the remote side. The sample code in Algorithm 1 illustrates this scenario. It uses the Customer class as the mutable local class. First, an Account object is created at the remote side. This object is then exported as a remote accessible object, and an identifying name MyAccount is assigned to it. The name is used by the local side during the lookup of the object-stub RemoteAccount in the context at the local side. The narrow method checks to ensure

5 that the object, returned by the lookup method, can be cast to the desired type RemoteAccount. The local object myfriend is now passed to a remoteaccount operation transferamountto as a parameter. At this point the local value of the Customer objects gets out-of-sync with the remote value. Algorithm 1 Java code out-of-sync //Remote side Account myaccount =new Account( ); // y PortableRemoteObject.exportObject(myAccount ); Context ctx = new InitialContext(someProperties); ctx.rebind( MyAccount, myaccount ); //Local side Context ctx = new InitialContext(someProperties); RemoteAccount myremoteaccount = (RemoteAccount) PortableRemoteObject.narrow( ctx.lookup( MyAccount ), RemoteAccount.class); //ry Money amount = new Money(100.0); //auxiliary object Customer myfriend = new Customer( Laura ); myremoteaccount.transferamountto( amount, myfriend ); 2 Solution to the Transparency Problem In this section, we will first present a number of scope settings to reduce the problem space. To guide us in selecting a solution we will use the following metaphor: objects live in their origins, and are cached in all other locations. Next, we will present a number of solutions, and explain why they do not satisfy the preferred solution. Finally, in Section 2.6, a caching strategy will be presented. And later on in this paper, in Section 3, we will implement this strategy. 2.1 Scope Settings All objects are non-remote per definition, unless otherwise specified. The distributed architecture constitutes of one server (master) and multiple clients (slaves). We will not introduce a remoting infrastructure at the client side, only an infrastructure at the server side. The out-of-sync objects live in the client programming environment. A network with continuous connectivity is presumed. We will present a number of strategies to solve the synchronisation issues and we will motivate why the caching strategy in Section 2.6 is selected as the optimal solution.

6 2.2 Make all Objects Remotely Available If this strategy is applied it will give remote access to all objects on all different locations. The remote stub is passed when passing parameters to remote operations. This way, all requests made concerning information in the object are forwarded to the original environment where the object resides. Hence, a symmetrical solution appears, in which both client and server provide objects to each other. Because we do not want to provide remoting infrastructure on the client, this strategy is not wanted. Another disadvantage is that we must add security restrictions to the client. When we make an object remotely available, we must restrict unauthorised access. 2.3 Objects Live Only in One Place Another strategy is to move the object from one location to another. When an operation is started, the object passed as parameter is serialised and removed at the client side. The serialised object is moved over to the server where it is recreated in the last state. The operation is executed in the server program space with the object in the same program space. On completion, the object is serialised and sent back to the client. The server instance of the object is now deleted. On arrival at the client side the object is recreated with its new state, a state which is changed only because of changes at the server side. This strategy reduces the ability to use the object as a parameter to multiple parallel requests. It also prevents a client from using or updating the local value of the object. Therefore this solution is not selected. 2.4 Transactions A transaction [2, 8] is started at the client side, noting all following requests at the client side that this object is in use by some operation. The transaction context can be distributed across the network, so that the remote operation can vote on the completion of this transaction. This voting takes place at the client side, when the remoting operation completes. Because of the transactions, all operations run in isolation of each other. A client is thus unable to change the original object in its local memory, until the object is released by the transaction. Additional settings are needed when remote operations are suddenly aborted. A distributed transaction infrastructure is needed on every client. Every time a remote operation needs a local object, necessary decisions are made on the isolation levels of the transaction (Read Uncommitted, Read Committed, Repeatable Read, Serialisable). Transactions can solve the synchronisation problem, but this mechanism is not selected as a

7 valuable solution, as mentioned in Section 1.2. The transaction infrastructure needed on every client is overkill. As such, interceptions are necessary both at client and at the server side. 2.5 Observer Pattern In the next strategy, we register an observer [7] for every object that is passed to a remote operation. The remote operation is added as an observer at the client side. When changes occur in data at the client side, all observers must be notified and updated. If we want to be able to change the remote version of the object, all changes must be propagated back to the client. In case of a bidirectional association, local changes can propagate to the remote side, and data race situations can occur. Data races are very hard to find and solve. This strategy requires a considerable administration at the client side. What if a remote operation suddenly aborts, then the corresponding observer is not removed from the enlisted observers on the client. The client will try to notify non-existing observers. 2.6 Caching strategy The strategy we will discuss further in this paper uses a caching solution. The sample application is located in the banking business. Imagine branch offices that keep track of extended customer information. Branch offices are responsible for managing all the information concerning their local customers. The head office needs information about all the customers, but is not willing to manage that huge amount of information. When the branch offices are communicating with the central bank, customer information is sent over to this head office. Since numerous applications are sending such information to the central bank, updated values may arrive while handling current requests. The caching solution notifies the executing requests if a more recent version is available. This is illustrated in the sequence diagram [4, 9] in Figure 2. In this illustration, the central bank object is represented twice. This serves to show that multiple requests can arrive in a parallel way. As an extra advantage, we are able to query the cache about cached customer information, even on moments that branches are not connected. As an example, head office applications may offer a business method returning the branch at which a given customer has an account. One may argue that the answers returned by the cache are not guaranteed to be up-to-date, since the cache is only updated when values are passed. To acquire more accurate data in the head office, dummy methods are triggered at the branch offices. These methods pass the changed customers to the head office in a nop-operation on the server. In our vision it is never possible - not even at the branches

8 request1 : BranchOffice : CentralBank : CentralBank : Cache processrequest updatevalues request2 processrequest updatevalues readproperty UpdatedValues Figure 2: Distributed Application themselves - to guarantee the data to be up-to-date, since it may be aging just after recording. We think it is better to have some information, than none at all. On top of this, while using the caching framework, we can warn a client during the processing of a request that he is using aged values. We will not focus on cache validation and cache eviction policies. It is clear that objects are removed from the cache when their time-to-live attribute has expired, or when the cache is cleared. The main goal of this paper is to focus on the transparency of passing arguments to local and remote methods. 3 Caching Strategy Implementation When a developer creates a class, he knows whether the objects will be mutable or immutable. He should not be concerned with the fact whether the application will be distributed or not. The current technology presumes all objects sent over the network are immutable, which is not always the case. By introducing an annotation, we want to give the developer an opportunity to state this mutability. When the annotation is mutable, the framework takes care of the introduction of a caching mechanism at the remote side to support mutable objects as parameters in remote operations. The framework adds all necessary code to cache the values when they are sent to remote methods, and the framework throws exceptions when requests are made to outdated values.

9 The caching strategy is implemented by annotating the initial class with a mutability-tag, see Section 1.2. The developer has the option to annotate the class with a or with a By the developer states that the objects are mutable, that their value is expected to change during the execution of operations. Since most objects will be mutable, tag is the default option. The retention policy of this annotation is runtime, meaning they are to be recorded in the class file by the compiler and retained by the VM at run time, so they may be read in a reflective manner. Local Branch Office Client (satellites) * myfriend : Customer {annotation id lastname givenname birthdate city country Network myfriend : Customer {annotation id lastname givenname birthdate city country Cache Remote Central Bank Server 1 myremoteaccount : RemoteAccount myaccount : Account nr customerid balance minbalance : AccountSkeleton Interception at Server Side Stub marshall(customer) Skeleton unmarshalling(customer) myremoteaccount.transferamountto( amount, myfriend) Figure 3: As illustrated in Figure 3, the class Customer is annotated with tag. During the marshaling, or serialisation, of the parameters of the remote operation myremoteaccount.transferamountto( ), the annotation is retained. The object is de-serialised during the un-marshaling phase at the remote side. At this point, an interceptor detects the annotation, sends the object to the cache, and makes sure all following requests on the object are verified to the cached version. The code to verify the cached version is based on a decoration pattern [7]. Every request that is made to the object is first verified with the cached version. When conflicts are detected an exception is thrown.

10 4 Future Work We want to implement the annotation based approach as a language construct, this way adding an extra keyword to the language so the developer has the ability to state the mutability of the objects. The performance degradation problems stated in Section 1.3 should be avoided. We plan to use smart references to solve this problem. Smart references are references that know internally if they refer to a local or a remote object. The proposed solution is implemented in J2EE, based on Enterprise Java Beans [17, 10]. Since the same problem exists in the J2EE world and in the.net [14] world, this strategy could be implemented for.net. 5 Conclusion In this paper we have elaborated on a local-remote transparency problem that exists with current remoting infrastructures. We proposed the developer to annotate the mutability of the class he develops, so the remoting infrastructure can intercept accordingly. When the infrastructure receives a mutable object as a parameter to a remote operation, a caching mechanism will be introduced. During the request on information in the objects, the cached version is checked. This way, the developer will create a transparent solution for both the local and the remote parameter passing scheme. References [1] T. Bennani, L. Blain, L. Courtes, J.-C. Fabre, M.-O. Killijian, E. Marsden, and F. Taiani. Implementing simple replication protocols using corba portable interceptors. [2] P. Bernstein and E. Newcomer. Principles of transaction processing: for the systems professional. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, [3] S. Bodoff, E. Armstrong, J. Ball, and D. B. Carson. The J2EE Tutorial, Second Edition. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, [4] G. Booch, J. Rumbaugh, and I. Jacobson. Unified Modeling Language User Guide, The (2nd Edition) (Addison-Wesley Object Technology Series). Addison-Wesley Professional, 2005.

11 [5] B. Clark. Enterprise Application Integration Using.NET. Addison- Wesley Professional, [6] B. Eckel. Thinking in Java (2nd ed.): the definitive introduction to object-oriented programming in the language of the World-Wide Web. Prentice Hall PTR, Upper Saddle River, NJ, USA, [7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: elements of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, [8] J. Gray and A. Reuter. Transaction Processing: Concepts and Techniques. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, [9] C. Larman. Applying UML and Patterns: An Introduction to Object- Oriented Analysis and Design and the Unified Process. Prentice Hall PTR, Upper Saddle River, NJ, USA, [10] F. Marinescu. Ejb Design Patterns: Advanced Patterns, Processes, and Idioms with Poster. John Wiley & Sons, Inc., New York, NY, USA, Foreword By-Ed Roman. [11] V. Matena, B. Stearns, and L. Demichiel. Applying Enterprise JavaBeans: Component-Based Development for the J2EE Platform. Pearson Education, [12] S. McLean, K. Williams, and J. Naftel. Microsoft.Net Remoting. Microsoft Press, Redmond, WA, USA, [13] H. Moessenboeck, W. Beer, D. Birngruber, and A. Woess..NET Application Development: With C#, ASP.NET, ADO.NET, and Web Services. Pearson Addison Wesley, [14] C. Nagel. Enterprise Services with the.net Framework: Developing Distributed Business Solutions with.net Enterprise Services (Microsoft Net Development Series). Addison-Wesley Professional, [15] C. Pohl and A. Schill. Client-side component caching. In IFIP, [16] I. Rammer. Advanced.Net Remoting. Apress, Berkely, CA, USA, [17] E. Roman, S. W. Ambler, and F. Marinescu. Mastering Enterprise Javabeans. John Wiley & Sons, Inc., New York, NY, USA, [18] I. Singh, B. Stearns, and M. Johnson. Designing enterprise applications with the J2EE platform. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2002.