Aspect Oriented IT fits BEA Liquid Computing

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Last week I attended eWorld, mainly as a speaker. It was a unique view on BEA's Liquid Computing vision kick off. Where AOP fits in Liquid Computing vision ? Why should we go on simplifying the AOP stack as our motto in AspectWerkz : full Java, J2EE integration, Java 1.5 readyness, value added Aspects, tool ecosystem... ?

Liquid Computing is the vision for a Simplified Enterprise Computing. Don't think it is SOA. SOA is what BEA provides today with Platform 8.1, but tomorrow, it will be something more.
"The time has come for a comprehensive vision for IT. One that improves business responsiveness by simplifying enterprise computing."
- Alfred S. Chaung
Founder, Chairman & CEO
BEA Systems, Inc.

Reading more in BEA's Liquid Computing pdf brochure, I found it is good exercise to emphasys on specific topics where AOP is a key way to enable Liquid Computing.

Note: the following is my own personnal vision and does not illustrates any official statement from BEA.

Active Adaptability: "Dynamic instrumentation and monitoring will track, display and manage system capabilities. At the core, the infrastructure
is constantly tuning itself in the service of the business."



Self healing policies can be easily builded on Dynamic Aspects.

Dynamic weaving capabilities of BEA JRockit and AspectWerkz has been demonstrated at our eWorld session, activating JMX reporting at runtime, in a web service / pojo based application running on 8.1 and a not yet released version of JRockit.



We can extend the demo to dynamically weave a caching aspect at our web service level to provide a business specific self healing policy. All this stack could be builded in 1 day based on AspectWerkz dynamic AOP stack, no matter the application complexity itself.



This is active adaptabilty now, on Platform 8.1. The same key idea can be enabled today on your older WebLogic Server 6.1, or on your Tomcat stack - whatever is running Java 1.3+ can be handled by AspectWerkz Dynamic AOP.

Enterprise compatibility: "the application just plugs into a
compatibility layer [Compatibility Fabric], rapidly delivering and sharing new
capability."



Cross cutting requirements can be addressed rapidly by AOP technologies.

The AOP stack is the compatibility fabric of the cross cutting concerns inherent to all software applications. Thinking AO enables to decouple this concern and address it as a single requirement, allowing change at this level only, to provide the same functionnality with a different underlying implementation but without any change in the application that serves your business.



At our session we have demonstrated an authentication / authorization service implemented in AO. The underlying implementation was using JAAS. It can now be easily enhanced to provide an implementation specific to any IT environment, be it JAAS compatible or not, be it LDAP based, or be it with very specific policies. This software complexity is reduced to the Aspect, and does not impact the functionnal requirements of the application.


It is not WebLogic specific. The same AO stack can be used to secure a Swing based application as well.



The AO implementation brings cross application security live in a minute, no matter the complexity of the application(s) and the IT environment. For more complex requirements, this AO implementation can be enhanced with business specific rules (application flow, business rules, dynamic activation of policies) by adding aspects on the stack, where those are needed.

Breakthrough Productivity: A powerfull engine that extends self-service "into meaningful application functionality. It gives business owners
the ability to make changes to processes and capabilities on their own.[..] There’s no downtime, no need for traditional re-programming and, because IT maintains governance, no loss of IT control."



Self servicing can be enabled thru a dynamic AO stack. Deploy a new aspect that encapsulates a new functionnal requirement, and have it inserted in your running application with dynamic AO, and metadata driven programming.



Metadata driven AOP brings self-servicing to a new IT control era, where model driven architecture can be unleashed by an AO based service stack. Add a cache on service methods, no matter the application was designed for a cache requirements. Change this cache to be distributed, single user based, or for the flow of this specific use-case. Add a JMX reporting layer on it to control cache hit count. Remove this cache when system is not under load.

At our AOP: SOA for the application eWorld session, we have demonstrated hot acitvation of a caching aspect while application was live. We have extended the cache scope to some other business method at a later point, just by using a tool and 3 mouse clicks.



