axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From gdani...@apache.org
Subject cvs commit: xml-axis/java/docs reference.html integration-guide.html user-guide.html
Date Thu, 13 Dec 2001 05:10:57 GMT
gdaniels    01/12/12 21:10:57

  Modified:    java/docs integration-guide.html user-guide.html
  Added:       java/docs reference.html
  Log:
  Start of documentation revamp.  Split out reference materials into separate
  doc, and move architectural overview into integration guide.
  
  More to come...
  
  Revision  Changes    Path
  1.2       +77 -0     xml-axis/java/docs/integration-guide.html
  
  Index: integration-guide.html
  ===================================================================
  RCS file: /home/cvs/xml-axis/java/docs/integration-guide.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- integration-guide.html	2001/11/05 14:09:02	1.1
  +++ integration-guide.html	2001/12/13 05:10:57	1.2
  @@ -46,6 +46,83 @@
   <h2>
   <a NAME="Architectural Overview"></a>Architectural Overview</h2>
   &nbsp;
  +<p>Axis consists of several subsystems working together. In this section we'll 
  +  give you an overview of how the package works, but for more details please see 
  +  the Axis Architecture Guide, a separate document.</p>
  +<h3>Handlers and the Message Path in Axis</h3>
  +<p>Put simply, Axis is all about processing Messages. When the central Axis processing

  +  logic runs, a series of <b>Handlers</b> are each invoked in order. The particular

  +  oder is determined by two factors - deployment configuration and whether the 
  +  engine is a client or a server. The object which is passed to each Handler invocation

  +  is a <b>MessageContext</b>. A MessageContext is a structure which contains
several 
  +  important parts: 1) a &quot;request&quot; message, 2) a &quot;response&quot;

  +  message, and 3) a bag of properties. We'll go into a little more detail on this 
  +  in a bit.</p>
  +<p>There are two basic ways which Axis is invoked:</p>
  +<ol>
  +  <li>As a <b>server</b>, a <b>Transport Listener</b> will
create a MessageContext 
  +    and invoke the Axis processing framework.</li>
  +  <li>As a <b>client</b>, application code (aided in most cases by the
client 
  +    programming model of Axis) will generate a MessageContext and invoke the Axis 
  +    processing framework.</li>
  +</ol>
  +<p>In either case, the Axis framework's job is simply to pass the resulting MessageContext

  +  through a configurable set of Handlers, each of which has an opportunity to 
  +  do whatever it is designed to do with the MessageContext. The message path (for 
  +  the server side) looks like this:</p>
  +<p><img src="ServerMessagePath.jpg" width="720" height="540"></p>
  +<p>(In the diagram above, each of the small cylinders represents a Handler.)</p>
  +<p>A message arrives (in some protocol-specific manner) at a Transport Listener.

  +  Let's posit that in this case it's an HTTP servlet. It's the Listener's job 
  +  to package the protocol-specific data into a <b>Message</b> object (org.apache.axis.Message),

  +  and put the Message into a <b>MessageContext</b>. The MessageContext is also

  +  loaded with various <b>properties</b> by the Listener - in this case, an
example 
  +  would be setting the property &quot;http.SOAPAction&quot; to the value of the

  +  SOAPAction HTTP header. The Transport Listener also sets the <b>transportName</b>

  +  String on the MessageContext - in this case we set it to &quot;http&quot;. Once

  +  the MessageContext is ready to go, the Listener hands it into the AxisEngine.</p>
  +<p>The AxisEngine's first job is to look up the transport by name. This will result

  +  in an object which contains a <b>request</b> flow, a <b>response</b>
