Web service/WSDL calls fail in VA 7

[vasu]

The operations which have multiple arguments are not recognized when using WL 10.3 WSDL . How to make VA generated operations/method with multiple arguments for SOAP 2.0.

WSDL generated by WL(Web Logic) 10.3 is using SOAP 2.0 (Style Documenet/ literal )
WSDLgenerated by WL 8.1.6 is using SOAP 1.x. (Style RCP/encodeing)

WL 8.1.6 - SOAP 1.1
VA parses WSDL and uses "Part" element and replaces "with:"
so smalltalk generates method "createTransaction: with:" from the following elements of the WSDL using (SstWSWsdlStrategy>>createDeploymentDescriptor:)

- <message name="createTransaction">
<part xmlns:partns="java:com.capgroup.afs.webservices" name="aFSBlisRequest" type="partns:AFSBlisRequest" />
<part xmlns:partns="java:com.capgroup.afs.lampdb" name="cASTransaction" type="partns:CASTransaction" />
</message>

WL 10.3 - SOAP 2.0

- <s0:message name="createTransaction">
<s0:part element="s1:createTransaction" name="parameters" />
</s0:message>
Smalltalk only generates createTransaction: one agruments.

1.Following is the smalltalk code works for WL8.1.6 generated WSDL not WL 10.3 what can be changed?

Container
SstWSContainer
containerNamed: 'ClientContainer'
ifNone: [SstWSContainer createContainerNamed: 'ClientContainer']

Creating service
[aService := (self container deploy: self class LampOracleWebServicesWSDL) first]
when: SgmlException
do:[Exception block]
aService isNil ifTrue:[self service: (
((self container managerNamed: ##wsServiceDefinitionsManager) managedObjects)
objectNamed: 'casWs'
inNamespace: 'http://dev:1080/casservice/casservice')]
ifFalse:[self service:aService].

Using default Strategy. Also tried SstWSWsdlStrategy

2. Is the following code VA bug?

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

^ ( self class strategyFor: (aUrl subStrings: $? ) last ) ifNil:[ self indeterminateDeploymentStrategy ]
========================================

Any info will help
Thanks

[tc]

Hello,

With this:

Code: Select all

<message name="createTransaction">
<part xmlns:partns="java:com.capgroup.afs.webservices" name="aFSBlisRequest" type="partns:AFSBlisRequest" />
<part xmlns:partns="java:com.capgroup.afs.lampdb" name="cASTransaction" type="partns:CASTransaction" />
</message>

. . . I can understand a message 'createTransaction:with:' being created because two parameters are specified, aFSBlisRequest and cASTransaction. However, with this fragment:

Code: Select all

<s0:message name="createTransaction">
<s0:part element="s1:createTransaction" name="parameters" />
</s0:message>

. . . 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.

--tc

[vasu]

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.

[tc]

Hello,

Here are two changes from WSDL 1.1 which could cause breakage:

1. PortTypes renamed to interfaces. Support for interface inheritance is achieved by using the extends attribute in the interface element.
2. Ports renamed to endpoints

It would be hard to say without seeing the actual WSDL/schema files.

--tc

[vasu]

Thanks for your response. Are you saying there is no patch for VA Smalltalk 7.0 for WSDL 2.0?

[tc]

Hello,

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.

--tc