Chris, You could still implement common endpoint pretty much the "XML Interface way" that you just explained.
<quote> For our XML interface, we actually look up a "version" field up front with XPath and then shunt the Document off to the correct handler for the version, which means every client of every version comes through the same URL. <unquote> If I understand the above, you are providing a POX (Plain old XML) service (i.e. endpoint accepting any XML payload - not necessarily wrapped inside SOAP envelope), and then are applying router logic to route-to (i.e. invoke) the correct service interface (based on the version). In this case you are not "binding" your XML data to any POJO/Java structure until it reaches the final (correct version) endpoint. If you go vanilla approach of JAX-WS/JAXB binding then you are asking CXF/stack to 'binding' the XML to an object model before it comes to you interface and hence it gets tricky. However, You can still do it XML/XPath (lookup to determine which interface to invoke) with CXF by using Provider API (which gives you access to the direct payload and then you proceed to interrogate the version and route to the correct interface). -----Original Message----- From: Kessel, Christopher [mailto:[email protected]] Sent: Monday, November 09, 2009 2:52 PM To: [email protected] Subject: RE: Pointer to a strategy on interface versioning? I appreciate the help from you an Manoj. I'm used to straight XML interfaces, but new to SOAP more or less and indeed I think I'm going to have to separate Endpoints at slightly different URL locations. For our XML interface, we actually look up a "version" field up front with XPath and then shunt the Document off to the correct handler for the version, which means every client of every version comes through the same URL. That's why I asked about having different versions come through the same URL for SOAP (with CXF). It looks like that'll be problematic though, so I'll go the route of a http://host/v11 and http://host/v10 type scheme. Not a big deal, though I'll have to distill the "why" into layman speak when I get asked why it differs from how we expose our XML interface :) Thanks, Chris -----Original Message----- From: Rao, Sameer V [mailto:[email protected]] Sent: Monday, November 09, 2009 12:09 PM To: [email protected] Subject: RE: Pointer to a strategy on interface versioning? Hi Chris, >> The problem is, how do I support both the v1.0 and v1.1 interfaces at the same endpoint? Since data structures (XSD elements) are backwards compatible, how are you differentiating between these two version? Rather do you want to differentiate between your 1.0 consumer and 1.1 consumer? If not then the 1.1 WebService interface & JAXB objects should suffice all your consumer. However, if you still want to return limited data (i.e. 1.0 data) to 1.0 version consumer then its best to have a separate endpoint within the same WAR and support the versions. If it's ok for all your consumer (1.0 and 1.1) to get the 1.1 data then just have one interface. There might not be special multi-version support in your case. Would this meet you needs? Cheers! Sameer -----Original Message----- From: Kessel, Christopher [mailto:[email protected]] Sent: Monday, November 09, 2009 11:41 AM 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