flow, or 
  +  perhaps both. If a transport request flow exists, it will be invoked, passing 
  +  the MessageContext into the invoke() method. This will result in calling all 
  +  the Handlers specified in the request flow configuration.</p>
  +<p>After the transport request handler, the engine locates a global request flow,

  +  if configured (in the &lt;requestFlow&gt; element of the WSDD &lt;globalConfiguration&gt;,

  +  as explained in the WSDD deployment section later in this document), and then 
  +  invokes any Handlers specified therein.</p>
  +<p>At some point during the processing up until now, some Handler has hopefully 
  +  set the <b>serviceHandler</b> field of the MessageContext (this is usually
done 
  +  in the HTTP transport by the &quot;URLMapper&quot; Handler, which maps a URL

  +  like &quot;http://localhost/axis/services/AdminService&quot; to the &quot;AdminService&quot;

  +  service). This field determines the Handler we'll invoke to execute service-specific

  +  functionality, such as making an RPC call on a back-end object. Services in 
  +  Axis are typically instances of the &quot;SOAPService&quot; class (org.apache.axis.handlers.soap.SOAPService),

  +  which may contain <b>request</b> and <b>response</b> flows (similar
to what 
  +  we saw at the transport and global levels), and must contain a <b>provider</b>,

  +  which is simply a Handler responsible for implementing the actual back end logic 
  +  of the service.</p>
  +<p>In typical RPC examples, the provider is the org.apache.axis.providers.java.RPCProvider

  +  class. This is just another Handler that, when invoked, attempts to call a backend 
  +  Java object whose class is determined by the &quot;className&quot; parameter

  +  specified at deployment time. It uses the SOAP RPC convention for determining 
  +  the method to call, and makes sure the types of the incoming XML-encoded arguments 
  +  match the types of the required parameters of the resulting method.</p>
  +<h3>The Message Path on the Client</h3>
  +<p>The Message Path on the client side is similar, except the order of scoping 
  +  is reversed. In other words:</p>
  +<p>The <b>service</b> handler, if any, is called first - on the client
side, there 
  +  is no &quot;provider&quot; since the service is being provided by a remote node,

  +  but there is still the possibility of request and response flows. The service 
  +  request and response flows serve to do any service-specific processing of the 
  +  message on its way out of the system, and also for the response message on its 
  +  way back to the caller.</p>
  +<p>After the service request flow, the global requestFlow, if any, is invoked, 
  +  followed by the transport. The <b>Transport Sender</b>, a special Handler
whose 
  +  job it is to actually perform whatever protocol-specific operations are necessary 
  +  to get the message to and from the target SOAP server, is invoked to send the 
  +  message. The response (if any) is placed into the responseMessage field of the 
  +  MessageContext, and the MessageContext then propagates back up through the response 
  +  flows - first the transport, then the global, and finally the service.</p>
   <h2>
   <a NAME="Pluggable APIs"></a>Pluggable APIs</h2>
   The following are the points that are pluggable in order to integrate AXIS
  
  
  
  1.29      +2 -235    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.28
  retrieving revision 1.29
  diff -u -r1.28 -r1.29
  --- user-guide.html	2001/12/04 19:47:54	1.28
  +++ user-guide.html	2001/12/13 05:10:57	1.29
  @@ -22,13 +22,11 @@
   <h3>Table of Contents</h3>
   <p><A href="#Introduction">Introduction</a><br>
     <A href="#Installation">Installing Axis</a><br>
  -  <A href="#Architecture">Axis Architecture - a Brief Primer</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="#DeploymentReference">Deployment Reference</a><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

  @@ -111,86 +109,7 @@
     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="Architecture"></a>Axis Architecture - a Brief Primer</h2>
  -<p>(Skip this section if you want to dive right in - in many cases using the basic

  -  features of Axis requires zero knowledge of these topics.)</p>
  -<p>Axis consists of several subsystems working together. In this section we'll 
  -  give you an overview of how the package works, but for more details please see 
  -  the Axis Architecture Guide, a separate document.</p>
  -<h3>Handlers and the Message Path in Axis</h3>
  -<p>Put simply, Axis is all about processing Messages. When the central Axis processing

  -  logic runs, a series of <b>Handlers</b> are each invoked in order. The particular

  -  oder is determined by two factors - deployment configuration and whether the 
  -  engine is a client or a server. The object which is passed to each Handler invocation

  -  is a <b>MessageContext</b>. A MessageContext is a structure which contains
several 
  -  important parts: 1) a &quot;request&quot; message, 2) a &quot;response&quot;

  -  message, and 3) a bag of properties. We'll go into a little more detail on this 
  -  in a bit.</p>
  -<p>There are two basic ways which Axis is invoked:</p>
  -<ol>
  -  <li>As a <b>server</b>, a <b>Transport Listener</b> will
