Comments inline.
Simon
Millies, Sebastian wrote:
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...
Not at all. You're asking some excellent questions.
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.
Actually you might be able to use the RMI binding with a Java-from-WSDL
substitutable interface. However, the WSDL-ness would show through
(if only because of the unusual exceptions thrown), so if you were trying
to interoperate with an unsuspecting RMI client then you would probably
prefer to create a different service and interface for that purpose.
However, you wouldn't need a different service implementation as it's
perfectly fine for the same implementation class to support multiple
services with different interfaces.
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
This is a very good question. The SCA 1.1 assembly spec treats exception
compatibility in the same way as it treats type compatibility for the
parameters of the interface: by saying that the exceptions or parameters
must be "the same". It also says that if there are different interface
definition languages for the reference and service interfaces, the
interfaces must be mapped to WSDL to determine compatibility. This means
that Java classes would be mapped to XML types. Putting these together,
I believe the right approach would be to convert exception types on the
service and reference interfaces to XML and check whether the mapped XML
types are the same, not to check whether the exception Java classes are
in the same Java package.
This is stretching the SCA spec a bit, but it feels plausible. However,
we would need to go further down this path before declaring victory.
If the Java exception classes are in different packages, the mapped XML
types would be in different namespaces but otherwise identical. So we
would also need SCA to define equivalence rules for XML types that only
look at the contents of the type rather that its namespace or name.
Again this feels plausible but it's too much of a stretch to assume
these semantics without explicit clarification in the SCA specs, and
this would need an OASIS spec issue to be raised.
I'm not sure how Tuscany handles this. I'll try it out using 1.6 and
post the results here.
Simon
