Recently I have been in some debates about how much web-services should be applied to any one problem. This is what comes to my mind after those discussions – services means a lot of things and the argument is when we use service to mean any of them. I will talk about the layers from top to bottom.

– At the top there are services which are little more than “convenience classes” – in a way these are not really “services” because they are really more part of the tools and applications than they “stand-alone-islands: of functionality. The APIs at this level need to be expressed in the language of the application and perhaps someday when we have implicit WDSL in a framework which supports it well – these can become “RPC-ized” over web services using implicit mechanisms. Given the nature of these APIs, it is not likely that a web-services implementation of this API will perform well unless the clients and servers are “close and fast” and perhaps even using the same framework so that serialization can be binary rather than XML. .NET shows the potential of this approach but is only successful because the framework helps a *lot*. There is no such framework in the non-.NET world yet.
– Then there are services which can be though of as “integration points” where some pluggable capability is to be inserted – these services can be expressed in a native language (i.e. JAVA) APIs – but at the same time, effort should be made so that these can work well under the 10ms rule. They may be implemented using local, native approaches but lets make sure not to preclude a web-serivces implementation. I.e. Solve the web services performance issues even before the web-services implementation exists. An interesting approach would be to put a 10ms sleep in every call on a native implementation of the API to simulate the pain.
– Then there are services which are a “collection point” for functionality which is published to the world. GPIR is an example of this, a campus-wide LDAP is similar, A campus-wide single signon is yet another. These are intended for extremely broad reuse across many languages – and they are so valuable that the effort to make web services implementations *right now* is worth it even with shifting technologies in the web services world and lame performance in the JAVA world. These implementations and their clients may be forced through 2-3 major rewites as the open source web services effort gets its act together – but that is worth it for these services.
– A variant of the last layer is the “read-only” collection point. These should be web services now – period. Basic SOAP support in a non-access controlled environment is pretty solid in a lot of languages and is already in heavy use. It is a no-brainer with a big win. Simple host/SSL certificate based stuff is also “sort-of” OK – it does not scale, is ad hoc, but tolerable.
– A disfunctional variant of the last version is the read-write web-services using ad hoc identity transfer all hidden by a firewall. When this approach is used, organizations can crow about their delightful commitment to web services and the fact that they use it heavily. For example Northwest airlines probably uses a lot of web services internally behind the firewall. But this is not proof that secure-identity web services works in the general case connected to the Internet – but it sure fires up the all-web-services-all-the-time evangelists.
I fear that at times the Web-Servces zealotry is fired by high-level executives who read airline magazines as their primary source of technical vision. I am a zealot in moving in that direction but I know far-too-well how hard it is to do without turning your project into a framework-building project.
If a company has the energy to invent their own .NET like framework and then program to is – then by all means – go do it. But dont jump on me and the projects that I am involved in encouraging us to solve these (very very hard) problems *before* we get to start line 1 of our own source code.