Moose XML: A New OXM Integration

[MichaelQuigley]

Hello!

I've been working with a new XML binding framework, Moose. It's similar to XStream in that it's annotation-driven, but it handles namespaces properly and is suitable for use with web services.

Moose is able to generate an XSD from the classes contained in its mapping. This has been really handy for a couple of rapid web services development projects that I've been involved with--Moose provides a SimpleXsdSchema implementation that can be used to generate a WSDL dynamically. Essentially, this provides nice support for Java-first web services development. You can exclusively deal with annotations in Java code, and Moose automatically takes care of the schema for you.

I'd love to get some feedback on the framework!

http://quigley.com/moose/

Thanks in advance for taking a look...

[MichaelQuigley]

Any feedback? Anyone? Surely this must make someone else's life a good bit easier?

[skram]

It looks promising. I'm gonna check more the documents.

[MichaelQuigley]

The website hasn't been updated since April, but the project is very much still alive. It's just quietly serving its purpose handling XML duties for a variety of production web services.

There is an 0.5.0 release in the works. Included in this release is a convention-based mapping provider, so you don't even need the annotations on your beans. In other words, you just tell Moose about which classes need to be marshalled, and XML flows in and out automatically. We'll be keeping the annotation-based mapping support, as it's very useful in any sort of complex situation. And, if you're masochistic, you could even build your mapping right in a spring context using whatever mechanism trips your fancy. It's a very pluggable and layered framework.

There are also lots of bugfixes and minor enhancements.

If anyone has any questions, feel free to contact me here or on the website.

[skram]

In other words, you just tell Moose about which classes need to be marshalled, and XML flows in and out automatically. We'll be keeping the annotation-based mapping support, as it's very useful in any sort of complex situation.

This is one of the features I like about Castor. You just declare the classes that are needed and no need to annotate. But my curious mind is telling me "Why learn another XML framework?" I have nothing against your framework. I think it's just a logical question.

You mentioned in the article you wrote "Rapid Web Services Development with Moose XML":

Moose XML's schema generator is what distinguishes it from the other frameworks. The schema generator can generate an XML schema directly from your annotated Java beans. These generated schemas are useful for driving "contract last" web services development approaches

That's interesting but what about when dealing with Spring WS that focuses on "contract-first"?

[MichaelQuigley]

This is one of the features I like about Castor. You just declare the classes that are needed and no need to annotate. But my curious mind is telling me "Why learn another XML framework?" I have nothing against your framework. I think it's just a logical question.

Every Castor project I've been involved with has had a pretty extensive mapping document, telling Castor how to marshall and unmarshall Java classes. Any time I've ever needed to deal with collections of any complexity in my mapping beans, Castor has always been very painful. Moose endeavors to have much more straightforward collections support.

Moose has no need for any sort of mapping specification when using the convention-based configuration. It literally just needs to know what classes are part of the mapping and it Does The Right Thing using your beans.

The unit test suite has a simple unmarshall/marshall performance test comparing Moose's performance to Castor. In that simple case, Moose is substantially faster. It's on my to-do list to build more complicated scenarios for both for a more thorough comparison. Moose is much faster at marshalling and only slightly faster at unmarshalling. There are probably lots of scenarios where one is faster or slower than the other. I haven't explored all of those yet.

You mentioned in the article you wrote "Rapid Web Services Development with Moose XML":

Moose XML's schema generator is what distinguishes it from the other frameworks. The schema generator can generate an XML schema directly from your annotated Java beans. These generated schemas are useful for driving "contract last" web services development approaches

That's interesting but what about when dealing with Spring WS that focuses on "contract-first"?

Moose was developed after having worked on a handful of contract-first web services using Castor. When using Castor with Spring WS, there are 3 co-variant artifacts that need to be maintained: the java beans behind the mapping, the castor mapping xml, and the schema/wsdl. Any small change to the service interface requires all 3 of these elements to be changed in unison--which ends up being slow and mistake-prone.

In a Moose contract-last Spring WS implementation, there are a couple of beans that get plugged in to your context to handle the Moose mapping. From there, the WSDL is generated automatically from your annotated or convention-based Java beans, and because everything is driven off the Java source, there is nothing to get out of sync. In scenarios where you're trying to be agile, or prototype things out quickly, that usage pattern results in much faster development.

Automatically generating a WSDL from your Moose mapping is this easy:

	
<bean id="service" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition">
	<property name="schema"><ref bean="agentSchema"/></property>
	<property name="portTypeName"><value>Sugar3Agent</value></property>
	<property name="locationUri"><value>http://localhost:8080/agent</value></property>
</bean>

<bean id="agentSchema" class="com.quigley.moose.spring.MooseXsdSchema">
	<property name="mappingProvider"><ref bean="agentMappingProvider"/></property>
</bean>

Eventually I'd like to release a tool which can ingest an XSD and produce annotated Moose mapping classes which match. This will allow true contract-first usage scenarios on top of Moose with the same convenience as our contract-last model. In that scenario, you could just make changes to your XSD/WSDL, and Moose would take care of generating the rest of your mapping layer for you.

There are lots of XML binding frameworks out there. I'm not trying to say that Moose is the best in every case. If you need to rapidly develop a Spring WS-based web service and you want to do it with a minimum of hassle, it makes life pretty easy. There are definitely some itches that Moose is really good at scratching.