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 jr...@apache.org on 2005/06/17 23:35:40 UTC
svn commit: r191215 - in
/incubator/apollo/trunk/src/site/content/xdocs/tutorial: callback.xml
home.xml images/ images/back.gif images/next.gif index.xml resource.xml
service.xml test.xml webapp.xml wsdl.xml wsdl2java.xml
Author: jruzzi
Date: Fri Jun 17 14:35:39 2005
New Revision: 191215
URL: http://svn.apache.org/viewcvs?rev=191215&view=rev
Log:
added for wsrf
Added:
incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/
incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/back.gif (with props)
incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/next.gif (with props)
Modified:
incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.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/wsdl.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?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/callback.xml Fri Jun 17 14:35:39 2005
@@ -1,47 +1,46 @@
<?xml version="1.0"?>
-
<!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 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 of callbacks 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)
+ <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 of callbacks is typically done upon initialization of the
+ Resource class, in its <code>init</code> method. An example of this can be seen in
+ <code> FileSystemResource</code>.
+ </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>
+ <ul>
+ <li><code>org.apache.ws.resource.properties.ResourcePropertyCallback</code> - 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><code>org.apache.ws.resource.properties.SetResourcePropertyCallback</code> - Implement this interface if the resource property is modifiable, thus methods like<code> insert</code>, <code>update</code> and <code>delete</code> <em>may</em> be appropriate. This interface extends <code>ResourcePropertyCallback</code>.
+ </li>
+ </ul>
+ </section>
+ <section id="refresh">
+ <title>Implementing a ResourcePropertyCallback</title>
+ <p><code>ResourcePropertyCallback</code> 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 (<code>string</code>,<code> int</code> etc.), XmlBeans provides objects specific to those types. In <code>BackupFrequencyCallback</code> we see that <code>BackupFrequency</code> was an <code>xsd:int</code> and so the XmlBean type is <code>XmlInt</code>:
+ </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 <code>OptionsCallback</code>:
+ </p>
+ <source> public ResourceProperty refreshProperty( ResourceProperty prop )
{
Iterator iterator = prop.iterator( );
while ( iterator.hasNext( ) )
@@ -59,26 +58,28 @@
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 by Apollo before servicing 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 (<code>XmlInt</code> and<code> Options</code>) all extend <code>XmlObject</code> 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 <code>refreshProperty</code> method is called by Apache WSRF before servicing <code>GetResourceProperty</code>, <code>GetMultipleResourceProperties</code> and <code>QueryResourceProperties</code> requests.
+ </p>
+ </section>
+ <section id="setresource">
+ <title>Implementing the SetResourcePropertyCallback</title>
+ <p><code>SetResourcePropertyCallback</code> is a way for the backend to be changed via requests to the front-end resource properties. The <code>SetResourcePropertyCallback</code> 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 <code>maxOccurs="1"</code>, and attempt to add (insertProperty)
+ another item to it, Apache WSRF will generate a fault.
+ </p>
+ <p><code>CommentCallback</code> 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
+ return; // no need to implement - Apache WSRFwill never call delete for a property whose minOccurs != 0
}
public void insertProperty( Object[] propElems )
@@ -93,18 +94,18 @@
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 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>
-
+ <p>Notice that the <code>deleteProperty</code> method does nothing since the implementor knew that the method
+ would never be called since the schema forbids it. The <code>updateProperty</code> simply hands-off to the
+ <code>insertProperty</code> since the implementor knew that an update on the backend is the same as an insert. The <code>insertProperty </code> method is the workhorse method and takes the <code>Object[]</code>, 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>
+ <p><img src="images/back.gif" alt="go to the previous step"></img><a href="site:resource">Back</a> <img src="images/next.gif"
+ alt="go to the next step"></img><a href="site:home">Next</a>
+ </p>
+ </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?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/home.xml Fri Jun 17 14:35:39 2005
@@ -1,47 +1,38 @@
<?xml version="1.0"?>
-
<!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 <code>AbstractResourceHome</code>. Extending <code>AbstractResourceHome</code> will provide services for caching instances and looking them up. It will also ensure
+ that the correct interfaces are implemented so that Apache WSRF can interact with your home.
+ </p>
+ <p>The <code>FileSystemHome</code> class extends <code>AbstractResourceHome</code> and implements <code>Serializable</code>:</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 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 )
+ </section>
+ <section id="ops">
+ <title>Operations</title>
+ <p>If you extend <code>AbstractResourceHome</code>, the only required operation you will need to implement is:</p>
+ <source>public Resource getInstance( ResourceContext resourceContext )</source>
+ <p>The <code>getInstance(...)</code> 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
@@ -78,13 +69,14 @@
}
return resource;
}</source>
-
- <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>
+ <p>Notice the method makes calls to <code>find(...) </code>and <code>createInstance(...)</code>. These operations are
+ provided by the <code>AbstractResourceHome</code> superclass. They provide functions like caching and
+ instantiating instances.</p>
+ <note>Many of the operations in the <code>AbstractResourceHome</code> may be overridden in your Home
+ class, if you have a need to extend its functionality.</note>
+ <p><img src="images/back.gif" alt="go to the previous step"></img><a href="site:callback">Back</a> <img src="images/next.gif"
+ alt="go to the next step"></img><a href="site:webapp">Next</a>
+ </p>
+ </section>
+ </body>
</document>
Added: incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/back.gif
URL: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/back.gif?rev=191215&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/back.gif
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
Added: incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/next.gif
URL: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/next.gif?rev=191215&view=auto
==============================================================================
Binary file - no diff available.
Propchange: incubator/apollo/trunk/src/site/content/xdocs/tutorial/images/next.gif
------------------------------------------------------------------------------
svn:mime-type = application/octet-stream
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?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/index.xml Fri Jun 17 14:35:39 2005
@@ -1,50 +1,30 @@
<?xml version="1.0"?>
-
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
"http://forrest.apache.org/dtd/document-v20.dtd">
-
<document>
-
- <header>
- <title>Apollo Tutorial</title>
- </header>
-
- <body>
-
- <section>
- <title>Creating and Deploying a WSRF Web Service</title>
- <p>
- This tutorial will walk you through using Apollo to create and deploy a WSRF Web service
- 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 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="test.html">Start Tomcat and send some test requests to the service.</a>
- </li>
- </ol>
- </section>
-
- </body>
-
+ <header>
+ <title>Apache WSRF Tutorial</title>
+ </header>
+ <body>
+ <section>
+ <title>Creating and Deploying a WSRF Web Service</title>
+ <p>This tutorial provides a step-by-step approach to using Apache WSRF to create and deploy a WSRF-compliant Web service
+ that represents a UNIX file system. If you want to see a completed version of the UNIX file system Web service, see the <a href="site:quick">Quick Demonstration</a>.</p>
+ <p>The process consists of the following steps:</p>
+ <ol>
+ <li><a href="wsdl.html">Write the WSDL for the service.</a></li>
+ <li><a href="wsdl2java.html">Run Apache WSRF 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 maintains 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 Apache WSRF web application.</a></li>
+ <li><a href="test.html">Start Tomcat and send some test requests to the service.</a></li>
+ </ol>
+ <p>
+ <img src="images/next.gif" alt="go to the next step"/>
+ <a href="site:wsdl">Next</a>
+ </p>
+ </section>
+ </body>
</document>
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?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/resource.xml Fri Jun 17 14:35:39 2005
@@ -1,70 +1,69 @@
<?xml version="1.0"?>
-
<!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 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.
- 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 declaration 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 Apache WSRF 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.
+ Initially, you should model your resource off of the included <code>FileSystemResource</code> 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 <code>org.apache.ws.resource.Resource</code> 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 <code>PersistentResource</code>, for providing hooks for persistence,
+ and <code>ScheduledResourceTerminationResource</code>, for adding the ability to schedule when the resource
+ should be terminated.
+ </p>
+ <p>The <code>FileSystemResource</code> class declaration 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="vars">
- <title>Instance Variables</title>
- <p> The instance variables of AbstractFileSystemResource should include the resource id and the
- ResourcePropertySet. The ResourcePropertySet is the object representation of the resource
- properties 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.</p>
- </section>
-
- </body>
+ <p>Notice that we've extended a base abstract class. This allows us to focus solely on the <code>init()</code> operation for registering callback objects and initializing the values of our ResourceProperties.
+ </p>
+ <p>The <code>AbstractFileSystemResource</code> class implements <code>Resource</code>, <code>PropertiesResource</code>, and <code> ScheduledResourceTerminationResource</code>. 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 <code>AbstractFileSystemResource</code> should include the resource id and the
+ ResourcePropertySet. The ResourcePropertySet is the object representation of the resource
+ properties 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 (<code>init(..) </code>and
+ <code>destroy()</code>). The operations allow you to do setup, initializing your resource properties,
+ adding callback objects, and cleanup in your resource class.
+ </p>
+ <p><img src="images/back.gif" alt="go to the previous step"></img><a href="site:service">Back</a> <img src="images/next.gif"
+ alt="go to the next step"></img><a href="site:callback">Next</a>
+ </p>
+ </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?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/service.xml Fri Jun 17 14:35:39 2005
@@ -1,100 +1,80 @@
<?xml version="1.0"?>
-
<!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 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.
- 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 used 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,
- SetResourcePropertiesPortType,
- 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>
- <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 Apollo services must 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> /**
+ <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.
+ 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 <code>FileSystemService</code> class.
+ The FileSystemService extends <code>AbstractFileSystemService</code>, which contains
+ any code which should not need to be altered. The abstract class mainly
+ consists of the specification operations (i.e. <code>getMultipleResourceProperties</code>),
+ while the service class which extends this class contains the "custom" operations.
+ In the case of <code>FileSystemService</code>, these operations are <code>mount</code> and <code>unmount</code>.
+ </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 <code>example.filesystem.AbstractFileSystemService</code> 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 used for mapping incoming request QName's to method name
+ for a given object. It basically ensures that Apache WSRF can interact with your
+ service class.
+ </p>
+ <p>The <code>AbstractFileSystemService</code> class declaration is as follows:</p>
+ <source><strong> abstract class AbstractFileSystemService implements WsrfService,
+ GetResourcePropertyPortType,
+ GetMultipleResourcePropertiesPortType,
+ SetResourcePropertiesPortType,
+ QueryResourcePropertiesPortType,
+ ImmediateResourceTerminationPortType,
+ ScheduledResourceTerminationPortType</strong>
+ </source>
+ <p>You should notice that the class implements <code>WsrfService</code> (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>
+ <p>The packages:<strong><code>org.apache.ws.resource.properties.porttype</code></strong> and
+ <strong><code>org.apache.ws.resource.lifetime.porttype</code></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 Apache WSRF services must implement the <code>WsrfService</code> interface. The interface provides operation
+ "hooks" which will allow Apache WSRF 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.
*
@@ -113,47 +93,46 @@
* 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 (e.g. 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 <code>getMethodNameMap()</code> 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 <code>ServiceSoapMethodName</code> and add mappings for your operations.
+ </p>
+ <p>The <code>getResourceContext()</code> 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<code> init()</code> method is provided to give you an opportunity to initialize members for your Service (e.g. <code>ServiceSoapMethodName </code>)</p>
+ </section>
+ <section id="classvars">
+ <title>Class Variables</title>
+ <p>The class variables which should be defined are:</p>
+ <ol>
+ <li><strong><code>TARGET_NSURI</code></strong> - The target namespace of your sevice's WSDL file.</li>
+ <li><strong><code>TARGET_NSPREFIX</code></strong> - The target prefix to be associated with your service's namespace.</li>
+ </ol>
+ <p> In the <code>AbstractFileSystem</code> 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 <code>public static final</code> 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 <code>AbstractFileSystem</code> class, we see the operations defined for methods like: <code>getMultipleResourceProperties(..)</code>. 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 <code>GetMultipleResourcePropertiesProvider</code> 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><code>org.apache.ws.resource.properties.porttype.impl</code></strong> and
+ <strong><code>org.apache.ws.resource.lifetime.porttype.impl</code></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 <code>getResourceContext()</code>. 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 <code>XmlObject</code>:
+ </p>
+ <source> public XmlObject mount( XmlObject requestDoc )
{
try
{
@@ -164,17 +143,15 @@
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 implement the XmlObject interface, since
- all XmlBeans implement this interface.</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 implement the <code>XmlObject</code> interface, since
+ all XmlBeans implement this interface.</p>
+ <p><img src="images/back.gif" alt="go to the previous step"></img><a href="site:wsdl2java">Back</a> <img src="images/next.gif"
+ alt="go to the next step"></img><a href="site:resource">Next</a>
+ </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?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/test.xml Fri Jun 17 14:35:39 2005
@@ -1,62 +1,55 @@
<?xml version="1.0"?>
-
<!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 servlet 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>
+ <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 servlet container.</p>
+ </section>
+ <section id="start">
+ <title>Starting Tomcat</title>
+ <p>Tomcat can be started by utilizing the scripts under the <code>TOMCAT_HOME/bin</code> directory.
+ The script most typically used is <code>startup.bat </code>(Windows) or <code>startup.sh</code> (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><code>>ant sendRequest -Dxml=./requests/QueryResourceProperties_allProps.soap</code></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 <code>getInstance()</code> 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><code>>ant -f soapclient.xml sendRequest -Durl=http://localhost:8080/wsrf/services/your_service - Dxml=./requests/QueryResourceProperties_allProps.soap</code></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 <code>build.properties</code> for <code>url</code> which will alleviate the need
+ to specify it on the command line.</note>
+ <p><img src="images/back.gif" alt="go to the previous step"></img><a href="site:webapp">Back</a>
+ </p>
+ </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?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/webapp.xml Fri Jun 17 14:35:39 2005
@@ -1,41 +1,38 @@
<?xml version="1.0"?>
-
<!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. 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">
+ <header>
+ <title>Deploy the service to the Apache WSRF 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 <code>webapps</code> directory which
+ contains a <code>wsrf</code> 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
+ <code>wsrf/WEB-INF/classes/wsdl</code> directory. This will allow Axis to reference it from the classpath and avoids the need to hard-code a location on your files ystem. We will use this location when registering the service in the
+ <code>server-config.wsdd</code> 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 <code>wsrf/WEB-INF/classes/</code> directory so that your service can be created by Axis and Apache WSRF.</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 Apache WSRF 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>
@@ -57,18 +54,21 @@
</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 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">
+ <p>The<code> name</code> 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 <code>home</code>. Notice <code>serviceClassName</code> points to the clasname for the service class. The same is said for the <code>resourceClassName</code>. The <code>wsdlTargetNamespace </code> is the target namespace from your WSDL.</p>
+ <p>The <code>resourceKeyName</code> 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>
+ <code>SINGLETON</code>
+ </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 <code>server-config.wsdd</code> file is the configuration file for the Axis SOAP engine,
+ which is bundled with Apache WSRF. This file is located in the <code>wsrf/WEB-INF/</code> 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">
@@ -77,44 +77,53 @@
</handler>
</requestFlow>
</service>]]></source>
- <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 should make sure to copy the Apollo webapp from the included webapps directory to your Tomcat installation/webapps directory, and that the environment
- variable CATALINA_HOME is set and pointing to your Tomcat installation.</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</strong>
- </p>
- <p>You will now need to change your directory to the docs/tutorial/generated/filesystem directory. You will need
- to replace the FilesystemResource.init() and FilesystemHome.getInstance(..) (generated under src) methods with the contents
- of the files in the directory docs/tutorial/generated/filesystem/method_impls</p>
-
- <p>You will then need to run the command:</p>
- <p>
- <strong>>ant compile deploy</strong>
- </p>
- <p>This will compile and deploy the code. You can now start Tomcat.</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>
-
+ <p>The service <code>name</code> attribute is the endpoint name and should be the same as the port's <code>name</code> 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 <code>wsdlFile</code> which points to the <code>/wsdl/FileSystem.wsdl</code>.
+ This translates to the wsdl directory under the <code>WEB-INF/classes</code> directory.
+ </p>
+ <p>The last part is the <code>requestFlow</code>. 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 should make sure to copy the Apache WSRF webapp from the included webapps directory to your <code>TOMCAT_HOME/webapps </code> directory, and that the environment variable <code>CATALINA_HOME</code> is set and pointing to your Tomcat installation.
+ </p>
+ <p>You will need to change your directory to the <code>docs/tutorial</code> directory. You will then
+ need to run the command:
+ </p>
+ <p>
+ <strong>
+ <code>>ant generate</code>
+ </strong>
+ </p>
+ <p>You will now need to change your directory to the <code>docs/tutorial/generated/filesystem</code> directory. You will need
+ to replace the <code>FilesystemResource.init()</code> and<code> FilesystemHome.getInstance(..)</code> (generated under src) methods with the contents of the files in the directory <code>docs/tutorial/generated/filesystem/method_impls</code>
+ </p>
+ <p>You will then need to run the command:</p>
+ <p>
+ <strong>
+ <code>>ant compile deploy</code>
+ </strong>
+ </p>
+ <p>This will compile and deploy the code. You can now start Tomcat.</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>
+ <p>
+ <img src="images/back.gif" alt="go to the previous step"/>
+ <a href="site:home">Back</a>
+ <img src="images/next.gif" alt="go to the next step"/>
+ <a href="site:test">Next</a>
+ </p>
+ </section>
+ </body>
</document>
Modified: incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl.xml
URL: http://svn.apache.org/viewcvs/incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl.xml?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl.xml Fri Jun 17 14:35:39 2005
@@ -1,175 +1,32 @@
<?xml version="1.0"?>
-
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
"http://forrest.apache.org/dtd/document-v20.dtd">
-
<document>
-
- <header>
- <title>Composing a WSRF WSDL File</title>
- </header>
-
- <body>
- <section>
- <title>Introduction</title>
-
- <p>
- This tutorial describes how to create a Web Services Description Language (WSDL)
- file that describes a WSRF WS-Resource. A
- <a href="_TEMPLATE_.wsdl">WSRF WSDL template</a>
- is provided to expedite the WSDL creation process.
- </p>
-
- </section>
-
- <section>
- <title>Using the WSRF WSDL Template</title>
- <p>
- To use the template, first make a copy of the template file. For example, on a Windows system,
- run a command like:
- </p>
- <source>copy _TEMPLATE_.wsdl nameOfYourService.wsdl</source>
- <warning>Do not modify the original template file.</warning>
- </section>
-
- <section>
- <title>Defining the WSRF PortType</title>
-
- <p>
- A WSRF WSDL should contain only one portType, which is an aggregation of custom
- resource-specific operations and operations from the following
- specification-defined portTypes:
- </p>
-
- <section>
- <title>WS-ResourceProperties (WSRF-RP) PortTypes</title>
-
- <table>
- <tr>
- <th>PortType</th>
- <th>Operations</th>
- <th>Properties</th>
- </tr>
- <tr>
- <td>GetResourceProperty</td>
- <td>GetResourceProperty</td>
- <td/>
- </tr>
- <tr>
- <td>GetMultipleResourceProperties</td>
- <td>GetMultipleResourceProperties</td>
- <td/>
- </tr>
- <tr>
- <td>SetResourceProperties</td>
- <td>SetResourceProperties</td>
- <td/>
- </tr>
- <tr>
- <td>QueryResourceProperties</td>
- <td>QueryResourceProperties</td>
- <td/>
- </tr>
- </table>
-
- <note>The GetResourceProperty portType is REQUIRED. The WS-Resource specification states that
- all WS-Resources MUST implement this portType.</note>
-
- </section>
-
- <section>
- <title>WS-ResourceLifetime (WSRF-RL) PortTypes</title>
-
- <table>
- <tr>
- <th>PortType</th>
- <th>Operations</th>
- <th>Properties</th>
- </tr>
- <tr>
- <td>ImmediateResourceTermination</td>
- <td>Destroy</td>
- <td/>
- </tr>
- <tr>
- <td>ScheduledResourceTermination</td>
- <td>SetTerminationTime</td>
- <td>CurrentTime,
- <br/>TerminationTime
- </td>
- </tr>
- </table>
-
- <note>In addition to operations, the ScheduledResourceTermination portType also includes two properties.
- This means that if a WS-Resource implements this portType, it must expose these properties.</note>
-
- </section>
-
- <p>
- The PortType element must have a
- {http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.xsd}ResourceProperties
- attribute whose value is the QName of the resource properties document element defined
- in the types/schema section of the WSDL file.
- </p>
-
- <p>
- If you've copied the WSDL template file as described above, your WSDL file
- already contains a WSRF portType. You simply have to uncomment the blocks
- corresponding to whichever optional portTypes you want your WS-Resource to support. You should also
- add any custom operations you want your WS-Resource to expose. The following
- section describes how to add custom operations.
- </p>
-
- </section>
-
- <section>
- <title>Adding Custom Operations</title>
-
- <p>
- You may optionally add custom operations to the WSRF portType. To do so,
- you will have to define message types, messages, and operations, as you would
- for any WSDL. It is recommended that, when defining your custom operations,
- you adhere to the rules defined by
- <a href="http://www.ws-i.org/Profiles/BasicProfile-1.0-2004-04-16.html#description">section 5 of the WS-I Basic Profile</a>.
- This will ensure maximum interoperability for your WS-Resource.
- </p>
-
- </section>
-
- <section>
- <title>Defining Resource Properties</title>
-
- <p>
- Resource properties are defined in the types/schema section of the WSDL file. In addition to defining
- custom resource-specific properties, you may also need to add properties that are required by certain
- specification-defined portTypes. For example, the WSRF-RL ScheduledResourceTermination portType requires
- two properties (see above). Chapter 4 of the
- <a href="http://docs.oasis-open.org/wsrf/2004/11/wsrf-WS-ResourceProperties-1.2-draft-05.pdf">WSRF-RP specification</a>
- explains how to define resource properties.
- </p>
-
- <p>
- If you've copied the WSDL template file as described above, your WSDL file
- already contains a resource properties document definition. If your WS-Resource
- implements the WSRF-RL ScheduledResourceTermination portType, simply
- uncomment the xsd element references, which correspond to the two ScheduledResourceTermination
- properties. If would like your WS-Resource to allow resource properties with arbitrary names
- (not generally recommended), simply uncommwent the xsd any element.
- </p>
-
- </section>
-
- <section>
- <title>An example WSRF WSDL</title>
-
- <p>
- <a href="FileSystem.wsdl">FileSystem.wsdl</a> is an example of a WSRF WSDL that exposes
- all of the optional portTypes defined by WSRF-RP and WSRF-RL. It also defines two custom
- operations, Mount and Unmount, and seven custom resource properties.
- </p>
-
- </section>
-
- </body>
-
+ <header>
+ <title>Viewing a WSRF WSDL</title>
+ </header>
+ <body>
+ <section>
+ <title>Introduction</title>
+ <p>Apache WSRF development typical begins by composing a WSRF-compliant WSDL that describes a WSRF WS-Resource. In this case, the WS Resource that being defined is for a UNIX file system resource. In the interest of time,
+ <a href="FileSystem.wsdl">FileSystem.wsdl</a> has already been created for use in this tutorial.
+ </p>
+ <p> The WSDL was created using the <a href="_TEMPLATE_.wsdl">WSRF WSDL template</a>. Use the template to expedite the
+ WSDL creation process for a resource. It contains detailed instructions and the default operations that are required by a
+ WSRF-compliant WSDL. In addition, the template contains sections for adding custom operations. It is good practice to use the
+ template if you are not familiar with the WSRF family of specifications. Detailed instructions for composing a WSDL are provided in the <a href="site:compose">Developer Guide</a>.
+ </p>
+ </section>
+ <section>
+ <title>The FileSystem WSDL</title>
+ <p>The <a href="FileSystem.wsdl">FileSystem WSDL</a> is an example of a WSRF WSDL that contains a single portType (<code>FileSystemPortType</code>), which exposes all of the optional portTypes defined by the WSRF-RP and WSRF-RL specifications. It also defines two custom operations, <code>Mount</code> and <code>Unmount</code>, and seven custom resource properties.
+ </p>
+ <p>
+ <img src="images/back.gif" alt="go to the previous step"/>
+ <a href="site:tut">Back</a>
+ <img src="images/next.gif" alt="go to the next step"/>
+ <a href="site:wsdl2java">Next</a>
+ </p>
+ </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?rev=191215&r1=191214&r2=191215&view=diff
==============================================================================
--- incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml (original)
+++ incubator/apollo/trunk/src/site/content/xdocs/tutorial/wsdl2java.xml Fri Jun 17 14:35:39 2005
@@ -1,46 +1,39 @@
<?xml version="1.0"?>
-
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
"http://forrest.apache.org/dtd/document-v20.dtd">
-
<document>
-
- <header>
- <title>Runing Apollo's Wsdl2Java tool on a WSRF WSDL</title>
- </header>
-
- <body>
- <section>
- <title>Introduction</title>
- <p>
- Apollo's Wsdl2Java file takes a WSRF WSDL file as its input and generates the following artifacts:
- </p>
- <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
+ <header>
+ <title>Running the Wsdl2Java tool on a WSRF WSDL</title>
+ </header>
+ <body>
+ <section>
+ <title>Introduction</title>
+ <p>The Apache WSRF Wsdl2Java tool takes a WSRF WSDL file as its input and generates the following artifacts:
+ </p>
+ <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>an abstract base Service class</li>
- <li>a Service class - described
+ </li>
+ <li>an abstract base Service class</li>
+ <li>a Service class - described
<a href="service.html">here</a>
- </li>
- <li>a Home class - described
+ </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>
- <li>a resource.cfg file</li>
- </ul>
- <note>The abstract classes and interfaces should NOT be modified.</note>
- </section>
-
- <section>
- <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[
+ </li>
+ <li>a CustomOperationsPortType interface</li>
+ <li>a PropertyQNames interface</li>
+ <li>an Axis deploy.wsdd file</li>
+ <li>a resource.cfg file</li>
+ </ul>
+ <note>The abstract classes and interfaces should NOT be modified.</note>
+ </section>
+ <section>
+ <title>Using the Ant Task</title>
+ <p>The Wsdl2Java tool is invoked using an Ant task, as shown by the following example:</p>
+ <source><![CDATA[
<property name="wsrf.webapp.dir" location="${apollo.home}/webapps/wsrf" />
<path id="apollo.classpath.id">
@@ -53,12 +46,11 @@
<wsdl2Java wsdl="path/to/your.wsdl"
outputdir="generated"
classpathref="apollo.classpath.id" />
- ]]>
- </source>
- <note>The apollo.home Ant property used above has to be set to your Apollo installation
- directory (e.g. /opt/apollo-1.0beta).</note>
- </section>
-
- </body>
-
+ ]]></source>
+ <note>The apollo.home Ant property used above has to be set to <code>INSTALL_DIR</code> (e.g. /opt/apollo-1.0beta).</note>
+ <p><img src="images/back.gif" alt="go to the previous step"></img><a href="site:wsdl">Back</a> <img src="images/next.gif"
+ alt="go to the next step"></img><a href="site:service">Next</a>
+ </p>
+ </section>
+ </body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: apollo-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: apollo-dev-help@ws.apache.org