Potential tight coupling between clients and complex business objects
Too many method invocations between clients and business objects
Business methods exposed for misuse by clients
Hide complex interactions behind a simple client interface
Reduce the number of business objects exposed to the client across the network
Hide implementation, interactions, and dependencies of business components
Use a business logic class to encapsulate the interactions required with the business objects
Simplifies complex systems
May appear to be a no value pass-thru in simple systems
Should involve more than one business object per facade
Should have more than one facade per system
Decouples the business objects from being aware of one another
Improves perceived network performance for remote interfaces
Centralizes security and transactions in some cases
POJO Business Logic is an example of Session Facade Pattern
You have already implemented the Session Facade Pattern with your POJO business logic from previous work. There is nothing magical about server-side EJBs over POJO business logic, relative to the Session Facade Pattern, except for the enhanced ability to implement remote, transactional, secure, and load-balanced behavior without impacting the focus on the business.
Remote clients require access to server-side resources.
Core service layer (business logic and its business objects) contains fine grain objects and methods
Significant number of fine-grain remote calls will not work
Provide a Remote Facade
Coarse-grain facade over service layer
Contains no detailed business logic -- it calls it
Translates course-grain methods and objects into fine-grain method calls and objects to/from service layer
Bulk accessors wrap fine-grain access methods
Service Layer does not have a remote interface
Fine-grain business objects mapped to database might not be serializable
Business Objects represent too much information or behavior to transfer to remote client
Client may get information they don't need
Client may get information they can't handle
Client may get information they are not authorized to use
Client may get too much information/behavior to be useful (e.g., entire database serialized to client)
Some clients are local and can share object references with business logic
Handling specifics of remote clients outside of core scope of business logic
Layer a Remote Facade over Business Logic
Remote Facade constructs Data Transfer Objects (DTOs) from Business Objects that are appropriate for remote client view
Remote Facade uses DTOs to construct or locate Business Objects to communicate with Business Logic
Clients only get what they need
Clients only get what they understand
Clients only get what they are authorized to use
Remote and Local interfaces to services are different
Makes it harder to provide location transparency
Lightweight Business Objects can be used as DTOs
Remote Facade must make sure they are “pruned” of excess related items before transferring to client
Remote Facade must make sure they are “cleaned” of DAO persistence classes before transferring to client