CHAPTER 1 INTRODUCTION TO THE EJB ARCHITECTURE methods simultaneously within the same elb or entity.for specifving behavior in metadata.in cases where the same edence in resolving the conflict.Additional benefits of this appr this chapter. Configuration by Exception Coupled with the ability to specify behavior declaratively is the strong use of intelligent defaults in EJB.Much behavior is attached automatically to an EJB or an entity without it being declared explicitly,such as the transactional behavior of session bean methods and the names of the table and columns that map to an entity's persistent data properties. An annotation,or its counterpart in XML,needs to be specified explicitly only when non-default behavior is desired. In the most common cases,where the default behavior is leveraged,this approach leads to very sparse,clean code. This development model is known as configuration by exception,because only in exceptional(non-default)cases is it necessary to configure the behavior of the component explicitly. Scalability Large-scale applications demand the ability to scale well as the client load increases.The EJB server employs resource pooling to maximize object reuse,utilizes a persistence c objects,and implen re ent sy n(RD concurr s.The EJB cor ner also manages an EJB's life cycle allo wing dependent resources to e freed up and reused to opumize pertormance Location Transparency te access,allowing them to be acce ent, an ance transpar tly manage th ion details Transactionality The lava transaction apl(ta)defines a standard api for distributed transactions.and the eib container act ITA transac tion o EIBs.Since its inc managed the EJB spec has defined a standard model for declaratively specifying container on ente rise beans. Multiuser Security Method-level access control may be specified declaratively on EJBs,enforcing user-and role-level privileges defined by application server administrators. Portability Spec-compliant enterprise beans are deployable to any application server that implements EJB,at least in theory In practice(and this was particularly true ofreleases prior to EJB 3),vendors provided their own metadata definitions that enterprise bean developers grew to rely upon,locking them into a particular vendor's implementation.As EJB has matured,it has grown to incorporate many of these formerly platform-specific features,so that EJBs implemented today are far more portable than in the past. Chapter 1 ■ Introduction to the EJB Architecture 3 methods simultaneously within the same EJB or entity, for specifying behavior in metadata. In cases where the same piece of metadata is defined both in an annotation and in XML, the XML declaration takes precedence in resolving the conflict. Additional benefits of this approach are explored later, in the “EJB 3 Simplified Development Model” section of this chapter. Configuration by Exception Coupled with the ability to specify behavior declaratively is the strong use of intelligent defaults in EJB. Much behavior is attached automatically to an EJB or an entity without it being declared explicitly, such as the transactional behavior of session bean methods and the names of the table and columns that map to an entity’s persistent data properties. An annotation, or its counterpart in XML, needs to be specified explicitly only when non-default behavior is desired. In the most common cases, where the default behavior is leveraged, this approach leads to very sparse, clean code. This development model is known as configuration by exception, because only in exceptional (non-default) cases is it necessary to configure the behavior of the component explicitly. Scalability Large-scale applications demand the ability to scale well as the client load increases. The EJB server employs resource pooling to maximize object reuse, utilizes a persistence cache to avoid repeatedly querying or creating the same objects, and implements an optimistic locking strategy in the middle tier to reduce load on the relational database management system (RDBMS) and to avoid concurrency locking issues. The EJB container also manages an EJB’s life cycle, allowing dependent resources to be freed up and reused to optimize performance. Location Transparency EJBs may be configured for remote access, allowing them to be accessed across a network connection. A client, which may be another EJB, simply requests an instance of a remote EJB, and the local and remote EJB containers transparently manage the communication details. Transactionality The Java Transaction API (JTA) defines a standard API for distributed transactions, and the EJB container acts as a JTA transaction manager to EJBs. Since its inception, the EJB spec has defined a standard model for declaratively specifying container-managed transactional behavior on enterprise beans. Multiuser Security Method-level access control may be specified declaratively on EJBs, enforcing user- and role-level privileges defined by application server administrators. Portability Spec-compliant enterprise beans are deployable to any application server that implements EJB, at least in theory. In practice (and this was particularly true of releases prior to EJB 3), vendors provided their own metadata definitions that enterprise bean developers grew to rely upon, locking them into a particular vendor’s implementation. As EJB has matured, it has grown to incorporate many of these formerly platform-specific features, so that EJBs implemented today are far more portable than in the past