Monthly Archives: February 2005

In an SOA, a service should not be tied to the resources that allow the service to be delivered. WSDM MUWS closely ties services with resources and in doing so it does not violate any SOA principle. I will show in this entry that these two sentences do not contradict each other.

Resources come and go and creating information systems that directly connect resources to one another results in brittle systems that don’t scale. Service-orientation, when well used, addresses this problem. Many have said this better than me before, like Jim: “Web Services are about hiding resources and exposing processes which operate on those resources”.

WSDM MUWS exposes a ResourceId property and manageability capabilities that are specifically tied to a given resource. But this “resource” is not the resource that makes it possible to deliver the MUWS service. It is the resource that the service has been created specifically to represent. Let’s illustrate this by contrasting two examples:

Service1 is a storage service. The “operational value” of this service is to store data. The right way to represent Service1 is in a way that is separated from the resource (in this case a storage array) that is used to provide the service. The service should expose its capabilities in terms of reading and writing data, not in terms of what SCSI disks are used. So that tomorrow I can replace the storage array with another one (or maybe with two smaller ones) and, assuming I replicate data correctly, the users of my service will not notice the change. A basic example of service-orientation. Now let’s look at Service2. Service2 is a management service (in MUWS terms, a “manageability endpoint”) used to manage the storage array from the previous example. The “operational value” of this service is not to store data in the array, it is to manage the array. And not any array, this specific array seating in my machine room. The resource used to provide the service is the Web services engine in which Service2 runs and whatever mechanism allows it to manage the storage array. In this case too, Service2 should be exposed in a way that is independent from the resource(s) that it relies on (like the Web service engine it runs on). But having it not be tied to the storage array makes would negate the very value this service provides, namely to manage a given storage array.

Of course in some cases it makes sense to embed the manageability endpoint inside the resource being managed in which case the resource being managed is also the resource that provides the service. But this is a corner case and in no way something requested by MUWS.

Separating the service from the resources that compose it is a good thing, but when the operational value of the service is exposed in terms of specific resources it is fine to explicitly attach the service to the resource. When deciding whether it is ok to let a resource show through a Web service, one needs to clearly understand whether it is a Service1 or Service2 type of situation.

As I was sitting in my car listening to KQED on the way back from work and I recently remembered an interview of Tim Berners-Lee by Terry Gross on Fresh Air that took place in 1999. TBL was promoting his book, Weaving the Web. At that time I was very familiar with Web technologies (first Web site in 1994 and I had been writing Web applications as CGIs more or less non-stop since 1995) but I hadn’t realized that the URL was the key building block of the Web, way ahead of HTTP and even more ahead of HTML. I don’t think I had ever asked myself the question, but if I had I would probably have sorted them backward. Hearing TBL in this interview describe how, before the Web, people would create small files that described where to find information in a human-readable way (I assume it must have been something like “telnet to this machine, use this logon/pwd, go to this directory, start this application, load this file”) really made me understand the importance of this URL thing I had taken for granted for many years. To this day I vividly remember this interview and the Eureka feeling when I realized the importance of URLs as an enabler for the Web.

I don’t know if the fact that this interview, which was targeted at the general audience of Fresh Air (more used to hearing Jazzmen interviewed than geeks), taught a Web-head like me something important is a testament to TBL’s vision, Terry Gross’ skills as an interviewer or my stupidity for not having grasped such a basic concept earlier.

Going back to WS-Addressing EPRs for a minute, what I was thinking recently is that these EPRs look a bit like the old “do this, do that” files that TBL talked about and that were replaced with URIs. Where “do this” becomes “put this header in your SOAP message”. Unlike the “do this” files, the instructions in the EPR can be machine-processed and that’s a key difference. But still, I can’t help getting this deja-vu feeling. Not that I have ever encountered these “do this” files myself but TBL made me see them one day in 1999.

[UPDATED 2011/9/27: Before pointing to this piece on Twitter (in response to this post by Joe Hewitt) I just have to change the awful title (for the record, the original title was “Thinking about EPRs like Proust”; yeah, I know). Whenever someone uses “la petite madeleine” (or Schrödinger’s cat for that matter) to illustrate a point you know it’s going to suck, so I removed it. And while I’m at it, I am replaced all the references to “URI” by “URL” which is less pedantic (and more accurate in this context). There. I usually don’t like to edit old entries, but this one was so bad it made almost no sense (not to mention the fact that no-one cares much about EPRs anymore).]