An Aspect-Oriented Communication Middleware System (DOA 2005)

This paper describes a Java-based communication middleware, called AspectJRMI, that applies aspect-oriented programming concepts to achieve the following requirements: (1) modular implementation of its features, including those with a crosscutting behavior; (2) high degree of configurability and adaptability; (3) performance similar to conventional object-oriented communication middleware systems, such as CORBA and Java RMI. In AspectJRMI, users may explicitly select the features provided by the middleware infrastructure, according to their needs. Most of these features have a crosscutting behavior, including interceptors, oneway calls, asynchronous calls, value-result parameter passing, and collocation optimizations. In this case, they are implemented as aspects. The design of AspectJRMI follows a set of principles, called horizontal decomposition, to achieve pluggability of aspects to the core middleware implementation. This paper presents the programming interface and the implementation of AspectJRMI. It also presents experimental results of its performance

Transcript

1. An Aspect-Oriented Communication Middleware System Marco Túlio Valente, Diana Leão, Rodrigo Palhares, Fabio Tirelo Institute of Informatics, PUC Minas Belo Horizonte, Brazil Distributed Objects and Applications (DOA 2005) Agia Napa, Cyprus, Nov 2nd, 2005
2. DOA - 20005 2 Background  Object oriented communication middleware platforms are largely used to support the implementation of distributed systems  Examples: CORBA, JavaRMI, .NET Remoting, Web Services etc  Basic service: remote method invocation  Synchronous, call-by-value, at-most-once semantics  Additional services:  Oneway calls  Asynchronous calls  Service combinators  Decorators  Call-by-value-result  Collocation optimizations
3. DOA - 20005 3 Problems  Traditonal middleware are very monolithic systems  A wide range of applications use only a reduced subset of middleware services  Services that are not used:  Increase memory footprint  Eventually, impact middleware performance  Example:  UIC-CORBA: 100 KB (basic CORBA service)  ORBit2: 2 MB (full CORBA service)  There are no implementations of CORBA between these two intervals
4. DOA - 20005 4 Crosscutting Concerns  One of the main reasons for these lack of configurability and tailorability is the fact that additional services present a crosscutting behavior  Problems:  Bad modularization  “plug in/plug out” is more difficult  “what you need, is what you get” is more difficult
5. DOA - 20005 5 AspectJRMI  Aspect oriented communication middleware system  Plug in/plug out architecture: at compile time, users may explicitly select the features provided by the middleware  Middleware carriers code to provide a service iff it is demanded by the distributed application  Horizontal decomposition (Zhang & Jacobsen)  AspectJRMI Architecture  Core: basic RMI service (Java)  Aspects: additional/crosscutting services (AspectJ)
6. DOA - 20005 6 AspectJRMI Core  Arcademis: framework for middleware implementation (www.dcc.ufmg.br/llp/arcademis)  Similar to Quarterware; many design patterns of TAO  AspectJRMI Core: Arcademis instance providing a basic RMI service  Several reconfigurations: channels, middleware protocol, serialization protocol, name service etc  Memory footprint:  Core (Client): 37 KB  Core (Client/Server): 68 KB  The core is compatible with J2ME, i.e., it is really a minimal RMI
7. DOA - 20005 7 Aspects  Oneway calls  Asynchronous calls  Service combinators  Remote reference decorators  Call-by-value-result  Call-by-result  Collocation optimizations
8. DOA - 20005 8 Oneway Calls  void calls whose control returns to the client as soon the middleware layer receives the call  Abstract aspect: abstract aspect OneWayAspect { protected abstract pointcut OneWayCalls(); }  Example: aspect MyOneWayAspect extends OneWayAspect { protected pointcut OneWayCalls(): call(void Hello.sayHello()) || call(void A.*(..)); }
9. DOA - 20005 9 Asynchronous Calls  Suppose we want to provide asynchronous versions for the methods in the following interface: interface Hello extends Remote { String sayHello() throws ArcademisException; String sayHello(String name) throws ArcademisException; }  We should define an aspect that introduces in the interface an asynchronous version for each of its methods.  The asynchronous version must return Future, have a prefix async in its name and a body that just returns null. aspect AsyncHello { public Future Hello.async_sayHello() { return null; } public Future Hello.async_sayHello(String name) { return null; } }
10. DOA - 20005 10 Asynchronous Calls  Method getResult in class Future returns the result of an asynchronous remote call.  If the call has not finished, getResult waits its conclusion.  Example: Future ftr = server.async_sayHello("Bob"); ... String res = (String) ftr.getResult();
11. DOA - 20005 11 Call by-value-Result  Call by value-result is specified by defining formal parameters as having type Holder  Holder is a wrapper for the value passed by value-result void foo(Holder h1, Holder h2) { Date d= (Date) h1.getValue(); d.setDate(d.getDia()+1,12,2004); h2.setValue(new Date(28,2,2005)); } ....... Holder h1= new Holder(new Date(17,2,2005)); Holder h2= new Holder(new Date()); foo(h1, h2); ((Date) h1.getValue()).print(); // prints December 18th, 2004 ((Date) h2.getValue()).print(); // prints February 28th, 2005
12. DOA - 20005 12 Service Combinators  Used to combine remote calls in order provide fault tolerance, to decrease response time, and to provide load distribution  Suppose C1 and C2 are remote calls  AspectJRMI supports the following service combinators:  C1 > C2: C1 is invoked; if its invocation fails then C2 is invoked; if C2 also fails then the call fails.  C1 ? C2: either C1 or C2 is non-deterministically invoked. If the selected call fails, then the other one is invoked. The combinator fails when both C1 and C2 fail.  C1 | C2: both C1 and C2 are concurrently started. The combinator returns the result of the first call that succeeds; the other one is ignored. It fails when both calls fail.
13. DOA - 20005 13 Service Combinators aspect HelloClientAspect extends RemoteAspect { private RemoteRef ref; protected pointcut RemoteCalls(): within(HelloClient) && call(* Hello.*(..)); HelloClientAspect(){ String s1= "skank.inf.pucminas.br/helloSrv"; String s2= "patofu.inf.pucminas.br/helloSrv"; ref= new StructuredRemoteRef('>', new SimpleRemoteRef(RmeNaming.lookup(s1)), new SimpleRemoteRef(RmeNaming.lookup(s2))); } protected RemoteRef getRemoteRef(){ return ref; } }
14. DOA - 20005 14 Remote Reference Decorators  Remote reference decorators (aka interceptors in CORBA) are used to insert additional behavior in the invocation path of remote calls.  Additional behavior: cache, log, authentication etc.  Example: ref = new StructuredRemoteRef('>', new Log (SimpleRemoteRef(Naming.lookup(s1))), new Log (SimpleRemoteRef(Naming.lookup(s2))));
15. DOA - 20005 15 Collocation optimizations f1() {...} f2() {...} ... fn() {...} s= lookup(“obj1”); s.f1(); // remote call stub server object skel standard Java reference TCP/IP middleware  Servers and clients may be in the same address space  There is no need to use the middleware infrastructure  Remote invocations can be forwarded directly to the server  This strategy is usually called direct collocation optimization Address Space
16. DOA - 20005 16 Experimental Results  Memory footprint:  Core: 37 KB (client) ou 68 KB (client/server)  AspectJRMI: 50 KB  aspectjrt.jar: 41 KB  But there is also the weaving cost
17. DOA - 20005 17 Weaving Size (in KB) 100 calls ajc abc javac (abc-javac)/100 P1 Oneway 47.9 11.5 2.07 0.09 P2 Asynchronous 11.0 5.76 2.84 0.03 P3 Combinator ? 48.9 12.2 2.05 0.10 P4 Value/Result 8.67 5.53 1.92 0.03  The ajc compiler introduces a considerable overhead  Considering abc weaver, the weaving cost per call is acceptable  It ranges from 30 bytes/call (in P2 and P4) to 100 bytes/call (in P3)
18. DOA - 20005 18 Performance  In order to establish a comparison, we ported programs P1, P2, and P4 to JacORB, preserving their semantics  Program P3 was excluded since in JacORB there is no support to service combinators calls/seg Program AspectJRMI JacORB P1: oneway 3595 3426 P2: Asynchronous 2028 2159 P4: Value/Result 2192 2153  The performance of AspectJRMI is very close to JacORB
19. DOA - 20005 19 Collocation optimizations void foo (long size) throws ArcademisException { double a=Math.random(), b=Math.random(); for(long i=0; i< size; i++) { a=a*(b*(a*(b*(a*(b*(a*(a*(b*a)))))))); a=Math.random(); b=Math.random(); } } 0,00 1,00 2,00 3,00 4,00 5,00 6,00 7,00 8,00 9,00 10,00 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 Number of iterations calls/msec (collocated client) Without optimization With optimization
20. DOA - 20005 20 Conclusions  AspectJRMI applies aspect-oriented programming concepts to achieve the following requirements:  Modular implementation of its features, including those with a crosscutting behavior  Plug/plug out architecture: users can explicitly select the features provided by the middleware infrastructure  High degrees of configurability and adaptability  Performance similar to conventional middleware  However, its programming model is based on AOP concepts  Corba: oneway void sayHello(String s);  AspectJRMI: pointcut OneWayCalls(): call(void Hello.sayHello(String))
21. An Aspect-Oriented Communication Middleware System Marco Túlio Valente, Diana Leão, Rodrigo Palhares, Fabio Tirelo Institute of Informatics, PUC Minas Belo Horizonte, Brazil Distributed Objects and Applications (DOA 2005) Agia Napa, Cyprus, Nov 2nd, 2005