What exactly is a container in J2EE and how does i

Question

I'm reading J2EE 1.4 spec right now and there are lot of terms that I do not understand do what. This is from the specs for containers:

Containers provide the runtime support for J2EE application components. Containers provide a federated view of the underlying J2EE APIs to the application components. J2EE application components never interact directly with other J2EE application components. They use the protocols and methods of the container for interacting with each other and with platform services. Interposing a container between the application components and the J2EE services allows the container to transparently inject the services defined by the components’ deployment descriptors, such as declarative transaction management, security checks, resource pooling, and state management.

Since I come from web development world, I'm not able to grasp, what exactly does this do and what is the purpose of a container. What is meant by providing run time support? How does it make a J2EE a better system in terms or scalability, architecture?

Answer 1

J2EE/Java EE applications aren't self contained. In order to be executed, they need to be deployed in a container. In other words, the container provides an execution environment on top of the JVM.

Also, applications rely on several APIs like JPA, EJB, servlet, JMS, JNDI, etc. The role of the EE compliant container is to provide a standard implementation of all or some of these APIs. This means you can theoretically run your application on top of any container as long as it relies on standard APIs.

From a technical perspective, a container is just another Java SE application with a main() method. EE applications on the other hand are a collection of services/beans/servlets/etc. The container finds these components and runs them, providing API implementations, monitoring, scalability, reliability and so on.

Answer 2

What is meant by providing run time support?

You're coming from the web development world, so that means you know that a traditional app made for the web must be accessible through HTTP protocol. Java is a programming language that runs on a JVM by design.

So how to link HTTP requests to your Java code?

Something must do that. A HTTP server like Apache can do that and using the old fashion Common Gateway Interface (CGI) you can call your Java code when the Apache server gets HTTP requests.

That's great, but at some point the web app will need authentication - one can write code for this, the web app will need some database access - one can write also the code for, the web app will need some UI code that one can also write with MVC, etc.

This web app has needs that other web apps will certainly have and one can see the common needs: authentication, datasources (like DB, etc), etc.
Java has already lots of these needs as APIs, as mentioned by previous answers, so why not put all this knowledge and common requirements for reuse into something that could be supporting the web application at runtime: a JEE container.

How does it make a JEE a better system in terms or scalability, architecture?

I think the question would be then why is JEE a more scalable system than a simple HTTP server with using CGI?

This has been answered by others, but with my previous answer I believe it is even more clear.

Hope this helps.

Answer 3

Usually one Java application use one JVM and have one OS level process for each. Container allow multiple Java application to be run under one JVM.

Answer 4

The JEE containers provide a wrapper around your source code.

Typical containers are the classic EJB data bean, and, the message driven bean. To a certain extent servlets and portlets can also be regarded as containers.

What the container provides a large number of services:-

• invocation -- your code gets loaded and started when required.
• transactional context -- most container code occurs in an ACID transaction context.
• configuration -- things like JDBC connections are passed to you by the container.
• security -- the container will restrict access to your code and data to authorized users.
• scalability -- since the container is in charge of scheduling it can automatically fire up extra copies if the load gets heavy, or, can be statically configured to run several instances in parallel.
• Encapsulation. Your program exposes a single interface to the container. However, externally it may expose this interface in a variety of forms (Corba,WSDL,JSM etc.).
• Common services. such as logging, services exposed by other EJBs. etc.