 | Level: Intermediate Kane Scarlett (kane@us.ibm.com), developerWorks Editor, IBM
24 Apr 2007 When you've built your Web Services Description Language (WSDL), this quick tip will remind you to how to map your interface to httpd-specific commands and settings using the Muse code-generation tool, WSDL2Java.
Let's say you've built your WSDL and you have a Web Services Distributed Management (WSDM) interface for an HTTP server that includes properties and operations from WSDM, WS-Resource Framework (WSRF), WSX, and your own custom definitions. (In other words, you did what you set out to do in the first tip, "So you are building a WSDM interface: Design a WSDL to translate httpd concepts.") Now, how will you map this interface to httpd-specific commands and settings?
You'll do it with the help of Muse's code-generation tool, WSDL2Java. This tool will generate the skeleton Java™ code and XML artifacts for a Muse-based application. Have your http-server.wsdl file (as well as the WS-* files it depends on) in a directory named http-management, and from the command line, switch to the http-management directory and invoke the following:
wsdl2java -proxy -wsdl http-server.wsdl
|
The tool will generate three directories -- JavaSource, WebContent, and src -- and an Apache Ant build file. The JavaSource directory contains the skeleton source code for the httpd-specific capabilities. The WebContent directory contains the Apache Axis2 SOAP engine, Muse libraries, WSDL files, and the Muse deployment descriptor; you should not need to modify anything in the WebContent directory, but its contents should look familiar to those in the Muse SDK's sample projects. The src directory contains the complete source code for a remote client; you can use this code to communicate with the WSDM interface without writing a lot of XML plumbing code.
Drill down through the package directories in JavaSource until you find the Java source files -- they should be named IMyCapability.java and MyCapability.java. By default, WSDL2Java configures the generated application to use Muse's implementations of the WS-* capabilities and then creates Java code for all custom capabilities, such as your HTTP server definitions. Thus, there is no generated code for WSRF, WSDM, or WSX constructs -- these are handled by the Muse libraries that you can find in WebContent/WEB-INF/lib. The source code you see here will be compiled into a JAR file and added to WebContent/WEB-INF/lib by the build file before a Java Platform, Enterprise Edition (Java EE) WAR file is created.
If you open the IMyCapability.java file, you see a Java interface that contains getter and setter methods for all three httpd properties, as well as start and stop methods. It also has a constant for the capability's XML namespace. Finally, notice that it extends Muse's org.apache.muse.ws.resource.WsrfCapability interface, which provides the foundation for all WSRF-based capabilities. The code should look exactly like Listing 1.
Listing 1. IMyCapability.java file
package com.example.www.http_server;
import javax.xml.namespace.QName;
public interface IMyCapability
{
String PREFIX = "tns";
String NAMESPACE_URI = "http://www.example.com/http-server";
public int getThreadsPerChild();
public void setThreadsPerChild(int param0);
public String getServerName();
public void setServerName(String param0);
public int getPortNumber();
public void setPortNumber(int param0);
public void start() throws StartFault;
public void stop() throws StopFault;
}
|
When you look in MyCapability.java, you will see an implementation class that has method stubs for all of the interface's methods. There you go.
Of note: As a reminder, all custom capability definitions are separated by their XML namespaces. When WSDL2Java analyzes your WSDL, it creates a new custom capability (package, interface, and implementation class) for each new schema that is referenced in your port type. For larger projects with port types that tie together more than one schema, this means that there will be multiple implementation classes to complete; it also means you won't have a giant, monolithic Java class to sort through when debugging a particular capability's behavior.
Resources Learn
Get products and technologies
Discuss
About the author | 
| | Kane Scarlett is the editor of the Autonomic computing technology zone for developerWorks. His past publishing work was with such magazines as Unix Review, Advanced Systems, and the -World publications (Java-, Sun-, NC-, Linux-), as well as some little oddball journals like National Geographic Magazine. |
Rate this page
| |
