See comments inline below.
Simon
Millies, Sebastian wrote:
Hello there,
one of the aims of SCA is to separate technology integration logic from
business
logic. For example, you don’t want your business logic to depend on a
webservice provider API. In Tuscany, the wiring infrastructure is handled
by specifying a binding in the configuration, which in theory could be
switched from one communication protocol to another.
I wonder if not integration technologies may be so different as to make this
goal unattainable, or at least not quite attained yet in Tuscany.
Consider the
case of exception handling as presented in the travelsample tutorial .
This is an excellent question about a rather tricky area of SCA.
In the specific case you are mentioning, I don't think there's a problem.
See my comments inline below for clarification of how this case would
be handled. I've also added some thoughts on the more general issue of
interface substitutability.
There is a CreditCardPayment service whose interface has been generated
from a wsdl according to JAX-WS 2.1. The generated service interface
interface contains an authorize- method that throws an
AuthorizeFault_Exception.
This CreditCardPayment interface is referenced by the Payment service.
Accordingly, the client code in the Payment implementation has
code like this:
* try*
{
creditCardPayment.authorize( … );
}
*catch*( AuthorizeFault_Exception e )
{
*do_something_with(* e.getFaultInfo().getErrorCode() );
}
Now, presumably the CreditcardPayment implementation on the service
provider side
would really throw an AuthorizeException, which is mapped to an
AuthorizeFault
in the wsdl, from which the client-side AuthorizeFault_Exception is
generated.
Actually the service provider code would throw AuthorizeFault_Exception
because this is what the interface declares for the authorize method.
It's unfortunate that the service-side code in CreditCardPaymentImpl.java
in the travel sample code doesn't declare or throw this exception, which
would have clarified this point.
Accordingly, if we switch to an ordinary Java binding, the Payment
service would need
to reference a different interface containing an authorize-method that
throws an
AuthorizeException, and the client code would look like something this:
* try*
{
creditCardPayment.authorize( … );
}
*catch*( AuthorizeException e )
{
*do_something_with(* e.getErrorCode() );
}
By "an ordinary Java binding" I presume you mean binding.sca. In this
case the interface wouldn't need to change and the client and server
could continue to catch and throw AuthorizeFault_Exception.
Clearly, both the referenced interface and the error handling code in
the business logic
would need to be binding specific.
Does this not defeat one of the original purposes of using Tuscany SCA
in the first place?
Or am I missing something?
-- Sebastian
This is a tricky area and needs care to avoid pitfalls.
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.
Simon
