When I started this blog, it was because I was working on an article (or blog post) that was supposed to be a IMO a level headed look at some of the silliness around the usage of Web Services in places that it just doesn’t make sense. Places where it doesn’t make sense to cross a boundary and places where a boundary cross is required, but web services don’t fit the bill. Don’t get me wrong; I LOVE web services, SOAP, XML, the new WSE2.0 enhancements, etc. I truly love this stuff. However, I truly love motorcycles too, and when I’m in my living room and want to get a cold one from the fridge, I usually don’t use my motorcycle. One could argue that I could (and in deed I could), but that would just be silly and my wife and kids would probably have me committed to a padded room.
I never finished this article or blog post. Its summer, I have a tight project deadline, and well the topic really deserves serious reflection (not System.Reflection but Brain.Reflection) Today, I read a blog post entitled Middle-tier hosting: Enterprise Services, IIS, DCOM, Web services and Remoting by Rocky Lhotka that blows away anything I could have thought of doing myself.
Rocky, thanks for cutting through the hype. IMO this blog is essential reading to anybody that actually wants to think level headed about the situation. Although, I’m willing to bet that it will generate some additional hype of its own ;-)
There is a lot of silliness taking place today. In my spare time, I try read articles and converse with other developers and architects on this same topic. It seems that everybody wants a silver bullet, and is constantly looking for a single elixir that will solve all aliments. As soon as the covered wagon pulls into town, we try to gulp up what is being sold as a cure for all our problems. In an attempt to do so, our logical layers become tiers, and our single answer for connecting these tiers is web services. I fight this battle on a daily basis with people I work and converse with.
The best elixir is design your application with the technologies that make sense for what it is you are doing. This implies that you first describe and understand what it is you are doing, and don’t pick the technology, protocol, etc. to do this until then. As is stated in the article, maybe tomorrow Indigo or something else will change this. But for today, the point at which my application uses or consumes a web service will be when it needs to interface with another application. While this approach may sound antithetical to SOA, it really isn’t. That is, if the application I’m building is one that’s purpose is to provide a new service and added value to other existing services. It’s all about what it is you are building, and more times then not I’m building an application that may or may not have some service interface points, but should not have it’s internal tier’s interfaces (both logical and physical in some cases) be dictated by web services and therefore SOAP and XML.