Service Contracts and Global Constaints

by coatta 1/29/2008 7:54:00 PM

We ran into an interesting problem with one of our web service interfaces at work today. We had recently added code to enforce some business logic constraints, and this was causing some requests to fail that, from the perspective of the UI, should have been legal. The problem was a mismatch between the granularity of our service contract and the granularity of the constraints.

The constraints that we had added were ones that applied to collections of objects. An example of this type of constraint is that a collection of nodes in a graph cannot have any cycles. The interesting thing about this sort of constraint is that you cannot determine if the constraint is being violated by looking at a single node. You have to examine all of them at once.

Now suppose that you have a web service call that allows you to add/remove/update a single node. Superficially this doesn't seem like a bad idea. In addition to that, let's assume that the application making use of the service allows the user to modify one or more nodes and then save all the changes back to the server. No problem, when it comes time to save the changes to the server, you iterate through the modified nodes and then make an add/update/delete call for each one.

But what if the server validates the set of nodes as part of each add/update/delete call. Now you've got problems. The user can make a set of changes that are consistent when considered as a whole. That is, the graph resulting from all the changes has no cycles.  However, it is possible that one or more of the individual changes results in a cycle. So part way through saving the changes back to the server, you'll get an error indicating that the constraint has been violated.

The problem is that the granularity of the updates does not match the granularity of the constraint. To resolve the mismatch for the example above, you need a service method that allows all the changes to be sent to the server as a batch. The server will only validate the results after the entire batch of changes has been applied.

You might feel inclined to complain that a web service that allowed the nodes to be updated individually was a poor design in the first place. After all, most service interfaces should allow operations to be carried out in bulk. But even if you design the service to support bulk changes, it is still possible that the granularity of the interface does not match the granularity of constraints -- so when designing a service interface you need to be aware of the business constraints that will be enforced by the service implementation and design your interface accordingly.  

Microsoft Volta

by coatta 1/27/2008 9:21:00 PM

I read through a lot of Microsoft's material on Volta the other day. I sense the turning of the karmic wheel of software development. They note on their blog that Volta "enables developers to postpone architectural decisions about distribution." Well, having spent 3 or 4 years deeply involved with building infrastructures on top of CORBA, I can safely assert that this is exactly one of the goals that we had in building those infrastructures, and I think it is safe to say that it was one of the primary goals behind CORBA itself. In fact, the whole point of location transparency was just that: to completely isolate code from decisions about where objects actually reside. Oddly, the Volta folks point out that they acknowledge the failure of location transparency by referring to the fallacies of distributed computing. But location transparency is not really one of those fallacies; the fallacies are about more fundamental issues in distributed computing such as the fact that latency is not zero and cannot be ignored.

One of the biggest problems with location transparency is that people misinterpreted it as meaning that location could be ignored. But anyone who was seriously involved in research in distributed computing -- including the folks who designed the CORBA specs, knew that was not the case. Location transparency was about creating systems in which the syntax and semantics of invocation were the same regardless of where an object was located. And the primary reason why location transparency was a goal in CORBA was precisely because it allowed the physical mapping of objects to servers to be changed without having to change code. Sounds oddly like allowing "developers [to] architect their applications as a single-tier application, then make decisions about moving logic to other tiers late in the development process" -- which is straight from the Volta FAQ

Part of the downfall of CORBA was that location transparency allowed people to build systems badly. In fact, I think it would be safe to say that unless you were thinking very carefully about patterns of object interaction, the physical locations of objects, the types of partial failures possible, etc. you were pretty much guaranteed failure. The Volta folks seem to be treading in similar territory. Unless they have mechanisms in place to prevent people from building poorly architected systems, then people will build poorly architected systems. And it will only be too easy to have the technology be the scapegoat.


<<  June 2017  >>

View posts in large calendar


My opinions are my own, but you can borrow them if you like.

© Copyright 2017

Sign in