Match the seven EJB roles with the corresponding description of the role's responsibilities
I've never understood the infatuation with JEE roles and such. I get the feeling that someone spent alot of time thinking these role things up, and nobody's had the guts to pull it out of the specification. I don't know. I guess being able to categorize the various hats people have to wear to bring a JEE EJB 3.0 application to fruition. It must have some value somewhere.
The seven EJB roles involved in bringing a JEE EJB application to fruition include:
Enterprise Bean Provider
EJB Server Provider
EJB Container Provider
The Enterprise JavaBeans architecture deﬁnes seven distinct roles in the application development deployment life cycle. Each EJB Role may be performed by a different party. The EJB architecture speciﬁes the contracts that ensure that the product of each EJB Role is compatible with the product of the other EJB Roles. The EJB speciﬁcation focuses on those contracts that are required to support the development and deployment of ISV-written enterprise beans. In some scenarios, a single party may perform several EJB Roles. For example, the Container Provider and the EJB Server Provider may be the same vendor. Or a single programmer may perform the two EJB Roles of the Enterprise Bean Provider and the Application Assembler. The following sections deﬁne the seven EJB Roles.
Enterprise Bean Provider
The Enterprise Bean Provider (Bean Provider for short) is the producer of enterprise beans. His or her output is an ejb-jar ﬁle that contains one or more enterprise beans. The Bean Provider is responsible for the Java classes that implement the enterprise beans’ business methods; the deﬁnition of the beans’ client view interfaces; and declarative speciﬁcation of the beans’ metadata. The beans’ metadata may take the form of metadata annotations applied to the bean classes and/or an external XML deployment descriptor. The beans’ metadata—whether expressed in metadata annotations or in the deployment descriptor—includes the structural information of the enterprise beans and declares all the enterprise beans’ external dependencies (e.g. the names and types of resources that the enterprise beans use). The Enterprise Bean Provider is typically an application domain expert. The Bean Provider develops reusable enterprise beans that typically implement business tasks or business entities. The Bean Provider is not required to be an expert at system-level programming. Therefore, the Bean Provider usually does not program transactions, concurrency, security, distribution, or other services into the enterprise beans. The Bean Provider relies on the EJB container for these services. A Bean Provider of multiple enterprise beans often performs the EJB Role of the Application Assembler.
The Application Assembler combines enterprise beans into larger deployable application units. The input to the Application Assembler is one or more ejb-jar ﬁles produced by the Bean Provider(s). The Application Assembler outputs one or more ejb-jar ﬁles that contain the enterprise beans along with their application assembly instructions. The Application Assembler can also combine enterprise beans with other types of application components when composing an application. The EJB speciﬁcation describes the case in which the application assembly step occurs before the deployment of the enterprise beans. However, the EJB architecture does not preclude the case that application assembly is performed after the deployment of all or some of the enterprise beans. The Application Assembler is a domain expert who composes applications that use enterprise beans. The Application Assembler works with the enterprise bean’s metadata annotations and/or deployment descriptor and the enterprise bean’s client-view contract. Although the Assembler must be familiar with the functionality provided by the enterprise bean’s client-view interfaces, he or she does not need to have any knowledge of the enterprise bean’s implementation.
The Deployer takes one or more ejb-jar ﬁles produced by a Bean Provider or Application Assembler and deploys the enterprise beans contained in the ejb-jar ﬁles in a speciﬁc operational environment. The operational environment includes a speciﬁc EJB server and container.
The Deployer must resolve all the external dependencies declared by the Bean Provider (e.g. the Deployer must ensure that all resource manager connection factories used by the enterprise beans are present in the operational environment, and he or she must bind them to the resource manager connection factory references declared in the metadata annotations or deployment descriptor), and must follow the application assembly instructions deﬁned by the Application Assembler. To perform his or her role, the Deployer uses tools provided by the EJB Container Provider. The Deployer’s output is a set of enterprise beans (or an assembled application that includes enterprise beans) that have been customized for the target operational environment, and that are deployed in a speciﬁc EJB container.
The Deployer is an expert at a speciﬁc operational environment and is responsible for the deployment of enterprise beans. For example, the Deployer is responsible for mapping the security roles deﬁned by the Bean Provider or Application Assembler to the user groups and accounts that exist in the operational environment in which the enterprise beans are deployed.
The Deployer uses tools supplied by the EJB Container Provider to perform the deployment tasks. The deployment process is typically two-stage:
• The Deployer ﬁrst generates the additional classes and interfaces that enable the container to
manage the enterprise beans at runtime. These classes are container-speciﬁc.
• The Deployer performs the actual installation of the enterprise beans and the additional
classes and interfaces into the EJB container.
In some cases, a qualiﬁed Deployer may customize the business logic of the enterprise beans at their deployment. Such a Deployer would typically use the Container Provider’s tools to write relatively simple application code that wraps the enterprise bean’s business methods. EJB Server Provider
The EJB Server Provider is a specialist in the area of distributed transaction management, distributed objects, and other lower-level system-level services. A typical EJB Server Provider is an OS vendor, middleware vendor, or database vendor.
The current EJB architecture assumes that the EJB Server Provider and the EJB Container Provider roles are the same vendor. Therefore, it does not deﬁne any interface requirements for the EJB Server Provider.
EJB Container Provider
The EJB Container Provider (Container Provider for short) provides:
• The deployment tools necessary for the deployment of enterprise beans.
• The runtime support for the deployed enterprise bean instances.
From the perspective of the enterprise beans, the container is a part of the target operational environment. The container runtime provides the deployed enterprise beans with transaction and security management, network distribution of remote clients, scalable management of resources, and other services that are generally required as part of a manageable server platform.
The “EJB Container Provider’s responsibilities” deﬁned by the EJB architecture are meant to be requirements for the implementation of the EJB container and server. Since the EJB speciﬁcation does not architect the interface between the EJB container and server, it is left up to the vendor how to split the implementation of the required functionality between the EJB container and server.
The expertise of the Container Provider is system-level programming, possibly combined with some application-domain expertise. The focus of a Container Provider is on the development of a scalable, secure, transaction-enabled container that is integrated with an EJB server. The Container Provider insulates the enterprise bean from the speciﬁcs of an underlying EJB server by providing a simple, stan- dard API between the enterprise bean and the container. This API is the Enterprise JavaBeans compo- nent contract.
The Container Provider typically provides support for versioning the installed enterprise bean components. For example, the Container Provider may allow enterprise bean classes to be upgraded without invalidating existing clients or losing existing enterprise bean objects. The Container Provider typically provides tools that allow the System Administrator to monitor and manage the container and the beans running in the container at runtime.
The expertise of the Persistence Provider is in object/relational mapping, query processing, and caching. The focus of the Persistence Provider is on the development of a scalable, transaction-enabled runtime environment for the management of persistence.
The Persistence Provider provides the tools necessary for the object/relational mapping of persistent entities to a relational database, and the runtime support for the management of persistent entities and their mapping to the database.
The Persistence Provider insulates the persistent entities from the speciﬁcs of the underlying persistence substrate, providing a standard API between the persistent entities and the object/relational runtime. The Persistence Provider may be the same vendor as the EJB Container vendor or the Persistence Provider may be a third-party vendor that provides a pluggable persistence environment as described.
The System Administrator is responsible for the conﬁguration and administration of the enterprise’scomputing and networking infrastructure that includes the EJB server and container. The SystemAdministrator is also responsible for overseeing the well-being of the deployedenterprise beans appli-cations at runtime.