SOAPAction if you explore can help you. For existing service SOAPAction="http://xxx.com/v10/ops"; or "" For new service SOAPAction=http://xxx.com/v11/ops Now you may need some proxy service which can filter based on soapaction where to rout the message synchronously. This proxy service can have same url as current.
This proxy service can be achieved by any modern open esb tool by just few configurations or you can write your own little filtering logic. Existing client may hit with existing soapAction and new client will send with SOAPAction=http://xxx.com/v11/ops to same url. Manoj -----Original Message----- From: Kessel, Christopher [mailto:[email protected]] Sent: Monday, November 09, 2009 12:41 PM To: [email protected] Subject: Pointer to a strategy on interface versioning? Is there documentation available on good strategies for versioning an endpoint published via CXF? We've got version 1.0 and are rolling a v1.1 that has a slightly enhanced version of the previous interface. The input/output objects have been updated, but backwards compatible with the v1.0 defined interface. The problem is, how do I support both the v1.0 and v1.1 interfaces at the same endpoint? Well, let me rephrase that, I want to keep the same URL for customers to send their SOAP requests through whether they're v1.0 or v1.1 customers. Essentially, this should be an invisible change to v1.0 customers since our implementation objects are backwards compatible. v1.1 customers would get an updated WSDL that shows the new fields available in the v1.1 input/output. Does that description make any sense? Is it possible or will I need to publish a new URL for v1.1 customers? Thanks, Chris
