Wednesday, November 3, 2010

Quote of the day

Yes it is normal. But it should not happen anymore in the future.
Anonymous colleague

Monday, April 5, 2010

Zitat des Tages

"Nie wieder Krieg; Deutschland, nie wieder Krieg": Das sind alles Floskeln, die ├╝berhaupt politisch gar keine Rolle spielen d├╝rfen.

Rupert Scholz, CDU, Verteidigungsminister a.D., am 24 Juli 2007 im Bayerischen Rundfunk.

Sunday, March 28, 2010

Some thoughts about Axis2-Spring integration

A longstanding issue with Axis2 is its lack of decent Spring integration. Currently the only available Spring support in Axis2 addresses the use case of embedding a Spring container inside a service archive (AAR), i.e. implementing an Axis2 service using Spring. However, what most people are looking for is to embed Axis2 inside Spring, i.e. to configure and manage the Axis2 runtime (including the deployed services) using Spring application contexts.

There are two third-party projects that attempt to address this shortcoming. One is WSF Spring from WSO2. The other is a SourceForge hosted project called Axis2M Spring, which (apparently) started as a fork of WSF Spring, but has not yet been released. In this blog post I will have a look at these two projects, discuss their shortcomings and establish a wish list for a decent Axis2-Spring integration. Note that I didn't really test these two projects and that my conclusions are drawn from the project documentation and/or source code, so that I may have missed some aspects. Also, if you want to get an idea of what a good Spring integration for a Web services stack should look like, you should have a look at Apache CXF.

WSF Spring

The interesting thing in WSF Spring is that the entire Axis2 configuration can be done in Spring and that it gets rid of axis2.xml. That's a good thing because that file is notoriously difficult to maintain. One reason is that there is no XML schema for this file and that Axis2 doesn't do any validation, so that a typo doesn't trigger any error. The other reason is that axis2.xml is not modularizable, which means that to customize the configuration, you need to take the default axis2.xml file from the distribution and modify it. The problem with that approach is that it makes it difficult to distinguish the standard settings (e.g. the phase configurations and message receivers which rarely need customization) from the settings that are really specific to your project. What I would like to see is a mechanism that allows me to configure only those parts that really need customization. E.g. I would like to be able to declare the transports in my Spring configuration and to pull in the rest from default configuration files.

The problem with WSF Spring is that it actually replaces axis2.xml by Spring configurations that are much more obscure and ugly than the original axis2.xml. An example can be seen here. It also fails to address the modularization issue: simply, instead of doing this with axis2.xml, you now have to copy and edit an axis2Config.xml file.

Let's try to understand the reasons for these shortcomings in WSF Spring. The first one is that the framework doesn't provide Spring namespace handlers which would make the configuration syntax easier and would also enable validation (and autocompletion with an appropriate XML editor). The other reason is more subtle. In WSF Spring, the entire Axis2 configuration is actually provided by two beans. One is of type and has explicit references to other beans representing the different configuration items (transports, message receivers, message formatters, etc.) found in axis2.xml. The other one is of type and contains a collection representing the services to be deployed. This design is bad: things like transports, message formatters, etc., as well as (individual) services should be top level beans that are automatically injected into the Axis2 configuration. This would enable real modularization because it allows to build the configuration from a set of independent Spring configuration files without the need to reference the beans in these configuration files explicitly. Apache CXF proves that it is possible to do this.

Having identified the most important shortcomings in WSF, what else can be said about this framework? First, services are added in a way that mimics the deployment through services.xml (see here for an example). Because of AXIS2-4611, this implies that there is no support for JAX-WS. Thus, WSF Spring fails to address one of the most popular use cases, which is Servlet + Spring + JAX-WS. Also, looking at the code, it seems that WSF Spring doesn't support building the AxisService description from a preexisting WSDL. Finally, it should be noted that WSF Spring has no support for the client side.

Axis2M Spring

Since Axis2M Spring is a fork of WSF Spring, some of the issues we have identified for WSF Spring are also present in Axis2M Spring, namely the lack of JAX-WS and client side support, as well as the missing support for building AxisService descriptions from preexisting WSDLs. On the other hand, there are several important differences between these two frameworks. The first one is that Axis2M recognizes the usefulness of Spring namespace handlers to make configuration easier (although Spring namespace support is not really "the latest trend with spring based developments", but has existed for some time now...).

