In this article, we will look at Business Tier in Java EE. We will look explain and contrast the approaches for building a business tier using entity beans, entities, stateful and stateless session beans and message driven beans. We will go into detail into how to these approaches work with the different container managed persistence strategies. This is part of a larger series of articles to help you prepare for the java architect exam. The most recent article looked at common java application architecture, ďTutorial:Review of Enterprise Integration Architecture EAI for the Java Architect ExamĒ.

Enterprise Java Bean

Modern enterprise applications apply the concept of separation of concerns in order to divide the responsibility over a number of layers. The most commonly used application architecture is the 3-layer model that consists of presentation, business, and database layers. The presentation layerís responsibility is to presenting a user interface that is used to handle interactions with the end user. The business layerís responsibility is for executing business logic. And the database layerís responsibility is to persist business data in permanent storage such as a relational database management system. This layered approach is very useful for managing complexity since each layer has a distinct responsibility.

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-common3tierarchitecture.jpg
Figure:Common 3-Layer Architecture

The Java Enterprise Edition (Java EE) platform provides services to enterprise applications using this multi-layered application architecture that applies the concept of separation of concerns. Java EE applications are web-enabled and JavaĖbased. This means that as is the case with Java, that the code can be written once and deployed on any container that supports the Java EE standard. In practical terms, containers are part of an application server that supports the Java EE specification. Fortunately for us, the Java EE specification is supported by a wide number of vendors such as Sun, IBM, Oracle, BEA Systems as well as open-source ventures such as JBoss.

The components which may be used for implementing the responsibilities for the presentation layer technologies in Java EE include servlets, JSP pages, and JSF components. These components can be developed for a business application and then deployed and run in a web container. The client would interact with the web container via a browser or an applet and would use either http or https internet protocol as the means of communication.

As for the components that implement the responsibilities of the business layer are Enterprise JavaBeans. Enterprise JavaBeans must be subdivided into the business layer in one layer that deals with business processing and then another layer that deals with persistence. In EJB the business layer components are session and message-driven beans. They are developed and then deployed and run in an EJB container to handle all business processing. The persistence component is called an entity. Entities are persisted to the database layer via a persistence provider or persistence engine. The persistence engine implements specification known as the Java Persistence API (JPA). The figure below shows the standard Java EE 5 application architecture:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-javaeearchitecture.jpg
Figure:Java EE Architecture

In our figure, the 3-layer model has been broken up into 5-layers. This is because we are making a distinction between client and web as well as business logic and persistence layers. In this case, we can refer to Java EE application architecture as n-layer or multi-layer. The Java EE container will therefore offer many other services such as web services, the Java Messaging Service (JMS), and resource adapters.

Finally the figure shows that it is possible to access an EJB directly from a Java SE application such as Swing while avoiding a web container. The Java application can be either stand-alone, or run from an Application Client Container (ACC). An ACC allows a client that executes in its own Java Virtual Machine (JVM) outside the EJB container to access a certain number of Java EE services.

The EJB 3 Application Architecture

The EJB 3 application architecture provides a standard for developing distributed, object-oriented, component-based business applications. The components developed using an EJB framework are either session or message-driven beans or both. These components are known as EJBs. EJBs tend to be coarse-grained objects that encapsulate a specific business process. One can combine a specific set of EJBs in order to create a business application. Also if EJBs are well designed EJBs, they can be reused by other applications. They can also be distributed across different computer servers and then be invoked by a remote client from a different system on the network.

If the EJB is a session bean, it must have a business interface that can be either remote or local. The figure below shows a remote client invoking a remote interface of a session bean:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-clientinvkrmtesessbean.jpg
Figure:Client Invoking Remote Interface of Session Bean

Itís possible for the session bean and its client to 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 the local interface of a session bean:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-clientlocalinterf.jpg
Figure:Client Invoking Local Interface of Session Bean

