Enterprise JavaBeans (EJB) 2.0 defines a Java component model for component transaction monitors (CTMs). A CTM is a marriage of two technologies: distributed objects and transaction processing monitors (TPMs). Distributed object technologies such as CORBA, Java RMI-JRMP, and DCOM provide a networking and routing infrastructure that allows applications to access objects hosted on other processes or computers. A TPM, such as CICS or TUXEDO, provides a robust, secure, and scalable environment for running transactional applications. A CTM combines these technologies into transactional distributed objects that run in a robust, secure, and scalable environment. There are three main CTM technologies today: Sun's Enterprise JavaBeans, Microsoft's COM+ (a.k.a. MTS), and the Object Management Group's CORBA Component Model (CCM). J2EE is built on EJB, which provides it with powerful transactional components that can be used to model and run an organization's business logic.

In Enterprise JavaBeans 2.0, bean components come in three main flavors: session, entity, and message-driven beans. Session beans model processes and act as server-side extensions of their clients (they can manage a client's session state). Entity beans model persistent business objects; and combine business logic and database data. Message-driven beans, the newest bean type, are JMS clients that can consume messages concurrently in a robust and scalable EJB environment. The EJB 2.0 bean components are shown in Figure 8.1.

Figure 8.1. The EJB 2.0 bean components

Application developers create custom enterprise beans by implementing one of the main bean interfaces and developing the bean according to conventions and policies dictated by the EJB specification. Entity beans are usually used for modeling business concepts that have persistent data and may be accessed by many clients concurrently. Entity beans might be used to model customers, orders, vehicles, locations, and similar objects. Session beans model business processes that may or may not have session state. Session beans might be used to model business concepts like a securities broker, an online shopping cart, loan calculation, medical claim processor—any process or mediator-type business concept. Message-driven beans are used to model stateless JMS consumers. A message-driven bean will have a pool of instances at runtime, each of which is a MessageListener. The bean instances can concurrently consume hundreds of messages delivered to the message-driven bean, which makes the message-driven bean scalable. Similar to session beans, message-driven beans model business processes by coordinating the interaction of other beans and resources according to the messages received and their payloads.

In addition to the Java classes that define a bean, every bean has an XML configuration file called a deployment descriptor . The deployment descriptor allows the bean developer to declare many of a bean's runtime behaviors including transaction policies, access control policies, and the resources (services) available. Resources ( JMS, JDBC, JavaMail, etc.) that are declared in the deployment descriptor are accessed via JNDI from the bean's environment naming context (ENC). The ENC is simply a default read-only JNDI namespace that is available to every bean at runtime. Each bean deployment has its own JNDI ENC. In addition to providing a bean with access to resources such as JDBC, JavaMail, JTA, and URL and JMS connection factories, the JNDI ENC is used to access properties and other enterprise beans. Resources accessed from the JNDI ENC are managed implicitly by the EJB server so that they are pooled and then are automatically enrolled in transactions as needed.

All enterprise beans (session, entity, and message-driven) can be developed separately, packaged in a JAR file and distributed. As components, packaged beans can be reused and combined with various other beans to solve any number of application requirements. In addition, enterprise beans are portable so that they can be combined and deployed on any application server that is EJB-compliant.

Session and entity beans are accessed as distributed objects via Java RMI-IIOP, which provides some level of location transparency; clients can access the beans on the server somewhat like local objects. Entity and session beans are based on the RPC distributed computing paradigm. Message-driven beans are JMS clients that process JMS messages; they are not accessed as distributed objects. Message-driven beans are based on the asynchronous enterprise messaging paradigm.

There is a lot more to Enterprise JavaBeans than is provided in this simple overview. You can learn more about EJB by reading Enterprise JavaBeans, by Richard Monson-Haefel (O'Reilly).

The servlet specification defines a server-side component model that can be implemented by web server vendors. Servlets provide a simple but powerful API for generating web pages dynamically. (Although servlets can be used for many different request-reply protocols, they are predominantly used to process HTTP requests for web pages.)

Servlets are developed in the same fashion as enterprise beans; they are Java classes that extend a base component class and may have a deployment descriptor. Servlets do not implicitly support transactions and are not accessed as distributed objects. Servlets respond to requests recieved from an input stream, usually HTTP, and respond by writing to an output stream. Once a servlet is developed and packaged in a JAR file, it can be deployed in a web server. When a servlet is deployed, it is assigned to handle requests for a specific web page or assist other servlets in handling page requests.

The servlet specification is simple and elegant. It's a powerful server-side component model. You can learn more about servlets in Java™ Servlet Programming, by Jason Hunter and William Crawford (O'Reilly).

JavaServer Pages ( JSP) is an extension of the servlet component model that simplifies the process of generating HTML dynamically. JSP essentially allows you to incorporate Java directly into an HTML page as a scripting language. JSP pages (text documents) are translated and compiled into Java servlets, which are then run in a web server just like any other servlet—some servers do the compilation automatically at runtime. JSP can also be used to generate XML documents dynamically.