Arcademis: a Framework for Middleware Development

1. Arcademis: a Framework forMiddleware Development Fernando Magno Quintão Pereira1 Marco Túlio de Oliveira Valente2 Roberto da Silva Bigonha1 Mariza Andrade da Silva Bigonha1 1 – Universidade Federal de Minas Gerais 2 – Pontíficia Universidade Católica de Minas Gerais

2. Middleware Systems • In the last ten years, developers of distributed systems have often relied on middleware platforms to increase their productivity. • A middleware system is a software layer that resides between the operating system and the distributed application layer. • Middleware systems hide from application developers details inherent to distributed programming: communication primitives, data marshaling and unmarshaling, failure handling, service lookup and synchronization. • Examples of middleware systems: CORBA, Java RMI, COM/DCOM, Lime, MPI.

3. Frameworks • Arcademis is a Java-based framework for middleware development. It consists of a set of classes and interfaces that define the architecture of object-oriented middleware systems. • A framework is a technique of reuse. It allows to reuse code and project. • A framework is constituted by a set of components, concrete and abstract, that collaborate to describe the skeleton of an application[jonhson97]. • A framework is different from a library.

4. Motivations • The generality of traditional middleware platforms compromises their flexibility. • General platforms are often complex systems, whose use demands a lot of computational resources. • Traditional middleware systems are monolithic: • CORBA implementations, such as ORBIX ou VisiBroker occupy several megabytes of memory; Therefore, they cannot be used in resource constrained devices. • Traditional middleware systems present few customization options. • Ex.: remote method invocation semantics in Java RMI.

5. Objectives of the Arcademis Project • To allow the development of non-monolithic and easily configurable middleware systems. • “What you need is what you get”. • To describe the architecture of object-oriented middleware systems. • To outline configurable aspects of object-oriented middleware systems. • To develop a remote invocation service for the CLDC configuration of Java 2 Micro Edition.

6. Object-Oriented Middleware • Provides to the application developer the illusion that remote objects are locally available. • Communication between objects is based on remote method invocation. Client Object Remote Object Distributed Application Layer Middleware Layer Stub Skeleton Client Address Space Server Address Space

7. Request Receiver Request Sender Response Sender Response Receiver A Component-Based Architecture Client Application Lookup Service Remote Object Distributed Application Layer Middleware Layer Remote Object Representation Stub Activator Skeleton Scheduler Middleware Protocol Serialization Protocol Chain of Dispatchers Chain of Invokers Transport Protocol Connector Acceptor

8. Configuration Parameters • Arcademis specifies 11 configurable aspects of object-oriented middleware platforms. 1 – Transport protocol. 2 – Connection set up. 3 – Middleware protocol. 4 – Serialization policy. 5 – Reliability level of remote operations. 6 – Remote object representation. • 7 – Service lookup. • 8 – Remote object activation. • 9 – Invocation policy. • 10 – Dispatching policy. • 11 – Priority policy.

9. Channel << interface >> ConnectionServer Epid epid +connect(Epid epid):void +send(byte[] a): void +recv(): byte[] +close(): void +getLocalEpid(): Epid +setTimeout(int t): void +getTimeout(): int +ConnectionServer(Epid epid) +abstract accept():void +abstract getChannel():Channel +abstract setTimeout(int t):void +abstract getTimeout():int 1th Parameter – Transport Protocol • There are several different implementations of transport protocols: TCP, UDP, HTTP, etc. • Arcademis defines the transport protocol by means of two components: • the Channelinterface; • the ConnectionServer abstract class;

10. Channel Decorators • Decorator : a design pattern that allows the aggregation of extra functions to a component by means of interceptor objects [Gamma 94]. Channel <<interface>> ChannelDecorator << decorator >> TcpChannel <<arcademis.concrete>> ZipChannel << decorator >> BufferedChannel << decorator >>

11. 2nd parameter – Connection Set Up • In Arcademis, connections are established by means of the acceptor-connector design pattern firstly proposed for the TAO platform [Schmidt 94]. • This pattern distinguishes the elements responsible for the connection establishment (AcceptorandConnector) from the elements in charge of the channel use (ServiceHandler’s). • Configuration options: • synchronous or asynchronous connection set up; • channel reuse or creation of a new channel per connection; • reception of connections by a dedicated thread or by the thread of the current application.

12. The Acceptor-ConnectorDesign Pattern ConnectionServer +accept(): +getChannel():Ch Acceptor +accept(): Connector +connect(epid): <<creates>> <<creates>> Channel +send(byte[]): +recv():byte[] +connect(Epid): <<creates>> <<creates>> <<uses>> <<uses>> ServiceHandler +open(channel): XxxxxHandler YyyyyHandler

13. 3rd Parameter – Serialization Policy • In order to send an object across the network it is necessary to transform it into a byte sequence (marshaling), so its contents can be recovered later (unmarshaling). This process is called serialization. • According to the Arcademis specification, data serialization is responsibility of the application developer. • Marshalable objects must implement the Marshalable interface, which defines the marshal and unmarshal methods. • The serialization protocol is defined by an implementation of the arcademis.Stream interface.

