Page 1 of 3   next page »

In Part 1 of this two-part article I discussed interoperability between .NET and Weblogic 8.1 and issues that arise when transferring data between Web serivces. In Part 2 I will cover some advanced issues: SOAP exception handling, uploading binary information via Web services, and application navigation and workflow.

SOAP Exception Handling
In non-Web Services environments, we're used to building a hierarchy of exceptions and throwing the appropriate exception to indicate the correct feedback to the client. For example, we can define an application exception called "UserNotLoggedInException" (that extends System.ApplicationException) to indicate to the caller that the application has failed because the user isn't logged into the application properly. When the calling method catches this exception, it's aware of the type of error that's occurred.

Exception handling in Web Services differs from the structured exception handling offered in Java or C#, where a developer puts code that can cause an exception in a try/catch clause. Exceptions are caught in the catch clause or bubble up to the calling method if not handled in one of the catch clauses. When an exception is thrown to a calling method, the method understands the data type of the exception and can deal with it accordingly.

With Web Services, exception handling gets a bit more complicated. All exceptions thrown in a Web Service are wrapped by .NET (or WebLogic) as a SoapException. A SoapException generates a SoapResponse that replaces the body of the SOAP message with a SoapFault element. A SoapFault is an XML element that contains elements with information indicating the SoapFault type, an error number, an error message, and an error source. The SoapFault also indicates a URI, which is usually the method that generated the exception. Table 1 displays the layout of a SoapFault. The SoapFault element provides information to the calling method about the exception that occurred.

.NET wraps native exceptions in a SoapException because the Web Service client doesn't understand the native type of the exceptions that occurred in the Web Service. In the last example, a client application calling a Web Service that threw a UserNotLoggedInException exception wouldn't understand this exception class and wouldn't know how to handle it properly. So a Web Service client will always need to handle a SoapException and may need to process the exception further to determine the root of the problem.

The faultcode element is usually set to either "client" or "server." The faultcode is the mechanism that a Web Service can use to indicate to the caller if the source of the error was a server error or a client error. For example, if the application wasn't able to connect to the database, the SoapFault should indicate a (namespace qualified) faultcode element of "server." It indicates that the server encountered an error and the error wasn't dependent on client input. In this case, you would log the error on the server, and return an incident number to the client. The client would display a generic user-friendly error page that indicates to the user that an error occurred and provide an incident number to contact the help desk. The help desk could then review the incident details and attempt to diagnose the problem.

When an error occurs that's dependant on client input, additional processing has to occur. An example of this occurs when the client attempts to access a resource when they are not logged in. In this case, it doesn't make sense to display a generic user-friendly error page; we'd like to let the user know the cause of the error so he can correct the situation. In this case, we would like to redirect the user to a login page so he can be authenticated. A similar (and more likely) scenario occurs when a user attempts to violate a foreign key relationship. For example, a user may try to delete a client who has orders. In this case, we'd like to notify the client via a message that the client can't be deleted because they have dependant data (orders). In both cases, we need to provide additional processing.

To provide additional information to the Web Services client, we generate and throw a SoapException and set the SOAP fault type to "client." This overrides the generation of a default SoapException by .NET (or WebLogic) and returns our custom SoapException. By setting the faultcode to "client," we notify the caller that the error was caused by client input or action.

The SOAP specification indicates that a SoapFault contains a "details" element. The contents of the details element are left open to the developer to define the error information they'd like to communicate to the client. The first step is to define an XML schema to declare the structure of the SoapFault detail element. This is the contract between the Web Service and client that indicates the data that will be passed when a custom SoapException is thrown.

When an exception occurs, we want to pass a message to display to the client. We also want to pass the server exception message and a stack trace to log for assistance in diagnosing the production problems. Listing 1 shows the XML schema we defined to pass this information via a custom SoapException. Listing 2 shows the SoapException XML generated.

In our sample application, we throw a custom SoapException from a WebLogic Web Service, catch, and process it in an ASP.NET application. The throwClientSoapException method throws a custom exception. The code for the throwClientSoapException method is shown in Listing 3.

The code calls the buildSoapFaultException method in the SOAPUtil class. This is a static helper method that builds the custom SoapException (see Listing 4).

The SOAP_NAMESPACE is defined as a Java constant:

  public static final String SOAP_NAMESPACE =
  "http://www.justwebsolutions.com/articles";

//Get SoapExceptionDetail.xsd full path
string schemaRelativePath = "../schemas/SoapExceptionDetail.xsd";
string schemaFullPath =
HttpContext.Current.Server.MapPath(schemaRelativePath);

//Read the Schema into the DataSet
dsError.ReadXmlSchema(schemaFullPath);

Page 1 of 3   next page »