Is there a way to record a response (even non permanently during one "test-session") in a way that I can use an assertion like "please validate that the (new) response is exactly like this (old recorded) one".
The use case is a regression test for changes which apply to several web services, which then have to be retested to be sure there were no side-effects.
I'm assuming that, after the Web service is changed, the old response will be available to your test only as a saved XML file or log file.
I'm also assuming that you have the free version of SoapUI.
How good is your Groovy? There might be a way, if you copied and pasted the old response into an XML file, for you to read in that XML file in a Groovy script assertion or Groovy script step. This part might also be done by creating a Groovy class from the XML and making sure that the class is in SoapUI's classpath.
Within that Groovy assertion or step, you would create a new XMLSlurper object from the XML in that file (or by referencing the class) and compare the values in the XMLSlurper object to the values in your new response.
Caveat: I haven't tried this myself but it's the first thing that comes to my mind if you won't be able to get the old response any other way and you're working with the free version.
Related
this is more of a high level question about using jaxb and xslt, as I try to gain more of an understanding of what I need to do, and what I need to learn more about.
I have inherited an application that has Java class files generated from an xsd schema (using jaxb), does some stuff, then writes one of these objects to a serialized 'save file'.
I currently need to make changes to the xsd, which of course will mean some of my originally generated classes will be updated. However, I still need to be able to load the old serialized saved files for backwards compatibility - does this mean I need to maintain a copy of the current xsd, and all generated class files in order to load the old serialized save files? Does anyone have a suggested way I can do this, if I must be able to load the old files?
For all future version of the xsd, I intend to output saved files to xml, and use xslt to transform the file before unmarshalling the xml, which I think will work, as mentioned in this thread How should I manage different incompatible formts of Xml based documents. Doesn't help me with the older serialized files though - any ideas?
Thanks.
Probably the main drawback of JAXB, and of data binding in general, is that it makes schema evolution very cumbersome. XML is a technology where people expect to change and extend the schema/data model frequently, whereas in Java it is hard-coded and hard to change. Use of XML-oriented languages like XSLT and XQuery is a big advantage in such situations.
Saving persistent data in the form of serialized Java objects seems completely perverse to me. Before you move to your new schema format, convert it all back to XML. The whole point of XML is that the data is then in a format that is far more durable, and not dependent on the continued existence of the software that created it.
Assuming I am developing a client for a known, WSDL-based, web service (of which source code is not available to me):
Is there a way I can validate various fields (e.g. string lengths not exceeding limit) based on the inline schema in that WSDL, at runtime?
If so, how do I interact with that web service to get its inline XSD information?
If you want to make this really dynamic, than you have to assume that the URI to the WSDL is accessible to you, along with all other external references the WSDL might use, to other WSDL files and/or XSD files.
First step, you will have to download files to a temp folder, or create I/O streams to those URIs for in memory loading, to load a schema (a javax.xml.validation.Schema). I am not aware of a Java API which would make this task easy (get a schema out of WSDL reference, such as one available to developers on the .NET platform) - hopefully if there is one, someone might chime in. Otherwise, it shouldn't be that difficult to write one.
I have to warn you that many people may consider this (loading external URIs, particularly one pointing to the Internet) as a security issue in a production environment, so be careful here with your design. Since you're saying "a known, WSDL-based, web service", I would probably aquire the XSDs at design time, and bundle them as resources in my Jar files which would go with the client code.
The next thing is how do you create your XML... Let's say you're using something such as JAXB, then a post such as this one will give an idea how to tackle your problem, and what exactly do you need to validate. If you're not using JAXB, then explore what your API is doing, and how it would actually allow you to interject your validation...
I hope that this at least gives you an idea around the kind of details you need to have in this kind of question, to get a more specific answer.
I'm working on a project where we have Jersey/JaxB based serialization system to talk to a web service. The service in question returns data wrapped inside an Atom feed.
An older part of the system wrote a one-off specific to their service XSD for Atom that was hard wired with only their particular elements. I now need to add support for a new service, which is doing a similar thing (using Atom as a "envelope"), but using significantly different elements and content schema.
I don't want to disturb the existing code, so ideally I'd like to do the same thing the previous project did: define my own schema for the parts of Atom that the new service is using.
I'm running into:
org.xml.sax.SAXParseException: 'feed' is already defined
I'm apparently hitting the limitation described in the XJC release notes: It is not legal to have more than one <jaxb:schemaBindings> per namespace.
Is there a way to set things up in our build so that if I have separate xjb files, I can run xjc independently over the two distinct schemas and generate code for each of them into separate packages? How do I work around this limitation?
We're using the maven jaxb plugin.
Just for the record, what we ended up doing was generating the code from the schema separately, and checking in the generated code. Since the ATOM schema's not changing, it was reasonably safe. Annoying to have to do it that way though.
I have to access a existing SOAP webservice from an Android application. I have been provided some WSDL files describing the webservice. Reading some other answers here on SO, it seems ksoap2-android is the way to go, with respect to which SOAP client to use.
The next issue is then how to generate the Java classes needed from the WSDL files, and this is where I am coming up short. As far as I can see there are the following options:
AXIS2 code generator
WSDL2ksoap
JAX-WS wsimport tool
I initially tried #1, with the AXIS2 eclipse plugin for wsdl2code generator. The wizard did successfully generate a lot of Java code, however it also changed my android project to some kind of webservice project, and I was never able to get anything that was generated to compile, let alone work with ksoap2-android. Has anybody has success with this?
I am not able to run wsdl2ksoap successfully, as it seems to require a running webservice, and all I have at the current point in time is WSDL files. Likewise from reading the webpage, it seems to be a project in its initial stages, and not really ready for prime time.
JAX-WS wsimport I have not had a chance to try yet. However I am unsure if what it generates will work with ksoap2-android?
Question: How can I generate Java files from WSDL files, for use on Android with ksoap2-android SOAP client library?
Thanks a lot in advance.
(PS: Yes, the choice is SOAP, it is suboptimal for Android use, but I cannot change that.)
I found this tool to auto generate wsdl to android code,
http://www.wsdl2code.com/example.aspx
Here is the code:
public void callWebService() {
SampleService srv1 = new SampleService();
Request req = new Request();
req.companyId = "1";
req.userName = "userName";
req.password = "pas";
Response response = srv1.ServiceSample(req);
}
I had similar situation (I had only wsdl file without working webservice). I've used
http://easywsdl.com/
to generate classes for android without any problem. This tool uses ksoap library. The great thing with this tool is that it supports WCF extensions and types like data contract with IsReference attribute or Guid.
My conclusion after quite a bit of researching is that there is no such (mature) tool available, unfortunately. Neither AXIS2 or JAX-WS will work on Android, and WSDL2ksoap is simply too immature for any real use.
However there is a proprietary tool called wsclient++ that will do the job really well. (Read update below, when put to real use, it does not stand the distance at all.) It does not use the ksoap2-android client library, it has it's own.
The client library is a bit crude as it has a hard dependency on the http transport, making (unit) testing a bit complicated. But it can be modified quite easily to allow DI, as the source is available in the distributed jar file.
The wsdl to java generator however works just perfect, and will save us tons of time.
Update
After working with wsclient++ for a while, it is clear that the generated classes are really crude, and does not handle error cases at all. (Every method declares throws Exception).
We are no longer using wsclient++, and I would not recommend anyone to use it!
We have not really found any working alternative, unfortunately. :/
In the end we converted our WSDL files using AXIS2, and then wrote a bunch of custom script to strip and transform the generated java files to something that will build on android using ksoap2-android library. Very hackish, and needs tons of manual labor to run. Unfortunately. If you find a better way, or one comes up, please provide a new answer.
I use Apache CXF tool just to create dto, and i wrote a class to perform a basic unmarshalling based on name of elements
A bit late on this, but there is a ksoap2 stub generator under development, and I successfully used it to create the stubs.
http://ksoap2-stub-gen.sourceforge.net/
Also someone made it availabe as an online service (i.e. you give your WSDL's URL and the service will return a zip file containing the stubs).
http://www.davidgouveia.net/2011/04/online-stub-generator-for-android-applications-using-ksoap2/
I have used for iPhone too some auto-generated classes I wanted to see here too.
wsdl2code is one of the similar what I have used at iPhone. Give an url with wsdl file you will get some classes to download. For me the hardest part it was to download the required parts. It took more than 2 minutes of searching :) ksoap2-android-assembly-3.0.0-jar-with-dependencies.jar needed to download ad drag-and-drop to ADT ( Eclipse) . It is super easy, especially if you have used the counterpart at iPhone. - a similar tool I have used.
However in my case I am not happy at all with the solution, because I see I am using cannon, a set of cannons to shot a sparrow. In my case it should be used a HTTP Post and not including dependencies from other libraries.
To be honest I don't care to much, because once the server side believe we have unlimited battery power and unlimited data plan, than I close my eyes and I don't care about marshaling-unmarshaling overheads, which use the CPU ( battery ) increase the data transmitted over network.
In worse case it should be a JSON + HTTP POST not SOAP for mobiles...
I would suggest to talk at server side guys and explain for they why it will not good if they do 2 click on wizards and we do other click on forms to get the generated code. At least while the application is not a huge one, even than should be budget to optimise for mobile a few interfaces implementations.
My webservice provider give me a large WSDL file, but we are going to use only a few function inside.
I believe that the large WSDL have negative impact to the application performance.
We use the webservice in client appliction, startup time and memory usage are issues.
Large WSDL means that jax-ws will takes longer to do binding and will takes more memory for the stub class.
Is is possible that we trim WSDL file to a lightweight version? Are there any tool for this purpose?
I do not think my webservice provider will generate another WSDL for us. We may have to do it auto in the build script.
In short, your answers are "No tool, but you can DIY".
I wish there are simple tool can do it because my WSDL contains too many unused function and schema of data structure.
If I can automate it, WSDL -> trimmed WSDL -> generate client stubs classes. Nothing unused will be generated, no misuse, no maintenances required, we will not touch on the generated code, and I can really focus on the code which in use. Smaller JAR, shorter XML parse time. If the WSDL get updated, I will had only to rebuild client stubs classes and run unit test.
I tried to keep off from human invoked. It takes time, easily to get mistake, and have to redo every time every little change on the original WSDL.
I am not conversant on the WSDL schema. I am thinking can it be done by XSLT?
The size of the WSDL will have zero impact on performance... unless you are downloading it and/or parsing it for every request. And if you are doing the latter, don't. It need only be processed when the service changes, and the service should always change compatibly, with continuing support of old messages (at least for some overlapping time period).
You should consider processing a WSDL to be a program change, and do it as you would any release, with versioning, and testing, etc.
The problem is not with the size of the WSDL itself. It's the size of the generated code that matters. For instance, if you use Axis2 to generate your code from a large WSDL, you'd end up creating a Request/Response class for every WSDL operation, as well as the classes of their return types. You'd end up with a huge stub class later on, which could affect performance since it would import classes that are required by web service operations that you don't need.
There's no easy tool to do that. I usually use notepad++ to do that, and YES you could always make mistakes while doing it.
Another common mistake is choosing to generate both Sync and Async style methods, when most of the time (In my case at least), you'd only use Sync style methods. This could dramatically increase the size of your stub as well.
I haven't used the tools that you're talking about, but you can successfully execute web service methods without the code ever touching a WSDL file.
This seems like a good time to run a quick test. Cut everything from the WSDL file except what you need to execute one of the simpler methods you plan to use. Reference that copy of the WSDL instead. If it works, you know what to do next!
There is no need to trim the WSDL. If you're set on going down this path, simply delete anything in the stub classes that you don't need. Just make sure to test it as you go to make sure everything is still working.
You could just manually remove the <wsdl:operation> elements corresponding to the methods you don't need and see if that's enough. You should be able to remove those elements without touching the rest of the file.
The physical size of the WSDL should not matter if you generate client stubs classes at compile time (e.g. via AXIS wsdl2java.) If you are downloading the WSDL and parsing it for each request then the download time will likely dwarf the parse time. Consider caching the file locally if the download time becomes an issue. If the parse time becomes an issue you may want to consider trimming the file or caching the parsed objects. Use care when caching or trimming the file as you will need to integrate any changes when your provider issues a new WSDL. Consider updating your cached/trimmed WSDL each time the service is restarted or at some interval.