If the EJB is a message-driven bean, it serves as the asynchronous recipient of a JMS message. The client can be a Java application or Java EE component such as a session bean. It sends a JMS message to a message queue or topic. The message queue or topic can be managed by either a Java EE container or a dedicated JMS sever. The figure below shows a client sending a JMS message to a queue which is then read by a message-driven bean:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-clientsndmessbean.jpg
Figure:Client Sending JMS Message that Invokes Message Driven Bean

The last component for EJBs are known as entities. They are normally fine-grained objects that are persisted into long-term storage. As entities are Java objects, they can utilize object-oriented features such as inheritance and polymorphism. They are persisted via a persistence provider or persistence engine that has implemented the JPA specification. The persistence engine can then run either within an EJB container or outside a container if the business application does not need other EJB services. Although, entities are not strictly speaking EJBs, since they are not really a remotely accessible component, we include entities unless the context requires us to make that distinction. In that case, when we refer to EJB components, we mean session and message-driven beans and not entities.

EJB Container Services

The containers for EJBs, which are used for deployment as well as execution provides a number of services that are designed to make applications enterprise ready. EJB containers support concurrency so all EJB components are thread-safe and pooling, load balancing and clustering for EJB component instances in order to facilitate the scalability of the EJB application architecture.

EJB containers have a naming service, the Java Naming and Directory Interface (JNDI), that is used for accessing EJBs or any other container-managed resource such as JMS queue connections. It also provides an annotation-based dependency injection facility is available that serves as an alternative to JNDI in many cases. EJB containers support Remote Method Invocation run over Internet Inter-Orb Protocol (RMI-IIOP). This protocol enables a client to remotely access an EJB irrespective of whether the invoked EJB is remote or residing in the same JVM. This feature is known as location transparency.
EJB containers provides a container-managed transaction service, messaging through the use of JMS-based message-driven beans, a basic scheduling capability called the Timer service, as well as a new service called the Interceptor service. This service allows for crosscutting concerns such as logging to be separated from any business logic. This concept is based on Aspect Oriented Programming (AOP). Some services require some initialization or cleanup to be used properly. EJB Containers also provide lifecycle callback services for the different EJB component types. They act as a hook for the bean provider to receive these events for all callback notifications for an EJB.

EJB containers provide a service that allows the conversion of a stateless session bean into a web service. The support for web services is based on the Java API for XML-based Web Services (JAX-WS) 2.1 specification, as well its predecessor, the Java API for XML- based RPC (JAX-RPC) 1.1. Finally, EJB containers provide a core set of security services that application developers can use to integrate declaratively and programmatically both the authentication and authorization aspects of security. Authentication is concerned with validating the identity of a user and authorization is concerned with controlling a user's access to an application, or part of an application.

The JPA Persistence Engine

There is actually one other service that is not done directly by the container but delegated by the container to a Java Persistence API (JPA) persistence engine. As many applications will require persistence services without the need for the many services provided by the container, the JPA has been issued as a separate specification and applications running outside an EJB container can still make use of JPA services. The main services provided by a JPA persistence engine are:
  • Entity Manager - which provides services for persistence, transaction management, and managing the lifecycle of entities.
  • Object/Relational Mapping - provided mapping of entities onto relational database tables through the use of metadata annotations.
  • The Java Persistence Query Language (JPQL) - is used for retrieving persisted entities.

The JPA specification leverages existing object/relational mapping products such as Hibernate and Oracle Toplink. As these products have been available for many years, the JPA specification drew heavily on these two products in order to flesh out the specification. In fact, Toplink and Hibernate are the actual default persistence engines for a number of EJB 3 containers. As each of the default persistence engines are a pluggable default, it is possible to swap out the default engine and use an alternative if so desired.

Session Bean

Session beans are used to implement such control classes. Control classes from an object oriented analysis and design perspective, are used to encapsulate business logic such as checking credit card details, transferring funds, and booking reservations. Session beans are generally transient, relatively short lived and not persistent so will not be stored in a database or other permanent file system. Session beans can be used to create and update entities, which are then persisted to permanent storage.

Clients interacts with session beans by invoking one or more methods defined in the bean. It is because of this sequence of method calls that is called a session, that these business components have the name session beans. The client for a session bean can be either a web-tier client such as a servlet or JSP page, or a standalone Java application program.

