Peter White wrote:
Those wsdl elements look OK to me.. But really all you've defined is theMy experience has been that there are certainly some gotcha but the vast majority of the remaining WSDL is boiler plate. Naturally you've gotta have the right boiler - but once you have one assuming wrapped doc/lit >98% of the remaining WSDL just falls out. If you like I can help out with this...
<types> schema and not the entire WSDL...
Here's what I would do:
1. Start with the data modeling just as Larry did. Get that crisp making sure you understand everything there.
2. Create a WSDL document that contains a schema black in a wsdl:Type section. The schema block imports your XSD from 1.
3. The schema block in the WSDL provides the method wrapper element declarations and references parameters from your other schema document.
IMO this provides a nice layering of abstractions. your WSDL is all about your WS while you XSD is all about your data. You can use your XSD in different scenarios (like code generating various marshaling layers) without introducing WS-isms.
As I said when you get the XSD stuff to a good point lemme know and I can help through the rest.
Oh I'd be remiss if I didn't offer an eval of my company's product: SOAPscope[1]. Its free...for 4 days. :)
Jim Murphy Mindreef, Inc.
[1] - http://www.mindreef.com/
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
