Page History

...

Top-Down (start with WSDL fault)

Start with a WSDL portTYpeportType, with a fault message defined in terms of a fault elem and generate the Java from that. If you use a tool like wsimport which you'll get a generated Java exception wrappering a fault in the JAX-WS Sec. 2.5 pattern. That's it. The top-down case is a lot simpler.

Bottom-Up (start with Java checked exception)

...

If you're working bottom-up from Java and you have a genuine Java business exception, well, it does get a bit ugly, at least if your exception wrappers fault data (i.e. it wrappers some data like an error code or object which it needs to convey). If your exception only contains a String 'message', then you won't experience the pain.

There are two options: 1)

1. Converts the exception to follow the JAX-WS Section 2.5 pattern (getFaultInfo(), ctor with faultBean as parm)

...

1. Rely on our Tuscany interpretation/implementation the JAX-WS Sec 3.7 pattern. This basically works the same whether you run a dev-time tool which supports this pattern (like wsgen) or if you leverage the runtime WSDL2Java.

Of these, 1) the first is better, and if you are willing/able to modify your Java business exception in this fashion, you gain the ability to use this exception as part of the client programming model.
The downside is it requires developer understanding of the pattern and the ability and effort to modify the exception.

Option 2) The second option will be used in both the case where the user won't/can't change the exception class and also the case where the user is ignorant of the WSDL mapping.

In either of those two cases, as long as the exception doesn't contain fault data, this will "just work" without any complexity seen by the user. For exceptions with fault data, the data will be handled correctly (or not) field by field. For each exception data field with a public getter/setter (i.e. we will serialize the exception by viewing it as a JavaBean) we will handle the data correctly (and we will lose the data without a getter/setter pair.

Some issues with 2)this second option:

• It won't be obvious to a user what the supported pattern is. One exception, even though it has fault data (with getter/setter) is handled correctly while another is not. Running wsgen at development time is no help either, since this generates the schema based on the exception's getters without assuring that the corresponding setters exist in order to populate the exception during unmarshalling.

...