Designing a Service's Interaction Layer
interface associated with the WSDL in Code Example 3.7
might invoke the service as shown in Code Example 3.8.
Context ic = new InitialContext();
WeatherWebService weatherSvc = (WeatherWebService)
WeatherServiceIntf port = (WeatherServiceIntf)
String returnValue = port.getWeatherByCity("San Francisco");
Code Example 3.8
Using Weather Service with WSDL to Java Approach
Just like any Java or J2EE application, a Web service application may encounter an
error condition while processing a client request. A Web service application needs to
properly catch any exceptions thrown by an error condition and propagate these
exceptions. For a Java application running in a single virtual machine, you can prop
agate exceptions up the call stack until reaching a method with an exception handler
that handles the type of exception thrown. To put it another way, for non Web
service J2EE and Java applications, you may continue to throw exceptions up the
call stack, passing along the entire stack trace, until reaching a method with an
exception handler that handles the type of exception thrown. You can also write
exceptions that extend or inherit other exceptions.
However, throwing exceptions in Web service applications has additional
constraints that impact the design of the service endpoint. When considering how
the service endpoint handles error conditions and notifies clients of errors, you
must keep in mind these points:
Similar to requests and responses, exceptions are also sent back to the client as
part of the SOAP messages.
Your Web service application should support clients running on non Java plat
forms that may not have the same, or even similar, error handling mechanisms
as the Java exception handling mechanism.