I'm looking book/online resourses about JEE application deployment pattens. Especially I want to know patterns when to use local interfaces when remote ones (how many nodes I need to?). The key question is to use single EAR (EJB and WAR) or separate nodes for EJB and WARs.
Resources I've found are bitty outdated, they concentrate on EJB2 or desing patterns. I'm intersted into new techlologies like EJB3, Spring or Seam.
First, for application servers such as WebSphere you can have a single EAR which contains one (or more) WARs and one (or more) EJB JARs and each WAR and JAR may be deployed to different servers. Hence this need not be a question as to how many EARs, the deployment pattern is a separate problem. You may decide to produce two EARs, but that's not forced by the JEE specification as such.
Second, at development time you do need to decide whether your EJBs shall expose a Remotely callable interface. This is first of all a design decision. APIs that are suitable for local invocation may not necessarily be suitable for remote invocation. For example, a very fine grained API may incur excessive message overhead - if we are going expose a remote api then we tend to favour coarse-grained APIs.
Third, EJB 3.0 does not fundamentally change the architectural and design decisions concerning whether a remote deployment pattern is appropriate. EJB 3.0 gives a much simpler programmign model over EJB 2.x, so have much less code/XML to write, but in terms of the resulting deployment pattern there is no actual change in what is happening in terms of processing or bytes flowing across networks. Not being a Spring or Seam developer, I can't be sure that Spring or Seam would say the same, but my guess is that fundamental architectural decisions such as remote or not would be technology agnostic.
So what forces might lead you to deploy Web and EJB to different tiers?
Co-location: Simplicity, fewer failure modes, reduced network over-head.
Ditributed EJB/WAR: Separate scalability (you can add more processing power to the Web tier or EJB tier indepently), Support for multiple clients, the same business logic can be exposed to other client (which may also result in scalability needs ), indenpendent maintenance releases (patches to Web don't perturb EJB).