j2ee的13种核心技术(中英文字幕)

 


ava originally made its debut in browsers and client machines; at the time, many questioned whether it was suitable for server-side development. Now, with increasing third-party support for the Java 2 Platform, Enterprise Edition (J2EE), Java has become a widely accepted alternative for developing enterprise-strength server-side solutions.
The J2EE platform consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multitiered Web-based applications.
In this article, we will examine the 13 core technologies that make up J2EE: JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF. We will describe where and when it is appropriate to use each technology; we will also describe how the different technologies interact with each other.
Moreover, to give J2EE a real-world feel, we'll look at its main technologies in the context of WebLogic Server, a widely used J2EE implementation from BEA Systems. With that in mind, this introductory article will be of interest to developers new to WebLogic Server and J2EE, as well as project managers and business analysts with an interest in understanding what J2EE has to offer.
The big picture: Distributed architectures and J2EE
In the past, two-tier applications -- also known as client/server applications -- were commonplace. Figure 1 illustrates the typical two-tier architecture. In some cases, the only service provided by the server was that of a database server. In those situations, the client was then responsible for data access, applying business logic, converting the results into a format suitable for display, displaying the intended interface to the user, and accepting user input. The client/server architecture is generally easy to deploy at first, but is difficult to upgrade or enhance, and is usually based on proprietary protocols -- typically proprietary database protocols. It also makes reuse of business and presentation logic difficult, if not impossible. Finally, and perhaps most important in the era of the Web, two-tier applications typically do not prove very scalable and are therefore not well suited to the Internet.
 

Figure 1. Two-tier application architecture

[align=left] [/align]
[align=left]Sun designed J2EE in part to address the deficiencies of two-tier architectures. As such, J2EE defines a set of standards to ease the development of n-tier enterprise applications. It defines a set of standardized, modular components; provides a complete set of services to those components; and handles many details of application behavior -- such as security and multithreading -- automatically. [/align]
[align=left]Using J2EE to develop n-tier applications involves breaking apart the different layers in the two-tier architecture into multiple tiers. An n-tier application could provide separate layers for each of the following services: [/align]
[align=left] [/align]

Presentation: In a typical Web application, a browser running on the client machine handles presentation.
 

Dynamically generated presentation: Although a browser could handle some dynamically generated presentation, for the widest support of different browsers much of the action should be done on the Web server using JSPs, servlets, or XML (Extensible Markup Language) and XSL (Extensible Stylesheet Language).
 

Business logic: Business logic is best implemented in Session EJBs (described later).
 

Data access: Data access is best implemented in Entity EJBs (described later) and using JDBC.
 

Backend system integration: Integration with backend systems may use a variety of technologies. The best choice will depend upon the exact nature of the backend system.

You may begin to wonder: why have so many layers? Well, the layered approach makes for a more scalable enterprise application. It allows each layer to focus on a specific role -- for example, allowing a Web server to serve Webpages, an application server to serve applications, and a database server to serve databases.
Because it's built on top of the Java 2 Platform, Standard Edition (J2SE), J2EE provides all the same advantages and features of J2SE. These include "Write Once, Run Anywhere" portability, JDBC for database access, CORBA technology for interaction with existing enterprise resources, and a proven security model. Building on this base, J2EE then adds support for Enterprise JavaBean (EJB) components, Java servlets, JavaServer Pages (JSPs), and XML technology.
Distributed architectures with WebLogic Server
J2EE provides a framework -- a standard API -- for developing distributed architectures. The implementation of an engine to implement this framework is left up to third-party vendors. Some vendors will focus on particular components of the overall J2EE architecture. For example, Apache's Tomcat provides support for JSPs and servlets. BEA Systems provides a fuller implementation of the J2EE specification with its WebLogic Server product.
By providing a complete implementation of the J2EE specifications, WebLogic Server makes it easy to build and deploy scalable, distributed applications. WebLogic Server and J2EE handle certain common programming tasks for you. These include the provision of transaction services, security realms, guaranteed messaging, naming and directory services, database access and connection pooling, thread pooling, load balancing, and fault tolerance.
By providing these common services in an easy-to-use and standard way, products like WebLogic Server provide more scalable and maintainable applications. The result is increased availability of those applications to a larger number of users.

The J2EE technologies
In the following sections, we'll describe each of the technologies making up J2EE, and see how WebLogic Server supports them in a distributed application. Perhaps the most commonly used J2EE technologies include JDBC, JNDI, EJB, JSPs, and servlets, upon which we therefore focus our attention.
Figure 2 illustrates where each of the J2EE technologies are most commonly used within a distributed application.
 

Figure 2. A sample n-tier application architecture

