axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cha...@apache.org
Subject svn commit: r397788 - in /webservices/axis2/trunk/java/xdocs/latest: Axis2ArchitectureGuide.html CodegenToolReference.html ServiceArchiveToolReference.html
Date Fri, 28 Apr 2006 06:59:28 GMT
Author: chatra
Date: Thu Apr 27 23:59:27 2006
New Revision: 397788

URL: http://svn.apache.org/viewcvs?rev=397788&view=rev
Log:
made upgrades  and corrections to the documents

Modified:
    webservices/axis2/trunk/java/xdocs/latest/Axis2ArchitectureGuide.html
    webservices/axis2/trunk/java/xdocs/latest/CodegenToolReference.html
    webservices/axis2/trunk/java/xdocs/latest/ServiceArchiveToolReference.html

Modified: webservices/axis2/trunk/java/xdocs/latest/Axis2ArchitectureGuide.html
URL: http://svn.apache.org/viewcvs/webservices/axis2/trunk/java/xdocs/latest/Axis2ArchitectureGuide.html?rev=397788&r1=397787&r2=397788&view=diff
==============================================================================
--- webservices/axis2/trunk/java/xdocs/latest/Axis2ArchitectureGuide.html (original)
+++ webservices/axis2/trunk/java/xdocs/latest/Axis2ArchitectureGuide.html Thu Apr 27 23:59:27
2006
@@ -26,8 +26,11 @@
   <li><a href="#bmBP">The Big Picture</a></li>
   <li><p><a href="#requirements">Requirement of Axis2</a></p>
   </li>
-  <li><a href="#thearchi">Axis2, The Architecture</a>
+  <li><a href="#thearchi">Axis2 Architecture</a>
     <ul>
+      <li><p><a href="#bmcore">Core Modules</a></p>
+      </li>
+      <li><a href="#bmother">Other Modules</a></li>
       <li><p><a href="#bmInfoMod">Information Model</a></p>
       </li>
       <li><a href="#bmXML">XML Processing Model</a></li>
@@ -91,27 +94,27 @@
 
 <h2>Requirement of Axis2</h2>
 
-<p>In the SOAP terminology, a participant who is taking part in a Web Service
+<p>In the SOAP terminology, a participant who is taking part in a Web service
 interaction is known as a SOAP Node. Delivery of a single SOAP Message is
 defined based on two participants, SOAP Sender and SOAP Receiver. Each SOAP
 Message is sent by SOAP Sender and received by SOAP Receiver. A single SOAP
-delivery is the most basic unit that builds the Web Service interaction.</p>
+delivery is the most basic unit that builds the Web service interaction.</p>
 
 <p>Each SOAP Node may be written in specific programming language, may it be
-Java, C++, .NET or Perl, the Web Services allow them to inter operate. This
-is possible because on the wire each Web Service interaction is done via
+Java, C++, .NET or Perl, the Web services allow them to inter operate. This
+is possible because on the wire each Web service interaction is done via
 SOAP, which is common to every SOAP Node.</p>
 
 <p><img alt="" src="images/archi-guide/soap.gif" name="Graphic1"
 align="bottom" width="691" height="319" border="0"></p>
 
-<p>Web Service middleware handles the complexity in SOAP messaging and lets
+<p>Web service middleware handles the complexity in SOAP messaging and lets
 the users work with the programming language they are accustomed to. Axis2
-allows java users to invoke Web Services using java representations, and
+allows java users to invoke Web services using java representations, and
 handles the SOAP messaging behind the curtain.</p>
 
 <p>Axis2 handles SOAP processing along with numerous other tasks. This makes
-the life of the Web Service developer a whole lot easier. Following are the
+the life of the Web service developer a whole lot easier. Following are the
 identified requirements:</p>
 <ol>
   <li>Provide a framework to process the SOAP messages. The framework should
@@ -119,9 +122,9 @@
     per service or per operation basis. Furthermore it should be able to
     model different Message Exchange Patterns (MEPs) using the processing
     framework.</li>
-  <li><p>Ability to deploy a Web Services (with or without WSDL)</p>
+  <li><p>Ability to deploy a Web services (with or without WSDL)</p>
   </li>
-  <li>Provide a Client API that can be used to invoke Web Services. This API
+  <li>Provide a Client API that can be used to invoke Web services. This API
     should support both the Synchronous and Asynchronous programming
   models.</li>
   <li><p>Ability to configure Axis2 and it's components via deployment.</p>
@@ -135,7 +138,7 @@
 three specifications- WSDL, SOAP and WS-Addressing. Other specifications like
 JAX-RP, SAAJ &amp; WS-Policy are layered on top of the Core Architecture.</p>
 
-<h2><a name="thearchi">Axis2, The Architecture</a></h2>
+<h2><a name="thearchi">Axis2 Architecture</a></h2>
 Axis2 architecture lays out some principals to preserve the uniformity. They
 are as follows:
 <ul>
@@ -149,10 +152,11 @@
 
 <p>Axis2 architecture is modular. Therefore Axis2 Framework is built up of
 core modules which collectively make up the core architecture of Axis2, and
-non-core modules that are layered on top of this core
+non-core/other modules that are layered on top of this core
 modules/architecture.</p>
+<a name="bmother"></a>
 
-<p>Core Modules:</p>
+<h3>Core Modules:</h3>
 <ul>
   <li><a href="#bmInfoMod">Information Model</a>- Axis2 defines a model
to
     handle information and all states are kept in this model. The model has a
@@ -175,7 +179,7 @@
     SOAP Processing model per system, service or operation basis.</p>
   </li>
   <li><a href="#bmClientAPI">Client API</a>- This provides a convenient
API
-    for users to communicate with web services using Axis2. There are set of
+    for users to communicate with Web services using Axis2. There are set of
     classes to interact with IN-OUT and IN-Only style Message Exchange
     Patterns (MEPs) where those can be used to construct any other MEP.</li>
   <li><p><a href="#bmTransports">Transports</a>- Axis2 define a transport
@@ -185,7 +189,9 @@
     new ones if and when it is needed.</p>
   </li>
 </ul>
-Non-core Modules:
+<a name="bmcore"></a>
+
+<h3>Other Modules:</h3>
 <ul>
   <li><a href="#bmWSDL">Code Generation</a>- Axis2 provides a code generation
     tool that will generate server side and client side code along with a
@@ -224,7 +230,7 @@
 <p>The two hierarchies are connected as shown in the above figure. The
 Description hierarchy represents the static data. This data may be loaded
 from a configuration file that exists throughout the lifetime of Axis2. For
-example, deployed Web Services, operations, etc. On the other hand, the
+example, deployed Web services, operations, etc. On the other hand, the
 context hierarchy holds more dynamic information about the things that have
 more than one instances (e.g.Message Context).</p>
 
@@ -260,7 +266,7 @@
       <td width="103"><p>Axis Configuration</p>
       </td>
       <td width="336"><p>Holds all global configurations. Transports, global
-        modules, parameters and Services etc.</p>
+        modules, parameters and services etc.</p>
       </td>
     </tr>
     <tr>
@@ -408,30 +414,31 @@
 <p>Let us see what happens at each phase of the execution. This process may
 happen either in the server or in the Client.</p>
 <ol>
-  <li>Transport Phase - The handlers are in the phase ment to be process
-    transport specific information such as validate incoming message by
-    looking at various transport headers, add data into message context
-  etc..</li>
-  <li>Pre-Dispatch Phase- The main functionality of the handlers are in this
-    phase is to populate message context in order to do the dispatching. As
-    an example processing of addressing headers happen in this phase , so by
-    looking at addressing headers it will find the name of the service and
-    operation.</li>
-  <li>Dispatch Phase - The Dispatchers run in this phase and find the Service
-    if the service is not found already. <br>
+  <li><strong>Transport Phase</strong> - The handlers are in the phase
meant
+    to process transport specific information such as validating incoming
+    message by looking at various transport headers, add data into message
+    context etc.</li>
+  <li><strong>Pre-Dispatch Phase</strong>- The main functionality of the
+    handlers are in this phase is to populate message context in order to do
+    the dispatching. As an example processing of addressing headers happen in
+    this phase , so by looking at addressing headers it will find the name of
+    the service and operation.</li>
+  <li><strong>Dispatch Phase</strong> - The Dispatchers run in this phase
and
+    find the service if the service is not found already. <br>
     The post condition of the dispatch phase work as follows; That checks
     whether the service and operation are found or not. If the service or
     operation has not been found by this point the execution will halt and
     send a "service not found error".</li>
-  <li>User Defined Phases - Users are allowed to engage their custom handlers
-    here.</li>
+  <li><strong>User Defined Phases</strong> - Users are allowed to engage
+    their custom handlers here.</li>
   <li>Message Validation Phase - Once the user level execution has taken
     place this phase validates whether SOAP Message Processing has taken
     place correctly.</li>
-  <li>Message Processing Phase - The Business logic of the SOAP message is
-    executed here. A <a href="#mr">Message Receiver</a> is registered with
-    each Operation. This Message receiver (associated to the particular
-    operation) will executed as the last Handler of this phase.</li>
+  <li><strong>Message Processing Phase</strong> - The Business logic of
the
+    SOAP message is executed here. A <a href="#mr">Message Receiver</a> is
+    registered with each Operation. This Message receiver (associated to the
+    particular operation) will executed as the last Handler of this
+  phase.</li>
 </ol>
 
 <p>There may be other handlers in any of these phases. Users may use custom
@@ -482,7 +489,7 @@
 Modules</a></h4>
 
 <p>Axis2 defines an entity called a 'module' that can introduce handlers and
-web service operations. A Module in terms of Axis2 usually acts as a
+Web service operations. A Module in terms of Axis2 usually acts as a
 convenient packaging that include a set of handlers and an associated
 descriptor which includes the phase rules. Modules have the concept of being
 'available' and 'engaged'. 'Availability' means the module is present in the
@@ -495,7 +502,7 @@
 
 <p>Apart from the extension mechanism based on the handlers the WS-*
 specifications suggest a requirement for adding new operations. For example,
-once a user add a Reliable Messaging capability to a Service the "Create
+once a user add a Reliable Messaging capability to a service the "Create
 Sequence" operation needs to be available to the service end point. This can
 be implemented by letting the modules define the operations, and once the
 module is engaged to a service, the necessary operations will be added to
@@ -535,9 +542,9 @@
 information.</p>
 <ol>
   <li>Service level parameters</li>
-  <li>Modules that are engaged Service level</li>
+  <li>Modules that are engaged service level</li>
   <li>Service Specific <a href="#mr">Message Receivers</a></li>
-  <li>Operations inside the Service</li>
+  <li>Operations inside the service</li>
 </ol>
 
 <h3><a name="modulearchive">Module Archive</a></h3>
@@ -559,7 +566,7 @@
 
 <h2>Client API</h2>
 
-<p>There are three parameters that decide the nature of the Web Service
+<p>There are three parameters that decide the nature of the Web service
 interaction.</p>
 <ol>
   <li>Message Exchange Pattern (MEP)</li>
@@ -711,7 +718,5 @@
 <p><code>public static org.apache.xmlbeans.XmlObject
 getTestObject(java.lang.Class type) /*This will be a utility method that can
 be used to create sample objects of the given data bound object.*/</code></p>
-
-<p></p>
 </body>
 </html>

Modified: webservices/axis2/trunk/java/xdocs/latest/CodegenToolReference.html
URL: http://svn.apache.org/viewcvs/webservices/axis2/trunk/java/xdocs/latest/CodegenToolReference.html?rev=397788&r1=397787&r2=397788&view=diff
==============================================================================
--- webservices/axis2/trunk/java/xdocs/latest/CodegenToolReference.html (original)
+++ webservices/axis2/trunk/java/xdocs/latest/CodegenToolReference.html Thu Apr 27 23:59:27
2006
@@ -4,7 +4,7 @@
   <title>Code Generator-Command Line Tool</title>
 </head>
 