create a MessageContext 
  -    and invoke the Axis processing framework.</li>
  -  <li>As a <b>client</b>, application code (aided in most cases by the
client 
  -    programming model of Axis) will generate a MessageContext and invoke the Axis 
  -    processing framework.</li>
  -</ol>
  -<p>In either case, the Axis framework's job is simply to pass the resulting MessageContext

  -  through a configurable set of Handlers, each of which has an opportunity to 
  -  do whatever it is designed to do with the MessageContext. The message path (for 
  -  the server side) looks like this:</p>
  -<p><img src="ServerMessagePath.jpg" width="720" height="540"></p>
  -<p>(In the diagram above, each of the small cylinders represents a Handler.)</p>
  -<p>A message arrives (in some protocol-specific manner) at a Transport Listener.

  -  Let's posit that in this case it's an HTTP servlet. It's the Listener's job 
  -  to package the protocol-specific data into a <b>Message</b> object (org.apache.axis.Message),

  -  and put the Message into a <b>MessageContext</b>. The MessageContext is also

  -  loaded with various <b>properties</b> by the Listener - in this case, an
example 
  -  would be setting the property &quot;http.SOAPAction&quot; to the value of the

  -  SOAPAction HTTP header. The Transport Listener also sets the <b>transportName</b>

  -  String on the MessageContext - in this case we set it to &quot;http&quot;. Once

  -  the MessageContext is ready to go, the Listener hands it into the AxisEngine.</p>
  -<p>The AxisEngine's first job is to look up the transport by name. This will result

  -  in an object which contains a <b>request</b> flow, a <b>response</b>
flow, or 
  -  perhaps both. If a transport request flow exists, it will be invoked, passing 
  -  the MessageContext into the invoke() method. This will result in calling all 
  -  the Handlers specified in the request flow configuration.</p>
  -<p>After the transport request handler, the engine locates a global request flow,

  -  if configured (in the &lt;requestFlow&gt; element of the WSDD &lt;globalConfiguration&gt;,

  -  as explained in the WSDD deployment section later in this document), and then 
  -  invokes any Handlers specified therein.</p>
  -<p>At some point during the processing up until now, some Handler has hopefully 
  -  set the <b>serviceHandler</b> field of the MessageContext (this is usually
done 
  -  in the HTTP transport by the &quot;URLMapper&quot; Handler, which maps a URL

  -  like &quot;http://localhost/axis/services/AdminService&quot; to the &quot;AdminService&quot;

  -  service). This field determines the Handler we'll invoke to execute service-specific

  -  functionality, such as making an RPC call on a back-end object. Services in 
  -  Axis are typically instances of the &quot;SOAPService&quot; class (org.apache.axis.handlers.soap.SOAPService),

  -  which may contain <b>request</b> and <b>response</b> flows (similar
to what 
  -  we saw at the transport and global levels), and must contain a <b>provider</b>,

  -  which is simply a Handler responsible for implementing the actual back end logic 
  -  of the service.</p>
  -<p>In typical RPC examples, the provider is the org.apache.axis.providers.java.RPCProvider

  -  class. This is just another Handler that, when invoked, attempts to call a backend 
  -  Java object whose class is determined by the &quot;className&quot; parameter

  -  specified at deployment time. It uses the SOAP RPC convention for determining 
  -  the method to call, and makes sure the types of the incoming XML-encoded arguments 
  -  match the types of the required parameters of the resulting method.</p>
  -<h3>The Message Path on the Client</h3>
  -<p>The Message Path on the client side is similar, except the order of scoping 
  -  is reversed. In other words:</p>
  -<p>The <b>service</b> handler, if any, is called first - on the client
side, there 
  -  is no &quot;provider&quot; since the service is being provided by a remote node,

  -  but there is still the possibility of request and response flows. The service 
  -  request and response flows serve to do any service-specific processing of the 
  -  message on its way out of the system, and also for the response message on its 
  -  way back to the caller.</p>
  -<p>After the service request flow, the global requestFlow, if any, is invoked, 
  -  followed by the transport. The <b>Transport Sender</b>, a special Handler
whose 
  -  job it is to actually perform whatever protocol-specific operations are necessary 
  -  to get the message to and from the target SOAP server, is invoked to send the 
  -  message. The response (if any) is placed into the responseMessage field of the 
  -  MessageContext, and the MessageContext then propagates back up through the response 
  -  flows - first the transport, then the global, and finally the service.</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>

  @@ -771,159 +690,7 @@
   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.
  -<h2><a name="DeploymentReference"></a>Deployment Reference</h2>
  -Note : all the elements referred to in this section are in the WSDD namespace, 
  -namely &quot;http://wsdd&quot;. 
  -<dl> 
  -  <dt><b><font face="Courier New, Courier, mono">&lt;deployment&gt;</font></b></dt>
  -  <dd>The root element of the deployment document which tells the Axis engine 
  -    that this is a deployment. Must be in the &quot;AdminService&quot; namespace.</dd>
  -  <dt>&nbsp;</dt>
  -  <dt><b><font face="Courier New, Courier, mono">&lt;undeployment&gt;</font></b></dt>
  -  <dd>The root element of the deployment document which tells Axis that this is 
  -    an undeployment. Must be in the &quot;AdminService&quot; namespace.</dd>
  -  <dt>&nbsp;</dt>
  -  <dt><b><font face="Courier New, Courier, mono">&lt;handler name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    type=&quot;</font></b><font face="Courier New, Courier, mono"><i>type</i></font><b><font
