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.