Thanks for your help in this matter.

Kev

>>Well, the middle-tier has it's own application object, not linked to the front-end. The front-end creates this app object and uses that as the central "hub" for all child data-objects. But even if the middle is maintaining "state information", it's only data-related state, nothing to do with the front-end, this information is only used by the middle data-objects.
>>
>>What should I do then, to completely seperate the front from the middle, I assumed I was already doing that, but obviously not.
>
>The fact that the middle-tier is maintaining state information, means it is not scalable. If the tier was deployed on a separate computer, and you had 100 users, you would need 100 instances of the "app object" on the middle tier (to keep track of the "current record", as you put it, for each client). If you had a 1000 users, etc.
>
>In a "state-less" scenario, the front-end would would retain the "current record ID" (for example), from one interaction to the next, and pass it to the middle-tier as part of any request (in order for the middle tier to retieve the "current record" from the data-tier and act on it accordingly). The middle-tier would then in effect be "state-less", and one instance could serve any number of requests from any number of front-ends for the "current record". Once performance became an issue, this middle-tier could be propagated to multiple computers and the "middle-ware" would do the load-balancing by ferrying out the request to the computer with the least load, regardless of which computer last satisfied a request for the "current current" for a given client.
>
>The "glue" in these scenarios is generally COM between the UI and the Business facade, and ADO.NET beween the other layers. ADO.NET (via XML) allows one to in effect pass a dataset "by value" (ie. "disconnected") across bounderies without worrying about firewalls, binary protocols, etc.