[align=left] [/align]
[align=left]Java Database Connectivity (JDBC)
The JDBC API accesses a variety of databases in a uniform way. Like ODBC, JDBC hides proprietary database issues from the developer. Because it's built on Java, JDBC also is able to provide platform-independent access to databases. [/align]
[align=left]JDBC defines four fundamentally different types of drivers, as we'll see next. [/align]
[align=left]Type 1: JDBC-ODBC Bridge
The JDBC-ODBC Bridge proved most useful when JDBC was still in its infancy. With it, developers can use JDBC to access an ODBC data source. As a downside, it requires that an ODBC driver be installed on the client machine which, generally speaking, should be running a version of Microsoft Windows. By using this type of driver, you therefore sacrifice the platform independence of JDBC. Additionally, the ODBC driver requires client-side administration. [/align]
Type 2: JDBC-native driver bridge
The JDBC-native driver bridge provides a JDBC interface built on top of a native database driver -- without using ODBC. The JDBC driver converts standard JDBC calls into native calls to the API of the database. Using a type 2 driver also sacrifices the platform independence of JDBC and requires installation of client-side native co
13a06
de.
[align=left]Type 3: JDBC-network bridge
JDBC-network bridge drivers remove the need for client-side database drivers. They make use of network-server middleware to access a database. This makes such techniques as load balancing, connection pooling, and data caching possible. Because type 3 drivers often involve a relatively small download time, are platform independent, and require no client-side installation or administration, they are good for Internet applications. [/align]
[align=left]Type 4: Pure Java driver
Type 4 provides direct database access using a pure Java database driver. Due to the way type 4 drivers run on the client and directly access a database, running in this mode would imply a two-tier architecture. A better use of type 4 drivers in an n-tier architecture would be to have an EJB contain the data access code, and have that EJB provide a database-independent service to its clients. [/align]
[align=left]WebLogic Server provides JDBC drivers for some of the more common databases, including Oracle, Sybase, Microsoft SQL Server, and Informix. It also comes with a JDBC driver for Cloudscape, a pure Java DBMS, an evaluation copy of which comes with WebLogic Server. [/align]
[align=left]Next, let's look at an example. [/align]
[align=left]JDBC Example
Our example assumes that you have a PhoneBook database set up in Cloudscape, and that this database contains a table

CONTACT_TABLE

with fields

NAME

and

PHONE

. We begin by loading the Cloudscape JDBC driver, and requesting that the driver manager obtain a connection to the PhoneBook Cloudscape database. Using this connection, we construct a

Statement

object and use it to execute a simple SQL query. Finally, the loop iterates through all entries in the result set, writing the contents of the

NAME

and

PHONE

fields to the standard output. [/align]
[align=left]

[/align]
[align=left]
import java.sql.*;

public class JDBCExample
  {
  public static void main( String args[] )
    {
    try
      {
      Class.forName("COM.cloudscape.core.JDBCDriver");
      Connection conn = DriverManager.getConnection("jdbc:cloudscape:PhoneBook");
      Statement stmt = conn.createStatement();
      String sql = "SELECT name, phone FROM CONTACT_TABLE ORDER BY name";
      ResultSet resultSet = stmt.executeQuery( sql );

      String name;
      String phone;
      while ( resultSet.next() )
        {
        name = resultSet.getString(1).trim();
        phone = resultSet.getString(2).trim();
        System.out.println( name + ", " + phone );
        }
      }
    catch ( Exception e )
      {
      // Handle exception here
      e.printStackTrace();
      }
    }
  }
[/align]
[align=left]That's all there is to it. Next, let's look at the use of JDBC in enterprise applications. [/align]
[align=left]JDBC in enterprise applications
The previous example is, by necessity, somewhat trivial. It also assumes a two-tier architecture. In an n-tier enterprise application, it is much more likely that the client will communicate with an EJB, which, in turn, will make the database connection. To enable improved scalability and performance, WebLogic Server provides support for connection pools. [/align]
[align=left]Connection pools reduce the overhead of establishing and destroying database connections by creating a pool of database connections when the server starts up. When a connection to the database is subsequently required, WebLogic Server simply selects one from the pool rather than creating one from scratch. Connection pools in WebLogic Server are defined in the

weblogic.properties

file. (Refer to the examples in your

weblogic.properties

file and the WebLogic Server documentation for more information.) [/align]
[align=left]Another database feature frequently required in enterprise applications is support for transactions. A transaction is a group of statements that should be treated as a single statement to ensure data integrity. JDBC uses the

auto-commit

transaction mode by default. This can be overridden using the

setAutoCommit()

method of the

Connection

class. [/align]
[align=left]Now that we have a sense of JDBC, let's turn our attention to JNDI. [/align]
[align=left][/align]
[align=left]Java Naming and Directory Interface (JNDI)
The JNDI API is used to access naming and directory services. As such, it provides a consistent model for accessing and manipulating such enterprise-wide resources as DNS, LDAP, local filesystems, or objects in an application server. [/align]
[align=left]In JNDI, every node in a directory structure is called a context. Every JNDI name is relative to a context; there is no notion of an absolute name. An application can obtain its first context using the

InitialContext

class: [/align]
[align=left]

[/align]
[align=left]
Context ctx = new InitialContext();
[/align]
[align=left]From this initial context, the application can traverse the directory tree to locate the desired resources or objects. For example, assume that you have deployed an EJB within WebLogic Server and bound the home interface to the name

