...

String someMethod(String... params)

Business Exceptions/Faults

This section describes Tuscany's Java<-->WSDL mapping for business exceptions on remotable interfaces.

Top-Down (start with WSDL fault)

Start with a WSDL portTYpe, 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.

Bottom-Up (start with Java checked exception)

First, it might not be a best practice to design a remotable interface which throws a technology exception, e.g. java.sql.SQLException. This might be more appropriate for a local interface rather than a coarse-grained remotable interface.

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) Converts the exception to follow the JAX-WS Section 2.5 pattern (getFaultInfo(), ctor with faultBean as parm)

2) 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) 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) 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):

• 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.

This seems an area for improvement, either by issuing warnings somewhere along the way or if we ever factor the Tuscany J2W functionality into a dev-time tool.

• If you run W2J against the generated WSDL you will end up with a different exception class (which does follow the Sec 2.5 pattern). So your client/service programming model are different which might confuse the Java-centered programmer. You might even need to add a JAXB customization to get around some mapping quirks to generate the client, and you might see weird names like MyException_Exception.

Tuscany

TODO - Add some details of which bits of tuscany do what w.r.t databindings, mappings and transformations in typical scenarios, e.g.

...