I have gone through many answers on stack overflow on how to make a soap client in Java but i still can't wrap my head around it.
Requirements
1) I have been using loadrunner for making Soap requests but I am gonna discontinue the product and wanted to make a simple Java soap client.
2) I need to automate the soap client to test the web service every day and generate logs. There are gonna be 20-25 soap web services to be tested at a time. How can I achieve it?
3) I have gone through SAAJ and JAX-WS but I found them too complicated and to also couldn't figure out how can I head custom HTTP headers in the requests.
It seems like I am designing Loadrunner again. So my question is what can be the steps to achieve the above requirements.
I have a wsdl file, certificate, URL and some custom HTTP headers to be included in the request.
Also, should I use SOAPUI to generate the request xml first, would that be a better idea?
As much as I love Java, if you have soapUI available, why reinvent the wheel by writing your own web service client? JAX-WS and SAAJ can do all the things you need; you just need to dig down into the APIs and experiment.
If it sounds like you're designing LoadRunner again, then why not stick with LoadRunner? It's free and integrates with soapUI, but like all tools it has a learning curve to be negotiated. There are alternatives such as Apache JMeter, but again it takes time to come up to speed.
Plus, LoadRunner might not be the right tool for your use case. If you just automating tests, and not performance or load testing, plain old soapUI used in conjunction with something like Jenkins might be a better alternative.
Related
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'm working with a client that's on a currently purely-MRI Ruby/Rails stack, but we have a 3'rd party service we need to start interfacing with that is built on .Net with WCF and the only way to access it is SOAP. They are using MS-LWSSP (MS documentation) as a security protocol and none of the Ruby SOAP libraries seem to understand how to connect to it.
We are considering adding JRuby to the tech stack (as a separate small application) to connect to this service, as Java has offers more choices for dealing with SOAP. However, I'm not familiar with any of the Java SOAP libraries.
I have seen some other posts about using a Java client to connect to a .Net SOAP service, but I have not seen any specifically addressing using this security protocol. Their SOAP service is SOAP version 1.2 and it does have a WSDL we can access.
Has anyone done this? Could you please provide me with information about what libraries would be helpful in doing so?
Thank you very much for any suggestions or information.
This is an old question now, but I'll respond with what worked for us. Or more correctly, what never worked for us.
None of the Ruby SOAP libraries were compatible with the protocol we had to use. We spent quite a bit of time on trying them out but they simply didn't work with the client. We considered look into implementing the protocol ourselves, but that was far more effort than we wanted to spend on this.
In the end, we requested the client to give us access via a non-SOAP route and that worked out much better.
The moral of the story: try asking if you can have non-SOAP access. It'll save you a lot of effort and headaches.
One desktop application needs to get some services from server.
For example sending some parameters and receiving some result.
Imagine implementing a solution by Java Servlets, in a way that the app sends the parameters to the servlet (POST) and receives the result in XML.
Does this approach have any security issue in compare with web-services (Soap / Restful) ?
Thanks and sorry if the question is a bit general.
I don't think so. But personally I would still go over REST, mainly because it would be easier to maintain and update if needed. Also probably easier to test and implement.
As long as your solution has suitable authentication (username/password) and takes place over SSL, it's no less secure than Web Services/SOAP. And indeed you might find it a simpler solution to implement.
The security issue is the same for both solutions because it's http but I won't do the post thing because it's not structured properly, meaning it's client dependent and not using a standard. If you don't like XML, you can try JSON.
I need comunicating using java with a WebService that uses the WSDL technology.
I tried some libraries but with no success, thus, I decided to do it manually.
My plan is getting a .xml which uses the comunication (filtering with fiddler for example) and copy it manually building a string. So the .xml will be ok. Do I need to take care of anything else?
Do I have to do any more? Http request, response?
I wouldn't like to create all the structure for the xml and after that, find that I can't continue the comunication.
Thanks
Java comes with a complete API for XML Web Services, this is JAX-WS. (lot of documentation available with a simple serach with google)
it allows developers to build a working client with very little effort starting from a WSDL file (seems your case)
I really discourage you to build the client by yourself. You should care about SOAP message building, message sending, response parsing and so on.
im starting with web services. I'm working in a project that needs to communicate Android with a web server and I'd like to save some time chosing the appropriate protocol for the communication.
Between JSON ,REST and SOAP:
Which ones can I run in a non-dedicated server?
Whats the best choice for a high trafic server?
Thanks in advance
JSON and REST are not mututally exclusive. JSON is a data format that the REST interface can return.
You may run either on a non dedicated server. I would personally choose REST for rapid prototyping on Android as it is easier to get up and running. (With SOAP you will probably want to have a schema which takes time to put together)
There's a good comparison between REST and SOAP on the REST wiki article: http://en.wikipedia.org/wiki/Representational_State_Transfer#Concept
REST is more of a framework than a communications protocol. JSON and SOAP could be use to create a RESTful application.
If you're writing something with many resources, I'd use REST as it is far more structured. There are also a lot of libraries that will set most of things up for you. I find JSON and SOAP are better for custom functionality that you want to hack together quickly. They can be lightweight, but less structured.