13 Core technologies of Java EE

I. Introduction of the Content

Java EE's 13 core technologies: JDBC, JNDI, EJB, RMI, JSP, Java Servlet, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF.

Java was initially in the browser and client machines, when many questioned whether it was suitable for server-side development. Now with the increase in support for third-party Java EE, Java is widely accepted as one of the preferred platforms for developing enterprise-Class Server-side solutions.

The Java EE platform is comprised of a suite of services, application interfaces (APIs), and protocols that provide functional support for developing web-based, multi-tiered applications. In this article I will explain the 13 core technologies that underpin Java EE: JDBC, JNDI, EJB, RMI, JSP, Java Servlet, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF, and will also describe when, Where these technologies need to be used. And of course I'm going to explain how these different technologies interact.

In addition, to give you a better sense of the real-world application of Java EE, I will present these technologies in the WebLogic Application server environment. Whether for the novice of the WebLogic application server and Java EE, or for those project managers and system analysts who want to know what the benefits of Java EE are, this article is sure to be of reference value.

Second, macro impression: Distributed architecture and Java EE

The past two layers of applications-often referred to as C/s applications-are the most talked about. In many cases, the only service provided by the server is the database service. In this solution, the client program is responsible for data access, implementing business logic, displaying the results in the appropriate style, ejecting the preset user interface, accepting user input, and so on. The C/s structure is usually easier to deploy in the first place, but difficult to upgrade or improve, and is often based on some proprietary protocol, usually some kind of database protocol. It makes it very difficult to reuse business logic and interface logic. More importantly, in the Web age, the two-layered application usually does not show a good scalability, so it is difficult to adapt to the requirements of the Internet.

Part of the reason Sun designed Java EE was to solve the flaws in the two-tier structure, Java EE defined a set of standards to simplify the development of n-tier enterprise applications. It defines a set of standardized components and provides a complete service for those components. Java EE also automatically handles many implementation details for the application, such as security, multithreading, and so on. Developing n-tier applications with Java EE involves slicing different layers of a two-tier structure into many tiers. An n-layered application A can provide a separate layer for each of the following services:

Display: In a typical Web application, the browser running on the client machine is responsible for implementing the user interface.

Dynamically generated display: Although the browser can do some dynamic content display, in order to be compatible with different browsers, these dynamic build work should be placed on the Web server side, using JSP, servlet or XML and XSLT.

Business logic: The business logic is appropriate to be implemented with session EJBS (described later).

Data access: Data access is appropriate for use with entity EJBs (described later) and JDBC.

Back-Office System integration: integration with back-office systems may require many different technologies, as to what is best and depends on the characteristics of the backend system.

You may start to wonder: Why are there so many layers? In fact, multi-tiered approaches can make enterprise applications highly scalable, allowing each layer to focus on specific roles. If the Web server is responsible for providing the page, the application server handles the application logic, and the database server provides the database service.

Because Java EE is built on the basis of J2SE, it has all the advantages and functions of J2SE. Includes "Write once, everywhere" portability, access to databases through JDBC, CORBA technology to interact with legacy enterprise resources, and a validated security model. Based on these, Java EE also adds support for EJB, Java Servlet, JSP, and XML technologies.

Third, distributed architecture and WebLogic Application Server

Java EE provides a framework (a set of standard APIs) for the development of distributed architecture applications, and the actual implementation of this framework is left to third-party vendors. While some vendors focus on specific components throughout the Java EE architecture, such as Apache Tomcat provides support for JSPs and Servlets, BEA Systems provides a more complete implementation of the entire Java EE specification through its WebLogic application server offerings.

The WebLogic server has simplified the process of building and deploying well-scaled distributed applications. WebLogic and Java EE generation you handle a number of routine programming tasks, including providing transactional services, security domains, reliable messaging, name and directory services, database access and connection pooling, thread pooling, load balancing, and fault tolerance processing. By providing these public services in a standard, easy-to-use manner, products like the WebLogic server create applications with better scalability and maintainability that provide increased availability for a large number of users.

