The application then loads the XML string passed from the Web Service into the DataSet via the ReadXml method.

//Get exception detail xml string
string xmlString = ex.Detail.OuterXml;

//Read the xml string into a StringReader object
StringReader stringReader = new StringReader(xmlString);

//Read the StringReader into the XmlReader object
XmlReader xmlReader = new XmlTextReader(stringReader);

//Read the Xml into the DataSet
dsError.ReadXml(xmlReader, XmlReadMode.IgnoreSchema);

// Create an instance of  DataView object
dataView = new DataView();

// Specify the table
dataView.Table = dsError.Tables["Error"];

// Get the first row
DataRow dsErrorRow = dataView.Table.Rows[0];

// Get the relevant Error message
message = dsErrorRow["ClientErrorMessage"].ToString();
txtSOAPClientMessage.Text = message;

There's one additional issue to consider when processing a SoapException thrown via a WebLogic Web Service. If you choose to expose a Session EJB as a Web Service, there's an additional caveat. Runtime (non-checked) exceptions thrown in Session EJBs are packaged by the EJBContainer as an EJBException before being thrown to the caller. This is mandated by the J2EE specification. EJBExceptions in a Web Service are automatically processed by WebLogic and wrapped using default SoapException processing. It doesn't let you override this processing to generate a custom SoapException. It's one of the reasons we used a business delegate layer (see Figure 1). It lets us throw our exception as a custom application exception in WebLogic, and in the business delegate class (which is a simple Java class), it allows us to catch the application exception, generate, and throw a custom SoapException.

Uploading binary information
In our application we needed to let users upload binary images to our site. The images then had to be available to other users of the application. The images contained confidential information for our clients, so we needed to ensure that the images couldn't be viewed easily in the Web application by manipulating the URL. As part of out business analysis for the site, we viewed the sites of some of our client's competitors and were surprised to see that we could often guess the names (and sequence numbers) of the images and could see information that was private and confidential.

So we stored the images on our WebLogic server (on the file system) and streamed the binary contents of the file via a Web Service. The client, an ASP.NET Web page, would gather the file's binary contents and stream them to the client browser.

The first issue we needed to resolve was the technology we were going to use to send the binary information via Web Services. There were two different alternatives: send the data via a binary data type or via the SOAP With Attachments protocol. We did some research and found an interesting paper written by several Microsoft and BEA architects at http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/dnwebsrv/html/infoset_whitepaper.asp. The paper advocates encoding the data via a binary data type such as xs:base64binary or xs:hexBinary because of security issues with out-of-band attachment data as well as the fact that SOAP Messages With Attachments don't conform to the Basic Profile 1.0 (BP) published by the Web Services Interoperability Organization (WS-I). That raised some potential performance issues with using text representations of binary code, but, since we weren't transferring a lot of binary data, optimal performance wasn't the most important issue. Based on that white paper, especially given the authors and the equal representation of Microsoft and BEA, we decided to use binary data types to send image data in our Web Service rather than using the SOAP With Attachments API. Once we established our approach, we needed to map out the steps. We would use the .NET upload HTML control to send the binary data to the Web server. Once the user uploaded the image to the Web server, the application needed to do the following in the ASP.NET application:

1. Check that the image extension was valid.
2. Define a temporary file name for the image and call the fileInput.PostedFile.SaveAs method to save the file to a temporary area on the Web server.
3. Check the size of the image to make sure it wasn't beyond the limit allowed.
4. Convert the image to a byte array.
5. Call the Web Service passing the byte array.
6. Delete the temporary file.

The Web Service code in BEA's WebLogic needed to get the byte array, create a file on the file system from it, and store the name of the image in the database so the image could be viewed in the future.

Listing 7 shows the Java code that did these steps. In the example we simply stored the file on the application server's file system. In our production application, we added a couple of additional steps to obfuscate the file name and to store the files in a hierarchical structure on the file system (rather than in the same directory) to make file system navigation and lookup more efficient.