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. In my humble opinion, one should be able to ask a question of a service and receive an intelligent response. So instead of extracting data and manipulating it oneself, the consumer could ask a meaningful question and recieve an intelligent response. This way, the service is responsible for the "logic" as well as the data. Business processes and the services within, work well with this approach. The UI on the other hand, wants to show a lot of information. Rollups, drill downs, and all sorts of stuff that helps the user *decide* to take action in that business process. It would be ideal if one could promote the simplification of the user interface. E.g. Library search interfaces were far more complicated then the google search interface, but google offers richer results even though the control "choices" of the user are limited. I have found however, that for human intelligence rich processes, it is imperative to provide the user a tonne of information so they are comfortable with the process, and can make a meaningful decision. It is tough to explain this without detailed examples, but it has been my experience that UIs pose a specific challenge to building services. Especially when you get right down to the nitty gritty of the details needed (often outside of the business service interface), and performance issues (consider a list pane with a scroll bar...ouch!). --cheers Suhayl http://www.linkedin.com/in/smasud --- In [email protected], "Rob Eamon" <[EMAIL PROTECTED]> wrote: > > In their book "Enterprise SOA: Service-Oriented Architecture Best > Practices", Krafzig, Banke and Slama define a "facade service" much > like what the other posts describe. Such services "encapsulate some of > the complexity of underlying basic services by providing an aggregated > API that enables clients to more easily utilize the functionality of > the basic layer." > > I know you were just providing an example with the 10 fields vs. 15 > fields scenario but we should be careful about thinking in those terms. > Rather, we should be thinking in terms of services. > > For example, from the Enterprise SOA book, they use an example of > separate booking and billing services that must record a reservation in > a coordinated manner--e.g. you don't want to book without billing and > vice versa. An intermediate service would be one way to address this. > This focuses on the need for coordinating the services, rather than > focusing on the data elements. > > -Rob >
