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.
Related
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 have a desktop application that consists of 10 features, and some clients asks only for 8 features or 7 features.
i want to have a way to manage adding/removing the permissions/features for the client (only i can control that). so that i can hide/show feature based on a flag.
is that should be done through a property file that contains the name of the feature with boolean flag, or what ?
please give me some ideas, thanks.
From your other answers, it sounds to me like the following additional details have cropped up; please let me know if I have these wrong:
You're delivering your application as a .jar file,
Each customer gets their build directly from you, and there's a small number of customers,
You configure a build specifically for each customer, and
You don't want your customers to be able to modify their feature access.
In that scenario, I'd store the "active" feature list in a hashed property value stored in a .properties file bound into the .jar. I'll describe one way to do that below. You generate the properties file just before delivery, add the file to the jar:
jar -uf applicationJarFile.jar configuration.properties
then sign the .jar and deliver it. At runtime, your app can load the properties file, run the hash of each feature, compare with the properties you've stored, and determine which ones are off or on.
Your properties, which determine which features are enabled, might consist of a list like this:
feature1=enabled
feature2=disabled
feature3=disabled
feature4=enabled
Write yourself a utility which hashes the whole string "feature1=enabled" plus a salt value, e.g. "feature1=enabledaKn087*h5^jbAS5yt". (There's code for this built into java; see How can I generate an MD5 hash?, for example.) The result will be an opaque 16-byte number, which you can then store in another properties file to be included in your app: feature1=1865834.... The salt value should be broken into multiple shorter strings in your code so your customer can't just retrieve it and easily duplicate the process themselves.
In your app, at startup, you construct the string above using both the "enabled" and the "disabled" value, run the MD5 of both, and compare it with the stored hash. That'll tell you what features to enable.
I think a separate .jar or .properties is a bad idea; it clutters your delivery.
You can automate the whole process fairly easily, since you can generate the properties on the fly any time, and bind them into your app.
You can add other "baked in" properties which gives you a lot of flexibility in the final deliverable, including things like skinning for customer branding.
As others have pointed out, though: there's lots of ways to approach this, depending on the rest of the details of your product and your overall goals. This is one way to do it, given the assumptions above. AFAIK, there's no "canonical" way to do this sort of thing.
You should consider using a License management api to do the same, which will give u both security and capability to change License pre/post installations.
It is not advisable to build adhoc licensing capabilty, take a look at License3j and TrueLicense, they are both free and can help you gain perspective or better fulfil your requirement
You could try and encode that in a file. I assume each user has an own installation/version of the application, right? I further assume the application should not need to check some web resource. Thus you need to implement that in a file.
However, you should encrypt that file and put the salt and key somewhere in the code where they can't easily be decompiled. Additionally create a hash to check for modifications of the file. That hash could be based on the application's size or something else.
Please note that there's no 100% security and any hacker could still crack your application. But in that case this would need some form of criminal energy not commonly present in the business world.
Modularize the application and deploy to each client only those parts that he wants/has access to. There's many ways to do it (the most complete but heavyweight being OSGi), but the specifics depend on your circumstances and requirements.
The quickest way to implement it might be to simply extract your extra functionality in separate JARs, and on deployment update the classpath appropriately.
It depends on the kind of application,kind of security you want and the number of people likely to use the application.
If the number of clients is not that big you can store their preference in some in memory data structure like a Map . Otherwise you can use file system or a DB depending upon the kind of security you want.
This is very open ended - it really depends on what you're trying to achieve, and what you mean by a feature.
One approach is to use a plugin based architecture. e.g. you have an interface
public interface Feature {}
and provide each of your ten features as implementors of this interface. Then have some method which runs at application start which looks for Feature subclasses on the classpath.
You can control which features a client has by including only the relevant features on the classpath, e.g. using maven.
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.
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.