14. Example of Marshable Object import arcademis.*; public class Example implements Marshalable { int argument = 0; public Example (int argument) { this.argument = argument; } public void marshal(Stream b) { b.write(argument); } public void unmarshal(Stream b) { this.argument = b.readInt(); } } <<interface>> Marshalable (from arcademis) +marshal(Stream b); +unmarshal(Stream b); <<interface>> Stream (from arcademis) +write(byte b): +write(char c): ... +write(Object o): +readByte():byte +readChar():char ... +readObject():Object

15. 4th parameter – Reliability Level of Remote Operations • Determines the level of reliability provided by the implementation of remote calls. • Different implementations can provide the same semantics with different levels of reliability. • Example: • one-way: the client sends the call to the server and does not wait for any result; • best-effort: the client attempts to contact the server once. In the case of errors, a new attempt is not performed; • at-most-once: the client performs a number of invocations. Each of them is marked with an identifier, so that the same operation is not executed more than once; • at-least-once: the client performs successive remote invocations until a valid result is obtained;

16. The Request-Response Solution • The communication between stubs and skeletons is intermediated by four components: request-sender, request-receiver, response-senderandresponse-receiver. • Different implementations of these components determine different reliability levels of remote invocations. Client Object Remote Object Request Sender Request Receiver Skeleton Stub Response Receiver Response Sender Host S Host T

17. 5th parameter – The Middleware Communication Protocol • The middleware protocol is defined by a set of messages and by a state machine that defines the order in which messages are transmitted. • Messages are implementations of the Message interface from Arcademis, and are marshalable objects: arcademis.Message extends Marshalable. • The implementation of the marshal and unmarshal operations defines the message contents. • Messages are defined according to the Command design pattern [Gamma94]; therefore, the message implementation defines the actions to be executed after it is received.

18. RemoteReference RemoteObject <<abstract>> +RemoteReference(Epid,Id): +equals(Object):boolean +toString():String +hashCode():int +getEpid():Epid +getId():Identifier +activate(): +deactivate(): +getRef():RemoteReference +getStub():Stub +getSkeleton():Skeleton +equals(Object):boolean +toString():String +hashCode():int 6th Parameter - Remote Object Representation Marshalable <<Interface>> Epid <<Interface>> Identifier <<Interface>>

19. 7th Parameter – Service Lookup • Arcademis is a service oriented architecture [Champion02]: • service provider (remote objects); • service requesters (clients); • discovery agencies (lookup service). Lookup service Service identifier publish() find() Service Requester Service Provider

20. Invoker <<interface>> Stub RequestSender +invoke(RemoteCall, RemoteReference):Stream 8th Parameter – Invocation Policy • Stubs use instances of arcademis.Invoker to issue remote calls. • Clients can specify non-functional characteristics of remote invocations: log generation, use of caches and buffers, timing, etc. InvokerDecorator +invoke(RemoteCall, RemoteReference):Stream

21. Invoker Decorators • In order to add further functionalities to invokers, Arcademis allows the use of invoker decorators. Examples of decorators include: • caches: record the result of remote calls that do not cause side effects, do not throw exceptions and always return the same valued when given the same parameters; • buffers: group several messages in the same package aiming to improve network utilization; • timers: after a certain period of time, if the invoker does not received the call’s result, the operation can be aborted; • load balancing: when the stub has access to more than one service provider, the invoker can distribute remote calls among the available servers; • log generators;

22. 9th Parameter – Dispatching Policy • The server architecture is defined by the implementation of the arcademis.Dispatcher component. • Dispatcher decorators allow to aggregate extra functionalities to dispatchers: • log generation; • report of server load rate to clients; • redirection of calls to other servers; • creation of threads to process specific calls; • Implementation of security policies.

23. Example of Server Architecture DispatcherDecorator RequestReceiver Dispatcher Scheduler Skeleton ResponseSender RemoteObject

24. 10th Parameter – Priority Policy • Arcademis allows the assignment of different priorities to remote methods. • Remote calls are scheduled by the arcademis.server.Scheduler component. • Different priority policies can be adopted: • first in, first out; • the priority of each method is defined by the stub implementation; • service providers assign clients different priorities;

25. 11th Parameter – Remote Object Activation • A remote object needs to be activated before being able to receive remote invocations. • What happens during the remote object activation: • instantiation and initialization of skeleton, dispatcher, scheduler and acceptor; • creation of threads to handle incoming remote calls; • bind of the remote object to a network address; • creation of a unique identifier to the remote object. • The remote object activation policy is implemented by the arcademis.server.Activator component.

26. Remote Object Activation (from arcademis.server) Active <<Interface>> +activate(): +deactivate(): from arcademis.server) RemoteObject <<abstract>> from arcademis.server) Activator <<abstract>> +getRef():RemoteReference +getStub():Stub +getSkeleton():Skeleton +equals(Object):boolean +toString():String +hashCode():int