AO solves a traditionnal multi-step IT project iterations in a disruptive way. Pick vendor certified aspects, hotdeploy them with tools and have them bringing your IT to the next generation of your requirements without any downtime. This is Breakthrough Productivity. I would have wrote Disruptive Productivity.

Conclusion: Go live with AO !



The three key concepts of Liquid Computing are part of Aspect Oriented Technologies and especially full java dynamic AOP stacks like AspectWerkz. A good aspect set, tools ecosystem and manageability of the AO layer itself disrupts the classical vision of IT projects. "Design, develop, QA, deploy" is turned into an on demand self servicing layer allowing you to concentrate on your assets. Dynamic AO brings Active Adaptability, address Enterprise Compatibilty and provides Disruptive Productivity.
The AO ways decorrelates your IT complexity from the complexity to address new requirements. Changes are made easy.

I hope this high level view on AO, the issues we aim to address everyday as an AOP stack builder, and the demo we can do today convince you that Aspect Oriented Technology is a key piece of the Liquid Computing puzzle.



Up to us to bring all this value to you now.

Make it live today with AspectWerkz. Ask for docs, demos, support, articles, tutorials. Join us in this aspect and tool ecosystem building.

Go live with AO. Go live with Liquid Computing. Go live with AspectWerkz.

AOP integration in Tomcat 5

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

On several recent ML post AspectWerkz users complained about getting into troubles when hooking in AOP in Tomcat 5. Steve provided good feedback but ... there is off course a damned better way to handle that !

Here is a little hands on that gives the idea for a 5 minutes shot.
Pretty much straigthforward based on

• cvs head ie the next 1.0 beta and not 0.10


• no integration detail, just some bin/aspectwerkz.bat magic


• aop.xml deployed wihin the target application itself


• a little fix in a strange Manifest.mf file in qdox-1-3.jar

I was concerned about this issue and had an hectic face to face burger discussion with Jonas about "my" so called seamless integration of AOP... I needed to sit down on that and hack, too bad for the jet lag in this crazy GMT 9h far from home SF BEA eWorld clock.

Since the Codehaus had to migrate some CVS details today, the little qdox.jar fix that is needed cannot be commited, but just do it yourself if you want to go on with those explanations. Or wait tomorrow since Bob the despot is around there as well... He'll fix that for me if he is not too busy on the new Codehaus / BEA BeeHive stuff there.

So I took a Tomcat 5 from Apache, unzipped the stuff on my windows box.
I checked that it was fine with the bin/startup.bat and shutted it down to spread AOP in.

Then I made sure that AW *cvs head* was builded, and ASPECTWERKZ_HOME and JAVA_HOME was set.

I decided to give a try to this integration issue and decided to start with a silly tracing aspect that is sitting in AW samples (examples.logging.JavaLoggingAspect). I then builded the samples with a maven target (aspectwerkz:samples:compile)and had a new target/aspectwerkz-samples.jar ready to use.

Then I just opened this bin/catalina.bat that is actually starting things and added this just before the comment:

        rem Execute Java with the applicable properties
        ...

to have AOP seamless integration:

        set CLASSPATH=%CLASSPATH%;%ASPECTWERKZ_HOME%\target\aspectwerkz-samples.jar
        set _EXECJAVA=%ASPECTWERKZ_HOME%\bin\aspectwerkz.bat
        set JAVA_OPTS=%JAVA_OPTS% -Daspectwerkz.transform.verbose=false

So as you see I go with the bin\aspectwerkz.bat way, which is the easiest kick off stuff we provide, with adaptive behavior regarding Java version detection etc, even if when it comes to production usage I would rather use some JRockit VM.

You will have noticed that I just added my silly tracing sample aspect in the CLASSPATH and replaced bin/java call by bin/aspectwerkz.bat - not taking care about the details.

