Hi all, I like the current path that this group is following about SOA and I would like to comment one of the principles laid out by JP Morgenthal that is related to versioning. He says that a SOA should be "Versioned - multiple versions of the same service should be able to co-exist to maintain backward compatibility in a changing environment".
Well, I think there are some fundamental questions to be answered related to versioning and change management in a SOA. - Are all services immutable? - What do we want to version, the service interface or the service implementation? - What does software version numbers really mean? First of all, are we talking about immutable service interfaces here? Does it mean to us that once a service interface is defined, it never changes, only the implementation or the location of the service can change? Will a new version of an existing service always result in a new service? Does some key identifier of the service includes the version number? Well, if your answer to the 3 questions above is yes, this approach works in practice, it is well possible to have several versions of a single service running at the same time. But this approach is also extremely expensive, it might result in service consumers using different views of the same service (different stubs or proxys) and might result in maintaining different service implementations on the server side. Not really an ideal world of reuse where several deprecated versions of a single service must be kept alive because of an installed base of consumers using it! Of course, there are more dynamic techniques allowing a client to be much more independent of a particular service version. But how do we know if a service consumer is using these techniques or not? There are also implementation strategies on the server side allowing different service versions invocations to be transformed and routed to a single service implementation. But do we really want to manage this overhead of transformation and routing? I have faced this problem myself and I want to share my experience here. I think that if we do not make a difference between changes that are backward compatible and changes that are not, we cannot have an efficient change management in a SOA or in composite applications in general. I have a range of blogs about this problem here: http://blogs.ittoolbox.com/eai/applications/ What is your own experience with change management in SOA? What are the best practices? Thanks for your feed-back. Robin --- In [email protected], "JP Morgenthal" <[EMAIL PROTECTED]> wrote: > > > Here's what I propose: > > A) Loose-coupling - every service is atomic, self-describing, > accessible, declarative, stateless and composite > B) Contracted - All services in an SOA are represented by a contract > that describes its inputs, outputs, access policies, QoS requirements and > error handling procedures > C) Manageable - all services can be individually managed or managed > as a group > D) Versioned - multiple versions of the same service should be able > to co-exist to maintain backward compatibility in a changing environment > E) Discoverable - services should be able to be discoverable at time > of execution. > F) Addressable - A service should be able to be uniquely identified > in a network > G) Distributed - Services in an SOA are separated by geographic and > machine boundaries and, therefore, must be good netizen applications. That > is, they must be developed with the ability to recover from loss of > communications. > H) Point-to-Point - At any point in time one consumer uses one and > only one producer > > ------------------------------------ > Avorcor, Inc. > JP Morgenthal ------------------------ Yahoo! Groups Sponsor --------------------~--> Most low income households are not online. Help bridge the digital divide today! http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> 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/