face="Courier New, Courier, mono">&quot;/&gt;</font></b></dt>
  -  <dd>Belongs inside a deploy or undeploy. Names a Handler, and indicates the 
  -    class which corresponds to the name. May contain an arbitrary number of <b><font
face="Courier New, Courier, mono">&lt;option 
  -    name=&quot;</font></b><font face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    value=&quot;</font></b><font face="Courier New, Courier, mono"><i>value</i></font><b><font
face="Courier New, Courier, mono">&quot;&gt;</font></b> 
  -    elements, each of which will supply an option to the deployed Handler.</dd>
  -  <dt>&nbsp;</dt>
  -  <dt><b><font face="Courier New, Courier, mono">&lt;service name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    provider=&quot;</font></b><font face="Courier New, Courier, mono"><i>provider</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    &gt;</font></b></dt>
  -  <dd>Deploys/undeploys an Axis Service. Common options for this element (i.e. 
  -    subelements of the form <code><b>&lt;parameter name=&quot;</b>name<b>&quot;

  -    value=&quot;</b>value<b>&quot;/&gt;</b>)</code>
include:<br>
  -    <b>className</b> : the backend implementation class<br>
  -    <b>methodName</b> : the allowed methods<br>
  -    <b>allowedRoles</b> : comma-separated list of roles allowed to access this

  -    service<br>
  -    <br>
  -    If you wish to define handlers which should be invoked either before or after 
  -    the service's provider, you may do so with the <b>&lt;requestFlow&gt;</b>

  -    and the <b>&lt;responseFlow&gt;</b> subelements. Either of those
elements 
  -    may be specified inside the <b>&lt;service&gt;</b> element, and
their semantics 
  -    are identical to the <b>&lt;chain&gt;</b> element described below
- in other 
  -    words, they may contain <b>&lt;handler&gt;</b> and <b>&lt;chain</b>&gt;
elements 
  -    which will be invoked in the order they are specified.</dd>
  -  <dt><b><br>
  -    <font face="Courier New, Courier, mono">&lt;chain name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot;</font></b><b><font face="Courier
New, Courier, mono">&gt;<br>
  -    &lt;<i>subelement</i>/&gt;...<br>
  -    &lt;/chain&gt; </font></b></dt>
  -  <dd>Defines a chain. Each <i>handler</i> (i.e. deployed handler name)
in the 
  -    list will be invoked() in turn when the chain is invoked. This enables you 
  -    to build up &quot;modules&quot; of commonly used functionality. The subelements

  -    inside chains may be &lt;<b>handler</b>&gt;s or &lt;<b>chain</b>&gt;s.
&lt;handler&gt;s 
  -    inside a &lt;chain&gt; may either be defined in terms of their Java class:<br>
  -    <pre>&lt;chain name=&quot;myChain&quot;&gt;
  -  &lt;handler type=&quot;java:org.apache.axis.handlers.LogHandler&quot;/&gt;
  -&lt;/chain&gt;</pre>
  -    or may refer to previously defined &lt;handlers&gt;, with the &quot;type&quot;

  -    of the handler referring to the name of the other handler definition:<br>
  -    <pre>&lt;handler name=&quot;logger&quot; type=&quot;java:org.apache.axis.handlers.LogHandler&quot;/&gt;<br>&lt;chain
name=&quot;myChain&quot;/&gt;<br>   &lt;handler type=&quot;logger&quot;/&gt;<br>&lt;/chain&gt;</pre>
  -  </dd>
  -  <dt><b><font face="Courier New, Courier, mono">&lt;transport name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot;&gt;</font></b></dt>
  -  <dd>Defines a transport on the server side. Server transports are invoked when

  -    an incoming request arrives. A server transport may define <b>&lt;requestFlow&gt;</b>

  -    and/or <b>&lt;responseFlow&gt;</b> elements to specify handlers/chains