-<body>
+<body lang="en">
 <h1>Code Generator Tool- Command Line &amp; Ant Task</h1>
 
 <p>The Code Generator tool consists of a command line version and an Ant
@@ -23,9 +23,9 @@
   <li><a href="#ant">Ant Task</a>
     <ul>
       <li><a href="#antref">Ant Task Reference</a></li>
-      <li><a href="#example">Example build file using the custom Ant
-      task</a></li>
-      <li><a href="#invoking">Invoking the Code Generator from Ant</a></li>
+      <li><a href="#example">Example Build File Using the Custom Ant
+      Task</a></li>
+      <li><a href="#invoking">Invoking the Code Generator From Ant</a></li>
     </ul>
   </li>
   <li><a href="#appendix">Appendix</a></li>
@@ -144,7 +144,7 @@
     <tr>
       <td width="20%">-g</td>
       <td width="20%">--generate-all</td>
-      <td width="60%">Genrates all the classes. This option is valid only
+      <td width="60%">Generates all the classes. This option is valid only
         with the -ss (server side code generation) option. When on, the
         client code (stubs) will also be generated along with the
       skeleton.</td>
@@ -195,22 +195,22 @@
 style="border-collapse: collapse" width="100%" id="AutoNumber2">
   <tbody>
     <tr>
-      <td width="50%" height="19">wsdlfilename</td>
-      <td width="50%" height="19">WSDL file location. Maps to the uri option
-        of the command line tool</td>
-    </tr>
-    <tr>
-      <td width="50%" height="76">output</td>
-      <td width="50%" height="76">output file location. This is where the
-        files would be copied once the code generation is done. If this
-        option is omitted the generated files would be copied to the working
-        directory. . Maps to the -o option of the command line tool</td>
-    </tr>
-    <tr>
-      <td width="50%" height="171">language</td>
-      <td width="50%" height="171">Output language. Currently the code
-        generator can generate code in Java and CSharp. (CSharp support is
-        limited) When omitted defaults to Java.
+      <td>wsdlfilename</td>
+      <td>WSDL file location. Maps to the uri option of the command line
+      tool</td>
+    </tr>
+    <tr>
+      <td>output</td>
+      <td>output file location. This is where the files would be copied once
+        the code generation is done. If this option is omitted the generated
+        files would be copied to the working directory. . Maps to the -o
+        option of the command line tool</td>
+    </tr>
+    <tr>
+      <td>language</td>
+      <td>Output language. Currently the code generator can generate code in
+        Java and CSharp. (CSharp support is limited) When omitted defaults to
+        Java.
 
         <p>Allowed options are</p>
         <ul>
@@ -222,62 +222,60 @@
       </td>
     </tr>
     <tr>
-      <td width="50%" height="57">packagename</td>
-      <td width="50%" height="57">The target package name. If omitted, a
-        default package (formed using the target namespace of the WSDL) will
-        be used. Maps to the -p option of the command line tool.</td>
+      <td>packagename</td>
+      <td>The target package name. If omitted, a default package (formed
+        using the target namespace of the WSDL) will be used. Maps to the -p
+        option of the command line tool.</td>
     </tr>
     <tr>
-      <td width="50%" height="75">asynconly</td>
-      <td width="50%" height="75">Generate code only for async style . when
-        this option is used the generated stubs will have only the
-        asynchronous invocation methods. Defaults to false if omitted Only
-        true and false are applicable as values. Maps to the -a option of the
-        command line tool.</td>
+      <td>asynconly</td>
+      <td>Generate code only for async style . when this option is used the
+        generated stubs will have only the asynchronous invocation methods.
+        Defaults to false if omitted Only true and false are applicable as
+        values. Maps to the -a option of the command line tool.</td>
     </tr>
     <tr>
