Tuesday, August 26, 2008

Match the seven EJB roles with the corresponding description of the role's responsibilities SCBCD Exam Objective.

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
Application Assembler
EJB Server Provider
EJB Container Provider
Persistence Provider
System Administrator

The Enterprise JavaBeans architecture defines seven distinct roles in the application development deployment life cycle. Each EJB Role may be performed by a different party. The EJB architecture specifies the contracts that ensure that the product of each EJB Role is compatible with the product of the other EJB Roles. The EJB specification 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 define 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 file that contains one or more enterprise beans. The Bean Provider is responsible for the Java classes that implement the enterprise beans’ business methods; the definition of the beans’ client view interfaces; and declarative specification 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.

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 files produced by the Bean Provider(s). The Application Assembler outputs one or more ejb-jar files 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 specification 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 files produced by a Bean Provider or Application Assembler and deploys the enterprise beans contained in the ejb-jar files in a specific operational environment. The operational environment includes a specific 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 defined 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 specific EJB container.
The Deployer is an expert at a specific operational environment and is responsible for the deployment of enterprise beans. For example, the Deployer is responsible for mapping the security roles defined 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 first generates the additional classes and interfaces that enable the container to
manage the enterprise beans at runtime. These classes are container-specific.
• The Deployer performs the actual installation of the enterprise beans and the additional
classes and interfaces into the EJB container.

In some cases, a qualified 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 define 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” defined by the EJB architecture are meant to be requirements for the implementation of the EJB container and server. Since the EJB specification 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 specifics 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.

Persistence Provider

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 specifics 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.

System Administrator

The System Administrator is responsible for the configuration 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.

No comments: