I am attempting to write a web client to access a web service; I out of every tool I have tried (CXF, JAX-WS, JAXB, Axis) only Visual Studio 2012 and soapUI are able to access the web service. For the Java generated classes the API is incorrect, there is no way to pass in the Authentication object. soupUI can call the web services and a CSharp program works fine. But my boss expects Java.
Anybody know what library soupUI is using, is it something I haven't tried or is it proprietary? Or anyone know how to hit this web service with Java and have it work?
Related
I am the developer of an application which is the consumer of an in-house developed web service. The web service was originally developed in Java and deployed in JBoss.
Recently, I have been notified that the web service had been completely ported to .NET WCF. I simply updated the web service endpoint URI string in my configuration file, but my application has failed to connect to the new web service.
Upon comparing the old and new WSDLs, I can see that the methods and the structures are the same, but somehow the namespaces and the internal structures of arrays are different.
What do you suggest so that my application would be compatible with the new web service?
Thank you very much.
Namespace change means the WSDL of both Java Web service and WCF service are different. You know in programming classes of the same name but in different namespaces are totally different classes. Likewise, though the method signatures and data signatures look the same, however, in different XML namespace of WSDL, they are different contracts. Thus on your client side, you should have new set of proxy classes to talk the the WCF service.
You may ask the developers of the Web services about what were the intend of changing Xml namespace in WSDL. If for the co-existence of both Java Web service and Wcf Web service and enforcing some changes on client side, you MUST generated new proxy classes against the new WSDL, and it is recommended to use svcutil.exe rather than Service Reference in IDE so you have fine gained control over CLR namespace mapping to Xml namespace.
If the service developer could reverse the change the Xml namespace of WSDL for good reasons and the WSDL could remain the same, you just need to change only URL.
I need to develop Webservice Application for our Client .
I dont know anything about WSDL4J
From the net I found this
"The Web Services Description Language for Java Toolkit (WSDL4J) allows the creation, representation, and manipulation of WSDL documents.
Is the reference implementation for JSR110 'JWSDL' (jcp.org)."
But anybody please tell me why should we use WSDL for developing webservices?
Is there any specific advantage we will get?
And can anybody please point me a link where to start for working with WSDL4j?
You actually need not to use wsdl4j for developing web services or clients for web services. There are other SOAP stacks developed on top of that. Axis2 is such an open source SOAP stack..
WSDL2Java tool that comes with Axis2 - which been used to generate client side stubs from a given WSDL. uses wsdl4j internally..
I'm developing an application for Blackberry that consumes .NET Web Services that are hosted on our public web server.
We are using JSON as our data interchange format.
So far we have been testing the application and everything is working fine but there is one big thing to solve: the .NET web services are public. If you go to the service URL: http://www.whatever.com/myservice.asmx you can assign values to the parameteres and invoke the service.
Obviously we don't want to have them publicly available and we want them to be secure.
I've been reading some questions here at stackoverflow but I haven't found a good answer.
I was thinking of adding a "password" parameter to every web service that I have and there sending a password to the server so that it can verify that it's the Blackberry trying to consume the service and not some spammer. That password would go as a String in each JSON request that the Blackberry does.
Another thing that is important to mention is that we have a simple web hosting solution from GoDaddy so our hosting is shared, we don't have full control on the computer.
Is this a correct approach?
For better protection depending on content importance you can use checksums or encryption methods.
You can use bouncycastle cryptography API http://www.bouncycastle.org/. This is free and good.
This can be used in both C# web service and blackberry application because it supports both C# and Java.
Is there a way to test a JAX-WS web service? Mine is in Netbeans and I'm trying to use a web service client in the test package to do it but I wonder if this is the right way.
You can use soapUI for testing the webservices, both using a GUI or command-line
http://www.soapui.org/Test-Automation/functional-tests.html
&
http://www.soapui.org/Test-Automation/integrating-with-junit.html
You can also by using netbeans test the webservices using generated tests, this is accessible by right clicking the webservice and click "test webservice", that is if you've created the web service using netbeans, if you haven't you can create a webservice from the WSDL of your web service and go from there.
If you want to use the web service client from the test package that is possible, netbeans should generate jaxb classes neccessary for testing, you would be able to drag-n-drop the methods from the client to a test class.
We have finally upgraded our web services from .Net 1.1 to .Net 2.0/3.5. One of the clients that calls these web services is run as a windows service. It is probable that the windows service will not be upgraded until some time after upgrading the server at customer sites.
Is it possible to massage my .Net 2.0 web services so they will correctly service the calls from the .Net 1.1 client? In my test environment, I connect to the .Net 2.0 web service from a .Net 1.1 client and I receive a 401.1 error from IIS. The web service is set to anonymous access. The same credentials work when connecting to the .Net 2.0 web service from a .Net 2.0 client.
Thanks for your help,
-colin-
Web services are meant to be platform-neutral. If your web service was written properly, then any client, on any platform supporting SOAP 1.1, should be able to consume it.
One place where this can fall down is if your service is returning or receiving types specific to .NET. If you send or receive a DataSet, for instance, then there can be problems - DataSet is specific not only to .NET, but also to specific versions of .NET. There were many changes made in the area of XML and XML Serialization between .NET 1.1 and .NET 2.0, and you could eventually see one of those problems.
But I don't think any of those should get you a 401 error. Look into the event log and see if anything interesting was written about that error.
It depends on the service. If the .NET 2.0 service:
Is configured to support SOAP 1.1
Does not use WSE 3.0 (WSE 2.0 is OK)
Does not use any nullable types (not supported in .NET 1.1)
Accepts and returns only primitives or POCO classes (no DataSets, etc.)
Then it's compatible.
If you're getting a 401.1 error, but have no problem connecting with other clients from the same machine, then my guess is that the service is expecting something in the SOAP headers. What it's expecting, I can't tell you offhand; I'd have to see the service code/configuration.
Alternatively, it might just be a configuration issue on the web server. Without more details about the specific environments that can/cannot connect, it's hard to say.
As #Aaronaught wrote, The error can be that the service is expecting something in the SOAP headers. To analyse this, you could verify the wsdl generated (expand all files of web reference) or download the metadata via svcutil.exe. This will generate a proxy, that is used to call the web-service.
That way, you have more control over the proxy.
Example on how to use svcutil:
From command prompt:
svcutil
http://service/metadataEndpoint
Thank you for your responses. They were helpful in further diagnosing why it wasn't working. It turns out that everything does work and that the 401.1 response was misleading (but correct). Our problem was due to a change in the web services directory structure. Had I been paying better attention, I might have caught it before asking this question.
To answer my question: Yes. A .Net 1.1 client can call a .Net 2.0 web service and, in general, no additional configuration is necessary. Just make sure you're URI is correct.