CVS: ivory/xdocs axiscomponent.xml,1.4,1.5

Update of /cvsroot/plexus/ivory/xdocs
In directory eng.werken.com:/tmp/cvs-serv24814/xdocs

Modified Files:
	axiscomponent.xml 
Log Message:
- Documentation corrections
- move the servlets to the plexus package.
- IvoryTestCase which should make testing services a little easier.
  See the unit tests if you're interested.  More testing utilities coming
  soon!
- You do not need to call AxisServer.start() as it turns out, the
  AxisServer constructor already does that.
- AxisService will not expose methods that return a List or take it
  as a parameter.  Axis does not know how to hanlde this yet.

Index: axiscomponent.xml
===================================================================
RCS file: /cvsroot/plexus/ivory/xdocs/axiscomponent.xml,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- axiscomponent.xml	19 Mar 2003 12:29:25 -0000	1.4
+++ axiscomponent.xml	4 May 2003 20:25:56 -0000	1.5
@@ -48,7 +48,12 @@
       </subsection>
       <subsection name="Security">
         <p>
-
+          While, not much has been done with security at this point, there
+          is one nice option that exists.  It would be very possible to
+          use aspects to check if an invocation on a class is a SOAP request.
+          If it is, then one could just execute the method 
+          MessageContext.getCurrentContext() which should give you the
+          appropriate information about the particular SOAP invocation.
         </p>
       </subsection>
       <subsection name="API Method">
@@ -116,21 +121,22 @@
       <p>
         However, in the AxisService we embed the AxisEngine (aka, the
         AxisServer) into an Avalon component.  By doing so we are able
-        to do things.  First, we are able to provide the AxisServer to the servlets 
-        and to other avalon components.  There are classes in the 
-        org.apache.ivory.axis.servlet package which extend the Axis servlets to provide 
-        axis to the ServiceManager so we can look up the AxisService and provide the servlets
+        to do two things.  First, we are able to provide the AxisServer to the
+        servlets as well as avalon components.  There are classes in the 
+        org.apache.ivory.axis.servlet package which extend the Axis servlets 
+        so we can look up the AxisService and provide the servlets
         with the AxisEngine.  Second, we are able to use the AxisEngine in our service
-        to dynamically configure components as SOAP services.
+        to dynamically configure components as SOAP services.  This is the real
+        meat of the Axis component.
       </p>
       <subsection name="Internal Axis Configuration">
         <p>
           Axis's primary mode of configuration resolves around WSDD
-          deployment descriptors.  Normally, he AdminServlet is the primary 
-          point of service deployment and undeployment.  The WSDD configuration
-          model is somewhat intertwined all throughout Axis.  While Axis starts
-          to have its own internal configuration model, it fails in some
-          respects.
+          deployment descriptors.  Normally, the AdminServlet is the primary 
+          point of service deployment and undeployment using WSDD.  The WSDD
+          configuration model is somewhat intertwined all throughout Axis.  While 
+          Axis starts to have its own internal configuration model, it fails in
+          some respects.
         </p>
         <p>
           The good news is that it is still workable to have a configuration
@@ -157,16 +163,20 @@
       </subsection>
       <subsection name="Axis Providers">
         <p>
-          Axis contains several default service handlers - usually called 
-          "Providers."  These providers are responsible for actually creating
-          the java class that the soap xml maps to (Serialization is handled
-          by the TypeMapping and other org.apache.axis.encoding.* classes).
+          Axis contains several default service handlers which encapsulate services.
+          They are usually called "Providers."  These providers are responsible
+          for the actual instantiation of your java classes that the soap xml maps to
+          (Serialization is handled by the TypeMapping and other 
+          org.apache.axis.encoding.* classes).
         </p>
         <p>
-          By setting the appropriate options on the SOAPService we are able to
-          tell the Axis JavaProvider to load in objects relatively easily.
-          However, we use a custom provider - AvalonProvider - that provides
-          java objects from the ServiceManager.
+          By setting the appropriate options on the SOAPService (which is the
+          encapsulation of a SOAP invocation) we are able to create new
+          services relatively easily (see DefaultAxisService). However, if we
+          are exposing Avalon services we need to use a different provider other
+          than the JavaProvider bundled with Axis.  The AvalonProvider extends
+          JavaProvider to do this.  Instead of creating new objects, it just
+          finds the object in the service manager.
         </p>
       </subsection>
       <subsection name="Serialization">