feedSubbu Allamaraju: December 2004 Archives
Whenever the topic of statefulness vs statelessness comes up, most people list performance and scalability as two main reasons to avoid state. Sometimes, these debates get very passionate with some people arguing that state is not all that bad. There are some valid points in both sides of the argument. It is true to that maintaining state can impair performance and scalability, and applications need to take extra care to keep some decent levels performance and scalability. But I think we don't often discuss how state affects architecture and deployment of applications, and these issues have some really long-term consequences.
Oftentimes, business critical web service interactions happen within the context of a user. User interactions with a web app might initiate communication (either synchronously or asynchronously) with web services deployed elsewhere. In such cases, how does your app let the web service know who the user is, so that the web service can impose security constraints on the kinds of transactions that can be done, or the kinds of data that can be accessed?
John Mitchell recently posed a question on his blog asking about the difference between design and architecture. He argues that, when people use the term architecture, they are just talking about design. I agree.
Managing change and versioning of web services can be hard. Although based on loose coupling and extensibility concepts, when it comes to change, web services are not far from older supposedly not-so-loosely coupled RPC-style technologies.
Most changes have good intentions - either they fix something broken, or try to enhance the service by adding new features. However, except in the most ideal cases, changes are disruptive. As David Bau explains in his "morning after" scenario, the need for compatibility can scuttle most plans for change. It is not always easy to foresee changes and future-proof the design, but eventually, we all get tasked to make changes.