Summary
The Spring project released Spring Web Services (Spring-WS) 1.0, a full-stack XML Web services framework. Spring-WS's focus is to make it easier to write document-driven, contract-first Web services that start with a WSDL document, and to enforce WS development best practices.
Advertisement
Web service developers face two basic options when defining a new Web service: Write some code in a programming language first, or use an existing class, and expose that code as a Web service by converting between the programming language interface and a WSDL service definition. Alternatively, a developer can start by defining a WSDL document, and generate a class in Java, or in some other programming language, from the WSDL.
Since WSDL defines a Web service's public contract, starting with the WSDL is sometimes referred to as the contract-first approach; concomitantly, starting with the programming language code is sometimes called the contract-last approach.
The newly released Spring Web Services 1.0 (Spring-WS 1.0) framework focuses on contract-first Web services development. As the project's documentation explains:
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 as simple as they appear: there is a fundamental difference between hierarchical languages such as XML (and especially XSD) and the graph model of Java...
If you are using [the contract-last] approach, you will have no guarantee that the contract stays constant over time. Each time you change your Java contract and redeploy it, there might be subsequent changes to the web service contract.
In addition to focusing on contract-first development, other strengths of Spring-WS include enforcing Web service development best practices:
People use Spring-WS for many reasons, but most are drawn to it after finding alternative SOAP stacks lacking when it comes to following Web service best practices. Spring-WS makes the best practice an easy practice. This includes practices such as the WS-I basic profile, Contract-First development, and having a loose coupling between contract and implementation.
Spring-WS also takes advantage of other components of the Spring framework, and adds the following capabilities to Spring:
Powerful mappings. You can distribute incoming XML requests to any object, depending on message payload, SOAP Action header, or an XPath expression.
XML API support. Incoming XML messages can be handled not only with 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. And because it is a separate module, you can use it in non-Web services code as well.
Reuses your Spring expertise. Spring-WS uses Spring application contexts for all configuration, which should help Spring developers get up-to-speed nice and quickly. Also, the architecture of Spring-WS resembles that of Spring-MVC.
Supports WS-Security. WS-Security allows you to sign SOAP messages, encrypt and decrypt them, or authenticate against them.
Integrates with Acegi Security. The WS-Security implementation of Spring Web Services provides integration with Acegi Security. This means you can use your existing Acegi configuration for your SOAP service as well.
Built by Maven. This assists you in effectively reusing the Spring Web Services artifacts in your own Maven-based projects.
What do you think of contract-first versus contract-last style Web service development?
>> However, things are not as simple as they appear: there >>is a fundamental difference between hierarchical >>languages such as XML (and especially XSD) and the graph >>model of Java
Not sure if defining WSDL first would make the JAVA-XML mapping any simpler for the implementation.
Java interface to a Java service might be easier way to define a contract, so why should it be considered as contract last approach. Also, i might want to expose the same service using multiple protocols, so keeping the Java interface as the primary contract would make more sense and if it changes, there must be some reason to it.
Jerry's right! The "academic" way of writing WSDLs without feedback of real world applications inevitably ends up like drawing ER diargrams before writing business logic. The WSDL will conatin alot of things noone will ever need but will miss all the importand things. A general puropse communication technique that isn't exclusively bound to web services is the way to go. Especially since there's no way around "Web Services 2.0" as the current approach doesn't lead anywhere...
Previous Topic
