Clemens Vasters, though he know it not, has had a non-negligible impact on my thoughts about service-oriented architecture. I usually enjoy what he has to say about topics architectural in nature, and topics related to service oriented architecture in particular. He did some interesting skunkworks with Microsoft on a reference architecture called "Fabriq," working closely with Arvindra Sehmi, an architect from Microsoft who is also an editor for the new Microsoft Architecture Journal. I saw a webcast of a joint presentation by the two. It dug into the notion of service agents in the context of Fabriq. Really interesting, somewhat heady stuff -- I need to find the link.
Additionally, he took the open-source blogx (rip) and turned it into dasBlog (with some help, of course), and that is a great public good.
Finally, he, through is company, newtelligence, has contributed some excellent web services management extensions for .NET. I am looking for a good excuse to sneak these into my current projects.
Because he has that influence on me, he earns a [perhaps someday] coveted spot in the thought leaders list.
Now.
I recently published an entry on architectural qualities, and it was superficial at best. A position statement, but not much more.
Then.
Clemens published a number of entries on his blog that he is providing as background material for one of his presentations at the Microsoft PDC, and despite the fact that it would most likely mean I would be away from my lovely wife and daughter, I wish I were there. I have only attended one PDC back in Denver ('98?), but it was great fun.
The first of his list of articles, Stateless?! delves into a commonly touted, oft-misunderstood statement (and I paraphrase): "Stateless [Services Components (collectively here for brevity--services)] are more scalable." This will be a platform for digging into scalability a bit more.
He then attempts to describe a scenario where a stateless service does not scale, but he focuses on performance rather than scalability. It is completely relevant that the increased response time of a hog of a stateless service will tie up precious system or otherwise resources that then have a negative impact on scalability. But that does not mean that the service would not scale. It merely means that it would scale all that well. You could still go with his earlier explained approach of throwing more hardware at it, and you would have a scalable solution. He tends to focus on the vertical load scalability aspects, while ignoring the horizontal scalability aspects.
Now, ignoring the quibble over scalablity vs. performance, I especially like a statement toward the end.
The scalability recipe isn’t to try achieving static statelessness by avoiding holding state across calls. Using this as a pattern certainly helps the naïve, but the actual goal is rather to keep sessions (interaction sequence duration) as short as possible and therefore limit the resource consumption of a single activity.
I might amend it slightly, though:
"the actual goal is rather to limit the resource consumption."
Limiting session duration is certainly one approach, and focusing on individual activities is another, but they two together are not the only approach. He mentions other approaches, such as pooling earlier in the article, and they are perfectly valid approaches to increasing the scalability of a solution as well.
RichB follows up with a comment that deserved some attention along the lines of "performance != scalability notion:"
Of course scalability may be increased by having a stateful service in certain scenarios. What if the service had millions of requests per minute, but only had a very few unique clients making those requests? You could save bandwidth by storing state on a per-client basis. For example - instead of sending a large amount of stateful data back to the client on every round trip, it could be stored in memory on in a state store - and the amount of data saved in every round trip is multiplied by the millions of requests per minute to get a large bandwidth saving.
Rich again does not seem to be addressing scalability, which has to do with how well a system responds under some dimension of growth. That dimension is usually load, concurrent number of client request, etc. Rich doesn't create a situation that describe a scalability problem, and the solution is couched in terms of increased performance (throughput, response time, network efficiency, and so on). The distinction may or may not be subtle, but I think it is relevant, because you may have a situation where your system performs well under the current load, and you know that you are about to bring on a new client that is going to appreciably increase that load beyond the scale of the current solution. You can dig into the software looking for ways to reduce the session duration in the name of scalability, or you can go with the more naive [and probably faster and easier to implement and test] solution of throwing more hardware at it (horizontal scalability).
Now, that being said, it is worth noting that there are other types of scalability than just load scalability -- internationalization, for instance, is a type of scalability.
Another type is domain scalability -- how well does your architecture incorporate new products, new concepts, new lines of business? This is a pet interest of mine (among others) under the name of Adaptive Object Models.
Recent Comments