Design by Contract for Java Based Mobile Agents - CiteSeerX

Design by Contract for Java Based Mobile Agents Seng Wai Lokey and Sea Lingyy

yCRC for Distributed Systems Technology, Monash University yySchool of Computer Science and Software Engineering Monash University, Caulfield VIC 3145, Australia [email protected], [email protected]

Abstract Java, one of the most popular object-oriented languages, provides support for platform independent execution, and so, has been used for building numerous mobile agent systems. Recently, there has been many extensions of Java with assertional constructs to support design by contract. In this paper, we outline four ways in which design by contract could be usefully employed for Java based mobile agents. We argue for future Java mobile agent systems incorporating declaratively specified mobility-related constraints. We also highlight how dynamic uptake of agent components and agent conversion could be supported by design by contract.

1 Introduction Mobile agents are software components which can move (i.e., not only is data transferred, but also code and state), on their own volition or invited, from one host to another to perform tasks. In recent years, there has been a proliferation of Java based mobile agent systems (e.g., as described in [8]).1 Parallel to these developments are a number of extensions to Java to support design by contract [2] where interactions among software elements (e.g., methods of classes) are governed by specifications (or contracts).2 Design by contract ideas have been used for specification, debugging, documentation, and to support fault tolerant behaviour. This paper aims to describe ways in which Java based mobile agents could benefit from design by contract. A combination of a Java mobile agent system with design by contract Java extensions (there is no such combined system as far as the authors know) would be a platform from which these ideas could be explored. In x2, we briefly present design by contract ideas and a mobile agent model. In x3, we discuss mobility-related constraints. Then, in x4, we discuss how design by contract supports the dynamic uptake of agent components and agent conversion - which we explain are two useful features for future mobile agent systems. We conclude in x5. The work reported in this paper has been funded in part by the Co-operative Research Centre Program through the Department of Industry, Science & Tourism of the Commonwealth Government of Australia. 1 For links to Java based mobile agents systems, see http://www.cetus-links.org/oo mobile agents.html. 2 For links to Java with design by contract extensions, see http://www.elj.com/eiffel/feature/dbc/java/ge/.

1

2 Preliminaries 2.1 Design by Contract Elements of formal specification, called assertions, indicate what a component does rather than how it does it. Using these assertions, the underlying theory, known as design by contract, views the construction of object-oriented software systems as the fulfilment of contracts between client and supplier objects. A specification is associated with every software element. We consider three kinds of assertions used in specifications for the methods of classes:

pre-condition: an input condition for a method post-condition: an output condition for a method class invariant: an assertion describing a property which holds for all instances of a class and is effectively added to the pre-conditions and post-conditions of all methods in the class The assertions are typically boolean expressions involving formal parameters of methods and state variables, and in this paper, are prefixed by keywords requires, ensures, and invariant respectively. We shall also write pre-condition p and post-condition q of a method M as follows: {p} M {q}

2.2 Mobile Agent Model As in many Java mobile agent systems, we view an agent as an instance of a class extending a pre-defined class of the Java agent class library. When an agent moves, its state and class implementation (the code) are transferred from one agent server (which we call a place) to another. Several places can be located in the same host (distinguished by different port numbers). We assume that the agent library provides a method called go(dest) which sends an agent (invoking the method) to a destination dest.

3 Mobility-Related Constraints This section discusses the interplay of design by contract assertions and mobility.

3.1 Consistency of Itineraries with Assertions A means to program mobile agent behaviour is the itinerary. The itinerary specifies a sequence of method invocations, each invocation at a different place (or location): e.g. if (L1,M1) represents “at location L1, invoke method M1”, then the sequence [(L1,M1), (L2,M2), (L3,M3)] means that the agent visits places L1, L2, and L3 in that order invoking methods M1, M2 and M3 in the same order. However, the preand postconditions of methods might impose dependencies on method executions which invalidates the order M1, M2, and M3. For example, given the pre- and postconditions of the three methods as: {p1} M1 {q1} {p2} M2 {q2} {p3} M3 {q3}

It is possible that M2 cannot be invoked after M1 because q1 ! :p2. Hence, the pre- and postconditions of methods must be consistent with the itinerary, in that the dependencies imposed by these conditions do not violate the order of method execution in the itineraries. Relationships between pre- and postconditions could be used to help define the itinerary. For example, if q3 ! p2, then, we could have M3 execute first and then M2. 2

