Services and situations

Ask five people what a service is and you will get five answers. If there is agreement, it is just at a dictionary level - that a service is some capability that is provided and exploited. The different answers offer a litmus test, however, for judging the roles played in constructing distributed systems. The simple service architecture plays host to an interesting dilemma. On one side, the subscriber doing the filtering-out of undesirable results can affect the performance of the composed system noticeably over some infrastructures. On the other side of this dilemma, the best constraints are situational, that is, dependent on the user's situation as inferred by the subscriber. Current provider-centric approaches to services ignore the user's situation altogether. Situational information is usually not available to the service. Services can take some profiles, to accommodate the interests of users but not their changing situations. The usual service architecture makes the subscriber responsible for managing the situation. The subscriber should be able to probe the service in various ways to obtain the best utility from the service, but without compromising privacy.