The second difference is that Axis2M Spring uses the traditional axis2.xml in addition to the Spring configuration (which is only used to define services and modules). Even if WSF Spring didn't get this part right either, this should be considered as a step backwards.

Another area where Axis2M Spring represents progress with respect to WSF Spring is the fact that services can be declared as top level beans, pretty much in the same way as other WS stacks do it. As explained earlier, this is important for modularization. Also interesting is the idea of implementing Axis2 modules with Spring configuration.

Wish list

From the above comments, it is clear that neither of the two frameworks considered in this post provides a definite solution for the Axis2-Spring integration problem. By looking at the issues that have been identified (and at Apache CXF...), it is easy to establish a wish list for Spring support in Axis2:

  • Support for JAX-WS. In particular the Spring support must provide an easy solution for the popular Servlet + Spring + JAX-WS use case.
  • All configuration (including the basic Axis2 configuration now done in axis2.xml) should be done in Spring and namespace handlers should be used consistently so that the configuration can be validated against an XML schema. Wherever appropriate, the configuration syntax should be similar to axis2.xml and services.xml to make transition easy.
  • Services as well as transports, message receivers, phase configurations, etc. should be top-level elements and they should be taken into account without the need to reference them from a central place, so that the configuration can be kept simple and modular.

Not mentioned in this wish list are the requirements that should be considered as prerequisites that must be satisfied by any Axis2-Spring integration (and that I didn't validate with the two frameworks considered in this post):

  • Correct lifecycle support for request and session scoped services.
  • Support for dependency injection and proxying for all user supplied objects: services, handlers, modules, password callbacks, etc.
  • Ability to run in a servlet container as well as standalone (e.g. with JMS transport only).

Saturday, March 27, 2010

How to connect JConsole to WAS 7

It's a bit tricky, but it's perfectly possible to connect (Sun's) JConsole to a remote WAS7 instance without any special server setup. You will only need to add a couple of JARs from the WAS runtime to JConsole's classpath. Also, the JMX URL to use is a bit special. Here is a Batch script for Windows that you can use as a starting point:

set JAVA_HOME=c:\Program Files\java\jdk1.6.0_17
set WAS_HOME=c:\IBM\WebSphere\AppServer
set CP=%JAVA_HOME%\lib\jconsole.jar
set CP=%CP%;%WAS_HOME%\runtimes\
set CP=%CP%;%WAS_HOME%\runtimes\
set CP=%CP%;%WAS_HOME%\runtimes\
set HOST=localhost
set PORT=9100
"%JAVA_HOME%\bin\jconsole" -J-Djava.class.path="%CP%" ^

PORT must be set to the ORB_LISTENER_ADDRESS in the WebSphere configuration.

Saturday, March 13, 2010

Improve your Maven builds with Groovy

Since Maven is essentially metadata driven, it sometimes lacks the flexibility provided by script oriented build tools such as Ant. Of course, the maven-antrun-plugin can be used to execute Ant tasks during the Maven build lifecycle. However, Ant has its own limitations. In those cases where neither Maven nor Ant provide a solution for a given problem, one may resort to Groovy as scripting language. Indeed, Groovy is very powerful and easy to learn for people familiar with Java. Here are two concrete examples where I used Groovy as part of a Maven build:
  • Axiom: Here a Groovy script is used to generate a file list, something which (surprisingly) cannot be achieved with standard Ant tasks.
  • Axis2: Here a test script uses Groovy to check a set of WSDL files produced by one of the Ant tasks that are part of the Axis2 tools. This script leverages Groovy's GPath expression language to navigate the nodes in an XML document and to build assertions on the content of the document.

Friday, February 19, 2010

Quote of the day

We think, with hindsight, that the complete separation of track and train into separate businesses at the time of privatisation was not right for our railways. We think that the separation has helped push up the cost of running the railways - and hence fares - and is now slowing decisions about capacity improvements. Too many people and organisations are now involved in getting things done - so nothing happens. As a result, the industry lacks clarity about who is in charge and accountable for decisions.

Chris Grayling, Tories, 2006, 12 years after his own party privatized British Rail.