Home

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.

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.

Document based or contract driven web-services? Ok, these are true and relevant needs but JAX-WS does support them. Object to XML mapping, yep, that’s another true need and there are several existing solutions ranging from static mapping to dynamic mapping.
So, is there any serious drawback in how its going on today that drove interface 21 to put a real effort? Perhaps a weak support for REST in standard EE tools?
The Spring approach, as far as I understand it was to complete J2EE where its lacking and compete with whatever J2EE parts that are rotten, or put in more mild words: not suitable for all business and technical cases.
The Acegi integrations look useful because if you're using it, you want to integrate it with the WS stack and that wasn’t possible until now. So is it: make our own stack so it would play nice with the rest of Spring or: everything else is done wrong and we are doing right this time, a little bit of both?
So, what's the story? Can anyone from Interface21 shed some light here?

I read about a recent agreement between Sun and Microsoft about web services:
The result is a 10-year collaborative agreement by which the two tech vendors are making interoperability a reality in Web services and on the desktop — as well as ensuring that Windows is supported on x64 Sun systems and providing storage and systems management interoperability.
The JAX-WS (not sure about Metro stack) is being used by BEA, JBoss, Glassfish, and JEUS. Sun and Microsoft spent a lot of time working together to ensure advanced features such as distributed transactions, reliability, security, etc... work perfectly between .NET and Java. Does Spring-WS offer this too?

I don't comment on the technical merits, but Spring team's track record for delivering stable software, professional release cycle and roadmaps, excellent documentation and friendly support is so impressive that it makes this offering #1 candidate for me when choosing web services stack for the next time.
Technical differences are often insignificant from business point of view when compared to lost productivity from bugs, lack documentation etc.
Congrats for the team,
/Henri Karapuu

I've never really hopped on the Spring bandwagon but I've got to say, this appears to have everything I'm looking for.
1. Contract first. This is huge. Building WSDLs from Java is a major error in my experience.
2. Choice between w3c schema, schematron and RELAX-NG.
3. Built-in XPath support.
4. Multiple xml serialization options such as XStream.
That's pretty much my shopping list. Maybe these Interface21 guys really do have it all figured out.

I've never really hopped on the Spring bandwagon but I've got to say, this appears to have everything I'm looking for.

1. Contract first. This is huge. Building WSDLs from Java is a major error in my experience.2. Choice between w3c schema, schematron and RELAX-NG.3. Built-in XPath support.4. Multiple xml serialization options such as XStream.

That's pretty much my shopping list. Maybe these Interface21 guys really do have it all figured out.

James, I had the same reaction to Spring-WS when I first looked at it last summer. It requires a little more work upfront because you can't push a button to magically generate a WSDL from Java, but as you point out, that's often a bad choice for a number of reasons.
However, I have the same questions as others on this thread - where does this fit in with JAX-WS, which has so much industry support? I like the Spring-WS approach and I like the programming model, and I like the Acegi integration as well - but I get the feeling that while Spring-WS is a perfect little framework for doing proper contract-first XML-based services, it will always be behind in terms of supporting the standards that JAX-WS supports (ignoring for the moment whether those standards are useful or not).

I like the Spring-WS approach and I like the programming model, and I like the Acegi integration as well - but I get the feeling that while Spring-WS is a perfect little framework for doing proper contract-first XML-based services, it will always be behind in terms of supporting the standards that JAX-WS supports (ignoring for the moment whether those standards are useful or not).

I think the WS-* standards are imploding and this is why REST is gaining so much more interest. Having said that, these standards are not going to disappear tomorrow.
What I saw when I looked at the Spring-WS package is that it seems to not really confine your solution much. If you want to pass the raw XML to a Java class, you can do that. Hypothetically, this should allow support for these standards to be added by pretty much anyone. Whether that will happen is another thing altogether but for this to be successful, it's probably going to have to happen.
One of the things that I learned doing intensive service development and support is that very few companies have the luxury of complete control over what protocols and message formats they support. In the long term the ability to render and receive the same data in wildly different ways is a requirement. Any plan that starts with the assumption 'we will only support X' is guaranteed to fail. This package appears to give you the tools that you need to do this without going crazy. I haven't worked with JAX-WS but it's predecessor JAX-RPC definitely did not.

I've never really hopped on the Spring bandwagon but I've got to say, this appears to have everything I'm looking for.

1. Contract first. This is huge. Building WSDLs from Java is a major error in my experience.2. Choice between w3c schema, schematron and RELAX-NG.3. Built-in XPath support.4. Multiple xml serialization options such as XStream.

That's pretty much my shopping list. Maybe these Interface21 guys really do have it all figured out.

Yep, exactly... I don't believe the other WS stacks do the contract first and it's a real issue, especially if you want to have a family of related web services re-using the same schemas, as opposed to a new definition of the same document types for each.

Originally the meaning of web services was just machines talkin' with each other. In the 'real' or original meaning there is absolutely nothing that requires XML.
That said i agree that the Spring guys seem to have warmer attitude towards XML than the average north-american heterosexual man. I.e. i wouldn't mind bit less of XML in Spring projects.
/Henri Karapuu

I invoke my IntelliJ WebServices plugin. It eats most of the current food.

So to host a web service, you do what, click a button?

I will send them a request, to extend the plugin ;-)

When a client asks how to use it do you just shrug?

