Typically an enterprise application consumes a number of webservices. It is likely that some of these webservices that are being consumed will be upgraded to a new version every month. Before consuming the new webservice , the consumer must do a thorough analysis of changes between old service and new service which will form the basis of impact assessment.
I have come across tools that compare the WSDL , however some of the services that the application consumes could be huge and the WSDL might have more than say 50 operations. The consuming application might be using say 10 operations. By using WSDL comparator , it could be a bit tedious to identify if a modified element is part of a any of the operations consumed. In order to do such an analysis, I usually generate the request and response using SOAP UI for each operation and use text comparison tools to identify the difference.
Is there a tool available for performing of operation-wise comparison when 2 WSDLs are provided as input?
WSDL is eventually an XML document. The XmlUnit can come very handy in this case. Its essentially a utility for unit testing the XML application which make heavy use of XML. In the most trivialized for, it has a Diff class which actually compares the XML as follows:
Diff myDiff = new Diff("</Original>", "</Modified>");
But as I said, this is very trivialized. Please explore this for more details.
Also there is XML diff utility from Oracle.
Not sure if you the operation-wise comparison is possible or not.
Service Registry
It sounds like you are describing service governance. Some of the functionality you are describing can be provided by a registry above the functions of finding and publishing services.
http://wso2.com/products/governance-registry/
http://www-03.ibm.com/software/products/us/en/wsrr/
Maybe you want to generate classes from wsdl files using Eclipse WSDL2Java plugin or Apache CXF instead of generating each operation request and response, in my idea it can facilitate your work. Then compare the new classes with old ones using Devart Code Compare. Am i right?
Related
I'm searching for a way to consume soap webservices without using wsimport and tools like that. So far, everyting I found requires the wsdl artifacts generation and I want to avoid it because I don't know wich webservices will be used.
The idea is to give the user the possibility to add several WSDL's urls / methods and the program consume them and send it's response to another url.
I'm not looking for out of the box solutions/code or something like that.
What I need is to know if it is possible or not and how to aproach this problem, ideas and things like that.
Thanks!
SOAP mandates a contract between the Client and Server. The contract is that Client will give a request XML is XYZ format and Server will give response in ABC format. Without this, SOAP does not work. This is what is defined in WSDL. So we have to use WSDL.
Tools like wsimport, wsdl4j convert these WSDL files into an object hierarchy and prepares a JAXB wrapper for you, to make life easy!
Now if you do not want to use the tools which automatically convert WSDL to Java Beans or anything of that sort, note SOAP is based on nothing but an XML. If you know how to parse an XML in java, thats pretty much it. You can use a JAX Parser to achieve this and you can read everything that comes in a SOAP request and response.
The problem that you will face is, as the complexity of the SOAP XML grows, it will be difficult for you to parse the XML properly, identify the nodes, values and relations properly. And add to that the problem where in you cannot, without a proper object hierarchy , relate between nodes which are distance apart. Meaning, from line 100 you cannot go back and relate a line 10 node, unless you start maintaining your own objects, relations etc. (which is not what you want, i guess)
Using Java Beans the object hierarchy is maintained and because of that it is easy for you to relate them between different objects at different nodes easily. But JAXB is comparatively slower than JAX.
This is more of a design-pattern question.
My client application [implemented and will run both as part of a scheduled batch job as well as a message processing application] makes SOAP over HTTP calls to a third party Engine to get some membership data. Since the underlying binding is done thought JAX-RPC, my SOAP response is eventually converted / copied into the generated client stubs.
Now, my question - Is it better to maintain my own domain objects and copy the data from the response objects of the service or is it OK if I can directly use the stub objects to do other processing!
Any suggestions?
This question is going to be somewhat subjective. I prefer to always translate to my own domain objects in case I ever need to swap out the web service implementation. If they ever change over to RESTful web services or just simply change up their wsdl on a version upgrade, you may be out of luck if you are using the stub classes throughout your application.
There are cons to this practice though:
You will need to maintain a similar set of classes
If the service never changes, you wont see any returns on your effort
You can always change this later if it proves useful
What is the best practice for consuming JAX-WS web service in a Java client? I am inclined to use wsimport to generate stubs. It means using JAXB. Please suggest.
Thanks.
I don't know that it's necessarily a best practice, but I definitely recommend using wsimport/JAXB generated stubs for consuming a SOAP service in the client. You could also use any number of other methods but they all boil down to two options:
1) have stub code generated that does all the XML and HTTP (or other protocol) work for me
2) concoct an XML message in a Java String and use various HTTP (or other protocols) methods to send that XML to the remote service. Then parse the result using some method (regex, custom parser, SAX, DOM, etc..)
In reality option 1 boils down to option 2, but you never see it.
My web service client application uses Apache CXF to generate client stubs for talking to several web services. The generated CXF web service stub objects have quite a large memory footprint (10 - 15 web service objects take more than 64 MB of memory). Is there any way to reduce the CXF object footprint?
We had similar problems with Axis. The problem we had was that we wanted to do many concurrent calls to the web service and the Axis clients generated using the WSDL caused each client to use a lot of memory. The clients arent thread safe, so we had to create one client per request.
We had two choices. First we could prune the generated code - but that was not nice for maintenance reasons.
Second, we simply pruned the WSDL to remove the parts that were not relevant to us, and regenerated slimmed down clients. That way, if we called one service method, it's client wouldn't contain bulk for unrelated methods which that thread wouldn't be using.
Worked quite well, but is still a maintenance nightmare, because any time the WSDL gets updated (e.g. our partner releases a new version of their web service), we need to spend time creating cut down wsdls. The ideal solution I guess would be to get our partner to recognise our problems and take ownership of the cut down WSDLs.
We took a different approach to the CXF client. I haven't looked into its memory footprint, which isn't an issue in our context, but it's certainly a simpler method of development than creating stubs. It looks something like this:
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
factory.setAddress(endpoint);
factory.getServiceFactory().setDataBinding(new AegisDatabinding());
factory.setServiceClass(myInterface.class);
Object client = factory.create();
((BindingProvider) client).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY, true);
myInterface stub = (myInterface)client;
We just do that (of course we've built some utility classes to simplify things further) for any WS we want to hook up to at runtime (provided, of course, we have its Java interface). Our goal was to make the whole WS thing as transparent to the programmers as possible. We really have no interest in WSDLs and XSDs per se. We suspect that we're not alone.
If your SOAP needs are very basic, you could look into kSOAP2 which is really memory efficient. It is designed to run fine in a J2ME phone application.
I've just finished reading about SOAP via Spring-WS in "Spring in Action", 2nd edition, by Craig Walls from Manning Publications Co. They write about Contract First, much like the Spring docs, with making a message and method XML and then transforming that to XSD and then again to WSDL, while wiring up the marshalling and service path in Spring.
I must admit, I'm not convinced. Why is this a better path than, let's say, making a service interface and generating my service based on that interface? That's quite close to defining my REST #Controllers in Spring3. Do I have options of going a path like this with making SOAP webservices with Spring?
Also: I'd like to duplicate an already existing webservice. I have its WSDL and I can have my service placed instead of it. Is this recommended at all? If so, what's the recommended approach?
Cheers
Nik
I think you must have your wires crossed.
Contract first means defining a WSDL, and then creating Java code to support this WSDL.
Contract last means creating your Java code, and generating a WSDL later.
The danger with contract last is if your WSDL is automatically generated from your Java code, and you refactor your Java code, this causes your WSDL to change.
Spring-WS only supports contract first
2.3.1. Fragility
As mentioned earlier, the
contract-last development style
results in your web service contract
(WSDL and your XSD) being generated
from your Java contract (usually an
interface). If you are using this
approach, you will have no guarantee
that the contract stays constant over
time. Each time you change your Java
contract and redeploy it, there might
be subsequent changes to the web
service contract.
Aditionally, not all SOAP stacks
generate the same web service contract
from a Java contract. This means
changing your current SOAP stack for a
different one (for whatever reason),
might also change your web service
contract.
When a web service contract changes,
users of the contract will have to be
instructed to obtain the new contract
and potentially change their code to
accommodate for any changes in the
contract.
In order for a contract to be useful,
it must remain constant for as long as
possible. If a contract changes, you
will have to contact all of the users
of your service, and instruct them to
get the new version of the contract.
Toolkit's point about Java interfaces being more brittle is correct, but I think there's more.
Just like there's an object-relational impedance mismatch, there's also an object-XML mismatch. The Spring web service docs do a fine job of explaining how collections and the rest can make generating an XML document from a Java or .NET class problematic.
If you take the Spring approach and start with a schema you'll be better off. It'll be more stable, and it'll allow "duck typing". Clients can ignore elements that they don't need, so you can change the schema by adding new elements without affecting them.