Professional Documents
Culture Documents
J2EE provides different types of components for different purposes. Today, you will start to look at one of the principal types of component in J2EEEnterprise JavaBeans (EJBs). The study of EJBs is continued on Day 5, "Session EJBs,", Day 6, "Entity EJBs", Day 7, "CMP and EJB QL", Day 8, "Transactions and Persistence", and Day 10, "MessageDriven Beans". As you can see, there is a lot to learn about EJBs, so today serves as a first step on the road to all of this EJB knowledge.
What Is an EJB?
In a typical J2EE application, Enterprise JavaBeans (EJBs) contain the application's business logic and live business data. Although it is possible to use standard Java objects to contain your business logic and business data, using EJBs addresses many of the issues you would find by using simple Java objects, such as scalability, lifecycle management, and state management.
requirements. The container will then use this information to perform authentication and control transactions on behalf of the componentthe component does not have to contain code to perform such tasks. The primary purpose of the container is to control and provide services for the EJBs it contains. When it needs to use some underlying functionality, such as creating a transaction on behalf of a bean, it uses the facilities of the underlying EJB server. The EJB server is the base set of services on top of which the container runs. Different types of EJB will run in different containers, but many different EJB containers can run on a single EJB server. EJB servers are generally delivered as part of a J2EE-compliant application server (examples include BEA WebLogic and IBM WebSphere). You will install and run the application server, which will provide the underlying services required of an EJB server and will host EJB containers.
Discovering EJBs
While it is quite easy to draw pictures of a 3-tier system containing boxes labelled "EJB,"
it is important to identify what application functionality should go into an EJB. At the start of application development, regardless of the precise development process used (Rational Unified Process (RUP), eXtreme Programming (XP), and so on), there is generally some analysis that delivers a Unified Modelling Language (UML) domain model (this identifies the main elements of the business problem to be solved). This can then form the basis of a solution model where the business concepts are mapped into appropriate design-level artefacts, such as components. This is where EJBs come into the design. The UML model will consist of a set of classes and packages that represent single or grouped business concepts. A class or package can be implemented as an EJB. Generally, only larger individual classes will become EJBs in themselves, because EJBs are intended to be fairly coarse-grained components that incorporate a reasonably large amount of functionality and/or data. There are generally two types of functionality discovered during analysisdata manipulation and business process flow. The application model will usually contain databased 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.
Types of EJB
There are three different types of EJB that are suited to different purposes: Session EJBA 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 that is created as it is needed. Entity EJBAn 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 based on that data within it. Message-driven EJBA 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.
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 Weboriented 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 frequently 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 EJBspecific patterns and idioms that can be applied when implementing EJB-based solutions. These are discussed more on Day 18, "Patterns." Given this context, common types of EJB client include the following: A servlet or JSP that provides an HTML-based interface for a browser client Another EJB that can delegate certain of its own tasks or can work in combination with other EJBs to achieve its own goals A Java/Swing application that provides a front-end for the business processes encapsulated in the EJB A CORBA application that takes advantage of the EJB's business logic An applet that takes advantage of the business logic in a remote EJB so that this business logic does not need to be downloaded to the client