36

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?

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
gizgok
  • 7,303
  • 21
  • 79
  • 124
  • "How does it make a J2EE a better system in terms or scalability, architecture?" - Key point, better than what? There are other approaches for java web development than the "enterprise way" of JEE that are worth considering. – Løkling Nov 21 '11 at 11:05
  • @Lokling So what exactly is JEE useful for, is it building for infrastructure services. coming from web dev background, I feel alot of JEE can be done in a much better way for web development. I'm not aware about middleware or infrastructure needs that JEE might be handling very well or might not be. – gizgok Nov 21 '11 at 12:06
  • @gizok -- at its simplest its an attempt at "separation of concerns" the application code deals with business logic, the Container handles the technical stuff. The fact that early implementations were flawed doesn't make it a bad idea. – James Anderson Nov 23 '11 at 02:06

4 Answers4

72

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.

Henrik Heimbuerger
  • 9,924
  • 6
  • 56
  • 69
Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • Let me understand this correctly, Containers are like an run time enviroment over JVM for J2EE specific. If that is does this seperation of layers hurt performance?Pardon me I do not possess a lot of knowledge of Java or J2ee – gizgok Nov 21 '11 at 12:12
  • @gizgok: It *might* introduce some overhead, but not necessarily (see my update). – Tomasz Nurkiewicz Nov 21 '11 at 12:25
  • What do you mean by applications not being self-contained, is it that since we go n-tier architecture jee apps are not or rather not preferred to run on webserver over an j2ee server. – gizgok Nov 21 '11 at 12:50
  • 5
    @gizgok Java SE applications are self-contained because you only need a JAR with an application to run (and JRE of course). With Java EE on the other hand a servlet, EJB or MDB alone are useless. You need a container to actually run them, manage their lifecycle and call them. E.g. servlet alone is just a Java class, even without `main()`. But once deployed on web container, the container will automatically call on every HTTP request. The container implements HTTP. Of course you can implement HTTP server yourself in Java SE - but the container does that for you, you can focus on business logic. – Tomasz Nurkiewicz Nov 21 '11 at 13:32
  • @TomaszNurkiewicz I guess the ideal is focusing on business logic, but since I started J2EE I've had to spend more time figuring out how to simply configure the container to provide data sources and execute my code. People will invent easier ways of doing things in future frameworks/languages (for example, compare how servlets are mapped using XML in J2EE to how REST mappings are set up with pure JavaScript calls in Express.js). The former is a black box, with the latter it's obvious where to look to figure out what it's doing under the hood. – Andy Apr 07 '15 at 14:52
  • @Andy I concur with you 100%. It's a black box unless you dive really deep and I don't like that. I find I have to spend so much time debugging config, biz logic gets postponed. The need to config to me is an anti-pattern, yet I am sure it's also necessary and useful, to achieve such powerful things as loose coupling. Perhaps it's a necessary evil, but I concurr 100% where you're coming from. Maybe it's just the J2EE learning curve. – gcr Apr 08 '21 at 23:12
  • I guess J2EE containers are similar to Docker containers in that they're bundled in a way that's easy to deploy into a bunch of different environments. But man, Docker was so much easier to grok and get started with. – Andy Apr 10 '21 at 00:56
  • the decline of Java application servers when using docker containers: https://blog.fabric8.io/the-decline-of-java-application-servers-when-using-docker-containers-edbe032e1f30 – Andy Apr 10 '21 at 00:56
6

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.
Nathan
  • 8,093
  • 8
  • 50
  • 76
James Anderson
  • 27,109
  • 7
  • 50
  • 78
  • Servlets are part of web containers according to J2ee spec. This tells me the services that it provides, not why it came into existence – gizgok Nov 21 '11 at 12:51
  • 1
    @gizok -- the containers exist to provide these services, so, you don't need to code them. The purpose is two fold. One to provide applications with a consistent API and to shield them from security and configuration issues. Two to make large scale applications manageable in terms of deployment, scheduling and access control, all of which are managed by the JE server in a consistent manner. – James Anderson Nov 22 '11 at 03:02
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.

user3366372
  • 371
  • 2
  • 4
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.

Nathan
  • 8,093
  • 8
  • 50
  • 76
Johnny Hujol
  • 51
  • 5