--- In [email protected], "Steve Jones" <[EMAIL PROTECTED]> wrote: > > But those service clients are, from the perspective of the user, a > producer and arbiter of access to capabilities.
>From a strict SO standpoint, I don't care about the perspective of the user. What the service consumer does, whether or not it has a UI, a report writer, a whiteboard connected to the network, or (to borrow your one of your favorite phrases) causes monkeys to fly, etc. is immaterial to SO principles. The only thing that matters is that the consumer interacts with the provider through one of its separately standing interfaces. At the BA and EA levels, and at the specific AA level, I certainly care about the UI of the app. But not through an SO lens. > In other words they provide a service. This is why I put the > concept of "Virtual Services" into the methodology piece as it > recognises that there are some services that do not provide > capability directly themselves but merely act as a re-direct to the > underlying capabilities. > > From the consumers perspective it walks like a service, talks like a > service and acts like a service. I agree fully that services that aggregate capabilities or compose a new service from existing services are indeed services. No issues with that. But IMO, an app that only consumes services is not itself a service, from an SO POV. A UI is never part of a service. As always, just my opinion. -Rob
