Keys to Component Developer Exam
In this first series of articles for those thinking about taking the Oracle Certified Professional Java EE 5 Business Component Developer (OCPJBCD) Exam, we will provide an EJB3 Tutorial of the technology. In further articles, we will look more in depth into different aspects that you as a developer need to be aware.

The Enterprise JavaBeans Platform (EJB)
The Enterprise JavaBeans (EJB) is a platform was initially developed by Sun Microsystems for building portable, reusable, and scalable business applications in Java programming language. The goal of EJB was to allow application developers to focus on building business logic without having to spend time on building infrastructure code. In its initial conception EJB platform had been touted as a component model or framework that facilitates the building of enterprise Java applications without having to reinvent services such as transactions, security, automated persistence, or other aspects that you may need for building the application. The reality was very different:
  • The increased complexity in creating and testing EJBs led to slower deployment and test cycles.
  • The Enterprise Java Bean developed were not portable between different application server EJB containers without significant modification
  • EJB applications were much harder to test because of their tight coupling to the EJB container.
  • Large amount of boilerplate code one needed to write in order to implement an EJB (i.e. ejbCreate, ejbRemove, ejbActivate, ejbPassivate, and setSessionContext)
  • Stateful session beans don’t scale because of problems with replicating the session beans.
  • Declarative role-based security is inadequate for many areas that require secure access to resources.


Tutorial: EJB3 Overview for the Component Developer Exam-jee-applicationlayers-1-.jpg



Now, it was only after the advent of the Spring Framework which used a Plain Old Java Object (POJO), Dependency Injection, Inversion of Control and Aspect Oriented Programming in order to, as a basis of building a lightweight framework that allowed one to overlay aspects on to a POJO, that the EJB model was radically changed along these lines so that it became easy to use. This is called the Enterprise JavaBeans version 3 (EJB3) standard for Java Enterprise Edition version 5.
Tutorial: EJB3 Overview for the Component Developer Exam-jee_overview.jpg







In the new version of Enterprise JavaBeans, an EJB is a POJO that executes in the EJB container that provides a number of component services. The business processing artifacts for EJBs are session and message-driven beans. These are developed for a business application and deployed and run in an EJB container. The persistence layer artifact is an entity; this is persisted to the database layer using a persistence provider or persistence engine.

Overview of EJB Architecture
A key thing for any developer to understand if you plan to successfully complete the Component Developer exam, is the EJB3 architecture. The EJB3 architecture provides a standard for developing distributed, object-oriented, component-based business applications. There are three types of EJB components:
  • Session Beans
    Session beans is used to implement business logic in an EJB3 application. They are generally coarse-grained objects encapsulating a business logic. A session bean has a business interface that can be either remote or local. In most cases, a client will make a remote call to a session bean, but there are times that a session bean and its client may reside in the same JVM instance. In such cases the client invokes the local interface of the session bean. The diagram below shows a web container client invoking using the session bean’s local interface:
    Tutorial: EJB3 Overview for the Component Developer Exam-ejb3sessionbeans.jpg
  • Message Driven Beans

    Message-driven beans are also used to implement business logic in an EJB3 application. A message-driven bean is a bean that receives JMS messages asynchronously. Like session beans, they tend to be coarse-grained . Clients, which can be Java applications, session beans or other systems that can communicate via JMS, sends a JMS message to a message queue or topic that is managed by a JEE container or dedicated JMS server. Below is an example of a client sending a JMS message which is received by a message-driven bean:
    Tutorial: EJB3 Overview for the Component Developer Exam-ejb3messagedrivenbeans.jpg
  • Entities

    Entities are classes that need to be persisted; their state is stored in a relational database or some other storage system. In difference to session beans or message driven beans, entities do not have business logic other than validation. Also, compared to pre-EJB3 entity bean which were extremely cumbersome to write, test and use, entities are just simple Java objects. The benefit of this is that you can use object oriented feature such as inheritance can be used and they can be persisted through a persistence provider or persistence engine that implements the JPA specification. In fact we regularly perform CRUD (Create, Read, Update and Delete) operations on entities as well as querying them.
    Tutorial: EJB3 Overview for the Component Developer Exam-entity.jpg






