Interface21 has announced the release of Spring Web Services 1.0, a comprehensive Web services stack for developing and consuming SOAP and POX (Plain Old XML) Web services. Spring Web Services 1.0 facilitates the creation of contract-first, document-driven Web services, delivering the flexibility, productivity and ease of use benefits of the Spring Framework to the Web services environment.
Contract-first, according to the explanation page, is where one writes (or generates) the WSDL for the service before writing the implementation, as opposed to the JAX-WS mechanism, where the Java code is written and the API generates the WSDL from that.
Similar to the field of ORM, where we have an Object/Relational impedance mismatch, there is a similar problem when converting Java objects to XML. At first glance, the O/X mapping problem appears simple: create an XML element for each Java object, converting all Java properties and fields to sub-elements or attributes. However, things are not so simple as they appear: there is a fundamental difference between hierarchical languages such as XML (especially XSD) and the graph model of Java. Note that most of the contents in this section was inspired by Rethinking the Java SOAP Stack and Effective Enterprise Java.
Contract-last has fragility problems (where the API might change over time, as the implementation changes), potential issues with cyclic graphs (where class A has a reference to class B, and class B has a reference to class A), conversion issues (the example given in the page referenced is that of a date, which Java represents as a time), performance (where the actual data marshaled might be more than you expect), and versioning (which is part of fragility, and Spring-WS addresses through mechanisms such as XSL to modify the request/response to match a requirement.)
Spring Web Services 1.0 also facilitates best practices such as the WS-I basic profile, and loose coupling between contract and implementation, allowing for the creation of flexible Web services using one of the many ways to manipulate XML payloads. By providing developers with a simpler approach to contract-first development, Spring Web Services 1.0 resolves many of the interoperability issues associated with typical Web services approaches.
Additional features of Spring Web Services 1.0 include:
- Incoming XML requests can be distributed to any object, depending on message payload, SOAP Action header, or an XPath expression.
- XML API Support – Incoming XML messages can be handled in standard JAXP APIs such as DOM, SAX, and StAX, but also JDOM, dom4j, XOM, or even marshalling technologies.
- Flexible XML Marshalling – The Object/XML Mapping module in the Spring Web Services distribution supports JAXB 1 and 2, Castor, XMLBeans, JiBX, and XStream. Because it is a separate module, it can be used in non-Web services code as well.
- Reuse of Spring Framework Concepts – Uses Spring application contexts for all configurations. Additionally, the architecture of Spring Web Services resembles that of Spring MVC.
- WS-Security Support – Allows developers to sign SOAP messages, encrypt and decrypt them, or authenticate against them.
- Integration with Spring Security – The WS-Security implementation of Spring Web Services provides integration with Spring (Acegi) Security, enabling developers to use existing configuration for SOAP service as well.
Interface21 has a tutorial on using Spring-WS to write contract-first services, of course, that walks through the process.
So how does this affect Spring-Remoting? Your Humble Editor isn't sure; chances are both projects will continue to be part of the Spring portfolio. (We'll have an answer for this soon.) Spring-WS is "more powerful" than Spring Remoting in the arena of web services; as you do more with web services, chances are you'll end up using Spring-WS instead of Spring Remoting.
Congratulations are in order to the Interface21 team; good job, guys.