Clarification on distributed data security
Adrian Batemen wonders if I meant you would expose the data components at the point of physically separating tiers:
First of all, I'd be reluctant to make the distribution break purely at the data access level. For me, the data access tier is all about dealing with the storage of entities. Each component deals with only one entity and as such each method only reads or writes to one entity type at a time. (By entity I typically mean the nouns in your system and these tend to tie to the main tables in a database - things like a person, product, or order.) The next layer up uses business rules to combine these entity operations together into meaningful business transactions (e.g. creating an order might create an order entity and add line item entities to it, etc.). I am more inclined to provide a distributed service using a business facade over these business rules and for that to be the security barrier. This helps to ensure that data integrity is maintained by the business rules and promotes reuse of the service in more robust manner. As I said, I'm not sure if this is what Robert means or whether we differ here.
I apologize if this wasn't made clearer in my previous post. I always advocate some kind of facade layer (could be a business rules layer, could be something else) over the data components. In fact, the data components should be hosted in-process to the server machine only. This makes sure, in our example, the web server components can never directly call the data components hosted on another machine.