1. Tomcat Ejb Container Carrier
2. Tomcat Ejb Container Tracking
3. Tomcat Ejb Container Box
4. Tomcat Ejb Container System

Installing the EasyBeans container in Apache Tomcat 5.5.x server or Apache Tomcat 6.x server. (Tested on 5.5.27 and 6.0.18 versions)

Tomcat integration, Collapsed EARs, Container Driven Testing, easy embedding, and other features make OpenEJB a unique EJB implementation. We’re going to take this code, kill all the static old-school techniques, modernize it with and IoC architecture based on the gbean.org kernel. Tomcat cannot deploy ear files because it is a Web container rather than EJB container. Web containers implement the interfaces to run servlets. EJB containers do that + many others. Whether or not the server is a Web Container rather than an ejb server it will need jars for 3rd party libraries installed in order to run those libraries. It does not support Java EE application stack such as EJB, JMS, etc. This web profile version is what Tomcat is known and popular for. Subsequently, the Apache Community later added a certified Java EE container profile to Tomcat called TomEE which supports all Java EE technologies. For the purposes of this article, we’re focusing on Tomcat.

JDK 5.0

To run the EasyBeans container, a JDK 5.0 or higher is required. A JDK 1.4.x will not work.

EasyBeans Web application

The EasyBeans container is provided as a .war file named ow_easybeans.war which allows to add or remove it in a few steps.
The .war file needs to be copied into $CATALINA_BASE/webapps directory.
Note : CATALINA_BASE could be replaced by CATALINA_HOME if CATALINA_BASE is not defined.

Note

This war file is specific to Tomcat. It will detect the Tomcat application server and register some libraries in Tomcat application server.
Also, the java: naming of EasyBeans will be redirected to Tomcat naming mechanism automatically.
By removing the war file of EasyBeans + easybeans-deploy/ folder (and examples), all is removed (No libraries or configuration files are copied).

Examples

The examples provided in this EasyBeans release need to be copied in the $CATALINA_BASE/examples_ejb3s/ directory. The resulting directory will be $CATALINA_BASE/examples_ejb3s with subfolders like statelessbean.

Deploying the EasyBeans container in a Tomcat server.

Launching Tomcat

As usual, Tomcat is launched with the catalina start or catalina run command. Note that a JDK 5.0 is required

Deploying EasyBeans container

ow_easybeans.war file located in $CATALINA_BASE/webapps directory will be autoloaded at the tomcat startup.

Trying examples.

Stateless Bean

Trying the example

This release is bundled with some examples. The first one is a stateless bean

Here are the steps for launching this example :

1. Check that CATALINA_HOME (and maybe CATALINA_BASE) environment variables are defined before launching ant scripts

   ant needs to be launched in $CATALINA_BASE/examples_ejb3s/statelessbean directory. This will compile the source code and copy the archive into the $CATALINA_BASE/easybeans-deploy/stateless.jar/ directory.
2. On the server side, some traces will be printed. This is because EasyBeans has detected a new module in the $CATALINA_BASE/easybeans-deploy directory. The bean was loaded automatically.
3. Then, the client can be executed by running the command ant run.client
   If the client is executed without errors, the output will be :
4. There is also a servlet's client that has been put in $CATALINA_BASE/webapps directory.
   It can be accessed with the default url :

Understanding the example

This example shows the use of JDK 5.0 annotations, the EJB3 interceptors and the EJB3 callbacks.

The SessionBean class is annotated with @Stateless. This means that this class will be used as a stateless session bean.

The method trace is annotated with @AroundInvoke EJB3 annotation. This method will be called at each call on a business method. The business methods are defined in the interface implemented by the SessionBean class.

As a new feature of the EJB3, the interface doesn't need to extend the Remote interface. On the client side, there is no need to do a PortableRemoteObject.narrow() call.

Customizing the example

Some annotations are commented in the session bean example. To discover some new features like interceptors in other classes or the EJB3 callbacks, the comments can be removed and the example compiled again.

New methods can be added in the interface and implemented in the bean class, then the only step to do is to call ant in $CATALINA_BASE/examples_ejb3s/statelessbean directory. The EJB3 container will detect the changes and reload the bean.

Stateful Bean

Trying the example

As for the stateless session bean, the example needs to be compiled and deployed by calling ant in the $CATALINA_BASE/examples_ejb3s/statefulbean directory.

Once the bean is detected by the container and loaded, the client can be launched with ant run.client command.

The output will be :

Tomcat Ejb Container Carrier

Understanding the example

The @Stateful annotation is used to mark the bean as a stateful session bean.

State of the stateful session bean is notified by the transactions (default = REQUIRED), as the bean implements the SessionSynchronization interface.

Entity Bean

Trying the example

The example needs to be compiled and deployed by calling ant in the $CATALINA_BASE/examples_ejb3s/entitybean directory.

