Subbu Allamaraju: December 2004 Archives

12:11 PM, Monday, December 27, 2004

More Reasons to Avoid State

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.

10:03 AM, Monday, December 27, 2004

Web Services and Propagating User Identity

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?

06:04 PM, Sunday, December 12, 2004

Design, Boxitecture and Architecture

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.

08:03 AM, Friday, December 10, 2004

WSRP 1.0 Primer Finalized

WSRP TC approved the WSRP 1.0 Primer for final public release yesterday. Here is the link: http://www.oasis-open.org/committees/download.php/10539/wsrp-primer-1.0.html

09:50 PM, Monday, December 06, 2004

Web Services Versioning - Part 1

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.

« Subbu Allamaraju: November 2004 | Main Index | Archives | Subbu Allamaraju: January 2005 »