SURVEY: Real world SOAP web services

[BluSynergy]

I'd like to know what the grails community is using for exposing and consuming SOAP web services for medium sized apps (say 50-100 domain classes with complex inter-relationships between the classes). On the server side, while I agree with the principles behind the wsdl-first approach, the thought of manually creating the XML schemas and wsdl for this many domain objects manually and then doing the mapping logic makes me shudder. The code-first approach is at least easy to get going. I'm aware that if I change my domain objects it will change the WSDL contract, but hopefully these will be forward compatible changes (new properties and relationships will be nullable, etc.) I'd consider the DTO approach, but that would put me back in the bloated mapping logic biz again.

So I'd like to survey what the community is doing:
1. Are you doing the contract-first or code-first approach?
2. What SOAP plugin/framework are you using for exposing your SOAP web services (server side)?
3. What  plugin/framework are you using for consuming other SOAP web services (client side)?
3. Any issues or pitfalls with your approach? (eg: compatibility with versions/plugins, functional limitations such as WS-* requirements). If you were to start fresh, would you do anything differently?

Thanks. Please note that the REST vs SOAP debate is not an option for our situation.

[thorstadt]

1. Code first.
2. grails-cxf
3. GroovyWS
4. I'm having to work on the grails-cxf plugin as our requirements grow. Just today I had to add support for JaxWS annotations so that we could force our WSDL into the format that Quickbooks expects without having to go all wsdl-first. For consuming services, we use GroovyWS. Unfortunately, there appear to be some threading issues. (Specifically the issue seems to be that the proxy classes that are generated can only be used from the request/thread that originally loaded them.)

The biggest roadblock we encountered was that development has basically ceased on Xfire and there are some non-trivial dependency conflicts between Xfire and GroovyWS, which caused grails-xfire to break GroovyWS. Hence grails-cxf.

BluSynergy wrote:

So I'd like to survey what the community is doing:
1. Are you doing the contract-first or code-first approach?
2. What SOAP plugin/framework are you using for exposing your SOAP web services (server side)?
3. What  plugin/framework are you using for consuming other SOAP web services (client side)?
3. Any issues or pitfalls with your approach? (eg: compatibility with versions/plugins, functional limitations such as WS-* requirements). If you were to start fresh, would you do anything differently?

Thanks. Please note that the REST vs SOAP debate is not an option for our situation.

[BluSynergy]

Thanks for the response. Hmm, I was not aware that xfire plugin development has ceased - that is a bummer given that it seems to be the most mature of the code-first WS plugins. I did try metro and got a bunch of exceptions as soon as it encountered a complex domain model. I cant' remember what I encountered with the axis2 plugin, but there were some show stoppers there as well.

How does the CXF plugin deal with bidirectional mappings? eg the child domain and the parent domain classes have references to each other (belongsTo, hasMany or direct instances). Also, does it deal with embedded classes?

[thorstadt]

I'm not sure if the Xfire plugin development has ceased, but the Xfire framework is deprecated (according to http://xfire.codehaus.org) in favor of CXF.

First, you will need to annotate your domain classes with @XmlAccessorType(XmlAccessType.FIELD) so it doesn't choke on the metaclass. There isn't much to the CXF plugin -- it mostly just does some dynamic spring wiring. grails-cxf uses the JAXB data binding built into CXF. For cyclic domain classes, you may want to take a look here: https://jaxb.dev.java.net/guide/Mapping_cyclic_references_to_XML.html. A few annotations will probably be all that it requires to prevent JAXB from getting confused.

I would be happy to help you out if you have any difficulty.

BluSynergy wrote:

How does the CXF plugin deal with bidirectional mappings? eg the child domain and the parent domain classes have references to each other (belongsTo, hasMany or direct instances). Also, does it deal with embedded classes?

[Luke Daley]

On 30/10/2009, at 5:17 AM, BluSynergy wrote:

> 1. Are you doing the contract-first or code-first approach?

contract-first.

> 2. What SOAP plugin/framework are you using for exposing your SOAP web
> services (server side)?

Spring-WS.

> 3. What  plugin/framework are you using for consuming other SOAP web
> services (client side)?

Spring-WS.

> 3. Any issues or pitfalls with your approach? (eg: compatibility with
> versions/plugins, functional limitations such as WS-* requirements).  
> If you
> were to start fresh, would you do anything differently?


Spring-WS has met my needs well.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[BluSynergy]

Are there any links to using the SpringWS plugin other than this: http://grails.org/plugin/springws ?

I'm not up to speed on the java side of SpringWS itself, and googling for grails usage examples with this plugin yielded few worthwhile results. In particular, I'm eager to see some real world examples of how the WSDL creation and mapping is performed (manually?) when a large number of domain objects are in play.

[Luke Daley]

On 05/11/2009, at 6:25 PM, BluSynergy wrote:

> Are there any links to using the SpringWS plugin other than this:
> http://grails.org/plugin/springws ?

None that I am aware of.

> I'm not up to speed on the java side of SpringWS itself, and  
> googling for
> grails usage examples with this plugin yielded few worthwhile  
> results. In
> particular, I'm eager to see some real world examples of how the WSDL
> creation and mapping is performed (manually?) when a large number of  
> domain
> objects are in play.

Spring WS is very much contract first.

It does not enforce how you deal with payloads, but has pluggable  
support for different xml marhalling/binding technologies like JAXB.

For my application, I wrote Marshaller and Unmarshaller  
implementations based on Groovy's MarkupBuilder and XmlSlurper.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email