Iv. Java EE Technology

In the next section, we will describe the various technologies that make up Java EE and understand how WebLogic servers support them in a distributed application. The most commonly used Java EE technology should be JDBC, JNDI, EJB, JSP, and servlet, which we will examine more carefully.

"1. Java Database Connectivity (JDBC) "

The JDBC API accesses a variety of databases in a unified manner. Like ODBC, JDBC hides different features of different databases for developers. In addition, because JDBC is based on Java, it also provides platform independence for database access. JDBC defines 4 different drivers, which are described below:

Type 1:JDBC-ODBC Bridge

In the early stages of JDBC, the Jdbc-odbc bridge was obviously very practical, and with the Jdbc-odbc Bridge developers could access the ODBC data source using JDBC. The disadvantage is that you need to install an ODBC driver on the client, in other words, you must install a version of Windows. Use this type to sacrifice the platform independence of JDBC. In addition, the ODBC driver must have client control permissions.

Type 2:jdbc-native driver Bridge

The JDBC Local driver bridge provides a JDBC interface that is built at the top level of the local database driver and does not require ODBC. The JDBC driver translates the API for the database from a standard JDBC call to a local call, using this type to sacrifice the platform independence of JDBC, and also require client database drivers to be installed on the client.

Type 3:jdbc-network Bridge

The JDBC Network Bridge driver does not require a client database driver. It uses a middleware server on the network to access the database. This application makes it possible to implement technologies such as load balancing, connection buffer pooling, and data caching. Because the 3rd type often requires relatively little download time, platform independence, and does not require the client to install the database driver and gain control, it is suitable for applications on the Internet.

Type 4:pure Java Driver

Perform direct access to the database by using a pure Java database driver. This type actually implements a 2-tier structure on the client. To apply in n-tier structures, a better approach is to write an EJB that includes access code and provides a service that has database independence for the client.

The WebLogic server provides JDBC drivers for some of the usual databases, including Oracle, Sybase, Microsoft SQL server, and Informix. It also comes with a JDBC driver for Cloudscape, which is a pure Java Dbms,weblogic server with an evaluation version of that database. Let's look at an example.

JDBC Instance

In this example, it is assumed that a phonebook database has been established in Cloudscape and contains a table named Contact_table with 2 fields: Name and phone. First load the Cloudscape JDBC driver and request driver Manager to get a connection to the phonebook Cloudscape database. With this connection, you can construct a statement object and use it to execute a simple SQL query. Finally, the loop is used to iterate through all the data in the result set and output the contents of the name and phone fields with standard output.

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 honebook");
Statement stmt = Conn.createstatement ();
String sql = "SELECT name, phone from contact_table ORDER by name";
ResultSet ResultSet = stmt.executequery (sql);
String name, 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 ();
}
}
}

Then let's take a look at how JDBC is used in enterprise applications.

The application of JDBC in enterprise-level application

The above example is actually very basic, may be a little trivial, it assumes a 2-layer structure. In a multi-tier enterprise application, it is possible to communicate between the client and an EJB, which will establish a database connection. To achieve and improve scalability and system performance, the WebLogic server provides support for connection buffer pool connection pools.

