One downside of working with experienced people is that, some experienced people tend to be opinionated, and the trouble with opinions is that opinions are, well, instantaneous reactions based on things they learned in the past. You can wake up an opinionated person and ask a question that you know this person has an opinion on, and that person (self included, on occasion) will most likely blurt out that opinion without even understanding the context. Unless careful, it is easy to get trapped into that mindset, and start enjoy being opinionated, and consequently, making or advocating "obvious" choices. Welcome to my soft rant!

Most web based systems are architected with three pieces: (a) a user-agent, (b) a web server for processing, and (c) a database for storage. Of these three, the user-agent is typically considered as a presentation node, with almost all the computing performed on the web server node. In this model, each node has some special characteristics:

• The user-agent is a mutli-threaded and dedicated node with reasonable computing power entirely under the control of the user
• The web server is a multi-threaded or multi-process node that is shared across several users
• The storage node is also a multi-threaded or multi-process node that is also shared across several users (via the web server)

In hosted environments, nodes (b) and (c) are expensive. For instance, while a typical shared hosting of an application costs under $100 per year, dedicated servers cost over $200 per month per node. Hosting an application on shared hosting systems therefore introduces some scalability problems that can not be solved cheaply. I was faced with this problem recently, and I had to make some choices to scale the application without requiring additional computing power on the server side.

Carlos Perez at manageability.org posted an interesting discussion on OO-styled interactions, and I can't agree more.

It is very common to find most people listing statelessness as one of the key principles of service API design. Statelessness is an overloaded term. To my experience, when someone says that a service is stateful, he/she usually means that the service maintains some internal state. We can argue all day long on whether maintaing state is good or bad - the answer usually depends on what the service is doing. In most cases, whether a service needs to maintain state or not is a service implementation choice - service users do not need to know or care about it.