>
The Web Services world is quite different from traditional development where one vendor or party controls the whole show and can distribute processing between server and client.
>

Agreed, but streaming large chunks of data will still yield scaleability issues.

>
I cannot possibly instruct the consumer how much data they need or tell them to process stuff on my server. I do not know why they want the data, the only "rationing" mechanism I have is cost.
>

You don't know *why* they want data??? This is an essential part of the requirements (both functional and data) gathering process. If you don't know why a user wants data, then the analysis is incomplete.


>
While you might declare rules about what people can request, there may be *excellent* reasons for a consumer to request data more than you might feel is efficient. Example: a hospital in the UAE requests a VAST data collection... you do not know it, but they have a collapsed holidaying dialysis patient and need to load the patient's full record into their Web EPR ASAP to expedite multiple specialist opinions.
>

The issue is not what I think is efficent. The issue is what their network infastructure can support. When you say VAST, how many bytes are we talking about? (8K, 16K, or more)??

>
Will your system refuse because it decides they don't actually need all that data? Or will you insist they guess date ranges and make multiple requests to avoid overloading your middleware? Or will you tell them they should have used Analysis Services? (!) Or will you abandon the middleware idea and load the server instead?
>

No. I will conduct the requisite data requirements analysis so I won't have to guess...< s >...

Thanks for shedding light on the level of your requirements gathering and analysis...