From there, Tomcat started up *almost* fine. The AW/lib/qdox-1.3.jar has a strange Manifest.mf file that Tomcat complains about... Just dropped this Manifest.mf from the qdox.jar and we are up and running with AOP online mode / class load time weaving / AOP container from cvs head.

Time to bind my system level tracing Aspect to some application.
I did a try by writting a 5 lines aop.xml file (actually copy pasted it from AW samples/hotdeployed.xml) and dropping it in Tomcat samples in webapps\servlets-examples\META-INF\aop.xml, since this is what we now provided in cvs head (and not in 0.10).

Once that done, nothing happened. I added some tracing stuff (-Daspectwerkz.transform.verbose=true) and figured out (with a bit of pain since toString() on Tomcat classloader is damned too much verbose..) that Tomcat classloader is not taking this META-INF topmost stuff into account.

I decided to move that to the WEB-INF/classes path, so ending up in webapps\servlets-examples\WEB-INF\classes\META-INF\aop.xml [file below]. I ll double check that later since this WEB-INF/.../META-INF is a bit strange there.

and here it is (once I browsed to http://localhost:8080/servlets-examples/)

METHOD_EXECUTION--> filters.ExampleFilter::doFilter
  METHOD_EXECUTION--> HelloWorldExample::doGet
  METHOD_EXECUTION<-- HelloWorldExample::doGet
  METHOD_EXECUTION--> filters.ExampleFilter::toString
  METHOD_EXECUTION<-- filters.ExampleFilter::toString
METHOD_EXECUTION<-- filters.ExampleFilter::doFilter
METHOD_EXECUTION--> filters.ExampleFilter::doFilter
  METHOD_EXECUTION--> SessionExample::doGet
    METHOD_EXECUTION--> listeners.SessionListener::sessionCreated
      METHOD_EXECUTION--> listeners.SessionListener::log
      METHOD_EXECUTION<-- listeners.SessionListener::log
    METHOD_EXECUTION<-- listeners.SessionListener::sessionCreated
  METHOD_EXECUTION<-- SessionExample::doGet
  METHOD_EXECUTION--> filters.ExampleFilter::toString
  METHOD_EXECUTION<-- filters.ExampleFilter::toString
METHOD_EXECUTION<-- filters.ExampleFilter::doFilter

aop.xml

<!DOCTYPE aspectwerkz PUBLIC
    "-//AspectWerkz//DTD//EN"
    "http://aspectwerkz.codehaus.org/dtd/aspectwerkz.dtd">
<aspectwerkz>
    <system id="sample">
        <aspect class="examples.logging.JavaLoggingAspect">
            <pointcut name="pc" expression="execution(* *..*.*(..))"/>
            <advice name="logMethod" type="around" bind-to="pc"/>
        </aspect>
    </system>
</aspectwerkz>
]]>

Conclusion
We are almost there and 1.0 will be damned good don't you think ?

See you at eWorld

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

I am moving to San Francisco for BEA eWorld.

Jonas and I will give several sessions / demos about AOP in BEA JRockit and the BEA WebLogic Platform, including WebLogic Server and WebLogic WorkShop.

In case you are in the area but do not attend to eWorld, just join the Silicon Valley BEA User Group since we will be there on wedsnesday as well.

We have been under the radar since AOSD, so be ready for something disruptive !
I will post a viewlet of some parts of the demo in some weeks.

dynamic AOP and HotSwap

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

In a recent post Bill Burke describes his preliminary research as regards HotSwap usage for dynamic AOP.

He first defines in a few words what is dynamic AOP and what is the HotSwap or class redefinition in Java. Then he briefly describes how JBossAOP handles
dynamic AOP thru a "prepare" phase, and gives some measurements about the overhead he obtained when using the -Xdebug mode during a JBoss startup sequence, an option required to activate the HotSwap API under Java 1.4.