myApp.myEJB

. A client of this EJB, after obtaining an initial context, could then locate the home interface using: [/align]
[align=left]

[/align]
[align=left]
MyEJBHome home = ctx.lookup( "myApp.myEJB" );
[/align]
[align=left]Once you have a reference to the acquired object -- in this case, the home interface of the EJB -- it is then possible to invoke methods on it. We will discuss this further in the section below entitled "Enterprise Java Beans." [/align]
[align=left]The above discussion of JNDI is just the tip of the iceberg. In addition to looking up objects in a context, JNDI also provides methods to: [/align]
[align=left] [/align]

Insert, or bind, an object into a context. This is effectively what you do when you deploy an EJB.
 

Remove an object from a context.
 

List all objects within a context.
 

Create and delete subcontexts.

Next, let's turn our attention to EJBs.
Enterprise Java Beans (EJB)
One of the J2EE technologies to receive a great deal of media attention is EJBs. They provide a framework for developing and deploying distributed business logic to clients, thereby significantly easing the development of scalable, highly complex enterprise applications. The EJB specification defines how and when EJB components should interact with their container. It is the responsibility of the container to provide for common services, such as directory services, transaction management, security, resource pooling, and fault tolerance.
The EJBs specification defines three fundamental types of bean:
 

[align=left]Stateless session beans: These provide a single-use service, do not maintain any state, do not survive server crashes, and are relatively short lived. For example, a stateless session bean may be used to perform temperature conversion. [/align]
 

[align=left]Stateful session bean: These provide a conversational interaction with the client and, as such, store state on the behalf of the client. An online shopping cart is a classic example of a stateful session bean. Stateful session beans do not survive server crashes, are also relatively short lived, and each instance can be used only by a single thread. [/align]
 

[align=left]Entity beans: These provide a representation of persistent data -- typically stored in a database -- and can therefore survive a server crash. Multiple clients can use EJBs that represent the same data. An example of an entity EJB: a customer's account information. [/align]

In spite of their differences, all EJBs have much in common. They all possess a home interface that defines how a client can create and destroy the EJB; a remote interface that defines the methods a client can invoke on the bean; and a bean class that implements the main business logic.
Describing how to develop an EJB is beyond the scope of this article. However, once an EJB has been developed or purchased from a third party, it must be deployed in your application server. WebLogic Server 5.1 comes with an EJB Deployer Tool to assist with deployment of EJBs. When you deploy an EJB using the EJB Deployer Tool, you specify the JNDI name used by clients to locate the EJB. The Deployer Tool will then generate wrapper classes to handle communications with the container and bundle the required Java classes together in a jar file.
Once an EJB has been deployed, a client can locate the EJB using its JNDI name. First, it must obtain a reference to the home interface. Then, using that interface, the client can invoke one of the bean's

create()

methods to obtain a handle to a bean instance running on the server. Finally, the client may use this handle to invoke methods on the bean.
From EJBs, we shift to JSPs.
JavaServer Pages (JSPs)
Some of you may already be familiar with Microsoft's Active Server Pages (ASPs); JSPs are the platform-independent equivalent. They were designed to help Web content developers create dynamic Webpages with relatively little coding. Web designers who don't know how to program can use JSPs to create dynamic pages. A JavaServer Page consists of HTML code interspersed with Java code. The server processes the Java code when the page is requested by the client, returning the generated HTML page to the browser.
Let's look at a simple example of a JSP that displays the server's current date and time. An explanation of the details of this is beyond the scope of this article; however, note the Java code between the

<%

and

%>

symbols, followed by the Java expression between the

<%=

and

%>

symbols.

<html>
<head>
<title>Sample JSP Page</title>
</head>
<body>
<h1>Date JSP sample</h1>

<h2>
<% response.setHeader("Refresh", 5); %>
The current date is <%= new Date()  %>.
</h2>

</body>
</html>

You may occasionally hear reference to JHTML, an older standard since superseded by JSPs. WebLogic Server can support JSPs as well as JHTML. Note that, by default, JSPs are not enabled within WebLogic Server. To enable them, you must edit the

weblogic.properties

file and enable the Web server -- if it hasn't already been enabled -- as well as the JSPServlet.
Next up: Java servlets

Java servlets
A servlet provides much the same functionality as a JSP, albeit by taking a somewhat different approach. Whereas JSPs typically consist mostly of HTML code interspersed with small amounts of Java code, servlets, on the other hand, are written totally in Java and produce HTML code.
A servlet is a small Java program that extends the functionality of a Web server. It is a server-side application dynamically executed when requested, much like CGI Perl scripts in more traditional Web servers. One of the major differences between CGI scripts and servlets: CGI scripts require a whole new process to be started -- incurring additional overhead -- whereas servlets are executed as a separate thread within the servlet engine. Servlets therefore tend to offer improved scalability.
When developing servlets, you will generally want to extend the

javax.servlet.http.HttpServlet

class, and override some of its methods. The methods of most interest include:
 

[align=left]

service()

