Thanks for a detailed reply. It was nice to validate some of the thinking I was doing (especially around the points 3 & 4).
On point#1 COuld you eloborate a little bit more? I did not get the issue you were trying to highlight. On point#6--Are you going towards a contract mgmt infrastructure (under umbrella of WS Mgmt. infrastructure)? On point#4--What are some of the patterns for WS-Clients to request specific versions of a service? Again are you suggesting going towards version mgmt infrastructure which routes requests based on client requests? Prashant Sarode --- In [email protected], Todd Biske <[EMAIL PROTECTED]> wrote: > > 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. > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