This is in fact a huge problem. It is THE web services problem. Lots of XML fetishists say WSDL/XSD is the documentation (some even add comments). But that's bullshit.
No one can use your web services without a nice and decent developer's guide. But avoid it to write it in a XML-centric way.

Originally the meaning of web services was just machines talkin' with each other.

I don't know the 'original' meaning. But Web Services has been widely understood to be defined specifically as SOAP based for a number of years. It's only lately that this definition has opened up to other technologies.

In the 'real' or original meaning there is absolutely nothing that requires XML.

Whether that is the case or not is irrelevant. XML is the lingua franca of web services. I'd say any notion that you can host or use web services without supporting XML is just wishful thinking.

Whether that is the case or not is irrelevant. XML is the lingua franca of web services. I'd say any notion that you can host or use web services without supporting XML is just wishful thinking.

For sure you are right. But it doesn't matter, that XML is used under the hood. As an application developer you shouldn't care about such details. There are smart tools that handle the problems of communication protocols. With Spring WebServices there is too much XML invloved.

True James, but that doesn't exclude the WSIF and binary
protocol service implementations, such as the brilliant Hessian project.
You use the Web Service Invocation Framework and binary implementations where you know the client and server are
both implemented using the same technologies or the protocol
has implementations that are both platform independent and
support the client/server technologies. In my example, Hessian allows, say, a Java client to call a C++ service using the Hessian binary protocol.
In my experience, particularly for a large financial clearing house in the UK recently, the binary implementations offer much better performance for "chatty" services.
- Gary

True James, but that doesn't exclude the WSIF and binaryprotocol service implementations, such as the brilliant Hessian project.

You use the Web Service Invocation Framework and binary implementations where you know the client and server areboth implemented using the same technologies or the protocolhas implementations that are both platform independent andsupport the client/server technologies. In my example, Hessian allows, say, a Java client to call a C++ service using the Hessian binary protocol.

In my experience, particularly for a large financial clearing house in the UK recently, the binary implementations offer much better performance for "chatty" services.

- Gary

There are many many ways web services could be improved and using something other than XML is one potential way to do that. That doesn't really have anything to do with what I wrote, however.

... as opposed to the JAX-WS mechanism, where the Java code is written and the API generates the WSDL from that.

