WebLogic & .NET: Making Web services that work
WebLogic & .NET: Making Web services that work
By: Guy Molinari
May. 20, 2002 12:00 AM
As a developer for a company selling application services to Fortune 500 companies, I was excited about the release of WebLogic 6.1. While its support of J2EE 1.3 features in and of itself is a reason to upgrade or adopt this product, the introduction of SOAP/WSDL-based Web services technology is a significant step forward for an already great application server. What I found interesting about BEA's approach is how relatively simple it is to tap the power of this new infrastructure. For RPC (synchronous-style) services it is a straightforward two-step process.
First, create a stateless session EJB that implements the application logic. The only catch here is to design the interface method signatures in such a way that only simple objects are passed. Think of these objects as complex types that expose no behavior other than get/set functionality to manipulate properties (as per the JavaBeans spec). Arrays of complex types and nesting of complex types are also supported. The key design principle is to keep the approach simple and drive behavior into the service itself. If heterogeneity is a design goal, then don't think of Web services as an object serialization technique but rather as a way of exposing business-event functionality.
Second, use the wsgen Ant task to create the enterprise archive .ear file. WebLogic bundles this task as well as Ant version 1.3 with the WLS product distribution. The product documentation provides a detailed description of exactly how to accomplish this. My build.xml scripts include the following snippet:
<target name="webservice" depends="init">
This defines a new target called webservice. It depends upon a target called init, which by convention defines environment variables and parameters. All of my scripts define the beanname variable that's used in various ways to name the necessary files. This target will create and deploy the .ear file within a running WLS instance. That's all there is to it! WLS 6.1 implements a conservative subset of SOAP and WSDL in a very simple way. It leverages the framework already established by EJB and provides the developer with a mechanism for exposing existing EJB components as Web services without any additional Java coding.
Bumps in the Road Are Inevitable in Any Journey
I was working on a project that required that .NET clients be able to call WLS-deployed services. My code worked well when my method signatures used native types (as defined by XML Schema) as a parameter or return value. Unfortunately, complex types or arrays of any type were another matter entirely. This is an unacceptable limitation in the face of real-world requirements. I turned to the WLS documentation looking for insight and saw a note stating that WLS 6.1 supports version 2.0 SP2 of Microsoft's SOAP Toolkit. As a key player on the W3C XML committees, Microsoft decided to adopt the 2001 XML Schema (XSD) specification in its .NET Framework. The SOAP Toolkit is based on the 1999 recommendation, as is WLS 6.1
It's ironic that there's a need for this article, considering that Web services are being touted as the interoperability panacea. In all fairness, the issues addressed arise because newer technologies forming the foundation for emerging protocols such as SOAP and WSDL are still evolving. Understandably, application server vendors must provide infrastructure components that are stable and reliable. These needs must override the desire to support the latest and greatest industry specifications. Undaunted, I decided to dig down deeper into the interoperability issues in the belief that these problems are solvable, given the simplicity and elegance of XML-based Web services technology.
This article outlines the XML-related interoperability issues a developer must face, given the current state of WLS and .NET. They can be categorized into two areas of concern pertinent to WSDL and SOAP, respectively. WSDL (Web Services Description Language) seems like a logical place to begin since before a newly created Web service can be invoked, it must be bound to the calling process.
WSDL Stack Interoperability Issues
When a WLS Web service is deployed, a public-facing Web page (JSP) is made accessible. This page contains two links: the first generates the WSDL file that describes the service, and the second allows for the downloading of a file called client.jar by convention. This .jar file contains the client-side proxy class, SOAP codecs, and some fairly lightweight infrastructure classes provided by BEA to simplify the consumption of services. This is the only .jar file needed in the CLASSPATH, other than client application-related code. For Java-based clients the WSDL is extraneous and is useful only for UDDI registries. For non-Java clients, the opposite is true.
Considering the problem, I knew that the first step in consuming the service was to create the necessary client-side proxy with C# code (although VB.NET would be an equally viable alternative). As a Java programmer with a C/C++ background, I felt comfortable with C# almost immediately, which drove my choice of languages. After downloading and installing the ASP.NET package, I immediately learned that Microsoft's approach to Web services involves the compilation of the WSDL to generate the proxy code. This can be accessed via the command-line utility WSDL.EXE or by using Visual Studio .NET. These tools are HTTP-enabled and can retrieve and compile the WSDL in one step. The WSDL compiler generates a source file with a .cs extension named by the name attribute of the service XML element in the WSDL file. This file is then compiled into a .dll. The service is called from the client code by instantiating the generated proxy class and invoking its methods as if they were local to the client process. In my case, the WSDL document created by WLS wouldn't compile correctly with the .NET-provided compiler.
The Web service I created and deployed on WLS is called PresentationController and has one method, named dispatchAction. This method takes five parameters. The first four are simple string types and the last is an array of NameValuePair JavaBean instances specific to my application code. The WSDL file generated by WLS is shown in Listing 1 . Notice the description element at the top of the document. The namespace attribute references the 1999 XSD spec. This is the first of three changes that must be made to the WSDL to bring it up to 2001 compatibility. Because my code utilizes the NameValuePair JavaBean, the WSDL contains an embedded XSD schema enclosed with a schema element. This element contains standard XSD definitions of any complex types that are referenced by the service described. The 1999 XSD specification allowed members of a complex type to be specified using attribute elements, while the 2001 spec uses element elements (confusing, eh?). Also, the 2001 spec mandates that all members of the complex type be enclosed within a sequence element to preserve order occurrence. The modified and MS-compatible WSDL file is shown in Listing 2. I wrote a simple tool that parses the WSDL file as an XML DOM, makes the changes I've previously described, and generates the converted document. The code for this utility is in Listing 3. A slicker approach would be to create a chained servlet that does the conversion on the fly without intermediary files. This exercise is left to the reader.
SOAP Stack Interoperability Issues
The Microsoft .NET Framework provides an API for intercepting and altering the SOAP XML payload. It is called SOAP Extensions and can be utilized in client-side proxies as well as .NET-hosted services. Listing 4 contains the C# source code for an extension called DispatchExtension, as well as its related DispatchExtensionAttribute attribute class. It's beyond the scope of this article to describe in detail how to write .NET SOAP extensions; suffice it to say that the method fixXML() does most of the heavy lifting. For the sake of simplicity this is a brute-force approach that completely discards and rebuilds the message body. As an exercise for the reader, this code could be generalized to automatically detect array types and apply intelligent filtering.
When you've written and compiled your SOAP extension, there's one final step. That is to register the attribute class with the appropriate method in your generated proxy class. The following C# snippet from the PresentationController proxy class shows how this is done:
In the snippet above, the attribute constructor for DispatchExtension is placed before the dispatchAction method. Be careful! If you change the interface of your service you will need to reapply this modification.
Hopefully, the next release of WLS will include an update of the XML serialization/deserialization infrastructure and SOAP codecs to resolve these issues. Also, the ability to manipulate the SOAP interactions via a callback interface would be a big plus. Overall, BEA has done a superb job in delivering entry-level Web services capabilities in its currently shipping product release. This platform, combined with the excellent tool offerings of .NET, will provide the developer with a best-of-breed toolbox of architectural options.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week