See comments below.
Simon
Millies, Sebastian wrote:
From: Simon Nash [mailto:[email protected]]
Sent: Thursday, August 19, 2010 4:59 PM
To: [email protected]
Subject: Re: Error handling, bindings and business logic
[snip]
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
Thank you for that explanation. I have a follow-up question with regard to
the default binding:
The book states in section 2.5.2 that "Tuscany uses Web services over
SOAP/HTTP for remote calls over the default binding" (within the same domain).
How does the pure Java bottom-up approach work when I deploy the client and
service in different JVMs in the same domain, e. g. on different servers in
a cluster? Or will it break even then?
No, everything works fine in a pure Java environment using the default binding
to connect services running in different JVMs or on different computers
in a network. Under the covers the Tuscany runtime uses the JAX-WS and JAXB
Java-to-WSDL mapping to create WSDL from the Java service interfaces, then
uses this generated WSDL to create web service endpoints for the distributed
SCA services. All this is completely transparent to the Java business logic
which doesn't see any JAX-WS artifacts or APIs. However, the Java service
interfaces do need to be JAXB-friendly (e.g., no unannotated interface types
passed as method arguments).
(When the client and service are within the same JVM, I assume there is no
problem
because this is not a remote call, and Java introspection would be used to discover
and invoke the correct service method.)
Yes, this case is automatically optimized by the Tuscany runtime to make
direct in-process calls and avoid going through the Web Services runtime stack.
Simon
-- Sebastian