In EJB 3, the session bean component consists of a bean interface, which provides all the bean method definitions and a bean class, which provides the method implementations. Note that EJB clients do not interact directly with a bean but interact with a proxy generated by the EJB container. The proxy will intercept method calls and then provide the container services such as transaction management, security, etc. There are two types of session beans. One type is stateless session beans and the other type is stateful session beans. We will look first at stateless session bean.

EJB Types - Stateless Session Bean

Stateless session beans are useful for business processes in which state is only useful for only one invocation. When invoking stateless session beans, client cannot assume that subsequent requests will be handled by the same bean instance. Instead, the container will often create and destroy instances however it feels will be most efficient. How a container chooses the target instance is left to the vendorís discretion.

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-slsbinstancesclientreqs.jpg
Figure:An SLSB Instances Handling Client Requests

For example, a stateless session bean that returns the current time to the client. The session bean consists of a bean interface and a bean class. We have named our interface TimeService.java, which contains a single method definition getTime():
Java Code: TimeService Interface
package com.acme.session; 
import javax.ejb.Remote;
@Remote public interface TimeService {
   public String getTime();
}
The listing shows the interface definition is prefixed with the @Remote annotation in order to indicate to the EJB container that this bean can be invoked by a remote client that is not residing in the same Java Virtual Machine (JVM) as the container. The interface could also be local. The @Remote annotation is part of the javax.ejb package.

As we noted above, stateless session beans maintain no internal client-specific state between separate client invocations. This implies that state information must be implemented elsewhere if required but also that the applicationís scalability will be significantly improved by the use of stateless session beans. A small pool of stateless session beans can easily service a significantly larger number of concurrent requests. The lifecycle of a stateless session bean is simply two states: Does Not Exist and Method-Ready Pool. The lifecycle of a stateless session bean is illustrated below:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-slsblifecycle.jpg
Figure:Stateless Session Bean Lifecycle

EJB Types - Stateful Session Bean

While stateless session bean are known for their speed and efficiency, stateful session beans (SFSB) are known as being a server-side extension of the client. One SFSB is dedicated to one client for the life of the bean instance. Itís purpose is to act as the clientís agent. Stateful session beans cannot be swapped among EJB objects, nor kept in an instance pool like stateless session beans. Once a stateful session bean is instantiated and assigned to a client, it is tied to that client for its entire lifecycle maintaining internal conversational state across multiple invocations from the same client. The advantage of stateful session beans is that the programming model is less restrictive and more natural. But, applications using stateful session beans are not as scalable as an equivalent application using stateless session beans. Stateful session beans can be activated and passivated by the container depending on the frequency of requests that it is receiving from its client. This is shown in the figure below:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-clientandsfsb.jpg
Figure:Client Relationship with an EJB Container

A stateful session bean can become aware of its lifecycle by implementing the javax.ejb.SessionSynchronization interface. This interface defines an additional set of callback methods which notifies the bean of its participation in transactions. The session bean that implements SessionSynchronization can then cache database data across several method calls before making an update..

The lifecycle of a stateful session bean has three states:
  • Does Not Exist
  • Method-Ready
  • Passivated

Although the Method-Ready state appears similar to the one for a stateless session bean, there are significant differences in its meaning for Method-Ready for stateful beans is considerably more complex. The figure below shows the lifecycle for stateful session beans:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-sfsblifecycle.jpg
Figure:SFSB Lifecycle

EJB Types - Entity Beans

Entity beans are a relic from the EJB 2.x specification. They are used to persist data and although they are no longer widely used in EJB 3.0 as the persistence model has undergone significant revision, the specification requires that they must be supported in EJB 3.0 compliant application servers since there is still a significant number of legacy applications that have used entity beans. Since they are in scope for the exam, we are obliged to cover them. In the future for any project, it is recommended that any architect embarking on designing a new system based on EJB 3.x use Java Persistence API entities.

EJB Types - CMP Entity Bean

