how to version jax-ws web services - web-services

is there any best practice to version every release of my jax-ws based web services build ? I have seen a few ways to version REST based services (for example to include the version information in URL etc.) Is there any other different way of versioning JAX-WS based web services. .

To version my services, I use a different targetNamespace.
For instance, I add the annotation to my interface :
#WebService(name = "YourService", targetNamespace = "http://whatever/you/want/VersionNumber")
Running wsgen you will end up with a different targetNamespace in you xsd. All old clients won't be able to use your webservice, with a clean, "fail fast" error.
However, as this is quite annoying, I only update this version when the signature of the service has changed, to prevent from wierd, hard to debug, errors

Related

WS-SecurityPolicy configuration of CXF client

The question: Can CXF automatically configure WS-Security for a client based on a WS-SecurityPolicy file?
If so, is there any documentation on actually doing so? I've spent several hours looking at the CXF site and doing searches without finding an answer.
The CXF documentation says "CXF 2.2 introduced support for using WS-SecurityPolicy to configure WSS4J instead of the custom configuration documented on the WS-Security page", and also says "In CXF 2.2, if the cxf-rt-ws-policy and cxf-rt-ws-security modules are available on the classpath, the WS-SecurityPolicy stuff is automatically enabled." Finally, there's a listing of the properties that may need to be configured (keystore locations, etc). All of that I understand, but the documentation doesn't actually explain what enabling WS-SecurityPolicy does. Is it just for policy generation, or does it actually help configure clients?
The reason I'm asking is that I'm working on an application that uses CXF (JAX-WS front end) via Camel to consume a SOAP service secured with WS-Security. Because of the existing structure of our application, I've been trying to configure the client with WSS4J interceptors, but have been having a tough time actually implementing what they've described.
After a couple of days working on this, the provider mentioned that they had a WS-SecurityPolicy file they could send to me (why they didn't mention this up front is a mystery). Now that I have their policy, I'd really like to figure out a less code-driven way of configuring the security.
Having a WS-SecurityPolicy configures "most" of the security requirements for a client. You still need to specify JAX-WS properties to configure users, passwords, keys etc. I would recommend checking out the CXF source and looking at the systests/ws-security-examples tests.

Is it mandatory to have a WSDL definition accessible using ?wsdl?

Is it mandated by any standard that a web service should provide a WSDL by appending ?wsdl to the endpoint address?
Is it OK if the WSDL is hosted at a different URL (without appending ?wsdl)?
For example:
Endpoint: http://abc.xyz.com/MyService
WSDL: http://abc.xyz.com/MyServiceDefinition.pqr
Note that I'm even using a different extension for the WSDL definition.
Does using this approach violate any standards or one can host the thing the way they want?
Is it mandatory to have a WSDL definition accessible using ?wsdl?
No, it's not.
A WSDL is used to describe a web service contract and is provided because it allows tools to automate generation of client stub code for calling the specified web service. Exposing the WSDL at the same location as the web service with ?wsdl appended to it is just very handy and that's the convention everybody uses.
People and tools look for the WSDL at that location and frameworks automatically expose it at that location but it's just a convention. As to my knowledge this isn't specified in any specification (or at least none that I could find).
Sometimes though you don't want to provide a WSDL that everybody can look at and try to create a client because it's a private web service and you only want to give access to your partners, not to everybody. At that point you can disallow the ?wsdl URL and provide the WSDL only to your partners by using an alternative channel. You can even e-mail it if you don't want it exposed online.
So you can choose whatever channel to expose it. Just remember that because people and tools are following this convention they are used to see it there and some (poorly written) tools might choke in a different extension, for example.
P.S. One other thing I wanted to mention - which isn't strictly related to this answer but kinda reinforces the convention - is the new ?singleWsdl option in WCF 4.5.
WCF, as most other tools, exposes the WSDL at the ?wsdl address but uses xsd:import statements with external schemas. Some frameworks were not able to process WSDL with imported dependencies so people started to write customizations over WCF to have a flat WSDL exposed, so much so that in the latest version of WCF Microsoft decided to add this feature out of the box.
But for backward compatibility they needed to keep the ?wsdl endpoint as it was (returning a WSDL document with xsd:import statements inside) and were forced to add a new query parameter for the flat WSDL: ?singleWsdl. I'm sure this idea will be picked up by other web service vendors and providers as well.
No, Its not mandatory to have ?wsdl access, but its recommended way.
Its worth noting that most clients will try to append "?wsdl" to your URL and will try to access WSDL file, Hence its highly recommended to setup it.

How to implement backward compatible soap webservice (java based)?

One of our product publishes a webservice using contract-last approach. This has becoming a real problem as all of our clients (ws clients) have to rebuild their client apps as soon as we release a new version of our product. This is due to all namespace changes that comes as a cost with auto-generated wsdls. We use Axis1 for javatowsdl. I've been seeking for a good methodology/ tool to develop backward compatible webservice for this.
i.e. version 9.3 clients can still hit the 10.0 service, of cause they will miss some of the functionality, that is fine. But they should be able to function without breaking.
I do understand the whole problem is due to our contract last approach (Pls. correct me if I'm wrong). Therefore, if the solution is to go for contract-first webservice what are the tools and technologies I could use? Also what are the best practises around contract-first?
Thanks in advance.
As you already realized, the recommendation is to use a Contract-First (or Top-Down) approach to develop Web Services. That implies a manual definition of your WSDL interface and generate a Java Skeleton of the Web Service based on this document using automatic tools.
Is important that your WSDL complies to the WS-I standart to assure interoperability between clients on different platforms. You can use SOAP-UI to test whether your WSDL is compatible with the standard or not.
For the Skeleton generation, there are several Web Service Runtime API's that you can use: Like Apache Axis and JAX-WS. I personally prefer JAX-WS because is a Java Standard and is supported by all Java EE Containers. Each container provides tools for the Skeleton generation, Weblogic has some nice Ant Task for that but there's also WS-Import that is Container neutral.

is there a hosted web app I can use to test WS-I BP1 soap compliance?

I have a url that has a wsdl from a vendor and would like to run a hosted tool and just forward him the results.
Does such a webtool exist where I can just type in the url of the wsdl? (or do really have to download soapui or other stuff to do something like this...yuck).
Looking for a quick way to test it out.
One way if you have .NET is to run the WSDL and any associated XML schemas through the svcutil.exe program. It complains about many compliance violations. The older WSDL.EXE tool also will complain for many of them.
There are also tools to do this. I have used the SoapScope tool from Mindreef. They have been purchased by Progress Software, and it appears the tool may now be Actional Application Development.

Using Axis to generate a web service implementation that calls another web service

I need to provide an implementation of a web service for which I have the WSDL, to run under Weblogic 9.2.
I aim to use the Axis (1, not 2) tools for this , having tried and failed to make it work with thw weblogic web service generation tools (due to an inability to set the authentication - see my other question here),
This web service needs to make calls to another web service (for which I also have the WSDL).
I can use the Axis tools to generate the client stubs etc.
But how do I do the two in combination? Is there a tutorial or other step by step guide? I have googled and found some mailing list postings, but they're about specific issues.
If someone's done it, could they share the relevant parts of their build.xml for this?
If I used the weblogic web service generation tools, there's a tool that in one go generates the skeleton implementation of the web service and the client stubs for the web service it calls - is there something similar in Axis?
Any gotchas if I just try to mash up the skeleton and client generation output from WSDL2Java?
Update:
Got this to work.
Used the Eclipse tools to build the client, then the service, allowing the second to overwrite the duplicate files from the first. We then had some issues with the client_deploy.wsdd file (see my other question How do I refer to a client_deploy.wsdd file that's in WEB-INF?) and with jar versions (needed to update the jars that Axis uses to newer version), then it just worked.
Speaking for axis2, you can create the client stub like this (I reckon axis1 is not much different):
/wsdl2java.sh -uri webservice.wsdl -p com.your.client.package -d adb -s -o output_folder_client
Once you have the client package you should be able to use it in your own webservice implementation by just importing it, creating a client instance and submitting requests.