计算机英语翻译－－题目八

Java 2 Enterprise Edition 1.3

Taking into consideration the disparate technologies based on the Java programming language and their application areas, the Java 2 Enterprise Edition (J2EE) is a move to combine the technologies under a common standardized architecture that lets developers leverage and mix-and-match the different technologies in Java. This makes more sense when building multi-tier enterprise applications that run on different operating systems and interact with different information sources. Multi-tier enterprise applications are inherently difficult to build, and without a standard architecture, that effort is repeated when building many enterprise applications. A standard architecture also demonstrates the validity of the concept that the different technologies will work together.

Apart from the consolidation of different technologies under one roof, the J2EE specification also defines roles and demarcates responsibilities to be undertaken when an enterprise application is being built. Because these roles map to real-life activities that need to be undertaken, the J2EE specification has found acceptance in the industry. Moreover, the J2EE specification is an industry-driven effort to standardize enterprise application architectures and to reduce the time needed to build enterprise applications.

Next you will study the different roles defined by the J2EE specification 1.3 supported by WebLogic Server 7.0.

J2EE Roles

The J2EE specification defines distinct roles based on the tasks and activities carried out when building enterprise applications. These roles can be assigned to different team members of your project or can be combined together to be carried out by the same person. It depends on the complexity of the application and the skill level of the person(s) carrying out the tasks. The different roles defined in the EJB specification are as follows:

·         Server provider— The application server is the overall infrastructure environment where the containers reside. An application server contains one or more containers. The integration and communication between these containers as well as allied services required for the containers, such as transaction drivers, database drivers, resource adapters, and so on, are supplied by the server provider.

·         Container provider— The actual run-time environment in which the application components are executed is the container. There can be different containers available for the different application components because the application components are based on different technologies. Servlet container and EJB container are a couple of examples of the types of containers available from a container provider. Containers provide life-cycle and support services for application components. Examples of these services are life-cycle management, connection pool management, instance pooling, transaction management, security management, and so on.

Container providers are required to build their containers to be compliant with the J2EE specification. This ensures that application components can be built and guaranteed to execute on a container regardless of the container provider that supplies it. Essentially, the J2EE specification ensures portability of applications regardless of where they are developed and deployed. Typically, a container provider and server provider are the same entity.

·         Application component provider— An application component provider develops the different components that make up the enterprise application. The application component provider can create different application components, such as JavaServer Pages/HTML files, Java Servlets, Enterprise JavaBeans, and so on. Third-party tools can be used by the application component provider to create these application components.

·         Application assembler— Assembling the different application components of an enterprise application is carried out by an application assembler. Different tools are utilized by the application assembler to generate the Enterprise Application archive (.ear file), which will be used by the application server to provide a configured runtime environment based on the settings defined by the deployer in the deployment descriptor files.

·         Deployer— An important role in building J2EE applications is deploying the applications. Deployment activities generally define the runtime environment for the application. Also, any declarative parameters for the J2EE application can be specified at deployment time. Generally, tasks such as virtual path mappings, transaction information and attributes definition, connection pool definition, security roles, and so on fall under the purview of a deployer. Depending on the complexity of the application, there may be a specialist deployer for the application, or developers themselves can carry out deployment activities for simple applications. Deployment information for the different components of an enterprise application is registered in a set of files called the deployment descriptor files. An application server or container reads and interprets these deployment descriptor files and configures the runtime environment for the enterprise application.

·         System administrator— The responsibility of configuring and maintaining the overall infrastructure of the application server environment as well as the containers within it lies with the system administrator. The system administrator utilizes performance-monitoring and configuring tools for performing the activities defined for this role.

·         Tool provider— As any experienced developer knows, tools make life much easier and simpler. Tools also improve overall productivity, resulting in shorter development cycles. Hence, the J2EE specification defines tool provider as a significant role. The different technologies that form the J2EE specification have well-defined interfaces that can be leveraged by tool providers to build tools for interacting with these technology components in a standard way. For developers this means that regardless of the tool provider from which the tools are obtained, the tools are guaranteed to interact with the technologies in a consistent way.

As you study each of the technologies covered in this book, you are going to perform the roles of the application component provider, application assembler, deployer, and system administrator at various stages of each sample application. BEA WebLogic Server performs the roles of server provider, container provider, and tool provider. There is a clear demarcation of the roles defined in the J2EE specification.

Component, Container, and Connector

J2EE consists of three main interlinked areas:

·         Components— As you learned earlier, components are the building blocks of applications. These pieces of code perform business functions and encapsulate business rules. Components are deployed on containers and use connectors to access enterprise resources.

·         Containers— Containers provide the actual execution environment for components. J2EE enables components to interact with containers in a consistent way. This ensures the portability of components across containers of different application server vendors. The containers facilitate interaction between components and connectors.

·         Connectors— Connectors provide a portable and consistent API that is used by components to access enterprise resources of different vendors. Connectors plug in to containers to make this possible.

Java Servlet API

The Java Servlet API is an extension to the standard Java packages and marks the first move of Java from the standard application domain to the server-side. This API aids developers in building powerful and efficient Web applications using a simple API. The entire HTTP protocol is encapsulated in a set of classes in the Java Servlet API.

