Introduction to Enterprise JavaBeans - Types of EJB and Common Uses of EJBs (Page 2 of 14 )
Types of EJB
In most texts on this subject you will see pictures of a 3-tier system containing boxes labeled "EJB." It is actually more important to identify what application functionality that should go into an EJB.
At the start of application development, regardless of the precise development process used there is generally some analysis that delivers a model, or set of classes and packages, that represent single or grouped business concepts.
Two types of functionality are generally discovered during analysis—data manipulation and business process flow. The application model will usually contain data-based classes such as Customer or Product. These classes will be manipulated by other classes or roles that represent business processes, such as Purchaser or CustomerManager. There are different types of EJB that can be applied to these different requirements:
Session EJB—A Session EJB is useful for mapping business process flow (or equivalent application concepts). There are two sub-types of Session EJB—stateless and stateful—that are discussed in more detail on Day 5. Session EJBs commonly represent "pure" functionality and are created as needed.
Entity EJB—An Entity EJB maps a combination of data (or equivalent application concept) and associated functionality. Entity EJBs are usually based on an underlying data store and will be created on the data within that store.
Message-Driven EJB—A Message-driven EJB is very similar in concept to a Session EJB, but is only activated when an asynchronous message arrives.
As an application designer, you should choose the most appropriate type of EJB based on the task to be accomplished.
Common Uses of EJBs
So, given all of this, where would you commonly encounter EJBs and in what roles? Well, the following are some examples:
In a Web-centric application, the EJBs will provide the business logic that sits behind the Web-oriented components, such as servlets and JSPs. If a Web-oriented application requires a high level of scalability or maintainability, use of EJBs can help to deliver this.
Thick client applications, such as Swing applications, will use EJBs in a similar way to Web-centric applications. To share business logic in a natural way between different types of client applications, EJBs can be used to house that business logic.
Business-to-business (B2B) e-commerce applications can also take advantage of EJBs. Because B2B e-commerce frequently revolves around the integration of business processes, EJBs provide an ideal place to house the business process logic. They can also provide a link between the Web technologies often used to deliver B2B and the business systems behind.
Enterprise Application Integration (EAI) applications can incorporate EJBs to house processing and mapping between different applications. Again, this is an encapsulation of the business logic that is needed when transferring data between applications (in this case, in-house applications).
These are all high-level views on how EJBs are applied. There are various other EJB-specific patterns and idioms that can be applied when implementing EJB-based solutions. These are discussed more on Day 18, "Patterns."
Why Use EJBs?
Despite the recommendations of the J2EE Blueprints, the use of EJBs is not mandatory. You can build very successful applications using servlets, JSPs or standalone Java applications.
As a general rule of thumb, if an application is small in scope and is not required to be highly scalable, you can use J2EE components, such as servlets, together with direct JDBC connectivity to build it. However, as the application complexity grows or the number of concurrent users increases, the use of EJBs makes it much easier to partition and scale the application. In this case, using EJBs gives you some significant advantages.
The main advantage of using EJBs in your application is the framework provided by the EJB container. The container provides various services for the EJB to relieve the developer from having to implement such services, namely
Distribution via proxies—The container generates a client-side stub and server-side skeleton for the EJB. The stub and skeleton use RMI over IIOP to communicate.
Lifecycle management—Bean initialization, state management, and destruction is driven by the container, all the developer has to do is implement the appropriate methods.
Naming and registration—The EJB container and server provide the EJB with access to naming services. These services are used by local and remote clients to look up the EJB and by the EJB itself to look up resources it may need.
Transaction management—Declarative transactions provide a means for the developer to easily delegate the creation and control of transactions to the container.
Security and access control—Again, declarative security provides a means for the developer to easily delegate the enforcement of security to the container.
Persistence (if required)—Using the Entity EJB's Container-Managed Persistence mechanism (CMP), state can be saved and restored without having to write a single line of code.
All of these container services are covered in more detail as the book progresses.
Now that you know why you would want to use an EJB and how to apply it, you can examine the inner workings of an EJB to understand how all the parts fit together.
 This chapter is from Teach Yourself J2EE in 21 Days, second edition, by Martin Bond et. al. (Sams, 2004, ISBN: 0-672-32558-6). Check it out at your favorite bookstore today. Buy this book now.
|
Next: What's in an EJB? >>
More Java Articles
More By Martin Bond
/ 38 
