Chapter 11. Remoting
"Remember the First Law of Distributed Computing: Don't Distribute Your Objects." (Martin Fowler, Patterns of Enterprise Application Architecture)
In previous chapters, we have noted that most J2EE applications, especially web applications, do not benefit from a distributed architecture. In most scenarios, it is preferable to co-locate all application components in a single server, to avoid costly remote calls between different layers of the application and the complexity introduced by any remoting infrastructure and a distributed programming model. Logical layering is usually far more important than physical layering. We have seen that lightweight frameworks can help to achieve such clean separation of concerns.
That said, there are valid reasons for choosing a distributed architecture for some applications. If you encounter specific requirements that actually require internal distribution of the application, you need to choose appropriate mechanisms for your particular scenario. For adaptability, applications should be designed so that they allow for introducing selective distribution if needed for exporting certain functionality in a future stage of the project. In this chapter, we will discuss important issues to consider in that respect.
A different kind of remoting is needed for exposing remote services to external clients: for example, to rich clients or other external processes. It's important to stress that this does not require a distributed application ...
Get Expert One-on-One™ J2EE™ Development without EJB™ now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.