Here is the situation. I have received a WSDL (and included XSD) from someone that is generated by an Apache/Tomcat server (Java). The company i do a project for, prefers .NET so i used wsdl.exe to generate a partial class and created the webservice.
Then I created a .NET client (in this case I am using VB.NET) that has a web reference to the java wsdl. This works fine. Then I change the url using code and make it point to my newly created .NET service but i cannot seem to get it to work.
Doing it the other way round, also doesnt seem to work.
Been fiddling a bit with the namespaces and the service name but can't seem to crack it. Keeps giving me an error about HTTP header unable to find . as a method. This indicates a transport problem.
I really do not want to revert to plan B, being the creation of a Java Webservice and then linking this to the .NET environment. I know this will work since you will never have to change the urls.
Any suggestions ?
So to summarise you have:
SERVER SIDE: java, WSDL: java generated
.NET client -> java server - WORKS .NET client -> .NET server -> FAILS
If thats the case this has not much to do with Java!
But I do know as I aluded to earlier that .NET servers are fussy about the soap action header.
Is there a soapAction in your WSDL?
If so, you need to send that value, but I don't know how to do this in .NET (Google would be your friend here).
If not, check out the comments in this question for how to determine the required soap action header value: stackoverflow.com/questions/2262781/soap-action-wsdl
After a bit of searching through the devine knowledge base (Google), i have managed to get this fixed.
In addition to being very carefull in specifying the portnames (the default ones are not always what is requested so you need to override it) but most importantly, i found that adding
as part of the asm class header solved my problem. Now all I need to do is find out why?
But trust me, it works...
I found the solution here
Related
I have a java listener for working with Docusign connect. Checking out the logs for the connect calls I see the XML as I expected with form fields populated. However, for some reason when the object gets deserialized in the form data section is null. I think it may be related to the below SO question
Why is my WCF web service presenting this object in a different namespace with different field names?
I'm using apache CXF and Maven to download the API objects from
https://www.docusign.net/api/3.0/api.asmx?wsdl
However, the deserialized object looks to be different to the XML sent from connect. Has anyone come across this before or have gotten a listener working in java which can access the forms fields?
Thanks,
Derm
I've never built a Java DocuSign Connect listener application, but I have built one with C#, and I did so by starting with the sample code on GitHub. The Java code is here -- https://github.com/docusign/DocuSign-eSignature-SDK/tree/master/Java/Connect -- if nothing else, perhaps comparing it with what you've got may help you identify the issue(s). Or, you might choose to start over by using the GitHub sample app as the basis for building your listener app -- the C# listener app was plug-and-play, I'd expect the Java version to be the same.
If a SOAP web service is working well via SoapUI (producing the correct SOAP responses), while building a web service client in Java using different APIs/frameworks to call this web service is facing different issues, is it safe to consider this web service stable and the issues are from the consumer side?
I'm asking a generic question in here, I have already asked a detailed one which is probably too long to read. I'm interested in the concept more than my actual implementation, so if you can answer my question without referring to my longer post, please do.
UPDATE:
I have realized that even if the WSDL is WS-I compliant and it's functioning correctly via SoapUI, this is still not enough to conclude that the web service is not broken. As #jtahlborn said, SoapUI is very tolerant to broken web services, and it could easily trick you to believe your web service is working fine, which is what happened in my case.
I'm constructing the SOAP response in the ESB and my issue was that I used a namespace that was defined in the WSDL but not in the schema. SoapUI received the response and showed it to me (with the wrong namespace); this issue could have been avoided if I turned on the response validation option.
It's also noteworthy to mention that in the Java web service client I created to test my web service, the response could not be loaded into the output object (a NullPointerException error showed up when I tried to access the output object), this was due to the namespace issue and it started working correctly once I fixed the namespace.
SoapUI is a fantastic product. one of the things which makes it a great product, however, is that it is very tolerant of poorly defined webservices. in our product, we deal with lots of webservices, and a frequent comment on an issue in our product is "it works fine in SoapUI". we have learned the hard way that SoapUI will tolerate all kinds of broken webservices. so, in summary, working with SoapUI is not a proof that your webservice is well-defined.
There are WS-I testing tools to check your web service for conformance to the Web Services Interoperability profiles. If your service adheres to the WS-I basic profile, and SoapUI can call it, the issues are definitely on the consumer side.
EDIT: well, or in between the both...
SoapUI can check your wsdl for WS-I compliance, see http://www.soapui.org/SOAP-and-WSDL/working-with-wsdls.html.
It's most likely that the consumer (client) is buggy... If the client is generated using wsdl2java it's a big chance to have bugs in it... and if you are using some special functionalities that are valid (conforming w3c) then don't be surprised... the generated clients sometimes do this... even some libraries used to generate java classes or libraries to generate the webservices are full of bugs...
A lot of things are not supported by known and frequently used libraries... (I don't want to give names -- but wsdl4java is not perfect)..
If you are using security or something ... higher chances to have bugs on both server and client side :)
maybe if you tell us what is the problem we can help you...
I have a set of java classes generated by wsimport utility from WSDL. (client) Is there a (simple, not involving sniffers and own replication of server) way to look at generated XML which is sent? I mean inside the code, some method or similar way.
Best option here is using message handlers. I'm writing from a mobile device right now, unable to provide code snippets, but you could have a look at http://docs.oracle.com/cd/E15051_01/wls/docs103/webserv_adv/handlers.html
It's possible to use them on a client side as well.
Update: here is a better link http://www.mastertheboss.com/jboss-web-services/web-services-handler-chains-tutorial
I am trying to write my first SOA client, and am having difficulties with the
"2-way SSL" part.
Our server runs under Weblogic, but my application is a simple Java Console app - it does not run in any container.
The server uses and requires certificates. We use trusted certificates from Godaddy.com, and we also have internal certificates.
Our sysadm gave me the server certificates, which I added to my JRE "cacerts" file using keytool. I was told that I should use Spring-WS as it would make my life easier, but I am having trouble getting it to work, as there are quite a few variations that Chap. 7 mentions, and I am not sure which one I should be using. He also created a .jks file for me personally to use for my authorization.
I would prefer to not use Spring at all, for this simple application (the SOA method is a simple "Add comment" method with no substantive return data.
I am working with MyEclipse 9.1 and am trying to use Maven4MyEclipse as well.
My question is:
Given that my authentication certs will be available via the JRE cacerts file (if I understand this correctly), the main thing I need to do is to be able to present my .jks file during the SSL handshake.
Can I do this without Spring? If so, is there a way I can simply set a System property with my .jks file so it gets handled automatically? Or do I really need to use Spring to handle the authorization part?
If the latter, how do I know which Spring security interceptor type to use? XwsSecurityInterceptor or Wss4jSecurityInterceptor?
Or another question just occurred to me. Can the .jks file also be added to the
cacerts file and have the authorization handled automatically?
Thanks,
Mitch
p.s. Believe it or not, there is apparently no existing Java client example in my organization to simply look at for a template.
For two way authentication, I have always used the followin when starting the client app:
java -Djavax.net.ssl.keyStore=myClientKeystore -Djavax.net.ssl.keyStorePassword=123456 -Djavax.net.ssl.trustStore=myTrustStore -Djavax.net.ssl.trustStorePassword=123456 -Djavax.net.debug=ssl
That is, my clients private certificate is in the "myClientKeystore" and then the server public certificate is in the "myTrustStore". The javax.net.debug=ssl will make your life easier, since it outputs some nice debug info if you can't make the SSL session to work.
That's for the SSL part.
Then I think you mix up SOA with Web Services and SOAP. SOA usually means service oriented architecture and is very high level. I think you are talking about a SOAP implementation.
If the web service is more than trivial, yes, a framework will make your life easier. Apart from Spring-ws (which I like as well), you can google for CXF and Axis2 and you will find tons of example how to write a SOAP client. But sure, you can write the web service call rather raw, if you are able to create the SOAP envelope manually (use SoapUI to generate test envelopes is a good start..).
Then, take a look at : this page, it has an example on how to make a SOAP call over HTTP without any framework at hand. Of course, since you are using SSL, you should reference a "https://" address instead.
I'm creating a web-service client. I used a WSDL file to generate the client side stubs.
But now I have to authenticate to the web-service, and invoke methods.
I've checked some tutorials on how this should be done, but they always explain generating the client code and server code then having them work together.
I was wondering if all the info needed to authenticate and invoke requests is contained within the WSDL file(and thus auto generated code)? Or do I have to also have knowledge of the web-service code?
Any help appreciated.
Generally speaking, a WSDL should be all you need (assuming it's been written by someone who knows what they're doing).
A well-written WSDL should have sensible method and parameter names such that the generated client bindings are more or less self-explanatory. Through the <annotation><documentation></documentation></annotation> attribute, comments should be added to resolve any ambiguities. In other words, think about a WSDL just like a JavaDoc API page. You shouldn't need to care about what's inside the black box, just so long as you know what you need to put in and what you'll get out of it.
As for authentication mechanisms there are really two cases to consider: the web service level authentication and application server level authentication.
At an application server level (e.g. Tomcat or GlassFish), the WSDL won't give you indication of the authentication method used (because the WSDL is at a level above the application server). In this case, you can try debugging by accessing the WSDL file in a browser (or maybe try invoking the service in SoapUI) and seeing what you need to be authenticated.
At a web service level the security mechanism should be described in the WSDL. I'm not aware of any IDEs that can automatically recognise the authentication mechanism described in the WSDL and then prompt you to what you need to supply (although I only really use NetBeans). However, you should be able to work it out - either by examining the WSDL or by looking at the error messages your web service client spits out when you try and access a protected resource.
A WSDL file does not contain information on the order of invoking certain functions (if any). So, in my opinion there should always be additional documentation.