You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by st...@apache.org on 2004/10/14 16:26:39 UTC
cvs commit: ws-axis/java/docs user-guide.html
stevel 2004/10/14 07:26:39
Modified: java/docs user-guide.html
Log:
Update for 1.2.
Note we need an endpoint with echo working, otherwise the tutorial is broken!
Revision Changes Path
1.93 +224 -222 ws-axis/java/docs/user-guide.html
Index: user-guide.html
===================================================================
RCS file: /home/cvs/ws-axis/java/docs/user-guide.html,v
retrieving revision 1.92
retrieving revision 1.93
diff -u -r1.92 -r1.93
--- user-guide.html 27 Mar 2004 12:35:46 -0000 1.92
+++ user-guide.html 14 Oct 2004 14:26:38 -0000 1.93
@@ -23,7 +23,7 @@
<li> <a href="#Installation">Installing Axis</a></li>
<li> <a href="#ConsumingServices">Consuming Web Services with Axis</a></li>
<li> <a href="#PublishingServices">Publishing Web Services with Axis</a></li>
- <li> <a href="#DataMapping">XML <-> Java Data Mapping in Axis</a></li>
+ <li> <a href="#DataMapping">XML <-> Java Data Mapping in Axis</a></li>
<li> <a href="#WSDL">Using WSDL with Axis</a></li>
<ul>
<li> <a href="#WSDL: Obtaining WSDL for deployed services">?WSDL: Obtaining
@@ -45,15 +45,18 @@
Welcome to Axis, the third generation of Apache SOAP!
<h3>
What is SOAP?</h3>
+
+<p>
SOAP is an XML<i>-</i>based communication protocol and encoding format for inter-application
communication. Originally conceived by Microsoft and Userland software, it has
-evolved through several generations and the current spec, <a href="http://w3.org/TR/soap">SOAP
-1.1</a>, is fast growing in popularity and usage. The W3C's <a href="http://www.w3.org/2000/xp/Group/">XML
-Protocol working group</a> is in the process of turning SOAP into a true open
-standard, and as of this writing has released a working draft of SOAP 1.2, which
-cleans up some of the more confusing areas of the 1.1 spec.
+evolved through several generations; the current spec is version,
+<a href="http://w3.org/TR/soap">SOAP 1.2</a>, though version1.1 is more
+widespread. The W3C's <a href="http://www.w3.org/2000/xp/Group/">XML
+Protocol working group</a> is in charge of the specification.
+</p>
<p>SOAP is widely viewed as the backbone to a new generation of cross-platform
cross-language distributed computing applications, termed Web Services.
+</p>
<h3>
What is Axis?</h3>
Axis is essentially a <i>SOAP engine</i> -- a framework for
@@ -154,16 +157,18 @@
<p>Before running the examples in this guide, you'll need to make sure
that your CLASSPATH includes
(Note: If you build Axis from a CVS checkout,
-these will be in xml-axis/java/build/lib instead of axis-1_1/lib):
+these will be in xml-axis/java/build/lib instead of axis-1_2/lib):
<ul>
-<li>axis-1_1/lib/axis.jar</li>
-<li>axis-1_1/lib/jaxrpc.jar</li>
-<li>axis-1_1/lib/saaj.jar</li>
-<li>axis-1_1/lib/commons-logging.jar</li>
-<li>axis-1_1/lib/commons-discovery.jar</li>
-<li>axis-1_1/lib/wsdl4j.jar</li>
- <li>axis-1_1/ <i><font color="#9966FF">(for the sample code)</font></i></li>
- <li>A JAXP-1.1 compliant XML parser such as Xerces or Crimson</li>
+<li>axis-1_2/lib/axis.jar</li>
+<li>axis-1_2/lib/jaxrpc.jar</li>
+<li>axis-1_2/lib/saaj.jar</li>
+<li>axis-1_2/lib/commons-logging.jar</li>
+<li>axis-1_2/lib/commons-discovery.jar</li>
+<li>axis-1_2/lib/wsdl4j.jar</li>
+<li>axis-1_2/ <i><font color="#9966FF">(for the sample code)</font></i></li>
+<li>A JAXP-1.1 compliant XML parser such as Xerces or Crimson. We recommend
+<A href="http://xml.apache.org/xerces2-j/">Xerces</A>, as it is the one
+that the product has been tested against.</li>
</ul>
<h2>
<a NAME="ConsumingServices"></a>Consuming Web Services with Axis</h2>
@@ -172,30 +177,30 @@
Basics - Getting Started</h3>
Let's take a look at an example Web Service client that will call the <b>echoString</b>
method on the public Axis server at Apache.
-<pre class="example">1 import org.apache.axis.client.Call;
-2 import org.apache.axis.client.Service;
-3 import javax.xml.namespace.QName;
-4
-5 public class TestClient {
-6 public static void main(String [] args) {
-7 try {
-8 String endpoint =
-9 "http://nagoya.apache.org:5049/axis/services/echo";
-10
-11 Service service = new Service();
-12 Call call = (Call) service.createCall();
-13
-14 call.setTargetEndpointAddress( new java.net.URL(endpoint) );
-15 call.setOperationName(new QName("<font color="#009933">http://soapinterop.org/</font>", "<font color="#993333">echoString</font>"));
-16
-17 String ret = (String) call.invoke( new Object[] { "<font color="#CC00CC">Hello!</font>" } );
-18
-19 System.out.println("Sent 'Hello!', got '" + ret + "'");
-20 } catch (Exception e) {
-21 System.err.println(e.toString());
-22 }
-23 }
-24 }</pre>
+<pre class="example">1 import org.apache.axis.client.Call;
+2 import org.apache.axis.client.Service;
+3 import javax.xml.namespace.QName;
+4
+5 public class TestClient {
+6 public static void main(String [] args) {
+7 try {
+8 String endpoint =
+9 "http://nagoya.apache.org:5049/axis/services/echo";
+10
+11 Service service = new Service();
+12 Call call = (Call) service.createCall();
+13
+14 call.setTargetEndpointAddress( new java.net.URL(endpoint) );
+15 call.setOperationName(new QName("<font color="#009933">http://soapinterop.org/</font>", "<font color="#993333">echoString</font>"));
+16
+17 String ret = (String) call.invoke( new Object[] { "<font color="#CC00CC">Hello!</font>" } );
+18
+19 System.out.println("Sent 'Hello!', got '" + ret + "'");
+20 } catch (Exception e) {
+21 System.err.println(e.toString());
+22 }
+23 }
+24 }</pre>
(You'll find this file in <a href="../samples/userguide/example1/TestClient.java">samples/userguide/example1/TestClient.java</a>)
<p>Assuming you have a network connection active, this program can be run
as follows:
@@ -214,13 +219,13 @@
values in the call above):
<pre class="xml"><?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
- <SOAP-ENV:Body>
- <ns1:<b><font color="#993333">echoString</font></b> xmlns:ns1="<b><font color="#009933">http://soapinterop.org/</font></b>">
- <arg0 xsi:type="xsd:string"><b><font color="#CC00CC">Hello!</font></b></arg0>
- </ns1:echoString>
- </SOAP-ENV:Body>
+ xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ <SOAP-ENV:Body>
+ <ns1:<b><font color="#993333">echoString</font></b> xmlns:ns1="<b><font color="#009933">http://soapinterop.org/</font></b>">
+ <arg0 xsi:type="xsd:string"><b><font color="#CC00CC">Hello!</font></b></arg0>
+ </ns1:echoString>
+ </SOAP-ENV:Body>
</SOAP-ENV:Envelope></pre>
<p>The String argument is automatically serialized into XML, and the server
responds with an identical String, which we deserialize and print.</p>
@@ -232,10 +237,10 @@
arguments in the SOAP message "arg0", "arg1", etc. (In this case there's just
"arg0") If you want to change this, it's easy! Before calling <tt>invoke()</tt>
you need to call <tt>addParameter</tt> for each parameter and <tt>setReturnType</tt> for the return, like so:
-<pre class="example"> call.addParameter("testParam",
- org.apache.axis.Constants.XSD_STRING,
- javax.xml.rpc.ParameterMode.IN);
- call.setReturnType(org.apache.axis.Constants.XSD_STRING); </pre>
+<pre class="example"> call.addParameter("testParam",
+ org.apache.axis.Constants.XSD_STRING,
+ javax.xml.rpc.ParameterMode.IN);
+ call.setReturnType(org.apache.axis.Constants.XSD_STRING); </pre>
This will assign the name <b>testParam</b> to the 1st (and only) parameter
on the invoke call. This will also define the type of the parameter (<tt>org.apache.axis.Constants.XSD_STRING</tt>)
and whether it is an input, output or inout parameter - in this case its
@@ -243,13 +248,13 @@
looks like this:
<pre class="xml"><?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
- <SOAP-ENV:Body>
- <ns1:echoString xmlns:ns1="http://soapinterop.org/">
- <<font color="#CC00CC">testParam</font> xsi:type="xsd:string">Hello!</<font color="#CC00CC">testParam</font>>
- </ns1:echoString>
- </SOAP-ENV:Body>
+ xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
+ xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ <SOAP-ENV:Body>
+ <ns1:echoString xmlns:ns1="http://soapinterop.org/">
+ <<font color="#CC00CC">testParam</font> xsi:type="xsd:string">Hello!</<font color="#CC00CC">testParam</font>>
+ </ns1:echoString>
+ </SOAP-ENV:Body>
</SOAP-ENV:Envelope></pre>
Note that the param is now named "testParam" as expected.
<h3>Interoperating with "untyped" servers</h3>
@@ -290,7 +295,7 @@
- data about data. In this case, we need a <b>description</b> of the service
that tells us what to expect as the return type. Here's how to do it on
the client side in Axis:</p>
-<pre class="example"> call.setReturnType( org.apache.axis.Constants.XSD_STRING );</pre>
+<pre class="example"> call.setReturnType( org.apache.axis.Constants.XSD_STRING );</pre>
<p>This method will tell the Axis client that if the return element is not typed
then it should act as if the return value has an xsi:type attribute set to the
predefined SOAP String type. (You can see an example of this in action in the
@@ -304,15 +309,15 @@
<a NAME="PublishingServices"></a>Publishing Web Services with Axis</h2>
Let's say we have a simple class like the following:
<pre class="example">public class Calculator {
- public int add(int i1, int i2)
- {
- return i1 + i2;
- }
-
- public int subtract(int i1, int i2)
- {
- return i1 - i2;
- }
+ public int add(int i1, int i2)
+ {
+ return i1 + i2;
+ }
+
+ public int subtract(int i1, int i2)
+ {
+ return i1 - i2;
+ }
}</pre>
(You'll find this very class in <a href="../samples/userguide/example2/Calculator.java">samples/userguide/example2/Calculator.java</a>.)
<p>How do we go about making this class available via SOAP? There are a
@@ -365,11 +370,11 @@
thing to deploy is a Web Service, so let's start by taking a look at a
deployment descriptor for a basic service (this file is <a href="../samples/userguide/example3/deploy.wsdd">samples/userguide/example3/deploy.wsdd</a>):</p>
<pre class="example"><deployment xmlns="http://xml.apache.org/axis/wsdd/"
- xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
- <service name="MyService" provider="java:RPC">
- <parameter name="className" value="samples.userguide.example3.MyService"/>
- <parameter name="allowedMethods" value="*"/>
- </service>
+ xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
+ <service name="MyService" provider="java:RPC">
+ <parameter name="className" value="samples.userguide.example3.MyService"/>
+ <parameter name="allowedMethods" value="*"/>
+ </service>
</deployment></pre>
Pretty simple, really - the outermost element tells the engine that this is a
WSDD deployment, and defines the "java" namespace. Then the service element actually
@@ -418,9 +423,9 @@
You typed : test me!
%</pre>
If you want to prove to yourself that the deployment really worked, try
-undeploying the service and calling it again. There's an "undeploy.wsdd"
+undeploying the service and calling it again. There's an "undeploy.wsdd"
file in the example3/ directory which you can use just as you did the deploy.wsdd
-file above. Run the AdminClient on that file, then try the service
+file above. Run the AdminClient on that file, then try the service
Client again and see what happens.
<p>You can also use the AdminClient to get a listing of all the deployed
components in the server:
@@ -438,21 +443,21 @@
the Handler itself, and then use the name that you give it in deploying
a service. Here's a sample deploy.wsdd file (this is example 4 in samples/userguide):
<pre class="example"><deployment xmlns="http://xml.apache.org/axis/wsdd/"
- xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
- <!-- define the logging handler configuration -->
- <handler name="track" type="java:samples.userguide.example4.LogHandler">
- <parameter name="filename" value="MyService.log"/>
- </handler>
-
- <!-- define the service, using the log handler we just defined -->
- <service name="LogTestService"<b> </b>provider="java:RPC">
- <requestFlow>
- <handler type="track"/>
- </requestFlow>
-
- <parameter name="className" value="samples.userguide.example4.Service"/>
- <parameter name="allowedMethods" value="*"/>
- </service>
+ xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
+ <!-- define the logging handler configuration -->
+ <handler name="track" type="java:samples.userguide.example4.LogHandler">
+ <parameter name="filename" value="MyService.log"/>
+ </handler>
+
+ <!-- define the service, using the log handler we just defined -->
+ <service name="LogTestService"<b> </b>provider="java:RPC">
+ <requestFlow>
+ <handler type="track"/>
+ </requestFlow>
+
+ <parameter name="className" value="samples.userguide.example4.Service"/>
+ <parameter name="allowedMethods" value="*"/>
+ </service>
</deployment></pre>
<p>The first section defines a Handler called "track" that is implemented
by the class samples.userguide.example4.LogHandler. We give this Handler
@@ -472,9 +477,9 @@
webapp's WEB-INF directory. In it, you'll see a deployment for the AdminService.
Add an option as follows:
<pre class="xml"><service name="AdminService" provider="java:MSG">
- <parameter name="className" value="org.apache.axis.util.Admin"/>
- <parameter name="allowedMethods" value="*"/>
- <b><parameter name="enableRemoteAdmin" value="true"/>
+ <parameter name="className" value="org.apache.axis.util.Admin"/>
+ <parameter name="allowedMethods" value="*"/>
+ <b><parameter name="enableRemoteAdmin" value="true"/>
</b></service></pre>
<p><b>WARNING: enabling remote administration may give unauthorized parties
access to your machine. If you do this, please make sure to add security
@@ -511,7 +516,7 @@
<p>A good place to start in describing the difference between document and wrapped
services is with a sample SOAP message containing a purchase order:</p>
<pre class="xml"><soap:Envelope xmlns="http://xml.apache.org/axis/wsdd/"
- xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
+ xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<soap:Body>
<myNS:PurchaseOrder xmlns:myNS="http://commerce.com/PO">
<item>SK001</item>
@@ -701,17 +706,6 @@
<h3>What Axis can send via SOAP with restricted Interoperability</h3>
-<h5>Unsigned data</h5>
-
-You cannot consume or generate services that use unsigned datatypes with
-pure JAX-RPC, because there are no unsigned dataypes in Java.
-<p>
-Axis does have support for the unsigned types, so you can consume services
-written in C++, C# and the like, and re-implement interfaces designed for
-those languages. Be very wary about exporting unsigned datatypes, however, as to
-do so will stop Java clients that do not use Axis or another SOAP client library
-with unsigned support from using them. The current JAX-RPC specification does
-not address this issue.
<h5>Java Collections</h5>
@@ -739,7 +733,7 @@
serialization support built in to Axis.
-Remote References
+<h5>Remote References</h5>
Remote references are neither part of the SOAP specification, nor the JAX-RPC
specification. You cannot return some object reference and expect the
@@ -755,7 +749,7 @@
of get/set accessors. All you need to do is tell Axis which Java classes
map to which XML Schema types. Configuring a bean mapping looks like this:
<pre class="xml"><beanMapping qname="ns:local" xmlns:ns="someNamespace"
- languageSpecificType="java:my.java.thingy"/></pre>
+ languageSpecificType="java:my.java.thingy"/></pre>
The <beanMapping> tag maps a Java class (presumably a bean) to an XML
QName. You'll note that it has two important attributes, <b>qname</b> and
<b>languageSpecificType</b>.
@@ -804,10 +798,10 @@
Axis which types they should be used for. You do this with a typeMapping
tag in WSDD, which looks like this:
<pre class="xml"><typeMapping qname="ns:local" xmlns:ns="someNamespace"
- languageSpecificType="java:my.java.thingy"
- serializer="my.java.Serializer"
- deserializer="my.java.DeserializerFactory"
- encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/></pre>
+ languageSpecificType="java:my.java.thingy"
+ serializer="my.java.Serializer"
+ deserializer="my.java.DeserializerFactory"
+ encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/></pre>
<p>This looks a lot like the <beanMapping> tag we saw earlier, but there
are three extra attributes. One, <b>serializer</b>, is the Java class name
of the Serializer <i>factory</i> which gets the serializer to
@@ -863,8 +857,8 @@
able to use it to access your service with toolkits like .NET, SOAP::Lite,
or any other software which supports using WSDL.
<p>You can also generate WSDL files from existing Java classes (see <a href="#Java2WSDL: Building WSDL from Java">Java2WSDL:
-Building WSDL from Java</a> ).
-<br>
+Building WSDL from Java</a> ).
+<br>
<h3><a NAME="WSDL2Java: Building stubs, skeletons, and data"></a>WSDL2Java:
Building stubs, skeletons, and data types from WSDL</h3>
@@ -875,15 +869,15 @@
% java org.apache.axis.wsdl.WSDL2Java (WSDL-file-URL)
</pre>
-<p>This will generate only those bindings necessary for the client.
+<p>This will generate only those bindings necessary for the client.
Axis follows the JAX-RPC specification when generating Java client bindings
-from WSDL. For this discussion, assume we executed the following:</p>
+from WSDL. For this discussion, assume we executed the following:</p>
<pre class="example">
% cd samples/addr
% java org.apache.axis.wsdl.WSDL2Java AddressBook.wsdl
</pre>
-<p>The generated files will reside in the directory "AddressFetcher2".
-They are put here because that is the target namespace from the WSDL and namespaces map to Java packages.
+<p>The generated files will reside in the directory "AddressFetcher2".
+They are put here because that is the target namespace from the WSDL and namespaces map to Java packages.
Namespaces will be discussed in detail later.</p>
<table BORDER COLS=2 WIDTH="100%" >
<tr>
@@ -933,31 +927,31 @@
action with an Ant based build process.
<h4>Types</h4>
-<p>The Java class generated from a WSDL type will be named from the WSDL type.
-This class will typically, though not always, be a bean. For example,
+<p>The Java class generated from a WSDL type will be named from the WSDL type.
+This class will typically, though not always, be a bean. For example,
given the WSDL (the WSDL used throughout the WSDL2Java discussion is from
the <a href="../samples/addr/AddressBook.wsdl">Address Book sample</a>):</p>
<pre class="example">
<xsd:complexType name="phone">
- <xsd:all>
- <xsd:element name="areaCode" type="xsd:int"/>
- <xsd:element name="exchange" type="xsd:string"/>
- <xsd:element name="number" type="xsd:string"/>
- </xsd:all>
+ <xsd:all>
+ <xsd:element name="areaCode" type="xsd:int"/>
+ <xsd:element name="exchange" type="xsd:string"/>
+ <xsd:element name="number" type="xsd:string"/>
+ </xsd:all>
</xsd:complexType>
</pre>
<p>WSDL2Java will generate:
<pre class="example">
public class Phone implements java.io.Serializable {
- public Phone() {...}
- public int getAreaCode() {...}
- public void setAreaCode(int areaCode) {...}
- public java.lang.String getExchange() {...}
- public void setExchange(java.lang.String exchange) {...}
- public java.lang.String getNumber() {...}
- public void setNumber(java.lang.String number) {...}
- public boolean equals(Object obj) {...}
- public int hashCode() {...}
+ public Phone() {...}
+ public int getAreaCode() {...}
+ public void setAreaCode(int areaCode) {...}
+ public java.lang.String getExchange() {...}
+ public void setExchange(java.lang.String exchange) {...}
+ public java.lang.String getNumber() {...}
+ public void setNumber(java.lang.String number) {...}
+ public boolean equals(Object obj) {...}
+ public int hashCode() {...}
}
</pre>
<h4>Mapping XML to Java types : Metadata</h4>
@@ -982,10 +976,10 @@
class in the Axis source, or generate your own bean from XML which uses attributes
or names which would be illegal in Java.</p>
<h4>Holders</h4>
-<p>This type may be used as an inout or out parameter. Java does not
-have the concept of inout/out parameters. In order to achieve this
-behavior, JAX-RPC specifies the use of holder classes. A holder class
-is simply a class that contains an instance of its type. For example,
+<p>This type may be used as an inout or out parameter. Java does not
+have the concept of inout/out parameters. In order to achieve this
+behavior, JAX-RPC specifies the use of holder classes. A holder class
+is simply a class that contains an instance of its type. For example,
the holder for the Phone class would be:</p>
<pre class="example">
package samples.addr.holders;
@@ -1007,18 +1001,18 @@
<p>The holder classes for the primitive types can be found in javax.xml.rpc.holders.</p>
<h4>PortTypes</h4>
<p>The Service Definition Interface (SDI) is the interface that's derived
-from a WSDL's portType. This is the interface you use to access the
-operations on the service. For example, given the WSDL:</p>
+from a WSDL's portType. This is the interface you use to access the
+operations on the service. For example, given the WSDL:</p>
<pre class="example">
<message name="empty">
<message name="AddEntryRequest">
- <part name="name" type="xsd:string"/>
- <part name="address" type="typens:address"/>
+ <part name="name" type="xsd:string"/>
+ <part name="address" type="typens:address"/>
</message>
<portType name="AddressBook">
- <operation name="addEntry">
- <input message="tns:AddEntryRequest"/>
- <output message="tns:empty"/>
+ <operation name="addEntry">
+ <input message="tns:AddEntryRequest"/>
+ <output message="tns:empty"/>
</operation>
</portType>
</pre>
@@ -1054,12 +1048,13 @@
document/literal changes what the interface looks like, and we could
have more than one binding referring to a single portType, we have to
create more than one interface, and each interface must have a unique name.
-<br>
+
<h4>
Bindings</h4>
-A Stub class implements the SDI. Its name is the binding name with
-the suffix "Stub". It contains the code which turns the method invocations
-into SOAP calls using the Axis Service and Call objects. It stands
+
+A Stub class implements the SDI. Its name is the binding name with
+the suffix "Stub". It contains the code which turns the method invocations
+into SOAP calls using the Axis Service and Call objects. It stands
in as a <b>proxy</b> (another term for the same idea) for the remote service,
letting you call it exactly as if it were a local object. In other words,
you don't need to deal with the endpoint URL, namespace, or parameter arrays
@@ -1067,49 +1062,49 @@
The stub hides all that work for you.
<p>Given the following WSDL snippet:
<pre class="example"><binding name="AddressBookSOAPBinding" type="tns:AddressBook">
- ...
+ ...
</binding></pre>
<p>WSDL2Java will generate:
<pre class="example">public class AddressBookSOAPBindingStub extends org.apache.axis.client.Stub
implements AddressBook {
- public AddressBookSOAPBindingStub() throws org.apache.axis.AxisFault
+ public AddressBookSOAPBindingStub() throws org.apache.axis.AxisFault
{...}
- public AddressBookSOAPBindingStub(URL endpointURL,
+ public AddressBookSOAPBindingStub(URL endpointURL,
javax.xml.rpc.Service service)
throws org.apache.axis.AxisFault
{...}
-<br> public AddressBookSOAPBindingStub(javax.xml.rpc.Service service)
+<br> public AddressBookSOAPBindingStub(javax.xml.rpc.Service service)
throws org.apache.axis.AxisFault
{...}
-<br> public void addEntry(String name, Address address) throws RemoteException
+<br> public void addEntry(String name, Address address) throws RemoteException
{...}<br>}</pre>
<h4>
Services</h4>
-Normally, a client program would not instantiate a stub directly.
+Normally, a client program would not instantiate a stub directly.
It would instead instantiate a service locator and call a get method which
-returns a stub. This locator is derived from the service clause in
-the WSDL. WSDL2Java generates two objects from a service clause.
+returns a stub. This locator is derived from the service clause in
+the WSDL. WSDL2Java generates two objects from a service clause.
For example, given the WSDL:
<pre class="example"><service name="AddressBookService">
- <port name="AddressBook" binding="tns:AddressBookSOAPBinding">
- <soap:address location="http://localhost:8080/axis/services/AddressBook"/>
- </port>
+ <port name="AddressBook" binding="tns:AddressBookSOAPBinding">
+ <soap:address location="http://localhost:8080/axis/services/AddressBook"/>
+ </port>
</service></pre>
<p>WSDL2Java will generate the service interface:
<pre class="example">public interface AddressBookService extends javax.xml.rpc.Service {
- public String getAddressBookAddress();
-<br> public AddressBook getAddressBook() throws javax.xml.rpc.ServiceException;
-<br> public AddressBook getAddressBook(URL portAddress) throws javax.xml.rpc.ServiceException;
+ public String getAddressBookAddress();
+<br> public AddressBook getAddressBook() throws javax.xml.rpc.ServiceException;
+<br> public AddressBook getAddressBook(URL portAddress) throws javax.xml.rpc.ServiceException;
}</pre>
<p>WSDL2Java will also generate the locator which implements this interface:
<pre class="example">public class AddressBookServiceLocator extends org.apache.axis.client.Service
implements AddressBookService {
- ...
+ ...
}</pre>
<p>The service interface defines a get method for each port listed in the
service element of the WSDL. The locator is the implementation of this
-service interface. It implements these get methods. It serves as
+service interface. It implements these get methods. It serves as
a locator for obtaining Stub instances. The Service class will by default
make a Stub which points to the endpoint URL described in the WSDL file,
but you may also specify a different URL when you ask for the PortType.
@@ -1117,30 +1112,30 @@
<pre class="example">public class Tester
{
- public static void main(String [] args) throws Exception {
- // Make a service
- AddressBookService service = new AddressBookServiceLocator();
-
- // Now use the service to get a stub which implements the SDI.
- AddressBook port = service.getAddressBook();
-
- // Make the actual call
- Address address = new Address(...);
- port.addEntry("Russell Butek", address);
- }<br>}</pre>
+ public static void main(String [] args) throws Exception {
+ // Make a service
+ AddressBookService service = new AddressBookServiceLocator();
+
+ // Now use the service to get a stub which implements the SDI.
+ AddressBook port = service.getAddressBook();
+
+ // Make the actual call
+ Address address = new Address(...);
+ port.addEntry("Russell Butek", address);
+ }<br>}</pre>
<h4>
Server-side bindings</h4>
Just as a stub is the client side of a Web Service represented in Java,
-a <b>skeleton</b> is a Java framework for the server side. To make
+a <b>skeleton</b> is a Java framework for the server side. To make
skeleton classes, you just specify the "--server-side --skeletonDeploy true" options
to WSDL2Java.
For instance, using the AddressBook.wsdl as we had above:
<pre class="example">% java org.apache.axis.wsdl.WSDL2Java --server-side --skeletonDeploy true AddressBook.wsdl</pre>
<p>You will see that WSDL2Java generates all the classes that were generated
before for the client, but it generates a few new files:
-<br>
-<br>
+<br>
+<br>
<table BORDER COLS=2 WIDTH="100%" >
<tr>
<td><b>WSDL clause</b></td>
@@ -1181,8 +1176,8 @@
Here is how you run WSDL2Java to deploy directly to the implementation:
<pre class="example">% java org.apache.axis.wsdl.WSDL2Java --server-side AddressBook.wsdl</pre>
<p>And here are the server side files that are generated:
-<br>
-<br>
+<br>
+<br>
<table BORDER COLS=2 WIDTH="100%" >
<tr>
<td><b>WSDL clause</b></td>
@@ -1214,32 +1209,32 @@
<h5>
Skeleton Description (for Skeleton Deployment) </h5>
The skeleton class is the class that sits between the Axis engine and the
-actual service implementation. Its name is the binding name with
-suffix "Skeleton". For example, for the AddressBook binding, WSDL2Java
+actual service implementation. Its name is the binding name with
+suffix "Skeleton". For example, for the AddressBook binding, WSDL2Java
will generate:
<pre class="example">public class AddressBookSOAPBindingSkeleton implements AddressBook,
- org.apache.axis.wsdl.Skeleton {
- private AddressBook impl;
-
- public AddressBookSOAPBindingSkeleton() {
- this.impl = new AddressBookSOAPBindingImpl();
- }
-
- public AddressBookSOAPBindingSkeleton(AddressBook impl) {
- this.impl = impl;
- }
-
- public void addEntry(java.lang.String name, Address address)
+ org.apache.axis.wsdl.Skeleton {
+ private AddressBook impl;
+
+ public AddressBookSOAPBindingSkeleton() {
+ this.impl = new AddressBookSOAPBindingImpl();
+ }
+
+ public AddressBookSOAPBindingSkeleton(AddressBook impl) {
+ this.impl = impl;
+ }
+
+ public void addEntry(java.lang.String name, Address address)
throws java.rmi.RemoteException
- {
- impl.addEntry(name, address);
- }
+ {
+ impl.addEntry(name, address);
+ }
}</pre>
-<p>(The real skeleton is actually much richer. For brevity we just show
+<p>(The real skeleton is actually much richer. For brevity we just show
you the basic skeleton.)
-<p>The skeleton contains an implementation of the AddressBook service.
+<p>The skeleton contains an implementation of the AddressBook service.
This implementation is either passed into the skeleton on construction,
-or an instance of the generated implementation is created. When the
+or an instance of the generated implementation is created. When the
Axis engine calls the skeleton's addEntry method, it simply delegates the
invocation to the real implementation's addEntry method.
<h5>
@@ -1247,15 +1242,15 @@
<p>WSDL2Java also generates an implementation template
from the binding:
<pre class="example">public class AddressBookSOAPBindingImpl implements AddressBook {
-<br> public void addEntry(String name, Address address)
+<br> public void addEntry(String name, Address address)
throws java.rmi.RemoteException {
- }
+ }
}</pre>
<p>This template could actually be used as a test implementation but, as
-you can see, it doesn't do anything. It is intended that the service
+you can see, it doesn't do anything. It is intended that the service
writer fill out the implementation from this template.</p>
<p>When WSDL2Java is asked to generate the implementation template (via the --server-side
- flag), it will ONLY generate it if it does not already exist. If this
+ flag), it will ONLY generate it if it does not already exist. If this
implementation already exists, it will not be overwritten.</p>
<h4>Services</h4>
<p>The tool also builds you a "deploy.wsdd" and an "undeploy.wsdd" for each
@@ -1264,20 +1259,23 @@
compiled the code, and made the classes available to your Axis engine.</p>
<h3><a NAME="Java2WSDL: Building WSDL from Java"></a>Java2WSDL: Building WSDL
from Java</h3>
-The Java2WSDL and WSDL2Java emitters make it easy to develop a new web service. The following sections describe the steps in building a web service from a Java interface.
-<br>
+The Java2WSDL and WSDL2Java emitters make it easy to develop a new web service.
+The following sections describe the steps in building a web service from a Java interface.
+<br>
<h4>
Step 1: Provide a Java interface or class</h4>
Write and compile a Java interface (or class) that describes the web service
-interface. Here is an example interface that describes a web services
-that can be used to set/query the price of widgets (<a href="../samples/userguide/example6/WidgetPrice.java">samples/userguide/example6/WidgetPrice.java</a>):
+interface. Here is an example interface that describes a web services
+that can be used to set/query the price of widgets
+(<a href="../samples/userguide/example6/WidgetPrice.java">samples/userguide/example6/WidgetPrice.java</a>):
<pre class="example">package samples.userguide.example6;
-<br>/**
- * Interface describing a web service to set and get Widget prices.
- **/
+
+/**
+ * Interface describing a web service to set and get Widget prices.
+ **/
public interface WidgetPrice {
- public void setWidgetPrice(String widgetName, String price);
- public String getWidgetPrice(String widgetName);
+ public void setWidgetPrice(String widgetName, String price);
+ public String getWidgetPrice(String widgetName);
}</pre>
<p><b>Note: </b>If you compile your class with debug information, Java2WSDL
will use the debug information to obtain the method parameter names.
@@ -1285,8 +1283,10 @@
Step 2: Create WSDL using Java2WSDL</h4>
Use the Java2WSDL tool to create a WSDL file from the interface above.
<p>Here is an example invocation that produces the wsdl file (<tt>wp.wsdl</tt>)
-from the interface described in the previous section:
-<pre class="example">% java org.apache.axis.wsdl.Java2WSDL -o wp.wsdl -l"http://localhost:8080/axis/services/WidgetPrice" -n "urn:Example6" -p"samples.userguide.example6" "urn:Example6" samples.userguide.example6.WidgetPrice</pre>
+from the interface described in the previous section (entered all on one line):
+<pre class="example">% java org.apache.axis.wsdl.Java2WSDL -o wp.wsdl
+ -l"http://localhost:8080/axis/services/WidgetPrice" -n "urn:Example6"
+ -p"samples.userguide.example6" "urn:Example6" samples.userguide.example6.WidgetPrice</pre>
<p>Where:
<ul>
<li>
@@ -1299,7 +1299,7 @@
-n is the target <b><i>namespace</i></b> of the WSDL file</li>
<li>
--p indicates a mapping from the <b><i>package to a namespace</i></b>.
+-p indicates a mapping from the <b><i>package to a namespace</i></b>.
There may be multiple mappings.</li>
<li>
@@ -1307,9 +1307,9 @@
</ul>
The output WSDL document will contain the appropriate WSDL types, messages,
portType, bindings and service descriptions to support a SOAP rpc, encoding
-web service. If your specified interface methods reference other
+web service. If your specified interface methods reference other
classes, the Java2WSDL tool will generate the appropriate xml types to
-represent the classes and any nested/inherited types. The tool supports
+represent the classes and any nested/inherited types. The tool supports
JAX-RPC complex types (bean classes), extension classes, enumeration classes,
arrays and Holder classes.
<p>The Java2WSDL tool has many additional options which are detailed in the <a href="reference.html#Java2WSDL">reference
@@ -1320,18 +1320,19 @@
<h4>
Step 3: Create Bindings using WSDL2Java</h4>
+
Use the generated WSDL file to build the appropriate client/server bindings
for the web service (see <a href="#WSDL2Java: Building stubs, skeletons, and data">WSDL2Java</a>):
-<pre class="example">% java org.apache.axis.wsdl.WSDL2Java -o . -d Session -s -S true -Nurn:Example6 samples.userguide.example6 wp.wsdl</pre>
+<pre class="example">% java org.apache.axis.wsdl.WSDL2Java -o . -d Session -s -S true -Nurn:Example6 samples.userguide.example6 wp.wsdl</pre>
<p>This will generate the following files:
<ul>
<li> <b><tt>WidgetPriceSoapBindingImpl.java</tt></b> : Java file containing
the default server implementation of the WidgetPrice web service.</li>
<br>
You will need to modify the *SoapBindingImpl file to add your implementation
- (see <a href="../samples/userguide/example6/WidgetPriceSoapBindingImpl.java">../samples/userguide/example6/WidgetPriceSoapBindingImpl.java</a>
+ (see <a href="../samples/userguide/example6/WidgetPriceSoapBindingImpl.java">../samples/userguide/example6/WidgetPriceSoapBindingImpl.java</a>
).
- <li> <b><tt>WidgetPrice.java</tt></b>: New interface file that contains
+ <li> <b><tt>WidgetPrice.java</tt></b>: New interface file that contains
the appropriate <b><tt>java.rmi.Remote</tt></b> usages.</li>
<li> <b><tt>WidgetPriceService.java</tt></b>: Java file containing the client
side service interface.</li>
@@ -1341,14 +1342,15 @@
<li> <b><tt>WidgetPriceSoapBindingStub.java</tt></b>: Client side stub.</li>
<li> <b><tt>deploy.wsdd</tt></b>: Deployment descriptor</li>
<li> <b><tt>undeploy.wsdd</tt></b>: Undeployment descriptor</li>
- <li> (data types): Java files will be produced for all of the other types
- and holders necessary for the web service. There are no additional files
+ <li> (data types): Java files will be produced for all of the other types
+ and holders necessary for the web service. There are no additional files
for the WidgetPrice web service.</li>
</ul>
<p>Now you have all of the necessary files to build your client/server side code
and deploy the web service!</p>
<h2>
<a NAME="published interfaces"></a>Published Axis Interfaces</h2>
+
Although you may use any of the interfaces and classes present in Axis, you need to
be aware that some are more stable than others since there is a continuing
need to refactor Axis to maintain and improve its modularity.
Re: cvs commit: ws-axis/java/docs user-guide.html
Posted by Toshiyuki Kimura <to...@apache.org>.
Hi Steve,
Could you please commit an original source of the content ? That is,
'ws-axis/site/src/documentation/content/xdocs/java/user-guide.ihtml'.
You might have made the change w/o using Forrest though, your change
will be lost in the next update for the same content if you don't keep
the original source - 'user-guide.ihtml' as the latest one.
After building the content using Forrest, you have to commit following
three files.
user-guide.ihtml to ws-axis/site/src/documentation/content/xdocs/java
user-guide.html to ws-site/targets/axis/java
user-guide.pdf to ws-site/targets/axis/java
Perhaps the problem is that the current instruction is not enough to
explain the complicated operations. I've talked about this issue with
tetsuya who is a contributor of the current ws-site.
I'd like to maintain the following content later. Any other thought ?
<http://ws.apache.org/howtobuild.html>
Thanks,
Toshi
On Thu, 14 Oct 2004 stevel@apache.org wrote:
> stevel 2004/10/14 07:26:39
>
> Modified: java/docs user-guide.html
> Log:
> Update for 1.2.
> Note we need an endpoint with echo working, otherwise the tutorial is broken!
>
> Revision Changes Path
> 1.93 +224 -222 ws-axis/java/docs/user-guide.html
>
> Index: user-guide.html
> ===================================================================
> RCS file: /home/cvs/ws-axis/java/docs/user-guide.html,v
> retrieving revision 1.92
> retrieving revision 1.93
> diff -u -r1.92 -r1.93
> --- user-guide.html 27 Mar 2004 12:35:46 -0000 1.92
> +++ user-guide.html 14 Oct 2004 14:26:38 -0000 1.93
> @@ -23,7 +23,7 @@
> <li> <a href="#Installation">Installing Axis</a></li>
> <li> <a href="#ConsumingServices">Consuming Web Services with Axis</a></li>
> <li> <a href="#PublishingServices">Publishing Web Services with Axis</a></li>
> - <li> <a href="#DataMapping">XML <-> Java Data Mapping in Axis</a></li>
> + <li> <a href="#DataMapping">XML <-> Java Data Mapping in Axis</a></li>
> <li> <a href="#WSDL">Using WSDL with Axis</a></li>
> <ul>
> <li> <a href="#WSDL: Obtaining WSDL for deployed services">?WSDL: Obtaining
> @@ -45,15 +45,18 @@
> Welcome to Axis, the third generation of Apache SOAP!
> <h3>
> What is SOAP?</h3>
> +
> +<p>
> SOAP is an XML<i>-</i>based communication protocol and encoding format for inter-application
> communication. Originally conceived by Microsoft and Userland software, it has
> -evolved through several generations and the current spec, <a href="http://w3.org/TR/soap">SOAP
> -1.1</a>, is fast growing in popularity and usage. The W3C's <a href="http://www.w3.org/2000/xp/Group/">XML
> -Protocol working group</a> is in the process of turning SOAP into a true open
> -standard, and as of this writing has released a working draft of SOAP 1.2, which
> -cleans up some of the more confusing areas of the 1.1 spec.
> +evolved through several generations; the current spec is version,
> +<a href="http://w3.org/TR/soap">SOAP 1.2</a>, though version1.1 is more
> +widespread. The W3C's <a href="http://www.w3.org/2000/xp/Group/">XML
> +Protocol working group</a> is in charge of the specification.
> +</p>
> <p>SOAP is widely viewed as the backbone to a new generation of cross-platform
> cross-language distributed computing applications, termed Web Services.
> +</p>
> <h3>
> What is Axis?</h3>
> Axis is essentially a <i>SOAP engine</i> -- a framework for
> @@ -154,16 +157,18 @@
> <p>Before running the examples in this guide, you'll need to make sure
> that your CLASSPATH includes
> (Note: If you build Axis from a CVS checkout,
> -these will be in xml-axis/java/build/lib instead of axis-1_1/lib):
> +these will be in xml-axis/java/build/lib instead of axis-1_2/lib):
> <ul>
> -<li>axis-1_1/lib/axis.jar</li>
> -<li>axis-1_1/lib/jaxrpc.jar</li>
> -<li>axis-1_1/lib/saaj.jar</li>
> -<li>axis-1_1/lib/commons-logging.jar</li>
> -<li>axis-1_1/lib/commons-discovery.jar</li>
> -<li>axis-1_1/lib/wsdl4j.jar</li>
> - <li>axis-1_1/ <i><font color="#9966FF">(for the sample code)</font></i></li>
> - <li>A JAXP-1.1 compliant XML parser such as Xerces or Crimson</li>
> +<li>axis-1_2/lib/axis.jar</li>
> +<li>axis-1_2/lib/jaxrpc.jar</li>
> +<li>axis-1_2/lib/saaj.jar</li>
> +<li>axis-1_2/lib/commons-logging.jar</li>
> +<li>axis-1_2/lib/commons-discovery.jar</li>
> +<li>axis-1_2/lib/wsdl4j.jar</li>
> +<li>axis-1_2/ <i><font color="#9966FF">(for the sample code)</font></i></li>
> +<li>A JAXP-1.1 compliant XML parser such as Xerces or Crimson. We recommend
> +<A href="http://xml.apache.org/xerces2-j/">Xerces</A>, as it is the one
> +that the product has been tested against.</li>
> </ul>
> <h2>
> <a NAME="ConsumingServices"></a>Consuming Web Services with Axis</h2>
> @@ -172,30 +177,30 @@
> Basics - Getting Started</h3>
> Let's take a look at an example Web Service client that will call the <b>echoString</b>
> method on the public Axis server at Apache.
> -<pre class="example">1 import org.apache.axis.client.Call;
> -2 import org.apache.axis.client.Service;
> -3 import javax.xml.namespace.QName;
> -4
> -5 public class TestClient {
> -6 public static void main(String [] args) {
> -7 try {
> -8 String endpoint =
> -9 "http://nagoya.apache.org:5049/axis/services/echo";
> -10
> -11 Service service = new Service();
> -12 Call call = (Call) service.createCall();
> -13
> -14 call.setTargetEndpointAddress( new java.net.URL(endpoint) );
> -15 call.setOperationName(new QName("<font color="#009933">http://soapinterop.org/</font>", "<font color="#993333">echoString</font>"));
> -16
> -17 String ret = (String) call.invoke( new Object[] { "<font color="#CC00CC">Hello!</font>" } );
> -18
> -19 System.out.println("Sent 'Hello!', got '" + ret + "'");
> -20 } catch (Exception e) {
> -21 System.err.println(e.toString());
> -22 }
> -23 }
> -24 }</pre>
> +<pre class="example">1 import org.apache.axis.client.Call;
> +2 import org.apache.axis.client.Service;
> +3 import javax.xml.namespace.QName;
> +4
> +5 public class TestClient {
> +6 public static void main(String [] args) {
> +7 try {
> +8 String endpoint =
> +9 "http://nagoya.apache.org:5049/axis/services/echo";
> +10
> +11 Service service = new Service();
> +12 Call call = (Call) service.createCall();
> +13
> +14 call.setTargetEndpointAddress( new java.net.URL(endpoint) );
> +15 call.setOperationName(new QName("<font color="#009933">http://soapinterop.org/</font>", "<font color="#993333">echoString</font>"));
> +16
> +17 String ret = (String) call.invoke( new Object[] { "<font color="#CC00CC">Hello!</font>" } );
> +18
> +19 System.out.println("Sent 'Hello!', got '" + ret + "'");
> +20 } catch (Exception e) {
> +21 System.err.println(e.toString());
> +22 }
> +23 }
> +24 }</pre>
> (You'll find this file in <a href="../samples/userguide/example1/TestClient.java">samples/userguide/example1/TestClient.java</a>)
> <p>Assuming you have a network connection active, this program can be run
> as follows:
> @@ -214,13 +219,13 @@
> values in the call above):
> <pre class="xml"><?xml version="1.0" encoding="UTF-8"?>
> <SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> - xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> - <SOAP-ENV:Body>
> - <ns1:<b><font color="#993333">echoString</font></b> xmlns:ns1="<b><font color="#009933">http://soapinterop.org/</font></b>">
> - <arg0 xsi:type="xsd:string"><b><font color="#CC00CC">Hello!</font></b></arg0>
> - </ns1:echoString>
> - </SOAP-ENV:Body>
> + xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> + <SOAP-ENV:Body>
> + <ns1:<b><font color="#993333">echoString</font></b> xmlns:ns1="<b><font color="#009933">http://soapinterop.org/</font></b>">
> + <arg0 xsi:type="xsd:string"><b><font color="#CC00CC">Hello!</font></b></arg0>
> + </ns1:echoString>
> + </SOAP-ENV:Body>
> </SOAP-ENV:Envelope></pre>
> <p>The String argument is automatically serialized into XML, and the server
> responds with an identical String, which we deserialize and print.</p>
> @@ -232,10 +237,10 @@
> arguments in the SOAP message "arg0", "arg1", etc. (In this case there's just
> "arg0") If you want to change this, it's easy! Before calling <tt>invoke()</tt>
> you need to call <tt>addParameter</tt> for each parameter and <tt>setReturnType</tt> for the return, like so:
> -<pre class="example"> call.addParameter("testParam",
> - org.apache.axis.Constants.XSD_STRING,
> - javax.xml.rpc.ParameterMode.IN);
> - call.setReturnType(org.apache.axis.Constants.XSD_STRING); </pre>
> +<pre class="example"> call.addParameter("testParam",
> + org.apache.axis.Constants.XSD_STRING,
> + javax.xml.rpc.ParameterMode.IN);
> + call.setReturnType(org.apache.axis.Constants.XSD_STRING); </pre>
> This will assign the name <b>testParam</b> to the 1st (and only) parameter
> on the invoke call. This will also define the type of the parameter (<tt>org.apache.axis.Constants.XSD_STRING</tt>)
> and whether it is an input, output or inout parameter - in this case its
> @@ -243,13 +248,13 @@
> looks like this:
> <pre class="xml"><?xml version="1.0" encoding="UTF-8"?>
> <SOAP-ENV:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> - xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> - <SOAP-ENV:Body>
> - <ns1:echoString xmlns:ns1="http://soapinterop.org/">
> - <<font color="#CC00CC">testParam</font> xsi:type="xsd:string">Hello!</<font color="#CC00CC">testParam</font>>
> - </ns1:echoString>
> - </SOAP-ENV:Body>
> + xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
> + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
> + <SOAP-ENV:Body>
> + <ns1:echoString xmlns:ns1="http://soapinterop.org/">
> + <<font color="#CC00CC">testParam</font> xsi:type="xsd:string">Hello!</<font color="#CC00CC">testParam</font>>
> + </ns1:echoString>
> + </SOAP-ENV:Body>
> </SOAP-ENV:Envelope></pre>
> Note that the param is now named "testParam" as expected.
> <h3>Interoperating with "untyped" servers</h3>
> @@ -290,7 +295,7 @@
> - data about data. In this case, we need a <b>description</b> of the service
> that tells us what to expect as the return type. Here's how to do it on
> the client side in Axis:</p>
> -<pre class="example"> call.setReturnType( org.apache.axis.Constants.XSD_STRING );</pre>
> +<pre class="example"> call.setReturnType( org.apache.axis.Constants.XSD_STRING );</pre>
> <p>This method will tell the Axis client that if the return element is not typed
> then it should act as if the return value has an xsi:type attribute set to the
> predefined SOAP String type. (You can see an example of this in action in the
> @@ -304,15 +309,15 @@
> <a NAME="PublishingServices"></a>Publishing Web Services with Axis</h2>
> Let's say we have a simple class like the following:
> <pre class="example">public class Calculator {
> - public int add(int i1, int i2)
> - {
> - return i1 + i2;
> - }
> -
> - public int subtract(int i1, int i2)
> - {
> - return i1 - i2;
> - }
> + public int add(int i1, int i2)
> + {
> + return i1 + i2;
> + }
> +
> + public int subtract(int i1, int i2)
> + {
> + return i1 - i2;
> + }
> }</pre>
> (You'll find this very class in <a href="../samples/userguide/example2/Calculator.java">samples/userguide/example2/Calculator.java</a>.)
> <p>How do we go about making this class available via SOAP? There are a
> @@ -365,11 +370,11 @@
> thing to deploy is a Web Service, so let's start by taking a look at a
> deployment descriptor for a basic service (this file is <a href="../samples/userguide/example3/deploy.wsdd">samples/userguide/example3/deploy.wsdd</a>):</p>
> <pre class="example"><deployment xmlns="http://xml.apache.org/axis/wsdd/"
> - xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> - <service name="MyService" provider="java:RPC">
> - <parameter name="className" value="samples.userguide.example3.MyService"/>
> - <parameter name="allowedMethods" value="*"/>
> - </service>
> + xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> + <service name="MyService" provider="java:RPC">
> + <parameter name="className" value="samples.userguide.example3.MyService"/>
> + <parameter name="allowedMethods" value="*"/>
> + </service>
> </deployment></pre>
> Pretty simple, really - the outermost element tells the engine that this is a
> WSDD deployment, and defines the "java" namespace. Then the service element actually
> @@ -418,9 +423,9 @@
> You typed : test me!
> %</pre>
> If you want to prove to yourself that the deployment really worked, try
> -undeploying the service and calling it again. There's an "undeploy.wsdd"
> +undeploying the service and calling it again. There's an "undeploy.wsdd"
> file in the example3/ directory which you can use just as you did the deploy.wsdd
> -file above. Run the AdminClient on that file, then try the service
> +file above. Run the AdminClient on that file, then try the service
> Client again and see what happens.
> <p>You can also use the AdminClient to get a listing of all the deployed
> components in the server:
> @@ -438,21 +443,21 @@
> the Handler itself, and then use the name that you give it in deploying
> a service. Here's a sample deploy.wsdd file (this is example 4 in samples/userguide):
> <pre class="example"><deployment xmlns="http://xml.apache.org/axis/wsdd/"
> - xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> - <!-- define the logging handler configuration -->
> - <handler name="track" type="java:samples.userguide.example4.LogHandler">
> - <parameter name="filename" value="MyService.log"/>
> - </handler>
> -
> - <!-- define the service, using the log handler we just defined -->
> - <service name="LogTestService"<b> </b>provider="java:RPC">
> - <requestFlow>
> - <handler type="track"/>
> - </requestFlow>
> -
> - <parameter name="className" value="samples.userguide.example4.Service"/>
> - <parameter name="allowedMethods" value="*"/>
> - </service>
> + xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> + <!-- define the logging handler configuration -->
> + <handler name="track" type="java:samples.userguide.example4.LogHandler">
> + <parameter name="filename" value="MyService.log"/>
> + </handler>
> +
> + <!-- define the service, using the log handler we just defined -->
> + <service name="LogTestService"<b> </b>provider="java:RPC">
> + <requestFlow>
> + <handler type="track"/>
> + </requestFlow>
> +
> + <parameter name="className" value="samples.userguide.example4.Service"/>
> + <parameter name="allowedMethods" value="*"/>
> + </service>
> </deployment></pre>
> <p>The first section defines a Handler called "track" that is implemented
> by the class samples.userguide.example4.LogHandler. We give this Handler
> @@ -472,9 +477,9 @@
> webapp's WEB-INF directory. In it, you'll see a deployment for the AdminService.
> Add an option as follows:
> <pre class="xml"><service name="AdminService" provider="java:MSG">
> - <parameter name="className" value="org.apache.axis.util.Admin"/>
> - <parameter name="allowedMethods" value="*"/>
> - <b><parameter name="enableRemoteAdmin" value="true"/>
> + <parameter name="className" value="org.apache.axis.util.Admin"/>
> + <parameter name="allowedMethods" value="*"/>
> + <b><parameter name="enableRemoteAdmin" value="true"/>
> </b></service></pre>
> <p><b>WARNING: enabling remote administration may give unauthorized parties
> access to your machine. If you do this, please make sure to add security
> @@ -511,7 +516,7 @@
> <p>A good place to start in describing the difference between document and wrapped
> services is with a sample SOAP message containing a purchase order:</p>
> <pre class="xml"><soap:Envelope xmlns="http://xml.apache.org/axis/wsdd/"
> - xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> + xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
> <soap:Body>
> <myNS:PurchaseOrder xmlns:myNS="http://commerce.com/PO">
> <item>SK001</item>
> @@ -701,17 +706,6 @@
>
> <h3>What Axis can send via SOAP with restricted Interoperability</h3>
>
> -<h5>Unsigned data</h5>
> -
> -You cannot consume or generate services that use unsigned datatypes with
> -pure JAX-RPC, because there are no unsigned dataypes in Java.
> -<p>
> -Axis does have support for the unsigned types, so you can consume services
> -written in C++, C# and the like, and re-implement interfaces designed for
> -those languages. Be very wary about exporting unsigned datatypes, however, as to
> -do so will stop Java clients that do not use Axis or another SOAP client library
> -with unsigned support from using them. The current JAX-RPC specification does
> -not address this issue.
>
> <h5>Java Collections</h5>
>
> @@ -739,7 +733,7 @@
> serialization support built in to Axis.
>
>
> -Remote References
> +<h5>Remote References</h5>
>
> Remote references are neither part of the SOAP specification, nor the JAX-RPC
> specification. You cannot return some object reference and expect the
> @@ -755,7 +749,7 @@
> of get/set accessors. All you need to do is tell Axis which Java classes
> map to which XML Schema types. Configuring a bean mapping looks like this:
> <pre class="xml"><beanMapping qname="ns:local" xmlns:ns="someNamespace"
> - languageSpecificType="java:my.java.thingy"/></pre>
> + languageSpecificType="java:my.java.thingy"/></pre>
> The <beanMapping> tag maps a Java class (presumably a bean) to an XML
> QName. You'll note that it has two important attributes, <b>qname</b> and
> <b>languageSpecificType</b>.
> @@ -804,10 +798,10 @@
> Axis which types they should be used for. You do this with a typeMapping
> tag in WSDD, which looks like this:
> <pre class="xml"><typeMapping qname="ns:local" xmlns:ns="someNamespace"
> - languageSpecificType="java:my.java.thingy"
> - serializer="my.java.Serializer"
> - deserializer="my.java.DeserializerFactory"
> - encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/></pre>
> + languageSpecificType="java:my.java.thingy"
> + serializer="my.java.Serializer"
> + deserializer="my.java.DeserializerFactory"
> + encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/></pre>
> <p>This looks a lot like the <beanMapping> tag we saw earlier, but there
> are three extra attributes. One, <b>serializer</b>, is the Java class name
> of the Serializer <i>factory</i> which gets the serializer to
> @@ -863,8 +857,8 @@
> able to use it to access your service with toolkits like .NET, SOAP::Lite,
> or any other software which supports using WSDL.
> <p>You can also generate WSDL files from existing Java classes (see <a href="#Java2WSDL: Building WSDL from Java">Java2WSDL:
> -Building WSDL from Java</a> ).
> -<br>
> +Building WSDL from Java</a> ).
> +<br>
> <h3><a NAME="WSDL2Java: Building stubs, skeletons, and data"></a>WSDL2Java:
> Building stubs, skeletons, and data types from WSDL</h3>
>
> @@ -875,15 +869,15 @@
> % java org.apache.axis.wsdl.WSDL2Java (WSDL-file-URL)
> </pre>
>
> -<p>This will generate only those bindings necessary for the client.
> +<p>This will generate only those bindings necessary for the client.
> Axis follows the JAX-RPC specification when generating Java client bindings
> -from WSDL. For this discussion, assume we executed the following:</p>
> +from WSDL. For this discussion, assume we executed the following:</p>
> <pre class="example">
> % cd samples/addr
> % java org.apache.axis.wsdl.WSDL2Java AddressBook.wsdl
> </pre>
> -<p>The generated files will reside in the directory "AddressFetcher2".
> -They are put here because that is the target namespace from the WSDL and namespaces map to Java packages.
> +<p>The generated files will reside in the directory "AddressFetcher2".
> +They are put here because that is the target namespace from the WSDL and namespaces map to Java packages.
> Namespaces will be discussed in detail later.</p>
> <table BORDER COLS=2 WIDTH="100%" >
> <tr>
> @@ -933,31 +927,31 @@
> action with an Ant based build process.
>
> <h4>Types</h4>
> -<p>The Java class generated from a WSDL type will be named from the WSDL type.
> -This class will typically, though not always, be a bean. For example,
> +<p>The Java class generated from a WSDL type will be named from the WSDL type.
> +This class will typically, though not always, be a bean. For example,
> given the WSDL (the WSDL used throughout the WSDL2Java discussion is from
> the <a href="../samples/addr/AddressBook.wsdl">Address Book sample</a>):</p>
> <pre class="example">
> <xsd:complexType name="phone">
> - <xsd:all>
> - <xsd:element name="areaCode" type="xsd:int"/>
> - <xsd:element name="exchange" type="xsd:string"/>
> - <xsd:element name="number" type="xsd:string"/>
> - </xsd:all>
> + <xsd:all>
> + <xsd:element name="areaCode" type="xsd:int"/>
> + <xsd:element name="exchange" type="xsd:string"/>
> + <xsd:element name="number" type="xsd:string"/>
> + </xsd:all>
> </xsd:complexType>
> </pre>
> <p>WSDL2Java will generate:
> <pre class="example">
> public class Phone implements java.io.Serializable {
> - public Phone() {...}
> - public int getAreaCode() {...}
> - public void setAreaCode(int areaCode) {...}
> - public java.lang.String getExchange() {...}
> - public void setExchange(java.lang.String exchange) {...}
> - public java.lang.String getNumber() {...}
> - public void setNumber(java.lang.String number) {...}
> - public boolean equals(Object obj) {...}
> - public int hashCode() {...}
> + public Phone() {...}
> + public int getAreaCode() {...}
> + public void setAreaCode(int areaCode) {...}
> + public java.lang.String getExchange() {...}
> + public void setExchange(java.lang.String exchange) {...}
> + public java.lang.String getNumber() {...}
> + public void setNumber(java.lang.String number) {...}
> + public boolean equals(Object obj) {...}
> + public int hashCode() {...}
> }
> </pre>
> <h4>Mapping XML to Java types : Metadata</h4>
> @@ -982,10 +976,10 @@
> class in the Axis source, or generate your own bean from XML which uses attributes
> or names which would be illegal in Java.</p>
> <h4>Holders</h4>
> -<p>This type may be used as an inout or out parameter. Java does not
> -have the concept of inout/out parameters. In order to achieve this
> -behavior, JAX-RPC specifies the use of holder classes. A holder class
> -is simply a class that contains an instance of its type. For example,
> +<p>This type may be used as an inout or out parameter. Java does not
> +have the concept of inout/out parameters. In order to achieve this
> +behavior, JAX-RPC specifies the use of holder classes. A holder class
> +is simply a class that contains an instance of its type. For example,
> the holder for the Phone class would be:</p>
> <pre class="example">
> package samples.addr.holders;
> @@ -1007,18 +1001,18 @@
> <p>The holder classes for the primitive types can be found in javax.xml.rpc.holders.</p>
> <h4>PortTypes</h4>
> <p>The Service Definition Interface (SDI) is the interface that's derived
> -from a WSDL's portType. This is the interface you use to access the
> -operations on the service. For example, given the WSDL:</p>
> +from a WSDL's portType. This is the interface you use to access the
> +operations on the service. For example, given the WSDL:</p>
> <pre class="example">
> <message name="empty">
> <message name="AddEntryRequest">
> - <part name="name" type="xsd:string"/>
> - <part name="address" type="typens:address"/>
> + <part name="name" type="xsd:string"/>
> + <part name="address" type="typens:address"/>
> </message>
> <portType name="AddressBook">
> - <operation name="addEntry">
> - <input message="tns:AddEntryRequest"/>
> - <output message="tns:empty"/>
> + <operation name="addEntry">
> + <input message="tns:AddEntryRequest"/>
> + <output message="tns:empty"/>
> </operation>
> </portType>
> </pre>
> @@ -1054,12 +1048,13 @@
> document/literal changes what the interface looks like, and we could
> have more than one binding referring to a single portType, we have to
> create more than one interface, and each interface must have a unique name.
> -<br>
> +
> <h4>
> Bindings</h4>
> -A Stub class implements the SDI. Its name is the binding name with
> -the suffix "Stub". It contains the code which turns the method invocations
> -into SOAP calls using the Axis Service and Call objects. It stands
> +
> +A Stub class implements the SDI. Its name is the binding name with
> +the suffix "Stub". It contains the code which turns the method invocations
> +into SOAP calls using the Axis Service and Call objects. It stands
> in as a <b>proxy</b> (another term for the same idea) for the remote service,
> letting you call it exactly as if it were a local object. In other words,
> you don't need to deal with the endpoint URL, namespace, or parameter arrays
> @@ -1067,49 +1062,49 @@
> The stub hides all that work for you.
> <p>Given the following WSDL snippet:
> <pre class="example"><binding name="AddressBookSOAPBinding" type="tns:AddressBook">
> - ...
> + ...
> </binding></pre>
> <p>WSDL2Java will generate:
> <pre class="example">public class AddressBookSOAPBindingStub extends org.apache.axis.client.Stub
> implements AddressBook {
> - public AddressBookSOAPBindingStub() throws org.apache.axis.AxisFault
> + public AddressBookSOAPBindingStub() throws org.apache.axis.AxisFault
> {...}
>
> - public AddressBookSOAPBindingStub(URL endpointURL,
> + public AddressBookSOAPBindingStub(URL endpointURL,
> javax.xml.rpc.Service service)
> throws org.apache.axis.AxisFault
> {...}
> -<br> public AddressBookSOAPBindingStub(javax.xml.rpc.Service service)
> +<br> public AddressBookSOAPBindingStub(javax.xml.rpc.Service service)
> throws org.apache.axis.AxisFault
> {...}
> -<br> public void addEntry(String name, Address address) throws RemoteException
> +<br> public void addEntry(String name, Address address) throws RemoteException
> {...}<br>}</pre>
> <h4>
> Services</h4>
> -Normally, a client program would not instantiate a stub directly.
> +Normally, a client program would not instantiate a stub directly.
> It would instead instantiate a service locator and call a get method which
> -returns a stub. This locator is derived from the service clause in
> -the WSDL. WSDL2Java generates two objects from a service clause.
> +returns a stub. This locator is derived from the service clause in
> +the WSDL. WSDL2Java generates two objects from a service clause.
> For example, given the WSDL:
> <pre class="example"><service name="AddressBookService">
> - <port name="AddressBook" binding="tns:AddressBookSOAPBinding">
> - <soap:address location="http://localhost:8080/axis/services/AddressBook"/>
> - </port>
> + <port name="AddressBook" binding="tns:AddressBookSOAPBinding">
> + <soap:address location="http://localhost:8080/axis/services/AddressBook"/>
> + </port>
> </service></pre>
> <p>WSDL2Java will generate the service interface:
> <pre class="example">public interface AddressBookService extends javax.xml.rpc.Service {
> - public String getAddressBookAddress();
> -<br> public AddressBook getAddressBook() throws javax.xml.rpc.ServiceException;
> -<br> public AddressBook getAddressBook(URL portAddress) throws javax.xml.rpc.ServiceException;
> + public String getAddressBookAddress();
> +<br> public AddressBook getAddressBook() throws javax.xml.rpc.ServiceException;
> +<br> public AddressBook getAddressBook(URL portAddress) throws javax.xml.rpc.ServiceException;
> }</pre>
> <p>WSDL2Java will also generate the locator which implements this interface:
> <pre class="example">public class AddressBookServiceLocator extends org.apache.axis.client.Service
> implements AddressBookService {
> - ...
> + ...
> }</pre>
> <p>The service interface defines a get method for each port listed in the
> service element of the WSDL. The locator is the implementation of this
> -service interface. It implements these get methods. It serves as
> +service interface. It implements these get methods. It serves as
> a locator for obtaining Stub instances. The Service class will by default
> make a Stub which points to the endpoint URL described in the WSDL file,
> but you may also specify a different URL when you ask for the PortType.
> @@ -1117,30 +1112,30 @@
>
> <pre class="example">public class Tester
> {
> - public static void main(String [] args) throws Exception {
> - // Make a service
> - AddressBookService service = new AddressBookServiceLocator();
> -
> - // Now use the service to get a stub which implements the SDI.
> - AddressBook port = service.getAddressBook();
> -
> - // Make the actual call
> - Address address = new Address(...);
> - port.addEntry("Russell Butek", address);
> - }<br>}</pre>
> + public static void main(String [] args) throws Exception {
> + // Make a service
> + AddressBookService service = new AddressBookServiceLocator();
> +
> + // Now use the service to get a stub which implements the SDI.
> + AddressBook port = service.getAddressBook();
> +
> + // Make the actual call
> + Address address = new Address(...);
> + port.addEntry("Russell Butek", address);
> + }<br>}</pre>
>
> <h4>
> Server-side bindings</h4>
> Just as a stub is the client side of a Web Service represented in Java,
> -a <b>skeleton</b> is a Java framework for the server side. To make
> +a <b>skeleton</b> is a Java framework for the server side. To make
> skeleton classes, you just specify the "--server-side --skeletonDeploy true" options
> to WSDL2Java.
> For instance, using the AddressBook.wsdl as we had above:
> <pre class="example">% java org.apache.axis.wsdl.WSDL2Java --server-side --skeletonDeploy true AddressBook.wsdl</pre>
> <p>You will see that WSDL2Java generates all the classes that were generated
> before for the client, but it generates a few new files:
> -<br>
> -<br>
> +<br>
> +<br>
> <table BORDER COLS=2 WIDTH="100%" >
> <tr>
> <td><b>WSDL clause</b></td>
> @@ -1181,8 +1176,8 @@
> Here is how you run WSDL2Java to deploy directly to the implementation:
> <pre class="example">% java org.apache.axis.wsdl.WSDL2Java --server-side AddressBook.wsdl</pre>
> <p>And here are the server side files that are generated:
> -<br>
> -<br>
> +<br>
> +<br>
> <table BORDER COLS=2 WIDTH="100%" >
> <tr>
> <td><b>WSDL clause</b></td>
> @@ -1214,32 +1209,32 @@
> <h5>
> Skeleton Description (for Skeleton Deployment) </h5>
> The skeleton class is the class that sits between the Axis engine and the
> -actual service implementation. Its name is the binding name with
> -suffix "Skeleton". For example, for the AddressBook binding, WSDL2Java
> +actual service implementation. Its name is the binding name with
> +suffix "Skeleton". For example, for the AddressBook binding, WSDL2Java
> will generate:
> <pre class="example">public class AddressBookSOAPBindingSkeleton implements AddressBook,
> - org.apache.axis.wsdl.Skeleton {
> - private AddressBook impl;
> -
> - public AddressBookSOAPBindingSkeleton() {
> - this.impl = new AddressBookSOAPBindingImpl();
> - }
> -
> - public AddressBookSOAPBindingSkeleton(AddressBook impl) {
> - this.impl = impl;
> - }
> -
> - public void addEntry(java.lang.String name, Address address)
> + org.apache.axis.wsdl.Skeleton {
> + private AddressBook impl;
> +
> + public AddressBookSOAPBindingSkeleton() {
> + this.impl = new AddressBookSOAPBindingImpl();
> + }
> +
> + public AddressBookSOAPBindingSkeleton(AddressBook impl) {
> + this.impl = impl;
> + }
> +
> + public void addEntry(java.lang.String name, Address address)
> throws java.rmi.RemoteException
> - {
> - impl.addEntry(name, address);
> - }
> + {
> + impl.addEntry(name, address);
> + }
> }</pre>
> -<p>(The real skeleton is actually much richer. For brevity we just show
> +<p>(The real skeleton is actually much richer. For brevity we just show
> you the basic skeleton.)
> -<p>The skeleton contains an implementation of the AddressBook service.
> +<p>The skeleton contains an implementation of the AddressBook service.
> This implementation is either passed into the skeleton on construction,
> -or an instance of the generated implementation is created. When the
> +or an instance of the generated implementation is created. When the
> Axis engine calls the skeleton's addEntry method, it simply delegates the
> invocation to the real implementation's addEntry method.
> <h5>
> @@ -1247,15 +1242,15 @@
> <p>WSDL2Java also generates an implementation template
> from the binding:
> <pre class="example">public class AddressBookSOAPBindingImpl implements AddressBook {
> -<br> public void addEntry(String name, Address address)
> +<br> public void addEntry(String name, Address address)
> throws java.rmi.RemoteException {
> - }
> + }
> }</pre>
> <p>This template could actually be used as a test implementation but, as
> -you can see, it doesn't do anything. It is intended that the service
> +you can see, it doesn't do anything. It is intended that the service
> writer fill out the implementation from this template.</p>
> <p>When WSDL2Java is asked to generate the implementation template (via the --server-side
> - flag), it will ONLY generate it if it does not already exist. If this
> + flag), it will ONLY generate it if it does not already exist. If this
> implementation already exists, it will not be overwritten.</p>
> <h4>Services</h4>
> <p>The tool also builds you a "deploy.wsdd" and an "undeploy.wsdd" for each
> @@ -1264,20 +1259,23 @@
> compiled the code, and made the classes available to your Axis engine.</p>
> <h3><a NAME="Java2WSDL: Building WSDL from Java"></a>Java2WSDL: Building WSDL
> from Java</h3>
> -The Java2WSDL and WSDL2Java emitters make it easy to develop a new web service. The following sections describe the steps in building a web service from a Java interface.
> -<br>
> +The Java2WSDL and WSDL2Java emitters make it easy to develop a new web service.
> +The following sections describe the steps in building a web service from a Java interface.
> +<br>
> <h4>
> Step 1: Provide a Java interface or class</h4>
> Write and compile a Java interface (or class) that describes the web service
> -interface. Here is an example interface that describes a web services
> -that can be used to set/query the price of widgets (<a href="../samples/userguide/example6/WidgetPrice.java">samples/userguide/example6/WidgetPrice.java</a>):
> +interface. Here is an example interface that describes a web services
> +that can be used to set/query the price of widgets
> +(<a href="../samples/userguide/example6/WidgetPrice.java">samples/userguide/example6/WidgetPrice.java</a>):
> <pre class="example">package samples.userguide.example6;
> -<br>/**
> - * Interface describing a web service to set and get Widget prices.
> - **/
> +
> +/**
> + * Interface describing a web service to set and get Widget prices.
> + **/
> public interface WidgetPrice {
> - public void setWidgetPrice(String widgetName, String price);
> - public String getWidgetPrice(String widgetName);
> + public void setWidgetPrice(String widgetName, String price);
> + public String getWidgetPrice(String widgetName);
> }</pre>
> <p><b>Note: </b>If you compile your class with debug information, Java2WSDL
> will use the debug information to obtain the method parameter names.
> @@ -1285,8 +1283,10 @@
> Step 2: Create WSDL using Java2WSDL</h4>
> Use the Java2WSDL tool to create a WSDL file from the interface above.
> <p>Here is an example invocation that produces the wsdl file (<tt>wp.wsdl</tt>)
> -from the interface described in the previous section:
> -<pre class="example">% java org.apache.axis.wsdl.Java2WSDL -o wp.wsdl -l"http://localhost:8080/axis/services/WidgetPrice" -n "urn:Example6" -p"samples.userguide.example6" "urn:Example6" samples.userguide.example6.WidgetPrice</pre>
> +from the interface described in the previous section (entered all on one line):
> +<pre class="example">% java org.apache.axis.wsdl.Java2WSDL -o wp.wsdl
> + -l"http://localhost:8080/axis/services/WidgetPrice" -n "urn:Example6"
> + -p"samples.userguide.example6" "urn:Example6" samples.userguide.example6.WidgetPrice</pre>
> <p>Where:
> <ul>
> <li>
> @@ -1299,7 +1299,7 @@
> -n is the target <b><i>namespace</i></b> of the WSDL file</li>
>
> <li>
> --p indicates a mapping from the <b><i>package to a namespace</i></b>.
> +-p indicates a mapping from the <b><i>package to a namespace</i></b>.
> There may be multiple mappings.</li>
>
> <li>
> @@ -1307,9 +1307,9 @@
> </ul>
> The output WSDL document will contain the appropriate WSDL types, messages,
> portType, bindings and service descriptions to support a SOAP rpc, encoding
> -web service. If your specified interface methods reference other
> +web service. If your specified interface methods reference other
> classes, the Java2WSDL tool will generate the appropriate xml types to
> -represent the classes and any nested/inherited types. The tool supports
> +represent the classes and any nested/inherited types. The tool supports
> JAX-RPC complex types (bean classes), extension classes, enumeration classes,
> arrays and Holder classes.
> <p>The Java2WSDL tool has many additional options which are detailed in the <a href="reference.html#Java2WSDL">reference
> @@ -1320,18 +1320,19 @@
>
> <h4>
> Step 3: Create Bindings using WSDL2Java</h4>
> +
> Use the generated WSDL file to build the appropriate client/server bindings
> for the web service (see <a href="#WSDL2Java: Building stubs, skeletons, and data">WSDL2Java</a>):
> -<pre class="example">% java org.apache.axis.wsdl.WSDL2Java -o . -d Session -s -S true -Nurn:Example6 samples.userguide.example6 wp.wsdl</pre>
> +<pre class="example">% java org.apache.axis.wsdl.WSDL2Java -o . -d Session -s -S true -Nurn:Example6 samples.userguide.example6 wp.wsdl</pre>
> <p>This will generate the following files:
> <ul>
> <li> <b><tt>WidgetPriceSoapBindingImpl.java</tt></b> : Java file containing
> the default server implementation of the WidgetPrice web service.</li>
> <br>
> You will need to modify the *SoapBindingImpl file to add your implementation
> - (see <a href="../samples/userguide/example6/WidgetPriceSoapBindingImpl.java">../samples/userguide/example6/WidgetPriceSoapBindingImpl.java</a>
> + (see <a href="../samples/userguide/example6/WidgetPriceSoapBindingImpl.java">../samples/userguide/example6/WidgetPriceSoapBindingImpl.java</a>
> ).
> - <li> <b><tt>WidgetPrice.java</tt></b>: New interface file that contains
> + <li> <b><tt>WidgetPrice.java</tt></b>: New interface file that contains
> the appropriate <b><tt>java.rmi.Remote</tt></b> usages.</li>
> <li> <b><tt>WidgetPriceService.java</tt></b>: Java file containing the client
> side service interface.</li>
> @@ -1341,14 +1342,15 @@
> <li> <b><tt>WidgetPriceSoapBindingStub.java</tt></b>: Client side stub.</li>
> <li> <b><tt>deploy.wsdd</tt></b>: Deployment descriptor</li>
> <li> <b><tt>undeploy.wsdd</tt></b>: Undeployment descriptor</li>
> - <li> (data types): Java files will be produced for all of the other types
> - and holders necessary for the web service. There are no additional files
> + <li> (data types): Java files will be produced for all of the other types
> + and holders necessary for the web service. There are no additional files
> for the WidgetPrice web service.</li>
> </ul>
> <p>Now you have all of the necessary files to build your client/server side code
> and deploy the web service!</p>
> <h2>
> <a NAME="published interfaces"></a>Published Axis Interfaces</h2>
> +
> Although you may use any of the interfaces and classes present in Axis, you need to
> be aware that some are more stable than others since there is a continuing
> need to refactor Axis to maintain and improve its modularity.
>
>
>
>