This is a cracking example of why a simple service definition isn't enough to ensure a decent quality of service. After all a bath is something that holds water, in which you can sit down, so these enlarged sinks match the basic criteria. They hold water, and if I get in one I get wet.
Now if when I specific a hotel room I could say
Bath.length > 1.2m
Bath.depth > 50cm
Thus giving a detail precondition on what I consider most important in a hotel room. I could also specify the details on the gym, to make sure its not just two crap machines in a tiny room.
Effectively here I talking about the importance of preconditions from a client perspective when selecting and invoking a service. A more business analogy would be when thinking about acceptable response times for a service, where if they don't respond in time you don't care about the result. Its about how the client can place restrictions and contracts onto the service.
The normal way to do this is via parameters on a method, but a more effective way would be via a contract applied to the call which could be managed as a policy independently of the invocation, i.e. changing acceptable response times.
Thus invocations should be about a negotiation between client and service to determine if the required conditions and QoS can be met, if they can't then the invocation is invalid, something the client should have as much say in as the service.
Seriously though, what is with US hotels? The beds are huge, the baths are tiny.
Technorati Tags: SOA, Service Architecture