which 
  -    should be invoked during the request (i.e. incoming message) or response (i.e. 
  -    outgoing message) portion of processing (this function works just like the 
  -    <b>&lt;service&gt;</b> element above). Typically handlers in the
transport 
  -    request/response flows implement transport-specific functionality, such as 
  -    parsing protocol headers, etc.</dd>
  -  <dt>&nbsp;</dt>
  -  <dt><b><font face="Courier New, Courier, mono">&lt;transport name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    pivot=&quot;</font></b><font face="Courier New, Courier, mono"><i>handler

  -    type</i><b>&quot;</b></font><b><font face="Courier
New, Courier, mono"> &gt;</font></b></dt>
  -  <dd>Defines a transport on the client side, which is invoked when sending a 
  -    SOAP message. The &quot;pivot&quot; attribute specifies a Handler to be used

  -    as the actual sender for this transport (for example, the HTTPSender). Request 
  -    and response flows may be specified as in server-side transports to do processing 
  -    on the request (i.e. outgoing message) or response (i.e. incoming message).</dd>
  -  <dt>&nbsp;</dt>
  -  <dt><b><font face="Courier New, Courier, mono">&lt;typeMapping
qname=&quot;</font></b><font face="Courier New, Courier, mono"><i>ns:localName</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    classname=&quot;</font></b><font face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    serializer=&quot;</font></b><font face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    deserializer=&quot;</font></b><font face="Courier New, Courier,
mono"><i>classname</i></font><b><font face="Courier New, Courier,
mono">&quot;/&gt;</font></b></dt>
  -  <dd>Each typeMapping maps an XML qualified name to/from a Java class, using 
  -    a specified Serializer and Deserializer. </dd>
  -  <dt>&nbsp;</dt>
  -  <dt><b><font face="Courier New, Courier, mono">&lt;beanMapping
qname=&quot;</font></b><font face="Courier New, Courier, mono"><i>ns:localName</i></font><b><font
face="Courier New, Courier, mono">&quot; 
  -    classname=&quot;</font></b><font face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">&quot;</font></b><b><font face="Courier
New, Courier, mono">&gt;</font></b></dt>
  -  <dd><b></b>A simplified type mapping, which uses pre-defined serializers/deserializers

  -    to encode/decode JavaBeans. The class named by &quot;classname&quot; must 
  -    follow the JavaBean standard pattern of get/set accessors.</dd>
  -</dl>
  -<p> </p>
  -<h2>Pre-Configured Axis Components Reference</h2>
  -<h3>On the server:</h3>
  -<dl> 
  -  <dt><b>LogHandler</b> 
  -  <dd>The LogHandler will simply log a message to a logger when it gets invoked.

  -  <dt> 
  -  <dt><b>EchoHandler</b> 
  -  <dd>The EchoHandler copies the request message into the response message. 
  -  <dt><b>HTTPAuth</b>
  -  <dd>The HTTPAuthHandler takes HTTP-specific authentication information (right 
  -    now, just Basic authentication) and turns it into generic MessageContext properties

  -    for username and password
  -  <dt><b>SimpleAuthenticationHandler</b> 
  -  <dd>The SimpleAuthentication handler passes a MessageContext to a SecurityProvider

  -    (see org.apache.axis.security) to authenticate the user using whatever information

  -    the SecurityProvider wants (right now, just the username and password).
  -  <dt><b>SimpleAuthorizationHandler</b> 
  -  <dd>This handler, typically deployed alongside the SimpleAuthenticationHandler

  -    (a chain called &quot;authChecks&quot; is predefined for just this combination),

  -    checks to make sure that the currently authenticated user satisfies one of 
  -    the allowed roles for the target service. Throws a Fault if access is denied.
  -  <dt><b>URLMapper</b> 
  -  <dd>The URLMapper, an HTTP-specific handler, usually goes on HTTP transport 
  -    chains (it is deployed by default). It serves to do service dispatch based 
  -    on URL - for instance, this is the Handler which allows URLs like http://localhost:8080/axis/services/MyService?wsdl

  -    to work.
  -  <dt>&nbsp;
  -  <dt> 
  -  <dt><b>RPCDispatcher</b> 
  -  <dd>The RPCDispatcher is the pivot point for all RPC services. It accepts the 
  -    following options: <br>
  -    <b><i>className</i></b> = the class of the backend object to
