From: Simon Nash [mailto:[email protected]]
[snip]
>In the general case, it is possible to end up with two interfaces with
>equivalent semantics that aren't substitutable for each other. For example,
>if a service CreditCardPayment1 were developed using a pure Java interface
>(with exceptions thrown as AuthorizeException etc.) and another service
>CreditCardPayment2 were developed using a WSDL interface using JAX-WS to
>generate a Java interface from the WSDL (top down WSDL->Java), the services
>CreditCardPayment1 and CreditCardPayment2 wouldn't be substitutable.
>
>If you want your services to have the greatest possible substitutability,
>it's advisable to implement them using top-down WSDL interfaces as this
>CreditCardPayment example shows. There's nothing to prevent a client and
>a service from using a top-down WSDL interface (as shown in this example)
>and being connected by a non-web services binding such as binding.sca.
>
>If you go the other way and use Java-specific interfaces with bottom-up
>Java->WSDL generation, everything works OK as long as all your services
>and clients are Java. You also have the convenience of being able to
>throw and catch AuthorizeException. The downside is that this approach
>doesn't scale beyond Java, so it can cause problems of the kind you are
>mentioning when non-Java services or clients are introduced.
I've thought about this some more, but I must be obtuse. Please tell me
when I'm getting to be a nuisance...
Anyway, suppose I have a top-down WSDL interface (or have edited my original
Java interface after generating JAX-WS artifacts from it, I guess both would
be possible). Now, I would also have to add webservice specific coding to
the code that throws the exception, e. g. like this:
final String msg = "Unknown user: " + user;
AuthorizeFault faultBean = new AuthorizeFault();
faultBean.setMessage(msg);
throw AuthorizeFault_Exception("Basic Message", faultBean);
What then if I also want to make this service available via RMI? I guess I
would have to create a non-substitutable interface and a separate service
implementation to go with it.
I also wonder how to organize my exception classes. When looking only at
interfaces
without exceptions, I can specify the interface name in the package structure of
my client, and SCA will discover if its compatible with the interface provided
by
the service. Once exceptions come into play, this isn't so easy, because in
general
they'd have to sit in the same package on the client and service side, forcing
me to
adapt the client side interfaces depending on the service.
An example is the scatours.CurrencyConverterLauncher, which I view as a client
for the
CurrencyConverter service. This class contains the following line:
scatours.currencyconverter.CurrencyConverter converter = ((SCAClient) node).
getService( CurrencyConverter.class, "CurrencyConverter" );
but methods in the interface scatours.currencyconverter.CurrencyConverter
couldn't throw
a hypothetical scatours.currencyconverter.CurrencyConverterException, they
would have
to use com.tuscanyscatours.currencyconverter.CurrencyConverterException so as
to be
compatible with the interface
com.tuscanyscatours.currencyconverter.CurrencyConverter.
Could SCA provide a way around this by relaxing the compatibility rules? Or am
I completely
on the wrong track? Perhaps I should see exception classes organized
orthogonally to services.
-- Sebastian