Container Managed Persistence (CMP) entity beans delegate the management of state of their persistence to the container. The advantage of this approach is that it improves developer productivity as the container manages all of the details of ensuring that the bean is properly persisted to permanent storage. The downside is the developer has not control over the SQL code generated by the container. Any issue that could require performance tuning would be lost with the use of CMP. The only thing that the architect can do is to ensure that the CMO implementation by the vendorís EJB container is considered to be very good.

EJB Types - BMP Entity Bean

Bean Managed Persistence (BMP) entity beans maintains the developers in control of the code used for persisting beans into permanent storage. The internal state data contained in the beanís instance variables is updated to a persistent store via SQL code. This requires that the developer code manually every aspect of data persistence. This is the most direct and efficient method of persisting data as it does require that the developer hand code every single aspect of data persistence. BMP entity beans are best suited in scenarios where a CMP implementation is not capable of delivering the performance required or no CMP implementation exists for the persistent store being used such as a custom database solution.

Entity Class

Entities are classes that are designed to be persisted with their state into permanent storage; such as a relational database. In deference to either session or message driven beans, entities contain no business logic other than validation. Entities are used primarily for queries, updates, and deletes of application data.

As almost all application have persistence requirements even if there is no need for transaction or security services that would usually be required of EJBs, the persistence aspects of EJB 3 have been moved and packaged in a separate specification known as the Java Persistence API (JPA). Because JPA makes no assumption about whether or not your application is using a container, JPA can also be used in Java Standard Edition (SE) applications.

JPA covers all aspects related to Object/Relational Mapping and Queries. An entity class is a plain old Java object (POJO) annotated in such a way as to provide a Java Persistence API (JPA) implementation information that can be used to update the persistent store with the values stored in the instance variables of the entity class. A key design goal of JPA and entity classes was to simplify the task of persistence. As such, JPA provides a much simpler method of persistence than was ever possible with CMP or BMP entity beans. The key to this is the EntityManager, which plays the equivalent role of a lightweight container for the entity instance. It manages the lifecycle of entities. The EntityManager is the bridge between the OO and relational worlds. When a request to create an entity is made, the EntityManager translates the entity into a new database record. On a request for an entity to be update is made, it finds the relational data corresponding to the entity and updates it. If there is a request to delete an entity, the EntityManager removes the relational data for the specified entity. In terms of entities, requests to persist an entity will cause the EntityManager to create the Entity object, populate it with relational data, and then returns the Entity back to the OO world. The figure below shows the lifecycle for an entity:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-entitylifecycle.jpg
Figure:Entity Lifecycle

Persistence Strategies

Similar to what existed with entity beans, there are two persistence strategies that can be used for entities. The first is container managed EntityManager where the EntityManager is managed by the container who does all the task related to looking up, opening and closing the EntityManager. In this case, persistence of the entities is delegated to the EJB container or an Object-Relational Mapping (ORM) tool. The second is application managed EntityManager where the developer retains the responsibility of writing that code in return for increased control over the code. Both approaches have been used effectively as the individual frameworks and design patterns have matured over time. Which strategies that you choose to use is dependent on your particular needs for the application and whether they can be met by allowing the container to manage the EntityManager and ultimately the persisting of the entities or whether it needs to be done manually.

Message-Driven Bean

Message Driven Beans (MDBs) are EJB components which act as asynchronous message consumers. They are able to support non-JMS messaging systems as well as JMS messaging systems. They are able to consume messages from any Connector 1.5 resource adaptor. MDBs do not have remote or local business interfaces but instead must implement the MessageListener interface. This interface has only one method, onMessage(). This method is a callback used to receive the message from a messaging system as well as perform any business logic related to the message. MDBs can use either point-to-point (queue) or publish/subscribe (topic) modes. Message Driven Beans are stateless similar to stateless session beans. In fact their lifecycle is very similar to the lifecycle of stateless session beans. Their lifecycle is shown in the figure below:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-mdblifecycle.jpg
Figure:Message-Driven Bean Lifecycle

