This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
Originally posted by jite eghagha: why doesn't my WSDL mention "String " or "String".
In order to be "language independent" you can't tell the other side what the data should be translated to - thats what conventions are for. So any data that the WSDL will be talking about is XML data - nothing else. And XML doesn't support arrays - because it doesn't have to. A sequence of identical elements does the trick.
Originally posted by jite eghagha: How does a client know what parameters to send or recieve? (i cut the WSDL short)
So that file must be available to the client. Then the client will use its own conventions to convert the data found in "tns:getRecordByIdResponse" to something that is suitable in the host language. If the language is Java and the SOAP stack uses the standard XML->Java conversion conventions the data will be converted to a String.
The same principles apply to each of the Request and Reply messages. Each WebMethod will have a matching Request Message. A Reply message is only necessary when the WebMethod has a return value.
#1 If i am returning data that consists of three distinct strings e.g. 1 ProjectNumber, 1 ProjectTile, (multiple)Task Discriptions, (multiple) SubTask Discriptions.
#2 If i am returning a list of similar elements e.g (multiple) ProjectNumbers
List, String , or dataSet ?
Joined: Aug 19, 2005
Originally posted by jite eghagha: What would you recommend
You aren't going to like it - but you did ask for my opinion. Design the web service for what it is - a document exchange.
Identify the documents you need to exchange.
Design the XML documents and capture the design in XML Schema.
Define the endpoint that exchanges the documents.
Create a WSDL based on this design using the XML Schema.
Use a WSDL-to-Java tool to generate the Java Server (and optionally Client) Stubs.
Patterns and Strategies for Building Document-Based Web Services That is really the only way that you can ensure that the Web-service definition is clean and clear (i.e. client-friendly), free of any accidental structures and complexities imposed by the brute-force object-to-(hierarchical) XML conversion. "Web Service by annotation" was a feature that J2EE vendors wanted so that they could feature-compete with .NET. It wasn't added because its a better way of working. It's great for creating a quick "proof of concept", so that you can delay learning the nitty-gritty of web services just a little bit longer. However an interoperable production web service should be designed WSDL-first. Just because "Web Service by annotation" is easier, doesn't make it a best practice.
Some XML-tools will contain features that should make the process of designing the necessary XML Schemas and WSDL a lot easier.
BTW: when using Java-to-WSDL don't return Java-specific data types like List (even a date can cause trouble). There is no guarantee that the other side has an equivalent structure and even a Java-client generated from the WSDL may not use the same type! [ October 12, 2006: Message edited by: Peer Reynders ]
Joined: Oct 06, 2006
now that i've gotten dealing with Objects out of the way, i'll begin learning WSDL to java and core XML for data exchange.