Error Parsing WSDL - Worklight 6.1 - Backend Discovery Service - soap

Testing the new backend discovery feature in WL6.1 used for a web service (SOAP) connection, we found a wrong import procedures from WSDL parsing. In particular, for each procedure offered by the SOAP server and exposed in the related WSDL the backend discovery service found only one input/output parameter although the procedures are composed of more than one input parameter. The problem seems to be a misinterpretation of the WSDL associated with the SOAP server.
thanks,
Here the WSDL:
https://dl.dropboxusercontent.com/u/15425546/Ws_StoreSurfer.xml

Is seems that WL v6.1 indeed has a problem with muli-parts and showing only one part of the input/output of a procedure.
Tested it with a new version of WL (not yet released) and it seems like the problem has already been addressed (see below). You will therefore get it solved in the next update of your Worklight Studio.
If you are an IBM business partner or customer you can open a PMR and request an intermittent iFix.

Related

Domino client web services and SOAP 1.2

I create a client in Domino to consume a web service that works with SOAP 1.2 and has HTTPBinding.
The client generation tool for Domino Designer Web services an error is displayed when trying to generate reporting that the SOAP accepted version is 1.1.
I decided to create the client with CXF framework through tool wsdl2java. In an agent I used these classes to consume the web service, however the below error was displayed. I think it's because of the SOAP version, but I'm not sure.
com.sun.xml.internal.ws.protocol.soap.MUTube getMisUnderstoodHeaders
INFO: Element not understood={http://www.w3.org/2005/08/addressing}Action
Also generated a jar of classes generated by wsdltojava and imported to another agent, but the error below is displayed.
java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version; class=, offset=6
The question is, no way consume a web service with SOAP 1.2 in Domino only supports up to version 1.1?
Thanks a lot!
I don't believe that Domino's web service consumer supports SOAP 1.2 at this time. You might be able to do what you need with an agent though - here's one way: How can I call a SOAP 1.2 Web service from a LotusScript agent?
In fact there is no way to natively consume a web service with soap version 1.2. There are already several requests from IBM to upgrade the SOAP version. What I did, was to develop a new layer through a new web service with the version SOAP 1.1, which internally calls the web service with the SOAP version 1.2;

Websphere 8.5 JAX-WS WSDL redirect

I got a SOAP web service with code first approach running with the built in JAX-WS implementation in Websphere 6.1.
The service was migrated from Websphere version 6.1 to version 8.5.
Formerly (version 6.1) the WSDL was available directly at the URL
[...]/services/SomeService?wsdl
Since migrating to version 8.5 the WSDL is still available via aforesaid URL, but a redirect is being made to
[...]/services/Services_002f_SomeService.wsdl
A client needs to access the WSDL before each request that is being made to the web service and is not getting on with the redirect (i.e. with the [...]?wsdl-URL), so he needs the redirected URL. (This is something I'm having no bearing on, unfortunately... )
Problem is that the '002f' part in the redirected URL is dynamic and might be changed by Websphere. (It did already in our testing environment.)
Does anybody know an option that prevents Websphere from the aforementioned redirect?
I finally found the reason for the weird '002f' characters in the redirect URL.
It is due to the given serviceName services/SomeService
#WebService (targetNamespace="http://example.net/", serviceName="services/SomeService")
\u002f is the '/' character in UTF8
So redirect goes to [...]/services/SomeService/Services_002fSomeService.wsdl and is reasonable.
The info of a possibly changing redirect URL to ...003f..., ...004f..., etc. which I got is obviously wrong.
Though not redirecting would not have caused any troubles at all and I don't know why the new JAX-WS implementation in WAS 8.5 really has to do that, I' coming to terms with just giving the (as I know know) static '002f' WSDL URL to the client.

Soap web service client

We are integrating our software with another company using a webservice. They created a SOAP web service which we now need to test.
I'm trying to write a java program with Eclipse IDE. When creating a web service client, I enter the wsdl:
[https://xxxxxxxxx/xxxxxxx/index.php/gt/property/soap?wsdl]*
but I keep getting a message that states: The service definition is invalid.
Any ideas as to why this would be or any links I could check out would be appreciated. I have searched but haven't found anything that helped me yet.
Thanks!
If you are going for a Java program you could use,
Web service client given WSDL
But if you just want to test the web service, you could always use program like SoapUI

Consume ServiceStack SOAP service from Silverlight application

For the past few days I have been looking at ServiceStack as a replacement for our WCF-based middleware (that exposes SOAP services).
My two main requirements :
Can be hosted outside of IIS (no problem using AppHostHttpListenerBase)
ServiceStack SOAP interfaces can be consumed from a Silverlight application.
Hosting from a console application works smoothly, but adding a service reference in my Silverlight client gives the following warning:
Custom tool warning: Endpoint 'WSHttpBinding_IOneWay' at address 'http://localhost:8080/soap12' is not compatible with Silverlight 5. Skipping...
Which makes sense, but I cannot seem to find a way to change the binding to e.g. basicHttpBinding.
Is this possible? I tried various ways to tackle this from app.config but no luck so far.
Much obliged in advance,
Robert van Drunen

weblogic jax-ws multithreading

I am using Eclipse + Oracle Enterprise Pack to write some jax-ws based service. It works fine in my development mode (composed WSDL, generated Weblogic web service stub code, completed the detail, and tested code from client), one by one. But when I moved these services into a public testing server (running WL 12c (12.1.1) the web service handler looks like is single threaded. This does not make sense to me, but from my app log, one service was running and then all other requests had to wait until the first one completed its task.
What had I missed in my stub code or configuration setting (I just used default server setting)? Any suggestion is appreciated.
Alan