Designing a Service's Interaction Layer
extends another exception, such as
, then when the service throws
methods and properties inherited from
passed to the client.
The exception stack trace is not passed to the client.
The stack trace for an exception is relevant only to the current execution envi
ronment and is meaningless on a different system. Hence, when a service throws
an exception to the client, the client does not have the stack trace explaining the
conditions under which the exception occurred. Thus, you should consider
passing additional information in the message for the exception.
Web service standards make it easier for a service to pass error conditions to a
client in a platform independent way. While the following discussion may be of
interest, it is not essential that developers know these details about the J2EE plat
form's error handling mechanisms for Web services.
As noted previously, error conditions are included within the SOAP messages
that a service returns to clients. The SOAP specification defines a message type,
, that enables error conditions to be passed as part of the SOAP
message yet still be differentiated from the request or response portion. Similarly,
the WSDL specification defines a set of operations that are possible on an end
point. These operations include
operations, which represent the
request and response respectively, and an operation called
defines system level exceptions, such as
which are irrecoverable errors. The WSDL
denotes service specific excep
tions, such as
, and these are recoverable application error
conditions. Since the WSDL
denotes a recoverable error condition, the plat
form can pass it as part of the SOAP response message. Thus, the standards
provide a way to exchange fault messages and map these messages to operations
on the endpoint.
Code Example 3.13 shows the WSDL code for the same weather Web service
example. This example illustrates how service specific exceptions are mapped
just like input and output messages are mapped.