Last week, in my presentation at the NL-JUG JFall, I introduced the Spring Web Services framework, a new major module for the Spring framework. You can download the slides from the presentation here.

I am sure there are a lot of people with questions about this framework. In a series of posts, I will try to formulate an answer to these. This first post is a generic introduction into the Design Goals of Spring-WS, more spicy stuff will come later.

Design Goals

Making Web Services First Class Citizens of the Architecture

We believe that Web Services deserve a proper place in an application architecture. Too often, Web Services exist as an afterthought in the application architecture, mostly because existing Java business interfaces are SOAPified by placing them in a Web Service container. We think that developing Web Services, both now and in the future, require careful thought and consideration, enough to justify a framework especially created for this purpose.

Create a Web Services Framework, not a Web Services container.

We do not believe there is any point in creating another black-box Web services container which does not allow a developer to customize service deployment and development. Instead, we believe in a transparent framework which offers customizability on all fronts.

Use Spring as a basis

Spring’s powerful features like Inversion of Control and Aspect-Oriented Programming make it a solid ground for an application framework. We plan to use Spring where possible, both as a framework and as a source of inspiration.

Pluggability

With relative little effort, it should be possible to swap one piece of the framework for another. For instance, it should be possible to replace one Object/XML-mapping framework with another. Spring, in combination with proper use of Java interfaces, will help us here.

Focus on SOAP

We believe that the future of Web Services lies in SOAP. While other standards and implementations also focus on REST-like services, we believe that there is little value in creating a framework for these kind of Web Services. REST services seem to have very little common functionality that cannot already be captured with Java classes like the HttpServlet.

This does not mean that developers cannot use facilities provided by Spring-WS. For instance, the Object-XML Mapping abstraction we have planned can be useful for REST as well as SOAP.

Use available implementations

There is little sense in reinventing the wheel. For this reason, we do not plan to create our own security framework, Object/XML-mapping framework, or SOAP mess, and the commercial world.

Sensible defaults

Customizability comes with a price. We plan to provide defaults where possible, but force the service developer to make a choice where necessary. Our goal is too make Web Service development as simple as possible, but not any simpler.

Message based

As I have written previously, RPC-style Web Service development has many disadvantages. We will focus on message-based development instead.

Contract-first development

Contract-first Web Service development is considered a best practice. While we plan to facilitate in both contract-first and contract-last development, we should point out the issues that go along with contact-last development.

Keep watching this space for more information…