>Ok, it's getting much clearer now.
>

Clearer for you. Muddier for me.

>So, I assume if it's all done like that and business tier is deployed on a server, clients can connect to it as to remote .Net objects which are still running as Serviced Components on a server and take advantage of COM+ declarative Transactions? Then i only need to make sure the ORM layer doesn't interfere with that and all Business Objects are derived from EnterpriseServices.ServiedComponent. (Doesn't look like they changed this requirement, but that's not a big deal i think).
>

If you use Windows 2000 (COM+ 1.5) then there is a feature called SWC (Services without Components). This is a little-known, little-discussed gem inside .NET 1.1. So you can use code like this (pardon my VB, I'm just pasting the code):

ServiceDomain.Enter(config)
MessageBox.Show("Is caller in everyone role: " & _
    ContextUtil.IsCallerInRole("Everyone").ToString())
ServiceDomain.Leave()

All code between the Enter and Leave runs inside the context of COM+ and your business objects don't have to derive from ServicedComponent.

Read about it here http://www.3leaf.com/default/articles/ea/serviceswithoutcomponents.aspx


> Then for the Security to work I only need to somehow pass the Identity of the client's process to this layer, right? I mean I don't think that
> AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
>will work in case of remote clients each connecting to the same AppDomain, I would assume, but all having different Identities... Or how does it work?
>

That's a good question. I think the security identity is passed to the remote appdomain, but I'm not sure.

>And since it's COM+ serviced I don't have to worry about scalability issues, right? At least in theory? Just make sure I correctly specify which objects are stateless (or what's the word in .Net? "Well known"?) - server decides when to create and delete the instance and it doesn't matter which instance serves which client; and objects that are not stateless - client decides when to instantiate it and when to delete.
>

I think you have to make a decision early on: Use COM+ and get all of its extra capabilities (transactions, security, enterprise services) or use .NET Remoting. Both technologies do similar things, but with COM+ you get a ton of built-in services. With Remoting you will have to roll your own transactions but I'm not sure about security. As far as statefulness, I think the stateful objects would be MarshalByValue so the client can keep the object's state.

Now, any client will talk to a ServicedComponent through a proxy so those should be stateless components, as you say.

In general, I try not to use remoting. Its easier to just have the middle-tier objects instantiated in the client's appdomain.

>And then if it all runs on Windows 2003 Advanced Server(s), I even get failover, right?

I think the product is called Application Center 2000 that provides failover, clustering, load balancing for COM+, but not for plain .NET remoting.