The Java Servlet API enables development of Web application components that can be deployed on any Java Servlet API–compliant servlet container. The API defines a set of classes for building generic servlets as well as HTTP protocol servlets. Apart from the support for the HTTP protocol, the Java Servlet API also provides useful features, such as filters and listeners, which enable application component providers to enhance their Web-application components.

When you use the Java Servlet API to build Web-application components, the servlet container guarantees that the Web application will receive the browser request data in the format it expects and can send back the response data in the format that the client browser expects. The Web-application-component provider can focus on writing the application logic for the component and need not worry about writing code to parse and interpret the format in which the client browser sends and receives data.

JavaServer Pages (JSPs)

JavaServer Pages (JSPs) are based on the concept of server-side parsing. A JavaServer Page is an HTML page with Java statements embedded in it. The JSP specification defines certain special tags that can be embedded within the HTML page. In a normal working scenario, the JSP pages are parsed by a JSP compiler within the application server and converted into a Java servlet with the generated code embedded within the Java servlet as a set of Java statements. The generated Java servlet is then compiled as a normal servlet and loaded into the Java servlet container. The Java servlet is then used to process the user requests.

In effect, the JSP specification simplifies the development of Java servlets, thus enabling specialized user interface (UI) application component providers to focus on building Web-enabled UIs for their applications. More importantly, JSP allows you to separate the development of the content and business logic of a Web application from the look and feel of the application.

The JSP specification defines the following set of tags that can be used by application component providers:

·         Directive tag— A directive tag embedded in a JSP is used to issue directives to the JSP compiler that compiles the JSP.

·         Declaration tag— A declaration tag can be used by the application component provider to define variables or methods that need to be put outside the service() method of the final generated Java servlet.

·         Expression tag— In order to use Java values or variables directly in the JSP, you can use the expression tag.

·         Scriptlet tag— The scriptlet tag is the most important tag in the JSP specification because it enables the actual embedding of Java code within an HTML page. An application component provider can write entire processing routines within the scriptlet tags.

·         Custom tag— The final set of tags that the JavaServer Page specification defines is the embedding of custom tags. Because the JSP compiler cannot process these tags on its own, a special set of classes called the JSP tag library must be built by the application component provider to support the processing of the custom tags. You will be taking a quick look at the JSP tag library in the next subsection.

JSP Tag Library

The JSP specification does allow developers to extend the JSP functionality and add custom tags in the JSP page. To develop custom tags, you need to write a custom JSP tag library to support the custom tags because the JSP engine that parses the JSP will have no idea how to interpret and process the custom tags.

The primary advantage offered by building a JSP tag library is the encapsulation of complex processing code in a separate Java class. This encapsulation also enables the processing logic and, hence, the custom tags in the JSP tag library to be reusable across different JSPs in the application. The behavior of the custom tags (its processing logic) can be customized with the ability to pass attributes to the Java class performing the processing for the custom tags. This is an added benefit to the reusable feature of custom tags. Moreover, as a part of building a JSP tag library, the JSP specification defines a set of interfaces and classes that need to be implemented or used by an application component provider. This ensures that the JSP tag libraries that an application component provider builds are compliant with the J2EE specification.

Visual composing tools are available from different vendors to create JSPs as well as to build custom tag libraries and embed them in the JSPs. Because these tools conform to the JSP specification, an application component provider can build JSPs and JSP tag libraries using any of the J2EE-compliant tools and can deploy the JSPs and JSP custom tag libraries in any J2EE-compliant containers or application servers without encountering any nonconformance problems.

Java Database Connectivity (JDBC) API

The Java Database Connectivity (JDBC) API provides a set of common, vendor-neutral classes and interfaces to enable database access to different databases from Java applications. The JDBC API specification defines a standard set of interfaces that vendors of JDBC drivers need to implement to conform to the JDBC API. Application component providers can use the JDBC driver in their application components to access data from databases. The JDBC drivers fall in one of the following four categories:

·         Type 1 driver— The type 1 driver is the JDBC-ODBC bridge. The JDBC-ODBC bridge communicates with an ODBC driver using the Java Native Interface (JNI) and acts as a translator between the Java application/JDBC API and the ODBC driver. The ODBC driver is the one that actually interacts with the database to perform the database-specific operations.

·         Type 2 driver— The type 2 JDBC driver is actually a set of wrapper Java classes that use the JNI to interact with the underlying database-driver software. The type 2 driver leverages the existing vendor-provider database-driver software and hence is platform dependent.

·         Type 3 driver— The type 3 driver consists of a set of Java wrapper classes. The driver interacts with a server-side application installed on a middleware server, with which it establishes a connection over the network using a socket connection. The middleware server acts as a proxy for the JDBC driver and performs database interaction on its behalf.

·         Type 4 driver— The type 4 driver is a pure Java implementation of a JDBC driver. The entire functionality of interacting with the database (the database driver protocol) is implemented as a set of Java classes, thus making it more portable.

The JDBC API was one of the first APIs introduced in Java and was part of the Java 2 Standard Edition before its role in enterprise development was recognized and the JDBC API was included as a part of the J2EE specification. Database vendors often provide implementations of JDBC drivers for their databases that comply with the JDBC API specification. This enables application component providers that use the JDBC API in their application components to access any database as long as a JDBC driver is available for the database.