All the components are built to be reused and to be portable between JEE 5 Application Servers. So if you are an online merchant, your company can build a module to handle credit and debit card purchases. This module can then be reused across several different types of online stores that your company has targeting different sectors of the retail market. So there could be an online store for children’s clothes, and another online store for sport clothes. Both could use the same module for handling credit and debit card purchases. Since it the credit and debit card charging module is implemented as an EJB3 component, it is easier for each new application to access it by simply making a call to it when it requires that functionality. It is important to note that it is not even necessary for the second application to understand its implementation.
At the same time building a reusable component requires careful planning since across enterprise applications within an organization, it is often a challenge to find business logic that may be reusable. We are now getting into the realm of what is called Service Orientated Architecture. This is design principles and methodologies used to develop interoperating services. The key enabling technology for this is called web services which can be built using EJB3. So if you and your organization are focused on the reusability of EJB3 components and/or web services, EJB3 has much to offer as a framework. In the figure 2, you see it is possible to access an EJB either via a web container or directly from a Java SE application, such as Swing or Java FX. The Java application can be stand-alone, or can be run from an Application Client Container that enables a client executing in its own Java Virtual Machine (JVM) outside the EJB3 container to access a limited number of Java EE services.

The container in which EJBs are deployed and run are designed to make applications scalable, multi-user, and thread-safe. An EJB3 container also provides a number of services that an enterprise scale business application is likely to need. We will discuss these services below.

Overview of EJB Container Services
Another key part of the Component Developer exam, is to know the services that are provided the EJB container. There are a large number of services that the EJB3 container that:
  • supports concurrency so that all EJB components are thread-safe.
  • provides pooling for EJB component instances. Pooling contributes to the scalability of the EJB3 architecture.
  • provides load balancing and clustering that contribute to the scalability of EJB.
  • provides a naming service using the Java Naming and Directory Interface (JNDI), for accessing EJBs or any other container-managed resource such as JMS queue connections. A component developer can also use EJB3’s simpler annotation-based dependency injection facility which is available in many cases as an alternative to JNDI.
  • supports Java RMI-IIOP (Remote Method Invocation run over Internet Inter-Orb Protocol), that enables a session to be remotely accessed by a client. Clients don’t need to know whether the invocation of an EJB is remote or local (location transparency).
  • provides a container-managed transaction service.
  • provides supports for JMS-based message-driven beans.
  • provides basic scheduling capability through the Timer service.
  • provides a new Interceptor service that allows common, tangential aspects of EJB components to be separated from any business logic. It is based on Aspect Oriented Programming (AOP).
  • provides a means to convert a stateless session bean into a web service.
  • provides standards for both the authentication, which addresses the validation of the identity of a user and authorization, which is concerned with controlling a user's access to an application, or part of an application as aspects of security for EJBs.
Finally the last service the is provide by EJB3 Containers is the service needed by most business applications for persisting entities. This service is delegated by the container to a Java Persistence API (JPA) persistence engine (see figure 1). As it is the most predominant service used in EJB containers is the persistence service. JPA has been issued as a separate specification JPA services. The main services include:
  • Entity Manager - provides services for persistence, transaction management, and managing the lifecycle of entities.
  • Object/Relational Mapping - metadata annotations are provided for mapping entities onto relational database tables.

  • The Java Persistence Query Language (JPQL) - is used for retrieving persisted entities