Just wanted to point out that this is incorrect. JAX-WS (in fact just about any web service stack that I've heard of) certainly supports contract-first, too.

Doesn't it generate a ton of Java classes when you do this though? Generating Java code from WSDLs is worse (IMO) than generating WSDLs from Java. The part that seems to be missing from JAX-WS is the transformation and simple Java object binding. Maybe it's in there and I just don't know about it. If you drop back to JAXB and build the code to use stylesheets to transform the message into the cannonical XML form for a Java object, then you are on the right path. But as I understand it, this is what this package gives you.

The part that seems to be missing from JAX-WS is the transformation and simple Java object binding. Maybe it's in there and I just don't know about it. If you drop back to JAXB and build the code to use stylesheets to transform the message into the cannonical XML form for a Java object, then you are on the right path. But as I understand it, this is what this package gives you.

You'd have to elaborate on what you mean by "ton of Java classes" --- maybe you are referring to what JAX-RPC used to generate. JAX-WS/Metro certainly doesn't generate anything beyond what's necessary. No code that reads/writes XML, etc.
I'm not quite following about the "canonical XML form" of things, but if you'd like to run a transformation on incoming XML, you can certainly do so, too.

The part that seems to be missing from JAX-WS is the transformation and simple Java object binding. Maybe it's in there and I just don't know about it. If you drop back to JAXB and build the code to use stylesheets to transform the message into the cannonical XML form for a Java object, then you are on the right path. But as I understand it, this is what this package gives you.

You'd have to elaborate on what you mean by "ton of Java classes" --- maybe you are referring to what JAX-RPC used to generate.

I guess I mean this:
"eBay requires 700 + Java classes
For example, the eBay WSDL includes a whopping 500 XML Complex Schema types, 200 WSDL message types, and 1 port type. That's ridiculous, but it might account for the huge package of Java classes that was generated by the JAX-WS wsimport tool. When I counted the Java source files generated from the WSDL I came up with over 700 Java classes! Maybe there is a Java class for each XML Schema type and WSDL message type? Still that seemed weird. Why would it be the sum of those and not simply be equal to the XML Complex Schema types and a couple of ancillary classes."

I consider the total number of classes that must be generated to be zero. Moreover, I consider that to be the ideal number.

No code that reads/writes XML, etc.

I'm not quite following about the "canonical XML form" of things, but if you'd like to run a transformation on incoming XML, you can certainly do so, too.

Java classes have a very simple data model relative to XML. It's fairly easy to represent a Java object in XML. But there are a lot of XML structures that are very difficult to describe statically in Java. So the approach I've found to be effective is to use XSLT/Xpath/XQuery to transform complex XML into a naive natural Java compatible format and just push the data into Java objects.
I have no interest in working with XML structures crystallized in Java ala JAXB 1. Having dealt with that, I can attest to it being one of the worst maintenance nightmares I have ever dealt with. It's the best way to turn a little bit of dynamic logic into reams of brittle hard-coding I have ever seen.

I consider the total number of classes that must be generated to be zero. Moreover, I consider that to be the ideal number.

OK, sounds like then you don't want data-binding at all. That's fine with JAX-WS, too. If you don't want to generate anything. You can do that --- you just don't run any tools.
Or maybe what you are really saying is that you'd rather use things like E4X, rather than Java.

I want to bind to my own (or my team members') custom objects. Binding and generating are two distinct activities.

A fact that's been largely missed by the Java XML frameworks, unfortunately. JiBX is probably the best option for binding a handmade schema to a handmade domain model. The others all want you to build one side and let them build the other.

I want to bind to my own (or my team members') custom objects. Binding and generating are two distinct activities.

A fact that's been largely missed by the Java XML frameworks, unfortunately. JiBX is probably the best option for binding a handmade schema to a handmade domain model. The others all want you to build one side and let them build the other.

I've heard good things about XStream too. One of the things I've seen tools such as Castor fail miserably at is creating their own mapping syntax. It's just a lot easier and more robust to transform the XML using XPath into something that is compatible with Java and do a naive mapping. I think what may turn people off about this is the lack of static checking but the benefits outweigh the costs in this context.
The confusion between binding and generating is very frustrating to me. If you generate a bunch of Java classes and recreate the xml data in Java objects, you really haven't gotten anywhere. I would argue you've actually made things harder on yourself. You have basically two options: 1. Use the generated classes as your domain model 2. Hand-write a bunch of really brittle code to map the data to your domain model.
The first option is really bad for a number of reasons including: it's an anemic domain model and when you need to map a number of XML messages to the same services (I've had to support couple dozen purchase order formats simultaneously where not all are XML based) you'll have to recreate the same services again and again.
If you go with the second option (the better one) you should realize pretty quickly that it's a huge pain. You have to check for nulls after retrieving every element and you can't really abstract out anything because every type in the document creates a separate class. The only way I can see around that is to use reflection and then you really have to question what you get out of doing that in Java.

I want to bind to my own (or my team members') custom objects. Binding and generating are two distinct activities.

A fact that's been largely missed by the Java XML frameworks, unfortunately. JiBX is probably the best option for binding a handmade schema to a handmade domain model. The others all want you to build one side and let them build the other.

I've heard good things about XStream too. One of the things I've seen tools such as Castor fail miserably at is creating their own mapping syntax. It's just a lot easier and more robust to transform the XML using XPath into something that is compatible with Java and do a naive mapping. I think what may turn people off about this is the lack of static checking but the benefits outweigh the costs in this context.

The confusion between binding and generating is very frustrating to me. If you generate a bunch of Java classes and recreate the xml data in Java objects, you really haven't gotten anywhere. I would argue you've actually made things harder on yourself.

This has been my experience as well. I like XMLBeans for converting the XML into generated Java objects - but then I've got that pain of moving the data to existing objects (have meant to look at Dozer as an option for doing this).
I used Castor some back in 2003 and 2004 because it was the only thing I could find that I could use to map XML to existing Java objects, but you're right, the mapping syntax was just never good enough.
So if I hear you right - are you preferring to use XSLT to convert the XML into something that XStream can unmarshal into your existing Java objects? I tinkered with that some last year, but I didn't do enough to get a sense of how well it would really work. Would like to know that it's been successful for someone.

So if I hear you right - are you preferring to use XSLT to convert the XML into something that XStream can unmarshal into your existing Java objects? I tinkered with that some last year, but I didn't do enough to get a sense of how well it would really work. Would like to know that it's been successful for someone.

If you look at the 'two minute tutorial' on XStream they take an object specified by this class:
public class Person {
private String firstname;
private String lastname;
private PhoneNumber phone;
private PhoneNumber fax;
// ... constructors and methods
}
and produce this output:
Joe
Walnes
123
1234-456
123
9999-999
Now, as far as I am concerned this is a perfectly valid internal format for a person entity. But it's not something I would necessarily want to expose. Or if it was something of a quality that could be exposed, I wouldn't want to couple my contract and code. I'd want to be able to change one without causing issues with the other. My experience is also that I've often not been able to specify the contract at all. It might come from some standard written by monkeys on acid kind of like, say RosettaNet. In any event, I want some sort of buffer between the external contract and my internal object.
I've never seen anything for working with XML that comes close to the XPath family of languages. I don't like it for logic (I've had to do that too) and processes but for retrieving data and converting XML, it's where you want to be, especially with the XPath 2 improvements.
The downside is that XPath (as far as I know) isn't reversible so you'd need a mapping for both directions. I personally don't see this as a huge deal but I can understand some people might.
It seems that WS-Spring has all the pieces to make this happen. I'm going to try and see if I can pull it together. That REST is missing is a downer but hopefully that will be rectified soon.

I want to bind to my own (or my team members') custom objects. Binding and generating are two distinct activities.

A fact that's been largely missed by the Java XML frameworks, unfortunately. JiBX is probably the best option for binding a handmade schema to a handmade domain model. The others all want you to build one side and let them build the other.

Jason, have you tried the TopLink XML mapping framework? It was actually created to solve the meet-in-the-middle mapping problem between a pre-existing domain model and a pre-existing schema and is the most flexible tool that I know of in this area (certainly well beyond JAXB, which really only does uni-directional generation). It is now open sourced as Eclipse MOXy, a part of the "Eclipse Persistence Services" runtime project.

I want to bind to my own (or my team members') custom objects. Binding and generating are two distinct activities.

A fact that's been largely missed by the Java XML frameworks, unfortunately. JiBX is probably the best option for binding a handmade schema to a handmade domain model. The others all want you to build one side and let them build the other.

Jason, have you tried the TopLink XML mapping framework? It was actually created to solve the meet-in-the-middle mapping problem between a pre-existing domain model and a pre-existing schema and is the most flexible tool that I know of in this area (certainly well beyond JAXB, which really only does uni-directional generation). It is now open sourced as Eclipse MOXy, a part of the "Eclipse Persistence Services" runtime project.

Nope, I sure haven't, but it sounds like it's worth checking out.
Any hope for an IDEA plugin? ;) Eclipse makes me twinge...

I want to bind to my own (or my team members') custom objects. Binding and generating are two distinct activities.

A fact that's been largely missed by the Java XML frameworks, unfortunately. JiBX is probably the best option for binding a handmade schema to a handmade domain model. The others all want you to build one side and let them build the other.

Jason, have you tried the TopLink XML mapping framework? It was actually created to solve the meet-in-the-middle mapping problem between a pre-existing domain model and a pre-existing schema and is the most flexible tool that I know of in this area (certainly well beyond JAXB, which really only does uni-directional generation). It is now open sourced as Eclipse MOXy, a part of the "Eclipse Persistence Services" runtime project.

Nope, I sure haven't, but it sounds like it's worth checking out.

Any hope for an IDEA plugin? ;) Eclipse makes me twinge...

EclipseLink is a runtime project that lives within the Eclipse ecosystem. Although other Eclipse projects in the ecosystem are starting to make use of it the runtime is not coupled to Eclipse. GUI workbench support (standalone as well as integrated with Eclipse tools) is also going to be offered.

...have you tried the TopLink XML mapping framework? It was actually created to solve the meet-in-the-middle mapping problem between a pre-existing domain model and a pre-existing schema and is the most flexible tool that I know of in this area (certainly well beyond JAXB, which really only does uni-directional generation). It is now open sourced as Eclipse MOXy, a part of the "Eclipse Persistence Services" runtime project.

Thanks for pointing this out. I went to the EclipseLink project and poked around the wiki but didn't find much. Is there somewhere you can point me to that explains their approach to this?

Thanks for the link. I looked at the examples and it looks pretty straight-forward for simple xml to object mappings.
However, one challenge I have faced in the past is how to do complex mappings. For example, once I had to deal with a message format for a shipment where the container detail was the parent of the shipment items. In our core system, however, the data was stored in an inverted way i.e. the container ID was stored as a child of the shipment item. So we might have one document with 2000 items in 2000 boxes while another one with 2000 items that ship on one pallet. The input from the core system would have 2000 items in either case but the output would look very different where one would have one container with 2000 items and the other would have 2000 containers with one item each.
Before anyone says it, the correct answer was not to restructure the data in the core system as other formats we supported matched the core system. This would not resolve anything but just move the problem somewhere else (and surely break lots of stuff).
How would you deal with something like this in TopLink or MOXy?

Thanks for the link. I looked at the examples and it looks pretty straight-forward for simple xml to object mappings.

However, one challenge I have faced in the past is how to do complex mappings. For example, once I had to deal with a message format for a shipment where the container detail was the parent of the shipment items. In our core system, however, the data was stored in an inverted way i.e. the container ID was stored as a child of the shipment item. So we might have one document with 2000 items in 2000 boxes while another one with 2000 items that ship on one pallet. The input from the core system would have 2000 items in either case but the output would look very different where one would have one container with 2000 items and the other would have 2000 containers with one item each.

Before anyone says it, the correct answer was not to restructure the data in the core system as other formats we supported matched the core system. This would not resolve anything but just move the problem somewhere else (and surely break lots of stuff).

How would you deal with something like this in TopLink or MOXy?

If I miss the mark on your question, feel free to email me blaise dot doughan at oracle dot com.
I think you are asking if we can distinguish between relationships represented by containment, and those represented by key/foreign key pairs? The answer is yes.
We have composite mappings that represent nested relationships.
123 Any St.
Ottawa
And we have key based mappings that represent key based relationships. Note that employee and address can occur anywhere in the document either together or apart. TopLink's object-to-XML mapping also supports composite keys.
1
123 Any St.
Ottawa
Other advanced mapping concepts:
- XPath based mapping (break the correlation between levels of nesting and the number of objects).
- Marshal and unmarshal events (get access to you objects as they are being converted to/from XML).
- Document preservation, marshal your content to a new document, or update the document you unmarshalled from.
- Custom processing, get access to the XML data during the unmarshal process.
- Map your object model to more than one XML Schema. Since TopLink OXM metadata can be externalized from the object model, you can map it more than once.
-Blaise
Team Lead, TopLink OXM

I think maybe I didn't explain it well enough. The data coming from the core system looked like this:
item: 1
box: A
quant: 5
box: B
quant: 5
item: 2
box: A
quant: 10
item: 3
box: B
quant: 10
But the outbound XML document was required to look like this:
You mentioned XPath, which is what I am guessing the solution would be for something like this.

You mentioned XPath, which is what I am guessing the solution would be for something like this.

In this specific use case if you have control over your object model the solution is straight forward. I would make the relationship between Item and Box bi-directional (in your object model) and then in the object-to-XML mapping metadata map only the box to item relationship.
If you can not change the domain object model, you can leverage a concept in JAXB 2.0 called an Adapter (see section 8.2.6 of the JAXB 2.0 spec). This allows you to sub in one object for another during marshalling and unmarshalling processes. In other words if you can not add a relationship from box to item in your domain model, then you can sub in another helper object that does.
Event based XML processing like SAX and StAX are the most efficient standards at processing XML, but they require single pass depth-first tree traversal. You will get the best performance with implementations such as TopLink that support this, if you can present your data in this way (either out of the box, or through the use of adapters).
TopLink also supports DOM based object-to-XML conversions which you could use to put your target document together, starting with child nodes and then building their parents, making use of our various event mechanisms, but for your example I would recommend one of the event based approaches above.
-Blaise
Team Lead, TopLink OXM

In this specific use case if you have control over your object model the solution is straight forward. I would make the relationship between Item and Box bi-directional (in your object model) and then in the object-to-XML mapping metadata map only the box to item relationship.

If you can not change the domain object model, you can leverage a concept in JAXB 2.0 called an Adapter (see section 8.2.6 of the JAXB 2.0 spec). This allows you to sub in one object for another during marshalling and unmarshalling processes.

OK, I can see how that would solve the problem and in this case the bi-directional relationship should potentially exist in any case. We didn't actually have a domain model when I dealt with this. We were also bound to JAXB generated classes which made this kind of change infeasible.
The thing is that this is just one simple example. We could have a lot of these kinds of things. I can't really see making everything bi-directional in my domain model simply to make XML serialization more flexible. For example the above items are under a shipment. We might have to send someone an invoice of all the the shipments organized by item and another by shipment. We would then need to make the item bi-directional with the shipment. There could be hundreds of such relationships to manage. To me it kind of seems like putting presentation details into the domain model. If I went with the JAVB adapter, I'm adding more complexity that seems necessary to me.
What do I gain by doing this instead of keeping things straightforward in XML serialization and just using XPath to do translation?

OK, I can see how that would solve the problem and in this case the bi-directional relationship should potentially exist in any case. We didn't actually have a domain model when I dealt with this. We were also bound to JAXB generated classes which made this kind of change infeasible.

Good point, class generation based XML binding solutions do not produce domain models. I equate these models with typed DOMs. JAXB 2.0 is a huge improvement because it allows you to modify the produced Java model.

The thing is that this is just one simple example. We could have a lot of these kinds of things. I can't really see making everything bi-directional in my domain model simply to make XML serialization more flexible. For example the above items are under a shipment. We might have to send someone an invoice of all the the shipments organized by item and another by shipment. We would then need to make the item bi-directional with the shipment. There could be hundreds of such relationships to manage. To me it kind of seems like putting presentation details into the domain model. If I went with the JAVB adapter, I'm adding more complexity that seems necessary to me.

These relationships make object-to-XML mapping easier. Normally TopLink makes use of the real relationships that exist between objects (instance variables or get/set methods), but you are able to implement your own means of property access. This is done through the oracle.toplink.mappings.AttributeAccessor (or org.eclipse.persistence.mappings.AttributeAccessor) class. Here you could provide the logical equivalent of the bi-directional relationship (outside of your domain model) to satisfy the object-to-XML mapping.

What do I gain by doing this instead of keeping things straightforward in XML serialization and just using XPath to do translation?

You are suggesting one of the 2 step approaches that some people are using today:
1. Start with your domain model and produce intermediate XML. Then use style sheets or an XML-to-XML tool to convert the intermediate document to the final document.
2. Start with the XML and generate an intermediate object model. Then use an object-to-object tool to convert the intermediate objects to the domain objects.
You will get better performace (both memory usage and execution time) with a single step meet-in-the-middle object-to-XML conversion.
-Blaise
Team Lead, TopLink OXM

Well,
Some can say this is another ws framework, we have a lot of stacks out there.
Do we need another really one!?!?
I think who really loves the Spring philosophy should give a chance to this stack.
It is fully featured and has a REALLY WELL EXPLAINED GUIDE, something the most of stacks out there doesn't have at all!
I found far much easier both starting from scratch and integrating with existing stuff with Spring WS, than getting lost between Axis,Axis 2,Jboss WS,CXF and XFire smoke and mirrors.
Enjoy!

... as opposed to the JAX-WS mechanism, where the Java code is written and the API generates the WSDL from that.

Just wanted to point out that this is incorrect. JAX-WS (in fact just about any web service stack that I've heard of) certainly supports contract-first, too.

I know Spring-WS gives you access to the XML message and you figure out what you want to do with it next, which typically means binding the XML data to plain Java objects and passing those off to some other plain Java object for processing. That completely shields the Java code from any knowledge of web services (which is why I can't see myself ever using web service annotations).
Does JAX-WS allow that as well? If so, then I'm wondering where Spring-WS fits in.

The simplest JAX-WS web service is this:
@WebService
public class MathService{
@WebMethod
public int add(int a, int b) {
return a+b;
}
}
And you can use any JAXB-bindable beans as parameters and return values. So if you consider those two annotations acceptable, then I think it gives you what you want.
And on top of this, Metro also let you configure web service through Spring.

Spring Web Services 1.0 sounds great but how does stack up to XFire and Axis2 in terms of performance? Are there any benchmarks out there?

- David Y. Hodge

I can't speak to any numbers, but my experience with Spring-WS was that there's really very little code - it relies on other APIs for reading in the request, and it then optionally relies on other libraries for binding that XML message to Java objects (or you can just handle the XML yourself). Spring-WS just provides a small framework for glueing things together.
I think that part is consistent with the general Spring approach (though there's still the larger question of how Spring-WS is competing with JAX-WS). As such, the question of performance would really depend on what choices you're using for reading in the request and dealing with the XML.

I recently looked at a comparison of several webservice frameworks/APIs and considered JAX-RPC, JAX-WS, xfire, axis2, and spring-ws.
Here is the summary:
- JAX-RPC is a dead spec. Don't use it.
- JAX-WS is the latest and greatest, however only partly supported by the most recent application servers, sometimes through special add-ons
- xfire just redesigned their framework completely (CXF). The feature set is great and it is based on JAX-WS (see above) and still in an incubator stage and not fully documented. Apart from this the vision behind it is great but it is just too soon.
- axis2 implemented their own application server framework and has really bad support for API standards (AXIOM and JIBX but not DOM and JAXB). Also it is just too complex (I had the misfortune of having to use it once)
- spring-ws: Only a true idiot can't make a webservice with this framework. Conceptually very simple. Portable on current application servers.
So for the moment, spring-ws wins.

I have read here and from many other sources why doing contract -last is a bad thing. But what is one to do if they made the spring beans as part of a basic web application and now you want to expose these spring beans as web services?
Writing is WSDL isn't too difficult if the spring bean methods accept and return basic objects (Strings, Dates, primatives). But if these methods use more complex objects, the WSDL gets to be out of control.
John Murray

I have read here and from many other sources why doing contract -last is a bad thing. But what is one to do if they made the spring beans as part of a basic web application and now you want to expose these spring beans as web services?

Personally, I think taking existing code and attempting to 'expose' it as a service is a misguided approach. You should be defining services based on what they do, not on how they do it.

Writing is WSDL isn't too difficult if the spring bean methods accept and return basic objects (Strings, Dates, primatives). But if these methods use more complex objects, the WSDL gets to be out of control.

I'm a little confused because you are basically describing one of the problems with generating WSDL from a Java class. It almost sounds like you think that instead of generating the WSDL from Java, people are advocating that you should produce an equivalent WSDL by hand. That's definitely not what contract-first means.
Defining a good service contract is a very different task than creating a Java bean.

You should be defining services based on what they do, not on how they do it.

An example of what I am talking about is a service that adds a customer. Now the customer object is not a trivial object. For instance, it contains some string fields, some date fields, and some collections of other objects such as address objects. So what the service is meant to do is take in a customer object and then return a boolean if successful. To me, this is a simple contract. Am I misguided here?

produce an equivalent WSDL by hand. That's definitely not what contract-first means.

This is my impression on what contract-first means. Please elaborate on that it means. I think we are having mutual confusion here.

You should be defining services based on what they do, not on how they do it.

An example of what I am talking about is a service that adds a customer. Now the customer object is not a trivial object. For instance, it contains some string fields, some date fields, and some collections of other objects such as address objects. So what the service is meant to do is take in a customer object and then return a boolean if successful. To me, this is a simple contract. Am I misguided here?

Nope. That's a pretty good example of a contract.
Well, let see, change this sentence: "Now the customer object is not a trivial object" to "Now the customer object is not a trivial entity" And this one:"and some collections of other objects such as address objects" to and some collections of other complex types such as addresses." We could also quibble about the return value but it's not really pertinent to the discussion.
Note that you didn't mention the word bean or Java in that description and once we remove the word object, it's something I could define a (limited) XML layout for with no other information.

produce an equivalent WSDL by hand. That's definitely not what contract-first means.

This is my impression on what contract-first means. Please elaborate on that it means. I think we are having mutual confusion here.

By hand, maybe, but I don't think it's a good idea to create an XML structure that mirrors a Java class. Java isn't a good language for specifying XML structures. There are tools out there that can help with creating schemata. I would also encourage people to look past w3c schema to RELAX NG and Schematron.
The article above has a pretty good summary of why generating XML schemata and WSDLs from Java is problematic.
http://static.springframework.org/spring-ws/site/why-contract-first.html

Thank you for changing the sentences. That is what I meant.
I did read the article that you provided the link for and I can't quibble with the reasoning. That being said, my conundrum is that I have an operating Spring business layer that all parties are happy with. Currently it is it's own library and used in multiple web applications.
So you can probably see the issue right away. If the logic in this library service is to change, then each of the applications have to be rebuilt with the new library.
The desire is to have these applications call this common business layer via some form of SOA. Since the clients and the server in this example are both running Spring, I could just expose the beans via HttpInvokerServiceExporter can call them via CommonsHttpInvokerRequestExecutor. That seems the quickest way to something tangable, but that locks all potential clients to Spring.

I did read the article that you provided the link for and I can't quibble with the reasoning. That being said, my conundrum is that I have an operating Spring business layer that all parties are happy with. Currently it is it's own library and used in multiple web applications.

So you can probably see the issue right away. If the logic in this library service is to change, then each of the applications have to be rebuilt with the new library.

The desire is to have these applications call this common business layer via some form of SOA. Since the clients and the server in this example are both running Spring, I could just expose the beans via HttpInvokerServiceExporter can call them via CommonsHttpInvokerRequestExecutor. That seems the quickest way to something tangable, but that locks all potential clients to Spring.

If I don't misunderstand you this is exact kind of problem almost everyone runs into when they expose their implementation to the world. The IT industry has been struggling with this for quite a while now with all kinds of different solutions. Most have failed.
SOA is the newest and (IMO) the most likely to succeed. The main reason I think that is the case is that there is a strong focus on separating the service contract from the underlying implementation. The second thing that makes it good (IMO) is that the focus on services is not on exposing some code you wrote a year ago on the network or web but on creating high-level services that are meaningful in a business sense. In that context, your spring bean is just one possible implementation of those services.
The biggest problem with your current situation is not just that all of these clients are coupled to your spring implementation but that they are in effect coupled to each other (indirectly).
You could take your existing objects and create a web service just like them. But I think it's unlikely that the result will be great.
The thing with services is that the contracts live longer than the implementations. The contract will basically never die. Right now, your implementation is your contract, to a large degree. This is something that has proven to be disastrous for application maintenance. It's why so many shops can't get away from COBOL and other 1960's technologies. Without an abstraction layer between the clients and the provider, changing the implementation is like trying to pull the tablecloth out from under a dinner table set for 100.
Anyway, I digress. So once you change the implementation, you'll still have this contract based on the old implementation. And if it was never that great of a contract, why is it like that? For historical reasons. The answer is that no one will really know or care. They just won't like it. It's kind of like how electrical charges are described. Electrons have negative charge, which is pretty unintuitive. The only reason is that Ben Franklin had to pick a way to name them and he guessed wrong. We can't really blame him, he had no way to know. He was just unlucky. But in the end, it can never be changed. It would cause chaos. People would die. So we are stuck with it.

Contracts, abstraction and decoupling clients from service providers are good things, no doubt. But I think many developers are simply uncomfortable with WSDL as primary contract description language for services. Every time I have to decipher a WSDL for a service like the HolidayRequest-thingy shown in the tutorial it takes my breath away... I really cannot image any service description which is more verbose, unfamiliar and less comprehensible than WSDL.
CORBA had many flaws, but everybody with some programming background could easily read an IDL file and get at least a clue how the client or servant had to be implemented in his/her favorite language.
Yes I know, currently we have no other lingua franca for defining service contracts than WSDL, but may be the XML-advocates are unlucky and wrong like Ben Franklin...

Writing is WSDL isn't too difficult if the spring bean methods accept and return basic objects (Strings, Dates, primatives). But if these methods use more complex objects, the WSDL gets to be out of control

As mentioned already, that's still code-first. Plus, I don't know if this is "officially" a good practice, but I don't think a WSDL should ever define any types. All types should be defined in XSDs that can easily be reused across WSDLs.
In fact, with contract-first, document-driven, you don't really even think about a WSDL anymore. You just think in terms of sending an XML document to a URL.... which is REST.
I believe the only advantage then to the alphabet soup of WS-* standards is whether those standards are useful to you or not. If they're not, then you're basically doing REST - you tell the other party, "Here's my schema", and you go from there. Very easy.

<<
You just think in terms of sending an XML document to a URL.... which is REST.

It's not...that's xml-rpc. The crux of REST is about a uniform interface exposing only the HTTP verbs as operations on resources identified by unique URIs, i.e., instead of a getCustomer(123) you do a GET on a URI such as http://whatever/customers/123. And there are far reaching implications because of the REST insistence on constraining the interace to a handlful of operations/verbs.

I'm a REST newbie, but it seems that REST pretty much removes the need for contract-first design as the client/server can just negotiate the content of the message.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

I got the idea from this thread that Spring-WS had support for REST/POX web services. But the documentation seems very SOAP and WSDL specific.
Is there something else I should be looking at? Where is the documentation on how to build a REST web service with this package? I'm feeling a little disappointed in this right now.

Having started off with the release candidates early this year, and putting a couple of applications into production, I have to say my experiences with spring-ws are only good ones.
In some circumstances, all I need to do is expose a business object as a web service, which is a trivial operation under most frameworks. I don't care what the WSDL looks like, and it is up to the clients to invoke my service properly, and I wouldn't use spring-ws in this circumstance.
However, on other applications it is absolutely necessary to define a contract, in the form of an XML schema and WSDL, well up front. This will be used by multiple stakeholders and in multiple technologies. In the case where the WSDL is king, it ends up being a maintenance nightmare dealing with classes that have been generated from it - especially when they (inevitably) don't always work perfectly.
In this situation, I cannot stress enough how simple it is to deal directly with the XML. Binding of your choice if you want, no binding if you don't need it. Far, far less fragile, and much lighter. It isn't right for all use cases but if you do have to do contract first (and some of you may not, but some of us do so don't knock it), spring-ws beats all comers in my experience.

And I am not one of them. But for those that love XML and therefore prefer Spring over EJB3, this is good.
Since at jbilling we use JBoss, we are moving towards JBossWS. Those married to Spring will probably be very happy about Spring WS. I just hope all these WS implementations can talk to each other.
Paul Casal
Sr Developer
jbilling.com
The Enterprise Open Source Billing System

And I am not one of them. But for those that love XML and therefore prefer Spring over EJB3, this is good.

You're comparing apples and oranges (and you don't seem to realize it either, which doesn't speak well for the "Sr Developer" job title at jbilling.com).
Yes, the Spring framework uses XML for configuration. XML vs annotations is a completely separate discussion. This thread happens to be about sending data between different parties in the form of XML documents and how Spring-WS tries to support that. Like it or not (and I've yet to meet anyone profess a "love" for XML - or is that just a strawman you're setting up?), XML is a common choice today for sending such messages, and so it's nice to have some frameworks to choose from that try to make it easier to deal with, and, more importantly, support a contract-first approach.

In terms of WS-AtomicTransaction, what support does Spring WS provide. WebSphere 6.0+ has support for WS-AtomicTransaction (haven't checked it out in detail but I read that somewhere recently). I'd be interested to know if Spring WS provides help/support if I want to combine/aggregate two or more WS calls into same (database) transaction. In my particular usage scenario, the WS services would be deployed within WebSphere AS or ESB and would be updating same database.
The background is I wish to provide a suite of WebServices which can be composed/aggregated into one atomic transaction. I want to use DB transactions and not the compensating transaction (its too much effort to write the rollback + I'm updating only one datbase).

Probably not much at this point. If you are interested in a WS-AT implementation Spring WS is not going to provide that just as Spring-WS does not aim at providing a SOAP stack. It does help you use some WS-* stuff, for example, WS-Security by leveraging the SUN XWSS implementation in a nice configuration driven way where you can choose to adorn an endpoint with an appropriate interceptor that might enforce WS-Security.
Btw, if this is really critical data you are updating are you sure you want to risk the transactional integrity of your system by trying some unproven implementation like WS-AT?

Probably not much at this point. If you are interested in a WS-AT implementation Spring WS is not going to provide that just as Spring-WS does not aim at providing a SOAP stack. It does help you use some WS-* stuff, for example, WS-Security by leveraging the SUN XWSS implementation in a nice configuration driven way where you can choose to adorn an endpoint with an appropriate interceptor that might enforce WS-Security.

Btw, if this is really critical data you are updating are you sure you want to risk the transactional integrity of your system by trying some unproven implementation like WS-AT?

Thanks for reply. I wasn't expecting Spring to provide WS-AT implementation but maybe make it easy to use WebSphere's. Your last comment is something that has crossed our minds. But without WS-AT it severely limits how we define web services; to date we've said just repackage service A, D and E into one to get the transaction control (our main usage scenario is updating same DB) but that's not very SOA; we're told:-)

70 or so posts about "contract first webservices". Just incredible. A Java Interface is an excellent interface and a contract. THAT IS WHAT IT IS DESIGNED FOR.
Why it should be better to design an unreadable xml structure than to define a contract by writing a set readable interface and create the portable contract definition out of these, is totally beyond my understanding. My contract is better than your contract because it is in XML?? If I need a lawyer to read the contract in the first place, I say thanks but no thanks!

70 or so posts about "contract first webservices". Just incredible. A Java Interface is an excellent interface and a contract. THAT IS WHAT IT IS DESIGNED FOR.

Why it should be better to design an unreadable xml structure than to define a contract by writing a set readable interface and create the portable contract definition out of these, is totally beyond my understanding. My contract is better than your contract because it is in XML?? If I need a lawyer to read the contract in the first place, I say thanks but no thanks!

Because Java data structures and XML data structures aren't the same?
Because auto-generated XML-Java bindings are brittle and kill the possibility of re-using common schemas? Common schemas allow you to define a common vocabulary across your services, and possibly industry wide.

Because auto-generated XML-Java bindings are brittle and kill the possibility of re-using common schemas? Common schemas allow you to define a common vocabulary across your services, and possibly industry wide.

No doubt that at some point you want to fix your data structures and fix the contract (create a release). The question is if the development cycle requires contract first development on an XML level or if it is not much more productive to define the contracts in Java and only bother with the XML representation as they are released. Also as long as the Java - XML binding is well defined it is pretty irrelevant if Java and XML data structures are not the same.

Because auto-generated XML-Java bindings are brittle and kill the possibility of re-using common schemas? Common schemas allow you to define a common vocabulary across your services, and possibly industry wide.

No doubt that at some point you want to fix your data structures and fix the contract (create a release). The question is if the development cycle requires contract first development on an XML level or if it is not much more productive to define the contracts in Java and only bother with the XML representation as they are released. Also as long as the Java - XML binding is well defined it is pretty irrelevant if Java and XML data structures are not the same.

Maybe I misunderstand what you are saying here but it sounds like you are taking the phrase "contract-first" too literally. There is no reason why you can't write your Java first. In fact contract first tends to work well with existing code bases. The point is that the contract is not derived mechanically from Java code. Most likely, the contract will remain exactly the same for a really long time and the code will change often. You need to put some effort into defining the contract and not leave it to chance.
Note that defining a contract is also about documentation. What happens if the input is bad? What happens if a required resource cannot be acquired? If this is a asynchronous transaction, when callers expect a response? How are errors reported? Are there data restrictions that cannot be defined in the schema? Who should callers contact in case of a problem? What do all the fields in the document mean?
And one thing more that I haven't mentioned here about why binding is problematic. You need to be prepared to support multiple versions of the same contract. If you have more than one client, you will never get them to all move to the new version at the same moment. If you can't support multiple versions easily, you are in for a world of hurt.

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.