Once the bean is detected by the container and loaded, the client can be launched with ant run.client command.

Note that Hibernate traces will be displayed as it will manage the Employee entity class.

Understanding the example

This example shows the use of an entity bean and using EJB3 persistence provider which is in this release Hibernate. TopLink Essentials, OpenJPA can also be used with this EasyBeans. ObjectWeb Speedo will also provide a JPA interface.

The Entity class is a POJO class annotated with @Entity. The entities class are managed by the persistence provider, and in this case, by Hibernate.

Message Driven Bean

Trying the example

As usual, ant command needs to be launched in the $CATALINA_BASE/examples_ejb3s/messagedrivenbean directory.

Once the bean is detected by the container and loaded, the client can be launched with ant run.client command.

The output on the server side will be :

Understanding the example

The @MessageDriven annotation is used to mark the bean as a message driven bean.

The client send 5 messages on the SampleQueue queue object that are received by the bean and displayed on the output.

Timer Example

Trying the example

The ant command needs to be launched in the $CATALINA_BASE/examples_ejb3s/timerservice directory.

When the bean is loaded by the container, the client can be launched with the ant run.client command.

The output on the server side will be:

Understanding the example

This example shows the use of the @Timeout annotation on a method. The client invokes the TimerBean that will launch a timer. This timer will send a message to an MDB and then calls another bean which implements javax.ejb.TimedObject interface.

Security Example

Trying the example

The ant command needs to be launched in the $CATALINA_BASE/examples_ejb3s/security directory.

The bean will be loaded and then the client can be launched with the ant run.client command.

The output on the server side will be :

Understanding the example

All the annotations related to the security are used in this example. The annotations are @DeclareRoles, @RolesAllowed, @DenyAll and @RunAs.

To get the admin role, the @RunAs annotation is used.

As shown by the output on the server, role admin is authorized to do some actions.

Pool Example

Trying the example

The ant command needs to be launched in the $CATALINA_BASE/examples_ejb3s/pool directory.

When the bean is loaded by the container, the client can be launched with the ant run.client command.

The output on the client side will be:

Understanding the example

The pool example is using XML or annotations to configure the pool of Stateless or MDB. The annotation used is @Pool

The configuration of the pool when using XML deployment descriptor is done in the META-INF/easybeans.xml file of the EJB-Jar file.

Migration Example

Trying the example

The ant command needs to be launched in the $CATALINA_BASE/examples_ejb3s/migrationejb21 directory.

When the bean is loaded by the container, the client can be launched with the ant run.client command.

The output on the server side will be:

Understanding the example

This example is using two interfaces for accessing the stateless session bean.

• The first interface is the business interface of the stateless bean. It is the EJB 3.0 view
• The second interface that is used is the EJB 2.1 Home interface. Then the client needs to call the create() method.

The stateless bean class EJB2And3Bean is annotated with @Remote(EJB3RemoteBusinessInterface.class) for the EJB 3.0 view. For the EJB 2.1 view, the class is annotated with @RemoteHome(EJB2RemoteHome.class). For a LocalHome, it can be annotated with @LocalHome(EJB2LocalHome.class).

EAR Example

Trying the example

This example will deploy the EJB3 included in the EAR file in EasyBeans EJB3 container while the .war file will be deployed in Tomcat Application server.

The ant command needs to be launched in the $CATALINA_BASE/examples_ejb3s/ear directory.

When the EAR is detected by EasyBeans, the following traces will be displayed :

Then, this example is available at the http://localhost:9000/ear-web/ URL.

Understanding the example

This EAR example includes an EJB3 and a WAR file. This allows to use local interface between the WEB layer and the EJB layer.

The EAR file has no entry named META-INF/application.xml, EasyBeans will detect the type of the given archives and use default values for the name of the web context.

Due to the use of local interface, the Entities don't need to implement the Serializable interface.

The interface is not annotated with @Local annotation as it is the default value.

Each entity class provides a @NamedQuery query that allows to get all the objects

There is a relationship between Author and Book entities. It is very simple: One Author can write several books, but a Book is written only by one Author.

@OneToMany and @ManyToOne annotations are used to define the relationship

Some aspects of EasyBeans design.

Proxy

On the client side, only the EJB3 libraries + bean's remote interface + client code is needed, no needs of the JOnAS***Stub.class, etc.

Bytecode enhancement

The generated code is done by using ASM which is faster than velocity + javac methods.

Automatic class (re)loading

It detects automatically the changes in the class made by the user and reload the bean. This can be tried on the examples provided in this release : Change the source code of a class, recompile and EasyBeans will reload the bean.

Reports

Bugs or comments can be reported on or to the EasyBeans mailing-list available at EasyBeans Mailing-List

