Re: [service-orientated-architecture] SOA Versioning Issues and Issues around mgmt. of multiple versions of same service.

[Todd Biske]

Hey Prashant, nice to hear from you again.  Here's my thoughts on versioning: 1) If you don't have identity on your messages (regardless of whether or not you actually perform authorization or authentication), get that fixed first.  Any versioning strategy will require some form of identity.  Give some serious thought to how you want to represent identity, because the specs are all user focused, while versioning might be based on application ids or location (all users at one location).   2) Strive to make your interface changes backwards compatible.  It may require applying an XSLT transform to incoming requests and outgoing responses, but at least existing consumers will only need a regression test. 3) If they're not backwards compatible, treat the new interface as a new service.  Odds are,  all existing consumers will not move in lock step, so you'll need to have multiple versions in production.  Most app servers I've used don't have a good way of doing this except by viewing each service independently, which will mean two URIs.  Be very careful with this, because it could have implications all the way back to the source code.   4) Consider whether or not you want clients to have the ability to explicitly request a particular version, in addition to having policies in the routing infrastructure that govern it implicitly.   5) For backwards compatibility, make sure you've got someone who understands how to version XML schemas appropriately.  There are a number of web pages that provide info on this.  6) Every consumer should have its own contract with the service provider, especially for the reasons you outline.  By taking a contract-based approach, and utilizing infrastructure that can separate contract from implementation (e.g. WSDL manipulation based upon consumer identity), you should be able to achieve what you need without having an implementation of the service for every consumer. As for how many versions to support, that will be directly dependent on how frequently you do releases of the service, and how responsive the consumers are to upgrading.  You've got to put a cap on it, otherwise the consumers won't be to upgrade, and the service provider will struggle to manage all of the versions.  This ties right into a question I asked a couple of weeks ago about what it means to be a service provider.  These are all issues that an internal development group must now face.  Versioning user-facing applications isn't as big of a deal, because humans are far more tolerant to change.   Hope this helps- -tb On Apr 6, 2006, at 9:04 AM, Sarode, Prashant wrote: Hi, I am trying to gather some intelligence around Versioning Problems in conjunction to SOA. In particular our SOA road is primarily based on Web Services and interested to know how people are solving the Versioning problem today.   In terms of Versioning of Service I have several questions in mind. Most organization start small on their SOA journey with some initial pilot services. But soon these small services gain popularity and now come the Versioning Issues. -Some clients want old API of service but new clients want tweak to the same API. -Some clients want altogether new/additional API to the service. -Some clients are interested few New API’s but few old ones to. -Some clients would want same API but would want to come over SSL secure rpc binding while others want non-secure doc lit binding. Also, there are some -How to relay the new version availability? -How many Endpoints to support for more or less same business service? -How to manage-monitor multiple end points for different versions?   What are some of the best practices around Versioning? How are people solving it today and what are the lessons learned for future?   Prashant Sarode Director SOA-Web Services Investors Bank & Trust Co. Boston www.ibtco.com   ************************************************************************** This message and any attached documents contain information which may be confidential, subject to privilege or exempt from disclosure under applicable law. These materials are solely for the use of the intended recipient. If you are not the intended recipient of this transmission, you are hereby notified that any distribution, disclosure, printing, copying, storage, modification or the taking of any action in reliance upon this transmission is strictly prohibited. Delivery of this message to any person other than the intended recipient shall not compromise or waive such confidentiality, privilege or exemption from disclosure as to this communication. If you have received this communication in error, please notify the sender immediately and delete this message from your system. ***************************************************************************** SPONSORED LINKS Computer software Computer aided design software Computer job Soa Service-oriented architecture YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. SPONSORED LINKS Computer software Computer aided design software Computer job Soa Service-oriented architecture YAHOO! GROUPS LINKS  Visit your group "service-orientated-architecture" on the web.    To unsubscribe from this group, send an email to:  [EMAIL PROTECTED]    Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.