Web Services Versioning: Is ESB overkill?_问答_开发者

We have multiple versions of our web services (both REST and SOAP) in production, and the number keeps getting bigger with every release.

Between versions, there can be minor changes (usually additions of new fields) to requests and responses.

If we were to retire old versions, how could we continue to service requests for old versions?

One aspect of a possible solution involves creating "virtual endpoints" to route requests for previous versions to the new versions of the same services. Thus, requests for /v1/customer/1 maps to /v2/customer/1. We are using Mashery through which this can easily be done.

We also want to apply transformation rules on requ开发者_如何学Pythonests and responses to generate XML and JSON responses that conform to the old contracts.

To summarize, we have a need for both routing and transformation rules to be applied to all incoming messages and responses. Is an ESB overkill for this? Our criteria don't quite fit the criteria outlined in http://blogs.mulesoft.org/to-esb-or-not-to-esb/. Is there a simpler solution to this problem? One that doesn't require modifying our code to implement versioning of requests and responses?

If the tool fits...

If the ESB that you're looking at it going to give satisfy your versioning and transformation needs, then go ahead and use it.

What you don't want is "Oh, here's our ESB listening to our one endpoint for our one web service". That's simply insane.

Seems to me an ESB may well fit your needs quite well. You don't have to check off all of the boxes. In fact, the only box you need to check off is the "Is this tool worth the resources and time to learn, leverage, support and deploy in our environment vs working with something we're more comfortable with" box.

Because one problem with software like ESBs is that they can come with a lot of stuff, and thus a lot of documentation that can be difficult for a novice in the platform to wade through and pick what it appropriate, and how to configure it.

I'd grab an ESB and do a pilot, and then do some performance tests. If you don't burn a huge amount of time on the pilot, and it seems to work out, then roll with it.

There are some companies like IBM who build software specifically for your use case. They basically have a service registry server. The service registry acts as your alias for all your services. More importantly, most service registry servers have a workflow that people use to promote, demote, sunset, version, notify users of the service that something has changed. Most people call the workflow... governance.

Try the UltraESB [http://adroitlogic.org] which shows many examples on how routing and transformations can be performed. You can also use the benchmark at http://esbperformance.org to load test any ESB to see how fast they perform on routing, transformations etc. It is a small (~35MB) ESB that does not require code changes or has a steep learning curve - as you write your routing rules as a couple of Java lines, or even Javascript, Ruby, Groovy etc - whatever JSR 223 scripting language you are aware of.

ESB might be overkill for this solution. Though we might deprecate the old version, and have new versions, what will happen to the client programs that still seek to use the old version of the service.

If we changed the request/response format in the new version of the service, then the clients trying to send old request formats and expect old response formats will fail. So we cannot and should not take the old service version off-line all the sudden, but phase it out. For that, we need both old and new services running in parallel, at least for some time.

So introduction of an ESB will not solve the problem. When we actually retire the old service, after some time that allows clients using old to migrate to new, then we can re-direct the old URLs to new. However, we do not need an ESB to do that, as a simple solution like httpd mod_proxy or nginx can do the job.

An ESB is really useful for value adding mediation of messages between clients and actual endpoints. So no matter there are so many performing ESBs out there, you should keep it to the simple and smart solution for this case.