I have been doing less and less with XML at my clients lately. This is not completely by my customer's choice, either: much of it is driven by me.
As a background, my role within Applied Information Sciences is Software Architect, following the roles defined in the Rational Unified Process. This makes me responsible for the overall design of a system and the integration plan for subsystems. I also function as a Lead Designer, which makes me responsible for designing the subsystems that I previously identified. I also function as the Database Designer as well as Implementer. This pretty much means I participate heavily in the Analysis and Design phase to develop the Software Architecture Document, then mentor teams of 5-10 people through the construction phase.
When I start a client engagement, I try to get a feel for what the customer is comfortable with as well as what the customer is interested in exploring. The usual suspects that they are familiar with include basics of C#, some DataGrid work, maybe even a user control or two for ASP.NET apps. Sometimes I am pleasantly shocked to hear what they have done with .NET, but more typically they have stuck to basics.
Then I ask what they are interested in. Within the first few moments, I hear that they want to do something with a web service. Typically they will indicate a desire to create a suite of reusable ASP.NET controls. Almost certainly, someone mentions the need for a centralized security framework, and given enough time someone will toss in requirements for developing a standard application portal. And all of this they want thrown into yet another 6-week project titled “Customer Relationship Management Tool“.
Parting the overall architecture dream from what can actually be accomplished in 6 weeks can be an art form, one of paring a mountain of granite down to a 5-inch perfectly shaped bust of Shakespeare. Time to start the inception phase to see what they really want.
Once I get started looking at what they are really asking for, I see no mention of web services, controls, security, or a centralized portal. They usually just want some basic data capture and retrieval behaviors. These requirements are captured into a few use cases. We are supposed to stay away from implementation details at this stage, but you cannot help but notice that there still is no need for introducing web services yet. Worse, you can't imagine much more than a 2-tier app that Infopath could serve just as well as a custom ASP.NET app.
Once we are done defining the use cases, we define the realizations through sequence diagrams. You ask a few clarification questions:
Me: Is all of the data contained within this single database?
Me: Do any of your external customers need access to this data?
Me: Are you interacting with any other platforms, maybe calling a Java app on a Sun box running Linux?
We just went through the basic premises of how to make the call if web services are appropriate or not. In this case, web services serve no apparent need. OK, maybe you can think of one or two odd situations for web services that this dialog doesn't cover, maybe using the IE Web Service Behavior for DHTML updates to the UI without page refreshes. But this does serve 90% of the purposes for web services. So why do people overuse web services so much?
I talked with a local Microsoft Evangelist, and he indicated that web services were definitely the future for .NET. And he said it with a straight face: I think he really believed it. Sadly, I think many of the developers lured into .NET also believe it. Hell, the marketing description for .NET describes it as Microsoft's platform for building next-generation web services. You can't work with .NET and not hear about web services.
Maybe someone at the web services team at Microsoft has a much different view of service oriented architectures, but that view won't soon be realized in the corporate world without making the cost of server licenses much less an impact to small and medium sized company's financial statements. They don't typically have farms of servers waiting to be utilized, and they typically don't have many external customers that they want to share data with. They have a pool of secretaries doing something manually that can be automated with a small investment.
Web services are great, don't get me wrong. But they just don't apply to many of the applications that are actually being built. That doesn't mean they are not being used. I have seen web services used for component to component calls on the same box. I asked the developer why he chose to implement a web service there: his answer was “it sounded interesting.“ OK, he is not getting the AM Turing Award anytime soon, but you have to wonder why web services sounded so interesting that he would defy reason just to throw one into an otherwise healthy application. In a word, “marketing.“ He bought the marketing hype, he drank the kool-aid, but more importantly he needed “web services“ on his resume somewhere.
Now go back out into the real world of developers where people have been programming for awhile, maybe using COM or Java successfully for several years. Mention “web services“ to many of them, and you will hear a giggle, maybe even a guffaw. “Web Service!?! What are you trying to do, cripple our systems? Slow 'em to a crawl? We don't need no stinking web services!“
The fact is that many of the clients I interact with do not have web services in place, nor do they need them. But their managers have read so much about web services and XML that they insist that web services are the only way to develop systems these days. The lesser experienced developers grab hold of every little bit of neat technology they can get without a bigger picture of the impact to a system. The more experienced developers are more grizzled and callous to “technology for technology's sake.“
Not so mainstream, but definitely related, is the guise of XML. XML has its place, definitely has its many uses. The configuration framework (a future post will explore the overuse of the term “framework“) within .NET is a prime example of how XML can be properly used. DataSets can use XML Schemas to define strongly typed DataSets as well as to coerce hierarchical data into relational objects. But just as soon as I list the benefits of XML, someone is sure to follow with a question like, “what is better, XML or a database?“ There are folks who see through the marketing and the hype, and the others who are stopped cold in its tracks.
XSLT never really suffered the same track as XML or SOAP. XSLT is difficult to approach, because you need to have a grasp on XML, namespaces, and XPath. There is a larger barrier to entry for XSLT than XML, where you can pick up the basics after reading aquick article on W3Schools.com. The remaining complexities of XML can be hidden by the DataSet. SOAP has been rendered deceptively simple by the existence of the [WebMethod] attribute in .NET, almost unnoticeable to those who develop web services. But XSLT... nothing really hides XSLT yet.
Nothing made XSLT easier, and this is one of the reasons that it has a comparatively slow adoption rate. To note, this is why you see so little about XSLT in the way of books and articles. Why write (better yet, why publish) for such a small audience? If nobody is using this stuff, why write on it? If there are so few articles in the mainstream rags about XSLT, why use it in my applications?
A few tools, like Marrowsoft's Xselerator, ease some of the burden of working with XSLT, but you still have to know a lot about XSLT to really leverage the tools.
And when do you use XSLT? Since I develop mainly web applications, people typically want to use XSLT for controlling dynamic screen placement or branding applications. Take a look at CSSZenGarden: This is one of the best demonstrations of why XSLT is not always the answer for this.
XSLT has its uses, but they are waning in my architectural style. The more I architect solutions that developers are able to construct and maintain, the less I introduce XML and XSLT. The fact is that developers just don't use them enough to understand them as viable tools. They know the marketing terms, they know the objects that hide deeper implementations. They don't know XML. So I am forced to develop less elegant yet equally effective solutions to problems using other means.
Thank God there are always Design Patterns left to confuse them with.