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.
Originally Posted by skram
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.
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.
Originally Posted by skram
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:
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.
<bean id="service" class="org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition">
<property name="schema"><ref bean="agentSchema"/></property>
<bean id="agentSchema" class="com.quigley.moose.spring.MooseXsdSchema">
<property name="mappingProvider"><ref bean="agentMappingProvider"/></property>
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.