Comments
yourfanat wrote: I am using another tool for Oracle developers - dbForge Studio for Oracle. This IDE has lots of usefull features, among them: oracle designer, code competion and formatter, query builder, debugger, profiler, erxport/import, reports and many others. The latest version supports Oracle 12C. More information here.
Cloud Expo on Google News
SYS-CON.TV
Cloud Expo & Virtualization 2009 East
PLATINUM SPONSORS:
IBM
Smarter Business Solutions Through Dynamic Infrastructure
IBM
Smarter Insights: How the CIO Becomes a Hero Again
Microsoft
Windows Azure
GOLD SPONSORS:
Appsense
Why VDI?
CA
Maximizing the Business Value of Virtualization in Enterprise and Cloud Computing Environments
ExactTarget
Messaging in the Cloud - Email, SMS and Voice
Freedom OSS
Stairway to the Cloud
Sun
Sun's Incubation Platform: Helping Startups Serve the Enterprise
POWER PANELS:
Cloud Computing & Enterprise IT: Cost & Operational Benefits
How and Why is a Flexible IT Infrastructure the Key To the Future?
Click For 2008 West
Event Webcasts
WebLogic & .NET: Making Web services that work
WebLogic & .NET: Making Web services that work

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">
<wsgen destpath="/xylo/dev/${beanname}.ear" con
text="/${beanname}" protocol="http">
<rpcservices
path="${jardest}/ejb_${beanname}.jar">
<rpcservice bean="${beanname}"
uri="/${beanname}"/>
</rpcservices>
</wsgen>
</target>

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.

Interoperability Issues

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 next category of interoperability issues revolves around the SOAP messages sent from client to server. As with WSDL, the .NET platform SOAP messages conform to XSD-2001. For the most part these messages are backward-compatible with the WLS FastParser. The showstopper is in the SOAP ArrayType encoding for arrays passed from the client. This is a problem with arrays of native types as well. According to the WLS release notes, there is a known issue, #055596: "WLS Web services do not support SOAP 1.1 multireference compound data types." Again, no workaround is given. XSD-2001 provides a slick optimization technique that allows a node to be referenced in multiple places. For large arrays this can greatly reduce the size of the message, thus conserving bandwidth and shortening parse times. Similar to the WSDL converter, what is needed is a mechanism to filter SOAP interactions.

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:

[DispatchExtension()]
public string dispatchAction(string arg0, string arg1, string arg2,
string arg3, NameValuePair[] arg4) {

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.

Conclusion
When resolving interoperability challenges, be sure to plan for the eventual removal of adapter code as infrastructure vendors evolve their product offerings and correct software deficiencies.

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.

About Guy Molinari
Guy Molinari has more than 15 years of experience in developing enterprise applications. For the past three years he has provided Web architecture/infrastructure support for Onvia.com and Xylo, Inc., a Bellevue, WA-based application service provider.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

Latest Cloud Developer Stories
The precious oil is extracted from the seeds of prickly pear cactus plant. After taking out the seeds from the fruits, they are adequately dried and then cold pressed to obtain the oil. Indeed, the prickly seed oil is quite expensive. Well, that is understandable when you conside...
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed...
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering cons...
ScaleMP is presenting at CloudEXPO 2019, held June 24-26 in Santa Clara, and we’d love to see you there. At the conference, we’ll demonstrate how ScaleMP is solving one of the most vexing challenges for cloud — memory cost and limit of scale — and how our innovative vSMP MemoryON...
Darktrace is the world's leading AI company for cyber security. Created by mathematicians from the University of Cambridge, Darktrace's Enterprise Immune System is the first non-consumer application of machine learning to work at scale, across all network types, from physical, vi...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021



SYS-CON Featured Whitepapers
ADS BY GOOGLE