This is just the request. In fact, this is just one variation of the request, the RPC/encoded variation. There are at least three others. With enough time, you could probably decipher this message. With even more time, you could probably write a program that would generate such a request. But the truth is that the conversation is so complex that just about any programmer will need some sort of help to get this programming feat accomplished. And that would be just one small part of the entire Web Service deployment.

WDSc to the Rescue

And that is where WDSc comes in. The WDSc wizards make it painless to create a Web Service. Not only that, but because there are so many different tasks involved in deploying a Web Service, WDSc came up with a new concept, the cheat sheet. Sort of a "meta-wizard," the cheat sheet is a walkthrough of the various steps required to create and deploy a Web Service. The cheat sheet for creating a Web Service from a JavaBean is depicted in Figure 1.

Figure 1: This is the cheat sheet for creating a Web Service from a JavaBean. (Click images to enlarge.)

I actually used this cheat sheet to create a Bean from a Web Service. My "JavaBean" is a simple class that takes a string (this is meant to be a customer number) and returns the associated email address. I put the term "JavaBean" in quotes because you don't really need to adhere to the conventions of a traditional JavaBean. There is a step in which a wizard looks through your class and lists all of the methods, and you can select the ones you want to make visible.

My Web Service

Currently, my class is really simple, as shown in the code below:

I'm not trying to be facetious here; I simply wanted to quickly create something that was a little more business-like than adding two numbers. This class will use the input parameter as a key to retrieve an email address. In a real business application, this would involve a connection to a database, but in this case, I use a simple TreeMap, which is basically a keyed list. I told you the class was simple; there is more code in the initialization than in the rest of the class.

What I Had to Do

Once the class was written, turning it into a Web Service required very little work. All I had to do was follow the steps in the cheat sheet. I read the introduction shown in Figure 1 and then clicked on the arrow at the bottom. This marked the first section of the cheat sheet complete and moved me on to the next section, as shown in Figure 2.

Figure 2: This is the second task in the cheat sheet, creating a Dynamic Web Project.

After reading what was going to happen, I clicked on the black arrow, which then brought up the appropriate wizard for the step. In this case, the wizard was the New Web Project wizard (Figure 3). I entered a name for my project (WSServer) and continued on.

Figure 3: This is the New Web Project wizard, which was invoked by the cheat sheet.

I continued working my way through each step of the cheat sheet until I had a working Web Service that I could test through the Web Services Explorer (Figure 4).

Figure 4: The Web Services Explorer is used to test a Web Service.

I continued on with the cheat sheet and created a Web Services client and then ran that within the workbench. That gave me a lightly different view of the same Web Service (Figure 5).

Figure 5: This is the Web Service after being called by the generated Web client proxy.

As you can see, the results are the same, which is a good thing. In the meantime, though, the workbench created an entire new project for me, as well as four client classes (in addition to the hefty WSDL file it created during the previous step).

What It Does, It Does Great

The Web Services cheat sheet works probably as well as anything like it I've ever seen. The integration between it and the various WDSc wizards is smooth, and the step-by-step nature of the approach appeals to me. And the cheat sheet I used is only one of three Web Service scenarios and only one of six cheat sheets. Given how well they work, I'm going to try some of the others when I get a chance.

The trick to the cheat sheet is how it encapsulates everything in simple, easy-to-follow steps that invoke the powerful WDSc wizards. With this technique, almost all of the actual work is hidden from you.

The Devil Is in the Details

Now, I must sound a warning, if only a mild one. Up until this point, everything has worked flawlessly, but that's because I've stayed strictly within the boundaries of the cheat sheet. Let's say I want to do something a little out of the ordinary; for example, suppose I want to write my own test client.

It would seem reasonable that I could simply go into the generated client code and start to play with it. The problem is that the code isn't that simple. There are over 300 lines of JSP code alone required to display the simple screen shown in Figure 5. Add to that over 200 lines of Java in the four generated classes, and it starts to get awfully top-heavy.

I managed to cut the client-side code in half, creating a simple client class that invokes a Web Service without all the extra baggage of the JSP. However, because everything is wrapped in a SOAP document, I was unable to remove the bulk of the code that formats the document. The code below shows one method generated by the Web Service wizard.

Although I tried, I was unable to remove the dense, nearly unreadable code generated in the bowels of the Web Service. And remember, this is for an almost trivial example. And even the code shown above is simplified; in the original code, every class was fully qualified, like so:

So if I wanted to write my own version of this code, I'd have to figure out how the IBM classes work, and I don't believe IBM is releasing the source to the com.ibm.ws.webservices packages. That means a lot of guesswork on my part to make use of those classes, as well as the chance that my custom code could break with the next release of IBM's jar files.

So what does this all mean? Among other things, it means I'm stuck using whatever code WDSc generates. I can't go in and customize and streamline the code to my own liking, and since this code must be all things to all Web Services, I end up with some pretty fat code.

Also, I don't really know what this code does. Through careful examination, I think I can puzzle out some of what is intended, but given the high use of specialized IBM classes, I'm not sure I would be able to debug this in the event of a failure.

And that brings me back to my opening quotation: To me, the Web Services wizards generate code that, while good enough for testing, is really only a substitute for production code, not the real thing. Like someone who can quote witticisms to seem witty, I can use the wizards to generate Web Services and seem Web-enabled, but unless I can get in and debug those generated classes, I hesitate to put them into production.

Lots of Compliments and a Caveat

By far, the news is good. The VIC is doing great things, and the Web Services cheat sheets functioned flawlessly and indeed managed to automate a process of substantial complexity. I am still raising a red flag, albeit a small one, regarding the proliferation of wizard-generated code that may or may not be debuggable in production, but the fact that I turned a class into a Web Service in about 10 minutes is an awfully strong argument in favor of the process.

Joe Pluta is the founder and chief architect of Pluta Brothers Design, Inc. He has been working in the field since the late 1970s and has made a career of extending the IBM midrange, starting back in the days of the IBM System/3. Joe has used WebSphere extensively, especially as the base for PSC/400, the only product that can move your legacy systems to the Web using simple green-screen commands. Joe is also the author of E-Deployment: The Fastest Path to the Web and Eclipse: Step by Step, with WDSc: Step by Step coming out this September. You can reach him at This email address is being protected from spambots. You need JavaScript enabled to view it..