I would like to give some feedback on his post, since I have been working in the dynamic AOP field for some time now thru my involvment in AspectWerkz and
thru a research paper and a runtime weaving prototype I did for the Dynamic Aspect Workshop for AOSD 2004.

I think dynamic AOP has to be splitted in two categories:

• rearranging AOP constructs at existing join points


• redefining join points (we could generalize with redefining pointcuts, or even redefining the whole AOP system)

The first category is fully supported by AspectWerkz. It is possible to rearrange (add/remove/reorder) aspects and advices at runtime providing that the join point(s) where the construct(s) is(are) bounded is(are) already existing as a result of the transformation phase, no matter it is a post compilation phase (ala AspectJ) or a class load time weaving.



As regards introductions, AspectWerkz allows to change the introduction implementation (thus the implementation of the added methods) at runtime (swap mixin implementation), again providing that the binding (which mixin(s) applies to which class(es)) is already existing.



This first category relies on the framework capabilities and several means allow to minimize the overhead when f.e. no advice is bounded at a particular join point.

The overhead even if minimal cannot be avoided here. Even reduced to a method call that does a boolean check, this is not the original bytecode instruction sequence which is running when the join point is reached.

This category is the one supported by JBoss as well.

The second category is the most interesting one. Redefining join points (thus pointcuts) allows - in theory - to add new AOP construct at new locations (join points) in the running application.
This should come with the guarantee that there is

• absolutely no runtime overhead prior the "activation" of the new join points, and no overhead after "deactivation"


• no assumption that the join points are known before activation (especially at class load time / application deployment time)

I think that this second category requires runtime weaving capabilities from the AOP framework (as long as the AOP frameworks rely on bytecode instrumentation).

A use-case for join point redefinition at runtime is some on-demand profiling tool that needs to activate profiling only when necessary, for a limited time, and without any overhead prior to activation, and without specific knowledge on what will be profiled at application deployment time.

As Bill explains, JBossAOP "addresses" the second category by providing a way to declare pointcuts with nothing bounded. This definition is used at class post compilation / class load time and is what Bill calls the "prepare phase".


The overhead involved by such an approach is not measured by Bill, but is conceptually limited to a boolean check and a method level indirection, this for each pointcuts declared for future activation.


I don't think this approach is really adressing dynamic AOP. The overhead at a single join point level is indeed minimal, but we might have a need to declare very invasive pointcuts to allow further on-demand profiling (or other AOP based constructs), and thus this minimal overhead might occurs trillions times in the running application (potentially at each method call, each method execution and each field access).

So what might be a better solution for true runtime join point redefinition ?

As Bill quotes, HotSwap API allows to change the implementation of method / constructor bodies of a class at runtime, and inject them in the running JVM.


There are some interesting things to consider, that Bill forgot to mention and led him to some approximative statements (I forgot to told him ;-) )

• HotSwap is an optional JVM capability. Some JVMs do not have HotSwap support (f.e IBM JRE)


• HotSwap might forbid class schema change. It might not be possible to add new methods (even private ones) to a class when redefining it. This schema change support is itself an optional HotSwap capabilitiy. Currently no JVM supports schema change, but the API does not restricts it.


• HotSwap exists since Java 1.4, requires -Xdebug mode, and can only be called from a remote JVM (well almost, read below)


• HotSwap is slightly modified in Java 1.5 and does not requires -Xdebug mode

So considering what HotSwap can do, and what bytecode instrumentation oriented AOP frameworks do to enable AOP in Java OOP, especially to enable dynamic AOP constructs of the first category I described previously, HotSwap seems very attractive, but is currently missing key things.


There might be some ways to address the problems thought...

The fact that the java level HotSwap API as described in Java 1.4 JPDA requires a remote JVM attached to the running JVM (or a JPDA LaunchingConnector) can be avoided by implementing a JNI layer on top of the C-level HotSwap API so that HotSwap is available at Java level, without coupling with the JPDA architecture: no need for a remote JVM, and no need for a LaunchingConnector (that would forbid further remote dedbugging ...).


