Service versioning clarification

[objectiser]

From a governance perspective, is it fair to assume that if a new version of a service is being deployed along side an existing version of the same service, but with different (enhanced) behaviour, that it will be deployed to a different distinct endpoint?

[jervisliu]

From a governance perspective, is it fair to assume that if a new version of a service is being deployed along side an existing version of the same service, but with different (enhanced) behaviour, that it will be deployed to a different distinct endpoint?

Not necessarily. Actually most ESB/SOA products offer versioning support. For example, this can be done through a proxy or gateway: Clients send requests to the service endpoint unaware of any endpoint changes (like the change of endpoing address, service contract etc). The proxy/gateway redirects the request to different versions of services accroding to some user defined rules for example, based on an optional HTTP header.

[objectiser]

Good point - although I think even using this approach could still result in two distinct endpoints for each service version.

For example, say we have a StockBroker service (initially version 1) at endpoint X. Then we want to deploy a new version of this service that has incompatilble behaviour - so would impact users of version 1.

We could deploy version 2 to endpoint Y, move version 1 to endpoint Z, and introduce a gateway at endpoint X that acts in the way you have described.

From a process governance perspective, we are then able to monitor each service version by monitoring endpoints Y and Z, instead of the previous endpoint X.

Alternatively, if the intelligence or necessary information is in the registry, then the registry can be updated to reference endpoints Y or Z, instead of X.

So at some level I think we can assume that there will be a distinct endpoint per version.

I think the only problem would occur if the service implementation at the single endpoint was updated to internally cater for multiple service versions. This would also be the case for BPEL process engines, that determine the process description to use when the initial interaction occurs, so a single BPEL endpoint in theory could be managing multiple versions of the same process over time.

Maybe the monitoring approach should be configurable based on the type of service it is managing - so for non-process engine based services, it would be configured to monitor against a specific behavour. For process engine based endpoints, it will operate in the same way as the BPEL engine - new sessions will monitor against the latest process description - but existing sessions will continue to monitor against the process description that was current when that particular sesison started.

One thing will be key though - the descriptions that are being used to monitor a service need to be updated in sync with the deployment of the new services, or the re-configuration of the endpoints.