ObjectSharp Blogs

You are currently viewing

Bruce Johnson's SOA(P) Box

: 

Using SOA in the .NET world


Home > Blogs > bruce

Versions in Services

Posted: Thursday, July 01, 2004 11:18 PM by bruce
Filed under: ,

One of my colleagues, John Lam, has been starting down the services road lately. We were kicking around some of the problems that can be encountered by SOA developers and John made an interesting comment. He said that the problems we were discussing had already been solved...in COM/DCOM.

This made me sit up and think. I'd been wrestling with how to best deal with versioning in services for while now. So I ask him. How does COM handle versions? The answer I got surprised me. It doesn't. Coming from Chapter 3 of Essential COM (thank you Mr. Box), COM interfaces are frequently given a different CLSID. This allows "clients to indicate explicitly which version is required." Even if the new COM interface is an extension of the old one. In fact, there is a function (CoTreatAsClass) whose purpose is to route instantiation requests from the old CLSID to the new one.

In other words, there is no real 'versioning' in COM. Each version is a class unto itself. It just happens to have the same interface or an extension of same.

So let's apply this to SOA. In the .NET world, an interface is roughly the equivalent of an ASMX file. So to create a different version of a service, create a different ASMX file, copying/changing/adding the web methods as needed.

The real challenge is ensuring that the second tenet of service orientation (services are autonomous, something I've blogged about here and here) is adhered to. Each 'version' service must have a certain level of autonomy over the underlying data. It is important (actually, critical) to eliminate any 'side effects'when designing the different versions . If a client executing the new version of the service causes the old version of the service to break in any way, shape or form, then autonomy is violated and you will have trouble on your hands.

So there you have it. No versions of services. Instead, just create a new service that implements the modified interface. If nothing else, this is a good reason to implement the web service class itself using the Facade design pattern, thus keeping the content of the class to a minimum.

Comments

  • bruce July 2, 2004 8:48 AM

    It's also been solved in .NET at the assembly level with binding policy (via fusion) - but that's real versioning support.

  • bruce July 2, 2004 11:26 AM

    Actually, if I'm not mistake, all binding policy provides is an assertion of compatibility between different versions of the 'same' assembly. I put 'same' in quotes because the assemblies are really different since the CLR uses the version information as part of the unique identifier for an assembly. Binding policy is typically used to upgrade an assembly from one version to another. Although the CLR does allow for side-by-side deployment, that is not typically the situation. Usually only one version of the assembly is loaded at a time.

    That having been said, there is not nearly as much difference between the two situations as you might imagine. If the different versions of the assembly can be loaded simultaneously, they have to adhere to the same autonomy rule that services do. So in that case, assemblies follow the same rule of versioning that COM and services do. That is that versioning is really only an illusion.

Leave a Comment

(required) 
(optional)
(required) 

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Recent Posts

Tag Cloud

Connections

ObjectSharp Blogs

Other Blogs I Read

Profiles

Recent Articles