You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsrf-dev@ws.apache.org by ip...@apache.org on 2004/12/23 01:41:42 UTC
svn commit: r123156 - incubator/apollo/trunk/src/site/content/xdocs/tutorial
Author: ips
Date: Wed Dec 22 16:41:41 2004
New Revision: 123156
URL: http://svn.apache.org/viewcvs?view=rev&rev=123156
Log:
reformatted and edited
Modified:
incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml
incubator/apollo/trunk/src/site/content/xdocs/tutorial/deploy.xml
incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml
incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml
incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml
incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml
incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml
incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml
incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml Wed Dec 22 16:41:41 2004
@@ -1,33 +1,46 @@
<?xml version="1.0"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
+
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+ "http://forrest.apache.org/dtd/document-v20.dtd">
+
<document>
- <header>
- <title>Writing Callback Objects.</title>
- </header>
- <body>
- <section id="intro">
- <title>Introduction</title>
- <p>Callback objects are how you keep the front-end resource properties in synch with your backend. You write callback objects and register them with your non-static resource properties. The registration is typically done upon initialization of the Resource class, in the init method. An example of this can be seen in the FileSystemResource.</p>
- <p>There are two interfaces which can be implemented when writing a Callback object. Which one you choose will depend on how you would like each ResourceProperty to behave:</p>
-<ol>
- <li>org.apache.ws.resource.properties.ResourcePropertyCallback - Implement this interface if the resource property will change (not static i.e. "name"), but is not modifiable externally. It provides the ability to refresh the front-end with the current state of your backend.</li>
- <li>org.apache.ws.resource.properties.SetResourcePropertyCallback - Implement this interface if the resource property is modifiable, thus methods like insert, update and delete <em>may</em> be appropriate. This interface extends the ResourcePropertyCallback. </li>
-</ol>
- </section>
- <section id="refresh">
- <title>Implementing the ResourcePropertyCallback</title>
- <p>The ResourcePropertyCallback is a way for you to synchronize the front-end resource properties with the backend. The interface defines one method:</p>
- <source>ResourceProperty refreshProperty( ResourceProperty prop );</source>
- <p>Notice the operation is passed a ResourceProperty. The ResourceProperty contains methods for pulling the values out of the property. You can get an iterator, in the case of a list, or can retrieve via an index: ResourceProperty.get(i)</p>
- <p>The returned property will be an XmlBean type. What "type" will depend on your method description in your wsdl. If the type is a schema-defined type (string, int etc.), XmlBeans provides objects specific to those types. In the BackupFrequencyCallback we see that BackupFrequency was an xsd:int and so the XmlBean type is XmlInt:</p>
-<source>public ResourceProperty refreshProperty(ResourceProperty prop)
+
+ <header>
+ <title>Writing Callback Objects</title>
+ </header>
+
+ <body>
+
+ <section id="intro">
+ <title>Introduction</title>
+ <p>Callback objects provide a means to keep resource properties in synch with the corresponding
+ state in the backend managed resource. You write callback objects and register them on any
+ non-static resource properties. The registration is typically done upon initialization of the
+ Resource class, in its <code>init</code> method. An example of this can be seen in the FileSystemResource.</p>
+ <p>There are two interfaces which can be implemented when writing a Callback object.
+ Which one you choose will depend on how you would like each ResourceProperty to behave:</p>
+ <ol>
+ <li>org.apache.ws.resource.properties.ResourcePropertyCallback - Implement this interface if the resource property will change (not static i.e. "name"), but is not modifiable externally. It provides the ability to refresh the front-end with the current state of your backend.</li>
+ <li>org.apache.ws.resource.properties.SetResourcePropertyCallback - Implement this interface if the resource property is modifiable, thus methods like insert, update and delete
+ <em>may</em> be appropriate. This interface extends the ResourcePropertyCallback.
+ </li>
+ </ol>
+ </section>
+
+ <section id="refresh">
+ <title>Implementing a ResourcePropertyCallback</title>
+ <p>The ResourcePropertyCallback is a way for you to synchronize the front-end resource properties with the backend. The interface defines one method:</p>
+ <source>ResourceProperty refreshProperty( ResourceProperty prop );</source>
+ <p>Notice the operation is passed a ResourceProperty. The ResourceProperty contains methods for pulling the values out of the property. You can get an iterator, in the case of a list, or can retrieve via an index: ResourceProperty.get(i)</p>
+ <p>The returned property will be an XmlBean type. What "type" will depend on your method description in your wsdl. If the type is a schema-defined type (string, int etc.), XmlBeans provides objects specific to those types. In the BackupFrequencyCallback we see that BackupFrequency was an xsd:int and so the XmlBean type is XmlInt:</p>
+ <source>public ResourceProperty refreshProperty(ResourceProperty prop)
{
XmlInt xInt = (XmlInt) prop.get( 0 );
xInt.setIntValue( m_fileSystem.getBackupFrequency() );
return prop;
}</source>
- <p>In the case of complex types, XmlBeans will generate a type and that is what will be passed to the operation. We can see an example of this in OptionsCallback:</p>
-<source> public ResourceProperty refreshProperty( ResourceProperty prop )
+ <p>In the case of complex types, XmlBeans will generate a type and that is what will be passed to the operation. We can see an example of this in OptionsCallback:</p>
+ <source> public ResourceProperty refreshProperty( ResourceProperty prop )
{
Iterator iterator = prop.iterator( );
while ( iterator.hasNext( ) )
@@ -45,17 +58,21 @@
return prop;
}</source>
- <p>In both cases the objects (XmlInt and Options) all extend XmlObject as a common class, however it is useful to utilize the defined class' operations directly.</p>
-<p>Once you have a handle on the passed-in object, you will need to set the equivalent value, from the current state of your backend, on the passed-in object.</p><p>The refreshProperty method is called before GetResourceProperty, GetMultipleResourceProperties and QueryResourceProperties requests.</p>
- </section>
- <section id="setresource">
- <title>Implementing the SetResourcePropertyCallback</title>
- <p>The SetResourcePropertyCallback is a way for the backend to be changed via requests to the front-end resource properties. The SetResourcePropertyCallback interface defines three methods:</p><source>void deleteProperty( QName propQName );
+ <p>In both cases the objects (XmlInt and Options) all extend XmlObject as a common class, however it is useful to utilize the defined class' operations directly.</p>
+ <p>Once you have a handle on the passed-in object, you will need to set the equivalent value, from the current state of your backend, on the passed-in object.</p>
+ <p>The refreshProperty method is called before GetResourceProperty, GetMultipleResourceProperties and QueryResourceProperties requests.</p>
+ </section>
+ <section id="setresource">
+ <title>Implementing the SetResourcePropertyCallback</title>
+ <p>The SetResourcePropertyCallback is a way for the backend to be changed via requests to the front-end resource properties. The SetResourcePropertyCallback interface defines three methods:</p>
+ <source>void deleteProperty( QName propQName );
void insertProperty( Object[] prop );
void updateProperty( Object[] prop );</source>
- <p>The operations will follow the same semantics as are defined in the specification and will be restricted to the bounds of you schema. If you define an element with a maxOccurs="1", and attempt to add (insertProperty) another item to it, Apollo will generate a fault.</p>
-<p>The CommentCallback illustrates how these methods <em>may</em> be implemented:</p>
-<source> public void deleteProperty( QName propQName )
+ <p>The operations will follow the same semantics as are defined in the specification and will be restricted to the bounds of you schema. If you define an element with a maxOccurs="1", and attempt to add (insertProperty) another item to it, Apollo will generate a fault.</p>
+ <p>The CommentCallback illustrates how these methods
+ <em>may</em> be implemented:
+ </p>
+ <source> public void deleteProperty( QName propQName )
{
return; // no need to implement - Apollo will never call delete for a prop whose minOccurs != 0
}
@@ -70,12 +87,17 @@
{
insertProperty( prop );
}
-</source>
-<p>Notice that the deleteProperty method does nothing since the implementor knew that the method would never be called since the schema forbids it. The updateProperty simply hands-off to the insertProperty since the implementor knew that an update on the backend is the same as an insert. The insertProperty is the workhorse method and takes the Object[], obtains the value from it and sets it on the backend.</p>
- </section>
- <section id="register">
- <title>registering</title>
- <p>Once you've written your callback objects you will need to register them with the resource properties. This is done in the init() method of your Resource implementation class. See the FileSystemResource for more information.</p>
- </section>
- </body>
+ </source>
+ <p>Notice that the deleteProperty method does nothing since the implementor knew that the method would never be called since the schema forbids it. The updateProperty simply hands-off to the insertProperty since the implementor knew that an update on the backend is the same as an insert. The insertProperty is the workhorse method and takes the Object[], obtains the value from it and sets it on the backend.</p>
+ </section>
+
+ <section id="register">
+ <title>Registering a Callback</title>
+ <p>Once you've written your callback objects you will need to register them with the resource properties.
+ This is done in the <code>init</code> method of your Resource implementation class. See the FileSystemResource
+ for an example.</p>
+ </section>
+
+ </body>
+
</document>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/deploy.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/deploy.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/deploy.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/deploy.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/deploy.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/deploy.xml Wed Dec 22 16:41:41 2004
@@ -1,19 +1,30 @@
<?xml version="1.0"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
+
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+ "http://forrest.apache.org/dtd/document-v20.dtd">
+
<document>
- <header>
- <title>Deploy the Webapp to Tomcat</title>
- </header>
- <body>
- <section>
- <title>Introduction</title>
- <p>This section will discuss how to deploy the webapp into the Tomcat container.</p>
- </section>
- <section id="deploy">
- <title>Deploying the WebApp</title>
- <p>Once you have deployed your service to the webapp, you will need to deploy the webapp to the Tomcat container.</p>
- <p>Deploying to Tomcat entails copying the webapp dir "wsrf" to TOMCAT_HOME/webapps directory. </p>
- <note>The directory name under the TOMCAT_HOME/webapps directory denotes the webapp context. Pleanse ensure after copying, that there is a "wsrf" directory under TOMCAT_HOME/webapps</note>
- </section>
- </body>
+
+ <header>
+ <title>Deploying the Apollo Webapp to Tomcat</title>
+ </header>
+
+ <body>
+
+ <section>
+ <title>Introduction</title>
+ <p>This section will discuss how to deploy the Apollo web application into the Tomcat container.</p>
+ </section>
+
+ <section id="deploy">
+ <title>Deploying the WebApp</title>
+ <p>Once you have deployed your service to the Apollo webapp, you will need to deploy the webapp to the
+ Tomcat container.</p>
+ <p>Deploying to Tomcat entails copying the webapp dir "wsrf" to <code>TOMCAT_HOME/webapps</code> directory. </p>
+ <note>The directory name under the TOMCAT_HOME/webapps directory denotes the webapp context.
+ Please ensure after copying, that there is a "wsrf" directory under <code>TOMCAT_HOME/webapps</code></note>
+ </section>
+
+ </body>
+
</document>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml Wed Dec 22 16:41:41 2004
@@ -1,28 +1,42 @@
<?xml version="1.0"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
+
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+ "http://forrest.apache.org/dtd/document-v20.dtd">
+
<document>
- <header>
- <title>Writing a Home class</title>
- </header>
- <body>
- <section id="intro">
- <title>Introduction</title>
- <p>This section will describe how to write a home for your resource class. The home is used to lookup the resource instance. It can act as a factory for creating instances upon request, or build all instances. It is meant to be the entry point for locating a resource instance.</p>
- </section>
- <section id="class-declaration">
- <title>Class Declaration</title>
- <p>When declaring your "home" you <strong>should</strong> extend AbstractResourceHome. Extending AbstractResourceHome will provide services for caching instances and looking them up. It will also ensure that the correct interfaces are implemented so that Apollo can interact with your home.</p>
-<p>The FileSystemHome extends AbstractResourceHome and implements Serializable:</p>
-<source>public class FileSystemHome
+
+ <header>
+ <title>Writing a Home class</title>
+ </header>
+
+ <body>
+
+ <section id="intro">
+ <title>Introduction</title>
+ <p>This section will describe how to write a home for your resource class. The home is used to lookup the resource instance. It can act as a factory for creating instances upon request, or build all instances. It is meant to be the entry point for locating a resource instance.</p>
+ </section>
+
+ <section id="class-declaration">
+ <title>Class Declaration</title>
+ <p>When declaring your "home" you
+ <strong>should</strong> extend AbstractResourceHome. Extending AbstractResourceHome will provide services for caching instances and looking them up. It will also ensure that the correct interfaces are implemented so that Apollo can interact with your home.
+ </p>
+ <p>The FileSystemHome extends AbstractResourceHome and implements Serializable:</p>
+ <source>public class FileSystemHome
extends AbstractResourceHome
implements Serializable</source>
- </section>
- <section id="ops">
- <title>Operations</title>
- <p>If you extend AbstractResourceHome, the only required operation you will need to invoke is:</p>
- <source>public Resource getInstance( ResourceContext resourceContext )</source>
- <p>The getInstance(...) operation provides the ability for you to intercept the request for retrieving an instance. In the FileSystem example we use the operation to determine if the requested resource instance is one of our expected "filesystems", if it is not we throw an exception.</p>
- <source>public Resource getInstance( ResourceContext resourceContext )
+ </section>
+
+ <section id="ops">
+ <title>Operations</title>
+ <p>If you extend AbstractResourceHome, the only required operation you will need to implement is:
+ </p>
+ <source>public Resource getInstance( ResourceContext resourceContext )</source>
+ <p>The getInstance(...) operation provides the ability for you to intercept the request for
+ retrieving an instance. In the FileSystem example, we use the operation to determine
+ if the requested resource instance is a valid filesystems (i.e. one that is being managed via WSRF);
+ if it is not, we throw an exception.</p>
+ <source>public Resource getInstance( ResourceContext resourceContext )
throws ResourceException,
ResourceContextException,
ResourceUnknownException
@@ -59,8 +73,13 @@
}
return resource;
}</source>
- <p>Notice the method makes calls to find(...) and createInstance(...). These operations are generic and implemented in the AbstractResourceHome, they provide functions like caching an instance and instantiating one.</p>
-<note>Many of the operations in the AbstractResourceHome may be overridden in your extension home class, if you have a need to extend its functionality.</note>
- </section>
- </body>
+
+ <p>Notice the method makes calls to find(...) and createInstance(...). These operations are
+ provided by the AbstractResourceHome superclass. They provide functions like caching and
+ instantiating instances.</p>
+ <note>Many of the operations in the AbstractResourceHome may be overridden in your Home
+ class, if you have a need to extend its functionality.</note>
+ </section>
+
+ </body>
</document>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml Wed Dec 22 16:41:41 2004
@@ -6,7 +6,7 @@
<document>
<header>
- <title>Apollo Tutorial</title>
+ <title>Apollo Tutorial</title>
</header>
<body>
@@ -18,15 +18,33 @@
that represents a Unix filesystem. The process is broken down into the following steps:
</p>
<ol>
- <li><a href="wsdl.html">Write the WSDL for the service</a></li>
- <li><a href="wsdl2java.html">Run Apollo's Wsdl2Java tool on the WSDL</a></li>
- <li><a href="service.html">Create the service class and add business logic to it</a></li>
- <li><a href="resource.html">Create the resource class which will maintain state for a resource instance</a></li>
- <li><a href="callback.html">Create backend callback objects.</a></li>
- <li><a href="home.html">Create the home class and add business logic to it</a></li>
- <li><a href="webapp.html">Deploy the service to the Apollo webapp</a></li>
- <li><a href="deploy.html">Deploy the Apollo webapp to Tomcat</a></li>
- <li><a href="test.html">Start Tomcat and send some test requests to the service</a></li>
+ <li>
+ <a href="wsdl.html">Write the WSDL for the service.</a>
+ </li>
+ <li>
+ <a href="wsdl2java.html">Run Apollo's Wsdl2Java tool on the WSDL.</a>
+ </li>
+ <li>
+ <a href="service.html">Create the service class and add business logic to it.</a>
+ </li>
+ <li>
+ <a href="resource.html">Create the resource class which will maintain state for a resource instance.</a>
+ </li>
+ <li>
+ <a href="callback.html">Create backend callback objects for all non-static resource properties.</a>
+ </li>
+ <li>
+ <a href="home.html">Create the home class and add instance lookup logic to it.</a>
+ </li>
+ <li>
+ <a href="webapp.html">Deploy the service to the Apollo webapp.</a>
+ </li>
+ <li>
+ <a href="deploy.html">Deploy the Apollo webapp to Tomcat.</a>
+ </li>
+ <li>
+ <a href="test.html">Start Tomcat and send some test requests to the service.</a>
+ </li>
</ol>
</section>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml Wed Dec 22 16:41:41 2004
@@ -1,37 +1,71 @@
<?xml version="1.0"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
+
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+ "http://forrest.apache.org/dtd/document-v20.dtd">
+
<document>
- <header>
- <title>Writing a Resource Class</title>
- </header>
- <body>
- <section id="intro">
- <title>Introduction</title>
- <p>
- The resource class is the stateful instance-representation of your of your Web service. The resource maintains the resource id and the ResourcePropertySet. The resource id is the unique identifier for an instance our your Web service. It allows you to have multiple versions of the same Web service, each with it's own stateful properties. The stateful properties are represented by the ResourcePropertySet. The ResourcePropertySet is the Java representation of the Resource Properties document defined in the schema section of your WSDL file.
- </p>
- <p>When a request is made for a Web service it is expected to contain a WS-Addressing header which has an entry for the resource id. When Apollo receives the request it will use the resource id to "identify" the correct instance of a Web Service for use when "servicing" a request.</p>
- <p>This section will discuss how to write a resource class. Please note that the eventual goal will be to generate most of this code for you via code generation. Currently, however, you will need to implement this class by hand.</p>
- <p>Initially, you should model your resource off of the included FileSystemResource example. This will ensure you will write a working resource class.</p>
- </section>
- <section id="class-declaration">
- <title>Class Declaration</title>
- <p>When declaring your Resource class you MUST implement org.apache.ws.resource.Resource which provides the necessary operations for dealing with the ResourcePropertySet and the resource's id. When defining a singleton service</p><note>The resource id is a custom WS-Addressing header element which you will define in your configuration information for your service.</note>
-<p>Optionally, you may also implement PersistentResource, for providing hooks for persistence, and ScheduledResourceTerminationResource, for adding the ability to schedule when the resource should be terminated.</p>
-<p>The FileSystemResource's class declarations is as follows:</p>
-<source>public class FileSystemResource extends
+
+ <header>
+ <title>Writing a Resource Class</title>
+ </header>
+
+ <body>
+
+ <section id="intro">
+ <title>Introduction</title>
+ <p>
+ The resource class is the stateful instance-representation of your of your Web service.
+ The resource maintains the resource id and the ResourcePropertySet. The resource id is
+ the unique identifier for an instance of your Web service. It allows you to have multiple
+ resource instances, each with their own state, fronted by the same Web service.
+ The stateful properties are represented by the ResourcePropertySet. The ResourcePropertySet
+ is the Java representation of the Resource Properties document defined in the schema section
+ of your WSDL file.
+ </p>
+ <p>When a request is made for a Web service, it is expected to contain a WS-Addressing
+ header which contains the resource id. When Apollo receives the request it
+ will use the resource id to look up the corresponding resource instance to
+ service the request.</p>
+ <p>This section will discuss how to write a resource class. Please note that the eventual
+ goal will be to generate most of this code for you via code generation. Currently,
+ however, you will need to write this class by hand.</p>
+ <p>Initially, you should model your resource off of the included FileSystemResource example.
+ This will ensure you will write a valid resource class.</p>
+ </section>
+
+ <section id="class-declaration">
+ <title>Class Declaration</title>
+ <p>When declaring your Resource class you MUST implement org.apache.ws.resource.Resource which provides the necessary operations for dealing with the ResourcePropertySet and the resource's id. When defining a singleton service</p>
+ <note>The resource id is a custom WS-Addressing header element which you will define in your configuration information for your service.</note>
+ <p>Optionally, you may also implement PersistentResource, for providing hooks for persistence, and ScheduledResourceTerminationResource, for adding the ability to schedule when the resource should be terminated.</p>
+ <p>The FileSystemResource's class declarations is as follows:</p>
+ <source>public class FileSystemResource extends
AbstractFileSystemResource</source>
<p>Notice that we've extended a base abstract class. This allows us to focus solely on the init() operation for registering callback objects and initializing the values of our ResourceProperties.</p>
-<p>The AbstractFileSystemResource class implements Resource, PropertiesResource, ScheduledResourceTerminationResource. We've "abstracted" the non-user specific code to the abstract class so that the user can focus on their initialization.</p>
- </section>
-<section id="classvars">
- <title>Class Variables</title>
- <p> The class variables of AbstractFileSystemResource should include the resource id and the ResourcePropertySet. The ResourcePropertySet will be the instance of the ResourceProperties Document associated with this resource, with this resource id.</p>
-<note>Since it is not a requirement to have a resource property in your service, there is a PropertiesResource interface to denote that properties are being used.</note>
- </section>
- <section id="ops">
- <title>Operations</title>
- <p>The operations are defined by the interfaces you implement and are mainly setters and getters for the ResourcePropertySet and the resource id. There are also operations which allow you to initialize your resource or destroy your resource (init(..) and destroy()). The operations allow you to do setup, initializing your resource properties, adding callback objects, and cleanup in your resource class. The exception, seen in the AbstractFileSystemResource, are the operations for ScheduledResourceTerminationResource in which we've provided a utility class (ResourcePropertyUtils) to help you implement these methods.</p><note>The use of ResourcePropertyUtils is purely optional and is meant to help the implementor.</note>
- </section>
- </body>
+ <p>The AbstractFileSystemResource class implements Resource, PropertiesResource, ScheduledResourceTerminationResource. We've "abstracted" the non-user specific code to the abstract class so that the user can focus on their initialization.</p>
+ </section>
+
+ <section id="vars">
+ <title>Instance Variables</title>
+ <p> The instance variables of AbstractFileSystemResource should include the resource id and the
+ ResourcePropertySet. The ResourcePropertySet will be the instance of the ResourceProperties
+ Document associated with this resource instance.</p>
+ <note>Since it is not a requirement to have resource properties in your service,
+ there is a PropertiesResource interface to denote that properties are being exposed.</note>
+ </section>
+
+ <section id="methods">
+ <title>Methods</title>
+ <p>The methods are defined by the interfaces you implement and are mainly setters and
+ getters for the ResourcePropertySet and the resource id. There are also operations
+ which allow you to initialize your resource or destroy your resource (init(..) and
+ destroy()). The operations allow you to do setup, initializing your resource properties,
+ adding callback objects, and cleanup in your resource class. The exception, seen in the
+ AbstractFileSystemResource, are the operations for ScheduledResourceTerminationResource
+ in which we've provided a utility class (ResourcePropertyUtils) to help you implement
+ these methods.</p>
+ <note>The use of ResourcePropertyUtils is purely optional and is meant to help the implementor.</note>
+ </section>
+
+ </body>
</document>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml Wed Dec 22 16:41:41 2004
@@ -1,48 +1,71 @@
<?xml version="1.0"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
+
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+ "http://forrest.apache.org/dtd/document-v20.dtd">
+
<document>
- <header>
- <title>Writing a Service Class</title>
- </header>
- <body>
- <section id="intro">
- <title>Introduction</title>
- <p>
- The service class is the representation of your WSDL file as a Web service. The public operations in the service class are the operations which will be invokable when a SOAP request is received for your service.
- </p>
- <p>This section will discuss how to write a service class. Please note that the eventual goal will be to generate most of this code for you via code generation. Currently, however, you will need to implement these classes by hand.</p>
- <p>Initially, you should model your service off of the included FileSystemService example. This will ensure you will write a working service.</p>
- </section>
- <section id="what-files">
- <title>What files will need to be written?</title>
- <p>The provided example "FileSystem" includes a FileSystemService. The FileSystemService extends AbstractFileSystemService to abstract out the code which should not need to be altered. The abstract class mainly consists of the specification operations (i.e. getMultipleResourceProperties) and the service class which extends this class contains the user-specific operations. In the case of FileSystemService, these operations are "mount" and "unmount".</p>
- <p>
- We recommend this structure for writing your service class, however you may write the service however you like. Our description will describe the use of the abstract class to seperate the functionality.
- </p>
- <section id="abstract">
- <title>The AbstractService class.</title>
- <p>The abstract class is the superclass for your service and will contain most of the specification-specific operations and utility operations. Our description of writing the class will be based on the example.filesystem.AbstractFileSystemService class.</p>
- <p>We will describe the class in sections:</p>
- <ol>
- <li>
- <a href="#class-declaration">Class Declaration</a>
- </li>
- <li>
- <a href="#wsrfservice">WsrfService Interface</a>
- </li>
- <li>
- <a href="#classvars">Class Variable</a>
- </li>
- <li>
- <a href="#ops">Operations</a>
- </li>
- </ol>
- <section id="class-declaration">
- <title>Class Declaration</title>
- <p>When declaring your abstract class, you must implement <code>org.apache.ws.resource.handler.WsrfService</code>. This interface provides methods for initialization, obtaining the ResourceContext and getting the SoapMethodNameMap use for mapping incoming request QName's to method name for a given object. It basically ensures that Apollo can interact with your service class.</p>
- <p>The AbstractFileSystemService's class declaration is as follows:</p>
- <source>
- <strong> abstract class AbstractFileSystemService
+
+ <header>
+ <title>Writing a Service Class</title>
+ </header>
+
+ <body>
+
+ <section id="intro">
+ <title>Introduction</title>
+ <p>
+ The service class is the representation of your WSDL file as a Web service.
+ The public methods in the service class correspond to the SOAP operations
+ exposed by your Web service.
+ </p>
+ <p>This section will discuss how to write a service class. Please note that
+ the eventual goal will be to generate most of this code for you via code generation.
+ Currently, however, you will need to implement these classes by hand.</p>
+ <p>Initially, you should model your service off of the included FileSystemService example.
+ This will ensure you will write a valid service.</p>
+ </section>
+
+ <section id="classes">
+ <title>What classes will need to be written?</title>
+ <p>The provided example "FileSystem" includes a FileSystemService class.
+ The FileSystemService extends AbstractFileSystemService, which contains
+ any code which should not need to be altered. The abstract class mainly
+ consists of the specification operations (i.e. getMultipleResourceProperties),
+ while the service class which extends this class contains the "custom" operations.
+ In the case of FileSystemService, these operations are "mount" and "unmount".</p>
+ <p>
+ We recommend this structure for writing your service class, however you may write
+ the service however you like. Our description will describe the use of the abstract
+ class to separate the functionality.
+ </p>
+
+ <section id="abstract">
+ <title>The AbstractService class.</title>
+ <p>The abstract class is the superclass for your service and will contain most of the specification-specific operations and utility operations. Our description of writing the class will be based on the example.filesystem.AbstractFileSystemService class.</p>
+ <p>We will describe the class in sections:</p>
+ <ol>
+ <li>
+ <a href="#class-declaration">Class Declaration</a>
+ </li>
+ <li>
+ <a href="#wsrfservice">WsrfService Interface</a>
+ </li>
+ <li>
+ <a href="#classvars">Class Variable</a>
+ </li>
+ <li>
+ <a href="#ops">Operations</a>
+ </li>
+ </ol>
+
+ <section id="class-declaration">
+ <title>Class Declaration</title>
+ <p>When declaring your abstract class, you must implement
+ <code>org.apache.ws.resource.handler.WsrfService</code>. This interface provides methods for initialization, obtaining the ResourceContext and getting the SoapMethodNameMap use for mapping incoming request QName's to method name for a given object. It basically ensures that Apollo can interact with your service class.
+ </p>
+ <p>The AbstractFileSystemService's class declaration is as follows:</p>
+ <source>
+ <strong> abstract class AbstractFileSystemService
implements WsrfService,
GetResourcePropertyPortType,
GetMultipleResourcePropertiesPortType,
@@ -50,15 +73,18 @@
QueryResourcePropertiesPortType,
ImmediateResourceTerminationPortType,
ScheduledResourceTerminationPortType</strong>
- </source>
- <p>You should notice that the class implements WsrfService (described above) and various *PortType inerfaces. Each PortType interface is a Java representation of a specification's WSDL portType declaration. By implementing the PortType interface corresponding to the specification's/portTypes you are interested in, you will ensure you get the correct method signature for the method call. </p><note>As per the Web Services Resource 1.2 specification, a resource must expose resource properties and if you expose properties you MUST, at least, implement GetResourceProperty. This means your service must implement the GetResourcePropertyPortType.</note>
- <p>The packages: <strong>org.apache.ws.resource.properties.porttype</strong> and <strong>org.apache.ws.resource.lifetime.porttype</strong> contain the interfaces for the specifications. You should refer to these packages when selecting the operations you'd like to support.
- </p>
- </section>
- <section id="wsrfservice">
- <title>WsrfService Interface</title>
- <p>All services in Apollo need to implement the WsrfService interface. The interface provides operation "hooks" which will allow Apollo to interact with your service. There are currenty three operations defined by the interface:</p>
- <source> /**
+ </source>
+ <p>You should notice that the class implements WsrfService (described above) and various *PortType inerfaces. Each PortType interface is a Java representation of a specification's WSDL portType declaration. By implementing the PortType interface corresponding to the specification's/portTypes you are interested in, you will ensure you get the correct method signature for the method call. </p>
+ <note>As per the Web Services Resource 1.2 specification, a resource must expose resource properties and if you expose properties you MUST, at least, implement GetResourceProperty. This means your service must implement the GetResourcePropertyPortType.</note>
+ <p>The packages:
+ <strong>org.apache.ws.resource.properties.porttype</strong> and
+ <strong>org.apache.ws.resource.lifetime.porttype</strong> contain the interfaces for the specifications. You should refer to these packages when selecting the operations you'd like to support.
+ </p>
+ </section>
+ <section id="wsrfservice">
+ <title>WsrfService Interface</title>
+ <p>All services in Apollo need to implement the WsrfService interface. The interface provides operation "hooks" which will allow Apollo to interact with your service. There are currenty three operations defined by the interface:</p>
+ <source> /**
* Returns the SoapMethodNameMap for the Service, to determine
* which method to invoke for an incoming request.
*
@@ -77,41 +103,47 @@
* Initialization method.
*/
public void init( );</source>
- <p>The getMethodNameMap() returns a SoapMethodNameMap implementation which contains mappings of WSDL operation QNames to Java method names. If you have custom operations you will need to create an instance of ServiceSoapMethodName and add mappings for you operations.</p>
- <p>The getResourceContext() operation returns the ResourceContext associated with this service. This method may be left abstract in this class and later implemented in the Service extension of your abstract class.</p>
- <p>The init() method is provided to give you an opportunity to initialize members for your Service (i.e. ServiceSoapMethodName )</p>
- </section>
- <section id="classvars">
- <title>Class Variables</title>
- <p>The class variables which should be defined are:</p>
- <ol>
- <li>
- <strong>TARGET_NSURI</strong> - The target namespace of your sevice's WSDL file.</li>
- <li>
- <strong>TARGET_NSPREFIX</strong> - The target prefix to be associated with your service's namespace.</li>
- </ol>
- <p> In the AbstractFileSystem we have:</p>
- <source>public static final String TARGET_NSURI = "http://ws.apache.org/resource/example/filesystem";
+ <p>The getMethodNameMap() returns a SoapMethodNameMap implementation which contains mappings of WSDL operation QNames to Java method names. If you have custom operations you will need to create an instance of ServiceSoapMethodName and add mappings for you operations.</p>
+ <p>The getResourceContext() operation returns the ResourceContext associated with this service. This method may be left abstract in this class and later implemented in the Service extension of your abstract class.</p>
+ <p>The init() method is provided to give you an opportunity to initialize members for your Service (i.e. ServiceSoapMethodName )</p>
+ </section>
+ <section id="classvars">
+ <title>Class Variables</title>
+ <p>The class variables which should be defined are:</p>
+ <ol>
+ <li>
+ <strong>TARGET_NSURI</strong> - The target namespace of your sevice's WSDL file.
+ </li>
+ <li>
+ <strong>TARGET_NSPREFIX</strong> - The target prefix to be associated with your service's namespace.
+ </li>
+ </ol>
+ <p> In the AbstractFileSystem we have:</p>
+ <source>public static final String TARGET_NSURI = "http://ws.apache.org/resource/example/filesystem";
public static final String TARGET_NSPREFIX = "fs";</source>
- <p>Notice the fields are "public static final" since they should not change and are easily accessible.
- </p>
- </section>
- <section id="ops">
- <title>Operations</title>
- <p>The operations which are defined in the abstract class should be operations which typically should not need to be touched. The specification operations are a prime example. Upon looking at the AbstractFileSystem class, we see the operations defined for methods like: getMultipleResourceProperties(..). The body of these methods are similar in that they hand the invocation off to a Provider class:</p>
- <source>public GetMultipleResourcePropertiesResponseDocument getMultipleResourceProperties( GetMultipleResourcePropertiesDocument requestDoc )
+ <p>Notice the fields are "public static final" since they should not change and are easily accessible.
+ </p>
+ </section>
+ <section id="ops">
+ <title>Operations</title>
+ <p>The operations which are defined in the abstract class should be operations which typically should not need to be touched. The specification operations are a prime example. Upon looking at the AbstractFileSystem class, we see the operations defined for methods like: getMultipleResourceProperties(..). The body of these methods are similar in that they hand the invocation off to a Provider class:</p>
+ <source>public GetMultipleResourcePropertiesResponseDocument getMultipleResourceProperties( GetMultipleResourcePropertiesDocument requestDoc )
{
return new GetMultipleResourcePropertiesProvider( getResourceContext( ) ).getMultipleResourceProperties( requestDoc );
}</source>
- <p>Notice the GetMultipleResourcePropertiesProvider class being used. Providers are used to handle the specification method calls. It provides a way to encapsulate the functionalty needed to handle a method call for a specific specification. Each specification operation will have an equivalent *Provider class to handle a particular class.</p>
- <p>The packages: <strong>org.apache.ws.resource.properties.porttype.impl</strong> and <strong>org.apache.ws.resource.lifetime.porttype.impl</strong> contain the Providers for the methods of the specifications. You should refer to these packages when implementing the specification operations.
- </p>
- </section>
- </section>
- <section id="service">
- <title>The Service class.</title>
- <p>The service class is the extension of the abstract class we previously outlined. Because of the extension you will need to implement the required method getResourceContext(). The ResourceContext should be passed in the constructor to the class and be maintained as a class variable. The ResourceContext will be passed, upon construction, to the Service via the Home class. </p><p>The Service class should contain any custom operations as were defined in the WSDL for the service. The safest way to handle the parameters and return type of the methods is to simply use XmlObject:</p>
- <source> public XmlObject mount( XmlObject requestDoc )
+ <p>Notice the GetMultipleResourcePropertiesProvider class being used. Providers are used to handle the specification method calls. It provides a way to encapsulate the functionalty needed to handle a method call for a specific specification. Each specification operation will have an equivalent *Provider class to handle a particular class.</p>
+ <p>The packages:
+ <strong>org.apache.ws.resource.properties.porttype.impl</strong> and
+ <strong>org.apache.ws.resource.lifetime.porttype.impl</strong> contain the Providers for the methods of the specifications. You should refer to these packages when implementing the specification operations.
+ </p>
+ </section>
+ </section>
+
+ <section id="service">
+ <title>The Service class.</title>
+ <p>The service class is the extension of the abstract class we previously outlined. Because of the extension you will need to implement the required method getResourceContext(). The ResourceContext should be passed in the constructor to the class and be maintained as a class variable. The ResourceContext will be passed, upon construction, to the Service via the Home class. </p>
+ <p>The Service class should contain any custom operations as were defined in the WSDL for the service. The safest way to handle the parameters and return type of the methods is to simply use XmlObject:</p>
+ <source> public XmlObject mount( XmlObject requestDoc )
{
try
{
@@ -122,9 +154,13 @@
throw new JAXRPCException( xe );
}
}
-</source>
- <p>XmlBeans will generate strongly typed objects for the types defined in the schema section of your WSDL document, and these types may be used, however if you are unsure which type will get passed to your operation you can be sure it will be XmlObject since it is the base class for all objects in XmlBeans.</p>
- </section>
- </section>
- </body>
+ </source>
+ <p>XmlBeans will generate strongly-typed objects for the types defined in the schema section of your WSDL document, and these types may be used, however if you are unsure which type will get passed to your operation you can be sure it will be XmlObject since it is the base class for all objects in XmlBeans.</p>
+
+ </section>
+
+ </section>
+
+ </body>
+
</document>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml Wed Dec 22 16:41:41 2004
@@ -1,31 +1,62 @@
<?xml version="1.0"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
+
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+ "http://forrest.apache.org/dtd/document-v20.dtd">
+
<document>
- <header>
- <title>Testing Your Service</title>
- </header>
- <body>
- <section id="intro">
- <title>Introduction</title>
- <p>This section will describe how to test your service running in the Tomcat container.</p>
- </section>
- <section id="start">
- <title>Starting Tomcat</title>
- <p>Tomcat can be started by utilizinge the scripts under the TOMCAT_HOME/bin directory. The script most typically used is "startup.bat" (Windows) or "startup.sh" (Unix).</p>
-<p>Once Tomcat is started you can navigate to: <a href="http://localhost:8080/wsrf">http://localhost:8080/wsrf</a> to view the deployed services in the webapp.</p>
-<note>Please refer to the Tomcat documentation for more details.</note>
- </section>
- <section id="testing">
- <title>Testing the FileSystem Service</title>
- <p>The provided example FileSystem includes some scripts for sending requests to the service. The scripts can be leveredged in order to test your own services.</p>
- <p>In order to test the FileSystem service you will need to change to the tutorial directory under docs. The Ant build script contains a target for sending a SOAP request. The name of the target is "sendRequest" and in order to invoke it you must specify a request XML file. The request XML files are located in the requests subdirectory. You can invoke the call by doing the following:</p>
-<p><strong>>ant sendRequest -Dxml=./requests/QueryResourceProperties_allProps.soap</strong></p>
- </section>
- <section id="your-own">
- <title>Using the Provided Scripts to Invoke Your Service</title>
- <p>Invoking your service will entail selecting the appropriate .soap script to use. Each script is named appropriately for which specification operation it is calling. You will need to make a copy of the script and modify the WS-Addressing headers for resource id to match the entry you put in the JNDI config and the resource id number for the instance you would like to invoke. Remember this has to do with the home's implementation of getInstance() and allows you to "decide" which instances are valid for sending requests to. Once done, in order to invoke your service with your modified scripts you will need to call:</p>
- <p><strong>>ant -f soapclient.xml sendRequest -Durl=http://localhost:8080/wsrf/services/your_service -Dxml=./requests/QueryResourceProperties_allProps.soap</strong> where "your_service" represents your service endpoint name, and the script name should be the name of your modified script.</p>
-<note>You may also add an entry to build.properties for "url" which will alleviate the need to specify it on the command line.</note>
- </section>
- </body>
+
+ <header>
+ <title>Testing Your Service</title>
+ </header>
+
+ <body>
+
+ <section id="intro">
+ <title>Introduction</title>
+ <p>This section will describe how to test your service running in the Tomcat container.</p>
+ </section>
+
+ <section id="start">
+ <title>Starting Tomcat</title>
+ <p>Tomcat can be started by utilizing the scripts under the TOMCAT_HOME/bin directory.
+ The script most typically used is "startup.bat" (Windows) or "startup.sh" (Unix).</p>
+ <p>Once Tomcat is started you can navigate to:
+ <a href="http://localhost:8080/wsrf">http://localhost:8080/wsrf/services</a> to view
+ the list of deployed Web services.
+ </p>
+ <note>Please refer to the Tomcat and Axis documentation for more details.</note>
+ </section>
+ <section id="testing">
+ <title>Testing the FileSystem Service</title>
+ <p>The provided example FileSystem includes some scripts for sending requests to the service.
+ The scripts can be leveraged in order to test your own services.</p>
+ <p>In order to test the FileSystem service you will need to change to the tutorial
+ directory under docs. The Ant build script contains a target for sending a SOAP
+ request. The name of the target is "sendRequest" and in order to invoke it you
+ must specify a request XML file. The request XML files are located in the requests
+ subdirectory. You can invoke the call by doing the following:</p>
+ <p>
+ <strong>>ant sendRequest -Dxml=./requests/QueryResourceProperties_allProps.soap</strong>
+ </p>
+ </section>
+
+ <section id="your-own">
+ <title>Using the Provided Scripts to Invoke Your Service</title>
+ <p>Invoking your service will entail selecting the appropriate .soap file to use.
+ Each file is named appropriately based on the operation it contains. You will
+ need to make a copy of the file and modify the WS-Addressing header for
+ the resource id to match the entry you put in the JNDI config and the resource
+ id number for the instance you would like to invoke. Remember this has to do
+ with the home's implementation of getInstance() and allows you to "decide" which
+ instances are valid for sending requests to. Once done, in order to invoke your
+ service with your modified scripts, you will need to call:</p>
+ <p>
+ <strong>>ant -f soapclient.xml sendRequest -Durl=http://localhost:8080/wsrf/services/your_service -Dxml=./requests/QueryResourceProperties_allProps.soap</strong>
+ where "your_service" represents your service endpoint name, and the script name should be the name of your modified script.
+ </p>
+ <note>You may also add an entry to build.properties for "url" which will alleviate the need
+ to specify it on the command line.</note>
+ </section>
+
+ </body>
</document>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml Wed Dec 22 16:41:41 2004
@@ -1,27 +1,41 @@
<?xml version="1.0"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
+
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+ "http://forrest.apache.org/dtd/document-v20.dtd">
+
<document>
- <header>
- <title>Deploy the service to the Apollo webapp</title>
- </header>
- <body>
- <section id="intro">
- <title>Introduction</title>
- <p>Once you've written, and compiled, the required classes, you will need to deploy your service to the webapp. The distribution contains a "webapps" directory which contains a "wsrf" webapp. We've provided an ANT script for deploying the FileSystem example. We will discuss how the script works so you will be able to build your own scripts.</p>
- </section>
- <section id="steps">
- <title>How to manually deploy your service</title>
- <p>In this section we will describe how to manually deploy your service. We will describe each step in the process.</p>
- <ol>
- <li><strong>Copy your WSDL file.</strong>
- <p>You will need to copy your WSDL file to an appropriate location in the webapp. We recommend you put it in the wsrf/WEB-INF/classes/wsdl directory. This will allow Axis to reference it from the classpath and avoids the need to hard-code a location on your filesystem. We will use this location when registering the service in the server-config.wsdd file.</p>
- </li>
- <li><strong>Copy your classes.</strong>
- <p>You will need to copy any .class files, generated by Wsdl2Java or hand written, to the wsrf/WEB-INF/classes/ directory so that your service can be created by Axis and Apollo.</p>
- </li>
- <li><strong>Update the jndi-config.xml file.</strong>
- <p>The jndi-config.xml contains information about yoru service, resource, home and resource key. This information is necessary for Apollo to create your home and handle requests for your service. It will setup the in-memory JNDI context for your classes. Here is the entry for the FileSystem:</p>
-<source><![CDATA[ <service name="filesystem">
+
+ <header>
+ <title>Deploy the service to the Apollo webapp</title>
+ </header>
+
+ <body>
+
+ <section id="intro">
+ <title>Introduction</title>
+ <p>Once you've written and compiled the required classes, you will need to deploy
+ your service to the webapp. The distribution contains a "webapps" directory which
+ contains a "wsrf" webapp. An Ant script is provided for deploying the FileSystem
+ example. We will discuss how the script works so you will be able to build your
+ own scripts.</p>
+ </section>
+
+ <section id="steps">
+ <title>How to manually deploy your service</title>
+ <p>In this section we will describe how to manually deploy your service. We will describe each step in the process.</p>
+ <ol>
+ <li>
+ <strong>Copy your WSDL file.</strong>
+ <p>You will need to copy your WSDL file to an appropriate location in the webapp. We recommend you put it in the wsrf/WEB-INF/classes/wsdl directory. This will allow Axis to reference it from the classpath and avoids the need to hard-code a location on your filesystem. We will use this location when registering the service in the server-config.wsdd file.</p>
+ </li>
+ <li>
+ <strong>Copy your classes.</strong>
+ <p>You will need to copy any .class files, generated by Wsdl2Java or hand written, to the wsrf/WEB-INF/classes/ directory so that your service can be created by Axis and Apollo.</p>
+ </li>
+ <li>
+ <strong>Update the jndi-config.xml file.</strong>
+ <p>The jndi-config.xml contains information about yoru service, resource, home and resource key. This information is necessary for Apollo to create your home and handle requests for your service. It will setup the in-memory JNDI context for your classes. Here is the entry for the FileSystem:</p>
+ <source><![CDATA[ <service name="filesystem">
<resource name="home" type="example.filesystem.FileSystemHome">
<resourceParams>
<parameter>
@@ -43,12 +57,18 @@
</resourceParams>
</resource>
</service>]]></source>
- <p>The "name" attribute is a unique name in the config file to denote your service in JNDI. The resource "name" attribute is used for locating your home instance, and is named "home". Notice the serviceClassName points to the clasname for the service class. The same is said for the resourceClassName. The wsdlTargetNamespace is the target namespace from your WSDL.</p>
-<p>The resourceKeyName represents the WS-Addressing-header name to be used for your resource id. This can be anything you like and is configurable here. If you omit this entry, it is assumed that the service is a <strong>SINGLETON</strong> service and no resourceid is expected in the WS-Addressing headers.</p>
- </li>
- <li><strong>Update the server-config.wsdd file.</strong>
- <p>The server-config.wsdd file is an Axis-specific file for loading Web services. It is located in the wsrf/WEB-INF/ directory. The file maintains entry for each service to be loaded. An example is the FileSystem service:</p>
-<source><![CDATA[ <service name="filesystem" provider="java:WSRF" style="document" use="literal">
+ <p>The "name" attribute is a unique name in the config file to denote your service in JNDI. The resource "name" attribute is used for locating your home instance, and is named "home". Notice the serviceClassName points to the clasname for the service class. The same is said for the resourceClassName. The wsdlTargetNamespace is the target namespace from your WSDL.</p>
+ <p>The resourceKeyName represents the WS-Addressing-header name to be used for your resource id. This can be anything you like and is configurable here. If you omit this entry, it is assumed that the service is a
+ <strong>SINGLETON</strong> service and no resource id is expected in the WS-Addressing headers.
+ </p>
+ </li>
+ <li>
+ <strong>Update the server-config.wsdd file</strong>
+ <p>The server-config.wsdd file is the configuration file for the Axis SOAP engine,
+ which is bundled with Apollo. This file is located in the wsrf/WEB-INF/ directory.
+ The file contains a deployment entry for each Web service. An example is the
+ FileSystem service:</p>
+ <source><![CDATA[ <service name="filesystem" provider="java:WSRF" style="document" use="literal">
<wsdlFile>/wsdl/FileSystem.wsdl</wsdlFile>
<requestFlow>
<handler type="java:org.apache.axis.handlers.JAXRPCHandler">
@@ -57,19 +77,34 @@
</handler>
</requestFlow>
</service>]]></source>
- <p>The service "name" attribute is endopoint name and should be the same as the port's "name" attribute from your WSDL file. This will ensure people consuming your WSDL will be able to invoke your service.</p>
- <p>Notice that we've made an entry for wsdlFile which points to the /wsdl/FileSystem.wsdl. This translates to the wsdl directory under the WEB-INF/classes directory.</p>
-<p>The last part is the requestFlow. This xml fragment is necessary to ensure the requests are routed through the WS-Addressing handler. This is static and should always be present. We did not define it globally in case there were other services defined which will not use WS-Addressing.</p>
- </li>
- </ol>
- </section>
- <section id="filesys">
- <title>Deploying the FileSystem Example</title>
- <p>To deploy the FileSystem example we will need to generate XmlBean code from the WSDL, compile all classes and deploy it to the webapp. We've provided an ANT script for handling all the steps.</p>
-<p>You will need to change your directory to the docs/tutorial directory. You will then need to run the command:</p>
-<p><strong>>ant generate compile deploy</strong></p>
-<p>This will do all the necessary tasks.</p>
-<note>This step assumes you have installed Apache's ANT. If not, you can get it at: <a href="http://ant.apache.org/">Apache Ant</a></note>
- </section>
- </body>
+ <p>The service "name" attribute is the endpoint name and should be the same as the port's "name" attribute from your WSDL file.
+ This will ensure people consuming your WSDL will be able to invoke your service.</p>
+ <p>Notice that we've made an entry for wsdlFile which points to the /wsdl/FileSystem.wsdl.
+ This translates to the wsdl directory under the WEB-INF/classes directory.</p>
+ <p>The last part is the requestFlow. This xml fragment is necessary to ensure the
+ requests are routed through the WS-Addressing handler. This is static and should
+ always be present. We did not define it globally in case there were other services
+ defined which will not use WS-Addressing.</p>
+ </li>
+ </ol>
+ </section>
+
+ <section id="filesys">
+ <title>Deploying the FileSystem Example</title>
+ <p>To deploy the FileSystem example we will need to generate XmlBean code from the WSDL,
+ compile all classes and deploy it to the webapp. An Ant script is provided for handling
+ all of these steps.</p>
+ <p>You will need to change your directory to the docs/tutorial directory. You will then
+ need to run the command:</p>
+ <p>
+ <strong>>ant generate compile deploy</strong>
+ </p>
+ <p>This will do all the necessary tasks.</p>
+ <note>This step assumes you have installed Apache Ant. If not, you can get it
+ <a href="http://ant.apache.org/">here</a>
+ </note>
+ </section>
+
+ </body>
+
</document>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml
Url: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml?view=diff&rev=123156&p1=incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml&r1=123155&p2=incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml&r2=123156
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml Wed Dec 22 16:41:41 2004
@@ -18,11 +18,17 @@
<ul>
<li>XMLBeans for all XML Schema types and elements defined in the types section of the WSDL</li>
<li>an abstract base Resource class</li>
- <li>a Resource class - described <a href="resource.html">here</a></li>
+ <li>a Resource class - described
+ <a href="resource.html">here</a>
+ </li>
<li>an abstract base Service class</li>
- <li>a Service class - described <a href="service.html">here</a></li>
+ <li>a Service class - described
+ <a href="service.html">here</a>
+ </li>
<li>Callback classes for each resource property</li>
- <li>a Home class - described <a href="home.html">here</a></li>
+ <li>a Home class - described
+ <a href="home.html">here</a>
+ </li>
<li>a CustomOperationsPortType interface</li>
<li>a PropertyQNames interface</li>
<li>an Axis deploy.wsdd file</li>
@@ -35,7 +41,7 @@
<title>Using the Wsdl2Java Ant Task</title>
<p>Apollo Wsdl2Java is invoked via an Ant task, as shown by the following example:</p>
<source>
- <![CDATA[
+ <![CDATA[
<property name="wsrf.webapp.dir" location="${apollo.home}/webapps/wsrf" />
<path id="apollo.classpath.id">
@@ -56,5 +62,5 @@
</section>
</body>
-
+
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: apollo-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: apollo-dev-help@ws.apache.org