The Rational® Application Developer implementation of session facades involves the creation of a session bean that encapsulates the data and logic properties of one or more CMP entity beans. This session bean interacts with a corresponding SDO that is created along with the session bean and is customized for representations of data specified in one or more CMP entity beans. The Create Session Bean Facade wizard is used to generate annotations in the CMP entity beans, which are then used to generate session bean facades. With the wizard, you can graphically select the CMP entity beans and all or some of their CMP attributes and CMR fields to include in the new SDOs. The result is a session bean instance that references the corresponding SDO Graph and interacts with the EJBMediator using EJB-QL for any persistence queries.
See Annotations for session facades and SDOs for reference information about the @ws.sdo and @ws.sbf tag sets that are used to define the session bean facades and SDOs.
Data objects were originally designed as a means to buffer the actual data on the business-tier from client applications. An example would be data access objects, which are a standardized method to abstract and encapsulate data from different sources.
Service Data Objects (SDOs) are a type of data object that derive their properties from CMP entity beans. They are able to encapsulate in a single object a subset of the individual container-managed relationship (CMR) properties from one or more CMP entity beans, allowing coarser-grained transactions between the client application and the business-tier. Changes to data are monitored by data graphs, which manage one or more SDOs, while a data mediator service on the middle tier manages data transfer with the client.
Session facades have traditionally been used to alleviate the complexity and performance problems that resulted from the tight coupling of client-tier and business-tier applications and objects. Traditional distributed enterprise applications used enterprise beans that exposed the business data and logic to the client-tier, with session beans used for processes and entity beans used for data representation.
With larger applications, one consequence of this is that the interaction of the client-tier and business-tiers grows, and the complexity of the business logic becomes increasingly entangled with the client application. Thus, clients must understand and respond appropriately to the overall business logic and data.
Maintaining data integrity between client and server could easily become a massive task, requiring client and server synchronization through an increase in the number of network calls to and from the client as well as an expansion of the complexity of the client program itself.
Session facades were introduced as a way to eliminate many of these situations by separating data from manipulation by clients. This was done by creating a session facade for a CMP entity bean that would receive an abstraction of data, as well as the business methods necessary for this data, from the business-tier. Data exchanges could now be handled by a mediator, usually the CMP facilities of EJB mechanism itself. Clients could now work only with the methods and data representations and would no longer be responsible for data integrity and compliance with overall business logic.
However, traditional session facade implementations have limitations. Only a single entity bean instance could be used for a given session facade, even though advanced applications would likely involve data from more than one CMP definition. This would result in many relatively fine-grained network calls between the client and the business-tier, resulting in possible network performance degradation.