Roedy said:
If one goes through the hazing rituals and learns J2EE, what can you
do that you could not before? What is this stuff for REALLY?
A quick synopsis:
EJB:
EJBs come in a number of flavors.
1) Entity beans. Entity beans are used to represent data in a database.
There are two flavors of entity beans, bean managed persistence (BMP)
and container managed persistence (CMP). With CMP the container handles
generating all the SQL. With BMP you have to write the SQL. A typical
simple use-case is that a single instance of an entity bean represents a
row in a database. Many people have soured on entity beans and prefer a
simpler approach like Hibernate. In fact, the new EJB specifications
endeavor to make entity beans more like Hibernate.
2) Session beans. Session beans are essentially service providers. A
typical use-case is to encapsulate high-level business logic. For
example, a session bean for a bank might implement an electronic
transfer. Session beans can be stateful or stateless. A stateful
session bean maintains a conversational state between itself and the
client. A stateless session bean does not; a client might get
completely different bean instances from one call to the next, even with
the same handle.
3) Message driven beans (MDB). Message driven beans are capable of
responding to JMS messages. (The other types of beans are not able to
do this do to the restrictions of the bean container.) MDB work
asynchronously, the other bean types are synchronous. MDB can post JMS
messages and that can be used as a "return value" of sorts.
Using EJBs gives you a number of things. The biggest thing is the
server environment. You do not need to implement all the things that go
with a server, like threading, polling, security, etc. (Do not be
fooled -- writing a server is hard. Just ask the guys at Apache HTTPD
or the IIS team.)
Using EJBs also takes away a number of things. You are not allowed to
do certain things within the EJB container. E.g., you should not create
threads, do file IO, listen on a socket, etc.
Web Technologies:
Web technologies come in two flavors, servlets and JSPs. Servlets are
the Java answer to CGI. Servlets are typically used as the controller
portion of a MVC set up.
JSPs allow for the definition of output pages with Java code and JSP
tags interspersed. There are libraries of custom tags for JSP that
allow you to avoid placing any actual Java code in the pages. JSPs are
typically used as the view part of an MVC set up. JSPs are also
suitable for quick and dirty prototyping or demos.
Many applications only require the web technology portion of J2EE and
some servers supply only that. The most prominent example of this is of
course tomcat.
Note that the web container is considerably less strict than the EJB
container.
Web Services:
J2EE allows for the definition of web services. I haven't used this
technology, so I'll refrain from further comment.
Misc Technologies:
J2EE also supplies a family of supporting technologies. These include
JNDI, JDBC extensions (including connection pooling), JAAS, RMI and JMS.
There are also hooks to link in resource adapters, which supply
external resources through a standard interface.
J2EE also provides enough configuration to allow you to avoid hard
coding anything. For example, using JNDI and ENC, you can link a
logical database connection to a physical database connection.
Overall, many people find J2EE too big and unwieldy for their needs.
Others have pared it down to use only the portions they find useful.
The biggest benefit of living inside a J2EE server is that all the
server technologies are implemented for you. So much of the concerns
about security and scalability are taken off the table. If a particular
J2EE server does not perform well for your application, you can try another.
J2EE is not an all-purpose server environment however. It was really
designed and is primarily used for web applications where the EJB layer
provides support to the web layer.
HTH,
Ray