The pieces that make up the J2EE architecture can be divided into three categories, as can be seen in Figure 10-1. Figure 10-1. J2EE components, containers, and services.These are:
ComponentsThere are three types of components defined in the J2EE model. These are:
Servlets and JSPs are components designed specifically for building Web-based applications and for simplifying the task of programming in an HTTP environment. These two technologies are more than adequate for developing many Web applications. EJBs are distributed objects that can be used to build multitier distributed applications. These applications can be either client-server applications or, in conjunction with servlets and JSPs, powerful, scalable Web applications. Because they encourage a component-based design, EJB applications can also be made flexible enough to accommodate multiple types of clients in addition to or instead of Web applications. ServletsServlets are Java classes that are associated with a URL when a user types a specific Web address into a browser, the servlet class is called with any parameters that the user may have provided. These parameters could be information that the user provided in an HTTP form or information provided in the URL itself. In response to the user request, a servlet generally either generates a new HTML page dynamically or passes control to another component, such as a JSP. JSPsJSPs are essentially HTML documents with embedded programming. This programming is similar to JavaScript with the important distinction that JavaScript is processed by the client browser, whereas JSPs are processed by the server. In fact, JSPs are converted into servlets. The client browser never sees the JSP (or servlet) code, only the HTML that is generated as a result of processing it. JSPs and servlets are largely interchangeable, but as we shall see, JSPs are best for designing Web pages with HTML and should include a bare minimum of code, whereas servlets are best for programming the logic of the Web site and the business in Java. EJBsEJBs are objects that can be invoked remotely and for this reason are a key J2EE component for building distributed, multitier applications. There are three different kinds of EJBs session beans, entity beans, and message (or message-driven) beans. In brief:
Session beans and entity beans are both used for database access, often in combination. In this chapter, we'll see an example of how a particular type of entity bean, a container-managed persistent entity bean, can simplify database access by delegating all database tasks creating retrieving, updating, and deleting records to the EJB container. In the next chapter, we'll take a more complete look at how session beans, entity beans, and databases can be used together. Message-driven beans are an interesting new feature in EJB (as of EJB 2.0), but they don't typically interact with a database and won't be covered here. ContainersJ2EE containers are programs that run on a server in order to provide a run-time environment for components. Containers manage the life cycles of components in response to client applications and mediate between components and the services they provide. There are two types of containers:
Typically, a program called an application server will perform these two roles. Even when that is the case, it is useful to consider these roles separately. Because one of the key goals of Java is portability not just between platforms but also between vendors Web applications and EJB applications developed for one application server, such as Oracle 9iApplication Server (AS), will usually run unchanged on another, such as BEA WebLogic, provided that you avoid proprietary features. ServicesTo be compliant with the J2EE specification, a container must provide a number of different services. These services are largely implementations of interfaces defined by the J2EE specification that permit a component to use a legacy system or technology, using a standard API. These include:
Even though most applications will use just a few of these services, the requirement that they all be supported helps ensure portability of J2EE applications across different vendors' application servers. The down side of this is that even if you use only a subset of this functionality, you may end up having to purchase and support an application server that is more complicated and expensive than you need. |