You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsrf-commits@ws.apache.org by ip...@apache.org on 2005/10/19 00:48:14 UTC
svn commit: r326288 - in
/webservices/wsrf/trunk/src/site/content/xdocs/dev_guide: callback.xml
home.xml index.xml metadata.xml service.xml wsdl_tool.xml
Author: ips
Date: Tue Oct 18 15:48:10 2005
New Revision: 326288
URL: http://svn.apache.org/viewcvs?rev=326288&view=rev
Log:
minor corrections
Modified:
webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/callback.xml
webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/home.xml
webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/index.xml
webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/metadata.xml
webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/service.xml
webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/wsdl_tool.xml
Modified: webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/callback.xml
URL: http://svn.apache.org/viewcvs/webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/callback.xml?rev=326288&r1=326287&r2=326288&view=diff
==============================================================================
--- webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/callback.xml (original)
+++ webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/callback.xml Tue Oct 18 15:48:10 2005
@@ -1,128 +1,128 @@
-<?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
- <code> FileSystemResource</code>.
- </p>
- <p>There are two interfaces which can be implemented when writing a Callback object. Which one you choose depends 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. An example of
- this in <code>OptionsCallback</code>:
- </p>
- <source> public ResourceProperty refreshProperty( ResourceProperty prop )
- {
- Iterator iterator = prop.iterator( );
- while ( iterator.hasNext( ) )
- {
- OptionsDocument.Options o = (OptionsDocument.Options) iterator.next( );
- clearOptionsFromProperty( o );
-
- //add current options...
- List options = m_fileSystem.getOptions( );
- for ( int i = 0; i <![CDATA[<]]> options.size( ); i++ )
- {
- o.addOption( options.get( i ).toString( ) );
- }
- }
-
- return prop;
- }</source>
- <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 defined by the resource properties document 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 - Apache WSRF will never call delete for a property whose minOccurs != 0
- }
-
- public void insertProperty( Object[] propElems )
- {
- // Comment prop has cardinality of 1, so passed array will always have exactly one element
- XmlString xString = (XmlString) propElems[0];
- m_fileSystem.setComment( xString.getStringValue() );
- }
-
- public void updateProperty( Object[] propElems )
- {
- insertProperty( prop );
- }
- </source>
- <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; it takes an array of property elements and
- updates the corresponding backend property.</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>
+<?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
+ <code>FileSystemResource</code>.
+ </p>
+ <p>There are two interfaces which can be implemented when writing a Callback object. Which one you choose depends 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's value
+ may change (not static - e.g. "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 individual elements out of the property. You can either get an iterator of the property elements or retrieve a specific element 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. An example of
+ this in <code>OptionsCallback</code>:
+ </p>
+ <source> public ResourceProperty refreshProperty( ResourceProperty prop )
+ {
+ Iterator iterator = prop.iterator( );
+ while ( iterator.hasNext( ) )
+ {
+ OptionsDocument.Options o = (OptionsDocument.Options) iterator.next( );
+ clearOptionsFromProperty( o );
+
+ //add current options...
+ List options = m_fileSystem.getOptions( );
+ for ( int i = 0; i <![CDATA[<]]> options.size( ); i++ )
+ {
+ o.addOption( options.get( i ).toString( ) );
+ }
+ }
+
+ return prop;
+ }</source>
+ <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 to ensure that the property element(s) returned to the client are up-to-date.
+ </p>
+ </section>
+
+ <section id="setresource">
+ <title>Implementing a SetResourcePropertyCallback</title>
+ <p>
+ <code>SetResourcePropertyCallback</code> is a way for the backend state to be updated via SetResourceProperties requests to the front-end resource.
+ The <code>SetResourcePropertyCallback</code> interface defines three methods:
+ </p>
+ <source>void deleteProperty( QName propQName );
+void insertProperty( Object[] propElems );
+void updateProperty( Object[] propElems );</source>
+ <p>The operations will follow the same semantics as are defined in the specification and will be restricted to
+ the bounds defined by the resource properties document 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 - Apache WSRF will never call delete for a property whose minOccurs != 0
+ }
+
+ public void insertProperty( Object[] propElems )
+ {
+ // Comment prop has cardinality of 1, so passed array will always have exactly one element
+ XmlString xString = (XmlString) propElems[0];
+ m_fileSystem.setComment( xString.getStringValue() );
+ }
+
+ public void updateProperty( Object[] propElems )
+ {
+ insertProperty( prop );
+ }
+ </source>
+ <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; it takes an array of property elements and
+ updates the corresponding backend property.</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 typically done in the <code>init</code> method of your Resource implementation class. See the FileSystemResource
+ for an example.</p>
+ </section>
+ </body>
+</document>
Modified: webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/home.xml
URL: http://svn.apache.org/viewcvs/webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/home.xml?rev=326288&r1=326287&r2=326288&view=diff
==============================================================================
--- webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/home.xml (original)
+++ webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/home.xml Tue Oct 18 15:48:10 2005
@@ -1,56 +1,53 @@
-<?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>The home class 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>
- <note>If your service is a singleton and only requires a single resource instance, see the <a href="site:single">Creating a Singleton Service</a> section.</note>
- <p>If you use the Wsdl2Java tool, the home class is automatically generated, but will need to modified to create instances of your resource. This section will
- describe how to write a home class for your resource. Initially, you should model your resource off of the included <code>FilesystemHome</code> example
- to ensure that you write a valid home class for your resource.
- </p>
- </section>
- <section id="class-declaration">
- <title>Class Declaration</title>
- <p>The generated home class extends <code>AbstractResourceHome</code>. Extending <code>AbstractResourceHome</code>
- provides services for caching instances and looking them up. It also ensures
- 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>
- <note>Many of the operations in the <code>AbstractResourceHome</code> may be overridden in your Home
- class, if you have a need to modfify or extend the base class' functionality.</note>
- </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 void init()</source>
- <p>The <code>init()</code> operation can be used to initialize any instances at startup.
- In the FileSystem example, the <code>init()</code> method is used to create and add two resource instances:</p>
- <source>public void init() throws Exception
- {
- super.init();
- add( createInstance( LVOL1_ID ) );
- add( createInstance( LVOL2_ID ) );
- }</source>
- <p>The <code>createInstance()</code> method:</p>
- <ul>
- <li>Creates an instance of the resource.</li>
- <li>Sets an endpoint reference on the resource.</li>
- <li>Calls <code>init()</code> on the resource.</li>
- </ul>
- <note>If you choose to not use the <code>createInstance()</code> method (e.g. if you have a non-empty constructor), then you must manually set the EPR then call
- the <code>init()</code> method on the resource. The generated home class contains a utility method from the <code>AbstractResourceHome</code> that can be used
- to build an EPR.</note>
- </section>
- </body>
-</document>
+<?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>The home class is used to lookup resource instances. 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>
+ <note>If your service is a singleton and only requires a single resource instance, see the <a href="site:single">Creating a Singleton Service</a> section.</note>
+ <p>If you use the Wsdl2Java tool, the home class is automatically generated, but will may be modified to create instances of your resource. This section will
+ describe how to write a home class for your resource. Initially, you should model your resource off of the included <code>FilesystemHome</code> example
+ to ensure that you write a valid home class for your resource.
+ </p>
+ </section>
+ <section id="class-declaration">
+ <title>Class Declaration</title>
+ <p>The generated home class extends <code>AbstractResourceHome</code>. Extending <code>AbstractResourceHome</code>
+ provides services for caching instances and looking them up. It also ensures
+ 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>
+ <note>Many of the operations in the <code>AbstractResourceHome</code> may be overridden in your Home
+ class, if you have a need to modify or extend the base functionality.</note>
+ </section>
+ <section id="ops">
+ <title>Operations</title>
+ <p>If you extend <code>AbstractResourceHome</code>, the only required operation you may wish to override is:</p>
+ <source>public void init()</source>
+ <p>The <code>init()</code> operation can be used to initialize any instances at startup.
+ In the FileSystem example, the <code>init()</code> method is used to create and add two resource instances:</p>
+ <source>public void init() throws Exception
+ {
+ super.init();
+ add( createInstance( LVOL1_ID ) );
+ add( createInstance( LVOL2_ID ) );
+ }</source>
+ <p>The <code>createInstance()</code> method:</p>
+ <ul>
+ <li>Creates an instance of the resource.</li>
+ <li>Sets the resource's EndpointReference.</li>
+ <li>Calls <code>init()</code> on the resource.</li>
+ </ul>
+ </section>
+ </body>
+</document>
Modified: webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/index.xml
URL: http://svn.apache.org/viewcvs/webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/index.xml?rev=326288&r1=326287&r2=326288&view=diff
==============================================================================
--- webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/index.xml (original)
+++ webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/index.xml Tue Oct 18 15:48:10 2005
@@ -10,7 +10,7 @@
<p>The Developer Guide provides instructions for using many of the features that are included in Apache WSRF. If you are new to this project, you should start
with the <a href="site:overview">Getting Started</a> and the <a href="site:tut">Tutorial</a> before reading this guide. They provide a good starting point for
learning how to use Apache WSRF.</p>
- <p>The Developer guide often refers to different parts of the <a href="site:wsrf">Web Services Resource Framework (WSRF) specifications</a> that are defined by
+ <p>The Developer Guide often refers to different parts of the <a href="site:wsrf">Web Services Resource Framework (WSRF) specifications</a> that are defined by
the OASIS standards body. You should become familiar with these specifications and refer to them as needed.</p>
<p>The Developer Guide guide often refers to Apache Axis, Apache Tomcat, Apache Ant, and Apache XMLBeans. Instructions for these packages are included
as required and are not meant to replace the formal documentation for these projects. Consult them as necessary.</p>
@@ -20,9 +20,10 @@
</section>
<section>
<title>WSRF Overview</title>
- <p>Apache WSRF is an implementation of the <a href="site:wsrf">WSRF</a> family of specifications that are defined by the OASIS standards body. Ultimately, the family
- of specifications define a method of exposing resources using Web services. This is typically done for management purposes. The resource can
- be anything from a device to application components or even current management components such as JMX MBeans.The specifications
+ <p>Apache WSRF is an implementation of the <a href="site:wsrf">WSRF</a> family of specifications that are defined by the OASIS standards body.
+ Ultimately, this family
+ of specifications defines a method of exposing resources using Web services. This is typically done for management purposes. The resource can
+ be anything from a device to an application component or even a current management component such as a JMX MBean. The specifications
include:</p>
<ul>
<li>WS Resource - Defines a WS-Resource and describes how one Web service can be used to represent multiple resource instances.</li>
@@ -37,7 +38,8 @@
</section>
<section>
<title>Resource Invocation Framework</title>
- <p> The resource invocation framework is the foundation upon which Apache WSRF is implemented. The framework includes a set of core interfaces, as well as
+ <p> The resource invocation framework is the foundation upon which Apache WSRF is implemented.
+ The framework includes a set of core interfaces, as well as
runtime pieces. The framework is discussed in detail below.
</p>
<section>
@@ -88,7 +90,7 @@
<li>A WSRF WSDL template for writing WSRF-compliant WSDLs</li>
<li>A Wsdl2Java tool for generating Java Classes from a WSDL</li>
<li>An integration with Apache XMLBeans for generating custom types defined in the WSDL</li>
- <li>an integration with Apache Axis for automatically deploying WS Resources</li>
+ <li>An integration with Apache Axis for automatically deploying WS Resources</li>
</ul>
</section>
</body>
Modified: webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/metadata.xml
URL: http://svn.apache.org/viewcvs/webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/metadata.xml?rev=326288&r1=326287&r2=326288&view=diff
==============================================================================
--- webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/metadata.xml (original)
+++ webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/metadata.xml Tue Oct 18 15:48:10 2005
@@ -1,114 +1,115 @@
-<?xml version="1.0"?>
-<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
- "http://forrest.apache.org/dtd/document-v20.dtd">
-<document>
- <header>
- <title>Adding Service Metadata</title>
- </header>
- <body>
- <section>
- <title>Introduction</title>
- <p>Web services may have various metadata associated with them (e.g. the WSDL for the service or a set of Topic Space documents). The
- <a href="http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-metadataexchange.pdf">WS-MEXWS-Metadata Exchange</a> specification (defined by Microsoft
- and other industry contributors) defines operations that can be provided by services to allow clients to retrieve these metadata documents.
- </p>
- </section>
- <section>
- <title>Define the Operations</title>
- <p>The metadata data operations are defined in your service's WSDL. If you used the INSTALL_DIR/template/_TEMPLATE_.wsdl file to create your WSDL, you simply
- need to uncomment these operations in the <code>portType</code> and <code>binding</code> sections.
- </p>
- <source><![CDATA[
-<portType name="MyPortType">
- ...
- <operation name="GetMetadata" >
- <input message="mex:GetMetadataMsg" wsa04:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Request" />
- <output message="mex:GetMetadataResponseMsg" wsa04:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Response" />
- </operation>
-
- <operation name="Get" >
- <input message="mex:GetMsg" wsa04:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/Get/Request" />
- <output message="mex:GetResponseMsg" wsa04:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/Get/Response" />
- </operation>
-</portype>
-
-<binding name="MySoapHttpBinding">
- ...
- <operation name="GetMetadata" >
- <soap:operation style="document"/>
- <input>
- <soap:body use="literal"/>
- </input>
- <output>
- <soap:body use="literal"/>
- </output>
- </operation>
-
- <operation name="Get" >
- <soap:operation style="document"/>
- <input>
- <soap:body use="literal"/>
- </input>
- <output>
- <soap:body use="literal"/>
- </output>
- </operation>
-</binding>]]></source>
- </section>
- <section>
- <title>Modify the JNDI Configuration File</title>
- <p>The JNDI configuration file must be modified to include a metadata resource for your service as well as configurations that define where your metadata files are located.</p>
- <p>To update the JNDI configuration file to include metadata information:</p>
- <ol>
- <li>Using a text editor, open <code>jndi-config.xml</code> in the <code>WEB-INF/classes</code> directory.</li>
- <li>Add the following JNDI resource block to the service, for which you would like to associate metadata:
- <source><![CDATA[
-<service name="myService">
- <resource name="metadata" type="org.apache.ws.util.jndi.tools.MetadataConfigImpl">]]></source>
- <p>The <code>org.apache.ws.util.jndi.tools.MetadataConfigImpl</code> object containing the metadata is available via JNDI using a Context lookup of
- <code>wsrf/services/{service_name}/metadata</code> - i.e. <code>ctx.lookup("wsrf/services/sushi/metadata");</code>
- </p>
- </li>
- <li>In the metadata resource block, add a<code> metadataConfig</code> element that contains metadata configurations. The configuration includes a <code>dialect</code>
- attribute that defines the type of the data (xsd, wsdl, etc...) and an identifier attribute that uniquely identifies a particular document and is typically a targetNamespace. The
- following examples demonstrate five different methods of configuring where your metadata files are located. The files should be "reachable" at the configured locations.<source><![CDATA[
-<resource name="metadata" type="org.apache.ws.util.jndi.tools.MetadataConfigImpl">
- <metadataConfig>
- <!-- classpath -->
- <metadata dialect="http://www.w3.org/2001/XMLSchema" identifier="http://ws.apache.org/resource/properties/test/sushi_classpath">
- <location>org/apache/ws/resource/properties/SushiProperties.xsd</location>
- </metadata>
-
- <!-- file -->
- <metadata dialect="http://schemas.xmlsoap.org/wsdl/" identifier="http://ws.apache.org/resource/properties/test/sushi_wsdl">
- <location>C:/Projects/apache/wsrf/trunk/src/test/org/apache/ws/resource/properties/SushiProperties.wsdl</location>
- </metadata>
-
- <!-- http url -->
- <metadata dialect="http://www.w3.org/2001/XMLSchema" identifier="http://ws.apache.org/resource/properties/test/sushi_url">
- <location>http://localhost:8080/wsrf/SushiProperties.xsd</location>
- </metadata>
-
- <!-- file url -->
- <metadata dialect="http://www.w3.org/2001/XMLSchema" identifier="http://ws.apache.org/resource/properties/test/sushi_fileurl">
- <location>file://C:/Projects/apache/wsrf/trunk/src/test/org/apache/ws/resource/properties/SushiProperties.xsd</location>
- </metadata>
-
- <!-- EndpointReference -->
- <metadata dialect="http://schemas.xmlsoap.org/ws/2004/08/addressing" identifier="http://ws.apache.org/resource/properties/test/sushi_epr">
- <reference xmlns:wsa04="http://schemas.xmlsoap.org/ws/2004/08/addressing">
- <wsa04:Address>http://localhost:8080/wsrf/services/sushi</wsa04:Address>
- <wsa04:ReferenceProperties>
- <sushi:ResourceIdentifier xmlns:sushi="http://ws.apache.org/resource/properties/test/sushi">1</sushi:ResourceIdentifier>
- </wsa04:ReferenceProperties>
- </reference>
- </metadata>
- </metadataConfig>
-</resource>]]></source>
- </li>
- <li>Save and close jndi-config.xml.</li>
- <li>Restart Tomcat if it is already started.</li>
- </ol>
- </section>
- </body>
-</document>
+<?xml version="1.0"?>
+<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
+ "http://forrest.apache.org/dtd/document-v20.dtd">
+<document>
+ <header>
+ <title>Adding Service Metadata</title>
+ </header>
+ <body>
+ <section>
+ <title>Introduction</title>
+ <p>Web services may have various metadata associated with them (e.g. the WSDL for the service or a set of Topic Space documents). The
+ <a href="http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-metadataexchange.pdf">WS-Metadata Exchange</a> (WS-MEx) specification (defined by Microsoft
+ and other industry contributors) defines operations that can be provided by services to allow clients to retrieve these metadata documents.
+ </p>
+ </section>
+ <section>
+ <title>Define the Operations</title>
+ <p>The metadata operations are defined in your service's WSDL. If you used the INSTALL_DIR/template/_TEMPLATE_.wsdl file to create your WSDL, you simply
+ need to uncomment these operations in the <code>portType</code> and <code>binding</code> sections.
+ </p>
+ <source><![CDATA[
+<portType name="MyPortType">
+ ...
+ <operation name="GetMetadata" >
+ <input message="mex:GetMetadataMsg" wsa04:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Request" />
+ <output message="mex:GetMetadataResponseMsg" wsa04:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/GetMetadata/Response" />
+ </operation>
+
+ <operation name="Get" >
+ <input message="mex:GetMsg" wsa04:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/Get/Request" />
+ <output message="mex:GetResponseMsg" wsa04:Action="http://schemas.xmlsoap.org/ws/2004/09/mex/Get/Response" />
+ </operation>
+</portype>
+
+<binding name="MySoapHttpBinding">
+ ...
+ <operation name="GetMetadata" >
+ <soap:operation style="document"/>
+ <input>
+ <soap:body use="literal"/>
+ </input>
+ <output>
+ <soap:body use="literal"/>
+ </output>
+ </operation>
+
+ <operation name="Get" >
+ <soap:operation style="document"/>
+ <input>
+ <soap:body use="literal"/>
+ </input>
+ <output>
+ <soap:body use="literal"/>
+ </output>
+ </operation>
+</binding>]]></source>
+ </section>
+
+ <section>
+ <title>Modify the JNDI Configuration File</title>
+ <p>The JNDI configuration file must be modified to include a metadata resource for your service as well as configurations that define where your metadata files are located.</p>
+ <p>To update the JNDI configuration file to include metadata information:</p>
+ <ol>
+ <li>Using a text editor, open <code>jndi-config.xml</code> in the <code>WEB-INF/classes</code> directory.</li>
+ <li>Add the following JNDI resource block to the service, for which you would like to associate metadata:
+ <source><![CDATA[
+<service name="myService">
+ <resource name="metadata" type="org.apache.ws.util.jndi.tools.MetadataConfigImpl">]]></source>
+ <p>The <code>org.apache.ws.util.jndi.tools.MetadataConfigImpl</code> object containing the metadata is available via JNDI using a Context lookup of
+ <code>wsrf/services/{service_name}/metadata</code> - i.e. <code>ctx.lookup("wsrf/services/sushi/metadata");</code>
+ </p>
+ </li>
+ <li>In the metadata resource block, add a<code> metadataConfig</code> element that contains metadata configurations. The configuration includes a <code>dialect</code>
+ attribute that defines the type of the data (xsd, wsdl, etc...) and an identifier attribute that uniquely identifies a particular document and is typically a targetNamespace. The
+ following examples demonstrate five different methods of configuring where your metadata files are located. The files should be "reachable" at the configured locations.<source><![CDATA[
+<resource name="metadata" type="org.apache.ws.util.jndi.tools.MetadataConfigImpl">
+ <metadataConfig>
+ <!-- classpath -->
+ <metadata dialect="http://www.w3.org/2001/XMLSchema" identifier="http://ws.apache.org/resource/properties/test/sushi_classpath">
+ <location>org/apache/ws/resource/properties/SushiProperties.xsd</location>
+ </metadata>
+
+ <!-- file -->
+ <metadata dialect="http://schemas.xmlsoap.org/wsdl/" identifier="http://ws.apache.org/resource/properties/test/sushi_wsdl">
+ <location>C:/Projects/apache/wsrf/trunk/src/test/org/apache/ws/resource/properties/SushiProperties.wsdl</location>
+ </metadata>
+
+ <!-- http url -->
+ <metadata dialect="http://www.w3.org/2001/XMLSchema" identifier="http://ws.apache.org/resource/properties/test/sushi_url">
+ <location>http://localhost:8080/wsrf/SushiProperties.xsd</location>
+ </metadata>
+
+ <!-- file url -->
+ <metadata dialect="http://www.w3.org/2001/XMLSchema" identifier="http://ws.apache.org/resource/properties/test/sushi_fileurl">
+ <location>file://C:/Projects/apache/wsrf/trunk/src/test/org/apache/ws/resource/properties/SushiProperties.xsd</location>
+ </metadata>
+
+ <!-- EndpointReference -->
+ <metadata dialect="http://schemas.xmlsoap.org/ws/2004/08/addressing" identifier="http://ws.apache.org/resource/properties/test/sushi_epr">
+ <reference xmlns:wsa04="http://schemas.xmlsoap.org/ws/2004/08/addressing">
+ <wsa04:Address>http://localhost:8080/wsrf/services/sushi</wsa04:Address>
+ <wsa04:ReferenceProperties>
+ <sushi:ResourceIdentifier xmlns:sushi="http://ws.apache.org/resource/properties/test/sushi">1</sushi:ResourceIdentifier>
+ </wsa04:ReferenceProperties>
+ </reference>
+ </metadata>
+ </metadataConfig>
+</resource>]]></source>
+ </li>
+ <li>Save and close jndi-config.xml.</li>
+ <li>Restart Tomcat if it is already started.</li>
+ </ol>
+ </section>
+ </body>
+</document>
Modified: webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/service.xml
URL: http://svn.apache.org/viewcvs/webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/service.xml?rev=326288&r1=326287&r2=326288&view=diff
==============================================================================
--- webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/service.xml (original)
+++ webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/service.xml Tue Oct 18 15:48:10 2005
@@ -1,190 +1,190 @@
-<?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>If you use the Wsdl2Java tool, the service class is automatically generated and typically does not need to be modified. However; this section discusses how
- to write a service class if you choose to do so. Initially, you should model your service off of the included FileSystemService example to ensure that you 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>, the custom 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-defined 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.
- *
- * @return SoapMethodNameMap
- */
- public SoapMethodNameMap getMethodNameMap( );
-
- /**
- * Returns the ResourceContext for the given Service.
- *
- * @return ResourceContext
- */
- public ResourceContext getResourceContext( );
-
- /**
- * Initialization method.
- */
- public void init( );</source>
- <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 <code>public static final</code> since they are constants that other classes may need to access.</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 <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.
- </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
- {
- return XmlObject.Factory.parse( "<![CDATA[<MountResponse />]]>" );
- }
- catch ( XmlException xe )
- {
- 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 <code>XmlObject</code> interface, since
- all XmlBeans implement this interface.</p>
- </section>
- </section>
- </body>
-</document>
+<?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>If you use the Wsdl2Java tool, the service class is automatically generated and typically does not need to be modified. However; this section discusses how
+ to write a service class if you choose to do so. Initially, you should model your service off of the included FileSystemService example to ensure that you 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>, the custom 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-defined 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.
+ *
+ * @return SoapMethodNameMap
+ */
+ public SoapMethodNameMap getMethodNameMap( );
+
+ /**
+ * Returns the ResourceContext for the given Service.
+ *
+ * @return ResourceContext
+ */
+ public ResourceContext getResourceContext( );
+
+ /**
+ * Initialization method.
+ */
+ public void init( );</source>
+ <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 <code>public static final</code> since they are constants that other classes may need to access.</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-defined 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 portType implementation class:
+ </p>
+ <source>public GetResourcePropertyResponseDocument getResourceProperty( GetResourcePropertyDocument requestDoc )
+ {
+ return new GetResourcePropertyPortTypeImpl( getResourceContext( ) ).getResourceProperty( requestDoc );
+ }</source>
+ <p>Notice the <code>GetMultipleResourcePropertiesPortTypeImpl</code> class being used. A portType implementation class
+ is used to handle the operations defined in a particular specification-defined portType. </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 portType implementation classes for the portTypes defined by
+ the WS-ResourceProperties and WS-ResourceLifetime specifications.
+ You should refer to these packages when implementing the operations from these specifications.
+ </p>
+ </section>
+ </section>
+ <section id="service">
+ <title>The Service class</title>
+ <p>The service class is the extension of the abstract service class we previously outlined.
+ You will need to implement a constructor that takes a ResourceContext as a parameter. This
+ constructor should call the equivalent constructor in the superclass.
+ </p>
+ <p>The Service class should contain any custom operations that were defined in the most-derived portType 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
+ {
+ return XmlObject.Factory.parse( "<![CDATA[<MountResponse />]]>" );
+ }
+ catch ( XmlException xe )
+ {
+ 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 <code>XmlObject</code> interface, since
+ all XmlBeans implement this interface.</p>
+ </section>
+ </section>
+ </body>
+</document>
Modified: webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/wsdl_tool.xml
URL: http://svn.apache.org/viewcvs/webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/wsdl_tool.xml?rev=326288&r1=326287&r2=326288&view=diff
==============================================================================
--- webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/wsdl_tool.xml (original)
+++ webservices/wsrf/trunk/src/site/content/xdocs/dev_guide/wsdl_tool.xml Tue Oct 18 15:48:10 2005
@@ -114,8 +114,8 @@
<strong>Example</strong>
</p>
<p>The following example generates files for a single WSDL and places the generated files in a subdirectory
- of the current directory named <code>/generated</code>. To simplify the example, the classpath is referenced. You must set the <code>${wsrf.home}</code> Ant property to <code>
- INSTALL_DIR</code> (e.g. /opt/wsrf-1.0).</p>
+ of the current directory named <code>generated</code>. To simplify the example, the classpath is referenced. You must set the <code>${wsrf.home}</code> Ant property to <code>
+ INSTALL_DIR</code> (e.g. /opt/wsrf-1.1).</p>
<source><![CDATA[
<property name="wsrf.webapp.dir" location="${wsrf.home}/webapps/wsrf" />