We all know that the .NET platform offers a great set of tools for building robust Web applications. There are times, however, when as .NET developers we need to understand how we can integrate the great features of .NET with other platforms and technologies. We often find our clients using both .NET and J2EE technologies successfully in their architectures.

I faced a situation such as this recently and I would like to share some of my experiences with you in this two-part article. Part 1 will discuss interoperability between ASP.NET and BEA WebLogic 8.1, and how to use XML Schemas to transfer data between the platforms. Part 2 will discuss how to properly process SOAP Exceptions, the uploading and viewing of binary data, and how we handled page navigation and application workflow. The source code for this article can be found at http://sys-con.com/weblogic/sourcec.cfm.

On a recent project, the client decided that they wanted to use J2EE technology (specifically BEA WebLogic 8.1) to support their core legacy applications. The new Web application would let vendors enter information that would be validated and transferred directly into the core application database. WebLogic would provide the business functionality via Web Services. The client had several applications developed in C# using Visual Studio.NET and wanted to take advantage of the productive features in ASP.NET to develop the presentation layer of the application.

There are various technologies we could use so .NET could communicate with J2EE. The most popular one is XML Web Services. The main benefits of Web Services are the industry support, tool support, and ease of development.

There are also several products such as Ja.NET (http://ja.net.intrinsyc.com/ja.net/info) or Janeva (www.borland.com/janeva) that bridge .NET and J2EE environments to allow binary communications and share native data types and stateful communication. These products bridge .NET and J2EE by configuring .NET Remoting to behave like a Java RMI/Corba client or server. Bridging .NET and J2EE provides more robust functionality and performs better than XML Web Services. The big drawbacks in using a bridging technology are the complexities of learning and configuring the bridging product and the cost of licensing it. We decided to use XML Web Services because the web application didn't need stateful communication and speed wasn't as high a priority as development time and cost.

The solution was to use ASP.NET Web Forms in the presentation layer communicating with Web Services hosted on WebLogic, which would provide the business services and data persistence. The presentation tier would display, capture, and perform simple domain validations on the data. The business tier would apply the business rules and the data tier would persist data to a SQL Server database. The ASP.NET Web Forms would communicate with the WebLogic business layer using WebLogic Web Services.

WebLogic Web Services are built using the WebLogic Web Services toolkit. It lets you expose a Java object as a Web Service without additional coding. WebLogic Web Services support the following components as the source of a Web Service:

• A method of a stateless session Enterprise Java Bean (EJB)
• A method of a Java class
• A JMS message consumer or producer

In our application, we used stateless session beans as a facade to the business logic and data persistence logic. The pattern we followed is the Session Facade pattern, which provides a single interface for application functionality and allows for course-grained access to business objects. You can find more information on the facade pattern at http://java.sun.com/blueprints/patterns/SessionFacade.html.

We also implemented an intermediate class to act as a business delegate that decouples business components from the code that uses them. Specifically, the business delegate class assisted in implementing exception handling by letting us throw application exceptions from Session EJBs and catch them in the business delegate class that then builds a custom SOAP exception. This is discussed in more detail in the section on SOAP exception handling and you can find more information on the business delegate pattern at http://java.sun.com/blueprints/patterns/BusinessDelegate.html.

Figure 1 shows the overall architecture of our application.

There were several challenges we faced. In this article I'll discuss some of these issues, how we decided to tackle them in our implementation, and our advice to anyone using a similar architecture.

We identified the following issues:

• We needed to ensure that the Web Services we developed were interoperable between ASP.NET and BEA WebLogic 8.1.
• We needed to determine the best method to transfer data via Web Services between the platforms.
• We needed to determine how we were going to do exception handling between the two platforms.
• We needed to upload and view images that would require the transfer and retrieval of binary information (images) via Web Services.
• We wanted to devise a plan for handling page navigation and application workflow.

The SOAP specification dictates that the contents of a message sent via a Web Service must be XML-formatted, but the specific format used is open to the vendor. The two predominant styles WebLogic supports are RPC-style and document-style. An RPC-style message is one in which the SOAP messages contain parameters and return values. A document-style message is one in which the SOAP messages contain XML documents.

The default style for .NET XML Web Services is document. The default style for the WebLogic Web Services toolkit is RPC (as it is for the Microsoft SOAP Toolkit v2). The preferred style is a source of debate. Many feel that document style is more flexible. Both styles are transparent to an ASP.NET developer since the proxy class generated by wsdl.exe supports both. Since interoperability was the key issue, we chose the RPC style, which has a longer history of support in most toolkits, and also makes the Web Service appear like a local API to the caller. RPC style also let us design Web Services interfaces similar to the standard interfaces we would use in Java or .NET.

There are two styles of encoding native data types in the XML sent as part of a SOAP message - SOAP encoding and literal encoding. SOAP encoding uses the SOAP specification to map native data types to XML. The SOAP specification defines native data types that are supported and you must use one of these data types. Literal encoding uses XML Schema to include a definition for all non-standard data types in the XML message itself. Literal encoding is more flexible in this instance.

RPC-style WebLogic Web Service operations must use SOAP encoding. Document-style WebLogic Web Service operations must use literal encoding. All operations in a single WebLogic Web Service (class) must be either RPC-style or document-style; WebLogic Server doesn't support mixing the two styles in the same implementation. Since we were using an RPC style of Web Service, all the Web Services in WebLogic would use SOAP encoding.

In the WebLogic application, we used built-in data types exclusively to minimize the development effort. Built-in data types are those specified by the JAX-RPC specification. When using built-in data types, WebLogic automatically handles the conversion of the data between its XML and Java representation. If the Web Service uses a non-built-in data type as a parameter or return value, you must create a serialization class to convert the data between Java and XML.

Table 1 lists the built-in data types WebLogic supports.

For the most part, we encountered few incompatibility issues consuming WebLogic 8.1 Web Services in an ASP.NET application. One issue of note is the use of SOAP encoding. While the WS-I Basic Profile 1.0 (BP) requires the RPC style and literal encoding, using RPC style in WebLogic requires SOAP encoding which violates the WS-I Basic Profile 1.0. For more information on the WS-I Basic Profile 1.0, see the sidebar, "WS-I Basic Profile 1.0." We should also note that using WebLogic Web Services, you can't expose static methods as a Web Service; they must be class-level methods.

Transferring Data via Web Services
Since the application needed to call non-.NET Web Services, the mechanism that we used to transfer data couldn't use data types or objects specific to .NET. In previous projects we had passed DataSets through Web Services and bound them to ASP.NET components in our Web applications. Since WebLogic has no concept of a DataSet, we couldn't use this approach. We considered a number of alternatives.

We considered building a mechanism to generate XML that would be identical to the XML generated from a DataSet. This would require generating an XML schema dynamically based on the data being passed and then the generation of XML data based on the dynamic schema. We decided against this solution because we felt it would take a great deal of effort to code and was susceptible to future changes in ADO.NET

Another option was to use value objects to pass the data. Value objects are based on the "Value Object" Pattern and represent simple classes with properties and accessor/mutator (get/set) methods. Value objects are often used in J2EE architectures to pass data between tiers. In this case, a value object or collection of value objects would be instantiated in a WebLogic Web Service and data would be stored in these classes. The data would be received in the ASP.NET application as a proxy object, which is a client representation of the Java classes. The classes must use primitive data types (or other collection objects such as ArrayLists that are recognized by both environments).

We decided against this solution because of the effort involved in parsing the data passed via the proxy objects. Under this approach a .NET developer would need to write code to parse the values from the proxy object and put them in a DataSet. This is relatively simple to code but it's a rather tedious and unnecessary step. The code would also need to change each time the data returned from the Web Service changed.

We wanted to find a solution that would involve minimal coding, use technologies available in both .NET and WebLogic, and would let ASP.NET developers bind objects such as DataGrids or DataLists directly to the data returned from the Web Service (as can be done when passing DataSets from a .NET Web Service).

The solution we decided on was to use XML schemas as the root of our solution. For each result set, we built an XML schema to define the data in the result set. To generate the XML data in the WebLogic environment, we used a product called XMLBeans. XMLBeans is a Java-XML binding tool that lets you to generate Java objects based on an XML schema easily. It generates an object representation of an XML schema in Java classes. BEA uses XMLBeans extensively in WebLogic itself. XMLBeans is an open source product originally developed by BEA and released to the open source community via Apache. You can learn more about XMLBeans at http://dev2dev.bea.com/technologies/xmlbeans/index.jsp and you can download the BEA version at http://workshop.bea.com/xmlbeans/XsdUpload.jsp.

Using XMLBeans, we generated a set of Java classes to contain our data and then used the XMLText method to get an XML document instance based on the object data. We could then pass this XML string via a Web Service to our ASP.NET application.

In the ASP.NET application, a developer could instantiate a DataSet, load in an XML schema to define the structure of the DataSet, and then load the XML document into the DataSet via the LoadXML method. In our example, which is based on the Northwind database, we build a schema to represent a set of client and order data. The ClientOrders.xsd schema is shown in Listing 1. To generate a set of Java objects based on the ClientOrders.xsd schema, you need to download and install the XMLBeans toolkit. As with all Java tools, you need to set the correct location of the Java SDK before running it. If you've installed a Java product (such a JBuilder or WebLogic), an SDK will likely be installed. Listing 2 shows a sample batch file that you can use - you will need to set the "JAVA_HOME" variable to point to your Java SDK location. The sample batch file expects to find the XMLBeans library (xbean.jar) in the default installation location (C:\xmlbeans).

Once you've run the XMLBeans tool, you'll have a .jar file that contains the classes that are the object representation of a ClientOrders.xsd XML schema.

The output should look like this:

C:\xmlbeans\output>scomp ClientOrders.xsd
Loading schema file ClientOrders.xsd
Time to build schema type system: 3.655 seconds
Time to generate code: 12.107 seconds
Compiled types to xmltypes.jar

Rename the xmltypes.jar file to ClientOrders.jar. The Java code sample simply instantiates the Java classes and uses the mutator methods to set sample values based on the Northwind database. In a real-life situation, you'd likely use a Java technology (such as JDBC or EJB) to access the database and get live data. After building the appropriate Java objects, the code calls the XMLText method to get an XML document instance representing the client and order data. The XML document instance can be validated using the ClientOrders.xsd XML schema. We then pass this XML string as the result of the Web Service generateTestData method.

Listing 3 shows the sample Java code to use the ClientOrders.jar to build an XML document instance.

The code for the ASP.NET client page first instantiates a Web Service proxy and makes the call to the WebLogic Web Service.

// Call J2EE web service and obtain xml document
weblogic.BusinessDelegate proxy = new weblogic.BusinessDelegate();

// Obtain XML document instance
string xmlDoc = proxy.generateTestData();

The ASP.NET client page then defines a DataSet, reads the XML into a string, uses the ClientOrders.xsd schema to define the DataSet structure, and loads the DataSet using the XML string passed.

DataSet dsClientOrder = new DataSet();
dsClientOrder.EnforceConstraints = false;
DataTable dataTable = new DataTable();

string schemaRelativePath = "~/Schemas/ClientOrders.xsd";
string schemaFullPath = HttpContext.Current.Server.MapPath(schemaRelativePath);

StringReader stringReader = new StringReader(xmlDoc);
XmlReader xmlReader = new XmlTextReader(stringReader);
dsClientOrder.ReadXmlSchema(schemaFullPath);
dsClientOrder.ReadXml(xmlReader, XmlReadMode.IgnoreSchema);

The ASP.NET client page then binds the DataSet to the dgClients and dgOrders datagrids.

// now bind to DataGrids
dgClients.DataSource = dsClientOrder;
dgClients.DataMember = "ClientOrder";
dgClients.DataBind();

dgOrders.DataSource = dsClientOrder;
dgOrders.DataMember = "Order";
dgOrders.DataBind();

Figure 2 shows the page after the code has completed.

We got the benefit of XML schema validation on our data, used an object representation of the data in WebLogic, and passed the data to the ASP.NET application in a way that made loading the data into a DataSet straightforward. We could then bind GUI objects such as a DataGrid or DataList directly to the DataSet table. This eliminates the need to parse the data passed by the Web Service. It also provides a flexible architecture in which the changes to the data passed to the ASP.NET application don't require changes to the interface. The data passed isn't validated by an interface, but it is validated via the XML schema.