Monday, February 24, 2014

Proxy Service Version Management with WSO2 ESB

Versioning of proxy services in an SOA environment is a common requirement. Versioning is required when you want to add / update or change the functionality of a proxy service without affecting the existing consumers of that proxy service. 




















Above diagram shows a typical versioning scenario. If the change in Service X 2.0 is compatible with Service X 1.0, then we can simply point to service X version 2.0 and consumers will not be affected by the change. However, if the change is in compatible, then we will have to introduce a new proxy service version.

General Principles of versioning

1. Client should not be forced to use the new version immediately
  • Gradual client migration
  • Retire services gracefully
2. Support multiple versions concurrently 
  • Limit the number of versions though governance
  • Only the latest version is discover-able

Solution 1. 

Create two versions of the proxy service. Consumer A can access the version 1.0 of the service and Consumer B can access version 2.0 of the service. Gradually migrate Consumer A to proxy service version 2.0. This way, consumer A can live with version 1.0 and plan for upgrading to version 2.0. Both versions of the proxy service will exist till version 1.0 is deprecated.
























Versioning with WSO2 ESB


Easiest way to version proxy services is to create a new version of the proxy service and related artifacts by appending the version information to the proxy service name. It is best to add version information to artifacts as a best practice. 

For example consider we have to  proxy a web service named StockQuote. Then we can name the proxy service as StockQuoteProxyV1. All artifacts contained with the proxy service should also be named accordingly. For example out endpoint pointing to the StockQuote service can be named as StockQuoteEndpointV1. 

Now creating and deploying new version of the proxy service becomes a simple task. We just need to update all the related artifacts with the new version number.


Future Improvements

Another approach to implementing proxy service versioning by having version as an attribute has been tried in the parent synapse project and there is a GSOC project on the same topic. These improvements are planed for future releases of WSO2 ESB.

References. 

9 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete
  6. if I have an API that calls 10 sequences I will have to duplicate everything? Is not there a better solution?

    I think it would be ideal to version the CAR and automatically already version the artifacts giving no problem of duplicity

    ReplyDelete
  7. Hello sir. i have read so many blog on this same topic. but yours is little different, with easily understandable lines. I have a same blog on this same topic also. You can check mine. You can suggest me if any changes required.

    ReplyDelete
  8. I have gone through your entire blog. When I started to read it, I just went on and on.
    Wonderful blog. I love this. Thanks. Hopefully, you keep on producing more such blogs.
    https://www.proxyrotator.com/

    ReplyDelete