Similar to session beans, MDBs are able to invoke other session beans and can interact with entities via the EntityManager. By the use of message-driven beans to receives and process messages from a JMS destination (i.e. a queue or topic), this gives the Java EE platform the means to process messages asynchronously. In this way your business application can use multithreaded message consumers to process messages concurrently right out of the box without any additional code. MDBs manage the incoming messages among multiple instances of beans (in a pool similar to that for stateless session beans) without any special multithreading code in themselves. As soon as a new message arrives at its destination, an MDB instance is retrieved from the pool to handle the message. This concept of MDB pooling is shown in the figure below:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-mdbpool.jpg
Figure: Pool of MDBs with one MDB used for listening for events on messaging system

EJB Advantages and Disadvantages

There are a number of architectural questions that EJBs bring to the surface concerning how they are best employed in a robust application architecture. Some of these questions are:
  • How much value does EJBs really add in an application architecture?
  • What is the best means of persisting data?
  • How do we implement and consume web services using EJBs?

The decision-making process as to whether to use or not use EJB is similar to that concerning the use of any framework. You need to know what intrinsic overheads that the framework will impose during the design, development or production phase of the project. Ultimately it comes down to whether the benefits of the framework outweigh the overheads for the application under consideration. Pre EJB 3.0, for many architects the answer would have been negative as can be attested by the popularity of many lightweight frameworks such as Spring Framework and persistence frameworks such as Hibernate and TopLink. The programming model for EJB was difficult to design and develop and testing EJBs was for the most part the equivalent of pulling teeth. This compared badly against lightweight frameworks such as Spring which allowed one to use POJOs for development and testing and would then layer on top as an aspect the transaction management and security capabilities that were required. This was in contrast to the EJB container where you were obliged to implement these capabilities in your application whether they were required or not. Below we will look in detail into the key application capabilities and how EJBs relate in fulfilling these capabilities.

Scalability

EJBs provide scalability due to the ability of the EJB container to manage the pool of stateless EJBs in order to handle the number, frequency, and duration of incoming client requests. This ability allows for any application to handle concurrency of requests with ease via the EJB container instead of being obliged to handle this in development. This is because the container can re-use stateless session beans after every method invocation, thus requiring a smaller number of stateless session beans in a container-managed pool to service all of the concurrent clients rather than with stateful session beans where their nature would require a one to one relationship with each client.

Security

Security is one of the core services offered to the EJB developer by the container. Along with transaction management and concurrency control, the built-in security capabilities of EJBs are one of the primary reasons for choosing to implement an application architecture as EJB-centric rather than web or framework-centric. As enterprise applications are designed to service a large number of clients with all users varying in terms of their access rights. An administrator would require hooks into the configuration of the system, whereas a guest may only be allowed a read-only view of data. The use of role based security where users are grouped into categories where the role specifies the level of access to be granted has been one pillar in the development of a robust fully featured security framework. The development of a fully featured security framework with EJB 3 is now as efficient as using commonly available web frameworks.

Contrasting Persistence Strategies

Choosing how your system persists data to a persistent store is one of the key decisions that you as architect will need to make. It requires multiple aspects to be considered and evaluated. The aspects to be considered are detailed below.

Ease of Development

Abstraction is generally a good thing in that it allows for a separation of concerns with different layers of an application. In terms of persistence, we are abstracting the developer away from explicitly coding data access and update logic. It is easier to develop this using a tool/framework that generates correct and efficient persistence logic. An example of this approach include JPA, ORM tools as well as CMP entity beans. If instead, one uses other persistence approaches that require the developer to explicitly code SQL code tend to require longer development durations.

Performance

In general, the trade-off of using ORM, JPA, or CMP is that there is a runtime penalty to be paid for the productivity gains realized in the development phase. By contrast, explicit persistence strategies such as raw SQL executed via a JDBC connection take longer to develop and are more arduous to maintain, but because the developer retains full control, also represent the theoretical best-performing method of general data access and persistence. This is an esoteric point, however. A container-based persistence strategy can outperform a hand-crafted SQL by for example reducing the number of database round-trips by pre-fetching fields of related entities. In terms of performance, only by doing careful, application-specific prototyping and benchmarking can you arrive at the right solution.

