11 February 2004

Applications or Components?

<?xml:namespace prefix = o ns = “urn:schemas-microsoft-com:office:office” /> 

When you create a system with web services, are your web services components or are they standalone applications?   While this might seem like a semantic question, it is actually a very big deal, with a lot of implications in terms of your overall application design, as well as the design of the web services themselves.   I specifically argue that web services are the ‘user interface’ to a standalone application. Any other view of web services is flawed and will ultimately lead to a seriously flawed application environment.   Another, simpler, way to put this is that “a web service is an application, not a tier in an application”.   Perhaps the key reason this is such an important thing to realize is that almost anyone can use a web service. It isn’t like we get to pick which other apps will call our web service. Web services are discoverable, and someone, somewhere in our organization (or outside) will discover our web service and will start using it.   If we designed the web service as a tier in our application, we would design it to trust our higher level tiers. If the higher level tier did a bunch of calculations or validations, it would be silly to replicate that functionality in a lower level tier.   On the other hand, if the web service is a standalone application that merely has an XML interface (as compared to a GUI or HTML interface), it must implement its own calculations and validations. It would be silly for an application not to implement this type of functionality.   So let’s get back to the component vs application thing.   Components are generally viewed as entities that live within applications. A component provides some functionality that our application can use. But components often have a high degree of trust in the application, and the application certainly has a high degree of trust in the component.   Think of Windows Forms controls, ActiveX controls, encryption libraries, data access (like ADO.NET) and so forth. These are all examples of components, and it is pretty clear that there’s a high level of trust between them and their hosting applications.   Viewing a web service as a component implies that it is part of an application, rather than actually being an application. This implies a higher level of trust than can be granted to something that is essentially a public API that can be invoked by any application in our organization (or beyond).   Applications, on the other hand, don’t trust each other. They trade data, they send messages, but they don’t trust. We’ve probably all be burned (multiple times) by having too much trust between applications, and we know that it is a bad thing.   By viewing a web service as an application, we can apply full application design principles to its creation. It has a presentation tier (the XML web service itself), a business tier (hopefully a set of business objects, or at least a business DLL), and a data tier (whatever that might be). It is self-contained, doing its own calculation, validation, authentication and so forth.   Other applications can use our web service as a data source, or however they choose. But our web service will be internally consistent and self-protecting.   This ultimately means that the web service will be reliable, useful across multiple applications and in the end will be a good investment in terms of development dollars.