axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sc...@apache.org
Subject cvs commit: xml-axis/java/docs user-guide.html
Date Wed, 19 Dec 2001 15:30:08 GMT
scheu       01/12/19 07:30:08

  Modified:    java/docs user-guide.html
  Log:
  Added Java2WSDL section, change tool names to WSDL2Java/Java2WSDL, Added links to the tool sections
  
  Revision  Changes    Path
  1.31      +972 -596  xml-axis/java/docs/user-guide.html
  
  Index: user-guide.html
  ===================================================================
  RCS file: /home/cvs/xml-axis/java/docs/user-guide.html,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- user-guide.html	2001/12/19 14:30:59	1.30
  +++ user-guide.html	2001/12/19 15:30:08	1.31
  @@ -1,8 +1,10 @@
  -<!-- saved from url=(0022)http://internet.e-mail -->
  +<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
   <html>
   <head>
  -<title>Axis User's Guide</title>
  -<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  +   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  +   <meta name="GENERATOR" content="Mozilla/4.72 [en] (Windows NT 5.0; U) [Netscape]">
  +   <title>Axis User's Guide</title>
  +<!-- saved from url=(0022)http://internet.e-mail -->
   <style type="text/css">
   <!--
   .example { background:#ccccff }
  @@ -14,421 +16,515 @@
   -->
   </style>
   </head>
  +<body text="#000000" bgcolor="#FFFFFF">
  +
  +<center>
  +<h1>
  +<img SRC="axis.jpg" height=96 width=176></h1></center>
  +
  +<h1>
  +Axis User's Guide</h1>
  +<i>Alpha 3 Version</i>
  +<h3>
  +Table of Contents</h3>
  +
  +<ul>
  +<li>
  +<a href="#Introduction">Introduction</a></li>
  +
  +<li>
  +<a href="#Installation">Installing Axis</a></li>
   
  -<body bgcolor="#ffffff" text="#000000">
  -<h1 align="center"><IMG height=96 src="axis.jpg" width=176></h1>
  -<h1>Axis User's Guide</h1>
  -<p><i>Alpha 3 Version</i></p>
  -<h3>Table of Contents</h3>
  -<p><A href="#Introduction">Introduction</a><br>
  -  <A href="#Installation">Installing Axis</a><br>
  -  <A href="#ConsumingServices">Consuming Web Services with Axis</a><br>
  -  <A href="#PublishingServices">Publishing Web Services with Axis</a><br>
  -  <A href="#DataMapping">XML &lt;-&gt; Java Data Mapping in Axis<br>
  -  </a> <A href="#WSDL">Using WSDL with Axis</a><br>
  -  <br>
  -  <A href="#Glossary">Glossary</a></p>
  -<h2><a name="Introduction"></a>Introduction</h2>
  -<p>Welcome to Axis, the third generation of Apache SOAP! This is the <b>alpha 
  -  3 </b> version. Please note that Axis is a work in progress, and although the 
  -  basic functionality is there, there are still a lot of unfinished areas and 
  -  rough edges. That said, we're very psyched about the package so far and would 
  -  love to get your take on how we can make it better. </p>
  -<h3>What is SOAP?</h3>
  -<p>SOAP is an XML<i>-</i>based communitcation protocol and encoding format for 
  -  inter-application communication. Originally conceived by Microsoft and Userland 
  -  software, it has evolved through several generations and the current spec, <a href="http://w3.org/TR/soap">SOAP 
  -  1.1</a>, is fast growing in popularity and usage. The W3C's XML Protocol working 
  -  group is in the process of turning SOAP into a true open standard, and as of 
  -  this writing has released a working draft of SOAP 1.2, which cleans up some 
  -  of the more confusing areas of the 1.1 spec.</p>
  -<p>SOAP is widely viewed as the backbone to a new generation of cross-platform 
  -  cross-language distributed computing applications, termed Web Services.</p>
  -<h3>What is Axis?</h3>
  -<p>Apache SOAP began at IBM as "SOAP4J" and then became Apache SOAP version 2. 
  -  The committers on the v2 project began some conversations in late 2000 about 
  -  making the engine much more flexible, configurable, and able to handle both 
  -  SOAP and the upcoming XML Protocol specification from the W3C. </p>
  -<p>After a little while, it became clear that a ground-up rearchitecture was the 
  -  way to go. Several of the v2 committers proposed very similar designs, all based 
  -  around configurable "chains" of message "handlers" which would implement small 
  -  bits of functionality in a very flexible and composable manner. Axis is the 
  -  result of months of continued discussion and coding effort in this direction. 
  -  Some of the key Axis features include the following:</p>
  +<li>
  +<a href="#ConsumingServices">Consuming Web Services with Axis</a></li>
  +
  +<li>
  +<a href="#PublishingServices">Publishing Web Services with Axis</a></li>
  +
  +<li>
  +<a href="#DataMapping">XML &lt;-> Java Data Mapping in Axis</a></li>
  +
  +<li>
  +<a href="#WSDL">Using WSDL with Axis</a></li>
  +
   <ul>
  -  <li> <b>Speed.</b> Axis uses SAX (event-based) parsing to acheive significantly 
  -    greater speed than earlier versions of Apache SOAP. 
  -  <li><b>Flexibility.</b> The Axis architecture gives the developer complete freedom 
  -    to insert extensions into the engine for custom header processing, system 
  -    management, or anything else you can imagine. 
  -  <li><b>Component-oriented deployment.</b> You can easily define reusable networks 
  -    of Handlers to implement common patterns of processing for your applications, 
  -    or to distribute to partners. 
  -  <li><b>Transport framework.</b> We have a clean and simple abstraction for designing 
  -    transports (i.e. senders and listeners for SOAP over various protocols such 
  -    as SMTP, FTP, message-oriented middleware, etc), and the core of the engine 
  -    is completely transport-independent. 
  +<li>
  +&nbsp;<a href="#WSDL: Obtaining WSDL for deployed services">?WSDL: Obtaining
  +WSDL for deployed services</a></li>
  +
  +<li>
  +&nbsp;<a href="#WSDL2Java: Building stubs, skeletons, and data">WSDL2Java:
  +Building stubs, skeletons, and data</a></li>
  +
  +<li>
  +&nbsp;<a href="#Java2WSDL: Building WSDL from Java">Java2WSDL: Building
  +WSDL from Java</a></li>
   </ul>
  -<p>We hope you enjoy using Axis. Please note that this is an open-source effort 
  -  - if you feel the code could use some new features or fixes, please get involved 
  -  and lend a hand! The Axis developer community welcomes your participation.</p>
  -<h4><b>Let us know what you think!</b></h4>
  -<p>Please send feedback about the package to "<A href="mailto:axis-user@xml.apache.org">axis-user@xml.apache.org</a>". 
  -  Also, Axis is regsitered in <a href="http://nagoya.apache.org/bugzilla">bugzilla</a>, 
  -  the Apache bug tracking and feature-request database.</p>
  -<h3>What's in this release?</h3>
  -<p>This release includes the following features:</p>
  +
  +<li>
  +<a href="#tcpmon">Using TCPMon</a></li>
  +
  +<li>
  +<a href="#Glossary">Glossary</a></li>
  +</ul>
  +
  +<h2>
  +<a NAME="Introduction"></a>Introduction</h2>
  +Welcome to Axis, the third generation of Apache SOAP! This is the <b>alpha
  +3 </b>version. Please note that Axis is a work in progress, and although
  +the basic functionality is there, there are still a lot of unfinished areas
  +and rough edges. That said, we're very psyched about the package so far
  +and would love to get your take on how we can make it better.
  +<h3>
  +What is SOAP?</h3>
  +SOAP is an XML<i>-</i>based communitcation protocol and encoding format
  +for inter-application communication. Originally conceived by Microsoft
  +and Userland software, it has evolved through several generations and the
  +current spec, <a href="http://w3.org/TR/soap">SOAP 1.1</a>, is fast growing
  +in popularity and usage. The W3C's XML Protocol working group is in the
  +process of turning SOAP into a true open standard, and as of this writing
  +has released a working draft of SOAP 1.2, which cleans up some of the more
  +confusing areas of the 1.1 spec.
  +<p>SOAP is widely viewed as the backbone to a new generation of cross-platform
  +cross-language distributed computing applications, termed Web Services.
  +<h3>
  +What is Axis?</h3>
  +Apache SOAP began at IBM as "SOAP4J" and then became Apache SOAP version
  +2. The committers on the v2 project began some conversations in late 2000
  +about making the engine much more flexible, configurable, and able to handle
  +both SOAP and the upcoming XML Protocol specification from the W3C.
  +<p>After a little while, it became clear that a ground-up rearchitecture
  +was the way to go. Several of the v2 committers proposed very similar designs,
  +all based around configurable "chains" of message "handlers" which would
  +implement small bits of functionality in a very flexible and composable
  +manner. Axis is the result of months of continued discussion and coding
  +effort in this direction. Some of the key Axis features include the following:
   <ul>
  -  <li>SOAP 1.1 compliant engine 
  -  <li>Flexible configuration / deployment system 
  -  <li>Support for "drop-in" deployment of SOAP services (JWS) 
  -  <li>Support for all basic types, and a type mapping system for defining new 
  -    serializers/deserializers 
  -  <li>Automatic serialization/deserialization of Java Beans 
  -  <li>Automatic two-way conversions between Java "List" collections and SOAP Arrays 
  -  <li>Providers for RPC and message based SOAP services 
  -  <li>Automatic WSDL generation from deployed services
  -  <li>Wsdl2java tool for building Java proxies and skeletons from WSDL documents
  -  <li>Preliminary security extensions, which can integrate with Servlet 2.2 security/roles
  -  <li>An EJB provider for accessing EJB's as Web Services
  -  <li>HTTP servlet-based transport 
  -  <li>Standalone version of the server (with HTTP support) 
  -  <li>Examples, including a client and server for the soapbuilders community interoperability 
  -    tests</li>
  +<li>
  +<b>Speed.</b> Axis uses SAX (event-based) parsing to acheive significantly
  +greater speed than earlier versions of Apache SOAP.</li>
  +
  +<li>
  +<b>Flexibility.</b> The Axis architecture gives the developer complete
  +freedom to insert extensions into the engine for custom header processing,
  +system management, or anything else you can imagine.</li>
  +
  +<li>
  +<b>Component-oriented deployment.</b> You can easily define reusable networks
  +of Handlers to implement common patterns of processing for your applications,
  +or to distribute to partners.</li>
  +
  +<li>
  +<b>Transport framework.</b> We have a clean and simple abstraction for
  +designing transports (i.e. senders and listeners for SOAP over various
  +protocols such as SMTP, FTP, message-oriented middleware, etc), and the
  +core of the engine is completely transport-independent.</li>
   </ul>
  -<h3>What's missing?</h3>
  +We hope you enjoy using Axis. Please note that this is an open-source effort
  +- if you feel the code could use some new features or fixes, please get
  +involved and lend a hand! The Axis developer community welcomes your participation.
  +<h4>
  +<b>Let us know what you think!</b></h4>
  +Please send feedback about the package to "<a href="mailto:axis-user@xml.apache.org">axis-user@xml.apache.org</a>".
  +Also, Axis is regsitered in <a href="http://nagoya.apache.org/bugzilla">bugzilla</a>,
  +the Apache bug tracking and feature-request database.
  +<h3>
  +What's in this release?</h3>
  +This release includes the following features:
   <ul>
  -  <li>Support for the SOAP with Attachments specification 
  -  <li>Supprt for multi-dimensional arrays 
  -  <li>Support for the SOAP actor attribute 
  -  <li>Support for generating complex type definitions in WSDL 
  +<li>
  +SOAP 1.1 compliant engine</li>
  +
  +<li>
  +Flexible configuration / deployment system</li>
  +
  +<li>
  +Support for "drop-in" deployment of SOAP services (JWS)</li>
  +
  +<li>
  +Support for all basic types, and a type mapping system for defining new
  +serializers/deserializers</li>
  +
  +<li>
  +Automatic serialization/deserialization of Java Beans</li>
  +
  +<li>
  +Automatic two-way conversions between Java "List" collections and SOAP
  +Arrays</li>
  +
  +<li>
  +Providers for RPC and message based SOAP services</li>
  +
  +<li>
  +Automatic WSDL generation from deployed services</li>
  +
  +<li>
  +WSDL2Java tool for building Java proxies and skeletons from WSDL documents</li>
  +
  +<li>
  +Java2WSDL tool for building WSDL from Java classes.</li>
  +
  +<li>
  +Preliminary security extensions, which can integrate with Servlet 2.2 security/roles</li>
  +
  +<li>
  +An EJB provider for accessing EJB's as Web Services</li>
  +
  +<li>
  +HTTP servlet-based transport</li>
  +
  +<li>
  +Standalone version of the server (with HTTP support)</li>
  +
  +<li>
  +Examples, including a client and server for the soapbuilders community
  +interoperability tests</li>
  +</ul>
  +
  +<h3>
  +What's missing?</h3>
  +
  +<ul>
  +<li>
  +Support for the SOAP with Attachments specification</li>
  +
  +<li>
  +Supprt for multi-dimensional arrays</li>
  +
  +<li>
  +Support for the SOAP actor attribute</li>
  +
  +<li>
  +Support for generating complex type definitions in WSDL</li>
   </ul>
  -<p>All of these items are on the list for the final release.</p>
  -<h2><a name="Installation"></a>Installing Axis and Using this Guide</h2>
  -<p>See the <a href="install.html">Axis Installation Guide</a> for instructions 
  -  on installing Axis as a web application on your J2EE server. </p>
  -<p>Before running the examples in this guide, you'll need to make sure that axis.jar 
  -  is in your classpath. You should find it in the build/lib directory of the distribution.</p>
  -
  -<h2><a name="ConsumingServices"></a>Consuming Web Services with Axis</h2>
  -<h3>Basics - Getting Started</h3>
  -<p>Let's take a look at an example Web Service client that will call the <b>echoString</b> 
  -  method on the public Axis server at Apache.</p>
  +All of these items are on the list for the final release.
  +<h2>
  +<a NAME="Installation"></a>Installing Axis and Using this Guide</h2>
  +See the <a href="install.html">Axis Installation Guide</a> for instructions
  +on installing Axis as a web application on your J2EE server.
  +<p>Before running the examples in this guide, you'll need to make sure
  +that axis.jar is in your classpath. You should find it in the build/lib
  +directory of the distribution.
  +<h2>
  +<a NAME="ConsumingServices"></a>Consuming Web Services with Axis</h2>
  +
  +<h3>
  +Basics - Getting Started</h3>
  +Let's take a look at an example Web Service client that will call the <b>echoString</b>
  +method on the public Axis server at Apache.
   <div class="example">
  -<pre>
  -1   import org.apache.axis.client.Call;
  -2   import org.apache.axis.client.Service;
  -3   
  -4   public class TestClient
  -5   {
  -6      public static void main(String [] args) {
  -7          try {
  -8              String endpoint =
  -9                       "http://nagoya.apache.org:5049/axis/servlet/AxisServlet";
  -10  
  -11             Service  service = new Service();
  -12             Call     call    = (Call) service.createCall();
  -13  
  -14             call.setTargetEndpointAddress( new java.net.URL(endpoint) );
  -15             call.setOperationName( "echoString" );
  -16             call.setProperty( Call.NAMESPACE, "http://soapinterop.org/" );
  -17  
  -18             String ret = (String) call.invoke( new Object[] { "Hello!" } );
  -19  
  -20             System.out.println("Sent 'Hello!', got '" + ret + "'");
  -21         } catch (Exception e) {
  -22             System.err.println(e.toString());
  -23         }
  -24     }
  -25  }
  -</pre>
  +<pre>1&nbsp;&nbsp; import org.apache.axis.client.Call;
  +2&nbsp;&nbsp; import org.apache.axis.client.Service;
  +3&nbsp;&nbsp;&nbsp;
  +4&nbsp;&nbsp; public class TestClient
  +5&nbsp;&nbsp; {
  +6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; public static void main(String [] args) {
  +7&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; try {
  +8&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String endpoint =
  +9&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "http://nagoya.apache.org:5049/axis/servlet/AxisServlet";
  +10&nbsp;&nbsp;
  +11&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Service&nbsp; service = new Service();
  +12&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call&nbsp;&nbsp;&nbsp;&nbsp; call&nbsp;&nbsp;&nbsp; = (Call) service.createCall();
  +13&nbsp;&nbsp;
  +14&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; call.setTargetEndpointAddress( new java.net.URL(endpoint) );
  +15&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; call.setOperationName( "echoString" );
  +16&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; call.setProperty( Call.NAMESPACE, "http://soapinterop.org/" );
  +17&nbsp;&nbsp;
  +18&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; String ret = (String) call.invoke( new Object[] { "Hello!" } );
  +19&nbsp;&nbsp;
  +20&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; System.out.println("Sent 'Hello!', got '" + ret + "'");
  +21&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } catch (Exception e) {
  +22&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; System.err.println(e.toString());
  +23&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
  +24&nbsp;&nbsp;&nbsp;&nbsp; }
  +25&nbsp; }</pre>
   </div>
  -<p>(You'll find this file in <a href="../samples/userguide/example1/TestClient.java">samples/userguide/example1/TestClient.java</a>)</p>
  -<p>Assuming you have a network connection active, this program can be run as follows:</p>
  +(You'll find this file in <a href="../samples/userguide/example1/TestClient.java">samples/userguide/example1/TestClient.java</a>)
  +<p>Assuming you have a network connection active, this program can be run
  +as follows:
   <pre>% java samples.userguide.example1.TestClient
   Sent 'Hello!', got 'Hello!'
  -% </pre>
  -<p>
  -  So what's happening here? On lines 11 and 12 we create new Service and Call
  -  objects.  These are the standard JAX-RPC objects that are used to store
  -  metadata about the service to invoke.  On line 14, we set up our endpoint 
  -  URL - this is the destination for our SOAP message.  On line 15 we define
  -  the operation (method) name of the Web Service. Line 16 defines the 
  -  namespace to use on the Body of the SOAP message.  And on line 18 we 
  -  actually invoke the desired service, passing in an array of parameters - 
  -  in this case just one String.
  -  
  -<p>You can see what happens to the arguments by looking at the SOAP request that 
  -  goes out on the wire (look at the colored sections, and notice they match the 
  -  values in the call above):</p>
  -  <div class="xml">
  -  <pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
  +%</pre>
  +So what's happening here? On lines 11 and 12 we create new Service and
  +Call objects. These are the standard JAX-RPC objects that are used to store
  +metadata about the service to invoke. On line 14, we set up our endpoint
  +URL - this is the destination for our SOAP message. On line 15 we define
  +the operation (method) name of the Web Service. Line 16 defines the namespace
  +to use on the Body of the SOAP message. And on line 18 we actually invoke
  +the desired service, passing in an array of parameters - in this case just
  +one String.
  +<p>You can see what happens to the arguments by looking at the SOAP request
  +that goes out on the wire (look at the colored sections, and notice they
  +match the values in the call above):
  +<div class="xml">
  +<pre>&lt;?xml version="1.0" encoding="UTF-8"?>
   &lt;SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  -                   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  -                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
  -  &lt;SOAP-ENV:Body&gt;
  -    &lt;ns1:<font color="#993333"><b>echoString</b></font> xmlns:ns1="<font color="#009933"><b>http://soapinterop.org/</b></font>"&gt;
  -      &lt;arg0 xsi:type="xsd:string"&gt;<b><font color="#cc00cc">Hello!</font></b>&lt;/arg0&gt;
  -    &lt;/ns1:echoString&gt;
  -  &lt;/SOAP-ENV:Body&gt;
  -&lt;/SOAP-ENV:Envelope&gt;
  -</pre>
  -  <div align="center"> </div>
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  +&nbsp; &lt;SOAP-ENV:Body>
  +&nbsp;&nbsp;&nbsp; &lt;ns1:<b><font color="#993333">echoString</font></b> xmlns:ns1="<b><font color="#009933">http://soapinterop.org/</font></b>">
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;arg0 xsi:type="xsd:string"><b><font color="#CC00CC">Hello!</font></b>&lt;/arg0>
  +&nbsp;&nbsp;&nbsp; &lt;/ns1:echoString>
  +&nbsp; &lt;/SOAP-ENV:Body>
  +&lt;/SOAP-ENV:Envelope></pre>
   </div>
  -<p>The String argument is automatically serialized into XML, and the server responds 
  -  with an identical String, which we deserialize and print.</p>
  -<p><i>Note: to actually watch the XML flowing back and forth between a SOAP client 
  -  and server, you can use the included tcpmon tool. See the <a href="#tcpmon">appendix</a> 
  -  for an overview.</i></p>
  -<h3>Naming Parameters</h3>
  -<p>In the above example, the parameters are in the order in which we sent them, 
  -  but since we only passed the objects themselves, Axis automatically named the 
  -  XML-encoded arguments in the SOAP message "arg0", "arg1", etc. If you want to 
  -  change this, it's easy! Before calling <code>invoke()</code> you need to call 
  -  <code>addParameter</code> for each parameter, like so:
  -<div class="example"><pre>
  -  call.addParameter("testParam", 
  -                    org.apache.axis.encoding.XMLType.XSD_STRING,
  -                    Call.PARAM_MODE_IN);
  -</pre></div><p>
  -
  +The String argument is automatically serialized into XML, and the server
  +responds with an identical String, which we deserialize and print.
  +<p><i>Note: to actually watch the XML flowing back and forth between a
  +SOAP client and server, you can use the included tcpmon tool. See the <a href="#tcpmon">appendix</a>
  +for an overview.</i>
  +<h3>
  +Naming Parameters</h3>
  +In the above example, the parameters are in the order in which we sent
  +them, but since we only passed the objects themselves, Axis automatically
  +named the XML-encoded arguments in the SOAP message "arg0", "arg1", etc.
  +If you want to change this, it's easy! Before calling <tt>invoke()</tt>
  +you need to call <tt>addParameter</tt> for each parameter, like so:
  +<div class="example">
  +<pre>&nbsp; call.addParameter("testParam",&nbsp;
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; org.apache.axis.encoding.XMLType.XSD_STRING,
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Call.PARAM_MODE_IN);</pre>
  +</div>
   This will assign the name <b>testParam</b> to the 1st (and only) parameter
  -on the invoke call.  This will also define the type of the parameter 
  -(<code>org.apache.axis.encoding.XMLType.XSD_STRING</code>) and whether it is 
  -an input, output or inout parameter - in this case its an input parameter.
  -Now when you run the program you'll get a message that looks like this: 
  +on the invoke call. This will also define the type of the parameter (<tt>org.apache.axis.encoding.XMLType.XSD_STRING</tt>)
  +and whether it is an input, output or inout parameter - in this case its
  +an input parameter. Now when you run the program you'll get a message that
  +looks like this:
   <div class="xml">
  -  <pre>&lt;?xml version="1.0" encoding="UTF-8"?&gt;
  +<pre>&lt;?xml version="1.0" encoding="UTF-8"?>
   &lt;SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  -                   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  -                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
  -  &lt;SOAP-ENV:Body&gt;
  -    &lt;ns1:echoString xmlns:ns1="http://soapinterop.org/"&gt;
  -      &lt;<font color="#cc00cc">testParam</font> xsi:type="xsd:string"&gt;Hello!&lt;/<font color="#cc00cc">testParam</font>&gt;
  -    &lt;/ns1:echoString&gt;
  -  &lt;/SOAP-ENV:Body&gt;
  -&lt;/SOAP-ENV:Envelope&gt;</pre>
  -  
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  +&nbsp; &lt;SOAP-ENV:Body>
  +&nbsp;&nbsp;&nbsp; &lt;ns1:echoString xmlns:ns1="http://soapinterop.org/">
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;<font color="#CC00CC">testParam</font> xsi:type="xsd:string">Hello!&lt;/<font color="#CC00CC">testParam</font>>
  +&nbsp;&nbsp;&nbsp; &lt;/ns1:echoString>
  +&nbsp; &lt;/SOAP-ENV:Body>
  +&lt;/SOAP-ENV:Envelope></pre>
   </div>
  -<p>Note that the param is now named "testParam" as expected.</p>
  -<h3>Interoperating with &quot;untyped&quot; servers</h3>
  -<p>In the above examples, we've been casting the return type of invoke(), which 
  -  is Object, to the appropriate &quot;real&quot; type - for instance, we know 
  -  that the echoString method returns a String, so we expect to get one back from 
  -  client.invoke(). Let's take a moment and investigate how this happens, which 
  -  sheds light on a potential problem (to which, of course, we have a solution 
  -  - so don't fret :)).</p>
  -<p>Here's what a typical response might look like to the echoString method: </p>
  -<pre><div class="xml">&lt;?xml version="1.0" encoding="UTF-8"?&gt;
  -&lt;SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  -                   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  -                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
  -  &lt;SOAP-ENV:Body&gt;
  -    &lt;ns1:echoStringResponse xmlns:ns1="http://soapinterop.org/"&gt;
  -      &lt;result <font color="#FF0000">xsi:type="xsd:string"</font>&gt;Hello!&lt;/result&gt;
  -    &lt;/ns1:echoStringResponse&gt;
  -  &lt;/SOAP-ENV:Body&gt;
  -&lt;/SOAP-ENV:Envelope&gt;</div></pre>
  -<p>Take a look at the section which we've highlighted in red - that attribute 
  -  is a schema <b>type declaration</b>, which Axis uses to figure out that the 
  -  contents of that element are, in this case, deserializable into a Java String 
  -  object. Many toolkits put this kind of explicit typing information in the XML 
  -  to make the message &quot;self-describing&quot;. On the other hand, some toolkits 
  -  return responses that look like this:</p>
  -<pre><div class="xml">&lt;?xml version="1.0" encoding="UTF-8"?&gt;
  -&lt;SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  -                   xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  -                   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"&gt;
  -  &lt;SOAP-ENV:Body&gt;
  -    &lt;ns1:echoStringResponse xmlns:ns1="http://soapinterop.org/"&gt;
  -      &lt;result&gt;Hello, I'm a string!&lt;/result&gt;
  -    &lt;/ns1:echoStringResponse&gt;
  -  &lt;/SOAP-ENV:Body&gt;
  -&lt;/SOAP-ENV:Envelope&gt;</div></pre>
  -<p>There's no type in the message, so how do we know what Java object we should 
  -  deserialize the &lt;result&gt; element into? The answer is <b>metadata</b> - 
  -  data about data. In this case, we need a <b>description</b> of the service that 
  -  tells us what to expect as the return type. Here's how to do it on the client 
  -  side in Axis:</p>
  +Note that the param is now named "testParam" as expected.
  +<h3>
  +Interoperating with "untyped" servers</h3>
  +In the above examples, we've been casting the return type of invoke(),
  +which is Object, to the appropriate "real" type - for instance, we know
  +that the echoString method returns a String, so we expect to get one back
  +from client.invoke(). Let's take a moment and investigate how this happens,
  +which sheds light on a potential problem (to which, of course, we have
  +a solution - so don't fret :)).
  +<p>Here's what a typical response might look like to the echoString method:
  +<div class="xml">&lt;?xml version="1.0" encoding="UTF-8"?> &lt;SOAP-ENV:Envelope
  +xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  +xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> &lt;SOAP-ENV:Body>
  +&lt;ns1:echoStringResponse xmlns:ns1="http://soapinterop.org/"> &lt;result
  +<font color="#FF0000">xsi:type="xsd:string"</font>>Hello!&lt;/result>
  +&lt;/ns1:echoStringResponse> &lt;/SOAP-ENV:Body> &lt;/SOAP-ENV:Envelope></div>
  +Take a look at the section which we've highlighted in red - that attribute
  +is a schema <b>type declaration</b>, which Axis uses to figure out that
  +the contents of that element are, in this case, deserializable into a Java
  +String object. Many toolkits put this kind of explicit typing information
  +in the XML to make the message "self-describing". On the other hand, some
  +toolkits return responses that look like this:
  +<div class="xml">&lt;?xml version="1.0" encoding="UTF-8"?> &lt;SOAP-ENV:Envelope
  +xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  +xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> &lt;SOAP-ENV:Body>
  +&lt;ns1:echoStringResponse xmlns:ns1="http://soapinterop.org/"> &lt;result>Hello,
  +I'm a string!&lt;/result> &lt;/ns1:echoStringResponse> &lt;/SOAP-ENV:Body>
  +&lt;/SOAP-ENV:Envelope></div>
  +There's no type in the message, so how do we know what Java object we should
  +deserialize the &lt;result> element into? The answer is <b>metadata</b>
  +- data about data. In this case, we need a <b>description</b> of the service
  +that tells us what to expect as the return type. Here's how to do it on
  +the client side in Axis:
   <div class="example">
  -  <pre>  call.setReturnType( org.apache.axis.encoding.XMLType.XSD_STRING ); </pre>
  +<pre>&nbsp; call.setReturnType( org.apache.axis.encoding.XMLType.XSD_STRING );</pre>
   </div>
  -<p>
  -  This method will tell the Axis client that if the return element is not typed
  -  then it should act as if the return value has an xsi:type attribute set to
  -  the predefined SOAP String type.
  -  (You can see an example of this in action in the interop echo-test 
  -  client - samples/echo/TestClient.java.)</p>
  -<p>OK - so now you know the basics of accessing SOAP services as a client. But 
  -  how do you publish your own services?</p>
  -<h2><a name="PublishingServices"></a>Publishing Web Services with Axis</h2>
  -<p>Let's say we have a simple class like the following:</p>
  +This method will tell the Axis client that if the return element is not
  +typed then it should act as if the return value has an xsi:type attribute
  +set to the predefined SOAP String type. (You can see an example of this
  +in action in the interop echo-test client - samples/echo/TestClient.java.)
  +<p>OK - so now you know the basics of accessing SOAP services as a client.
  +But how do you publish your own services?
  +<h2>
  +<a NAME="PublishingServices"></a>Publishing Web Services with Axis</h2>
  +Let's say we have a simple class like the following:
   <pre class="example">public class Calculator {
  -  public int add(int i1, int i2)
  -  {
  -    return i1 + i2; 
  -  }
  -  
  -  public int subtract(int i1, int i2)
  -  {
  -    return i1 - i2;
  -  }
  -} 
  -</pre>
  -<p>(You'll find this very class in <a href="../samples/userguide/example2/Calculator.java">samples/userguide/example2/Calculator.java</a>.)</p>
  -<p>How do we go about making this class available via SOAP? There are a couple 
  -  of answers to that question, but we'll start with the easiest way Axis provides 
  -  to do this, which takes almost no effort at all!</p>
  -<h3>JWS (Java Web Service) Files - Instant Deployment</h3>
  -<p>OK, here's step 1 : copy the above .java file into your webapp directory, and 
  -  rename it "Calculator.jws". So you might do something like this:</p>
  -<pre>% copy Calculator.java <i><font color="#0000FF">&lt;your-webapp-root&gt;</font></i>/axis/Calculator.jws</pre>
  -<p>Now for step 2... hm, wait a minute. You're done! You should now be able to 
  -  access the service at the following URL (assuming your Axis web application 
  -  is on port 8080):</p>
  -<p><a href="http://localhost:8080/axis/Calculator.jws">http://localhost:8080/axis/Calculator.jws</a> 
  -</p>
  -<p>Axis automatically locates the file, compiles the class, and converts SOAP 
  -  calls correctly into Java invocations of your service class. Try it out - there's 
  -  a calculator client in samples/userguide/example2/CalcClient.java, which you 
  -  can use like this:</p>
  +&nbsp; public int add(int i1, int i2)
  +&nbsp; {
  +&nbsp;&nbsp;&nbsp; return i1 + i2;&nbsp;
  +&nbsp; }
  +&nbsp;&nbsp;
  +&nbsp; public int subtract(int i1, int i2)
  +&nbsp; {
  +&nbsp;&nbsp;&nbsp; return i1 - i2;
  +&nbsp; }
  +}</pre>
  +(You'll find this very class in <a href="../samples/userguide/example2/Calculator.java">samples/userguide/example2/Calculator.java</a>.)
  +<p>How do we go about making this class available via SOAP? There are a
  +couple of answers to that question, but we'll start with the easiest way
  +Axis provides to do this, which takes almost no effort at all!
  +<h3>
  +JWS (Java Web Service) Files - Instant Deployment</h3>
  +OK, here's step 1 : copy the above .java file into your webapp directory,
  +and rename it "Calculator.jws". So you might do something like this:
  +<pre>% copy Calculator.java <i><font color="#0000FF">&lt;your-webapp-root></font></i>/axis/Calculator.jws</pre>
  +Now for step 2... hm, wait a minute. You're done! You should now be able
  +to access the service at the following URL (assuming your Axis web application
  +is on port 8080):
  +<p><a href="http://localhost:8080/axis/Calculator.jws">http://localhost:8080/axis/Calculator.jws</a>
  +<p>Axis automatically locates the file, compiles the class, and converts
  +SOAP calls correctly into Java invocations of your service class. Try it
  +out - there's a calculator client in samples/userguide/example2/CalcClient.java,
  +which you can use like this:
   <pre>% javac CalcClient.java
   % java CalcClient -p8080 add 2 5
   Got result : 7
   % java CalcClient -p8080 subtract 10 9
   Got result : 1
  -% </pre>
  -(note that you may need to replace the &quot;-p8080&quot; with whatever port your 
  -J2EE server is running on) 
  -<h3>Custom Deployment - Introducing WSDD</h3>
  -<p>JWS files are great quick ways to get your classes out there as Web Services, 
  -  but they're not always the best choice. For one thing, you need the source code 
  -  - there might be times when you want to expose a pre-existing class on your 
  -  system without source. Also, the amount of configuration you can do as to how 
  -  the service gets accessed is pretty limited - you can't specify custom type 
  -  mappings, or control which Handlers get invoked when people are using your service.</p>
  -<h4><a name="descriptors"></a>Deploying via descriptors</h4>
  -To really use the flexibility available to you in Axis, you should get familiar 
  -with the Axis <b>Web Service Deployment Descriptor (WSDD)</b> format. A deployment 
  -descriptor contains a bunch of things you want to "deploy" into Axis - i.e. make 
  -available to the Axis engine. The most common thing to deploy is a Web Service, 
  -so let's start by taking a look at a deployment descriptor for a basic service 
  -(this file is samples/userguide/example3/deploy.wsdd): 
  -<div class="example"> 
  -  <pre>&lt;deployment xmlns=&quot;http://xml.apache.org/axis/wsdd/&quot;
  -            xmlns:java=&quot;http://xml.apache.org/axis/wsdd/providers/java&quot;&gt;
  - &lt;service name="MyService" provider=&quot;java:RPC&quot;&gt;
  -  &lt;parameter name="className" value="samples.userguide.example3.MyService"/&gt;
  -  &lt;parameter name="methodName" value="*"/&gt;
  - &lt;/service&gt;
  -&lt;/deployment&gt;</pre>
  +%</pre>
  +(note that you may need to replace the "-p8080" with whatever port your
  +J2EE server is running on)
  +<h3>
  +Custom Deployment - Introducing WSDD</h3>
  +JWS files are great quick ways to get your classes out there as Web Services,
  +but they're not always the best choice. For one thing, you need the source
  +code - there might be times when you want to expose a pre-existing class
  +on your system without source. Also, the amount of configuration you can
  +do as to how the service gets accessed is pretty limited - you can't specify
  +custom type mappings, or control which Handlers get invoked when people
  +are using your service.
  +<h4>
  +<a NAME="descriptors"></a>Deploying via descriptors</h4>
  +To really use the flexibility available to you in Axis, you should get
  +familiar with the Axis <b>Web Service Deployment Descriptor (WSDD)</b>
  +format. A deployment descriptor contains a bunch of things you want to
  +"deploy" into Axis - i.e. make available to the Axis engine. The most common
  +thing to deploy is a Web Service, so let's start by taking a look at a
  +deployment descriptor for a basic service (this file is samples/userguide/example3/deploy.wsdd):
  +<div class="example">
  +<pre>&lt;deployment xmlns="http://xml.apache.org/axis/wsdd/"
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
  +&nbsp;&lt;service name="MyService" provider="java:RPC">
  +&nbsp; &lt;parameter name="className" value="samples.userguide.example3.MyService"/>
  +&nbsp; &lt;parameter name="methodName" value="*"/>
  +&nbsp;&lt;/service>
  +&lt;/deployment></pre>
   </div>
  -
  -<p>Pretty simple, really - the outermost element tells the engine that this is 
  -  a WSDD deployment, and defines the &quot;java&quot; namespace. Then the service 
  -  element actually defines the service for us. If you remember from the architecture 
  -  overview, a service is a <b>targeted chain</b>, which means it may have any/all 
  -  of: a request Handler, a pivot Handler (which for a service is called a &quot;provider&quot;), 
  -  and a response Handler. In this case, our provider is &quot;java:RPC&quot;, 
  -  which is predefined to indicate a Java RPC service.</p>
  -<p>We need to tell the RPCDispatcher that it should instantiate and call the correct 
  -  class (e.g. samples.userguide.example3.MyService), and we do so by including 
  -  a &lt;parameter&gt; tag, giving the service one parameter to configure the class 
  -  name, and another to tell the engine that any public method on that class may 
  -  be called via SOAP (that's what the "*" means; we could also have restricted 
  -  the SOAP-accessible methods by using a space or comma separated list of available 
  -  method names).</p>
  -<h4>Using the AdminClient</h4>
  -<p>Once we have this file, we need to send it to an Axis server in order to actually 
  -  deploy the described service. We do this with the AdminClient, or the "org.apache.axis.client.AdminClient" 
  -  class. An invocation of the AdminClient looks like this:</p>
  +Pretty simple, really - the outermost element tells the engine that this
  +is a WSDD deployment, and defines the "java" namespace. Then the service
  +element actually defines the service for us. If you remember from the architecture
  +overview, a service is a <b>targeted chain</b>, which means it may have
  +any/all of: a request Handler, a pivot Handler (which for a service is
  +called a "provider"), and a response Handler. In this case, our provider
  +is "java:RPC", which is predefined to indicate a Java RPC service.
  +<p>We need to tell the RPCDispatcher that it should instantiate and call
  +the correct class (e.g. samples.userguide.example3.MyService), and we do
  +so by including a &lt;parameter> tag, giving the service one parameter
  +to configure the class name, and another to tell the engine that any public
  +method on that class may be called via SOAP (that's what the "*" means;
  +we could also have restricted the SOAP-accessible methods by using a space
  +or comma separated list of available method names).
  +<h4>
  +Using the AdminClient</h4>
  +Once we have this file, we need to send it to an Axis server in order to
  +actually deploy the described service. We do this with the AdminClient,
  +or the "org.apache.axis.client.AdminClient" class. An invocation of the
  +AdminClient looks like this:
   <pre>% java org.apache.axis.client.AdminClient deploy.wsdd
  -&lt;Admin&gt;Done processing&lt;/Admin&gt;</pre>
  -<p>This command has now made our service accessible via 
  -SOAP. Check it out by running the Client class -  it should look like this:</p><PRE>% java samples.userguide.example3.Client "test me!"<BR>You typed : test me!<BR>% </PRE>
  -<P>If you want to prove to yourself that the deployment really worked, try undeploying 
  -  the service and calling it again.&nbsp; There's an "undeploy.wsdd" file in the 
  -  example3/ directory which you can use just as you did the deploy.wsdd file above.&nbsp; 
  -  Run the AdminClient on that file, then try the service Client again and see 
  -  what happens.</P>
  -<P>You can also use the AdminClient to get a listing of all the deployed 
  -components in the server:</P><PRE>% java org.apache.axis.client.AdminClient list<BR>&lt;big XML document returned here&gt;</PRE>
  -<P>In there you'll see services, handlers, transports, etc. Note that this listing 
  -  is an exact copy of the server's &quot;server-config.wsdd&quot; file, which 
  -  we'll talk about in more detail a little later.</P>
  -<H4>More deployment - Handlers and Chains</H4>
  -<p>Now let's start to explore some of the more powerful features of the Axis engine. 
  -  Let's say you want to track how many times your service has been called. We've 
  -  included a sample handler in the samples/log directory to do just this. To use 
  -  a handler class like this, you first need to deploy the Handler itself, and 
  -  then use the name that you give it in deploying a service. Here's a sample deploy.wsdd 
  -  file (this is example 4in samples/userguide): </p>
  -<pre>&lt;deployment xmlns=&quot;http://xml.apache.org/axis/wsdd/&quot;
  -            xmlns:java=&quot;http://xml.apache.org/axis/wsdd/providers/java&quot;&gt;
  - 
  - &lt;!-- define the logging handler configuration --&gt;
  - &lt;handler name="track" type="java:samples.userguide.example4.LogHandler"&gt;
  -  &lt;parameter name="filename" value="MyService.log"/&gt;
  - &lt;/handler&gt;
  -
  - &lt;!-- define the service, using the log handler we just defined --&gt;
  - &lt;service name="LogTestService"<b> </b>provider=&quot;java:RPC"&gt;
  -  &lt;requestFlow&gt;
  -   &lt;handler type=&quot;track&quot;/&gt;
  -  &lt;/requestFlow&gt;
  -
  -  &lt;parameter name="className" value="samples.userguide.example4.Service"/&gt;
  -  &lt;parameter name="methodName" value="*"/&gt;
  - &lt;/service&gt;
  -&lt;/deployment&gt;</pre>
  -<p>The first section defines a Handler called "track" that is implemented by the 
  -  class samples.userguide.example4.LogHandler. We give this Handler an option to let it know 
  -  which file to write its messages into.</p>
  -<p>Then we define a service, LogTestService, which is an RPC service just like we saw 
  -  above in our first example. The difference is the &lt;requestFlow&gt; element 
  -  inside the &lt;service&gt; - this indicates a set of Handlers that should be 
  -  invoked when the service is invoked, before the provider. By inserting a reference 
  -  to "track", we ensure that the message will be logged each time this service 
  -  is invoked.<br>
  -</p>
  -<h4>Remote Administration</h4>
  -<p>Note that by default, the Axis server is configured to only accept administration 
  -  requests from the machine on which it resides - if you wish to enable remote 
  -  administration, you must set the "enableRemoteAdmin" property of the AdminService 
  -  to <b>true</b>. To do this, find the "server-config.wsdd" file in your webapp's 
  -  WEB-INF directory. In it, you'll see a deployment for the AdminService. Add 
  -  an option as follows:</p>
  -<pre>&lt;service name="AdminService" provider=&quot;java:MSG"&gt;
  - &lt;parameter name="className" value="org.apache.axis.util.Admin"/&gt;
  - &lt;parameter name="methodName" value="*"/&gt;
  - <b>&lt;parameter name="enableRemoteAdmin" value="true"/&gt;</b>
  -&lt;/service&gt;</pre>
  -<p><b>WARNING: enabling remote administration may give unauthorized parties access 
  -  to your machine. If you do this, please make sure to add security to your configuration!</b><br>
  -  <i><font color="#ff0000"></font></i> </p>
  -<i><font color="#ff0000"></font></i><h2><a name="DataMapping"></a>XML &lt;-&gt; Java Data Mapping in Axis</h2>
  -<h3>Encoding Your Beans - the BeanSerializer</h3>
  -<p>Axis includes the ability to serialize/deserialize, without writing any code, 
  -  arbitrary Java classes which follow the standard JavaBean pattern of get/set 
  -  accessors. All you need to do is tell Axis which Java classes map to which XML 
  -  Schema types. Configuring a bean mapping looks like this:</p>
  -<pre class="xml">&lt;beanMapping qname=&quot;ns:local&quot; xmlns:ns="someNamespace"
  -             languageSpecificType="java:my.java.thingy"/&gt;
  -</pre>
  -<p>The &lt;beanMapping&gt; tag maps a Java class (presumably a bean) to an XML 
  -  QName. You'll note that it has two important attributes, <b>qname</b> and <b>languageSpecificType</b>. 
  -  So in this case, we'd be mapping the "my.java.thingy" class to the XML QName 
  -  [someNamespace]:[local].</p>
  -<p>Let's take a look at how this works in practice. Go look at the samples/userguide/example5/BeanService.java 
  -  file. (we won't reproduce it here, it's pretty straightforward) The key thing 
  -  to notice is that the argument to the service method is an Order object. Since 
  -  Order is not a basic type which Axis understands by default, trying to run this 
  -  service without a type mapping will result in a fault (if you want to try this 
  -  for yourself, you can use the bad-deploy.wsdd file in the example5 directory). 
  -  But if we put a beanMapping into our deployment, all will be well. Here's how 
  -  to run this example (from the example5 directory):</p>
  +&lt;Admin>Done processing&lt;/Admin></pre>
  +This command has now made our service accessible via SOAP. Check it out
  +by running the Client class - it should look like this:
  +<pre>% java samples.userguide.example3.Client "test me!"
  +You typed : test me!
  +%</pre>
  +If you want to prove to yourself that the deployment really worked, try
  +undeploying the service and calling it again.&nbsp; There's an "undeploy.wsdd"
  +file in the example3/ directory which you can use just as you did the deploy.wsdd
  +file above.&nbsp; Run the AdminClient on that file, then try the service
  +Client again and see what happens.
  +<p>You can also use the AdminClient to get a listing of all the deployed
  +components in the server:
  +<pre>% java org.apache.axis.client.AdminClient list
  +&lt;big XML document returned here></pre>
  +In there you'll see services, handlers, transports, etc. Note that this
  +listing is an exact copy of the server's "server-config.wsdd" file, which
  +we'll talk about in more detail a little later.
  +<h4>
  +More deployment - Handlers and Chains</h4>
  +Now let's start to explore some of the more powerful features of the Axis
  +engine. Let's say you want to track how many times your service has been
  +called. We've included a sample handler in the samples/log directory to
  +do just this. To use a handler class like this, you first need to deploy
  +the Handler itself, and then use the name that you give it in deploying
  +a service. Here's a sample deploy.wsdd file (this is example 4in samples/userguide):
  +<pre>&lt;deployment xmlns="http://xml.apache.org/axis/wsdd/"
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
  +&nbsp;
  +&nbsp;&lt;!-- define the logging handler configuration -->
  +&nbsp;&lt;handler name="track" type="java:samples.userguide.example4.LogHandler">
  +&nbsp; &lt;parameter name="filename" value="MyService.log"/>
  +&nbsp;&lt;/handler>
  +
  +&nbsp;&lt;!-- define the service, using the log handler we just defined -->
  +&nbsp;&lt;service name="LogTestService"<b> </b>provider="java:RPC">
  +&nbsp; &lt;requestFlow>
  +&nbsp;&nbsp; &lt;handler type="track"/>
  +&nbsp; &lt;/requestFlow>
  +
  +&nbsp; &lt;parameter name="className" value="samples.userguide.example4.Service"/>
  +&nbsp; &lt;parameter name="methodName" value="*"/>
  +&nbsp;&lt;/service>
  +&lt;/deployment></pre>
  +The first section defines a Handler called "track" that is implemented
  +by the class samples.userguide.example4.LogHandler. We give this Handler
  +an option to let it know which file to write its messages into.
  +<p>Then we define a service, LogTestService, which is an RPC service just
  +like we saw above in our first example. The difference is the &lt;requestFlow>
  +element inside the &lt;service> - this indicates a set of Handlers that
  +should be invoked when the service is invoked, before the provider. By
  +inserting a reference to "track", we ensure that the message will be logged
  +each time this service is invoked.
  +<h4>
  +Remote Administration</h4>
  +Note that by default, the Axis server is configured to only accept administration
  +requests from the machine on which it resides - if you wish to enable remote
  +administration, you must set the "enableRemoteAdmin" property of the AdminService
  +to <b>true</b>. To do this, find the "server-config.wsdd" file in your
  +webapp's WEB-INF directory. In it, you'll see a deployment for the AdminService.
  +Add an option as follows:
  +<pre>&lt;service name="AdminService" provider="java:MSG">
  +&nbsp;&lt;parameter name="className" value="org.apache.axis.util.Admin"/>
  +&nbsp;&lt;parameter name="methodName" value="*"/>
  +&nbsp;<b>&lt;parameter name="enableRemoteAdmin" value="true"/>
  +</b>&lt;/service></pre>
  +<b>WARNING: enabling remote administration may give unauthorized parties
  +access to your machine. If you do this, please make sure to add security
  +to your configuration!</b>
  +<h2>
  +<a NAME="DataMapping"></a>XML &lt;-> Java Data Mapping in Axis</h2>
  +
  +<h3>
  +Encoding Your Beans - the BeanSerializer</h3>
  +Axis includes the ability to serialize/deserialize, without writing any
  +code, arbitrary Java classes which follow the standard JavaBean pattern
  +of get/set accessors. All you need to do is tell Axis which Java classes
  +map to which XML Schema types. Configuring a bean mapping looks like this:
  +<pre class="xml">&lt;beanMapping qname="ns:local" xmlns:ns="someNamespace"
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; languageSpecificType="java:my.java.thingy"/></pre>
  +The &lt;beanMapping> tag maps a Java class (presumably a bean) to an XML
  +QName. You'll note that it has two important attributes, <b>qname</b> and
  +<b>languageSpecificType</b>.
  +So in this case, we'd be mapping the "my.java.thingy" class to the XML
  +QName [someNamespace]:[local].
  +<p>Let's take a look at how this works in practice. Go look at the samples/userguide/example5/BeanService.java
  +file. (we won't reproduce it here, it's pretty straightforward) The key
  +thing to notice is that the argument to the service method is an Order
  +object. Since Order is not a basic type which Axis understands by default,
  +trying to run this service without a type mapping will result in a fault
  +(if you want to try this for yourself, you can use the bad-deploy.wsdd
  +file in the example5 directory). But if we put a beanMapping into our deployment,
  +all will be well. Here's how to run this example (from the example5 directory):
   <pre class="example">% java org.apache.axis.client.AdminClient -llocal:///AdminService deploy.wsdd
  -&lt;Admin&gt;Done processing&lt;/Admin&gt;
  +&lt;Admin>Done processing&lt;/Admin>
   
   % java Client -llocal:// -n "Glen"
   Hi, Glen!
  @@ -439,163 +535,196 @@
   4 of item : 1600mahBattery
   
   If this had been a real order processing system, we'd probably have charged you about now.
  -%<br>
  +%
  +
   </pre>
  -<h3>When Beans Are Not Enough - Custom Serialization</h3>
  -<p>Just as JWS deployment is sometimes not flexible enough to meet all needs, 
  -  the default bean serialization model isn't robust enough to handle every case 
  -  either. At times there will be non-bean Java classes (especially in the case 
  -  of pre-existing assets) which you need to map to/from XML, and there also may 
  -  be some custom XML schema types which you want to map into Java in particular 
  -  ways. Axis gives you the ability to write custom serializers/deserializers, 
  -  and some tools to help make your life easier when you do so.</p>
  -<p><i><font color="#ff0000">TBD - this section will be expanded in a future version! 
  -  For now, take a look at the ArraySerializer, the BeanSerializer (both in org.apache.axis.encoding), 
  -  and the DataSer example (in samples/encoding) to see how custom serializers 
  -  work.</font></i></p>
  -<h4>Deploying custom mappings - the &lt;typeMapping&gt; tag</h4>
  -<p>Now that you've built your serializers and deserializers, you need to tell 
  -  Axis which types they should be used for. You do this with a typeMapping tag 
  -  in WSDD, which looks like this:</p>
  -<pre class="xml">&lt;typeMapping qname=&quot;ns:local&quot; xmlns:ns="someNamespace"
  -             languageSpecificType="java:my.java.thingy"
  -             serializer=&quot;my.java.Serializer&quot;
  -             deserializer=&quot;my.java.DeserializerFactory&quot;/&gt;</pre>
  -<p>This looks a lot like the &lt;beanMapping&gt; tag we saw earlier, but there 
  -  are two extra attributes. One, <b>serializer</b>, is the Java class name of 
  -  the Serializer class which should be used to write the specified Java class 
  -  (i.e. my.java.thingy) into XML. The other, <b>deserializer</b>, is the class 
  -  name of a Deserializer <i>factory</i> that generates Deserializers which can 
  -  be used to unmarshall XML into the correct Java class.</p>
  -<p>(the &lt;beanMapping&gt; tag is really just shorthand for a &lt;typeMapping&gt; 
  -  tag with serializer=&quot;org.apache.axis.encoding.BeanSerializer&quot; and 
  -  deserializer=&quot;org.apache.axis.encoding.BeanSerializer$BeanSerFactory&quot;, 
  -  but clearly it can save a lot of typing!)</p>
  -<h2><a name="WSDL"></a>Using WSDL with Axis</h2>
  -<p>The <a href="http://www.w3.org/TR/wsdl">Web Service Description Language</a> 
  -  is a specification authored by IBM and Microsoft, and supported by many other 
  -  organizations. WSDL serves to describe Web Services in a structured way. A WSDL 
  -  description of a service tells us, in a machine-understandable way, the interface 
  -  to the service, the data types it uses, and where the service is located. Please 
  -  see the spec (follow the link in the first sentence) for details about WSDL's 
  -  format and options.</p>
  -<p>Axis supports WSDL in two ways: first, when you deploy a service in Axis, users 
  -  may then access your service's URL with a standard web browser and by appending 
  -  &quot;?WSDL&quot; to the end of the URL, they will obtain an automatically-generated 
  -  WSDL document which describes your service. Second, we provide a &quot;Wsdl2java&quot; 
  -  tool which will build Java proxies and skeletons for services with WSDL descriptions. 
  -  Both of these techniques are explained in more detail below.</p>
  -<h3>WSDL generation for deployed services</h3>
  -<p>When you make a service available using Axis, there is typically a unique URL 
  -  associated with that service. For JWS files, that URL is simply the path to 
  -  the JWS file itself. For non-JWS services, this is usually the URL &quot;http://&lt;host&gt;/axis/services/&lt;service-name&gt;&quot;.</p>
  -<p>If you access the service URL in a browser, you'll see a message indicating 
  -  that the endpoint is an Axis service, and that you should usually access it 
  -  using SOAP. However, if you tack on &quot;?wsdl&quot; to the end of the URL, 
  -  Axis will automatically generate a service description for the deployed service, 
  -  and return it as XML in your browser (try it!). The resulting description may 
  -  be saved or used as input to proxy-generation, described next. You can give 
  -  the WSDL-generation URL to your online partners, and they'll be able to use 
  -  it to access your service with toolkits like .NET, SOAP::Lite, or any other 
  -  software which supports using WSDL.</p>
  -<h3>Building stubs and skeletons with Wsdl2java</h3>
  -<p>You'll find the Axis WSDL -&gt; Java tool in &quot;org.apache.axis.wsdl.Wsdl2java&quot;. 
  -  The basic invocation form looks like this:</p>
  +
  +<h3>
  +When Beans Are Not Enough - Custom Serialization</h3>
  +Just as JWS deployment is sometimes not flexible enough to meet all needs,
  +the default bean serialization model isn't robust enough to handle every
  +case either. At times there will be non-bean Java classes (especially in
  +the case of pre-existing assets) which you need to map to/from XML, and
  +there also may be some custom XML schema types which you want to map into
  +Java in particular ways. Axis gives you the ability to write custom serializers/deserializers,
  +and some tools to help make your life easier when you do so.
  +<p><i><font color="#FF0000">TBD - this section will be expanded in a future
  +version! For now, take a look at the ArraySerializer, the BeanSerializer
  +(both in org.apache.axis.encoding), and the DataSer example (in samples/encoding)
  +to see how custom serializers work.</font></i>
  +<h4>
  +Deploying custom mappings - the &lt;typeMapping> tag</h4>
  +Now that you've built your serializers and deserializers, you need to tell
  +Axis which types they should be used for. You do this with a typeMapping
  +tag in WSDD, which looks like this:
  +<pre class="xml">&lt;typeMapping qname="ns:local" xmlns:ns="someNamespace"
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; languageSpecificType="java:my.java.thingy"
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; serializer="my.java.Serializer"
  +&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; deserializer="my.java.DeserializerFactory"/></pre>
  +This looks a lot like the &lt;beanMapping> tag we saw earlier, but there
  +are two extra attributes. One, <b>serializer</b>, is the Java class name
  +of the Serializer class which should be used to write the specified Java
  +class (i.e. my.java.thingy) into XML. The other, <b>deserializer</b>, is
  +the class name of a Deserializer <i>factory</i> that generates Deserializers
  +which can be used to unmarshall XML into the correct Java class.
  +<p>(the &lt;beanMapping> tag is really just shorthand for a &lt;typeMapping>
  +tag with serializer="org.apache.axis.encoding.BeanSerializer" and deserializer="org.apache.axis.encoding.BeanSerializer$BeanSerFactory",
  +but clearly it can save a lot of typing!)
  +<h2>
  +<a NAME="WSDL"></a>Using WSDL with Axis</h2>
  +The <a href="http://www.w3.org/TR/wsdl">Web Service Description Language</a>
  +is a specification authored by IBM and Microsoft, and supported by many
  +other organizations. WSDL serves to describe Web Services in a structured
  +way. A WSDL description of a service tells us, in a machine-understandable
  +way, the interface to the service, the data types it uses, and where the
  +service is located. Please see the spec (follow the link in the first sentence)
  +for details about WSDL's format and options.
  +<p>Axis supports WSDL in three ways:
  +<ol>
  +<li>
  +When you deploy a service in Axis, users may then access your service's
  +URL with a standard web browser and by appending "?WSDL" to the end of
  +the URL, they will obtain an automatically-generated WSDL document which
  +describes your service.</li>
  +
  +<li>
  +We provide a "WSDL2Java" tool which will build Java proxies and skeletons
  +for services with WSDL descriptions.</li>
  +
  +<li>
  +We provide a "Java2WSDL" tool which will build WSDL from Java classes.</li>
  +</ol>
  +
  +<h3>
  +<a NAME="WSDL: Obtaining WSDL for deployed services"></a>?WSDL: Obtaining
  +WSDL for deployed services</h3>
  +When you make a service available using Axis, there is typically a unique
  +URL associated with that service. For JWS files, that URL is simply the
  +path to the JWS file itself. For non-JWS services, this is usually the
  +URL "http://&lt;host>/axis/services/&lt;service-name>".
  +<p>If you access the service URL in a browser, you'll see a message indicating
  +that the endpoint is an Axis service, and that you should usually access
  +it using SOAP. However, if you tack on "?wsdl" to the end of the URL, Axis
  +will automatically generate a service description for the deployed service,
  +and return it as XML in your browser (try it!). The resulting description
  +may be saved or used as input to proxy-generation, described next. You
  +can give the WSDL-generation URL to your online partners, and they'll be
  +able to use it to access your service with toolkits like .NET, SOAP::Lite,
  +or any other software which supports using WSDL.
  +<p>You can also generate WSDL files from existing Java classes (see <a href="#Java2WSDL: Building WSDL from Java">#Java2WSDL:
  +Building WSDL from Java</a>&nbsp; ).
  +<h3>
  +<a NAME="WSDL2Java: Building stubs, skeletons, and data"></a>WSDL2Java:
  +Building stubs, skeletons, and data types from WSDL</h3>
  +You'll find the Axis WSDL -> Java tool in "org.apache.axis.wsdl.WSDL2Java".
  +The basic invocation form looks like this:
   <div class="example">
  -  <pre>% java org.apache.axis.wsdl.Wsdl2java <i>(url-to-wsdl-file)</i>
  -</pre>
  +<pre>% java org.apache.axis.wsdl.WSDL2Java <i>(url-to-wsdl-file)</i></pre>
   </div>
  -<h4>Stubs - making Web Service access transparent from the client side</h4>
  -<p>A <b>stub</b> is a Java class which has the same interface as a remote Web 
  -  Service. It stands in as a <b>proxy</b> (another term for the same idea) for 
  -  the remote service, letting you call it exactly as if it were a local object. 
  -  In other words, you don't need to deal with the endpoint URL, namespace, or 
  -  parameter arrays which are involved in dynamic invocation via the Service
  -  and Call objects. 
  -  The stub hides all that work for you.</p>
  -<p>You can try an example, assuming you've deployed the service in <a href="#descriptors">example 
  -  3</a> above and have your Axis server up and running. Type the following at 
  -  the command line:</p>
  -<pre>% java org.apache.axis.wsdl.Wsdl2java http://localhost:8080/axis/services/MyService?wsdl</pre>
  -<p>You can add the &quot;--verbose&quot; option right before the URL if you want 
  -  some more feedback on what the tool is up to. This will generate stub code, 
  -  which we'll describe.</p>
  -<p>Wsdl2java generates a few classes; here's a rundown of what they are and how 
  -  to use them:</p>
  +
  +<h4>
  +Stubs - making Web Service access transparent from the client side</h4>
  +A <b>stub</b> is a Java class which has the same interface as a remote
  +Web Service. It stands in as a <b>proxy</b> (another term for the same
  +idea) for the remote service, letting you call it exactly as if it were
  +a local object. In other words, you don't need to deal with the endpoint
  +URL, namespace, or parameter arrays which are involved in dynamic invocation
  +via the Service and Call objects. The stub hides all that work for you.
  +<p>You can try an example, assuming you've deployed the service in <a href="#descriptors">example
  +3</a> above and have your Axis server up and running. Type the following
  +at the command line:
  +<pre>% java org.apache.axis.wsdl.WSDL2Java http://localhost:8080/axis/services/MyService?wsdl</pre>
  +You can add the "--verbose" option right before the URL if you want some
  +more feedback on what the tool is up to. This will generate stub code,
  +which we'll describe.
  +<p>WSDL2Java generates a few classes; here's a rundown of what they are
  +and how to use them:
   <ul>
  -  <li>There will be an interface for each referenced PortType in the WSDL. These 
  -    interfaces are the ones you will actually use to call the remote methods, 
  -    as they contain the operations described in the WSDL. For the example, above, 
  -    the generated interface is called MyServicePortType.</li>
  -  <li>The Stub classes implement the interface, and contain the code which turns 
  -    the method invocations into SOAP calls using the Axis Service and Call
  -    objects. For the 
  -    example, this is MyServiceSoapBindingStub. The stubs themselves also have 
  -    a few additional methods for getting a little more control over the SOAP invocations 
  -    - in this version of Axis we won't go into more detail about these, though 
  -    you can read the code if you're inclined.</li>
  -  <li>The Service class serves as a factory for obtaining Stub instances - MyService 
  -    for our example. The Service class will by default make a Stub which points 
  -    to the endpoint URL described in the WSDL file, but you may also specify a 
  -    different URL when you ask for the PortType.</li>
  +<li>
  +There will be an interface for each referenced PortType in the WSDL. These
  +interfaces are the ones you will actually use to call the remote methods,
  +as they contain the operations described in the WSDL. For the example,
  +above, the generated interface is called MyServicePortType.</li>
  +
  +<li>
  +The Stub classes implement the interface, and contain the code which turns
  +the method invocations into SOAP calls using the Axis Service and Call
  +objects. For the example, this is MyServiceSoapBindingStub. The stubs themselves
  +also have a few additional methods for getting a little more control over
  +the SOAP invocations - in this version of Axis we won't go into more detail
  +about these, though you can read the code if you're inclined.</li>
  +
  +<li>
  +The Service class serves as a factory for obtaining Stub instances - MyService
  +for our example. The Service class will by default make a Stub which points
  +to the endpoint URL described in the WSDL file, but you may also specify
  +a different URL when you ask for the PortType.</li>
   </ul>
  -<p>So a typical usage of the stub classes would be as follows:</p>
  +So a typical usage of the stub classes would be as follows:
   <pre class="example">public class Tester {
  -  public static void main(String [] args) throws Exception
  -  {
  -    // Make a service (PortType factory)
  -    MyService service = new MyService();
  -
  -
  -    // Now use the service to get a PortType that we can call.
  -    MyServicePortType port = service.getMyServicePort();
  - 
  -    // Make the actual call
  -    String ret = port.serviceMethod(&quot;test string&quot;);
  -    System.out.println(&quot;Return val was &quot; + ret);
  -  }
  -} </pre>
  -<h4>Skeletons - frameworks for implementing Web Services</h4>
  -<p>Just as a stub is the client side of a Web Service represented in Java, a <b>skeleton</b> 
  -  is a Java framework for the server side. You'd want to make a skeleton if you 
  -  had a WSDL description of a service which you'd like to implement. For instance, 
  -  you might want to join a digital marketplace which requires you to make your 
  -  inventory available via a particular Web Service interface.</p>
  -<p>To make skeleton classes, you just specify the &quot;--skeleton&quot; option 
  -  to Wsdl2java. For instance, if we wanted to replicate the service in the last 
  -  example, we'd type:</p>
  -<pre>% java org.apache.axis.wsdl.Wsdl2java --skeleton http://localhost:8080/axis/services/MyService?wsdl</pre>
  -<p>There are a couple of classes produced by the skeleton generator, so let's 
  -  take a look at them:</p>
  +&nbsp; public static void main(String [] args) throws Exception
  +&nbsp; {
  +&nbsp;&nbsp;&nbsp; // Make a service (PortType factory)
  +&nbsp;&nbsp;&nbsp; MyService service = new MyService();
  +
  +
  +&nbsp;&nbsp;&nbsp; // Now use the service to get a PortType that we can call.
  +&nbsp;&nbsp;&nbsp; MyServicePortType port = service.getMyServicePort();
  +&nbsp;
  +&nbsp;&nbsp;&nbsp; // Make the actual call
  +&nbsp;&nbsp;&nbsp; String ret = port.serviceMethod("test string");
  +&nbsp;&nbsp;&nbsp; System.out.println("Return val was " + ret);
  +&nbsp; }
  +}</pre>
  +
  +<h4>
  +Skeletons - frameworks for implementing Web Services</h4>
  +Just as a stub is the client side of a Web Service represented in Java,
  +a <b>skeleton</b> is a Java framework for the server side. You'd want to
  +make a skeleton if you had a WSDL description of a service which you'd
  +like to implement. For instance, you might want to join a digital marketplace
  +which requires you to make your inventory available via a particular Web
  +Service interface.
  +<p>To make skeleton classes, you just specify the "--skeleton" option to
  +WSDL2Java. For instance, if we wanted to replicate the service in the last
  +example, we'd type:
  +<pre>% java org.apache.axis.wsdl.WSDL2Java --skeleton http://localhost:8080/axis/services/MyService?wsdl</pre>
  +There are a couple of classes produced by the skeleton generator, so let's
  +take a look at them:
   <ul>
  -  <li>The Skeleton proper (in our example, <b>MyServiceSoapBindingSkeleton</b>) 
  -    is the class you'll actually deploy as an Axis service. You won't need to 
  -    edit the code in here at all.</li>
  -  <li>The Implementation class (<b>MyServiceSoapBindingImpl</b>) is the actual 
  -    framework class which you'll flesh out with your own code.</li>
  +<li>
  +The Skeleton proper (in our example, <b>MyServiceSoapBindingSkeleton</b>)
  +is the class you'll actually deploy as an Axis service. You won't need
  +to edit the code in here at all.</li>
  +
  +<li>
  +The Implementation class (<b>MyServiceSoapBindingImpl</b>) is the actual
  +framework class which you'll flesh out with your own code.</li>
   </ul>
  -The tool also builds you a &quot;deploy.wsdd&quot; and an &quot;undeploy.wsdd&quot; 
  -for use with the AdminClient. These files may be used to deploy the service once 
  -you've filled in the methods of the Implementation class, compiled the code, and 
  -made the classes available to your Axis engine. 
  -<h4>Data Types for Stubs and Skeletons</h4>
  -<h3></h3>
  -<p>WSDL files can contain (or reference) XML Schema describing the data types 
  -  used by particular operations. As we've seen, Axis needs to do some work to 
  -  map schema types to Java types, and this remains true whether we code the Java 
  -  by hand or generate it with a tool. When you use Wsdl2java to generate either 
  -  stubs or skeletons for operations which contain complex types, you will notice 
  -  that Java classes corresponding to the XML data types are also generated. For 
  -  the stub, the code inside the stub handles setting up the type mapping in Axis 
  -  - and for the skeleton, the type mappings are included in the generated &quot;deploy.wsdd&quot; 
  -  file. </p>
  -<h5>Holders</h5>
  -<p>You'll notice that for each data class that Wsdl2java generates, there is a 
  -  corresponding &quot;Holder&quot; class - for instance a class called &quot;MyDataType&quot; 
  -  would also get a companion class &quot;MyDataTypeHolder&quot;. These classes 
  -  exist so that we have a reasonably clean mapping for WSDL's in/out and out parameters 
  -  in Java. See the examples for more details.</p>
  -<h4>Wsdl2java details</h4>
  +The tool also builds you a "deploy.wsdd" and an "undeploy.wsdd" for use
  +with the AdminClient. These files may be used to deploy the service once
  +you've filled in the methods of the Implementation class, compiled the
  +code, and made the classes available to your Axis engine.
  +<h4>
  +Data Types for Stubs and Skeletons</h4>
  +WSDL files can contain (or reference) XML Schema describing the data types
  +used by particular operations. As we've seen, Axis needs to do some work
  +to map schema types to Java types, and this remains true whether we code
  +the Java by hand or generate it with a tool. When you use WSDL2Java to
  +generate either stubs or skeletons for operations which contain complex
  +types, you will notice that Java classes corresponding to the XML data
  +types are also generated. For the stub, the code inside the stub handles
  +setting up the type mapping in Axis - and for the skeleton, the type mappings
  +are included in the generated "deploy.wsdd" file.
  +<h5>
  +Holders</h5>
  +You'll notice that for each data class that Wsdl2java generates, there
  +is a corresponding "Holder" class - for instance a class called "MyDataType"
  +would also get a companion class "MyDataTypeHolder". These classes exist
  +so that we have a reasonably clean mapping for WSDL's in/out and out parameters
  +in Java. See the examples for more details.
  +<h4>
  +Wsdl2java details</h4>
   Wsdl2java has a number of options, some of which have already been detailed.
   <p>Usage:&nbsp; java org.apache.axis.wsdl.Wsdl2java [options] WSDL-URI
   <br>Options:
  @@ -613,18 +742,17 @@
   emit a MessageContext parameter to skeleton methods
   <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -N, --NStoPkg &lt;argument>=&lt;value>
   <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  -mapping of namespace to package
  -&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; -p, --package &lt;argument&gt;<br>
  -&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
  -override all namespace to package mappings, use this package name instead<br>
  -<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -o, --output &lt;argument>
  +mapping of namespace to package&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-p, --package &lt;argument>
   <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +override all namespace to package mappings, use this package name instead
  +<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -o, --output &lt;argument>
  +<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
   output directory for emitted files
   <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -d, --deployScope &lt;argument>
  -<br>
  -  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  -  add scope to deploy.wsdd: "Application", "Request", "Session" <br>
  -  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -t, --testCase
  +<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +add scope to deploy.wsdd: "Application", "Request", "Session"
  +<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -t, --testCase
   <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
   emit junit testcase class for web service
   <br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -n, --noImports
  @@ -668,20 +796,21 @@
   <p>If an entry for a given mapping exists both on the command line and
   in the properties file, the command line entry takes precedence.
   <h5>
  --p, --package &lt;argument&gt;</h5>
  -This is a shorthand option to map all namespaces in a WSDL document to the
  -same Java package name. &nbsp;This can be useful, but dangerous. &nbsp;You
  -must make sure that you understand the effects of doing this. &nbsp;For instance
  -there may be multiple types with the same name in different namespaces. &nbsp;It
  -is an error to use the --NStoPkg switch and --package at the same time.<br>
  +-p, --package &lt;argument></h5>
  +This is a shorthand option to map all namespaces in a WSDL document to
  +the same Java package name.&nbsp; This can be useful, but dangerous.&nbsp;
  +You must make sure that you understand the effects of doing this.&nbsp;
  +For instance there may be multiple types with the same name in different
  +namespaces.&nbsp; It is an error to use the --NStoPkg switch and --package
  +at the same time.
   <h5>
   -o, --output &lt;argument></h5>
   The root directory for all emitted files.
   <h5>
   -d, --deployScope &lt;argument></h5>
  -Add scope to deploy.wsdd: "Application", "Request", or "Session".&nbsp; If this 
  -option does not appear, no scope tag appears in deploy.wsdd, which the AXIS runtime 
  -defaults to "Request". 
  +Add scope to deploy.wsdd: "Application", "Request", or "Session".&nbsp;
  +If this option does not appear, no scope tag appears in deploy.wsdd, which
  +the AXIS runtime defaults to "Request".
   <h5>
   -t, --testCase</h5>
   Generate a client-side JUnit test case.
  @@ -690,49 +819,296 @@
   Only generate code for the WSDL document that appears on the command line.&nbsp;
   The default behaviour is to generate files for all WSDL documents, the
   immediate one and all imported ones.
  +<h3>
  +<a NAME="Java2WSDL: Building WSDL from Java"></a>Java2WSDL: Building WSDL
  +from Java</h3>
  +The Java2WSDL and WSDL2Java emitters make it easy to develop a new web
  +service.
  +<br>The following sections describe the steps in building a web service
  +from a Java interface.
  +<br>&nbsp;
  +<h4>
  +Step 1: Provide a Java interface</h4>
  +Write and compile a Java interface that describes the web service interface.&nbsp;
  +Here is an example interface that describes a web services that can be
  +used to set/query the price of widgets ( <a href="../samples/userguide/example6/WidgetPrice.java">../samples/userguide/example6/WidgetPrice.java</a>
  +):
  +<p><tt><font color="#006600">package samples.userguide.example6;</font></tt>
  +<p><tt><font color="#006600">/**</font></tt>
  +<br><tt><font color="#006600">&nbsp;* Interface describing a web service
  +to set and get Widget prices.</font></tt>
  +<br><tt><font color="#006600">&nbsp;**/</font></tt>
  +<br><tt><font color="#006600">public interface WidgetPrice</font></tt>
  +<br><tt><font color="#006600">{</font></tt>
  +<br><tt><font color="#006600">&nbsp;&nbsp;&nbsp; public void setWidgetPrice(String
  +widgetName, String price);</font></tt>
  +<br><tt><font color="#006600">&nbsp;&nbsp;&nbsp; public String getWidgetPrice(String
  +widgetName);</font></tt>
  +<br><tt><font color="#006600">}</font></tt>
  +<br>&nbsp;
  +<h4>
  +Step 2: Create WSDL using Java2WSDL</h4>
  +Use the Java2WSDL tool to create a WSDL file from the interface above.
  +<p>Here is an example invocation that produces the wsdl file (<tt>wp.wsdl</tt>)
  +from the interface described in the previous section:
  +<p><tt><font color="#009900">java org.apache.axis.wsdlgen.Java2WSDL -o
  +wp.wsdl -l"http://localhost:8080/axis/services/WidgetPrice" -n "urn:Example6"
  +-p"samples.userguide.example6" "urn:Example6"&nbsp; samples.userguide.example6.WidgetPrice</font></tt>
  +<p>Where:
  +<ul>
  +<li>
  +-o indicates the name of the <b><i>output wsdl</i></b> file</li>
  +
  +<li>
  +-l indicates the<b><i> location of the service</i></b></li>
   
  -<a name="tcpmon"></a><h2>Using the Axis TCP Monitor (tcpmon) </h2>
  -<p>The included &quot;tcpmon&quot; utility can be found in the org.apache.axis.utils 
  -  package. To run it from the command line:</p>
  +<li>
  +-n is the target <b><i>namespace</i></b> of the wsdl file</li>
  +
  +<li>
  +-p indicates a mapping from the <b><i>package to a namespace</i></b>.&nbsp;
  +There may be multiple mappings.</li>
  +
  +<li>
  +the class specified contains the interface of the webservice.</li>
  +</ul>
  +The output wsld document will contain the appropriate wsdl types, messages,
  +portType, bindings and service descriptions to support a SOAP rpc, encoding
  +web service.&nbsp; If your specified interface methods reference other
  +classes, the Java2WSDL tool will generate the appropriate xml types to
  +represent the classes and any nested/inherited types.&nbsp; The tool supports
  +JAX-RPC complex types (bean classes), extension classes, enumeration classes,
  +arrays and Holder classes.
  +<p>The Java2WSDL tool has many additional options which are detailed in
  +the next section.
  +<h5>
  +<a NAME="Java2WSDL Details"></a>Java2WSDL Details</h5>
  +Here is the help message generated from the current tool:
  +<p><tt><font color="#993366">Usage: java org.apache.axis.wsdlgen.Java2WSDL
  +[options] class-of-portType</font></tt>
  +<br><tt><font color="#993366">Options:</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-h, --help</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +print this message and exit</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-o, --output &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +output Wsdl filename</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-l, --location &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +service location url</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-s, --service &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +service name (obtained from --location if not specified)</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-n, --namespace &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +target namespace</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-p, --PkgtoNS &lt;argument>=&lt;value></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +package=namespace, name value pairs</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-m, --methods &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +space separated list of methods to export</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-a, --all</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +look for allowed methods in inherited class</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-w, --outputWsdlMode &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +output WSDL mode: All, Interface, Implementation</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-L, --locationImport &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +location of interface wsdl</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-N, --namespaceImpl &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +target namespace for implementation wsdl</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +-O, --outputImpl &lt;argument></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +output Implementation Wsdl filename, setting this causes --o</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +utputWsdlMode to be ignored</font></tt>
  +<br><tt><font color="#993366">Details:</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +portType&nbsp;&nbsp;&nbsp; name= &lt;class-of-portType name></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +binding&nbsp;&nbsp;&nbsp;&nbsp; name= &lt;--service value>SoapBinding</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +service&nbsp;&nbsp;&nbsp;&nbsp; name= &lt;--service value>Service</font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +port&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; name= &lt;--service value></font></tt>
  +<br><tt><font color="#993366">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  +address location= &lt;--location value></font></tt>
  +<p><b>-h , --help</b>
  +<br>Prints the help message.
  +<p><b>-o, --output &lt;wsdl file></b>
  +<br>Indicates the name of the output wsdl file.&nbsp; If not specified,
  +a suitable default wsdl file is written into the current directory.
  +<p><b>-l, --location &lt;location></b>
  +<br>Indicates the url of the location of the service.&nbsp; The name after
  +the last slash or backslash is the name of the service port (unless overriden
  +by the -s option).&nbsp; The service port address location attributed is
  +assigned the specified value.
  +<p><b>-s, -service &lt;name></b>
  +<br>Indicates the name of the service.&nbsp; If not specified, the service
  +name is derived from the --location value.&nbsp; The names of the wsdl
  +binding, service, and port elements are derived from the service name as
  +indicated in the <tt><font color="#993366">Details</font></tt> section
  +above.
  +<p><b>-n, --namespace &lt;target namespace></b>
  +<br>Indicates the name of the target namespace of the wsdl.
  +<p><b>-p, --PkgToNS &lt;package> &lt;namespace></b>
  +<br>Indicates the mapping of a package to a namespace.&nbsp; If a package
  +is encountered that does not have a namespace, the Java2WSDL emitter will
  +generate a suitable namespace name.&nbsp; This option may be specified
  +multiple times.
  +<p><b>-m, --methods &lt;arguments></b>
  +<br>If this option is specified, only the indicated methods in your interface
  +class will be exported into the wsdl file.&nbsp; The methods list must
  +be comma separated.&nbsp; If not specified, all methods declared in the
  +interface class will be exported into the wsdl file.
  +<p><b>-a, --all</b>
  +<br>If this option is specified, the Java2WSDL parser will look into extended
  +classes to determine the list of methods to export into the wsdl file.
  +<p><b>-w, --outputWSDLMode &lt;mode></b>
  +<br>Indicates the kind of wsdl to generate.&nbsp; Accepted values are:
  +<ul>
  +<li>
  +All --- (default) Generates wsld containing both interface and implementation
  +wsdl constructs.</li>
  +
  +<li>
  +Interface --- Generates a wsdl containing the interface constructs (no
  +service element).</li>
  +
  +<li>
  +Implementation -- Generates a wsdl containing the implementation.&nbsp;
  +The interface wsdl is imported via the -L option.</li>
  +</ul>
  +<b>-L, --locationImport &lt;url></b>
  +<br>Used to indicate the location of the interface wsdl when generating
  +an implementation wsdl.
  +<p><b>-N, --namespaceImpl &lt;namespace></b>
  +<br>Namespace of the implementation wsdl.
  +<p><b>-O, --outputImpl &lt;wsdl file></b>
  +<br>Use this option to indicate the name of the output implementation wsdl
  +file.&nbsp; If specified, Java2WSDL will produce interface and implementation
  +wsdl files.&nbsp; If this option is used, the -w option is ignored.
  +<br>&nbsp;
  +<h4>
  +Step 3: Create Bindings using WSDL2Java</h4>
  +Use the generated wsdl file to build the appropriate client/server bindings
  +for the web service (see <a href="#WSDL2Java: Building stubs, skeletons, and data">WSDL2Java</a>):
  +<p>&nbsp;<tt><font color="#009900">java org.apache.axis.wsdl.Wsdl2java
  +-o . -d session -s -Nurn:Example6 samples.userguide.example6 ws.wsdl</font></tt>
  +<p>This will generate the following files:
  +<ul>
  +<li>
  +<b><tt>WidgetPriceSoapBindingImpl.java</tt></b> : Java file containing
  +the default server implementation of the WidgetPrice web service.</li>
  +
  +<br>You will need to modify the *SoapBindingImpl file to add your implementation
  +(see&nbsp; <a href="../samples/userguide/example6/WidgetPriceSoapBindingImpl.java">../samples/userguide/example6/WidgetPriceSoapBindingImpl.java</a>
  +).
  +<li>
  +<b><tt>WidgetPrice.java</tt></b>:&nbsp; New interface file that contains
  +the appropriate <b><tt>java.rmi.Remote</tt></b> usages.</li>
  +
  +<li>
  +<b><tt>WidgetPriceService.java</tt></b>: Java file containing the client
  +side service class.</li>
  +
  +<li>
  +<b><tt>WidgetPriceSoapBindingSkeleton.java</tt></b>: Server side skeleton.</li>
  +
  +<li>
  +<b><tt>WidgetPriceSoapBindingStub.java</tt></b>: Client side stub.</li>
  +
  +<li>
  +<b><tt>deploy.xml</tt></b>: Deployment descriptors</li>
  +
  +<li>
  +<b><tt>undeploy.xml</tt></b>: Undeploy descriptors</li>
  +
  +<li>
  +(data types):&nbsp; Java files will be produced for all of the other types
  +and holders necessary for the web service.&nbsp; There are no additional
  +files for the WidgetPrice web service.</li>
  +</ul>
  +Now you have all of the necessary files to build your client/server side
  +code and deploy the web service!
  +<h2>
  +<a NAME="tcpmon"></a>Using the Axis TCP Monitor (tcpmon)</h2>
  +The included "tcpmon" utility can be found in the org.apache.axis.utils
  +package. To run it from the command line:
   <pre>% java org.apache.axis.utils.tcpmon [listenPort targetHost targetPort]</pre>
  -<p>Without any of the optional arguments, you will get a gui which looks like this:</p>
  -<p align="center"><img src="tcpmon1.jpg" width="599" height="599"></p>
  -<p align="left">To use the program, you should select a local port which tcpmon 
  -  will monitor for incoming connections, a target host where it will forward such 
  -  connections, and the port number on the target machine which should be &quot;tunneled&quot; 
  -  to. Then click &quot;add&quot;. You should then notice another tab appearing 
  -  in the window for your new tunneled connection. Looking at that panel, you'll 
  -  see something like this:</p>
  -<p align="center"><img src="tcpmon2.jpg" width="599" height="600"></p>
  -<p align="left">Now each time a SOAP connection is made to the local port, you 
  -  will see the request appear in the &quot;Request&quot; panel, and the response 
  -  from the server in the &quot;Response&quot; panel. Tcpmon keeps a log of all 
  -  request/response pairs, and allows you to view any particular pair by selecting 
  -  an entry in the top panel. You may also remove selected entries, or all of them, 
  -  or choose to save to a file for later viewing.</p>
  -<p align="left">The &quot;resend&quot; button will resend the request you are 
  -  currently viewing, and record a new response. This is particularly handy in 
  -  that you can edit the XML in the request window before resending - so you can 
  -  use this as a great tool for testing the effects of different XML on SOAP servers.</p>
  +Without any of the optional arguments, you will get a gui which looks like
  +this:
  +<center>
  +<p><img SRC="tcpmon1.jpg" height=599 width=599></center>
  +
  +<p>To use the program, you should select a local port which tcpmon will
  +monitor for incoming connections, a target host where it will forward such
  +connections, and the port number on the target machine which should be
  +"tunneled" to. Then click "add". You should then notice another tab appearing
  +in the window for your new tunneled connection. Looking at that panel,
  +you'll see something like this:
  +<center>
  +<p><img SRC="tcpmon2.jpg" height=600 width=599></center>
  +
  +<p>Now each time a SOAP connection is made to the local port, you will
  +see the request appear in the "Request" panel, and the response from the
  +server in the "Response" panel. Tcpmon keeps a log of all request/response
  +pairs, and allows you to view any particular pair by selecting an entry
  +in the top panel. You may also remove selected entries, or all of them,
  +or choose to save to a file for later viewing.
  +<p>The "resend" button will resend the request you are currently viewing,
  +and record a new response. This is particularly handy in that you can edit
  +the XML in the request window before resending - so you can use this as
  +a great tool for testing the effects of different XML on SOAP servers.
   <dl>
  -  <dt> </dt>
  +<dt>
  +</dt>
   </dl>
  -<a name="Glossary"></a><h2>Glossary</h2>
  -<dl> 
  -  <dt><i>Handler</i>
  -  <dd>&lt;definition&gt; 
  -  <dt>
  -  <dt><i>SOAP</i>
  -  <dd>The Simple Object Access Protocol (yes, despite the fact that it sometimes 
  -    doesn't seem so simple, and doesn't have anything to do with objects... :)). 
  -    You can read the SOAP 1.1 specification at <a href="http://www.w3.org/TR/SOAP">http://www.w3.org/TR/SOAP</a>. 
  -    The W3C is currently in the midst of work on SOAP 1.2, under the auspices 
  -    of the <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Group</a>. 
  -  <dt>
  -  <dt><i>Provider</i>
  -  <dd>&lt;definition&gt; 
  -  <dt>
  -  <dt><i></i></dt>
  +<a NAME="Glossary"></a>
  +<h2>
  +Glossary</h2>
  +
  +<dl>
  +<dt>
  +<i>Handler</i></dt>
  +
  +<dd>
  +&lt;definition></dd>
  +
  +<dt>
  +<i>SOAP</i></dt>
  +
  +<dd>
  +The Simple Object Access Protocol (yes, despite the fact that it sometimes
  +doesn't seem so simple, and doesn't have anything to do with objects...
  +:)). You can read the SOAP 1.1 specification at <a href="http://www.w3.org/TR/SOAP">http://www.w3.org/TR/SOAP</a>.
  +The W3C is currently in the midst of work on SOAP 1.2, under the auspices
  +of the <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Group</a>.</dd>
  +
  +<dt>
  +<i>Provider</i></dt>
  +
  +<dd>
  +&lt;definition></dd>
  +
  +<dt>
  +</dt>
   </dl>
  +
   </body>
   </html>
  
  
  

Mime
View raw message