Hibernate is a product available at http://www.hibernate.org. Toplink Essentials is a product available at https://glassfish.dev.java.net/downloads/persistence/JavaPersistence.html. OpenJPA is a product available at http://openjpa.apache.org. EclipseLink is a product available at http://www.eclipse.org/eclipselink/

There is no simple yes or no answer to this question as it depends on where you stand in the mix of things.

The answer would be yes for those who are currently using it as an application server and a no for those who have deployed more complex servers due to one reason or the other.

What is not in doubt though is that it is currently one of the most widely used application servers in the market. As a matter of fact, many of today’s applications and virtually all web services can be built on top of Tomcat with a variety of add-ons and pluggable services readily available in the market.

It is no secret that many developers acknowledge that Tomcat is usually a much better choice to build today’s deployment and development architectures than other servers.

Tomcat is normally defined as a reference implementation of the Java Servlet and the Java Server Page (JSP) Specifications. It basically executes Java servlets and renders web pages which include JSP coding.

It is available on the Apache site in both source and binary versions. The product is a result of an open collaboration of developers and can be used either as a standalone product with its own web server (internal) or with other web servers. To get an objective view of the above, it is, therefore, important to first understand and agree on what is an application (app) server.

What Is An Application Server?

Initially, app servers were considered to be the hardware and operating system that’s used to run application code in what could be considered a two-tier environment. The other server used was known as a database server.

In later years, as web applications evolved, the UI (User Interface) gradually moved to the client machine while the business logic remained in the app server with the database still retaining its server. Later, Java application servers were introduced and things started to change.

These servers were based on Java 2 Platform and Enterprise Edition (J2EE) which adopted a multi-tier distributed model. The model above did include a Data Tier, a Middle Tier and a Client Tier.

The J2EE platform resided in the middle tier and consisted of lots of stuff such as an EJB server, a Servlet Container, a web server etc. These servers can also be referred to as containers.

The client tier consisted of several applications and/or browsers. The data tier, on the other hand, provide databases and/or data services.

An application server can be defined as the code, container or framework that sits between the Operating System and the application. It is usually charged with the responsibility of providing a suite of services for the application.

It also provides the infrastructure for developing, deploying and running applications. Some of the common characteristics of an application server can thus be categorized as follows:

• Fits between the JVM or OS layer and the application layer
• Supports multiple applications simultaneously
• Provides components (services) to the application, thereby eliminating the need for the application developer to create or even attempt to manage and integrate these services from the beginning
• The services being provided are implicitly or explicitly invoked by the application on a need basis and are not therefore coded into the application and finally,
• Mostly, but not always, an app server will include a configuration/administrative function that’s used for managing the environment and its functional applications.

Confusion over whether Tomcat is an application server is quite common amongst Java developers with some claiming Tomcat is absolutely an application server while some claiming it isn’t.

The truth though is that Tomcat is frequently used as an application server.

As a matter of fact, there are lightweight applications where Tomcat does shine as an app server and then there are more complex service oriented architectures where one would be better off using what can be termed as a full-fledged Java Platform Enterprise Edition (Java EE) application server. It thus follows that to clearly find out if Apache Tomcat is an application server or not, then we need to gauge it against the Java EE specifications.

Using Java EE as a Reference Point

Generally, Java EE is considered as the de facto standard that’s used to develop server side applications. In this regard, it is the foundation on which all server side technologies which include app servers must rest.

Java EE compliance is, therefore, an important cog for any app server. A compliant Java EE application is therefore expected to support a number of features; these include but are not limited to the following:

• JNDI capabilities
• Enterprise JavaBeans (EJB) container and server
• Java Transaction API (JTA) framework
• Java Message Service (JMS) framework
• J2EE Connector Architecture
• EAR files
• JavaMail
• JavaServer Pages or JavaServer Faces
• JAAS (Java Authentication and Authorization Service)
• JAF (JavaBeans Activation Framework)
• JPA (Java Persistence API)
• JTA (Java Transaction API)
• SAAJ(The SOAP with Attachments API for Java)
• JDBC (Java Database Connectivity) Framework
• JAXB (The Java Architecture for XML Binding)
• JAX-RPC (The Java API for XML-based RPC)

Further to the above Java EE does define containers for client applications, EJB components, and servlets. These containers normally provide structure as well as functionality that not only facilitate the deployment, but also the persistence and execution of all supported components.

J2EE does also define a standard architecture that’s used to connect Java EE applications and application servers to heterogeneous Enterprise Information Systems such as non-Java legacy applications, database systems, mainframes and ERP systems.

Simply put, the JavaEE specifications are a set of rules, they basically contain the interface. Thus, any JavaEE servers which need to comply with specifications need to have the implementation of these interfaces.

It is at this point where the major difference between a JavaEE server and Tomcat come in quite clearly with most people who believe it is solely a web server coming in hard.