invoke<br>
  -    <b><i>methodName</i></b> = a space-separated list of methods
which are exported 
  -    as web services. The special value &quot;*&quot; matches all public methods

  -    in the class. 
  -  <dt> 
  -  <dt><b>MsgDispatcher</b> 
  -  <dd>The MsgDispatcher is the pivot point for all messaging services. It accepts

  -    the following options: <br>
  -  <dd><b><i>className</i></b> = the class of the backend
object to invoke<br>
  -    <b><i>methodName</i></b> = a space-separated list of methods
which are exported 
  -    as web services. The special value &quot;*&quot; matches all public methods

  -    in the class. 
  -  <dt> 
  -  <dt><b></b> 
  -  <dt> 
  -  <dt><b>LocalResponder</b> 
  -  <dd>The LocalResponder is a Handler whose job in life is to serialize the response

  -    message coming back from a local invocation into a String. It is by default 
  -    on the server's local transport response chain, and it ensures that serializing 
  -    the message into String form happens in the context of the server's type mappings.</dd>
  -</dl>
  -<h3>On the client:</h3>
  -<dl> 
  -  <dt><b>HTTPSender</b> 
  -  <dd>A Handler which sends the request message to a remote server via HTTP, and

  -    collects the response message.
  -  <dt> 
  -  <dt><b>LocalSender</b> 
  -  <dd>A Handler which sends the request message to a &quot;local&quot; AxisServer,

  -    which will process it and return a response message. This is extremely useful 
  -    for testing, and is by default mapped to the &quot;local:&quot; transport.

  -    So, for instance, you can test the AdminClient by doing something like this:<br>
  -    <pre>% java org.apache.axis.client.AdminClient -llocal:// list</pre>
  -  <dt></dt>
  -</dl>
  +
   <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>
  
  
  
  1.1                  xml-axis/java/docs/reference.html
  
  Index: reference.html
  ===================================================================
  <!-- saved from url=(0022)http://internet.e-mail -->
  <html>
  <head>
  <title>Axis Reference Guide</title>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  <style type="text/css">
  <!--
  .example { background:#ccccff }
  .xml { background:#eeeeee }
  body {  font-family: Verdana, Arial, Helvetica, sans-serif; margin-left: 40px}
  h2 {  text-decoration: underline; background-color: #DCE1FF; background-position: left;
margin-left: -30px}
  h3 {  margin-left: -10px}
  h1 {  margin-left: -30px}
  -->
  </style>
  </head>
  
  <body bgcolor="#ffffff" text="#000000">
  <h1 align="center"><IMG height=96 src="axis.jpg" width=176></h1>
  <h1>Axis Reference Guide</h1>
  <p><i>Alpha 3 Version</i></p>
  <h3>Table of Contents</h3>
  
  <h2><a name="DeploymentReference"></a>Deployment Reference</h2>
  Note : all the elements referred to in this section are in the WSDD namespace, 
  namely &quot;http://wsdd&quot;. 
  <dl> 
    <dt><b><font face="Courier New, Courier, mono">&lt;deployment&gt;</font></b></dt>
    <dd>The root element of the deployment document which tells the Axis engine 
      that this is a deployment. Must be in the &quot;AdminService&quot; namespace.</dd>
    <dt>&nbsp;</dt>
    <dt><b><font face="Courier New, Courier, mono">&lt;undeployment&gt;</font></b></dt>
    <dd>The root element of the deployment document which tells Axis that this is 
      an undeployment. Must be in the &quot;AdminService&quot; namespace.</dd>
    <dt>&nbsp;</dt>
    <dt><b><font face="Courier New, Courier, mono">&lt;handler name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      type=&quot;</font></b><font face="Courier New, Courier, mono"><i>type</i></font><b><font
face="Courier New, Courier, mono">&quot;/&gt;</font></b></dt>
    <dd>Belongs inside a deploy or undeploy. Names a Handler, and indicates the 
      class which corresponds to the name. May contain an arbitrary number of <b><font
face="Courier New, Courier, mono">&lt;option 
      name=&quot;</font></b><font face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      value=&quot;</font></b><font face="Courier New, Courier, mono"><i>value</i></font><b><font
face="Courier New, Courier, mono">&quot;&gt;</font></b> 
      elements, each of which will supply an option to the deployed Handler.</dd>
    <dt>&nbsp;</dt>
    <dt><b><font face="Courier New, Courier, mono">&lt;service name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      provider=&quot;</font></b><font face="Courier New, Courier, mono"><i>provider</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      &gt;</font></b></dt>
    <dd>Deploys/undeploys an Axis Service. Common options for this element (i.e. 
      subelements of the form <code><b>&lt;parameter name=&quot;</b>name<b>&quot;

      value=&quot;</b>value<b>&quot;/&gt;</b>)</code>
include:<br>
      <b>className</b> : the backend implementation class<br>
      <b>methodName</b> : the allowed methods<br>
      <b>allowedRoles</b> : comma-separated list of roles allowed to access this

      service<br>
      <br>
      If you wish to define handlers which should be invoked either before or after 
      the service's provider, you may do so with the <b>&lt;requestFlow&gt;</b>

      and the <b>&lt;responseFlow&gt;</b> subelements. Either of those
elements 
      may be specified inside the <b>&lt;service&gt;</b> element, and
their semantics 
      are identical to the <b>&lt;chain&gt;</b> element described below
- in other 
      words, they may contain <b>&lt;handler&gt;</b> and <b>&lt;chain</b>&gt;
elements 
      which will be invoked in the order they are specified.</dd>
    <dt><b><br>
      <font face="Courier New, Courier, mono">&lt;chain name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot;</font></b><b><font face="Courier
New, Courier, mono">&gt;<br>
      &lt;<i>subelement</i>/&gt;...<br>
      &lt;/chain&gt; </font></b></dt>
    <dd>Defines a chain. Each <i>handler</i> (i.e. deployed handler name)
in the 
      list will be invoked() in turn when the chain is invoked. This enables you 
      to build up &quot;modules&quot; of commonly used functionality. The subelements

      inside chains may be &lt;<b>handler</b>&gt;s or &lt;<b>chain</b>&gt;s.
&lt;handler&gt;s 
      inside a &lt;chain&gt; may either be defined in terms of their Java class:<br>
      <pre>&lt;chain name=&quot;myChain&quot;&gt;
    &lt;handler type=&quot;java:org.apache.axis.handlers.LogHandler&quot;/&gt;
  &lt;/chain&gt;</pre>
      or may refer to previously defined &lt;handlers&gt;, with the &quot;type&quot;

      of the handler referring to the name of the other handler definition:<br>
      <pre>&lt;handler name=&quot;logger&quot; type=&quot;java:org.apache.axis.handlers.LogHandler&quot;/&gt;<br>&lt;chain
name=&quot;myChain&quot;/&gt;<br>   &lt;handler type=&quot;logger&quot;/&gt;<br>&lt;/chain&gt;</pre>
    </dd>
    <dt><b><font face="Courier New, Courier, mono">&lt;transport name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot;&gt;</font></b></dt>
    <dd>Defines a transport on the server side. Server transports are invoked when 
      an incoming request arrives. A server transport may define <b>&lt;requestFlow&gt;</b>

      and/or <b>&lt;responseFlow&gt;</b> elements to specify handlers/chains
which 
      should be invoked during the request (i.e. incoming message) or response (i.e. 
      outgoing message) portion of processing (this function works just like the 
      <b>&lt;service&gt;</b> element above). Typically handlers in the
transport 
      request/response flows implement transport-specific functionality, such as 
      parsing protocol headers, etc.</dd>
    <dt>&nbsp;</dt>
    <dt><b><font face="Courier New, Courier, mono">&lt;transport name=&quot;</font></b><font
face="Courier New, Courier, mono"><i>name</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      pivot=&quot;</font></b><font face="Courier New, Courier, mono"><i>handler

      type</i><b>&quot;</b></font><b><font face="Courier
New, Courier, mono"> &gt;</font></b></dt>
    <dd>Defines a transport on the client side, which is invoked when sending a 
      SOAP message. The &quot;pivot&quot; attribute specifies a Handler to be used

      as the actual sender for this transport (for example, the HTTPSender). Request 
      and response flows may be specified as in server-side transports to do processing 
      on the request (i.e. outgoing message) or response (i.e. incoming message).</dd>
    <dt>&nbsp;</dt>
    <dt><b><font face="Courier New, Courier, mono">&lt;typeMapping qname=&quot;</font></b><font
face="Courier New, Courier, mono"><i>ns:localName</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      classname=&quot;</font></b><font face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      serializer=&quot;</font></b><font face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      deserializer=&quot;</font></b><font face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">&quot;/&gt;</font></b></dt>
    <dd>Each typeMapping maps an XML qualified name to/from a Java class, using 
      a specified Serializer and Deserializer. </dd>
    <dt>&nbsp;</dt>
    <dt><b><font face="Courier New, Courier, mono">&lt;beanMapping qname=&quot;</font></b><font
face="Courier New, Courier, mono"><i>ns:localName</i></font><b><font
face="Courier New, Courier, mono">&quot; 
      classname=&quot;</font></b><font face="Courier New, Courier, mono"><i>classname</i></font><b><font
face="Courier New, Courier, mono">&quot;</font></b><b><font face="Courier
New, Courier, mono">&gt;</font></b></dt>
    <dd><b></b>A simplified type mapping, which uses pre-defined serializers/deserializers

      to encode/decode JavaBeans. The class named by &quot;classname&quot; must 
      follow the JavaBean standard pattern of get/set accessors.</dd>
  </dl>
  <p> </p>
  <h2>Pre-Configured Axis Components Reference</h2>
  <h3>On the server:</h3>
  <dl> 
    <dt><b>LogHandler</b> 
    <dd>The LogHandler will simply log a message to a logger when it gets invoked. 
    <dt> 
    <dt><b>EchoHandler</b> 
    <dd>The EchoHandler copies the request message into the response message. 
    <dt><b>HTTPAuth</b>
    <dd>The HTTPAuthHandler takes HTTP-specific authentication information (right 
      now, just Basic authentication) and turns it into generic MessageContext properties

      for username and password
    <dt><b>SimpleAuthenticationHandler</b> 
    <dd>The SimpleAuthentication handler passes a MessageContext to a SecurityProvider

      (see org.apache.axis.security) to authenticate the user using whatever information 
      the SecurityProvider wants (right now, just the username and password).
    <dt><b>SimpleAuthorizationHandler</b> 
    <dd>This handler, typically deployed alongside the SimpleAuthenticationHandler 
      (a chain called &quot;authChecks&quot; is predefined for just this combination),

      checks to make sure that the currently authenticated user satisfies one of 
      the allowed roles for the target service. Throws a Fault if access is denied.
    <dt><b>URLMapper</b> 
    <dd>The URLMapper, an HTTP-specific handler, usually goes on HTTP transport 
      chains (it is deployed by default). It serves to do service dispatch based 
      on URL - for instance, this is the Handler which allows URLs like http://localhost:8080/axis/services/MyService?wsdl

      to work.
    <dt>&nbsp;
    <dt> 
    <dt><b>RPCDispatcher</b> 
    <dd>The RPCDispatcher is the pivot point for all RPC services. It accepts the 
      following options: <br>
      <b><i>className</i></b> = the class of the backend object to
invoke<br>
      <b><i>methodName</i></b> = a space-separated list of methods
which are exported 
      as web services. The special value &quot;*&quot; matches all public methods

      in the class. 
    <dt> 
    <dt><b>MsgDispatcher</b> 
    <dd>The MsgDispatcher is the pivot point for all messaging services. It accepts

      the following options: <br>
    <dd><b><i>className</i></b> = the class of the backend object
to invoke<br>
      <b><i>methodName</i></b> = a space-separated list of methods
which are exported 
      as web services. The special value &quot;*&quot; matches all public methods

      in the class. 
    <dt> 
    <dt><b></b> 
    <dt> 
    <dt><b>LocalResponder</b> 
    <dd>The LocalResponder is a Handler whose job in life is to serialize the response

      message coming back from a local invocation into a String. It is by default 
      on the server's local transport response chain, and it ensures that serializing 
      the message into String form happens in the context of the server's type mappings.</dd>
  </dl>
  <h3>On the client:</h3>
  <dl> 
    <dt><b>HTTPSender</b> 
    <dd>A Handler which sends the request message to a remote server via HTTP, and 
      collects the response message.
    <dt> 
    <dt><b>LocalSender</b> 
    <dd>A Handler which sends the request message to a &quot;local&quot; AxisServer,

      which will process it and return a response message. This is extremely useful 
      for testing, and is by default mapped to the &quot;local:&quot; transport. 
      So, for instance, you can test the AdminClient by doing something like this:<br>
      <pre>% java org.apache.axis.client.AdminClient -llocal:// list</pre>
    <dt></dt>
  </dl>
  </body>
  </html>
  
  
  

Mime
View raw message