I have an older webservice and I want to rewrite some code. In the end the new wsdl should be equal/same than the "old" wsdl.
The problem is, that both WSDL files have different ordering of fields ...
How can I gurantee, that users do not have any problems due to the code changes and can still use their clients, because the interface has noc changes? How can I compare both wsdl files, if both have the same meaning/interface? Does someone knows a tool to compare the two wsdl files?
Related
I have 2 WSDL for 2 different services which uses same XSD for Input and Output messages. Now I want to use CXF WSDL2Java by ANT target and create the server java file out of it one by one, but I don't want to recreate the java files in 2nd time which created earlier in 1st time. As both uses same XSD and almost all Input and Output parameter is same but the purpose of the service is different.
Kindly help me how can I achieve this by CXF and ANT.
As CXF documentation says you can configure Ant to parse your XSD: http://cxf.apache.org/docs/wsdl-to-java.html
Maybe you can define two targets, one that results in your XSD files parser and java files created and a second one that does not need to do this. Later you can integrate these two targets with your Ant workflow as you need.
Initially I have used bottom-up approach (Code to WSDL) to generate a wsdl file using three classes.
Now using the generated wsdl file I am trying to create the code i.e. top down approach using eclipse and its creating lot of classes than what I have used initially to create a wsdl file. How do I get rid of unnecessary classes and get the original classes which I have written?
You will most likely never get the precise original code if you go with code -> generate WSDL from code (e.g. jax-ws) -> generate code from WSDL (e.g. wsimport) and that is fine because WSDL-driven development and it's counterpart are two different approaches.
With WSDL-driven approach your specify your WSDL contract first and then usually would generate you server/client code from the contract.
With code-first approach you define the service and it's operations in Java and would usually rely on a framework to generate the final WSDL.
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've been looking for a way to programmatically parse WSDL and associated XSD files to get values from annotation / documentation tags. I managed to get values from wsdl using wsdl4j, but how do i do this for XSD files? I tried to use XSOM but for some reason i always get null.
1). Hope this link will be useful for you to choose the best parser, Parse WSDL Effectively.
I have tried using Apache Woden, WSDL4J and Membrane SOA. Among these, Membrane SOA seems to be developer friendly.
2). Place the dependent XSD's in the folder where you have placed the WSDL. Then try parsing your WSDL, it should work fine.
Maybe the JWSDL help will be of service. It also makes calls to the services.
Here a discussion on the subject
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.