Hi. Some thoughts. Assuming that you are looking to implement web service versioning ...
With current technologies, I don't know if this is good practice, or if it a good standards-based way to go about it, unless you are restricted to use some older versions of web service implementations (that do not support JAX-WS for example). Also, in case you use an ESB, the ESB itself should support versioning via configuration and it might be an easier route for you.
Here is a good article on versioning, the concepts. This is my understanding of your situation:
1. You already have an existing service with some operations, say operation1 and operation2
2. Now, you have updates to your operations: operation1V2 and operation2V2
Is the above correct? Probably not So please add to it if you like. I am trying to understand:
1. what is the rationale for using a handler to achieve this. For example, if you are only adding operations to a WSDL, then you can add them to the same existing endpoint without affecting existing users.
2. why a new WSDL? Are there incompatible changes?
3. What technologies (like JAX-WS) and software (like Axis2 1.4) are you using?
Are any of the data structures (request/response XML) changing? Any operations being removed? The above article has a list of changes that are backward-compatible, and those that are not compatible. Which of them apply to you? I guess the answer depends a lot on that.
For example, if you have an existing web service OrderService with one operation placeOrder, and you have a new version placeOrderV2 then you can always just add the new method to the existing WSDL in the same namespace, and the WS consumer can call placeOrderV2. Is this not an option for you?
I have a feeling that I may have completely misunderstood your problem. If yes, then please explain your context a little more.
Joined: May 28, 2010
Thanks for the reply. The article on versioning is excellent and covers almost all aspects of web service versioning. And i am trying to implement the same ( probably i should have posted with right heading :-) ) .
My situation as you understood is right, i have an existing web service with multiple operations and i am trying to update one of those operations.
To start with our existing web service are written using axis 1.2 and the reasons for writing a new wsdl are as follows.
1. Few of the new fields we are trying to add in an operation are mandatory, so we cannot update the operation as it will impact existing customers. ( i know if we make all fields optional it will solve the issue easily, but the business requires few of them as mandatory )
2. As you said we could have added a new operation, i went through this option as well. But the issue is the change is in a complex type which is shared by multiple operations.
Now, this part is in Common.xsd ( included in other xsd's ) which is used by multiple operations. One option could be i can create a new complex type ( lets say AccountInfo_v1).. but i guess this would not be feasible option as if in future i get more similar changes .. it will be difficult to maintain and document all those new fields.
So we created a new wsdl with a new namespace without changing the element names and having them mandatory, which of course resolved the issue ( so that existing clients can continue with the old services and all the new clients can implement new wsdl)
But now i have a new endpoint url. <NewService>_V1... that's where Handler part came in :-) .. i am not sure if this can be done. All i am trying to do is have just one endpoint url for all ( existing and new clients ) .
Also, i have a question in the article posted .. under heading ( Versioning by URL )
. Here the end point is changed, not the service name. But in the wsdd file, if you have two entries with same service name , it will just consider the last entry, right ? ( probably not with RAD ? )
Hope i am clear enough about the issue and Thanks Again for all your help.
Joined: Feb 19, 2010
Hi Suri, You might have been able to use the existing endpoint if the schema had originally been designed to anticipate such changes, but it is very hard to anticipate this kind of thing. So here are some thoughts/points:
- A WSDL document can have multiple (0 or more) services in it as you can tell by the "*" at the end of the wsdl:service element.
- So I think that both versions can be aggregated into a single WSDL, but you might still need another service. The new service's clients can call the new service off of the same WSDL, but it would be a different endpoint (port type) inside a different service.
- You have some data structure changes (in Common.xsd), and these are not backward compatible. So you will still need a AccountInfoV2 (you could keep this in the same Common.xsd though), but you can reuse the existing schema xsds wherever possible - just import/include the same xsds for the V2 schema.
- In any case, I don't know if giving your clients a single endpoint makes any difference to the clients. They will develop using whatever you give them. However, you on the other hand, will have more complicated code to maintain. So I would say make it easier on yourself have two services/endpoints, and try to reuse code/methods from the existing service wherever possible.
Here the end point is changed, not the service name. But in the wsdd file, if you have two entries with same service name , it will just consider the last entry, right ?
You may be correct if the services are exactly the same/duplicate. However ... and this is my opinion ... I am not 100% sure if its technically accurate ... the service name is qualified by the URL. So if any part of the URL changes (BigBank vs BigBank1), that means that the service name is also different. So http://bigbank.com/BigBank/services/AccountService and http://bigbank.com/BigBank1/services/AccountService would really be considered as different services I would say. This is like com.mypkg.Order and com.anotherpkg.Order - they fall under different namespaces, and therefore, are different.
Hope that helps your analysis somewhat.
Joined: May 28, 2010
You are right, these things needs to be anticipated at the time of desigining itself. Anyhow through all these analysis on versioning, i got to learn little more on webservices .
If i have to maintain 2 different endpoints, i better have two wsdls ( atleast i can keep it more organised code wise ) .
just out of curiosity, is there any other way we can have one single endpoint .. transport handler ..or if not handler .. any other way ?
Joined: Feb 19, 2010
Hi Suri. I very much doubt if that is possible in your case, but maybe someone with more experience in this can correct me. Here is my thinking:
- Lets say your existing WSDL has a type CheckingAccountBalanceRequest (with the existing AccountInfo type inside it) as the message input for getAccountBalance. In order to use the same endpoint, the client has to pass an XML that is compatible with the CheckingAccountBalanceRequest type. But the new client cannot do this since the new AccountInfoV2 type breaks from the structure. Since the data structure has changed, the request would fail inside the XML parser library while unmarshalling the XML to an Object, long before it even gets to your code where you could do something with it.
- On the other hand, if the getAccountBalance method accepted a generic XML without any structure/type limitations, then you could cast the object into your desired type. But I am guessing that this may not be the case for you.
- Having said all that, I am thinking that it must still be possible to mess around with the generated (using WSDL2Java for example) code to somehow make it work. But that would be a pain to do, and then maintain.
Have you considered the following approach?
- Retain the old and the new service as two separate services.
- Develop a facade web service which endpoint implementation class implements javax.xml.ws.Provider<T>.
This facade service will inspect incoming requests and, based on, for instance, the XML namespace used, forward the requests to the appropriate version of the service that is to process the request.
Naturally this increases the complexity and introduces a certain overhead, but it may be acceptable to you.