-      <td width="50%" height="16">testcase</td>
-      <td width="50%" height="16">Generates a test case</td>
+      <td>testcase</td>
+      <td>Generates a test case</td>
     </tr>
     <tr>
-      <td width="50%" height="19">synconly</td>
-      <td width="50%" height="19">Generate code only for sync style . when
-        this option is used the generated stubs will have only the
-        synchronous invocation methods. Defaults to false if omitted. Only
-        true and false are applicable as values. Maps to the -s option of the
-        command line tool.</td>
+      <td>synconly</td>
+      <td>Generate code only for sync style . when this option is used the
+        generated stubs will have only the synchronous invocation methods.
+        Defaults to false if omitted. Only true and false are applicable as
+        values. Maps to the -s option of the command line tool.</td>
     </tr>
     <tr>
-      <td width="50%" height="19">serverside</td>
-      <td width="50%" height="19">Generates server side code (i.e.
-        skeletons). Only true and false are applicable as values. Default is
-        false. Maps to the -ss option of the command line tool</td>
+      <td>serverside</td>
+      <td>Generates server side code (i.e. skeletons). Only true and false
+        are applicable as values. Default is false. Maps to the -ss option of
+        the command line tool</td>
     </tr>
     <tr>
-      <td width="50%" height="18">generateserverxml</td>
-      <td width="50%" height="18">Generates server side code (i.e.
-        skeletons). Only true and false are applicable as values. Default is
-        false. Maps to the -sd option of the command line tool.</td>
+      <td>generateserverxml</td>
+      <td>Generates server side code (i.e. skeletons). Only true and false
+        are applicable as values. Default is false. Maps to the -sd option of
+        the command line tool.</td>
     </tr>
     <tr>
-      <td width="50%" height="18">unpackClasses</td>
-      <td width="50%" height="18">unpackes the generated classes. This forces
-        the databinding classes to be generated separately, which otherwise
-        would have been generated as inner classes.</td>
+      <td>unpackClasses</td>
+      <td>Unpacks the generated classes. This forces the databinding classes
+        to be generated separately, which otherwise would have been generated
+        as inner classes.</td>
     </tr>
     <tr>
-      <td width="50%" height="18">serviceName</td>
-      <td width="50%" height="18">The name of the service</td>
+      <td>serviceName</td>
+      <td>The name of the service</td>
     </tr>
     <tr>
-      <td width="50%" height="18">PortName</td>
-      <td width="50%" height="18">The name of the port</td>
+      <td>PortName</td>
+      <td>The name of the port</td>
     </tr>
   </tbody>
 </table>
 <a name="example"></a>
 
-<h3>Example build file using the custom Ant task</h3>
+<h3>Example Build File Using the Custom Ant Task</h3>
 
 <p>Following is an example ant build file that uses the custom Ant task.</p>
 <pre>&lt;?xml version="1.0"?&gt;
@@ -321,7 +319,7 @@
 </ul>
 <a name="invoking"></a>
 
-<h3>Invoking the Code Generator from Ant</h3>
+<h3>Invoking the Code Generator From Ant</h3>
 
 <p>Since the users may find altering their ant class path a bit daunting they
 can also follow an easier technique. The code generator main class can be
@@ -439,14 +437,14 @@
   &lt;/jar&gt;
   &lt;/target&gt;
   
-  &lt;!-- build an .aar file for axis2 web services --&gt;
+  &lt;!-- build an .aar file for axis2 Web services --&gt;
   &lt;target name="aar" depends="compile"&gt;
 
      &lt;delete dir="${build.classes}/META-INF" /&gt;
      &lt;mkdir dir="${build.classes}/META-INF" /&gt;
      &lt;copy todir="${build.classes}/META-INF" &gt;
        &lt;fileset dir="output/service_descriptors/LoginEndpoint" &gt;
