Java Programming, Lecture Notes #1320
Time to regroup
The previous lessons in this series have provided accelerated instructions to help you get your first enterprise bean up and running as quickly as possible. Quite a few lessons were required to accomplish that objective, not because it is especially difficult to write enterprise beans, but rather because it is difficult to deploy the beans in a J2EE server.
A cookbook approach
In working through the accelerated lessons, I provided the information more or less in a cookbook fashion. That is to say, I told you what to do, and not necessarily why to do it.
A change of pace
Now that you have your first enterprise bean running successfully in your J2EE server, it is time to sit back, relax, take a deep breath, and embark on the task of understanding Enterprise JavaBeans.
That will be the purpose of the remaining lesson in this series on EJB — to help you really understand what enterprise beans are, how to write them, and how to use them to advantage.
From this point on, I intend to go much more slowly explaining things more carefully as I proceed. Along the way, I will show you lots of sample bean programs, each of which will be as simple as I can make it while still illustrating the concept that the program is intended to illustrate.
Recommended supplementary reading
It is strongly recommended that you study the previous lesson entitled
Enterprise JavaBeans: Getting Started with EJB, Part 7
before embarking on this lesson.
Additional supplementary material that I have written is available at Gamelan. As of the date of this writing, Gamelan does not maintain a consolidated index to my Java tutorials. Therefore, they may be difficult to locate on the Gamelan site. A consolidated index with links to the tutorials on the Gamelan site is available at Baldwin’s Java Programming Tutorials.
You may find it useful to open another copy of this lesson in a separate browser window. That will make it easier for you to scroll back and forth and refer to earlier material without losing your place.
In this lesson, I will discuss the use of Sun’s J2EE as a middle-tier server in a multi-tier environment. I will explain some of the benefits of the multi-tier environment in general, and the use of J2EE in particular.
J2EE compliant services
I will discuss some of the services provided by a J2EE compliant server along with the fact that such a server provides both a web container and an EJB container. The purpose of the web container is different from the purpose of this series of lessons on EJB. Therefore, the web container won’t be discussed further in this series of lessons on EJB.
What is an EJB container?
I will discuss the general concept of an EJB container, describe the services provided by the EJB container, and discuss how the EJB container fits into the grand scheme of things in J2EE.
Enterprise JavaBeans technology (also known as EJB technology) is part of a larger overall technology known as the Java 2 Platform, Enterprise Edition (J2EE). (Note that this series of lessons is primarily concerned with EJB. Other components of J2EE, such as servlets and JSP are covered in other lessons.)
J2EE provides an architecture for developing, deploying, and executing applications in a distributed-object environment. System-level services, such as transaction management, security, client connectivity, and database access are often required of such applications.
Concentrating on business logic
A server that complies with the J2EE specification provides the required system-level services. This allows the application programmer to concentrate on business logic without having to also write the code to provide system-level services.
Enterprise beans are reusable components that can be accessed by client programs. The application programmer codes the business logic into the beans and deploys them into a J2EE compliant server. The server functions as a middle-tier server in a multi-tier client/server system.
A Middle-Tier Server
This leads to a system concept involving clients often referred to as thin clients. The thin-client programs simply deal with the interface to the middle tier. This relieves them of the difficulties of executing complex business rules, connecting to legacy programs, and making queries to database systems. This complexity is handled by the enterprise beans and the associated system services running in the middle tier.
Because the clients are thin, and are not required to execute complex programs, they can exist in a variety of forms including Java applications, web browsers, hand-held devices, etc.
The first tier in a J2EE three-tier system typically consists of one or more clients. These clients request business-logic services from enterprise beans running in the middle tier. The beans make use of the system services provided by the middle-tier server to access data from existing systems in the third tier. The beans apply business rules to the data, and return the results to the clients in the first tier.
Gasoline pumps and Automated Teller Machines
In an earlier lesson, I speculated that gasoline pumps that accept credit cards and ATMs both function as thin clients in a multi-tier system.
In one case, the back end database system includes your credit-card account. In the other case, the back end system includes your bank account.
Although I don’t know the details, I doubt that the little processor in the gas pump interacts directly with your credit-card account, and I doubt that the ATM interacts directly with your bank account. In both cases, I speculate that there is a middle tier that accepts requests from the client (in this case the gas pump or the ATM) and provides the requested services by dealing with the back end databases.
Services provided by the middle-tier
According to Sun, middle-tier servers provide:
- Business services to clients
- Remote access to clients and back-office systems
- Session and transaction management
- Security enforcement
- Resource pooling
Also according to Sun,
“Because the middle-tier provides these services, the clients can be thin, simple, and rapidly developed. You can integrate new clients with existing applications and databases, protecting your investment in legacy systems.
Middle-tier servers enable you to create large-scale distributed applications for the enterprise. The architecture of the J2EE platform makes it the ideal choice for developing middle-tier servers.”
A J2EE Compliant Server
According to Sun, a J2EE compliant server provides the following services:
- Naming and Directory – allows programs to locate services and components through the Java Naming and Directory Interface (JNDI) API
- Authentication – enforces security by requiring users to log in
- HTTP – enables Web browsers to access servlets and JavaServer Pages (JSP) files
- EJB – allows clients to invoke methods on enterprise beans
As mentioned earlier, and as indicated by the above list of services, J2EE is broader than EJB alone. A J2EE compliant server can be compartmentalized into two containers:
- A web container
- An EJB container
The Web container
The Web container is a runtime environment for managing JSP files and servlets. I have previously published numerous tutorial lessons on JSP and servlets in a different series of tutorial lessons. The series of lessons that you are reading now will concentrate on enterprise beans, and therefore, won’t be concerned with the Web Container that is a part of J2EE.
The EJB Container
The EJB container is a runtime environment for managing enterprise beans. Enterprise beans are objects that run within an EJB container.
What is a container?
The concept of a container is a little abstract. Maybe this will help. One author who publishes excellent technical material on Sun’s site explains the concept as follows, “The container hosts and manages an enterprise bean in the same manner that … an HTML browser hosts a Java applet.”
An enterprise bean cannot function outside of an EJB container, (which, by the way, leads to some difficulty in testing and debugging enterprise beans). The EJB container controls the beans and provides them with system-level services.
Services provided by EJB container
With a J2EE compliant server, the programmer of the class from which the enterprise bean object will be instantiated can assume that the following system-level services will be available:
- Transaction Management
- Remote Access to the bean
- Life Cycle Management for the bean
- Database Connection Pooling
As a result, the programmer can concentrate on programming the methods that execute business logic (business methods) within the enterprise beans without having to also program the system-level services enumerated in the above list.
A client application does not have direct access to an enterprise bean. Rather, the bean is isolated from the client application by the container.
The invocation of a business method on the bean passes first through the container before reaching the bean. The container ensures that persistence, transaction management, and security are handled properly for each invocation of a business method on a bean made by a client.
The code required to manage distributed transactions can be very complex. Each time a client invokes a business method on a bean, the container intercepts the invocation in order to manage the transaction. Rather than being required to write and debug complex code for transaction management, the bean programmer declares the transactional properties for the bean in something called the deployment descriptor file. The container reads the file and handles the bean’s transaction requirements automatically.
The deployment descriptor file
The deployment descriptor file is an XML file that is automatically generated by the J2EE deployment tool. (In case you are unfamiliar with XML, I have written numerous tutorial lessons on XML. You will find a consolidated index to those tutorial lessons at Baldwin’s Java Programming Tutorials.)
I provided a listing of a J2EE deployment descriptor file for a simple bean in Listing 4 of the lesson entitled
Enterprise JavaBeans: Getting Started with EJB, Part 6
The container also builds and manages a security shield around the enterprise bean. Only authorized clients are allowed to invoke methods on the bean. This is accomplished using a system of roles.
According to Sun, “Each client belongs to a particular role, and each role is permitted to invoke certain methods.”
The roles of the different clients along with the methods they are allowed to invoke are also declared in the deployment descriptor file. As a result, the bean programmer is not required to write the code to enforce security.
Remote access to the bean
The container manages the low-level communications between clients and enterprise beans. As with RMI and the Java implementation of CORBA, once an enterprise bean has been created by a client, the client invokes methods on the bean just as if the bean were running in the same virtual machine as the client.
According to Sun, “An enterprise bean passes through several states during its lifetime. The container creates the enterprise bean, moves it between a pool of available instances and the active state, and finally, removes it. Although the client calls methods to create and remove an enterprise bean, the container performs these tasks behind the scenes.”
Life-cycle management for a simple session bean was illustrated by the program discussed in several previous lessons in this series. (See the lesson entitled
Enterprise JavaBeans: Getting Started with EJB, Part 2
At each critical stage in the bean’s life cycle, the container invokes a specific callback method on the bean. The bean programmer can override the callback methods to provide the desired behavior as the bean moves from one stage in its life to the next.
Database connection pooling
Also according to Sun, “A database connection is a costly resource. Obtaining a database connection is time-consuming and the number of connections may be limited. To alleviate these problems, the container manages a pool of database connections. An enterprise bean can quickly obtain a connection from the pool. After the bean releases the connection, it may be re-used by another bean.”
The simple bean that was discussed in the previous lessons in this series did not involve a database. Furthermore, the bean was a session bean and not an enterprise bean (the two flavors of beans will be the primary topic of a subsequent lesson). The use of database access by enterprise beans will also be illustrated in subsequent lessons.
Other resource management
It is the container (not the bean or the client program) that is generally responsible for resource management. For example, through careful life cycle management and the pooling of resources, the container can often reduce memory consumption. When a bean is not being used, a container can place it in a pool to be used by another client. The container can also remove it from memory and bring it back when it is needed. (This is referred to as passivation and activation, which will also be discussed in a subsequent lesson.)
Because the container sits between the client and the bean, the client is not aware of such activities. For example, a bean might be passivated while its remote reference on the client remains intact. When the client later invokes a method on the remote reference, the container activates the bean to service the request. This all happens without any awareness on the part of the client (except possibly for the fact that some delays might be noticed).
A bean’s access to resources
A bean accesses other resources, such as those on the following list, through the container:
- JDBC connection
- Another bean
- The identify of its caller
- A reference to itself
- Various properties
The following three mechanisms are provided, through which the bean interacts with its container:
- Callback methods
- The EJBContext interface
- The Java Naming and Directory Interface (JNDI)
As mentioned earlier, each time a bean reaches a specific stage in its life cycle, the container invokes a corresponding callback method on the bean. By so doing, the container alerts the bean to the occurrence of the specific events in its life. The bean programmer can override the callback methods to cause the bean to exhibit some desired behavior in conjunction with those events.
The EJBContext interface
One of the callback methods is a method named setSessionContext(). When a bean is created by a client, the container invokes this method on the bean passing a reference to an object of type SessionContext. According to one author, this is “a reference directly to the container.”
The bean programmer can save this reference in an instance variable of the bean. Having saved the reference, the bean can later invoke methods on the reference to interact with the container. For example, there are methods that allow the bean to obtain the identity of its client. (I will show you a sample bean that uses this capability in a subsequent lesson.)
I provided a brief discussion of JNDI in the lesson entitled
Enterprise JavaBeans: Getting Started with EJB, Part 7
The container manages a special naming system for use by the beans. This naming system is accessed by beans using JNDI to access other resources registered in the naming system.
One of the main advantages of J2EE is portability. The specification defines a contract that is expected to be adhered to by J2EE compliant servers. The contract specifies various bean/container interactions and behaviors with regard to security, transaction management, persistence, etc. This contract is intended to provide portability between J2EE compliant servers so that existing enterprise beans can be deployed and run in any J2EE compliant server.
In this lesson, I have discussed the use of Sun’s J2EE as a middle-tier server in a multi-tier environment. I explained some of the benefits of the multi-tier environment in general, and the use of J2EE in particular.
I discussed some of the services provided by a J2EE compliant server along with the fact that such a server provides both a web container and an EJB container. I explained that the purpose of the web container is different from the purpose of this series of lessons on EJB, and therefore, I won’t discuss the web container further in this series.
An EJB container
I discussed the general concept of a container, described the services provided by the EJB container, and discussed how the EJB container fits into the whole scheme of things in J2EE.
Where To From Here?
In the next lesson, I will present another sample enterprise bean program that you can use to hone your deployment skills. This bean will make use of helper classes.
Shortly after that, I will publish a lesson that discusses the two different flavors of enterprise beans: session beans and entity beans.
Trademarks: The following terms (and possibly some other terms used in this lesson as well) are trademarks of Sun Microsystems: Enterprise JavaBeans, EJB, Java, Java 2 Platform Enterprise Edition, J2EE, Java Naming and Directory Interface, JNDI, and JDBC
Copyright 2000, Richard G. Baldwin. Reproduction in whole or in part in any form or medium without express written permission from Richard Baldwin is prohibited.
About the author
Richard Baldwin is a college professor and private consultant whose primary focus is a combination of Java and XML. In addition to the many platform-independent benefits of Java applications, he believes that a combination of Java and XML will become the primary driving force in the delivery of structured information on the Web.
Richard has participated in numerous consulting projects involving Java, XML, or a combination of the two. He frequently provides onsite Java and/or XML training at the high-tech companies located in and around Austin, Texas. He is the author of Baldwin’s Java Programming Tutorials, which has gained a worldwide following among experienced and aspiring Java programmers. He has also published articles on Java Programming in Java Pro magazine.
Richard holds an MSEE degree from Southern Methodist University and has many years of experience in the application of computer technology to real-world problems.