27. The ORB Class • The Arcademis components are instantiated according to the abstract factorydesign pattern [Gamma 94]. • Make it easier to configure instances of Arcademis. • Every factory is associated to a singleton component: the ORB (arcademis.ORB). • To configure an instance of Arcademis means to determine the implementation of the factories bound to the ORB. • The ORB functions can be accessed by means of a façade (arcademis.OrbAccessor).

28. The ORB Class Distributed Applications ORB 16 factories Invoker factory Dispatcher factory Channel factory Activator factory Connector factory Message Factory Epid factory Notifier factory Acceptor factory Stream factory Scheduler factory Identifier factory Buffer factory ServiceHandler factory Protocol factory ConnectionServer factory Operating System

29. Case Study – RME – Remote Method Invocation for Java 2 Micro Edition • RME is a middleware platform derived from Arcademis that targets the CLDC (Connected Limited Device Configuration) configuration of J2ME. • Java RMI cannot be deployed in the CLDC configuration because this environment does not support J2SE computational reflection and, consequently, object serialization. • RME provides the same programming syntax than Java RMI.

30. Some of RME Characteristics • RME uses 13 of the 16 factories of Arcademis. • Transport protocol: TCP/IP. • Synchronous connection set up, with channel reuse. • Middleware Protocol: seven different types of messages. • Reliability of remote calls: best-effort or at-most-once. • Name service: the same interface as in Java RMI. • Dispatcher sends remote calls directly to the skeleton. • Priority policy: first-in, first-out.

31. Contributions of the Arcademis Project • Methodological contributions: • description of the architecture of object-oriented middleware; • enumeration of several configuration parameters of middleware systems; • descriptions of new solutions for middleware implementation. Ex.: request-response. • Practical contributions: • Arcademis implementation; • RME implementation.

32. Final Remarks • Flexible system. • Arcademis could be used in an environment where Java RMI could not. • Project based on design patterns: abstract factory, singleton, acceptor-connector, etc. • Abstract factories facilitate middleware configuration. • Tests show that Arcademis’ flexibility does not substantially compromise its overall performance. • Arcademis does not provides dynamic reconfiguration, although some of its components can be changed during execution time. Ex.: invoker decorators in RME.

33. Download http://www.dcc.ufmg.br/llp/arcademis/

34. Application Example: Phone Book import rme.*; import arcademis.*; public interface PhoneCatalogue extends Remote { public PhoneAddress getPhoneAddress(String name) throws ArcademisException; } import java.io.*; import java.util.*; public class PhoneBook extends rme.server.RmeRemoteObject implements PhoneCatalogue { Hashtable h = null; public PhoneAddress getPhoneAddress(String name) { return (PhoneAddress)h.get(name); } private void insert(String name, String number, String address) { ... } }

35. PhoneAddress Implementation import arcademis.*; public class PhoneAddress implements Marshalable { private String name, phoneNumber, address; public PhoneAddress(String n, String p, String a){ name = n; phoneNumber = p; address = a; } public void marshal(Stream b) { b.write(phoneNumber); b.write(name); b.write(address); } public void unmarshal(Stream b) { this.phoneNumber = (String)b.readObject(); this.name = (String)b.readObject(); this.address = (String)b.readObject(); } // other method’s implementations: get’s and set’s }

36. Server Application public class Server { public static void main(String args[]) { try { rme.RmeConfigurator c = new rme.RmeConfigurator(); c.configure(); PhoneBook o = new PhoneBook(); rme.naming.RmeNaming.bind("obj", o); o.activate(); o.readFile(args[0]); // fills the phone book } catch (arcademis.ArcademisException e){} catch (arcademis.concreteComponents.MalformedURLException e){} catch (rme.naming.AlreadyBoundException e){} catch (java.io.IOException e){} } }

37. Client Application (J2SE) import arcademis.*; import rme.*; public class Client { public static void main(String a[]) { try { RmeConfigurator c = new RmeConfigurator(); c.configure(); PhoneCatalogue phoneBook = (PhoneCatalogue) RmeNaming.lookup("algol.dcc.ufmg.br/obj"); PhoneAddress a = phoneBook.getPhoneAddress(“Machado de Assis”); System.out.println(a.toString()); } catch (Exception e) {} } }

38. ORB Configuration package rme; import rme.server.*; import arcademis.*; public final class RmeConfigurator implements Configurator { public void configure() throws ReconfigurationException { if(ORB.isOpenForReconfiguration()) { // Define the channel factory ChannelFc cnFc = new RmeChannelFc(); ORB.setChannelFactory(cnFc); // Define the connection server factory ConnectionServerFc csFc = new RmeConServerFc(); ORB.setConnectionServerFactory(csFc); // Define the other 7 factories ... // close the ORB for furter reconfigurations ORB.closeForReconfiguration(); } else throw new ReconfigurationException(); } }