JAsCo an Aspect-Oriented approach tailored for Component Based Software Development This presentation covers a paper of the same name found at: http://www.umcs.maine.edu/~huang/readings/JAsCo.pdf Because the audience may not be familiar with aspect oriented programming (AOP), the first few slides give a very rough overview of AOP. The later slides describe the JAsCo language and implementation.

Crosscutting Concerns public long doSomething() { if(!Security.isAuthorized()) { return AUTHERROR; } Transaction.begin(); try { doTheThing(); Transaction.commit(); } catch(Exeception e) { Log.error(e); Transaction.rollback(); return 0; Most real systems/applications have many concerns other than just getting the job done, e.g. security, database consistency, synchronization, logging, etc. Once all the business concerns of a system have reared their ugly heads, code meant to do something simple can become very busy. This is a contrived example, similar to an example you would find in any introduction to AOP.

Security public long doSomething() { if(!Security.isAuthorized()) { return AUTHERROR; } Transaction.begin(); try { doTheThing(); Transaction.commit(); } catch(Exeception e) { Log.error(e); Transaction.rollback(); return 0; We have to do a similar security check all over the application. Fortunately, in this mock example, we have a security component that makes access checking very simple, but we are still reliant on every component being aware of, and using, the Security component.

Consistency public long doSomething() { if(!Security.isAuthorized()) { return AUTHERROR; } Transaction.begin(); try { doTheThing(); Transaction.commit(); } catch(SomeErrorEvent e) { Log.error(e); Transaction.rollback(); return 0; Once again, we have magic component that simplifies the transaction mechanism for us, but in order for our components to use it, we are reliant on –every- component being aware of and utilizing this transactional component.

Logging public long doSomething() { if(!Security.isAuthorized()) { return AUTHERROR; } Transaction.begin(); try { doTheThing(); Transaction.commit(); } catch(Exeception e) { Log.error(e); Transaction.rollback(); return 0; Most exceptional conditions require some logging. For this contrived example, we are assuming that the calling code will check the Transaction component to see if a rollback occurred. Perhaps it could also obtain the error from the Log component.

Actual Purpose public long doSomething() { doTheThing(); } The actual thing this method wanted to accomplish was very simple, but we had to go and clutter it up. Wouldn’t it be nice if we could avoid all that repetitive code and even make it where our components didn’t have to be aware of every single one of our cross cutting concerns?

Join Points Method Invocations / Property Accesses On Events Interceptor Glue Code/ Component/ Environment Component To summarize, join points are places where it would be advantageous to inject our code, i.e. before or after a method invocation, in place of a method invocation, and when an event fires. So in our previous example, we could replace the method firing with a call to the Security component, which would fire the method if it decided that the invocation was allowed. Similarly, the Transaction component would intercept the invocation before it happened and begin a transaction, and then commit that transaction after the invocation. Likewise, when the method tries “doSomething(),” an Event occurs and in response, the Transaction component would rollback the transaction (and then after the invocation it would recognize that it had already committed.) Finally, the Log component would be invoked in response to the error event, and it would log the error. Invocation Event

Weaving Component Logging Aspect Subclass Security Aspect Some implementations of AOP achieve their goal by (at runtime or compile time) incorporating the configured aspects into the component, via subclassing, byte code injection, or a similar method. This is known as aspect weaving. Weaving has undesirable side effects. Firstly, the aspect code is copied into and becomes a part of whatever class it is applied to. This means the aspects lose their identity at runtime, and are, in general, statically bound to the classes they advise. doSomething()

JAsCo Keywords hook connector execute cflow on event * [signature wildcards] JAsCo extends Java with just 5 keywords plus a special wildcard syntax used in the constructor to a hook. (See the paper for definitions) It should be noted that the extra keywords are just for brevity. It is possible to implement all the functionality of the JAsCo model using regular Java, although modifications to the byte code of non-aspect enabled components would still be necessary.

This shows the definition of an aspect bean (component) This shows the definition of an aspect bean (component). An aspect bean is no different from a normal Java Bean except that it contains hook definitions which describe when it should join. The hook definition also may contain the definitions of the before, after, and replace methods, which define a hook’s behavior. An important feature of JAsCo is that the hook does not define what sort of methods/events are intercepted.

These are some connector definitions These are some connector definitions. Connectors are what attach aspect bean hooks to method invocations and events. Inside a connector it is possible to specify the order of the hooks, and what part of the hooks should be applied. Notice that connectors instantiate hook instances with the signatures that they will be applied to.

At run time, components have either been written with, or had their byte code altered to contain traps that make calls to the connector registry whenever a public method (or property change) is invoked or an event is fired. The traps cause the connector registry to determine which connectors match and to apply the relevant hooks as specified by the connector. Another important feature of the JAsCo architecture is that both connectors and aspect beans are available at runtime (since traps always result in action by the connector registry, they should be), so it is possible to dynamically apply and remove aspects to/from other components while running. For example, it would be possible to apply the logging aspect to different parts of a running application server via a control console.