Those wsdl elements look OK to me.. But really all you've defined is the
<types> schema and not the entire WSDL... As a fellow N00b (about 3
weeks ago I was in "what's this axis thing" stage) I feel the need to
warn you that lots of the delicate chicanery that is axis wrasslin'
tends to be the details of the WSDL being affected in strange ways.
Sometimes so much gets lost in the WSDL's service <--> binding <-->
Soap Port <--> Message <--> Types mappings that you might think you have
everything dandy... Get everything implemented in the Impl class, just
to find out that there is an extra namespace mapping that upsets
everyone's doc-style WSDL parser.
I have gone through about 15 instantiations of my "I'm creating a simple
customer information database backed webservice that needs to be DOC
style so we can test our BPM product that connects to webservices"
'simple' webservice just trying to get MS InfoPath and Suns
JavaStudioCreator to connect to them and pull back data without getting
namespace errors in the return wrapper part.
I think the only time I ever got one to fire properly is when I started
from a WSDL that java2WSDL created for me. Then tweaked it with the help
of several examples of working webservices.
Thus, I think the best next step at this point is to go ahead and get
your WSDL finished and validated (I've found SOA editor by cape clear
has one of the best validators over XMLSpy (it showed you more than one
problem at a time, and caught things that XMLSpy missed), but XMLSpy is
much prettier). After everything maps out properly... use WSDL2Java to
make the java files, get them compiled with the Impl stub wrapper
returning empty classes (since each complex type becomes a class) Then:
use something that connects to webservices to link up to your Axis WSDL
(MS InfoPath is OK for testing .NET parsers... But Suns Java Studio
Creator has a nice "test this method" UI as well) and make sure you get
empty returns. Then go about writing the data behind the Impl class.
I'm using axis 1.2: and the issue I've found is that sometimes WSDL2Java
liked to create the data types with namespaces next to the names in the
Qnames.
....typeDesc.setXmlType(new
javax.xml.namespace.QName("http://www.m1global.com/ws";, "AccountType"));
org.apache.axis.description.ElementDesc elemField = new
org.apache.axis.description.ElementDesc();
elemField.setFieldName("account_ID");
elemField.setXmlName(new
javax.xml.namespace.QName("http://www.m1global.com/ws";, "account_ID"));
elemField.setXmlType(new
javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema";, "int"));
typeDesc.addFieldDesc(elemField);
elemField = new org.apache.axis.description.ElementDesc();
elemField.setFieldName("cust_ID");
elemField.setXmlName(new
javax.xml.namespace.QName("http://www.m1global.com/ws";, "cust_ID"));
elemField.setXmlType(new
javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema";, "int"));
typeDesc.addFieldDesc(elemField); ...
And it needs to be more like
... typeDesc.setXmlType(new
javax.xml.namespace.QName("http://www.m1global.com/ws";, "AccountType"));
org.apache.axis.description.ElementDesc elemField = new
org.apache.axis.description.ElementDesc();
elemField.setFieldName("account_ID");
elemField.setXmlName(new javax.xml.namespace.QName("",
"account_ID"));
elemField.setXmlType(new
javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema";, "int"));
typeDesc.addFieldDesc(elemField);
elemField = new org.apache.axis.description.ElementDesc();
elemField.setFieldName("cust_ID");
elemField.setXmlName(new javax.xml.namespace.QName("",
"cust_ID"));
elemField.setXmlType(new
javax.xml.namespace.QName("http://www.w3.org/2001/XMLSchema";, "int"));
typeDesc.addFieldDesc(elemField); ...
I'm still not sure what I mis-tweaked in the WSDL to make it think that
those extra namespaces were necessary... But if they are present, they
will give you "got {http://www.m1global.com/ws}accountReturn expecting
{}accountReturn" type errors
I'm glad I found that I could just remove the namespaces from the
classes themselves, rather than having to tweak the java generating WSDL
and trying to guess at what WSDL2Java was expecting. SoapScope and such
help too because they let you see what is awry about the messages being
returned sometimes.
Good luck getting everything to work out, Hope this helps.
-----Original Message-----
From: Larry Meadors [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 23, 2004 12:21 AM
To: [EMAIL PROTECTED]
Subject: Re: n00b seeking advice
Dang, better responses than I expected! Great!
First off, I have to confess that I *have* hacked stuff together using
the JWS mapping, but it was a very short lived experiment because..well,
it sucked.
OK, so to get back on to the right path, what I am hearing consistently
is "Do not start with Java and generate WSDL from it." The reference
Bill sent went even further by saying to define the types using xsd
files. So I guess that is as good a place as any to start - in spite of
the fact that there is not a chance in heck I will be using Castor for
this! ;-)
Anyway, the service is intended to be implemented by companies that sell
books, movies and CDs. It would provide an interface for their customers
to use to look up products based on unique identifiers such as ISBN or
UPC code. Eventually, it will be expanded to allow more advanced
searches like Author and/or title fragment (eg., author = 'Stephen King'
and title like '%hospital%'). At that point, it will have to provide
methods that return arrays (per Anne's advice). For now, I will keep it
simple - single parameter searches that return 0-1 items. The data
returned would be a product that for simplicity will include these
properties: title (String), author (String), ISBN (String), UPC
(String), and listPrice (double).
So that translates into an xsd definition like this:
<xsd:element name="product">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="title" type="xsd:string"/>
<xsd:element name="author" type="xsd:string"/>
<xsd:element name="isbn" type="xsd:string"/>
<xsd:element name="upc" type="xsd:string"/>
<xsd:element name="listPrice" type="xsd:float"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Next, I need to define the methods available. Again, keeping it simple:
<xsd:element name="getProductByUpc">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="upc" type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="getProductByUpcResponse">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="product" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
Confession time again - I am using the stuff from the page Bill included
in his email, so if you see me doing something silly, please correct me.
:-)
If I am reading this correctly, I have defined what in Java will end up
being a bean, a method, and a return type for that method that will wrap
the bean.
Sooo, how am I doing so far? Tomorrow, unless there are issues with what
I have so far, I will dive into the WSDL.
I am way too tired for that now. :-/
Larry