Connection pool reduces the cost of establishing and releasing database connections. Such a buffer pool can be established after the system is booted, and after that, the WebLogic server can easily extract data from the buffer pool as soon as there is a request for the database. The data buffer pool can be defined in the Weblogic.properties file of the WebLogic server (refer to the example in the Weblogic.properties file for more detailed reference information in the WebLogic server's documentation).

Another common database feature in an enterprise application is transaction processing. A transaction is a set of claims statement that must be handled as the same statement to ensure data integrity, and JDBC uses the Auto-commit transaction mode by default. This can be achieved by using the Setautocommit () method of the connection class.

"2. Java Naming and Directory Interface (JNDI) "

The JNDI API is used to perform name and directory services. It provides a consistent model for accessing and manipulating enterprise-level resources, such as DNS and LDAP, local file systems, which are objects in the application server.

In Jndi, each node in the directory structure is called a context. Each jndi name is relative to the context. There is no concept of absolute name here. For an application, it can get its first context by using the InitialContext class:

Context CTX = new InitialContext ();

The application can use this initialized context to locate the resource or object it needs through this directory tree. If you expand an EJB in the WebLogic server and bind the home interface to the name MYAPP.MYEJB, a client of that EJB will be able to locate the home interface with the following statement after obtaining an initialization context:

Myejbhome home = ctx.lookup ("MYAPP.MYEJB");

In this case, once you have a reference to the requested object, the EJB's home interface can invoke the method on it. We'll cover more in the EJB section below. The above discussion of Jndi is just one corner of the iceberg. If you want to find objects further in the context, Jndi also provides some ways to do the following:

Inserting or binding an object into the context is effective when you expand an EJB.

Removes an object from the context.

Lists all objects in the context.

Create or delete a sub-level context.

"3. Enterprise Java Beans (EJB) "

EJB is one of the reasons why Java EE technology has gained widespread attention. They provide a framework for developing and implementing distributed business logic, which significantly simplifies the development of scalable and highly complex enterprise-class applications. The EJB specification defines when EJB components interact with their containers. Containers are responsible for providing common services, such as directory services, transaction management, security, resource pooling, and fault tolerance.

The EJB specification defines the basic bean type in 3, where the Message-driven bean is not discussed first:

Stateless session Beans: Provides a single service that does not maintain any state and cannot continue to exist in the event of a server failure, with relatively short lifetimes. As it may be used to perform a temperature conversion calculation.

Stateful Session Bean: Provides sessions with the client to store the state and thereby represent a customer. A typical example is a shopping cart. However, in the case of server failure can not continue to survive, a relatively short life span. Each instance is used only for a single thread.

Entity Beans: Provides a representation of consistent data that is typically stored in a database and can continue to exist after a server failure occurs. Multiple users can use EJBS to represent the same data, and a typical example of an Entity EJB is the customer's account information.

Despite the differences above, all ejbs have a lot in common. They all deal with home interface. It defines how a client is created with the extinct EJB. The remote interface that defines the client method can be invoked in the bean, and the Bean class executes the primary business logic.

Describing the development of EJBS is beyond the scope of this article. However, if an EJB has been developed or purchased from a third party, it must be published in the application server. WebLogic Server 5.1 has an EJB Deployer tool to assist with the publication of the EJB. When you use the EJB Deployer tool, you define the Jndi name used by the client to locate the EJB. The Deployer tool will generate the wrapper class to handle the communication with the container and bind the requested Java class together in a jar file.

Once the EJB is published, the client can use its Jndi name to locate the EJB. First it must get a reference to the home interface. The client can then use the interface to invoke a Create () method to get a handle to a bean instance running on the server, and the client can use the handle to invoke the method in the bean.

"4. JavaServer Pages (JSPs) "

Many of us may already be familiar with Microsoft's ASP technology. JSP and ASP correspond, but more platform-independent. They are designed to help Web content developers create dynamic Web pages that require relatively little code. Even if web designers don't know how to program, they can use JSP because JSP applications are convenient. The JSP page consists of the HTML code and the Java code embedded therein. The server processes the Java code after the page is requested by the client, and then returns the resulting HTML page to the client's browser.

You may have heard of jhtml, which is a previous older standard for JSPs. The WebLogic server can support both. Note that, by default, the JSP is not in a valid state on the WebLogic server. To make it work, you can edit the Weblogic.properties file. If the Web server is not in a valid state, make it valid first. The servlet situation is the same as the JSP.

"5. Java Servlet "

The servlet provides most of the functionality similar to JSPs, but is implemented differently. JSPs are usually embedded in a small amount of Java code in most HTML code, and the servlet is all written in Java and generates HTML.

A servlet is a small Java program that extends the functionality of a Web server. As a server-side application, it starts executing when requested and is similar to CGI perl scripts. A big difference between servlets and CGI scripts is that each CGI requires a new process to start, and the servlet runs in a separate thread in the servlet engine. As a result, it provides a good improvement in scalability.

When developing a servlet, it is often necessary to extend the Javax.servlet.http.HttpServlet class and override some of its methods, including:

Service (): Implement command as Dispatcher-Define method

Doget (): Handles HTTP GET requests from the client.

DoPost (): HTTP POST operation

Other methods include handling different types of HTTP requests, which can be referenced in the HttpServlet API documentation.

The above description is a variety of methods for the standard Java EE Servlet API. The WebLogic server provides a complete implementation path for the API. Once you have developed a servlet, you can register it in the Weblogic.properties and configure it in the WebLogic server.

"6. Remote Method Invocation (RMI) "

Some methods are called on the remote object to pass data on the client and server side in sequential sequence mode. RMI is a lower-level protocol that is used by EJBS.

"7. Java Idl/corba "

With the support of Java IDL, developers can integrate Java with CORBA. They can create Java objects that can be expanded in the CORBA orb, or can create Java classes and serve as clients for CORBA objects that are expanded with other orbs. The latter approach provides another way through which Java can be used to integrate your new application with the legacy system.

"8. Java Transaction Architecture (JTA)/java Transaction Service (JTS) "

JTA defines a standard API that allows the application system to access a variety of transaction monitoring.

JTS is the basic implementation of CORBA OTS transaction monitoring, and JTS specifies the implementation of the transaction manager. The transaction manager is a Java image that supports the Java Transaction API (JTA) specification at the top level and implements the OMG OTS specification in the lower layer. The JTS transaction Manager provides transactional services for application servers, resource managers, stand-alone applications, and communication Explorer.

"9. JavaMail and JavaBeans Activation Framework "

JavaMail is an API for accessing mail servers, which provides an abstract class of mail servers. Supports not only SMTP servers, but also IMAP servers. JavaMail uses the JavaBeans Activation Framework (JAF) to process mime--encoded message attachments. MIME byte streams can be converted to Java objects or converted from Java objects. As a result, most applications do not need to use JAF directly.

"10. Java Messaging Service (JMS) "

JMS is an application interface (API) for communicating with each other for message-oriented middleware. It supports both point-to-point domains, domains that support publish/subscribe (Publish/subscribe) types, and provides support for the following types of messages: Approved messaging, transactional message delivery, consistent messaging, and persistent subscriber support. JMS also provides another way to integrate your application with the legacy backend system.

"11. Extensible Markup Language (XML) "

XML is a language that can be used to define other markup languages, and it is used to share data in different business processes. The development of XML and Java are independent of each other, but it and Java have the same goal, that is, platform independence. By combining Java and XML, you get a perfect platform-independent solution. There are many different companies working on the combination of Java and XML. To learn more about this, visit the Sun's Java-xml page or the IBM developerworks XML Zone.

Five summary

This paper introduces a distributed application architecture based on Java EE, and describes the various support of WebLogic server to Java EE. However, what we are revealing is only one corner of the iceberg, and it is not fair to show the potential impact of Java EE on your enterprise applications in a thousands of-word article.

We've focused on the kinds of technologies you're most likely to encounter when you start Java EE: JDBC, JNDI, EJB, JSP, and servlet. We also provide you with some background knowledge of Java EE technologies that are not yet common. Whether you're a developer, business application analyst, or project manager, there's a better understanding of what Java EE and WebLogic servers can deliver to our enterprise-class applications.

13 Core technologies of Java EE