Versioning

[jmfaerman]

Does switchyard provides any feature for versioning services?

I would like to run some versions of the same service at the same time, until they get old enough to be deprecated.

Are there any references on how to do that using switchyard?

[kcbabo]

Hey Julio,

Versioning is an important aspect of service lifecycle management and I expect our support for it to evolve over time.  I can explain what we support now and what's coming soon.  It would be great if you could let us know if you see gaps in our approach or other features that would be interesting to add.

Right now, you can have multiple implementations of a service registered inside of SwitchYard core.  This means that you could have multiple implementations of a service deployed and running alongside one another.  When it comes time to retire the old service implementation, you can undeploy the old service implementation and the new service implementation will still be there to handle requests.  Another versioning strategy we plan on supporting is the ability to encapsulate applications (and the services they provide and consume) inside of service domains.  Among other things, these domains will allow you to provide separate service namespaces for applications, which is useful when an alternative service implementation is required which is not backward compatible with the existing service implementation.

What we don't have (at the moment, at least) is the ability for users to introduce logic which directs routing based on service version.  One possible use for this is to route a message to a specific version of the service based on content of the message or possibly runtime metadata (e.g. one service has been marked as 'retired'). 

BTW, I took the opportunity to review our current routing implementation and found a bug related to multiple service implementations (SWITCHYARD-357), so thanks for asking the question!

cheers,

keith

[jmfaerman]

Thanks for the attention Keith.

Versioning is a very commom problem, so it got me wondering when i was reading about SwitchYard. But i just started playing  with it, i hope i can contribute in time.

[yusufb]

Hi Keith,

I agree that versioning is an absolutely critical component of a SOA. Has the support for versioning in SwitchYard improved since your previous post (21-07-2011)? What is the current status of versioning facilities in SwitchYard? I cannot find any documentation regarding versioning on SwitchYard. Could you perhaps point me in the right direction?

In particular, for a service that has a Java Interface and a Bean implementation:

1. Can you have multiple versions of the same interface (for example: with extra operations on one interface, or perhaps modified operation parameters)?
2. Can there be multiple implementations of the same interface?

Thanks!

Yusuf

[jmfaerman]

Yusuf,

If you sort this out, pls post back

My best shot so far is having completely separated endpoints (v1.api.mycompany.com, v2.api.mycompany.com,...) and let everyone else (switchyard, jax-rs, jax-ws, ejbs, etc) care not about versioning.

[kcbabo]

Hey Yusuf,

Yes, there has been progress since my original post, although there is still more to be done.  The ability to query for implementations of a service was added in SWITCHYARD-1000, so if you have multiple service providers (e.g. different versions) you can introduce logic to select a specific one (e.g. payload corresponds to a specific version of the service).  The underlying support for service domains is also there, but we do not expose the ability to create individual service domains and associate them with one or more applications today.  This is on the plan before we get to SY 1.0. 

In particular, for a service that has a Java Interface and a Bean implementation

1. Can you have multiple versions of the same interface (for example: with extra operations on one interface, or perhaps modified operation parameters)?
2. Can there be multiple implementations of the same interface?

You can't have multiple versions of an interface definition for the same service instance.  You can either change the name of the service or (eventually) deploy another instance with the new interface inside a different service domain.  There was a discussion a few months back in this forum about applying something similar to transformers to contract definitions.  It's an interesting idea that would allow you to provide a contract adapter which would keep the original interface the same but could account for any changes based on version change or incompatible consumer contracts by adapting the provider's contract.

Yes, you can have multiple implementations of the same interface.  All interface types (Java, WSDL, ESB) are parsed into our generic contract model at deployment time.

hth,

keith