: Acts as a dispatcher to command-specific methods [/align]

[align=left]

doGet()

: Handles an HTTP GET request from a client [/align]

[align=left]

doPost()

: Handles an HTTP POST request from a client [/align]

Other methods exist to handle different types of HTTP requests -- refer to the HttpServlet API documentation for more information (see Resources).
The methods described above are all part of the standard J2EE Servlet API. WebLogic Server provides a full implementation of this API. Once you have developed your servlet, you can deploy it in WebLogic Server by registering it in the

weblogic.properties

file.
With Java servlets, we've reached the end of J2EE's major technologies, but that's not the end to what J2EE has to offer. In the next sections, we'll take a brief look at the remaining technologies, including RMI, Java IDL and CORBA, JTA, and XML, to name a few.
Remote Method Invocation (RMI)
As its name suggests, the RMI protocol invokes methods on remote objects. It uses serialization to pass data between the client and the server. RMI is the underlying protocol used by EJBs.
Java IDL/CORBA
With Java's IDL support, developers can integrate Java with CORBA. They can create Java objects that can be deployed within a CORBA ORB, and they can create Java classes that act as clients to CORBA objects deployed within other ORBs. The latter approach provides another way in which Java can be used to integrate your new application with legacy systems.
Java Transaction Architecture (JTA)/Java Transaction Service (JTS)
JTA defines a standard API that applications can use to access transaction monitors.
JTS is a basic implementation of a CORBA OTS transaction monitor. JTS specifies the implementation of a Transaction Manager that supports the Java Transaction API (JTA) specification at a high level and implements the Java mapping of the OMG OTS specification at a low level. A JTS Transaction Manager provides transaction services to the application server, the resource manager, standalone applications, and the Communications Resource Manager.
JavaMail and JavaBeans Activation Framework
JavaMail is an API for accessing mail servers. The JavaMail API provides a set of abstract classes that model a mail system. Both SMTP and IMAP servers are supported.
JavaMail makes use of the JavaBeans Activation Framework (JAF) to handle MIME-encoded mail attachments. MIME byte streams can be converted to and from Java objects. Most applications will not have to use JAF directly.
Java Messaging Service (JMS)
JMS is an API for communicating with message-oriented middleware. It supports both the point-to-point domain and the publish/subscribe domain, and provides support for guaranteed message delivery, transactional message delivery, persistent messages, and durable subscribers. JMS provides another way of integrating your application with legacy backend systems.
Extensible Markup Language (XML)
XML is a language for defining other markup languages. It can be used to share data between businesses. XML was developed independently from Java; however, it shares similar goals in that it is platform independent. By combining Java with XML, you have a completely platform-independent solution. Various companies are working on developing a tight integration between Java and XML. For more information, visit Sun's Java-XML page, or the XML Zone at IBM's developerWorks (see Resources for the URLs).
Conclusion
In this article, we introduced distributed architectures built upon J2EE, and we described WebLogic Server's support for J2EE. This, however, is just the tip of the iceberg, as no 3,000 word article could begin to do justice to J2EE's potential impact on your enterprise applications.
We focused our attention on the technologies that you are most likely to encounter when you begin working with J2EE: JDBC, JNDI, EJBs, JSPs, and servlets. We also provided you with some background information on the less well-known J2EE technologies. Whether you are a developer, business analyst, or project manager, you now should have a good idea of what J2EE and WebLogic Server have to offer you, your enterprise, and your enterprise applications.
译文：
JAVA最初是在浏览器和客户端机器中粉墨登场的。当时，很多人质疑它是否适合做服务器端的开发。现在，随着对JAVA2平台企业版（J2EE）第三方支持的增多，JAVA被广泛接纳为开发企业级服务器端解决方案的首选平台之一。

　　J2EE平台由一整套服务（SERVICES）、应用程序接口（APIS）和协议构成，它对开发基于WEB的多层应用提供了功能支持。

　　在本文中我将解释支撑J2EE的13种核心技术：JDBC, JNDI, EJBS, RMI, JSP, JAVA SERVLETS, XML, JMS, JAVA IDL, JTS, JTA, JAVAMAIL 和 JAF，同时还将描述在何时、何处需要使用这些技术。当然，我还要介绍这些不同的技术之间是如何交互的。

　　此外，为了让您更好地感受J2EE的真实应用，我将在WEBLOGIC应用服务器—来自BEA SYSTEMS公司的一种广为应用的产品—环境下来介绍这些技术。不论对于WEBLOGIC应用服务器和J2EE的新手，还是那些想了解J2EE能带来什么好处的项目管理者和系统分析员，相信本文一定很有参考价值。

　　宏观印象: 分布式结构和J2EE

　　过去，二层化应用 -- 通常被称为CLIENT/SERVER应用 -- 是大家谈论的最多的。图1刻画了典型的二层化结构。在很多情况下，服务器提供的唯一服务就是数据库服务。在这种解决方案中，客户端程序负责数据访问、实现业务逻辑、用合适的样式显示结果、弹出预设的用户界面、接受用户输入等。CLIENT/SERVER结构通常在第一次部署的时候比较容易，但难于升级或改进，而且经常基于某种专有的协议—通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。更重要的是，在WEB时代，二层化应用通常不能体现出很好的伸缩性，因而很难适应INTERNET的要求。

　　图1. 二层化应用结构

　　SUN设计J2EE的部分起因就是想解决二层化结构的缺陷。于是，J2EE定义了一套标准来简化N层企业级应用的开发。它定义了一套标准化的组件，并为这些组件提供了完整的服务。J2EE还自动为应用程序处理了很多实现细节，如安全、多线程等。

　　用J2EE开发N层应用包括将二层化结构中的不同层面切分成许多层。一个N层化应用A能够为以下的每种服务提供一个分开的层：

　　显示：在一个典型的WEB应用中，客户端机器上运行的浏览器负责实现用户界面。

　　动态生成显示: 尽管浏览器可以完成某些动态内容显示，但为了兼容不同的浏览器，这些动态生成工作应该放在WEB服务器端进行，使用JSP、SERVLETS，或者XML（可扩展标记语言）和（可扩展样式表语言）。

　　业务逻辑：业务逻辑适合用SESSION EJBS（后面将介绍）来实现。

　　数据访问：数据访问适合用ENTITY EJBS（后面将介绍）和JDBC来实现。

　　后台系统集成: 同后台系统的集成可能需要用到许多不同的技术，至于何种最佳需要根据后台系统的特征而定。

　　您可能开始诧异：为什么有这么多的层？事实上，多层方式可以使企业级应用具有很强的伸缩性，它允许每层专注于特定的角色。例如，让WEB服务器负责提供页面，应用服务器处理应用逻辑，而数据库服务器提供数据库服务。

　　由于J2EE建立在JAVA2平台标准版（J2SE）的基础上，所以具备了J2SE的所有优点和功能。包括“编写一次，到处可用”的可移植性、通过JDBC访问数据库、同原有企业资源进行交互的CORBA技术，以及一个经过验证的安全模型。在这些基础上，J2EE又增加了对EJB（企业级JAVA组件）、JAVA SERVLETS、JAVA服务器页面（JSPS）和XML技术的支持。

　　分布式结构与WEBLOGIC应用服务器

　　J2EE提供了一个框架--一套标准API--用于开发分布式结构的应用，这个框架的实际实现留给了第三方厂商。部分厂商只是专注于整个J2EE架构中的的特定组件，例如APACHE的TOMCAT提供了对JSP和SERVLETS的支持，BEA系统公司则通过其WEBLOGIC应用服务器产品为整个J2EE规范提供了一个较为完整的实现。

　　WEBLOGIC服务器已使建立和部署伸缩性较好的分布式应用的过程大为简化。WEBLOGIC和J2EE代你处理了大量常规的编程任务，包括提供事务服务、安全领域、可靠的消息、名字和目录服务、数据库访问和连接池、线程池、负载平衡和容错处理等。

　　通过以一种标准、易用的方式提供这些公共服务，象WEBLOGIC服务器这样的产品造就了具有更好伸缩性和可维护性的应用系统，使其为大量的用户提供了增长的可用性。

　　J2EE技术

　　在接下来的部分里，我们将描述构成J2EE的各种技术，并且了解WEBLOGIC服务器是如何在一个分布式应用中对它们进行支持的。最常用的J2EE技术应该是JDBC、JNDI、EJB、JSP和SERVLETS，对这些我们将作更仔细的考察。

　　图2表示了在一个分布式应用中，J2EE技术的各个方面通常在何处发挥作用。

　　图2. 一个N层应用结构的例子

　　JAVA DATABASE CONNECTIVITY (JDBC)

　　JDBC API以一种统一的方式来对各种各样的数据库进行存取。和ODBC一样，JDBC为开发人员隐藏了不同数据库的不同特性。另外，由于JDBC建立在JAVA的基础上,因此还提供了数据库存取的平台独立性。

　　JDBC定义了4种不同的驱动程序，现分述如下：

　　类型 1: JDBC-ODBC BRIDGE

　　在JDBC出现的初期，JDBC-ODBC桥显然是非常有实用意义的，通过JDBC-ODBC桥，开发人员可以使用JDBC来存取ODBC数据源。不足的是，他需要在客户端安装ODBC驱动程序，换句话说，必须安装MICROSOFT WINDOWS的某个版本。使用这一类型你需要牺牲JDBC的平台独立性。另外，ODBC驱动程序还需要具有客户端的控制权限。

　　类型 2: JDBC-NATIVE DRIVER BRIDGE

　　JDBC本地驱动程序桥提供了一种JDBC接口，它建立在本地数据库驱动程序的顶层，而不需要使用ODBC。 JDBC驱动程序将对数据库的API从标准的JDBC调用转换为本地调用。使用此类型需要牺牲JDBC的平台独立性，还要求在客户端安装一些本地代码。

　　类型 3: JDBC-NETWORK BRIDGE

　　JDBC网络桥驱动程序不再需要客户端数据库驱动程序。它使用网络上的中间服务器来存取数据库。这种应用使得以下技术的实现有了可能，这些技术包括负载均衡、连接缓冲池和数据缓存等。由于第3种类型往往只需要相对更少的下载时间，具有平台独立性，而且不需要在客户端安装并取得控制权，所以很适合于INTERNET上的应用。

　　类型 4: PURE JAVA DRIVER

　　第4种类型通过使用一个纯JAVA数据库驱动程序来执行数据库的直接访问。此类型实际上在客户端实现了2层结构。要在N-层结构中应用，一个更好的做法是编写一个EJB，让它包含存取代码并提供一个对客户端具有数据库独立性的服务。

　　WEBLOGIC服务器为一些通常的数据库提供了JDBC驱动程序，包括ORACLE, SYBASE, MICROSOFT SQL SERVER以及INFORMIX。它也带有一种JDBC驱动程序用于CLOUDSCAPE，这是一种纯JAVA的DBMS，WEBLOGIC服务器中带有该数据库的评估版本。

　　以下让我们看一个实例。

　　JDBC实例

　　在这个例子中我们假定你已经在CLOUDSCAPE中建立了一个PHONEBOOK数据库，并且包含一个表，名为 CONTACT_TABLE ，它带有2个字段：NAME 和 PHONE。 开始的时候先装载CLOUDSCAPE JDBC DRIVER，并请求 DRIVER MANAGER得到一个对PHONEBOOK CLOUDSCAPE数据库的连接。通过这一连接，我们可以构造一个 STATEMENT 对象并用它来执行一个简单的SQL查询。最后，用循环来遍历结果集的所有数据，并用标准输出将NAME和PHONE字段的内容进行输出。

import java.sql.*;

public class JDBCExample
  {
  public static void main( String args[] )
    {
    try
      {
      Class.forName("COM.cloudscape.core.JDBCDriver");
      Connection conn = DriverManager.getConnection("jdbc:cloudscape:PhoneBook");
      Statement stmt = conn.createStatement();
      String sql = "SELECT name, phone FROM CONTACT_TABLE ORDER BY name";
      ResultSet resultSet = stmt.executeQuery( sql );

      String name;
      String phone;
      while ( resultSet.next() )
        {
        name = resultSet.getString(1).trim();
        phone = resultSet.getString(2).trim();
        System.out.println( name + ", " + phone );
        }
      }
    catch ( Exception e )
      {
      // Handle exception here
      e.printStackTrace();
      }
    }
  }

　　OK。接着我们来看一看JDBC是如何在企业应用中的进行使用。

　　JDBC在企业级应用中的应用

　　以上实例其实是很基本的，可能有些微不足道。它假定了一个2层结构。在一个多层的企业级应用中，更大的可能是在客户端和一个EJB进行通信，该EJB将建立数据库连接。为了实现和改进可伸缩性和系统性能， WEBLOGIC服务器提供了对连接缓冲池CONNECTION POOL的支持。

　　CONNECTION POOL减少了建立和释放数据库连接的消耗。在系统启动以后即可建立这样的缓冲池，此后如故再有对数据库的请求，WEBLOGIC服务器可以很简单地从缓冲池中取出数据。数据缓冲池可以在WEBLOGIC服务器的 WEBLOGIC.PROPERTIES 文件中进行定义。(可参考 WEBLOGIC.PROPERTIES 文件中的例子，WEBLOGIC服务器的文档中还有更详细的参考信息)

　　在企业级应用的另一个常见的数据库特性是事务处理。事务是一组申明STATEMENT，它们必须做为同一个STATEMENT来处理以保证数据完整性。缺省情况下JDBC使用 AUTO-COMMIT 事务模式。这可以通过使用CONNECTION类的 SETAUTOCOMMIT() 方法来实现。

　　现在我们已经对JDBC有了一些认识，下面该转向JNDI了。

　　JAVA NAMING AND DIRECTORY INTERFACE (JNDI)

　　JNDI API被用于执行名字和目录服务。它提供了一致的模型来存取和操作企业级的资源如DNS和LDAP，本地文件系统，后者在应用服务器中的对象。

　　在JNDI中，在目录结构中的每一个结点称为CONTEXT。每一个JNDI名字都是相对于CONTEXT的。这里没有绝对名字的概念存在。对一个应用来说，它可以通过使用 INITIALCONTEXT 类来得到其第一个CONTEXT:

　　CONTEXT CTX = NEW INITIALCONTEXT();

　　应用可以通过这个初始化的CONTEXT经有这个目录树来定位它所需要的资源或对象。例如，假设你在WEBLOGIC服务器中展开了一个EJB并将HOME接口绑定到名字 MYAPP.MYEJB ，那么该EJB的某个客户在取得一个初始化CONTEXT以后，可以通过以下语句定位HOME接口：

　　MYEJBHOME HOME = CTX.LOOKUP( "MYAPP.MYEJB" );

　　在这个例子中，一旦你有了对被请求对象的参考，EJB的HOME接口就可以在它上面调用方法。我们将在下面的"ENTERPRISE JAVA BEANS"章节中做更多的介绍。

　　以上关于JNDI的讨论只是冰山之一角而已。如果要更进一步地在CONTEXT中查找对象，JNDI也提供了一些方法来进行以下操作：　

　　将一个对象插入或绑定到CONTEXT。这在你展开一个EJB的时候是很有效的。

　　从CONTEXT中移去对象。

　　列出CONTEXT中的所有对象。

　　创建或删除子一级的CONTEXT。

　　接下来，我们要开始关注EJB了。

　　ENTERPRISE JAVA BEANS (EJB)

　　J2EE技术之所以赢得某体广泛重视的原因之一就是EJB。它们提供了一个框架来开发和实施分布式商务逻辑，由此很显著地简化了具有可伸缩性和高度复杂的企业级应用的开发。EJB规范定义了EJB组件在何时如何与它们的容器进行交互作用。容器负责提供公用的服务，例如目录服务、事务管理、安全性、资源缓冲池以及容错性。

　　EJB规范定义了3中基本的BEAN类型:

　　STATELESS SESSION BEANS: 提供某种单一的服务，不维持任何状态，在服务器故障发生时无法继续存在，生命期相对较短。例如，一个STATELESS SESSION BEAN可能被用于执行温度转换计算。

　　STATEFUL SESSION BEAN: T提供了与客户端的会话交互，可以存储状态从而代表一个客户。典型例子是购物车。STATEFUL SESSION BEAN在服务器故障时无法继续生存，生命气相对较短。每一个实例只用于一个单个的线程。

　　ENTITY BEANS: 提供了一致性数据的表示-- 通常存放在数据库中 -- 在服务器故障发生后能继续存在。多用户情况下可以使用EJB来表示相同的数据。ENTITY EJB的一个典型例子是客户的帐号信息。

　　尽管有以上的区别，所有的EJB还是有许多的共同之处。它们都处理HOME INTERFACE。它定义了一个客户端是如何创建与消亡EJB的。可以在BEAN中对定义了客户端方法的远程接口进行调用；BEAN类则执行了主要的商务逻辑。

　　描述EJB的开发已经超出了本文的范围。但是，如果一个EJB已经被开发了或者从第三方进行了购买，它就必须在应用服务器中进行发布。WEBLOGIC SERVER 5.1带有一个EJB DEPLOYER TOOL来协助处理EJB的发布。当你使用EJB DEPLOYER TOOL的时候，你要定义客户端所用的JNDI名字来定位EJB。DEPLOYER TOOL将生成WRAPPER类来处理和容器的通信以及在一个JAR文件中把被请求的JAVA类绑定在一起。

　　一旦EJB被发布，客户端就可以使用它的JNDI名字来定位EJB。首先，它必须得到一个到HOME接口的REFERENCE。然后，客户端可以使用该接口，调用一个 CREATE() 方法来得到服务器上运行的某个BEAN实例的句柄；最后，客户端可以使用该句柄在BEAN中调用方法。

　　了解 EJB后，让我们再来看JSP。

　　JAVASERVER PAGES (JSPS)

　　我们中间可能已经有许多人已经熟悉MICROSOFT的ACTIVE SERVER PAGES (ASP)技术了。JSP和ASP相对应的，但更具有平台对立性。他们被设计用以帮助WEB内容开发人员创建动态网页，并且只需要相对较少的代码。 即使WEB设计师不懂得如何编程也可以使用JSP，因为JSP应用是很方便的。 JSP页面由HTML代码和嵌入其中的JAVA代码所组成。服务器在页面被客户端所请求以后对这些JAVA代码进行处理，然后将生成的HTML页面返回给客户端的浏览器。

　　下面我们来看一个JSP的简单实例。它只显示了服务器的当前日期和时间。虽然，对语法的具体解释已经超出了本文的范围，但我们还是可以很直观地看到，JAVA代码被放在的中间，而JAVA的表达式则放在之间。

<html>
<head>
<title>Sample JSP Page</title>
</head>
<body>
<h1>Date JSP sample</h1>

<h2>
<% response.setHeader("Refresh", 5); %>
The current date is <%= new Date()  %>.
</h2>

</body>
</html>

　　您可能有时候听说过JHTML。这是JSP以前的一种较老的标准。WEBLOGIC服务器既可支持JSP，又可支持JHTML。请注意，在缺省状况下，JSP在WEBLOGIC服务器中并没有处于有效状态。要使之有效，你可以编辑WEBLOGIC.PROPERTIES文件。如果WEB服务器还没有处于有效状态，则要先使之有效。SERVLET的情况和JSP是一样的。

　　下面是: JAVA SERVLETS

　　JAVA SERVLETS

　　SERVLET提供的功能大多与JSP类似，不过实现的方式不同。JSP通常是大多数HTML代码中嵌入少量的JAVA代码，而SERVLETS全部由JAVA写成并且生成HTML。

　　SERVLET是一种小型的JAVA程序，它扩展了WEB服务器的功能。作为一种服务器端的应用，当被请求时开始执行，这和CGI PERL脚本很相似。SERVLETS和CGI脚本的一个很大的区别是：每一个CGI在开始的时候都要求开始一个新的进程 -- 而SERVLETS是在SERVLET引擎中以分离的线程来运行的。因此SERVLETS在可伸缩性上提供了很好的改进。

　　在开发SERVLETS的时候，您常常需要扩展JAVAX.SERVLET.HTTP.HTTPSERVLET 类，并且OVERRIDE一些它的方法，其中包括：

　　SERVICE(): 作为DISPATCHER来实现命令-定义方法

　　DOGET(): 处理客户端的HTTP GET请求。

　　DOPOST(): 进行HTTP POST操作

　　其它的方法还包括处理不同类型的HTTP请求 -- 可以参考HTTPSERVLET API文档。

　　以上描述的是标准J2EE SERVLET API的各种方法。WEBLOGIC服务器提供了一个该API完整的实现途径。一旦你开发了一个SERVLET，你就可以在WEBLOGIC.PROPERTIES 中加以注册并由此可以在WEBLOGIC服务器中对它进行配置。

　　通过JAVA SERVLETS,我们已经到达了J2EE主要技术的末尾了。但J2EE所提供的并不止于这些。下面的段落中我们将简要地看一下现存的一些技术，包括RMI, JAVA IDL和CORBA, JTA, 以及XML，等等。

　　REMOTE METHOD INVOCATION (RMI)

　　正如其名字所表示的那样，RMI协议是在远程对象上调用一些方法。它使用了连续序列方式在客户端和服务器端传递数据。RMI是一种被EJB使用的更下层的协议。

　　JAVA IDL/CORBA

　　在JAVA IDL的支持下，开发人员可以将JAVA和CORBA集成在一起。 他们可以创建JAVA对象并使之可在CORBA ORB中展开, 或者他们还可以创建JAVA类并作为和其它ORB一起展开的CORBA对象的客户。后一种方法提供了另外一种途径，通过它JAVA可以被用于将你的新的应用和LEGACY系统相集成。

　　JAVA TRANSACTION ARCHITECTURE (JTA)/JAVA TRANSACTION SERVICE (JTS)

　　JTA定义了一种标准的API，应用系统由此可以存取各种事务监控。

　　JTS是CORBA OTS事务监控的基本的实现。JTS规定了事务管理器的实现方式。该事务管理器是在高层支持JAVA TRANSACTION API (JTA)规范，并且在较底层实现OMG OTS SPECIFICATION的JAVA映像。JTS事务管理器为应用服务器、资源管理器、独立的应用以及通信资源管理器提供了事务服务。

　　JAVAMAIL AND JAVABEANS ACTIVATION FRAMEWORK

　　JAVAMAIL是用于存取邮件服务器的API，它提供了一套邮件服务器的抽象类。不仅支持SMTP服务器，也支持IMAP服务器。

　　JAVAMAIL利用JAVABEANS ACTIVATION FRAMEWORK (JAF)来处理MIME-编码的邮件附件。MIME的字节流可以被转换成JAVA对象，或者转换自JAVA对象。由此大多数应用都可以不需要直接使用JAF。

　　JAVA MESSAGING SERVICE (JMS)

　　JMS是用于和面向消息的中间件相互通信的应用程序接口(API)。它既支持点对点的域，有支持发布/订阅(PUBLISH/SUBSCRIBE)类型的域，并且提供对下列类型的支持：经认可的消息传递,事务型消息的传递，一致性消息和具有持久性的订阅者支持。JMS还提供了另一种方式来对您的应用与LEGACY BACKEND系统相集成。

　　EXTENSIBLE MARKUP LANGUAGE (XML)

　　XML是一种可以用来定义其它标记语言的语言。它被用来在不同的商务过程中共享数据。XML的发展和JAVA是相互独立的，但是，它和JAVA具有的相同目标正是平台独立性。通过将JAVA和XML的组合，您可以得到一个完美的具有平台独立性的解决方案。目前正有许多不同的公司在为JAVA和XML的组合而努力。如果要了解更多的这方面的信息，可以访问SUN的JAVA-XML页面，或者IBM DEVELOPERWORKS的XML ZONE。

　　总结

　　在本文中，我们介绍了建立在J2EE上的分布式应用结构，并且描述了WEBLOGIC服务器对J2EE的各种支持。 然而，我们所揭示的仅仅是冰山之一角而已，要以一篇数千字的文章来展示J2EE潜在的对您的企业级应用的影响可是很不公平的。

　　我们已经关注了在您开始用J2EE进行工作时最有可能遇到的各类技术：JDBC, JNDI, EJB, JSP和SERVLET。我们也为您提供了一些尚未常见的J2EE技术的背景知识。不管您是一名开发人员，商务应用分析师，或者项目经理，都应该对J2EE和WEBLOGIC服务器所能提供给我们，给我们的企业以及我们的企业级应用所带来的意义有一个更好的认识。