13 core technologies of J2EE

Java was first launched on browsers and client machines. At that time, many people questioned whether it was suitable for server-side development. Now, with the increase in third-party support for the Java2 Platform Enterprise Edition (J2EE), Java is widely accepted as one of the preferred platforms for developing enterprise-level server solutions.

 

The J2EE platform consists of a complete set of Services, application interfaces (APIs), and Protocols. It provides Function Support for developing Web-based multi-layer applications.

 

In this article, I will explain 13 core technologies supporting J2EE: JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, javaMail and JAF will also describe when and where to use these technologies. Of course, I would also like to introduce how these different technologies interact.

 

In addition, to make you better feel the real applications of J2EE, I will introduce these technologies in the WebLogic application server, a widely used product from BEA Systems. No matter whether you are new to WebLogic application server and J2EE, or project managers and system analysts who want to know what benefits J2EE can bring, I believe this article will be of great reference value.

 

Macro impression: distributed architecture and J2EE

 

In the past, layer-2 applications-usually called client/server applications-were the most talked about. Figure 1 depicts a typical L2 structure. 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, business logic implementation, display results with appropriate styles, pop-up preset user interfaces, and accept user input. The client/server structure is usually easier to upgrade or improve during the first deployment, and is often based on a proprietary protocol-usually a database protocol. It makes it very difficult to reuse business logic and interface logic. More importantly, in the Web era, L2 applications usually do not have good scalability, making it difficult to adapt to Internet requirements.

 

 

 

Figure 1. l2 application structure

 

Part of Sun's design for J2EE is to solve the defects of the L2 structure. Therefore, J2EE defines a set of standards to simplify the development of layer-N enterprise applications. It defines a set of standardized components and provides complete services for these components. J2EE also automatically handles many implementation details for applications, such as security and multithreading.

 

Using J2EE to develop N-layer applications includes dividing different layers in a L2 structure into multiple layers. An N-tier 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.

 

Dynamic generation and display: although the browser can display some dynamic content, to be compatible with different browsers, these dynamic generation tasks should be carried out on the Web server, using JSP, Servlets, or XML (Extensible Markup Language) and (Extensible style sheet language ).

Business logic: SessionEJBs is suitable for business logic implementation.

 

Data Access: EntityEJBs and JDBC are suitable for data access.

 

Background system integration: the integration of the same background system may require many different technologies. The best requirements depend on the characteristics of the background system.

 

You may be surprised: why are there so many layers? In fact, a multi-tier approach can make enterprise-level applications highly scalable, allowing each layer to focus on specific roles. For example, the Web server is responsible for providing pages and application servers to process application logic, while the database server provides database services.

 

Because J2EE is built on the Java 2 platform Standard Edition (J2SE), it has all the advantages and functions of J2SE. This includes the portability of "write once, available everywhere", the ability to access the database through JDBC, the ability to interact with the original enterprise resources, and a verified security model. Based on these, J2EE has added support for EJB (enterprise-level Java components), Java servlets, Java Server Pages (JSPs), and XML technologies.

 

Distributed architecture and WebLogic application server

 

J2EE provides a framework-a set of standard APIs-for developing distributed architecture applications. The actual implementation of this framework is left to third-party vendors. Some vendors only focus on specific components in the entire J2EE architecture. For example, Apache Tomcat provides support for JSP and servlets, BEA System provides a complete implementation of the entire J2EE specification through its WebLogic application server product.

 

The WebLogic Server has simplified the process of establishing and deploying distributed applications with better scalability. WebLogic and J2EE handle a large number of common programming tasks on your behalf, including providing transaction services, security fields, reliable messages, name and directory services, database access and connection pools, thread pools, load balancing, and fault tolerance Processing.

 

By providing these public services in a standard and easy-to-use way, products such as WebLogic servers have created application systems with better scalability and maintainability, this increases availability for a large number of users.

 

 

 

 

J2EE Technology

 

In the following section, we will describe various technologies that constitute J2EE and learn how WebLogic servers support them in a distributed application. The most common J2EE technologies are JDBC, JNDI, EJB, JSP, and servlets. We will take a closer look at these technologies.

 

