The user-interface components are normally not services themselves. Front-ends (UIs, reporting tools, etc.) use the exposed services and perform the work necessary to achieve some end. Intermediary services can be constructed to help 1 or more front-ends that have common needs.
I'd offer that if the user wants to see the information, then it is part of the process. As you say, they may use that information to help drive actions and make decisions. A facade will solve this problem (depending on the details of the base services), but it isn't necessarily the only way to solve it. How is the data returned from the service "getCustomer" distinguishable from a "raw data dump?" -Rob --- In [email protected], "Suhayl Masud" <[EMAIL PROTECTED]> wrote: > > Thanks for the responses so far. > > However facade / aggregate services are not going to solve the > problem posed : "your user wants to see more information then is > required to conduct your business process". > > Here is my premise: a service should not offer a simple raw data > dump. Why? Because then you are tightly coupling on the data. The > more raw data you expose, the more people will manipulate it > different ways and be tied to it. Furthermore, once again, the > logic will start getting built over and over to do similar things > all over the place.
