 <p>It seems that whenever you talk about anything J2EE related - there are always a whole bunch of assumptions behind the scenes - which people assume one way or the other - which then leads to confusion. (I probably could have made the question clearer too.)</p> <p>Assuming (a) we want to use container managed transactions in a strict sense through the EJB specification then</p> <p>Session facades are a good idea - because they abstract away the low-level database transactions to be able to provide higher level application transaction management.</p> <p>Assuming (b) that you mean the general architectural concept of the session façade - then </p> <p>Decoupling services and consumers and providing a friendly interface over the top of this is a good idea. Computer science has solved lots of problems by 'adding an additional layer of indirection'. </p> <p>Rod Johnson writes "SLSBs with remote interfaces provide a very good solution for distributed applications built over RMI. However, this is a minority requirement. Experience has shown that we don't want to use distributed architecture unless forced to by requirements. We can still service remote clients if necessary by implementing a remoting façade on top of a good co-located object model." (Johnson, R "J2EE Development without EJB" p119.)</p> <p>Assuming (c) that you consider the EJB specification (and in particular the session façade component) to be a blight on the landscape of good design then:</p> <p>Rod Johnson writes "In general, there are not many reasons you would use a local SLSB at all in a Spring application, as Spring provides more capable declarative transaction management than EJB, and CMT is normally the main motivation for using local SLSBs. So you might not need th EJB layer at all. " <a href="http://forum.springframework.org/showthread.php?t=18155" rel="nofollow noreferrer">http://forum.springframework.org/showthread.php?t=18155</a></p> <p>In an environment where performance and scalability of the web server are the primary concerns - and cost is an issue - then the session facade architecture looks less attractive - it can be simpler to talk directly to the datbase (although this is more about tiering.)</p>