SstWSDeploymentManager>>strategyForUrl: Method below expects URL to have a .wsdl extension. I changed to follow to work with my URL http://dev:1080/casservice/casservice?wsdl=======================================strategyForUrl: aUrl

. . . only one argument is specified, parameters. To be able to debug it thoroughly, create a test case and zip up the wsdl and schema files, and other xml files needed and attach them to a message here, include the ST code also.

Thanks for the response. Before we go further on the debug route, can you tell whether there is a VA Smalltalk version which can talk to WSDL version 2.0 or WSDL generated by WebLogic 10.3? We are currently using VA Smalltalk 7.0.

First, this could be a red herring in that, we do not know what the issue is. The only way to know is to actually see the WSDL/schema files and from that, determine the problem.

On the issue of WSDL 2.0, there is no ST 7.0 patch I'm aware of that one can apply to their image and make it WSDL 2.0 compliant.

The WSDL problems I've seen have, to date, had very little to do with whether the file was WSDL 1.2 or 2.0, they had more to do with the quality of the tool and in the case of high end tools, what was being fed into them. Processing takes place at many levels. A WSDL file that is syntactically correct at the XML level does not mean it is a valid WSDL file. The same applies to schema files. Schema files can be syntactically correct at the XML level but still be an invalid schema file.

The reason for this is processing at the WSDL/schema level looks at attributes in tags and for certain types of tags, certain attributes need to be present. If a certain attribute is used, other types off attributes may not be allowed. Namespaces also determine the validity of the files.

As you can guess, one can take three high end WSDL/schma tools and run a set of files through them. Two tools may report the WSDL and schema as valid whereas the third tool finds problems. I've done this with WSDL that customers have sent us and found this situation many times.

Given that, we have been handliing problems on an issue by issue basis, first determining the problem and looking for a solution. The solution part is a little easier than one might think because the XML/schema/WSDL framework in ST allows for pluggable handlers.

On the issue of WSDL 2.0, I'll raise the issue in our meeting next week. The thing to remember is WSDL 2.0, schema specs, etc. are not standards, they are proposals. If you look here:http://www.w3.org/TR/wsdl20/. . . it says:

This is the W3C Recommendation . . .

. . . I think this is part of the reason for the wide variation of WSDL/schema files I've seen. Most documents on the W3C website are only proposals. The WSDL 1.2 document on the W3C website says:

This is a W3C Working Draft . . .

. . . for the status of the document. Schema documents have the same status, 'This is a W3C Recommendation . . .'. The following is a quote from the O'Reilly book 'Web Services Essentials' by Ethan Cerami:

Web services are still in their infancy, but they are poised to make great inroads in the world of distributed application development. The most crucial elements to the long-term success of web services, however, will be standardization and the coherency of those standards. Currently, none of the web service technologies described in this book has any official standing with the W3C or the IETF. SOAP and WSDL have both been submitted to the W3C, but have no official recommendation status. XML-RPC has not been submitted to any standards body. UDDI is currently under the purview of an industry consortium and will probably go through several more iterations before being handed over to a standards body.