JPA inspires itself a great deal from similar object/relational mapping technology such as Hibernate and Oracle Toplink. In fact, Toplink and Hibernate are the actual default persistence engines for a number of EJB3 containers. (i.. Sun's GlassFish and Oracle Application Server 11g use Toplink as the embedded persistence engine while the JBoss EJB3 container uses Hibernate as the embedded persistence engine). As the defaults are pluggable it is possible to use Hibernate with GlassFish. Another reason for separating JPA in its own specification is that when an application needs persistence but doesn’t need an EJB container, it is possible to use JPA on its own.

EJB3 Simplified Programming Model
Another aspect of the Component Developer exam, is to understand the EJB3 Programming Model. As noted above there were quite a number of significant problems that one needed to overcome in order to implement an application using EJB2. Now in, EJB3 it is possible for you to develop an EJB component using POJOs and POJIs that know nothing about platform services. On top, you then apply configuration metadata, using annotations, to these POJOs and POJIs to add platform services such as remoteability, web services support, and lifecycle callbacks only as needed. To summarize the main features in EJB:
  • Simplified Persistence API
  • Metadata Annotations - used as an alternative to XML deployment descriptor for configuring EJB components and specifying object/relational mappings with entities
  • Improved Query Language - EJB QL provides enhancements for: projections, GROUP BY and HAVING clauses, Joins, Subqueries, Dynamic Queries, Queries with parameters, Bulk update and delete operations
  • Use of Defaulting - now extensively used to reduce the need for configuration for the most common expected behavior
  • Dependency Injection - inspired by the Spring Framework as an alternative to using JNDI for looking up container managed resources
  • Simplification of Sessions Beans - the elimination of component and home interfaces as well as callback interfaces unless absolutely required.
So in short, EJB service definitions have been moved into deploy and runtime configurations. Mechanical steps have been automated by the platform itself. So now it is extremely easy to create an EJB.

Packaging and Deploying EJB3 Applications
The next key part that you need to know for the Component Developer exam, is how to package and deploy JEE5 applications using EJBs. Once you have built your EJBs with session business-logic tier with session and message-driven beans, used entities to support the persistence tier, and built a presentation tier using for example, JSP or JSF, to access the business logic, you are now in a position to assemble and deploy your application. One of the real successes of Java EE applications lies in its ability to deliver on Java’s promise of write once, run anywhere (WORA) application. Failing to fully grasp this step, you will not be able to realize the level of portability for your application that you desire. To deploy and run an application, you have to package the complete application together—the web module and EJBs—and deploy to an application server. In order to do this, you create a Java archive (JAR) file. Typically, a JAR file is a file in zip format that contains classes. But enterprise Java applications are packaged as specialized versions of JAR files (i.e. EAR, WAR, and EJB-JAR modules) before being deployed to a Java EE–compliant application server. One of the advantages of having these formats defined as part of the specification is that they are portable across application servers. See diagram below.

Tutorial: EJB3 Overview for the Component Developer Exam-ejbpackaging.jpg





Below is a table with the lists the archives or modules supported by Java EE 5 and their contents. Note that each archive type is used for packaging a specific type of module, such as EJB or web. For instance, a WAR is used to package a web-tier application module, and the EAR file is intended to be the über archive containing all the other archives so that in the end, you’re only deploying one file. The application server will scan the contents of the EAR and deploy it. Similarly to create these type of files, you use the jar utility that comes with JDK. Afterwards you assemble all the JAR files into one EAR file for deployment.


Type
Description
Descriptor
Content
CAR Client application archives application-client.xml Thick Java client for EJBs
EAR Enterprise application archive application.xml Other Java EE modules such as EJB-JARs
EJB-JAR EJB Java archive ejb-jar.xml Session beans, message-driven beans, and or entities. Requires a persistence.xml for entities that are packaged.
RAR Resource adapter archives ra.xml Resource adapters
WAR Web application archives web.xml Web application artifacts such as servlets, JSPs, JSF, static files, etc. Entities can also be packaged in this module. Needs a persistence.xml for entities that are packaged.






During the deployment process, the application server determines the module types, validates them, and takes appropriate steps so that the application is avail- able to users. Although all application servers have to accomplish these goals, it’s up to the individual vendor exactly how to implement it. One area where server implementations stand out is in how fast they can deploy the archives.
When the application is deployed, the application server determines the module types, validates them, and takes the necessary steps so that the application is available to users. Although every application server must accomplish these goals, the application vendor is free as to how to do this. One area where server implementations stand out is in how fast they can deploy the archives while at the same time, following the rules of the specification as well as in what order the loading of classes takes place.

Java Enterprise Edition 5 Seven Key Roles
The Java EE platform defines different roles and responsibilities relating to development, assembly, and deployment of Java EE applications. You will need to remember all of these roles for the Component Developer exam. The roles defined by the specifications are:
  • Enterprise Bean Provider - is responsible for defining and implementing the business logic and structure of an enterprise bean.
  • Application Assembler - is responsible for combining EJBs into EJB modules, nd entities into persistence archives and the combines these modules together with other Java EE modules for an application
  • Deployer - takes an application that has been assembled by an App Assembler and deploys it to a specific EJB container.
  • EJB Service Provider - Specialist in the area of distributed transactions management, distributed objects, and other lower-level system-level services
  • EJB Container Provider (Container Provider) - Provides deployment tools necessary for the deployment of enterprise beans and the runtime support for the deployed enterprise bean instances.
  • Persistence Provider - Expert in object/relational mapping, query processing, and caching. Provides tools and runtime support for the management of persistent entities and their mapping to the database.
  • System Administrator - Responsible for the configuration and administration of the enterprise's computing and networking infrastructure that includes the EJB server and container.
What is interesting is that database administrator is not one of the defined Java EE roles. Despite this, the importance of this role cannot be overlooked, especially in large corporations where relational databases are outside the control of the application developers. Developers, Assemblers, and Deployers may need to work with the DBAs in order to successfully build and release Java EE applications.

You're Ready for This Part of the Component Developer Exam!
OK. That’s it! In our next article on preparing for the Component Developer Exam, we will look more in depth about EJB instances and it’s lifecycle.