This is mainly because if you are deploying any enterprise application, meaning that you have some technology such as EJB, JPA etc which are part of the JavaEE set to the server which is compliant, then your lib will not need to contain any API implementation jars. However, if you are using Tomcat for deployment, then you will have to add these API implementation jars.

This does explain why many Java based web applications (you can host these here on our Tomcat hosting plans) are normally deployed to environments that support a wide array of technologies that are found in a web container/server such as JavaServer Pages (JSP), JDBC and servlets. In such a scenario, a Tomcat application server comes in very handy when compared against a Java EE application server which may find these environmental constraints a tad difficult to adapt to.

On the other hand, a Java Web application is normally said to combine a subset of Java Enterprise application components and technologies such as:

• JDBC (Java Database Connectivity) Framework
• Java Servlets
• WAR files
• Java Servlets

In a typical Java EE web application, HTML clients are required to simply post a request to a server where the request is handled by a web container of the application server being used. At this point, it is the web container that’s charged with the responsibility of invoking the Servlet that’s been configured to handle the specific or exact context of the request.

Going by the above-mentioned details, it follows that strictly speaking Tomcat should be referred to as Tomcat web server or a JavaServer/Servlet container since there are certain conditions and services of a commercial JEE Application server that it doesn’t offer its users.

However, it does cover for these faults by including the most widely used services and supports add-ons as well as plug-ins which make server enhancement quite easy. The main advantage of this server, therefore, lies in its architecture which allows users to leave out what they don’t need, use what they need and install what they may be lacking.

Because of this, Tomcat is often used as an application server for strictly web-based applications even though it doesn’t include the entire suite of capabilities that a standard Java EE application would have on offer.

Inherent Advantages of Apache Tomcat

Tomcat Ejb Container Tracking

Apache Tomcat is a widely used application with slightly more than a million downloads a month. Its overall success has been due to its lightweight, effective and efficient nature.

This is because as earlier mentioned; Tomcat does implement JSP and Servlet which is basically what many applications tend to depend on.

Because Apache Tomcat is not a Java EE engine, it is possible to keep it lightweight and upload any add-ons on a need basis. This not only makes it versatile and flexible but also ensures that it can continuously meet the needs of most web applications.

Since Apache Tomcat is an open source product, it does enjoy the benefits of well thought out and thoroughly tested updates as many well trained and highly experienced developers and other volunteers are usually given an opportunity to offer their input.

This does give the product a distinct advantage since the skills- set that it borrows from is quite wide and diverse. It is also important to mention that since it is open source, getting updates and using it with other products is not only seamless but also quite simple and straightforward.

Another main advantage of the product is the ease of installing and configuring the application. Typically, this can be done in less than twenty (20) minutes. It is also worth mentioning that deploying web applications to Tomcat is also very easy and simple.

Apache Tomcat Growth and Upgrades

Over the years, the Apache community has continued to introduce new components into the Tomcat. These include components such as cluster, web application, and high availability. The cluster component has been added to help in the management of large applications.

The cluster is mainly used for load balancing and can be achieved through a number of techniques. Currently, one is required to have JDK version 1.5 or later so as to support clustering.

The high availability feature has been added so as to facilitate the scheduling of system upgrades which includes but is not limited to change requests and new releases that don’t affect live environments.

This is usually achieved by simply dispatching live traffic requests to a different server which is located to a different port as the main server is upgraded or replaced on the main port. This is an indispensable feature when handling user requests on applications that are considered high traffic.

Tomcat Ejb Container Box

The web application comes for both system and user based application enhancements, all these make it pretty easy to deploy across a variety of environments, be it mobile, desktop or even remote based. The component does also manage applications as well as sessions across the network.

It is worth mentioning that there are a whole lot of components which users can either opt to build on their own or download from one of the numerous mirrors and then proceed to upload into the server. It is also important to note that by adding some administrative services from other vendors, it is possible to meet IT operations requirements; giving users a complete suite of services at any given time.

Conclusion

Tomcat Ejb Container System

As earlier mentioned, defining whether Apache Tomcat is an application server is dependent on who you are talking to.

Those who develop rather lightweight and not too complex web based applications will vouch for it as an application server since they use it quite effectively and efficiently on a daily basis as an application server. The few add-ons that they need to deploy from time to time notwithstanding.

However, those developers who for one reason or the other have failed once or severally in trying to use Apache Tomcat in more complex web-based applications will be quick to dismiss it as a web server and will also rightfully remind anyone willing to hear that Apache Tomcat doesn’t meet the Java EE specifications which are a pre-requisite for any application server that wants to interface with the Java family.

Whichever the case, the truth though is that even though Tomcat cannot be technically defined as an application server, it is continuously and successfully being used as an application server for millions of mission-critical applications on a daily basis. The jury is still out there.