Web Services for Spring with Axis2

WSO2 recently launched the beta of a new toolkit called "WSF/Spring" (Web Services Framework for Spring). I wanted to take a moment to discuss this and explain the differences between this and some other approaches.

The first question you might ask is "Don't Axis2 and WSO2 WSAS both already offer Spring support?". In other words - why something different.

Basically Axis2 and WSAS both offer a way of embedding Spring into them. So what happens is a request comes in, the Axis2 engine receives it, and when the time comes to execute some service code, the Axis2 engine uses a Spring application context to get access to a Bean and call that Bean. So effectively, Axis2 (or WSAS) is in control. All the WS-* handling (modules, Axis listeners and servlets, etc) are all still configured in Axis2 land.

Now, Spring is all about inversion of control, so let's invert the control pattern. Suppose Spring is in the hot seat now. How would that work? Well, you would use Spring to deploy a servlet, Spring to configure the mapping of requests to QoS (modules), Spring to configure Axis2, and Spring to wire up the request to the bean. Sounds a little more Spring-like! And this is what WSF/Spring is.

So what does this look like?

Here is an excerpt from the web.xml:

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<context-param>
<param-name>contextConfigLocation</param-name>

<!--Point to the application context of the application -->
<param-value>/WEB-INF/applicationContext.xml</param-value>

</context-param>

<servlet>
<servlet-name>axis2</servlet-name>
<servlet-class>
org.wso2.spring.ws.servlet.SpringAxis2Servlet
</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>axis2</servlet-name>
<url-pattern>/axis2/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>axis2</servlet-name>
<url-pattern>/services/*</url-pattern>
</servlet-mapping>

So this is basically a standard Spring style web.xml with a new Axis2 servlet defined.

Now you need to import the Axis2 configuration into your application context xml:

<import resource="axis2Config.xml"/>

What's in axis2Config.xml? Basically this is axis2.xml re-worked as Spring markup - e.g.:

<bean id="axisConfig" class="org.wso2.spring.ws.SpringAxisConfiguration">
<property name="parameters">
<list>
<bean id="hd" class="org.wso2.spring.ws.beans.ParameterBean">
<property name="name" value="hotdeployment"></property>
<property name="value" value="true"></property>

</bean>
<bean id="hu" class="org.wso2.spring.ws.beans.ParameterBean">
<property name="name" value="hotupdate"></property>
<property name="value" value="true"></property>
</bean>

etc.

Obviously you can edit this as needed.

Finally you have to configure some actual services, in your application context xml:
<bean id="services" class="org.wso2.spring.ws.WebServices">
<property name="services">
<list>
<bean id="bookService" class="org.wso2.spring.ws.SpringWebService">
<property name="serviceBean" ref="productManager"></property>
<property name="serviceName" value="TestProductManager"></property>
</bean>
</list>
</property>
</bean>

As you can see, the whole of the model is now integrated closely into the standard Spring/Tomcat model of exposing an application.

So how does this compare to Spring Web Services? Well, the first thing is that SWS is mainly about contract-first. And while contract first is an excellent practice, there are times when it is not appropriate - for example it may be simply too much effort for a simple first web service. WSF/Spring supports the POJO programming model simply and effectively, and generates the WSDL automatically from the beans you expose. (WSF/Spring does also expose contract-first). The second reason is simply that some users want to use Axis2. Axis2 is a very full featured and interoperable toolkit that does support some extra standards not yet available in SpringWS such as WS-SecureConversation, WS-Trust, WS-Policy and WS-ReliableMessaging. Axis2 also takes a very different approach to enabling these standards using the module approach rather than direct wiring of handlers.

I honestly don't believe WSF/Spring is "a competitor" to SpringWS. They offer different approaches and each have different benefits. Just as Spring users have a choice of different frameworks for databinding, MVC, etc, this adds one more framework to support Web Services into the excellent Spring framework. And they also share a lot of code - for example they both use Axiom and support many of the same databinding toolkits (JIBX, JAXB, XMLBeans).

One last note: WSF/Spring is still a little early code - so don't expect a fully released, beautifully documented release just yet. However, to look on the bright side --- this is a great opportunity to get your feedback in and contribute to the direction this takes!

A busy week for releases

Its been an amazing two weeks for releases - at least from WSO2! We released:

• Mashup Server 1.0 (http://wso2.org/projects/mashup)
  
• Mooshup.com - a community portal for writing and hosting mashups
• Web Services Application Server 2.2, including clustering, JMX and improved Data Services support
• ESB 1.6 (http://wso2.org/projects/esb)- also featuring JMX management, clustering support and improvements to several areas, plus some useful new mediators
• WSF/Spring 1.0 beta1 (http://wso2.org/projects/wsf/spring) - a new way of embedding Axis2 into Spring to allow Spring developers the chance to expose Spring applications as Web Services

With my Apache hat on, I helped release Apache Synapse 1.1.1 and move to our new home: http://synapse.apache.org. More about that later.

I'll also blog more about the WSF for Spring beta very soon too.

If you want the lowdown on the Mashup Server release, I'll pass you over to Jonathan Marsh who leads the project, and Ganesh, who has blogged about Mooshup.com.

The one thing I do want to mention is this: I think the Mashup Server embodies a new kind of middleware, and Jonathan takes huge credit for driving this vision inside WSO2. The Mashup Server inherently supports multiple users and the concept of each user having their own space. Of course this isn't new in the website world, but for Enterprise middleware this is part of a new world. The result - mooshup.com - the funky Web2.0 website - is running on the same code as the downloadable server. This is a story that is unfolding and my bet is that this will be a theme that really makes it big in 2008.

Mule launches Registry

MuleSource launched a Registry/Repository yesterday. I guess it looks remarkably similar to WSO2's:

• Both use a REST model
• Both use AtomPub - both via Apache Abdera
  
• Both support versioning
• Both support search

I haven't had a chance to really look at this yet, but I think there is one clear difference - and that is between Published Source and Open Source. WSO2's Registry development has been done completely openly - all discussions on an open mailing list, public commits, public SVN. This has encouraged at least two developers to get involved, start coding and submit patches.

When you look at the code commits here: http://svn.galaxy.muleforge.org/ you can clearly see that more than half the Galaxy code was checked in during the last week. Kudos to Dan for single-handedly coding this!

UPDATE: Anne Thomas Manes has written about this: http://apsblog.burtongroup.com/2008/01/mulesource-rele.html

Monitoring HTTP requests

One of the tools I use the most is TCPMON. Basically it acts as a proxy or sender for HTTP requests, but it lets you see them. Mainly I use it for SOAP, but it works for any HTTP traffic.
Now the Axis2/C and WSF/C projects have done a command-line version in C. Kau has blogged about it here. The benefit of this one is that (a) you don't need a JVM, and (b) its more like a Unix toolkit... it sits and logs to file. I won't be giving up on the Graphical version, but this is an extra tool in my toolbox.

Securing Web Services with Unix PAM passwords

One of the problems in security is how to store userids and passwords in a sensible way. Not everyone wants to set up a whole LDAP server. If you are on Unix/Linux you already have a solution - the default Linux password store.

Ruchith has built a link from Rampart to the Pluggable Authorization Modules (aka standard Linux/Unix authentication) via the JPAM project. A nice simple solution to the problem. Check it out.

Dims and IBM

Today Dims joined IBM. I'm sure its good news for IBM and for Dims... but I hope he continues hacking Android. His new management should take note that they have just hired one of the world's experts on a very hot technology. And he's pretty good at Axis2 as well :)