dcsimg

Creating Web Services with AXIS

Java developers interested in building Web services will find the AXIS toolkit

axis_01

If you’ve invested heavily in the Web — dynamic content, personalized Web pages, extensive browser scripting, and site security — you might be wondering if Web services are even necessary for your business. After all, your Web presence probably didn’t come cheap (even if you used Linux and open source tools), and it meets all of your needs. After all, you say, interoperability is not a new ideal, and the features espoused by Web services are not revolutionary. So why adopt yet another technology?

What makes Web services promising and practical is infrastructure and standards. Given the pervasiveness of the Web and a handful of standards (for an overview of the prevailing Web services standards, see the accompanying article on page 22), it’s now tractable for any business to interoperate with any other business. That’s the promise of Web services.

And, as it turns out, the larger the investment you’ve made in the Web, the better suited you are to deploying Web services. Instead of replacing the technology you’ve worked hard to deploy, Web services can leverage it. Just think of Web services as another outlet for the expertise — code, servers, infrastructure, and bandwidth — you’ve already amassed.

Axis Powers

Apache AXIS (http://xml.apache.org/axis) is a substantial and comprehensive open source Java (and eventually C++) toolkit for building and deploying Web service clients and servers. Based on standards (HTTP, the Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL), and XML), AXIS includes APIs, tools, and lots of sample code that you’ll find invaluable whether you’re deploying your first simple Web service, a full-blown commercial service, or a Java applet that interacts with another vendor’s Web service.

For example, if you’re developing a Web service client, you’ll need to know how to communicate with a remote Web service. Specifically, you’ll need to know the service’s URL, its service and method names, and the types and number of parameters for each method. In the realm of Web services, all of that information is captured in a service’s WSDL file. AXIS offers a tool, called WSDL2java, that interprets WSDL files and emits Java code that encapsulates all Web service intercommunication. (Where you previously wrote tens of lines of code to send SOAP messages manually with Apache SOAP, AXIS can reduce the effort to invoke a remote procedure to just two or three calls to create and initialize two objects.)

On the other hand, if you’re developing the server code for a new Web service, AXIS can help there, too. As mentioned above, all Web services describe themselves with WSDL files. Rather than write WSDL files from scratch (which have to accurately reflect the public methods of your Java classes), AXIS’s java2WSDL tool can generate WSDL files directly from Java source code. Or, given a WSDL file from another Web service, WSDL2java can generate server stub code, too. (In fact, from a single Java source file, you can create a client and a server and all of the files you need to deploy a Web service in less than an hour. We’ll do that very thing here in just a little while.) If you’re having problems debugging your service, AXIS’s handy tcpmon tool can be used to monitor and display all incoming and outgoing traffic.

Finally, AXIS makes deploying and managing Web services a snap. The fastest way to create an AXIS Web service is to simply drop a Java source file into the AXIS Web applications directory. The other technique, Web Services Deployment Descriptors (WSDD), are about as easy to use, but give you more control and more flexibility. For example, WSDD files can enable or disable individual methods in your Web service.

AXIS also offers a number of system administration tools that make management of Web services more tractable. Services can be deployed and un-deployed using AXIS’s AdminClient tool, and to help others consume your Web services, AXIS automatically generates WSDL files from any service deployed on your site.

Of course, a Web services toolkit would be worthless if it didn’t interoperate well with other Web services. AXIS is tested rigorously with other Web services implementations and works well with almost all of them, including Microsoft’s .NET (in fact, the AXIS developers maintain an impressive interoperability “scorecard” at http://www.apache.org/~rubys/ApacheClientInterop.html).

Let’s take a hands-on look at AXIS, and focus on the many features and tools that facilitate the deployment of new Web services. As we go to press, AXIS Beta 2 is the most recent release. All significant features have been implemented and the AXIS team is planning a beta release each month, targeting an official release by the end of this summer. To begin, let’s get Tomcat and AXIS installed on our Linux Web server.

Take a Spin on Axis

All of the examples in this article were developed on Red Hat Linux 7.1 (running on a Toshiba Satellite laptop). The Java code is based on AXIS Beta 2 and Java JDK 1.4. The code was developed and debugged in the Sun ONE Studio 4 Community Edition integrated development environment. Apache’s Jakarta Tomcat 4.0.3 was used as the Web server and servlet engine.

If you want to follow along and try the examples on your own machine, use the instructions in the next few sections to install and configure AXIS.

INSTALL TOMCAT

If you don’t have Tomcat installed, go to the Apache Web site (http://www.apache.org/tomcat) and download the latest production version of the server (as we went to press the latest production version of Tomcat was 4.0.3). At a minimum, you will need to download these Java packages: jakarta-regexp-1.2, servlet-2.3, xerces-j 1.4.4, Tomcat 4.0.3 itself, and the Tomcat 4.0.3 default Web applications.

Once you’ve downloaded the files, use rpm to install them (assuming you’re using Red Hat). After running the installs, you should have several new directories and files. On Red Hat, the Tomcat server is installed by default into /var/tomcat4. The init.d script is installed to /etc/init.d/tomcat4. The startup configuration script can be found in /etc/tomcat4/conf/tomcat4 .conf. For the rest of this article, we’ll refer to /var/tomcat4 as TOMCAT_HOME.

CONFIGURE THE TOMCAT SCRIPT

Before you launch Tomcat, you must edit the Tomcat start-up script to point to your installation of the JDK. Go to the directory /etc/tomcat4/conf and edit the file tomcat4.conf. Change the JAVA_HOME variable to point to your copy of JDK 1.4. On the laptop, the line was JAVA_HOME=/usr/java/j2sdk1 .4.0. The other script variables, CATALINA_HOME, JASPER_HOME, and CATALINA_TMPDIR should already be set correctly.

Finally, if you are using JDK 1.4, you must add the following line to the end of your startup script or AXIS will not work (if you are using JDK 1.3, you can safely skip this step).


JAVA_ENDORSED_DIRS=”$CATALINA_HOME”/bin:
“$CATALINA_HOME”/common/lib:
“$CATALINA_HOME”/webapps/axis/WEB-INF/lib

START AND TEST TOMCAT

After editing tomcat4.conf, the only task left is to start Tomcat. As root, use the init.d script to launch the server:


# /etc/init.d/tomcat4 start
Starting tomcat4: [ OK ]

To test that Tomcat is running, point your Web browser to http://localhost:8180/. (The port on your system may be 8080, depending on what other servers you have installed. If you’re not sure what port to use, open the file TOMCAT_HOME/ conf/server.xml, and look for the port number associated with the non-SSL standalone server.) You should see the default Tomcat web page.

INSTALL AXIS

The AXIS toolkit is distributed as a collection of jar files. To install AXIS on your server, go to http://xml.apache.org/axis/index.html and download the latest release. The release will be in a tar file named something like xml-axis.tar.gz. Unzip and untar the file into a temporary directory. We’ll refer to this temporary directory as AXIS_HOME (it’s probably useful to set a shell variable to record AXIS_HOME).

Copy the entire AXIS_HOME/webapps/axis directory to the directory TOMCAT_HOME/webapps. Next, copy the Xerces XML parser (the jar is located at TOMCAT_HOME/common/lib/xerces.jar to TOMCAT_HOME/webapps/axis/WEB-INF/lib. The following commands show what to copy:


# cp -pr $AXIS_HOME/webapps/axis \ $TOMCAT_HOME/webapps
# cp $TOMCAT_HOME/common/lib/xerces.jar \ $TOMCAT_HOME/webapps/axis/WEB-INF/lib








axis_02
Figure One: The AXIS test page

At this point, AXIS is installed and ready to use on the server. To test AXIS, point your browser to http://localhost:8180/axis/. You should see a page like the one shown in Figure One.

SET UP YOUR DEVELOPMENT ENVIRONMENT

To develop clients with AXIS, you will need to add several of the AXIS jar files to your Java CLASSPATH. If you’ve defined the AXIS_HOME environment variable in your shell, then a command like the following will add everything you need.


% export CLASSPATH=\
$AXIS_HOME/src/axis/lib/axis.jar:\
$AXIS_HOME/src/axis/lib/jaxrpc.jar:\
$AXIS_HOME/src/axis/lib/commons-logging.jar:\
$AXIS_HOME/src/axis/lib/tt-bytecode.jar:\
$AXIS_HOME/src/axis/lib/wsdl4j.jar:\
$TOMCAT_HOME/common/lib/xerces.jar:\
$AXIS_HOME/src/axis:\
$CLASSPATH

At this point AXIS should be working on the server, and your shell should be able to build the Java examples. Now, let’s build a Web service and a client and try them out.

Instant Web Service — Just Add Java

One of the nicest parts of AXIS is its “instant Web service” feature called Java Web Service (JWS) — just take a Java file, rename it, and drop it into TOMCAT_HOME/webapps/axis to make all of the (public) methods in the class callable through Web services.

The magic of JWS is defined in the TOMCAT_HOME/webapps/ axis/WEB-INF/web.xml file using the following configuration:


<servlet-mapping>
<servlet-name>AxisServlet</servlet-name>
<url-pattern>*.jws</url-pattern>
</servlet-mapping>

Whenever Tomcat — or any other J2EE-compliant server — is prompted for a .jws file in the AXIS context, the Axis-Servlet is invoked.

For our example, we’re going to deploy a famous quotes service. Initially, the service will offer two methods (but we’ll add complexity as we go along):


  • String quote(String name). Given a person’s String name, this method returns a famous quote attributed to that person (if any). The return value is String.

  • int count() returns the number of quotes stored in the service. The return value is an int.

This is a very simple service, but you can easily replace it with a more substantial class that uses JDBC or another technique for persistence. Listing One shows Quote.java, a class that implements the quote() and count() methods.




Listing One: The Quote class


import java.util.HashMap;
import java.util.Map;

public class Quote {
private HashMap quotes = null;
public Quote() {
quotes = new HashMap();
quotes.put(“Groucho Marx”, “Time flies like an arrow.
Fruit flies like a banana.”);
quotes.put(“Mae West”, “When women go wrong, men go
right after them.”);
quotes.put(“Mark Twain”, “Go to Heaven for the climate,
Hell for the company.”);
}
public String quote(String name) {
String quote;
if (name == null || name.length() == 0
|| (quote = (String) quotes.get(name)) == null) {
quote = “No quotes.”;
}
return (quote);
}
public int count() {
return quotes.size();
}
}

To deploy Quote as a Web service, simply copy the Quote.java file to TOMCAT_HOME/webapps/axis/Quote.jws. As mentioned above, the .jws extension is special: if AXIS finds a .jws files, it will automatically compile the file and make the public methods in the class available as a Web service.

Note that Listing One is in the default package. Do not place your classes in a specific package if you want to deploy them via JWS.

The server-side coding is nice and simple. The hefty coding is done in the client. Listing Two shows QuoteClient.java.




Listing Two: The famous quotes client


1 package linuxmag.aug02.example1;
2
3 import org.apache.axis.client.Call;
4 import org.apache.axis.client.Service;
5 import org.apache.axis.encoding.XMLType;
6 import org.apache.axis.utils.Options;
7
8 import javax.xml.rpc.ParameterMode;
9
10 public class QuoteClient
11 {
12 public static void main(String [] args) throws Exception {
13 String host = “http://localhost:“;
14 String servicepath = “/axis/Quote.jws”;
15 Options options = new Options(args);
16 int port = options.getPort();
17 String endpoint = host + port + servicepath;
18 String method = null;
19
20 args = options.getRemainingArgs();
21
22 if (args == null || (!((method = args[0])).equals(“quote”)
23 && !method.equals(“count”))) {
24 System.err.println(“Usage:”);
25 System.err.println(” QuoteClient count”);
26 System.err.println(” QuoteClient quote name”);
27 return;
28 }
29
30 String op1 = null;
31
32 if (method.equals(“quote”)) {
33 op1 = args[1];
34 }
35
36 String ret = null;
37 Service service = new Service();
38 Call call = (Call) service.createCall();
39
40 call.setTargetEndpointAddress(new java.net.URL (endpoint));
41 call.setOperationName(method);
42
43 if (op1 != null) {
44 call.addParameter(“op1″, XMLType.XSD_STRING, ParameterMode.IN);
45 call.setReturnType(XMLType.XSD_STRING);
46 ret = (String) call.invoke(new Object [] {op1});
47 } else {
48 call.setReturnType(XMLType.XSD_INT);
49 ret = ((Integer) call.invoke((Object[])null)).toString();
50 }
51
52 System.out.println(“Got result : ” + ret);
53 }
54 }

To run the client, put QuoteClient.java in AXIS_HOME/src/ axis/linuxmag/aug02/example1 and do the following:


% cd $AXIS_HOME/src/axis/linuxmag/aug02/example1
% javac QuoteClient.java
% java linuxmag.aug02.example1.QuoteClient \
-p8180 quote “Groucho Marx”
Got result : Time flies like an arrow.
Fruit flies like a banana.

Let’s look at the client in some detail. Lines 3-8 bring in the additional classes required for an AXIS client. Line 13 names the host; here we’re using localhost and we’ve appended a colon so we can specify the exact port to connect to. Line 14 specifies the path to Web service. Because Quote.jws does not name a package, the path simply points to the /axis/ directory. Line 15 uses an AXIS convenience class named Options to find, store, and remove common AXIS arguments on the command line. For example, you can specify the port number you want to connect to with the -p flag.

Lines 22-28 are typical argument checking code.

Lines 37 and 38 create two critical classes. Service is the starting point to access any SOAP Web service. Call is used to invoke the service. Lines 40-41 set the endpoint — the destination for our SOAP message — and name the method we want to invoke. Lines 44-46 and lines 48-49 set the parameters for the remote call, and specify the type of the return value. The method quote returns a String, specified with XMLType.XSD_STRING. The method count returns an Integer, denoted with XMLType.XSD_INT. The return value of call.invoke() is Object, which we case to the corresponding return type of each method.








axis_03
Figure Two: SOAP request and response

Figure Two shows the SOAP request and response (with the HTTP headers) for calling the quote method. (Some of the SOAP-ENV:Envelope elements have been omitted to save space; everything else appears intact.) Notice that endpoint appears as part of the HTTP POST; quote, the remote method name, is the only element of the SOAP-ENV:Body; and, the arguments to the remote method are the sub-elements of quote.

Finally, notice that the xsi:type attribute of the quote- Return element is xsd:string. AXIS uses the xsi:type attribute to deserialize the return value captured in the XML response into the correct Java class. In this case, the return value was deserialized into a String. (The opposite process of converting Java to XML, as is perfomed to generate the request, is called serialization).

The xsi:type is generated by the Web service and not by call.setReturnType(XMLType.XSD_STRING). So, why is the setReturnType() call even needed? Some Web services do not label return values with types. In those cases, the call to setReturnType() is a hint to AXIS, telling it to convert whatever the return value is to a Java String. In our example, the setReturnType() is indeed redundant, but we can’t always predict what a Web service will return.

If you want to see the outgoing requests and the incoming responses to your Web service, AXIS offers a special tool (actually a Java class) called tcpmon that acts as a proxy between two ports. See the sidebar “Debugging with tcpmon” on pg. 37 for more information on this valuable tool.

So, that’s the near-instant way to deploy a Web service and a general technique to write a client. While the JWS technique offers convenience, there are some detractors:

  • The client is too tightly bound to the specifics of the Web service. Indeed, the client does many things manually, tied closely to the specifics of SOAP. (We’ll discuss how to address this in the next section.)
  • The instant Web service deployment technique requires Java source files. While adequate for very simple services, that’s just too limiting. If you don’t have the source code to a useful class, you’re out of luck.
  • The JWS technique does not provide for custom type mappings. You can use the standard types — Integer, Double, others — but you can’t serialize and return custom classes.
  • JWS does not support any kind of authentication or access control.
  • The other option to deploy an AXIS Web service, and the one developers will most likely use, is AXIS’s Web Service Deployment Descriptor, or WSDD.

Exert Control with WSDD

WSDD files let you leverage all of the advanced features of AXIS. AXIS is quite extensible, and as you add components to your Web service, you’ll use a WSDD file to pull it together.

For example, we’ve seen the HTTP transport, but you could add an SMTP or FTP transport to process requests originating through those protocols. Or, you can add a logging mechanism to your service by adding an AXIS handler. Configured correctly, the logging handler would be called before your code every time your Web service receives a request.

Deploying a Web service via a WSDD file is a little more time consuming than JWS, but still pretty simple. Here’s how to deploy the quote service with WSDD:

1. Unlike JWS, you should provide a package name for your classes when deploying with WSDD. In this case, add the line packagelinuxmag.aug02.quoteservice; to the top of Quote.java.


2. Run javac to compile Quote.java, yielding Quote.class.


3. Create a new directory linuxmag/ aug02/quoteservice in TOMCAT_HOME/ webapps/axis/WEB-INF/classes and copy the file Quote.class to it.


4. Deploy the Web service by submitting the WSDD file shown in Listing Three to AXIS. A special utility called AdminClient does the work. The command below shows what to do.




Listing Three: The WSDD file for the famous quotes service


1 <deployment
2 xmlns=”http://xml.apache.org/axis/wsdd/
3 xmlns:java=”http://xml.apache.org/axis/wsdd/providers/java“>
4
5 <service name=”Quote” provider=”java:RPC”>
6 <parameter name=”className” value=”linuxmag.aug02.quoteservice.Quote”/>
7 <parameter name=”allowedMethods” value=”*”/>
8 </service>
9 </deployment>


% java org.apache.axis.client.AdminClient \
-p8180 deploy.wsdd
[INFO] AdminClient-Processing file deploy.wsdd
<Admin>Done processing</Admin>

5. If you want to see if the service has been “registered” properly with AXIS, use the list option of AdminClient. You should see something similar to Figure Three (the output has been greatly abbreviated to save space). The list option also shows any JWS services you may have deployed.




Figure Three: Listing available Web services


% java org.apache.axis.client.AdminClient -p8180 list

<handler name=”URLMapper” type=”java:org.apache.axis.handlers.http.URLMapper”/>
<service name=”Quote” provider=”java:RPC”>
<parameter name=”allowedMethods” value=”*”/>
<parameter name=”className” value=”linuxmag.aug02.quoteservice.Quote”/>
</service>

Of course, you can also run a client to test the Web service. Let’s do that. Copy the code from Listing Two and make the following changes to adapt the code to access the new service:


  • Import an additional package named javax.xml.rpc. namespace.QName.

  • Change the name of the Java file, the Java class (and don’t forget the constructor) to QuoteClientWSDD.

  • Edit line 14 and change it to String servicepath = “/axis/servlet/AxisServlet”;

  • Comment out or delete line 41.

  • Add the following line after the code that begins call.add Parameter(“op1″, XMLType.XSD_STRING…


call.setOperationName(new QName
(“Quote”, “quote”));


  • Immediately after else, in the else block, add the line:


call.setOperationName(new QName
(“Quote”, “count”));

Compile and run the edited class shown in Figure Four .




Figure Four: Building and running the modified client


% javac QuoteClientWSDD.java
% java linuxmag.aug02.example1.QuoteClientWSDD -p8180 quote “Mae West”
Got result : When women go wrong, men go right after them.
% java linuxmag.aug02.example1.QuoteClientWSDD -p8180 count
Got result : 3

Again, that’s it. We’ve deployed a Web service and a complementary client in just a few minutes. In general, you will follow a similar procedure to deploy all your Web services via WSDD. (You might use JWS for debugging or quick projects to test interoperability.)

By the way, if you ever want to undeploy a service, create and submit another WSDD file that looks like the following:


<undeployment xmlns=”http://xml.apache.org/
axis/wsdd/”>
<service name=”Quote”/>
</undeployment>

WSDL: Web Services All The Time

So far, we’ve seen tools and code that make deployment of Web services easy, but we haven’t seen a way to make client coding any easier. What we need is something to separate the client from the particulars of the server. What we need is WSDL.

WSDL, or Web Services Description Language, is an XML-based syntax that describes a Web service in an abstract but regular form. Given a WSDL file, a client can dynamically call a Web service. Better yet, with a WSDL file and a few clever AXIS tools, you can even create Java stub code for your client and your server.

For example, if you still have the original Quote.jws file deployed in AXIS, point your Internet browser to http://localhost:8180/axis/Quote.jws?WSDL. What you see in the browser is a WSDL description of your Web service, generated automatically by AXIS.

For our last example, let’s extend the famous quotes server, deploy it, and use AXIS tools to build a WSDL file and a client.

1. Make a directory AXIS_HOME/src/axis/linuxmag/aug02/quote. Copy the original Quote.java file (shown in Listing One) into that directory.

2. Edit Quote.java. At the top of the file add package linuxmag.aug02.quote; and add the two new methods shown in Figure Five to the Quote class.




Figure Five: Two new methods for the Web service


public String[] contents() {
String[] s = new String[quotes.size()];

Set keys = quotes.keySet();
int j = 0;
for (Iterator i = keys.iterator(); i.hasNext(); ) {
String name = (String) i.next();
s[j++] = (String) quotes.get(name);
}
return s;
}

public long time() {
return System.currentTimeMillis();
}

3. Java2WSDL is a special AXIS client that interprets a Java class and creates a WSDL file that describes all of the methods in the class. Once we have the WSDL file for our Quote class, we can use another AXIS utility, WSDL2Java to create client and server code stubs. To create a WSDL file from our class, run this command:


% java org.apache.axis.wsdl.Java2WSDL \
-o quote.wsdl \
-l”http://localhost:8180/axis/services/Quote” \
-n “urn:Quote” \
-p”linuxmag.aug02.quote” “urn:Quote” \
linuxmag.aug02.quote.Quote

The output of the command (the -o switch) is quote.wsdl. The -l option specifies the URL (the endpoint) of the Web service. -n is the target namespace of the WSDL file. -p indicates a mapping from the package to a namespace. The last argument is the Java class (or a Java interface) that defines the methods of the Web service.

4. Before we generate any code, move the original Quote.java file to Quote.java.orig. If you don’t, it will get clobbered in the next step.

5. The AXIS utility WSDL2Java can generate stub code for the server and client. For the server, the utility generates all the code you need to deploy a service — all you’ll need to do is fill in the actual service code itself. For the client, the code to invoke the service remotely is reduced to three lines. WSDL2Java also generates a simple WSDD file to deploy your Web service.

Run the following command java command to generate the server and client stubs in the current directory.


% java org.apache.axis.wsdl.WSDL2Java \
-o . -d Session -s -S true-Nurn:Quote \
linuxmag.aug02.quote quote.wsdl

Run ls in the current directory to see a list of files. QuoteService .java, QuoteSoapBindingSkeleton.java, QuoteSoapBinding-Impl.java, and Quote.wsdd are used on the server. QuoteServiceLocator.java and Quote-SoapBindingStub.java are used on the client. Quote.java is a Java interface and is used on the client and server.

6. Open the file QuoteSoapBinding-Impl.java and replace its methods with those from Quote.java.bak. Make sure to import all of the packages you need and define all of the fields. QuoteSoapBindingImpl.java is where your code and the Web service code meet.

7. As root, create a new directory TOMCAT_HOME/webapps/axis/WEB-INF/classes/linuxmag/aug02/quote, and run commands to compile, copy, and deploy your service, as shown in Figure Six.




Figure Six: Deploying the new Web service


% javac *.java
% su
Password:
# cp Quote.class QuoteSoapBindingImpl.class QuoteSoapBindingSkeleton.class \
$TOMCAT_HOME/webapps/axis/WEB-INF/classes/linuxmag/aug02/quote
% java org.apache.axis.client.AdminClient -p 8180 deploy.wsdd
[INFO] AdminClient – -Processing file deploy.wsdd
<Admin>Done processing</Admin>

8. Copy the code in Figure Seven to create the file named Test.java.




Figure Seven: A Web service client built from stub code


package linuxmag.aug02.quote;

import java.util.Date;

public class Test {
public static void main(String[] args) throws Exception {
QuoteServiceLocator l = new QuoteServiceLocator();
QuoteSoapBindingStub stub = (QuoteSoapBindingStub) l.getQuote();

System.out.println(“Time on server: ” + (new Date(stub.time())).toString());
System.out.println(stub.quote(“Groucho Marx”) + ” — Groucho Marx”);
System.out.println(“Number of quotes: ” + stub.count());

String[] quotes = stub.contents();
for (int i = 0; i < quotes.length; i++) {
System.out.println(quotes[i]);
}
}
}

Notice that only two calls — the first two lines of the main method — are needed to setup before we call the service.

9. Compile and run the client.


% javac Test.java
% java linuxmag.aug02.quote.Test
Time on server: Tue Jun 18 01:59:20 PDT 2002
Time flies like an arrow. Fruit flies like
a banana. — Groucho Marx
Number of quotes: 3
When women go wrong, men go right after them.
Time flies like an arrow. Fruit flies like a
banana.
Go to Heaven for the climate, Hell for the
company.

And, that’s all folks. WSDL2Java reduced a complex programming task to some very simple code. You can follow the same procedure to talk to any Web service. All you need is the Web service’s WSDL file.

Now, Get Off Your Axis…

AXIS has more tricks and features to discover. Although we’ve seen an expansive set of tools and techniques, we’ve only scratched the surface. To see more samples and get more information on other AXIS concepts, read the AXIS User’s Guide. There is also an in-depth architecture guide if you’re curious about the guts of AXIS.

A good toolkit is a software developer’s best friend. Armed with a set of classes, build tools, off-the-shelf infrastructure, and a few helpful examples, a programmer is ready to type away at any gauntlet management throws down. Add AXIS to your arsenal.




Debugging with tcpmon








axis_04
tcpmon message monitor

To help you debug your Web service and Web client, AXIS includes a helpful utility class named org.apache.axis.utils.tcpmon (or Icpmon). tcpmon listens for connections on a given port on the localhost, and forwards incoming messages to another port on another server. By inserting itself between the two ports, tcpmon can show you all incoming and outgoing messages. A picture of tcpmon is shown here.

Assuming you have your CLASSPATH and DISPLAY variables set correctly, the following commands will launch a tcpmon X window.


% alias tcpmon=”java org.apache.axis.utils.tcpmon”
% tcpmon &

Once the window appears, enter a port number that’s not in use in the Listen Port # field. Choose Act as a Listener… and enter the hostname and port number of your Tomcat server in the Target hostname and Target port # fields, respectively. In the figure, the incoming port was 8181 and the hostname and port for Tomcat was localhost and 8180, respectively. Again, your port numbers may be different. Next, click the Add button and then click on the tab for your port number.

Incoming SOAP requests are shown in the topmost window, and responses are shown in the bottom window.



Martin Streicher is the Executive Editor of Linux Magazine. He can be reached at mstreicher@linux-mag.com.

Fatal error: Call to undefined function aa_author_bios() in /opt/apache/dms/b2b/linux-mag.com/site/www/htdocs/wp-content/themes/linuxmag/single.php on line 62