howto return exceptions as soap faults

[res1st]

Thanks for your answers. I'll think about it. Maybe i'll switch the WS technolgy in a later phase of my project.

[routis]

I work for a European Union Project that provides a central service (not web service) where each member country has to send information concerning the movement of all ships.
This information is sent in XML over HTTP using a home grown protocol (The project was started back in 2000 when the WS were not a option). There are XML Schemas that define the structure of the XML Messages.
Each member country has made big investments on software that produces this XML message large amounts (.Net, Java, PHP etc) . Thus, the XML Schema cannot change.
My job is to investigate the transition from the custom HTTP protocol to Web Services. I have looked Axis1, Axis2, J2EE WS etc, with no luck. None did give the option to begin my development from WSDL (and XML Schema).
Then sometime in October, I read a Poutsma's presentation that was talking for the development of "contract-first" web services. Among all the ambiguous things that you find about WS in the internet this was a clear path for me.

In my experience, when you have to build a system that inter-operates with others, you must pay attention to the interface that you provide.
The implementation of the interface is important but it also can change in time. The interface on the other hand cannot / should not change.

So, if you allow me to give you an advice:
Use whatever product, framework, soap stack best suits you, but invest on XML Schema and WSDL, because these are the essence of WS.

Friendly routis

[paulgielens]

Service contracts, data contracts are amended over time, this is the reality. One strategy for a service contract is to add a new contract but continue to support the original contract. Data contracts however have a build-in versioning system, assuming you use XML to describe the message body. I think my point is, yes I wholeheartedly agree that you need to invest in the service contract (WSDL) and data contract (XML), but I also want to stress the importance of a versioning strategy.

[Arjen Poutsma]

Service contracts, data contracts are amended over time, this is the reality. One strategy for a service contract is to add a new contract but continue to support the original contract. Data contracts however have a build-in versioning system, assuming you use XML to describe the message body. I think my point is, yes I wholeheartedly agree that you need to invest in the service contract (WSDL) and data contract (XML), but I also want to stress the importance of a versioning strategy.

True, though some contracts are defined by another party. They may change as well, but hopefully not often. This doesn't change the necessity for having a versioning strategy, however.

Fact is that having a versioning strategy is pretty hard when you tie yourself directly to the contract. Basically, the only option is to create a new class that implements the new contract (AirlineService2.class), or to create an entirely new WS app (airlineservice2.war). You can imagine where this will end up .

If you put a layer in between, you will have much more room for handling different versions of the contract. Providing that layer is what Spring-WS is all about.

Cheers,