Extensibility

There is no clear advantage between one particular data persistence approach or another as far as extensibility goes. When new columns are added to tables or new business rules are encoded into the persistence tier, there is extra work that will be required in order to upgrade the persistence tier to accommodate these requirements. The extensibility will vary widely from one vendor to another duo to the manner of the EJB container implementation.

EJB and Web Services

The basis of web services is to expose business logic in an application as a service for other independent clients of different types to consume. The service may be fine grained, such as a mathematical calculation, or coarse grained, such as processing an order. One of the key goals of web services is the concept of interoperability, which has been embraced by all leading technology providers such as IBM, Microsoft and Oracle through their implementation of web services standards. This allows for a C# client running under .NET to invoke a web service implemented as a Java EJB in a Java EE environment and vice-versa. This ability of clients and web services built on different platforms to interoperate is one of the key goals of web services means. One of the key technologies for implementing web services in Java is EJBs.

EJBs as Web Service End Points

The Java Web Service specification reduces the developer effort required to expose an EJB as a web service. A developer can export all of its public methods in an EJB as well as any Java class by just simply placing the @WebService annotation in the class definition. Java Web Service will automatically publish the public methods of the class as web service operations, using tools for the Java Web Services such as JAXB 2.0 to map operation arguments into an XML schema.

A Java Web Service (JWS) deployable module is anything the container can deploy as a Web service. One type of deployable module is an EJB-JAR module. It can be auto- deployed as a single annotated class file. A JWS container includes a deployment subsystem that is responsible for deployment. The actual deployment could involve an EAR containing multiple deployable modules.

In the case of deploying a single module, the deployment subsystem, first validates the contents of the deployable module by checking that EJB Web service endpoints are deployed in EJB-JARs. It might also collect binding information from the deployer. The deployment subsystem then deploys the components and Web services defined in the deployable module, publishes the WSDL documents representing the deployed Web services, deploys any clients using Web services, configures the server, and starts the application.

EJBs Consuming Web Services

JAX-WS is a replacement for JAX-RPC that was created as a more efficient and flexible means for programmers to invoke a Web service as through they are invoking a Java method. It in fact mirrors in many ways Java Remote Method Invocation (Java RMI) in enabling the programmer to use a local method call to invoke a service on another host. It differs from Java RMI in that the service on the other host is not necessarily implemented as a Java application. With JAX-WS, the Web service on the remote host only needs to provide a WSDL interface with a wsdl:portType1 definition. JAX-WS includes a standard WSDL to Java mapping that maps a wsdl:portType to a Java interface. The Java interface is known as a service endpoint interface (SEI) because it is a Java representation of a Web service endpoint. JAX-WS generates an instance of a SEI at runtime that can be used to invoke a Web service. The internal workings of a JAX- WS proxy are based on an instance of java.lang.reflect.InvocationHandler which implements a standard WSDL to Java and Java to WSDL mapping. So when you invoke a method on a proxy, the internal InvocationHandler converts the parameters into a SOAP message that gets sent to the Web service endpoint. Vice versa, the SOAP response message is converted back into an instance of the SEI return type.

JAX-WS proxies are dynamic since they are created at runtime. You need to generate the SEI prior to runtime but you donít need to concern yourself with the stub classes that implement the SEI since the dynamic proxy technology employed by JAX-WS requires only an interface definition in order to create a proxy class instance. Vendors who supply JAX-WS implementations normally furnish tools for creating a SEI from its corresponding wsdl:portType. For example in GlassFish, this functionality is provided by the wsimport utility. The figure below shows the invocation of a Web service with a Java proxy:

Tutorial:Review of EJB Application Architecture for the Java Architect Exam-c4-invocwebservicewithproxy.jpg
Figure:Invocation of a Web service with a Java Proxy

Advantages and Disadvantages of Web Service Endpoints

