Admittedly there are a few slightly different slants on this, but I like to think of a session facade as being a way of grouping/performing functionality on one or more entity beans. In other words, a session bean would hide away access to one or more entity beans, therefore providing a good way to encapsulate functionality, demarcate transactionality and, of course, reduce the network overhead of the client manipulating multiple entity beans. A business delegate on the other hand, for me anyway, is a way of providing a further abstraction of the functionality provided, typically, by one or more session facades. There are a couple of benefits in doing this as it reduces the coupling between the client and the components running on the server, and additionally it can provide a much simpler client interface. A side-effect of this, and depending on how you implement it, is that you can negate the need for the client to get involved with the complexities involved with locating remote services and handling the various exceptions that might get thrown. In terms of the interface it provides, it can either act as a proxy or a mediator. Business delegates are usually implemented as regular JavaBeans, that when constructed look up the facade(s) that it will make use of and cache them for future use. The client then uses the interface of the business delegate, which in turn hides all those nasty RemoteExceptions by instead catching them and rethrowing business related exceptions. Check out the patterns forum on www.theserverside.com and the previous link for more information, and also for additional implementation options and strategies. Hope that helps Simon