Figure 2 shows the common role of J2EE in a distributed application.

 

 

 

Figure 2. Example of an N-layer application structure

 

JavaDatabase 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 built on Java, it also provides database access platform independence.

 

JDBC defines four different drivers, which are described as follows:

 

JDBC-ODBC Bridge Type 1

 

In the early stages of JDBC, The JDBC-ODBC bridge is obviously very useful, through the JDBC-ODBC bridge, developers can use JDBC to access ODBC data sources. However, you must install the ODBC driver on the client. In other words, you must install a certain version of Microsoft Windows. To use this type, you must sacrifice the independence of the JDBC platform. In addition, the ODBC driver must have the control permissions of the client.

 

Type 2: JDBC-native driver bridge

 

The JDBC local driver bridge provides a JDBC interface, which is built on the top layer of the local database driver without using ODBC. The JDBC driver converts database APIs from standard JDBC calls to local calls. To use this type, you must sacrifice the platform independence of JDBC and install some local code on the client.

 

Type 3: JDBC-network bridge

 

The JDBC Network Bridge driver no longer needs the client database driver. It uses an intermediate server on the network to access the database. This application makes it possible to implement the following technologies, including Server Load balancer, connection buffer pool, and data cache. Because the 3rd types usually require less download time and platform independence, and do not require installation and control on the client, it is suitable for applications on the Internet.

 

Type 4: PureJava driver

 

The 4th types Use a pure Java Database driver to execute direct access to the database. This type actually implements a layer-2 Structure on the client. To be applied in the N-layer structure, a better way is to write an EJB that contains the access code and provides a service that is database independent to the client.

 

The WebLogic Server provides JDBC drivers for some common databases, including Oracle, Sybase, Microsoft SQLServer and Informix. It also includes a JDBC driver for Cloudscape, which is a pure Java DBMS and the WebLogic Server carries the evaluation version of the database.

Let's look at an instance.

 

JDBC instance

 

In this example, we assume that you have created a PhoneBook database in Cloudscape and contain a table named CONTACT_TABLE, which has two fields: NAME and PHONE. First, load the Cloudscape JDBC driver and request the driver manager to obtain a connection to the PhoneBook Cloudscape database. Through this connection, we can construct a Statement object and use it to execute a simple SQL query. Finally, we use a loop to traverse all the data in the result set and use the standard output to output the content of the NAME and PHONE fields.

 

Importjava. SQL .*;

 

Public classJDBCExample