The replacement of JAX-RPC with JAX-WS and the introduction of annotations in WS-Metadata and WSEE as part of the overall the Java Web Services toolset has greatly simplified the process of transforming EJBs into JAX-WS Service Endpoints that along with stateless session beans can implement a service endpoint interface for JAX-WS. It as well makes it easy to consume web services from EJBs. The advantages and disadvantages of these capabilities are the following:
Advantages
  • Improved developer productivity.
  • Ability to rapidly consume web services to meet new business requirements.
  • Ability to rapidly expose business logic as web services for external applications to meet new business requirements.

Disadvantages
  • A bottom up or quick transformation approach could lead to a disordered application architecture. As an architect, you should strive to define a clearly delineated integration layer in the application architecture.
  • Publishing of business functionality to a wider audience could create new security concerns as the data and information previously accessible only to authenticated users of the application is now available to external users and applications.
  • Publishing of business functionality via a web service may compromise validation leading to problems in either the referential integrity of a database or a break in a business rule by the use of unvalidated data.


Improvements through EJB 3 Specification

Until EJB 3.0 specification, there was a significant segment of Java developer community who viewed EJB as an unproductive and bloated element of the JEE platform. Developers and architects experience had showed that EJB failed to deliver in the following aspects:
It didnít reduce complexity but introduced complexity in numerous area.
The entity bean for persistence was a failure.
Applications using EJB were generally less portable between application servers than applications using other J2EE technologies, such as servlets, JSPs and tag libraries
Despite touting EJBs as providing scalability, EJB systems often performed poorly and didnít scale as promised. The overhead of excessive use of EJB required re-factoring or caused outright failure in a significant number of projects.
EJB transformed simple programming paradigms into major challenges. For example because of its dependency on the container and certain interfaces implementing design patterns such as the Singleton design pattern were near impossible in EJB.
As many developers and architects were avoiding the use of EJBs and moving to lightweight containers such as Spring, as well as lightweight persistence frameworks such as Hibernate and Toplink, the EJB 3.0 expert group took on board the complaints of the user community and completely revised the EJB specification making the design and development of all types of EJBs quicker, simpler, and easier to develop while still retaining all the advantages that EJBs bring to a JEE application. The key changes that were brought through in the revision of the specification are discussed below.

Ease of Development

Of all of the improvements driving the EJB 3.0 specification the most important was to improve developer productivity and to simplify the process of developing every type of EJB. EJB 3.0 had drastically reduced the overheads traditionally associated with EJBs by moving from multiple interfaces for one component, a restrictive inheritance mechanism for the core EJB implementation class, boilerplate XML that is difficult to keep in sync with the source code it configures, to a POJO based development model using annotations. By moving to a POJO based development model now EJBs can take full advantage of the power of object oriented programming features in Java, while the use of annotations allows for the use of the inversion of control pattern so prevalent in lightweight frameworks that use dependency injection to inject the required aspects into the POJO to provide the full power of EJBs. In this way the 3.0 specification and implementations reduces significantly the overhead of developing and deploying EJBs, while still retaining all of the advantages of EJBs.

Container in EJB 3

EJB containers have not changed significantly in EJB 3 from the perspective of the architect/developer. It has added some new features such as dependency injection and web services to the base set of plumbing or infrastructure services that already existed. It is the relation to POJO based EJBs where container services are used on an as needed basis, which has allowed the developer to focus on implementing the business logic for a specific application instead of worrying about the particulars of EJBs.

JPA in EJB 3

The Java Persistence API (JPA) is a major change from the failure that was Entity Beans. It addresses the core task of business data persistence in a lighter more flexible way than was done previously. JPA is a nice change from Entity Beans and one of its best features is that it leverages existing ORM frameworks and tools rather than tries to recreate the wheel. There are certain cases where JPA will not be the optimal solution. These cases are the following:
  • When you are looking for raw performance and need to tune your SQL statements to wring out the last bit of speed.
  • When minor modifications are being made to a existing persistence tier. The cost, risk versus benefits will in most cases not add up.
  • When the underlying datastore is not supported by mainstream JPA implementations such as a non-relational database.


Summary

OK. Thatís it for our review of the business tier. We will next look at the web tier.