I describe the advantage of this JNI glue in the work I submitted to the DAW AOSD 2004, and call it "in-process HotSwap". We have it in Java 1.5 so there is no problem on this side anymore.

The "in-process HotSwap" - Java level API - is standardized in Java 1.5 thru the JSR-163. Java 1.5 will not requires -Xdebug to enable the HotSwap API. As you might have understood, the HotSwap API is not that coupled to the JVM debugging capabilities, althought the API was part of the same block in Java 1.4.


The -Xdebug overhead issue raised by Bill is fixed (though I would like to do measurement of what -Xjavaagent in Java 1.5 involves).

The schema change support would be interesting for AOP join point redefinition, since as Bill explains, AOP frameworks that allow dynamic AOP (AspectWerkz, JBossAOP) require some structural changes to bring in enough indirection level between the join point (in the weaved classed) and the AOP constructs (handled by the AOP framework internals).




A simple bytecode decompilation of an AspectWerkz weaved class with execution pointcut will show you that AspectWerkz has added a wrapper method to handle the join point and renamed the original method, since it will be called by the framework as a result of the execution join point construct.


class Foo {

public void doAction() {
// the bytecode for your code
}

}


can appeared transformed after the weaving as (approximation)


class Foo {

JoinPointManager __AW_joinPointManager =...

public void doAction() {
__AW_joinPointManager.proceed(this, "doAction()");
}

private void __AW_doAction() {
// the bytecode for your code
}
}


As a consequence, if we would like to be able to redefine (f.e. simply define) the "* Foo.doAction(..)" execution pointcut at runtime, we would need schema change support. The schema change support might not be needed though for caller side constructs.


The problem is thus more a HotSwap API problem, tight to current JVM limited capabilities.

I think that HotSwap - if largely adopted by JVM implementation - can be a good enabler for dynamic AOP as regards pointcut redefinition at runtime. I don't think that the debate is limited to a -Xdebug option, and Java 1.5 demonstrates it.


In the work I submitted to the DAW AOSD 2004, I describe how we are able in an AspectWerkz prototype to redefine pointcuts at runtime even without schema change support.

I agree that this solution (which I will publish later in my blog) is itself not optimal but I was able to demonstrates the feasability of such an on-demand AOP approach, instead of an invasive pointcut definition, that might itself lead to a globally large overhead. I was able to do the prototype with Java 1.4, and it will be even more easy to do with Java 1.5 and the standardized "in-process" Java level HotSwap.


I will debate if HotSwap is good for dynamic AOP at the DAW AOSD workshop, and you bet, some more JVM level AOP support might be crucial on this area.

So far so good, what do we wanted ?

Probably not a low level "addPointcut(<pointcut pattern>, Class klass)" API with a controlled and guaranteed minimal (or even zero) global overhead prior activation, but maybe a more usefull system wide control like "addAOPSystem(ClassLoader klassScope, SystemDefinition definition)" to be able to activate AOP constructs as a whole, at runtime, and leaving the internal recipe of it to AOP solutions and JVM implementations ...

Right ?

It's life

(imported from http://blogs.codehaus.org/people/avasseur, read comments there)

Most of my blog' fans (do I have blog fans ?) might think I am hacking AOP constructs and weaving architecture all the day.

Well I have to admit that this is not exactly true, thought almost true ;-).

These days I had to hack a small app that gather data from a WebLogic Server farm (more than 60 servers) by querying runtime JMX mbean so that we can then generate some graph to feed a NOC intranet.
Rather simple to play with JMX, have a fault tolerant client that does not crash when one instance is downed, and be able to handle at least 10 Go log daily.

For now the logs are parsed and consolidated as regular file. I would have liked to use a MySQL or HSQL database instead of parsing Go of files... but well, it is a customer driven story.

Here is a pretty cool graph that I got using JFreeChart that shows some http session data history grabbed from a subset of the farm.
Fun ?