Take the 2-minute tour ×

We have a legacy system with data stored in a SQL database. Several clients connects to this database using a web service. The web service expose a lot of "commands" to query the database and to "do" operations.

So far, so good.

However, new operations need to be added and the web service cannot be extended. We can add a new service that would implement the operations from the old one (somewhat easy) and add our own operations.

At the same time we want to enhance the performance of the web service by having multiple requests bundled as one request (the responses would come out as a bundle too).

One desirable outcome would be to isolate the application from the web service using programming interfaces and a somewhat generic messaging (or whatever) mechanism.

We are contemplating several ways to effectively support multiple clients: enterprise service bus, a request/response service layer, ORM with client/server architecture...

Has anyone been confronted to such issues and what did you end up with?

share|improve this question
add comment

1 Answer

up vote 8 down vote accepted

This is not an architecture problem. It's either a design problem or a management problem.

Why can you not add new operations to the web service? That is one of the principal benefits of having a web service. Adding a new operation is a guaranteed non-breaking change. So either there is some misguided policy explicitly preventing you from doing it (management problem), a technical barrier to doing it (e.g. no privileges to redeploy - different kind of management problem), or you've somehow managed to rev-lock your client applications (serious design problem).

The architecture is fine. There is nothing you need to change in order support this type of extensibility. If you can't make changes to the web service that's there, then wrap it with one that you can change and start using that one from now on.

Multiple requests are, again, a design issue. Specifically, it's a message design issue. You ordinarily do not attempt to architect your entire system so as to literally be sending multiple simultaneous requests. Instead, you design your web services around the "chunky interface" concept, as opposed to the RPC-style "chatty" interface.

Simply put, a chunky interface means that you expose coarse, user-level units of work as operations. Your service contracts should not look like "method calls", they should look like activities. For example, instead of having many different (chatty) operations to change a single customer's phone number, mailing address, e-mail address, etc., you design one (chunky) CustomerUpdateRequest contract that accepts a sequence of customers and performs all of the updates therein.

When you design your messages this way, you should never need to worry about something like bundling multiple requests, because it wouldn't make any logical sense to do so. You're not going to bundle a customer-update request with a shipping request because there is no reason for those requests to ever come in at exactly the same time.

I cannot see any practical purpose in attempting to "isolate the application from the web service" - the web service is your isolation, from library dependencies, platform dependencies, revision dependencies, etc. An orchestration engine or service bus can provide a higher level of abstraction, but that doesn't remove the dependency on contracts, just endpoints. And unless you're prepared to do some serious re-architecting (we are talking about, for example, rewriting every application and service to use pub/sub and other asynchronous messaging patterns), then there's going to be no benefit.

You already have everything you need in place to support multiple clients. What you need is a better deployment process, a clearer upgrade path, and messaging contracts that are more appropriate to an SOA. For scaling, if one web service can't handle the load, then use a load balancer - your web services should be stateless anyway.

If your architecture's become really big - and I mean enormous, to the point where your database and services are hyper-optimized but there are just too many transactions happening per second to keep up - then you might consider implementing Command-Query Separation. But don't start down that path unless you're prepared to see it through to the end, because you won't see most of the benefits until you have completely isolated the queries from the commands.

share|improve this answer
Thank you for the very detailed explanation. The web service is from a third party with no sources available so we will possibly replace it with an entirely new web service since we have control of the database. As of now the Web service is using an RPC-like interface so you're right this is heavily chatty. –  Stecy May 16 '11 at 11:47
@Stecy: Ah, the good old missing-source-code problem. Unless the existing API is filled with mysterious business logic, I would turf it - there's no productivity gain to be had in coding against a black-box service tier when you have white-box access to both the data and client tiers. –  Aaronaught May 16 '11 at 13:42
Please pardon my incomplete understanding of the english language but I'm not grasping the signification of the word TURF here. –  Stecy May 16 '11 at 14:31
@Stecy: It means throw it away. I get the impression that the service is just a thin wrapper over the database, which is worse than useless; if that impression is correct then I think you'd be better off not using it at all. –  Aaronaught May 16 '11 at 14:44
I was not sure "turf it" meant "throw it away" but you confirmed it and it makes sense now. Effectively the web service is a thin wrapper. For that reason, we are going to replace it with a new web service that would provide domain methods to clients. However, in doing so the service will have a LOT of methods. Do you see this as a problem? Would it be more maintainable to have several web services? –  Stecy May 16 '11 at 14:55
show 2 more comments

Your Answer