The following is a simple example of an agent which takes a value from one place and prints it out at another. class Agent { int value = 0; // initial value take() requires // no pre-condition { value = abs(getvalue()) + 1 } ensures value != 0

put() requires value != 0 { print(value) } ensures // no post-condition ... }

The itinerary [(L1,take), (L2,put)] works but not [(L2,put), (L1,take)] since the pre-condition of put is false when value is zero.

3.2 Location Assertions Pre-conditions might include assertions about where methods are active and post-conditions might include assertions about how methods affect the location of an agent. Such location assertions are formulated in terms of a system-updated location variable (similar to the idea in mobile UNITY [4]) for each agent instance and is denoted by . This variable represents the current place on which the agent is running. We can write location constraints on methods. For example, method M1 must only be invoked at location L1: f==L1g M1 fq1g. Similarly, if method M1 invokes the go(L2) method whose invocation migrates the invoking object to L2, we can ensure that at the end of the method call, the object is at some location L2: f==L1g M1 f==L2g. class Agent

f

... travel(Location nextDestination) requires != nextDestination // nextDestination is not the current place

f g

go(nextDestination); // migrate doTask(nextDestination); // do some task ensures == nextDestination // the agent should be at the next destination

doTask(Location l) requires == l // only query when at l

f g

query()

3

ensures == l // querying shouldn’t change the agent’s location ...

g

We have assumed a class Location for place identifiers.

3.3 Location Dependent Assertions When objects are migrating from one host to another, some assertions might depend on where the objects are. We could label assertions with locations. For example, in the following, the pre- and postconditions for method M1 depends on where the object (containing the method is): ==L1: fp1g M1 fq1g ==L2: fp1’g M1 fq1’g

Such location labelled assertions could be used to specify the location dependent nature of a method’s behaviour. For example, suppose we want to compute an approximation to pi using an iterative algorithm whose accuracy increases with the number of iterations. And we have two machines L1 and L2 both with limited CPU resources but L1 has more resources than L2. Then, on L1, we should only compute less than 10000 iterations, but on L2, less than 1000 iterations, with corresponding differences in what we expect the accuracies to be. The pre- and postconditions below reflect the differences: class Agent

f

int iterations; float approximationOfPi; float error; compute(int iterations) requires ==L1: iterations < 10000 ==L2: iterations < 1000

f g

approximationOfPi = computePi(iterations); error = computeError(approximationOfPi) ensures ==L1: error < 0.1 ==L2: error < 0.2

...

g

3.4 Assertions for MASIF MASIF [3] is an object-oriented specification of the interface of a mobile agent server (i.e. a place). One of the methods in the interface is the following: void receive_agent(Name agent_name, AgentProfile agent_profile, OctetString agent, String place_name, ClassNameList class_names, String code_base, MAFAgentSystem agent_sender)

When a place A invokes this method of another place B via a remote method call (e.g., via Java RMI), the agent whose name is the value of the parameter agent name is transferred from A to B. Pre-conditions could be defined on such methods to specify the security and resource requirements. For example, we have

4

class MAFAgentSystem

f

int numberOfAgentsRunning; Agents agent[]; // array of agents currently being hosted ... void receive_agent(Name agent_name, AgentProfile agent_profile, OctetString agent, String place_name, ClassNameList class_names, String code_base, MAFAgentSystem agent_sender) requires agent_sender 2 SetOfTrustedSystems && agent_profile.language_id == JavaID && numberOfAgentsRunning < 100 && ...

f g

... ensures ...

...

g

These pre-conditions depend on the security and resource usage policies set up by the system creators. In evaluating the pre-conditions, note that not all the values of the actual parameters need to be sent but only those required. This means that invocation of a remote method would be preceded by a remote call to evaluate pre-conditions. Agent transfer only occurs if the pre-conditions are satisfied.

4 Further Uses Apart from the above interplay of method pre- and postconditions with mobility, we point out two useful features for mobile agent systems supported by design by contract.

4.1 Dynamic Uptake of Components Mobile agents move from one location to another to perform tasks. Since some components might be needed for some tasks and not for others, and often the required component can only be determined at run-time, it is useful for an agent to be able to upload components on-the-fly. For example, in [6], an architecture is proposed which allows mobile agents to change or add negotiation and communication capabilities by plugging in (or out) components. Method signatures are used to select the right component to plug in. Pre- and postconditions could be employed in such architectures to declaratively specify component selection criteria based on the agent’s state and location. The notion of substitutability of an object by another as presented in [5] has been formally defined based on relationships between the pre- and postconditions of the substituting methods and the substituted methods. Such a notion could provide an aid to correctness and conformance to desired behaviour when the agent uses methods of new components. The notion of substitutability has also been extended to concurrent systems, in which synchronisation guards are interpreted as Eiffel-style assertions and conformance rules for objects in sequential systems are extended to components in distributed systems [5]. This will facilitate the use of design-by-contract for agents in a distributed environment, allowing synchronisation constraints to be specified.

5

4.2 Agent Conversion We expect future mobile agents to move among a wide range of platforms and machines including desktop, laptops, notebooks, smartphones, communicators, and other handheld devices. Different versions of Java have been created for different form factors including PersonalJava3 for handheld devices, Spotless Java for PalmOS devices4 , and EPOC’s Java system5 . We see the conversion of an agent implemented in one version of Java to an equivalent agent implemented in a different version of Java to be important if these agents are to run on different platforms. Agent conversion is also a means for an agent to run on different agent systems. Ongoing standardization efforts by OMG such as MASIF aim to allow different mobile agent systems to inter-operate. Until they are widely adopted, conversion between agents implemented in one agent toolkit to their equivalent in a different toolkit is another possible solution (e.g., in [1], agents implemented in the Aglet toolkit are converted at run-time to agents in the Voyager toolkit). A formalization of the relationship between an original object and the converted object capturing what is preserved and what is lost has been given in [7]. In the formalization, a conversion function, where an object of type A is converted into an object of type B, respects a type T which is a supertype of A and B if some constraints in terms of pre- and postconditions of methods of A, B and T are satisfied. Based on such work, well-defined agent conversion functions could be explored where the “essence” of the agent (as represented by a respected supertype T) is retained after conversion.

5 Conclusion and Future Work We have proposed ideas in which design by contract could support mobile agent applications. To validate our hypotheses, an implementation of a mobile agent system in Java with assertions would be needed, followed by experimentation along the above mentioned lines.

References [1] D. Tjung and M. Tsukamoto and S. Nishio. A Converter for Mobile Agent System Integration: a Case of Aglet to Voyager. In 1st International Workshop on Mobile Agents for Telecommunication Applications (to appear), October 1999. [2] Interactive Software Engineering. Building Bug-Free O-O Software: An Introduction to Design by Contract. 1999. Web page at . [3] D. Milojicic, M. Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman, K. Kosaka, D. Lange, K. Ono, M. Oshima, C. Tham, S. Virdhagriswaran, and J. White. MASIF: The OMG Mobile Agent System Interoperability Facility. In Proceedings of the 2nd International Workshop on Mobile Agents (MA’98), Lecture Notes in Computer Science 1477, pages 50–67, September 1998. [4] G-C. Roman and P.J. McCann. An Introduction to Mobile UNITY. In Proceedings of the International Workshop on Formal Methods for Parallel Programming: Theory and Applications (FMPPTA 98), in Parallel and Distributed Processing, LNCS 1388, pages 871 – 880, April 1998. [5] H. Schmidt. Compatibility of Interoperable Objects. In Information Systems Interoperability,chapter 6. Research Studies Press Ltd, 1998. 3 See

http://java.sun.com/products/personaljava/. http://www.sunlabs.com/research/spotless/. 5 See http://www.symbian.com/epoc/papers/java/java.html 4 See

6

[6] M. T. Tu, F. Griffel, M. Merz, and W. Lamersdorf. A Plug-in Architecture Providing Dynamic Negotiation Capabilities for Mobile Agents. In K. Rothermel and F. Hohl, editors, Proc. 2nd Int. Workshop on Mobile Agents, volume 1477 of Lecture Notes in Computer Science, pages 222–236, Stuttgart, Germany, 1998. Springer-Verlag, Berlin. [7] J.M. Wing and J. Ockerbloom. Respectful Type Converters for Mutable Types. Submitted to Foundations of Component Based Systems, 1999. [8] D. Wong, N. Paciorek, and D. Moore. Java-based Mobile Agents. Communications of the ACM, 42(3):92–102, March 1999.

7