An Introduction to Enterprise JavaBeans Overview : In this article we will learn what are Enterprise JavaBeans ( EJBs ), what are it's different types and why to use EJBs in your application. What are EJBs ? EJB stands for "Enterprise JavaBeans" which are distributed network aware components for developing secure, scalable, transactional and multi-user components in a J2EE environment. Above definition actually describes EJBs from functional point of view i.e. what they do. A more structural definition would be : "EJBs are collection of Java classes, interfaces and XML files adhering to given rules". What do EJBs provide ? In J2EE all the components run inside their own containers. JSP, Servlets and JavaBeans have their own web container. Similarly EJBs run inside EJB container. The container provides certain built-in services to EJBs which the EJBs use to function. The services that EJB container provides are :  Component Pooling  Resource Management  Transaction Management  Security  Persistence  Handling of multiple clients i. Component Pooling : The EJB container handles the pooling of EJB components. If there are no requests for a particular EJB then the container will probably contain zero or one instance of that component in memory. If need arises then it will increase component instances to satisfy all incoming requests. Then again if number of requests decrease, container will decrease the component instances in the pool. The best thing is that the client is absolutely unaware of this component pooling and the container handles all this for you. ii. Resource Management : The container is also responsible for maintaining database connection pools. It provides you a standard way of obtaining and returning database connections. The container also manages EJB environment references and references to other EJBs. The container manages following types of resources and makes them available to EJBs :  JDBC 2.0 Data Sources  JavaMail Sessions  JMS Queues and Topics  URL Resources  Legacy Enterprise Systems via J2EE Connector Architecture iii. Transaction Management : This is probably the single most important factor of all. A transaction is a single unit of work, composed of one or more steps. If all the steps succeed then the transaction is committed otherwise it is rolled back. There are different types of transactions and it is absolutely unimaginable to not to use transactions in today's business environments. We will learn more about transactions in a separate article. iv. Security. The EJB container provides it's own authentication and authorization control, allowing only specific clients to interact with the business process. There is no need for you to create a security architecture of your own, you are provided with a built-in system, all you have to do is to use it. v. Persistence : The container if desired can also maintain persistent data of our application. The container is then responsible for retrieving and saving the data for us while taking care of concurrent access from multiple clients and not corrupting the data. vi. Handling of multiple clients. The EJB container handles multiple clients of different types. A JSP based thin client can interact with EJBs with same ease as that of GUI based thick client. The container is smart enough to allow even non- Java clients like COM based applications to interact with the EJB system. Like before the EJB container handles it all for you. On the next page we learn about different types of EJBs. Types of EJBs : There are three types of EJBs :  Session Beans  Entity Beans  Message-Driven Beans i. Session Beans : Session beans are the brain of our EJB based application. Their methods should decide what should or should not happen. They maintain the business logic. The client directly interacts with them, they are of two types : • Stateless Session Beans They do not maintain state in class level variables. They are thus fastest and most efficient of all. Since they do not save their state in class level variables, they are called as "Stateless". • Stateful Session Beans They do maintain state in class level variables and each client is provided a different and specific Stateful Session bean. This is different from Stateless Session beans in which case the client can be provided any Stateless Session bean between requests since the Stateless Session beans haven't managed their state, to the client, all of them are equal. Due to this fact, Stateful Session beans are heavy beans, while Stateless Session beans are light and efficient. ii. Entity Beans : Entity beans represent data in an EJB system. That data can reside in any data source including database. Entity beans are also of two types :  Container-Managed Persistence Entity Beans : CMP bean's persistence is managed by the EJB container which is responsible for saving and retrieving the data from the underlying database for us. CMP beans are easier to develop and work well with database access.  Bean-Managed Persistence Entity Beans : BMP bean's persistence has to be managed by the EJB itself. While it gives more control to the EJB developer to save and retrieve data, they are harder to build as more coding is required. One use of BMP beans would be to retrieve and save data from non-database data sources like XML files, JMS resources etc. iii. Message-Driven Beans : They are new in EJB 2.0 specification and provide a mechanism for EJBs to respond to asynchronous JMS messages from different sources. Message-Driven beans and JMS have opened a new paradigm for J2EE developers to create MOM ( Message Oriented Middleware ) based applications. We will learn more and more about this in separate articles on Stardeveloper. Why to use EJBs ? Developers have shown that good online applications can be created using JSP, Servlets and JavaBeans alone, without using EJBs. This has raised the question that why should we use EJB? People who ask this question bring two important points in favor of not using EJBs : • EJB Containers are expensive. • EJB based systems turn out to more complex to develop and maintain. I'll try to answer these questions now. First of all the reason EJB containers are expensive and their license fees turn out to be thousands of dollars for a single instance of that container is simple, the whole business process depends on that EJB container ( application server ) to run. Now if due to any reason there is a bug or if the application server crashes all of a sudden then it is going to halt the business application, something which business people wouldn't want to see happening even in dreams. Due to the dependency of the whole business process on these application server, the application server vendors spend lot of money on developing truly robust, secure and scalable application servers which are fault-tolerant and work in clusters to provide fail-safe operations. They also provide certain additional features like load balancing to prevent one server from becoming bobbed down from load. Current application servers also act as transactional processing monitors and work in the transactional system as heart in the body. Developers developing these application servers spend lot of time in making sure that if for some reason a server crashes, other servers should take over and not only take over but they should also be able to maintain the system in a stable state and complete any transactions which the failed application server might have been in the middle of committing or rolling back. Now whether you agree or not, all of this takes lot of money and hard work on the part of application server vendors. Now depending on the requirements of your organization or company you may or may not be requiring such great level of services. If your organization's business processes span hundreds or thousands of different computers and servers then you will do yourself lot of good if you get yourself good application servers, database applications and best of all good J2EE developers. But on the other hand if your organization is really small one but still wants to use EJBs due to future scalability requirements then there are quite a few EJB application servers from free and open source to the ones which are fast but still their license fees are quite low. Examples of application servers which are popular in large organizations include BEA Web Logic, IBM Web Sphere and Oracle 9i Application Server. While those for small organizations include JBoss and Orion Application Server. Now to answer the second point that the EJB based system are complex to develop and maintain. I think people who raise this issue are probably those who have little experience in building and maintaining EJB systems or are too scared to learn EJBs in the first place. To be honest, after the availability of new and advanced editors, architecting, building, deploying and maintaining EJB based J2EE systems is a fun. After the rising standard of UML to model business processes, it has become quite easy to architect business systems. There are UML modeling tools available like Rational Rose and Together Control Center which not only allow you to architect J2EE systems using UML but also allow you to build and deploy complete J2EE applications using graphical user interface. Their code editors are so nice that you only type the name of the object and it's methods and properties appear on the screen. They also offer this kind of code editors for JSP pages as well. To sum up, you should use complete EJB based J2EE system when you need scalability and portability in your system. Developing and using EJBs is fun and to me there is no reason why you should stay away from them. The best anyone can do is to offer them to you at a cost you can afford, now it is up to you to make use of them. Summary : In this article we learned that EJBs are distributed, network aware, secure and scalable components which adhere to given EJB specification. Adhering to this specification means that EJBs will be able to run on a long list of application servers on a wide variety of platforms without change. EJBs are thus portable not only acorss platforms but across application servers. We learned that there are different system level services provided to us built-in by the EJB container. The EJBs make use of them. We also learned that EJB's offer their services to different types of clients including Java based JSP and GUI windowed applications to non-Java COM based applications. We learned that there are 3 types of EJBs and each one of them is responsible for a specific task. Session beans are responsible for maintaining logic, entity beans represent data and message-driven beans provide asynchronous event based response to JMS messages. In the end we had a pretty long discussion on what points people not in favor of using EJBs raise and why we should use EJBs. We also learned that there are wide variety of application servers from free and open source to the ones with high license fees are available. There are accompanying IDEs for developing J2EE applications using wizards and graphical tools to aid in their quick development. The industry standard of UML for modeling business processes alleviates the complexity of architecting J2EE based systems. Previous ( 1 Gone ) ( No Further Pages ) Related Articles 1. Building your first Enterprise JavaBean 2. Reading and Parsing XML Files with Enterprise JavaBeans 3. EJB 2.1 Kick Start : Implementing a Solution Using EJB 2.1 Building your first Enterprise JavaBean Overview : In this tutorial we will learn how to create our first Enterprise JavaBean. We will then deploy this EJB on a production class, open source, and free EJB Server; JBoss. JBoss is a really popular EJB Container and is used by quite a lot of organizations World wide. We will thus also learn how to install and run JBoss Server. The client for our EJB will be a JSP page running in a separate Tomcat Server. This tutorial consists of following topics :  Installing and running JBoss Server  Installing, configuring and running Tomcat Server  Developing your first Session EJB  Deploying this EJB on JBoss Server  Creating the client JSP page  Running the JSP page  Summary ι. Installing and Running JBoss Server : You can download JBoss from JBoss web site. Current stable version is 2.4.3. Download it from their web site. Once you have downloaded it, unzip the JBoss zip file into some directory e.g. C:\JBoss. The directory structure should be something like following : C:\JBoss admin bin client conf db deploy lib log tmp This is it as far as installation of JBoss is concerned. Now to start JBoss with default configuration go to JBoss/bin directory and run the following command at the DOS prompt : C:\JBoss\bin>run run.bat is a batch file which starts the JBoss Server. Once JBoss Server starts, you should see huge lines of text appearing on your command prompt screen. These lines show that JBoss Server is starting. Once JBoss startup is complete you should see a message like following on your screen : [Default] JBoss 2.4.3 Started in 0m:11s Well done, you just installed and ran JBoss successfully on your system for the first time. To stop JBoss, simply press Ctrl + C on the command prompt and JBoss will stop, again after displaying huge lines of text. ii. Installing, Configuring and Running Tomcat Server : First download latest stable release of Tomcat Server from Tomcat web site. Current latest stable release is 4.0.1. If you are on Windows platform then you have the luxury of downloading Tomcat in an executable ( .exe ) format. So from the different types of Tomcat files available for download, select following : jakarta-tomcat-4.0.1.exe Once download is complete, double click this file to start the process of Tomcat installation. Installation is quite straight forward. During setup if you are running Windows NT/2K/XP, you'll be asked if you want to install it as a service, select 'yes' if you know what as a service is and how to start and stop it. Basically allowing the Tomcat to be installed a service means that you will be able to auto-start Tomcat when Windows starts and secondly Tomcat will run in the background and you won't have to keep one command prompt window open while it is running. Both of these features are great if you are using Tomcat on production machines. During development I will suggest that you don't install Tomcat as a service. It will also ask you where you want it to be installed. Give it any location you want or simply allow it to be installed on the default location of C:\Program Files\Apache Tomcat 4.0. Before starting Tomcat, let's first configure it a bit on the next page. Configuring and Running Tomcat : Create a new folder under the main C:\ drive and name it "Projects". Now create a new sub-folder in the C:\Projects folder and name it "TomcatJBoss". The directory structure should look like following : C:\Projects TomcatJBoss Now open conf/Server.xml file from within the Tomcat directory where you have installed it. By default this location will be : C:\Program Files\Apache Tomcat 4.0\conf\server.xml Some where in the middle where you can see multiple <Context> tags, add following lines between other <Context> tags : <! Tomcat JBoss Context > <Context path="/jboss" docBase="C:\Projects\TomcatJBoss\" debug="0" reloadable="true" /> Now save Server.xml file. Go to Start -> Programs -> Apache Tomcat 4.0 -> Start Tomcat, to start Tomcat Server. If everything has been setup correctly, you should see following message on your command prompt. Starting service Tomcat-Standalone Apache Tomcat/4.0.1 Note: Creating C:\Projects\TomcatJBoss folder and setting up new /jboss context in Tomcat is NOT required as far as accessing EJBs is concerned. We are doing it only to put our JSP client in a separate folder so as not to intermingle it with your other projects. iii. Developing your first Session EJB : As we learned in "An Introduction to Enterprise JavaBeans" article, Session EJBs are responsible for maintaining logic in our J2EE applications. What we did not say in that article was that Session beans are also the simplest EJBs to develop. So that's why our first EJB will be a Session bean. As you will see in a moment, every EJB class file has two accompanying interfaces and one XML file. The two interfaces are Remote and Home interfaces. Remote interface is what the client gets to work with, in other words Remote interface should contain the methods you want to expose to your clients. Home interface is actually EJB builder and should contain methods used to create Remote interfaces for your EJB. By default Home interface must contain at least one create() method. The actual implementation of these interfaces, our Session EJB class file remains hidden from the clients. The XML file we talked about is named as "ejb-jar.xml" and is used to configure the EJBs during deployment. So in essence our EJB, which we are going to create ( we will call it FirstEJB from now onwards ) consists of following files : com stardeveloper ejb session First.java FirstHome.java FirstEJB.java META-INF ejb-jar.xml First.java will be the Remote interface we talked about. FirstHome.java is our Home interface and FirstEJB.java is the actual EJB class file. The ejb-jar.xml deployment descriptor file goes in the META-INF folder. Create a new folder under the C:\Projects folder we had created earlier, and name it as "EJB". Now create new sub-folder under C:\Projects\EJB folder and name it as "FirstEJB". Create a new folder "src" for Java source files in the "FirstEJB' folder. The directory structure should look like following : C:\Projects TomcatJBoss EJB FirstEJB src Now create directory structure according to the package com.stardeveloper.ejb.session in the "src" folder. If you know how package structure is built, it shouldn't be a problem. Anyhow, the final directory structure should like following : C:\Projects TomcatJBoss EJB FirstEJB src com stardeveloper ejb session First.java : Now create a new First.java source file in com/stardeveloper/ejb/session folder. Copy and paste following code in it: [...]... ejb session First. class FirstHome.class FirstEJB.class META-INF ejb-jar.xml src com stardeveloper ejb session First. java FirstHome.java FirstEJB.java Now to package the class files and XML descriptor file together, run the following command at the command prompt : C:\Projects\EJB\FirstEJB>jar cvfM FirstEJB.jar com META-INF Running this command should produce an EJB JAR file with the name of FirstEJB.jar... "http://www.jboss.org/j2ee/dtd/jboss.dtd"> First ejb /First < /enterprise- beans> To add this new jboss.xml file into our existing FirstEJB.jar file, run the following command at the DOS prompt : C:\Projects\EJB\FirstEJB>jar uvfM FirstEJB.jar META-INF Now our FirstEJB.jar is ready to be deployed to the JBoss Server iv Deploying FirstEJB.jar... lookup our FirstEJB running on JBoss Notice that the argument to Context.lookup("ejb /First" ) is the same value we had put in the jboss.xml file to bind our FirstEJB to this name in the JNDI context We use that same value again to look for it Once our lookup is successful, we cast it to our FirstHome Home interface FirstHome home = (FirstHome)ctx.lookup("ejb /First" ); We then use create method of our FirstHome... our FirstEJB Session bean Create a new ejb-jar.xml file in the FirstEJB/METAINF folder Copy and paste following text in it : FirstEJB First... C:\Projects TomcatJBoss EJB FirstEJB src com stardeveloper ejb session First. java FirstHome.java FirstEJB.java META-INF ejb-jar.xml You can compile all the Java source file by using a command like following on the command prompt : C:\Projects\EJB\FirstEJB\src\com\stardeveloper\ejb\session> javac -verbose -classpath %CLASSPATH%;C:\JBoss\client\jbossj2ee.jar -d C:\Projects\EJB\FirstEJB *.java Note: The... and Home interfaces for our FirstEJB These two are the only things which our client will see, the client will remain absolutely blind as far as the actual implementation class, FirstEJB is concerned FirstEJB.java : FirstEJB is going to be our main EJB class Create a new FirstEJB.java source file in com/stardeveloper/ejb/session folder Copy and paste following text in it : /* FirstEJB.java */ package com.stardeveloper.ejb.session;... public interface FirstHome extends EJBHome { public First create() throws CreateException, RemoteException; } Hit the 'save' button to save FirstHome.java source file Explanation : First few lines are package and import statements Next we declare our FirstHome interface which extends javax.ejb.EJBHome interface Note: All Home interfaces *must* extend EJBHome interface public interface FirstHome extends... Introduction to Enterprise JavaBeans" article Last tag is , whose value can be either "Container" or "Bean" We will learn more about transactions in another article, for now it is sufficient to say that the transactions for our FirstEJB will be managed by the container FirstEJB First... com.stardeveloper.ejb.session.FirstHome com.stardeveloper.ejb.session .First com.stardeveloper.ejb.session.FirstEJB Stateless Container < /enterprise- beans> Then there is a tag which tells that all methods of FirstEJB "support" transactions We.../* First. java */ package com.stardeveloper.ejb.session; import javax.ejb.EJBObject; import java.rmi.RemoteException; public interface First extends EJBObject { public String getTime() throws RemoteException; } Hit the 'save' button to save First. java source file Explanation : First line is the package statement which tells that First interface belongs in the com.stardeveloper.ejb.session . Articles 1. Building your first Enterprise JavaBean 2. Reading and Parsing XML Files with Enterprise JavaBeans 3. EJB 2.1 Kick Start : Implementing a Solution Using EJB 2.1 Building your first Enterprise. EJB FirstEJB com stardeveloper ejb session First. class FirstHome.class FirstEJB.class META-INF ejb-jar.xml src com stardeveloper ejb session First. java FirstHome.java FirstEJB.java Now. folder so as not to intermingle it with your other projects. iii. Developing your first Session EJB : As we learned in "An Introduction to Enterprise JavaBeans" article, Session EJBs