{

Publicstatic void main (String args [])

{

Try

{

Class. forName ("COM. cloudscape. core. JDBCDriver ");

Connectionconn = DriverManager. getConnection ("jdbc: cloudscape: PhoneBook ");

Statementstmt = conn. createStatement ();

Stringsql = "SELECT name, phone FROM CONTACT_TABLE order by name ";

ResultSetresultSet = stmt.exe cuteQuery (SQL );

 

Stringname;

Stringphone;

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. Next, let's take a look at how JDBC is used in enterprise applications.

 

Application of JDBC in enterprise applications

 

The above instances are actually very basic and may be insignificant. It assumes a 2-layer structure. In a multi-tier enterprise application, it is more likely that the client communicates with an EJB, And the EJB establishes a database connection. To achieve and improve scalability and system performance, the WebLogic Server provides support for connection buffer pool connection pools.

 

Connectionpool reduces the consumption of establishing and releasing database connections. After the system starts, you can create such a buffer pool. Later, if you have another request to the database, the WebLogic Server can easily retrieve data from the buffer pool. The data buffer pool can be defined in the WebLogic. properties file of the weblogic Server. (For more information, see the example in the weblogic. properties file)

 

Another common database feature of enterprise applications is transaction processing. Transactions are a set of declarative statements that must be processed as the same statement to ensure data integrity. By default, JDBC uses the auto-commit transaction mode. This can be achieved by using the setAutoCommit () method of the Connection class.

 

Now we have some knowledge about JDBC, and we should switch to JNDI below.

Java Naming and Directory Interface (JNDI)

 

The jndi api is used to run the name and directory services. It provides a consistent model to access and operate enterprise-level resources such as DNS and LDAP, local file systems, and the latter's objects on the application server.

 

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

 

Context ctx = new InitialContext ();

 

The app can use this initialized context to locate the resources or objects it needs through this directory tree. For example, suppose you expand an EJB on the Weblogic Server and bind the home interface to the myApp name. myEJB, a client of this EJB can locate the home interface through the following statement after obtaining an initialization context:

 

MyEJBHomehome = ctx. lookup ("myApp. myEJB ");

 

In this example, once you have a reference to the requested object, the EJB home interface can call the method on it. We will introduce you more in the "iseisejava Beans" section below.

 

The above discussion about JNDI is just a tip of the iceberg. To further search for objects in the context, JNDI also provides some methods to perform the following operations:

 

Insert or bind an object to the context. This is effective when you expand an EJB.

 

Removes objects from context.

 

Lists all objects in the context.

 

Creates or deletes sub-level context.

 

Next, we will start to focus on EJB.

 

Enterprise Java Beans (EJB)

 

One of the reasons why J2EE technology has won widespread attention is EJB. They provide a framework for developing and implementing distributed business logic, significantly simplifying the development of scalable and highly complex enterprise-level applications. The EJB specification defines when and how the EJB component interacts with their containers. Containers are responsible for providing public services, such as directory services, transaction management, security, resource buffer pools, and fault tolerance.

 

The EJB specification defines three basic bean types:

 

Statelesssession beans: provides a single service that does not maintain any status. It cannot continue to exist when a Server failure occurs and has a short life cycle. For example, a stateless session bean may be used for temperature conversion calculation.

 

Statefulsession bean: T provides session interaction with the client, and stores the status to represent a customer. A typical example is shopping cart. Stateful session bean cannot survive when the server fails, and its life is relatively short. Each instance is used only for a single thread.

 

Entitybeans: provides consistent data representation-typically stored in the database-can continue to exist after a Server failure occurs. Multiple users can use EJB to represent the same data. A typical example of entity EJB is the customer's account information.

Despite the above differences, all ejbs have many similarities. They all process the home interface. It defines how a client creates and destroys ejbs. You can call the remote interface that defines the client method in bean, and the bean class executes the main business logic.

 

The description of EJB development is beyond the scope of this article. However, if an EJB has been developed or purchased from a third party, it must be released on the application server. WebLogicServer 5.1 comes with an EJBDeployer Tool to help with EJB Publishing. When using the EJB Deployer Tool, you need to define the JNDI name used by the client to locate the EJB. Deployer Tool generates wrapper Classes to process and communicate with containers, and binds the requested Java classes 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. Then, the client can use this interface to call a create () method to obtain the handle of a bean instance running on the server. Finally, the client can use this handle to call the method in the bean.

 

After learning about EJB, let's look at JSP.
Assumerver Pages (JSPs)

 

Many of us may already be familiar with Microsoft's Active Server Pages (ASP) technology. JSP corresponds to ASP, but it is more platform-specific. They are designed to help Web content developers create dynamic Web pages and only require a relatively small amount of code. JSP can be used even if Web designers do not know how to program, because JSP applications are very convenient. A JSP page consists of HTML code and Java code embedded in it. The server processes the Java code after the page is requested by the client, and then returns the generated HTML page to the browser of the client.

 

Let's take a look at a simple JSP instance. It only displays the current date and time of the server. Although the syntax is beyond the scope of this article, we can intuitively see that Java code is placed in the middle of the symbol, while Java expressions are placed between symbols.

 

<H1> Date JSP sample </H1>

 

<H2>

<% Response. setHeader ("Refresh", 5); %>

Thecurrent date is <% = new Date () %>.

</H2>

 

You may have heard of JHTML sometimes. This is an old standard of JSP. The WebLogic Server supports both JSP and JHTML. Note that by default, JSP is not in a valid state on the WebLogic Server. To make it effective, you can edit the weblogic. properties file. If the Web server is not in a valid state, make it valid first. The situation of Servlet is the same as that of JSP.

 

The following is: assumervlets

 

Assumervlets

 

Most of the functions provided by Servlet are similar to those provided by JSP, but the implementation methods are different. JSP usually embeds a small amount of Java code in most HTML code, while servlets is all written in Java and generates HTML.

 

Servlet is a small Java program that extends the functions of Web servers. As a server-side application, it is executed when requested, which is similar to the CGIPerl script. A major difference between Servlets and CGI scripts is that each CGI requires a new process to start at the beginning -- while servlets runs in a separate thread in the servlet engine. Therefore, servlets provides good scalability improvements.

 

When developing servlets, you often need to extend the javax. servlet. http. HttpServlet class and override some of its methods, including:

 

Service (): implements the command-definition method as a dispatcher.

 

DoGet (): process http get requests from the client.

 

DoPost (): performs the http post operation.

 

Other methods include processing different types of HTTP requests. For more information, see the HttpServlet API documentation.

 

The above describes various methods of the standard J2EEServlet API. The WebLogic Server provides a complete way to implement this API. Once you develop a servlet, you can register it in weblogic. properties and configure it on the WebLogic Server.

 

Through assumervlets, we have reached the end of main J2EE technologies. But what J2EE provides does not end with this. The following section briefly describes some existing technologies, including RMI, Java IDL and CORBA, JTA, and XML.

 

RemoteMethod Invocation (RMI)

 

As its name indicates, the RMI protocol calls some methods on a remote object. It uses a continuous sequence to transmit data on the client and server. RMI is a lower-layer protocol used by EJB.

 

JavaIDL/CORBA

 

With the support of Java IDL, developers can integrate Java and CORBA. They can create Java objects and expand them in corba orb, or they can also create Java classes and serve as the customers of the CORBA objects expanded with other ORB. The latter method provides another way through which Java can be used to integrate your new application with the legacy system.

 

JavaTransaction Architecture (JTA)/Java Transaction Service (JTS)

 

JTA defines a standard API, which allows the application system to access various transaction monitoring data.

 

JTS is the basic implementation of the transaction monitoring function of corba ots. JTS specifies the implementation method of the Transaction Manager. The transaction manager is a Java image that supports the JavaTransaction API (JTA) specification at the high-level level and implements omg ots specification at a lower level. JTS Transaction Manager provides transaction services for application servers, resource managers, independent applications, and communication resource managers.

 

JavaMail andJavaBeans Activation Framework

 

JavaMail is an API used to access the mail server. It provides a set of abstract classes for the mail server. Not only supports SMTP servers, but also supports IMAP servers.

 

JavaMail uses JavaBeans Activation Framework (JAF) to process MIME-encoded email attachments. MIME byte streams can be converted to Java objects or to Java objects. Therefore, most applications do not need to directly use JAF.

 

JavaMessaging Service (JMS)

 

JMS is an application interface (API) used to communicate with message-oriented middleware ). It supports point-to-point domains, publish/subscribe domains, and supports the following types: Approved message transmission and transactional message transmission, supports consistent messages and persistent subscribers. JMS also provides another way to integrate your application with the legacy backend system.

 

ExtensibleMarkup Language (XML)

 

XML is a language that can be used to define other Markup languages. It is used to share data in different business processes. The development of XML and Java are mutually independent. However, the same objective of XML and Java is platform independence. By combining Java and XML, you can get a perfect platform-independent solution. At present, many different companies are working hard to combine Java and XML. For more information, visit Sun's Java-XML page or IBM developerWorks's XML Zone.

 

Summary

 

In this article, we introduce the distributed application structure built on J2EE, and describe various J2EE support for WebLogic Server. However, what we reveal is only the tip of the iceberg. It is unfair to use a thousand-character article to demonstrate the potential impact of J2EE on your enterprise-level applications.

 

We have already paid attention to the various technologies most likely to encounter when you start to work with J2EE: JDBC, JNDI, EJB, JSP, and servlet. We also provide you with some background knowledge about J2EE technology that is not yet common. Whether you are a developer, business application analyst, or project manager, you should provide us with the J2EE and WebLogic servers, we have a better understanding of the significance of our enterprises and our enterprise-level applications.