You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-commits@ws.apache.org by ae...@apache.org on 2007/03/16 17:12:54 UTC
svn commit: r519035 - in /webservices/muse/site/docs/2.2.0/manual/tools:
wsdl-conventions.html wsdl2java.html wsdlmerge.html
Author: aeberbac
Date: Fri Mar 16 09:12:53 2007
New Revision: 519035
URL: http://svn.apache.org/viewvc?view=rev&rev=519035
Log:
MUSE-197: Updating docs
Modified:
webservices/muse/site/docs/2.2.0/manual/tools/wsdl-conventions.html
webservices/muse/site/docs/2.2.0/manual/tools/wsdl2java.html
webservices/muse/site/docs/2.2.0/manual/tools/wsdlmerge.html
Modified: webservices/muse/site/docs/2.2.0/manual/tools/wsdl-conventions.html
URL: http://svn.apache.org/viewvc/webservices/muse/site/docs/2.2.0/manual/tools/wsdl-conventions.html?view=diff&rev=519035&r1=519034&r2=519035
==============================================================================
--- webservices/muse/site/docs/2.2.0/manual/tools/wsdl-conventions.html (original)
+++ webservices/muse/site/docs/2.2.0/manual/tools/wsdl-conventions.html Fri Mar 16 09:12:53 2007
@@ -131,7 +131,7 @@
<ol>
<li>If the method has a message whose <em>type</em> attribute is <em>xsd:anyType</em> (xsd being bound to the
XML Schema namespace), then this means it returns void. This method must only have
- a <em>type</em> attribute, there must not be any other attribute (for example, a <em>type</em> attribute).</li>
+ a <em>type</em> attribute, there must not be any other attribute (for example, a <em>element</em> attribute).</li>
<li>If the method has a message whose <em>element</em> references an XSD element whose type
is <em>xsd:anyType</em> or the element has no type, then it returns org.w3c.dom.Element</li>
</ol>
@@ -139,6 +139,36 @@
The problem stems from the fact that an XSD element with type <em>xsd:anyType</em> is equivalent (according to
the XML Schema spec) to an XSD element with no type.
</li>
+
+ <li>Properties that are arrays: If a property has a minOccurs or maxOcurrs greater than one (this includes
+ "unbounded") we consider it an array. These attributes should be set <b>in the resource property document definition</b> and not in the element
+ definitions that are referenced from that document.</li>
+
+ <li>Parameters: A method can take zero or more input parameters. Method parameters are encapsulated by the
+ element that is referenced from WSDL message for the particular operation. For example, if a message has an element
+ attribute referencing "pre:foobar" (where pre is mapped appropriately), then parameters for this message would be
+ created as follows:
+ <pre>
+<xsd:element name="foobar">
+ <xsd:complexType>
+ <xsd:sequence>
+ <xsd:element name="param1" type="xsd:string"/>
+ <xsd:element name="param2" type="xsd:integer"/>
+ </xsd:sequence>
+ </xsd:complexType>
+</xsd:element>
+ </pre>
+ The preceding describes a method that takes two parameters: the first parameter (param1) is a string and the second
+ param (param2) is an integer.
+ </li>
+ <li>Parameters that are arrays: Parameters that are arrays need to be defined as above, but the minOccurs/maxOccurs
+ attributes must be set inside of the complexType/sequence/element path defined above.</li>
+ <li>Return types: Since methods only return one parameter, you must define return types as a type reference
+ on the element referenced from the message. So if your return message is called "pre:foobarResponse" (where pre is mapped
+ appropriately). Then the return element should look like:
+ <pre><xsd:element name="foobarResponse" type="xsd:string"></pre>
+ The return can be an array as well, in which case one would set the appropriate minOccurs/maxOccurs on this
+ element.</li>
</ul>
</li>
<li><b>Messages:</b>
@@ -153,7 +183,9 @@
</li>
<li><b>Binding:</b>
<ul>
- <li>Single binding: We expect one binding referencing the above portType.</li>
+ <li>Single binding: We expect one binding referencing the above portType. Generating the binding is
+ a totally automated process if you already have the portType. We provide a tool for doing this (as well as
+ merging multiple WSDL files together) called <a href="wsdlmerge.html">wsdlmerge</a>.</li>
</ul>
</li>
<li><b>Service:</b>
Modified: webservices/muse/site/docs/2.2.0/manual/tools/wsdl2java.html
URL: http://svn.apache.org/viewvc/webservices/muse/site/docs/2.2.0/manual/tools/wsdl2java.html?view=diff&rev=519035&r1=519034&r2=519035
==============================================================================
--- webservices/muse/site/docs/2.2.0/manual/tools/wsdl2java.html (original)
+++ webservices/muse/site/docs/2.2.0/manual/tools/wsdl2java.html Fri Mar 16 09:12:53 2007
@@ -191,15 +191,6 @@
This will allow users to write their own WSDL, simplify code generation for headless builds
and, most importantly, act as an isolation layer between changes in the UI models and
the code generation (since it is driven by WSDL).</p>
-<div class="frame note">
-<div class="label">Note</div>
-<div class="content">
-The first time you run <em>wsdl2java</em>, it will download the latest version of
-<a href="http://people.apache.org/dist/axis2/nightly/" class="external">Apache Axis2 1.1.</a> This download is
-almost 10 MB, so you can expect a delay of a few seconds to almost one minute depending on your connection speed.
-Once Axis2 has been downloaded, <em>wsdl2java</em> will continue as normal and you won't have to download it again.
-</div>
-</div>
</div>
<div class="section">
<h2 class="boxed"><a name="usage"></a>Usage</h2>
@@ -207,50 +198,86 @@
<blockquote>
<code>
<pre>
-Usage: wsdl2java.[bat|sh] -wsdl FILE [OPTIONS]
+Usage: wsdl2java.[bat|sh] PLATFORM [CONTAINER] -wsdl FILE [OPTIONS]
The following arguments are required:
-wsdl FILE The WSDL definition file to analyze
+ PLATFORM Must be one of the following:
+ -j2ee Create a J2EE project
+ -osgi Create a OSGi project
+ -proxy Create a Proxy project
+
+ CONTAINER Specify one of the following for J2EE or OSGi:
+ axis2 Create a Axis2 1.1 container
+ mini Create a Mini SOAP Engine container
+
The following arguments are optional:
+ -output DIR Specify an output direcgtory
-overwrite Overwrite files that exist
-help Display this message
- -helpmore Display more advanced help message
- </pre>
+ -helpmore Display more advanced help message</pre>
</code>
</blockquote>
</p>
<ul>
<li><b>-wsdl</b> - the WSDL file that we should analyze. This should be a filesystem path.</li><br/>
+ <li>You must specify a target platform. This is different than previous versions of wsdl2java, but after
+ some confusion on what the default should be the choice is now explicit.
+ <ul><br/>
+ <li><b>-j2ee</b> - Creates a J2EE project, which means the end result will be a Web ARchive File (WAR File).</li><br/>
+ <li><b>-osgi</b> - Creates an OSGi project, which means that the end result will be an OSGi Bundle Java ARchive File (JAR file).</li><br/>
+ <li><b>-proxy</b> - creates a Proxy project, which means that the end result will be a JAR file containing the proxy classes.</li><br/>
+ </ul>
+ </li>
+ <li>For OSGi and J2EE, you must specify a container. This is what handles the incoming requests and routes them to the Muse framework.
+ <ul><br/>
+ <li><b>axis2</b> - Uses an Axis2 1.1 container to host the Muse environment. This is a robust container which has many features.</li><br/>
+ <li><b>mini</b> - Uses the Muse Mini Servlet Engine which has a much smaller footprint than axis2. </li><br/>
+ </ul>
+ </li>
+ <li><b>-output</b> - tells the program to write all files to a given directory. When this optional flag is not present files are generated to the current directory.</li><br/>
<li><b>-overwrite</b> - tells the program to overwrite existing files</li><br/>
<li><b>-help</b> - prints the help message (same as running with no arguments)</li><br/>
<li><b>-helpmore</b> - prints advanced options (see below)</li><br/>
</ul>
-<p>Running wsdl2java with the "-helpmore" argument prints the following message to standard output:
+<p>There are other options for more advanced usage scenarios. These are not printed by default
+since they would just confuse regular users.
+Running wsdl2java with the "-helpmore" argument prints the following message to standard output:
<blockquote>
<code>
<pre>
Usage (one of the following):
-wsdl2java.[bat|sh] -wsdl FILE [OPTIONS]
+wsdl2java.[bat|sh] PLATFORM [CONTAINER] -wsdl FILE [OPTIONS]
-wsdl2java.[bat|sh] -descriptor FILE [OPTIONS]
+wsdl2java.[bat|sh] PLATFORM [CONTAINER] -descriptor FILE [OPTIONS]
One of the following arguments is required:
-wsdl FILE The WSDL definition file to analyze
-descriptor FILE The Muse descriptor to use
+ PLATFORM Must be one of the following:
+ -j2ee Create a J2EE project
+ -osgi Create a OSGi project
+ -proxy Create a Proxy project
+
+ CONTAINER Specify one of the following for J2EE or OSGi:
+ axis2 Create a Axis2 1.1 container
+ mini Create a Mini SOAP Engine container
+
The following arguments are optional:
+ -output DIR Specify an output direcgtory
-overwrite Overwrite files that exist
-analyzer CLASS The Analyzer component
-synthesizer CLASS The Synthesizer component
-projectizer CLASS The Projectizer component
-dump FILE Dump the built-in descriptor to a file
- -osgi Generate an OSGi project
- -proxy Generate a proxy project
+ -headers Generate a custom headers parameter in operations
-quiet Turn off all messages
-verbose Turn on verbose output
+ -version Print out the version
-help Display a simple help message
-helpmore Display this message
</pre>
@@ -259,31 +286,47 @@
</p>
<ul>
<li><b>-wsdl</b> - the WSDL file that we should analyze. This should be a filesystem path.</li><br/>
- <li><b>-desriptor</b> - the Muse descriptor we should analyze. This should be a filesystem path. You can specify both only one of -descriptor or -wsdl, they are mutally exclusive.</li><br/>
+ <li><b>-desriptor</b> - the Muse descriptor we should analyze. This should be a filesystem path. You can specify both only one of -descriptor or -wsdl, they are mutally exclusive. When generating from a single WSDL file only one resource-type will be generated (in most circumstances). In some instances,
+ a developer might want to make a more complex environment that can incorporate advanced Muse features and multiple resource-types. In this case
+ a user would pass in a <a href="../architecture/deployment-descriptor.html">Muse descriptor</a> that would contain all of the information
+ needed to generate the complex project.</li><br/>
+ <li>You must specify a target platform. This is different than previous versions of wsdl2java, but after
+ some confusion on what the default should be the choice is now explicit.
+ <ul><br/>
+ <li><b>-j2ee</b> - Creates a J2EE project, which means the end result will be a Web ARchive File (WAR File).</li><br/>
+ <li><b>-osgi</b> - Creates an OSGi project, which means that the end result will be an OSGi Bundle Java ARchive File (JAR file).</li><br/>
+ <li><b>-proxy</b> - creates a Proxy project, which means that the end result will be a JAR file containing the proxy classes.</li><br/>
+ </ul>
+ </li>
+ <li>For OSGi and J2EE, you must specify a container. This is what handles the incoming requests and routes them to the Muse framework.
+ <ul><br/>
+ <li><b>axis2</b> - Uses an Axis2 1.1 container to host the Muse environment. This is a robust container which has many features.</li><br/>
+ <li><b>mini</b> - Uses the Muse Mini Servlet Engine which has a much smaller footprint than axis2. </li><br/>
+ </ul>
+ </li>
+ <li><b>-output</b> - tells the program to write all files to a given directory. When this optional flag is not present files are generated to the current directory.</li><br/>
<li><b>-overwrite</b> - tells the program to overwrite existing files</li><br/>
<li><b>-analyzer</b> - specifies a class to plug in as the <a href="#analyzer">Analyzer</a></li><br/>
<li><b>-synthesizer</b> - specifies a class to plug in as the <a href="#synthesizer">Synthesizer</a></li><br/>
<li><b>-projectizer</b> - specifies a class to plug in as the <a href="#projectizer">Projectizer</a></li><br/>
<li><b>-dump</b> - tells the program to write the built-in skeleton descriptor to a file. This is useful as a starting point to write your own custom descriptor, it has reasonable default values.</li><br/>
- <li><b>-osgi</b> - tells the program to generate an OSGi project. This is really just a shortcut for specifying the OSGi projectizer.</li><br/>
- <li><b>-proxy</b> - tells the program to generate proxy code. This is the same as specifying the Proxy synthesizer and Proxy projectizer.</li><br/>
+ <li><b>-headers</b> - Tells the program to generate an extra parameter to every operation that allows for custom headers to be passed in. This is only implemented for Proxy generation.</li><br/>
<li><b>-quiet</b> - turns off all output (including error and warning messages)</li><br/>
<li><b>-verbose</b> - turn up verbosity, also print stack traces for errors.</li><br/>
+ <li><b>-version</b> - prints the version information and exits.</li><br/>
<li><b>-help</b> - prints the help message (same as running with no arguments)</li><br/>
- <li><b>-helpmore</b> - prints advanced options</li><br/>
+ <li><b>-helpmore</b> - prints advanced options (see below)</li><br/>
</ul>
</div>
<div class="section">
<h2 class="boxed"><a name="architecture_overview"></a>Architecture Overview</h2>
- <p>The tool will have a simple command-line interface that will take as
- few parameters as humanly possible. From these humble beginnings, the tool will
- analyze the wsdl and extract the following information:
+ <p>Wsdl2java performs the following functions during code generation:
<ol type="A">
- <li>The capabilities:
+ <li>Capability Extraction:
<ol type="a">
<li>Capabilities can be grouped by namespace.
This allows the tool to figure out which properties (from the properties document)
- and which operations (based on the namespace of the messages) belong to a common
+ and which operations (based on the namespace of the input elements of the messages) belong to a common
namespace (ie. capability). See below for <a href="#algorithm">details of the algorithm</a>.</li>
<li>For each capability the tool generates separate classes that implement the necessary operations
and have the necessary properties.</li>
@@ -291,9 +334,20 @@
</li>
<li>Deployment artifact generation:
<ol type="a">
- <li>Muse deployment artifacts will have to come from the analyzed WSDL.</li>
+ <li>Muse deployment artifacts will have to come from the analyzed WSDL. A Muse endpoint needs
+ to have a Muse deployment descriptor to function. However, the contents of this descriptor can be
+ inferred from the contents of the WSDL file for many common cases so that users do not need to
+ understand how to make a deployment descriptor to generate a project.</li>
</ol>
</li>
+ <li>Platform specific artifact generation:
+ <ol type="a">
+ <li>Each platform has specific files and a specific directory structure. Wsdl2java aims to
+ ease the burden of assembling these files by automatically creating the needed directory structure
+ and useful default values for all of the artifacts needed for deployment.</li>
+ <li>The same WSDL can be used to generate a variety of projects that target different environments.</li>
+ </ol>
+ </li>
<li>A java project
<ol type="a">
<li>An automatically generated directory structure that has
@@ -324,15 +378,6 @@
<p>The capability extraction can be summarized as follows:
<ol type="1">
<li>Read in the WSDL using wsdl4j.</li>
- <li>Analyze the types section to find all schemas:
- <ol type="a">
- <li>For each schema, locate its targetNamespace attribute and create a capability object
- for it, saving this object in a map if it wasn't there already.</li>
- <li>Recurse into the schema to find other referenced schemas, repeating step a. for each one. </li>
- </ol>
- </li>
- <li>Repeat step 2 for each wsdl or schema file imported.</li>
- <li>At this point there will be a map of URIs to <code>Capability</code> objects.</li>
<li>Get the service (there should only be one), get the port (there should only be one)
and then go through the portType for the given port.</li>
<li>Iterate over each operation in the portType. Use the namespace URI of the input
@@ -342,8 +387,30 @@
referenced element in the schemas referenced from the current WSDL.
Iterate through the list of elements and add each as a property for the given
<code>Capability</code> (based on the namespace URI of the element).</li>
+ <li>At this point there will be a map of URIs to <code>Capability</code> objects.</li>
</ol>
</p>
+ <p>Capability creation is lazy in the above algorithm to prevent unneeded Capabilities from being created. This
+ means that a Capability will only be created if an operation or property is found for that capability. This precludes
+ the ability to create empty Capabilities (that is, those that have no operations or properties) by using a WSDL descriptor. However,
+ if a Muse deployment descriptor is used during code generation, if a capability pair is defined that is not built
+ in and has not appeared in the WSDL then an empty capability will be generated during code generation. Empty capabilities
+ are useful for doing server-side tasks that don't fit neatly into other capabilities.</p>
+ <p>The code generation is also aware of the built-in implementations for the standard capabilities. This means
+ that by using the standard WSDL and schema descriptors for the built-in capabilities will not result in
+ skeleton implementation classes being generated for Capabilities such as Identity or Manageability Characteristics. By default,
+ if wsdl2java finds elements that belong to a certain built-in capability, the generated muse descriptor will
+ reference the built-in Muse class as the default implementation for the capability. In this way, a user can concentrate
+ only on creating their own custom capability implementations and wsdl2java will take care of plugging in the needed
+ web services plumbing.</p>
+ </div>
+ <div class="subsection">
+ <h2>WS-Notification Producer Support</h2>
+ <p>In general, one input WSDL will create a server-side project that has one resource-type in its Muse Deployment
+ descriptor. WS-Notification Producers need to also have a second resource-type that handles all of the subscriptions
+ for notifications that come in. Instead of forcing users to create a deployment descriptor when creating a
+ WS-NotificationProducer, wsdl2java will automatically add the required artifacts and augment the generated
+ deployment descriptor to contain a resource-type that implements a <a href="../capabilities/wsn-sub.html">Subscription Manager</a>.</p>
</div>
<div class="section">
<h2 class="boxed"><a name="synthesizer"></a>Synthesizer</h2>
@@ -359,33 +426,102 @@
</div>
<div class="subsection">
<h2>Client Proxy Code Generation</h2>
- <p>The client code generation already exists and creates a single class that exposes all of the
+ <p>The client code generation creates a single class that exposes all of the
properties and methods of the combined capabilities at the remote endpoint. This class converts
local requests into remote calls.</p>
+ <p>If using a deployment descriptor for generation, a proxy will be created for each resource-type
+ in the descriptor.</p>
+ <p>The -headers option add an extra parameter to each custom operation found in the analyzed WSDL files. This parameter
+ will be the last parameter in the parameter list and will be defined as: <code>Element[] customHeaders</code>. </p>
</div>
<div class="section">
<h2 class="boxed"><a name="projectizer"></a>Projectizer</h2>
<p>The Projectizer takes the Maps from the previous two stages and creates the necessary
project layout for the target platform. This class handles writing the files to disk and laying
- out a suitable directory structure along with descriptors and optional build scripts.</p>
+ out a suitable directory structure along with descriptors and optional build scripts. The projectizer
+ has the unpleasant and tedious task of laying out the right directory structure for OSGi, J2EE and Proxy
+ projects that would otherwise take many error-prone steps.</p>
+ <p>It been our experience that projectizers will grow in number while the synthesizers and analyzers have
+ stayed relatively stable. This allows for reuse of this tooling in other environments and for other platforms
+ without having to do any WSDL analysis.</p>
+ </div>
+ <div class="subsection">
+ <h2>J2EE Projectizer Family</h2>
+ <p>The J2EE platform is the most complicated platform for projectizing. It contains many descriptors
+ and has implied patterns for classloading locations. Currently, wsdl2java supports two engines
+ for the J2EE platform: Axis2 and Muse Mini Soap Servlet.</p>
+ <p>See the <a href="../../tutorial/03-wsdl2java.html#Section2">example</a> in the tutorial for more information.</p>
</div>
<div class="subsection">
- <h2>Axis2 Projectizer</h2>
- <p>Currently, we include a Projectizer for the Axis2 platform. This projectizer creates two directories:
- <code>WebContent</code> and <code>JavaSource</code>, along with a build.xml file for building with ant.
+ <h2>OSGi Projectizer Family</h2>
+ <p>Unlike the J2EE platform, the OSGi platform can be easily self-contained. The OSGi projectizer
+ will create everything that is needed to deploy and run the endpoint while the J2EE projectizer would
+ create only the deployable WAR that has to be deployed into a J2EE container like Tomcat. The OSGi projectizer
+ uses the Equinox framework as its OSGi implementation. Currently, wsdl2java supports two engines for the OSGi
+ platform: Axis2 and Muse Mini Soap Servlet. In essence, the engines serve as isolation layers
+ that isolate Muse from its environment.</p>
+ <p>The OSGi projectizer creates the necessary descriptor files and copies over all of the bundles
+ necessary to launch the generated project into an OSGi environment. See the
+ <a href="../../tutorial/03-wsdl2java.html#Section3">example</a> in the tutorial for more information. </p>
+ </div>
+ <div class="subsection">
+ <h2>Axis2 Engine</h2>
+ <p>The Axis2 1.1 engine project will contain two directories (as well as a <code>build.xml</code> and <code>.overwrite</code>):
+ <code>WebContent</code> and <code>JavaSource</code>.
This class also creates the necessary descriptors (muse.xml, services.xml) that include information
about the implementing classes. When ant is invoked in the directory where the code is generated,
a WAR file is created that matches the name of the current directory. So if the current working directory
- is "c:\foo\bar\example" then the build will create "example.war" when run. See the <a href="../../tutorial/03-wsdl2java.html#Section2">example</a> in the tutorial for more information.
- </div>
+ is "c:\foo\bar\example" then the build will create "example.war" when run.
+ </div>
<div class="subsection">
- <h2>OSGi Projectizer</h2>
- <p>The OSGi projectizer creates the necessary descriptor files and copies over all of the bundles necessary to launch the generated project into an OSGi environment. See the <a href="../../tutorial/03-wsdl2java.html#Section3">example</a> in the tutorial for more information. </p>
- </div>
+ <h2>Muse Mini Servlet Engine</h2>
+ <p>Although Axis2 provides a robust platform for hosting Muse endpoints, some users find that it
+ is too complex for their needs. On platforms such as J2ME, Axis2 is not a viable option because of the
+ limited subset of classes that are present.</p>
+ </div>
<div class="subsection">
<h2>Proxy Projectizer</h2>
<p>A proxy exposes all of the properties and operations of an endpoint using a Java facade. This is a useful convenience for interacting with the endpoint programmatically. See the <a href="../../tutorial/03-wsdl2java.html#Section4">example</a> in the tutorial for more information. </p>
</div>
+ <div class="subsection">
+ <h2>Overwriting</h2>
+ <p>During <a href="#iterative_development">iterative development</a>, it is common to generate a project into a target directory, find some changes
+ that need to be made to the WSDL and then regenerate into the same directory. In previous versions of Muse this
+ posed a problem in deciding which files to overwrite. Initially the approach was extreme caution: do not overwrite
+ anything that exists. This approach proved to be too restrictive for normal use. For example, it was not uncommon
+ for users to modify the generated build.xml that is generated and it was also required that users modify the
+ generated skeleton code for server-side capabilities that define their own operations. However, if the WSDL changed
+ and a user regenerated, the changes would not appear in the generated code since the default behaviour was not to overwrite
+ any existing files. If the user specified the -overwrite flag, there would be no checking of which files would be overwritten
+ creating a potentially dangerous situation wherein a user would overwrite files that contained hand-written
+ server-side implementation code.</p>
+ <p>To overcome these problems, wsdl2java now generates a simple list of files that are considered overwritable
+ in a file called <code>.overwrite</code> located in the root of the generated project directory. This file contains
+ an <b>include</b> list of files that can be overwritten without worry by the tooling. The file contains one file name
+ per line. Lines that begin with <code>#</code> are considered comments. If a user modifies a file that has been generated
+ by the tooling and does not wish for the tooling to overwrite the file during the subsequent generation, the user can simply
+ remove or comment out the file in the <code>.overwrite</code> manifest.</p>
+ <p>This also solves the problem of changing WSDL files and regenerating. The server-side code is split into
+ an implementation class and an interface. The implementation class is the place where users are expected
+ to add custom code. By default, the implementation class is <b>not</b> in the <code>.overwrite</code> file, while
+ the interface is added to the manifest. In this way, if the WSDL (that is, the interface description) changes, the
+ generated interface will be overwritten while leaving the implementation file untouched. If the user fails to
+ make the needed modifications to the implementation file to fulfill the requirements of the implementation class
+ a compilation error will occur alerting the user to missing operations.</p>
+ <p>It is also fully possible for a user to add other files to the <code>.overwrite</code> manifest. This could be
+ done if the implementation class does not have any custom operations or initialization code and can be safely regenerated
+ during subsequent calls to wsdl2java. A special case of this behaviour is adding the <code>.overwrite</code> file to itself.
+ This changes the behaviour to always overwriting all of the time. It would be the equivalent of running wsdl2java with
+ -overwrite every time. The only caveat here is that the .overwrite file is not overwritten since it no longer
+ matters. If you delete the .overwrite file, the next code generation will be done with no overwriting. To regenerate the default
+ <code>.overwrite</code> on such a project you must run wsdl2java with the -overwrite flag.</p>
+ </div>
+ <div class="subsection">
+ <h2>WS-ResourceMetadataDescriptor Support</h2>
+ <p>If there is a WS-ResourceMetadataDescriptor (.rmd file) referenced in the WSDL that is passed to
+ wsdl2java, that file will be carried through to the generated project. For more information about
+ see <a href="../capabilities/wsx.html">Metadata Exchange</a>.</p>
+ </div>
<div class="section">
<h2 class="boxed"><a name="iterative_development"></a>Iterative Development Usage Pattern</h2>
<p>We envision that this tool will be part of an iterative development procedure that looks like:
@@ -405,7 +541,7 @@
</div>
<div class="section">
<h2 class="boxed"><a name="code_reuse"></a>Code Reuse in Other Projects</h2>
- <p>This tool should have portions that are pluggable when value-added options are available.
+ <p>This tool should has portions that are pluggable when value-added options are available.
For example, it might make sense that if we are in the Eclipse tooling we use EMF-based code generation
for conflict resolution and automatic round-tripping. This would be a value-add that would make
changing the WSDL and regenerating a bit more informative than just breaking the abstract to implementation
@@ -433,8 +569,8 @@
<div class="description">
<span class="title">Description:</span> In this scenario a user would pass in a WSDL file to
the command line tool and the tool would examine the contents of the file, extract capability
- information (see above) and pass it to a proxy and server synthesizer. The synthesizer would create
- proxy classes for remote classes to use in calling out to the endpoint and the server skeleton
+ information (see above) and pass it to a proxy or server synthesizer. The synthesizer would create
+ proxy classes for remote classes to use in calling out to the endpoint or the server skeleton
classes for handling the requests. The server-side classes would implement the same interfaces
as the client side proxies, which would essentially be the capabilities extracted from the WSDL.
A Muse descriptor would be created to map the capability URIs to the generated classes.</div>
Modified: webservices/muse/site/docs/2.2.0/manual/tools/wsdlmerge.html
URL: http://svn.apache.org/viewvc/webservices/muse/site/docs/2.2.0/manual/tools/wsdlmerge.html?view=diff&rev=519035&r1=519034&r2=519035
==============================================================================
--- webservices/muse/site/docs/2.2.0/manual/tools/wsdlmerge.html (original)
+++ webservices/muse/site/docs/2.2.0/manual/tools/wsdlmerge.html Fri Mar 16 09:12:53 2007
@@ -130,6 +130,7 @@
<li>combine the WS-RF Document schema from each WSDL (if present) into a one merged WS-RF Document schema.</li>
<li>create a binding based on the new portType using conventions needed for wsdl2java and Muse.</li>
<li>create a service element that attaches to the new binding and portType.</li>
+ <li>optionally combine all of the referenced .rmd (WS-ResourceMetadataDescriptor) files referenced from the gathered WSDLs into one metadata descriptor.</li>
</ul>
</p>
<h2 class="boxed"><a name="usage"></a>Usage</h2>
@@ -143,12 +144,14 @@
The following arguments are required:
-uri URI The target namespace of the generated WSDL file
-address URL The address of the generated service
- -output FILE The address of the generated service
+ -output FILE The file where the merged wsdl will be written
FILES must be at least one WSDL file
The following arguments are optional:
+ -rmdoutput The file where the merged metadata will be written
-overwrite Overwrite files that exist
+ -version Print out the version
-help Display this message
</pre>
</code>
@@ -158,7 +161,9 @@
<li><b>-uri</b> - the targetNamespace of the newly created WSDL</li><br/>
<li><b>-address</b> - the address at which to create the service element</li><br/>
<li><b>-output</b> - the file name of the new WSDL</li><br/>
+ <li><b>-rmdoutput</b> - the file name of the combined RMD</li><br/>
<li><b>-overwrite</b> - tells the program to overwrite existing files</li><br/>
+ <li><b>-version</b> - prints the version information and exits.</li><br/>
<li><b>-help</b> - prints the help message (same as running with no arguments)</li><br/>
</ul>
For example a typical usage would be as follows:
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-commits-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-commits-help@ws.apache.org