-         &lt;!-- axis2 web services definitions file --&gt;
+         &lt;!-- axis2 Web services definitions file --&gt;
          &lt;include name="services.xml"/&gt;
 
        &lt;/fileset&gt;
@@ -575,7 +573,7 @@
 needed to compile the generated sources.</p>
 
 <p>The next step is to modify the generated Skeleton Java Source file - the
-Web Service. This file as generated returns null and needs to be updated to
+Web service. This file as generated returns null and needs to be updated to
 contain the business logic.</p>
 
 <p>After the WSDL2Java command runs the file LoginEndpoint.wsdl, edit the
@@ -668,7 +666,7 @@
 jar file lib/axis2_example_wsdl.jar in the 'lib' directory under the
 build.xml . This jar will be used to compile the client, and also will be
 placed in the servlet container. Next, run the 'aar' ant task from the
-example build.xml, which generates the deployable axis2 web service. Place
+example build.xml, which generates the deployable axis2 Web service. Place
 dist/LoginEndpoint.aar into axis2/WEB-INF/services . Place
 lib/axis2_example_wsdl.jar into axis2/WEB-INF/lib . Verify the happy axis
 page loaded the services correctly - there should be the service

Modified: webservices/axis2/trunk/java/xdocs/latest/ServiceArchiveToolReference.html
URL: http://svn.apache.org/viewcvs/webservices/axis2/trunk/java/xdocs/latest/ServiceArchiveToolReference.html?rev=397788&r1=397787&r2=397788&view=diff
==============================================================================
--- webservices/axis2/trunk/java/xdocs/latest/ServiceArchiveToolReference.html (original)
+++ webservices/axis2/trunk/java/xdocs/latest/ServiceArchiveToolReference.html Thu Apr 27
23:59:27 2006
@@ -5,15 +5,28 @@
 </head>
 
 <body>
-<h1>Service Archive Wizard - Eclipse Plug-in</h1>
+<h1>Service Archive Wizard - eclipse Plug-in</h1>
 
-<p><a href="http://ws.apache.org/axis2/download.cgi">[Download]</a></p>
+<p><a href="http://ws.apache.org/axis2/download.cgi">[Download Plugin
+Tool]</a></p>
+
+<p>This document will guide you through the installation of the eclipse
+plugin and how the tool can be used. </p>
+
+<h2>Content</h2>
+<ul>
+  <li><a href="#intro">Introduction</a></li>
+  <li><a href="#installation">Installation</a></li>
+  <li><a href="#operation">Operations</a></li>
+</ul>
+
+<h2>Introduction</h2>
 
 <p>Axis2 comes with a simple service archive tool. This tool provides easy to
 use functionality to develop an Axis archive or an "aar" file or a "jar" file
-that can be deployed as a web service to the Axis2. This tool is in the form
-of an Eclipse plug-in and can be downloaded from the downloads section. This
-document describes how the tool can be used.</p>
+that can be deployed as a Web service to the Axis2. This tool is in the form
+of an Eclipse plug-in and can be downloaded from the downloads section. </p>
+<a name="installation"></a>
 
 <h2>Installation</h2>
 
@@ -21,8 +34,9 @@
 zip file into the Eclipse installation folder. (The plug-in will actually go
 into the plugins directory in the Eclipse installation root). Restarting
 Eclipse will set the plug-in automatically.</p>
+<a name="operation"></a>
 
-<h2>Operation</h2>
+<h2>Operations</h2>
 
 <p>If the plug-in is properly installed you should see a new wizard under the
 "New" section.(use the File -&gt; New -&gt; Other or Ctrl + N )</p>
@@ -115,7 +129,7 @@
 <p>If any library needs to be removed, highlight it in the list and hit
 remove. Click next to proceed to the last page of the wizard</p>
 
-<p align="center"><img alt="" border="0"
+<p align="center"><img alt=""
 src="images/tools/service/service_page5_remove.JPG"></p>
 
 <p>The last page of the wizard asks for the output location and the output



Mime
View raw message