Upgrade to Pro — share decks privately, control downloads, hide ads and more …

An Aspect-Oriented Communication Middleware System (DOA 2005)

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

ASERG, DCC, UFMG

November 02, 2005
Tweet

More Decks by ASERG, DCC, UFMG

Other Decks in Research

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide

  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

    View Slide

  7. DOA - 20005 7
    Aspects
     Oneway calls
     Asynchronous calls
     Service combinators
     Remote reference decorators
     Call-by-value-result
     Call-by-result
     Collocation optimizations

    View Slide

  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.*(..));
    }

    View Slide

  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; }
    }

    View Slide

  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();

    View Slide

  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

    View Slide

  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.

    View Slide

  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;
    }
    }

    View Slide

  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))));

    View Slide

  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

    View Slide

  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

    View Slide

  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)

    View Slide

  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

    View Slide

  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

    View Slide

  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))

    View Slide

  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

    View Slide