Greg, agreed but if the service is fine grained data shifting and usage is coarse grained then the service isn't fit for purpose.
More often I see the request the other way around, so a service wants to accept a list of order items that make up a whole purchase order and the ui allows people to add to this list one at a time and then submit in bulk. Lazy UI people try and push this caching logic (which is really what it is) back on to the service rather than building the list themselves and pushing it down in one go. Steve On 27/06/07, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
JP Morgenthal wrote: > You're premise is correct. I am constantly having to remind my > development team that we do not change the service to fit the needs of > the UI. In these cases we have to develop a server-side processor to > provide information aggregation and transformation. Some might do this > with an ESB today, but I'm using a Microsoft stack. You might also use > a BPM tool to help in this layer since the UI is probably connected to a > business process. One the important things for me is that you have to decide which is more important, the interface that the users use or the interface that the services use. For me, the importantance is the interface that the users use. It has to provide the right value for the use that it is intended for. If the service has an interface that returns 1 item per query yet the user interface shows a list of items, then the service will have a lot more overhead of query count to deal with which impacts scalability. In the end, the service has to meet the needs of the "supported" clients. So I'd suggest that there is a need to change some attributes of services which were not designed with particular types of clients in mind. Gregg Wonderly
