13 Kinds of core technology of Java EE

j2ee| detailed
Java was originally staged in browsers and client machines. At the 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 version, Java is widely accepted as one of the preferred platforms for developing enterprise server-side solutions. The Java EE platform consists of a suite of service (services), application interfaces (APIs), and protocols that provide functional support for the development of web-based multi-tier applications. This article will explain the 13 core technologies underpinning Java EE: JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF, and describe when and where to Use these technologies. Of course, it's also about how these different technologies interact. In addition, in order to give you a better sense of the real application of Java EE, we will introduce these technologies in a WebLogic application server, a widely used product environment from BEA Systems Company. Whether for WebLogic application server and the novice of Java EE, or those who want to know what the benefits of Java EE, Project managers and system analysts, I believe this article must be very valuable reference. Macro Impressions: Distributed architecture and Java EE past, two-layered applications-often called client/server applications-are the most talked about. In many cases, the only service the server provides is the database service. In this solution, the client program is responsible for data access, implementing business logic, displaying the results in a suitable style, ejecting the preset user interface, accepting user input, and so on. Client/server structures are usually easier to deploy at first time, but difficult to upgrade or improve, and are often based on a 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 applications usually do not show good scalability, so it is difficult to adapt to the requirements of the Internet. Part of the reason Sun design Java EE is to solve the two-layered structure of the defects. As a result, Java EE defines 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 these components. Java EE also automatically handles many implementation details for the application, such as security, multithreading, and so on. Using Java EE to develop n-tier applications involves slicing different layers of the two-layered 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. Dynamic build display: Although browsers can complete some dynamic content display, in order to be compatible with different browsers, these dynamicThe build work should be done on the Web server side, using JSP, Servlets, or XML (Extensible Markup Language) and (Extensible Stylesheet Language). Business logic: Business logic is appropriate to use session EJBs (described later) to implement. Data access: Data access is suitable for use with entity EJBs (described later) and JDBC. Background system integration: the integration with the backend system may require many different technologies, as to what the best needs are based on the characteristics of the backend system.

You may begin to wonder: Why are there so many layers? In fact, multi-tier approaches enable enterprise-class applications to be highly scalable, allowing each layer to focus on specific roles. For example, let the Web server be responsible for providing pages, the application server processes the application logic, and the database server provides the database service. Thanks to Java-ee based on the JAVA2 Platform Standard Edition (J2SE), it has all the advantages and functions of J2SE. Includes "Write once, everywhere available" portability, access to databases through JDBC, CORBA technology that interacts with existing enterprise resources, and a validated security model. On this basis, Java EE has added support for EJB (Enterprise-class Java components), Java servlets, Java Server Pages (JSPs), and XML technology. Distributed architecture and WebLogic Application Server Java provides a framework-a set of standard api--for the development of distributed architecture applications, and the actual implementation of this framework is left to third-party vendors. Some vendors just focus on the specific components of the entire Java EE architecture, such as Apache Tomcat provides support for JSP and Servlets, while BEA Systems provides a more complete implementation of the Java EE specification through its WebLogic Application server product. WebLogic servers have greatly simplified the process of building and deploying scalable, distributed applications. WebLogic and Java EE have handled 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-tolerant processing. By providing these public services in a standard, easy-to-use way, products such as WebLogic servers create more scalable and maintainable applications that provide increased availability for a large number of users. 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 Servlets, which we will examine more carefully. The Java Database Connectivity (JDBC) JDBC API accesses a wide 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 days of JDBC, jdbc-odbc bridges are obviously very practical, through JDBC-ODBC Bridge, developers can use JDBC to access ODBC data sources. The disadvantage is that he needs to install an ODBC driver on the client, in other words, a version of Microsoft Windows must be installed. With this type you need to sacrifice JDBC platform independence. Additionally, the ODBC driver requires control of the client.

Type 2:jdbc-native driver Bridgejdbc The local driver bridge provides a JDBC interface that is built at the top level of the local database driver without the need for ODBC. The JDBC driver converts the API for the database from a standard JDBC call to a local call. Using this type requires sacrificing the platform independence of JDBC and also requiring some local code to be installed on the client. Type 3:jdbc-network BRIDGEJDBC Network Bridge driver no longer requires a client database driver. It uses an intermediary server on the network to access the database. This application makes possible the implementation of the following technologies, including load balancing, connection buffer pooling, and data caching. Because the 3rd type often requires only relatively little download time, platform independence, and no need to install and gain control on the client, it is ideal for applications on the Internet. Type 4:pure Java Driver The 4th type performs direct access to the database by using a pure Java database driver. This type actually implements a 2-tier structure on the client. A better approach to applying in the N-tier structure is to write an EJB that contains 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, a pure Java dbms,weblogic server with an evaluation version of the database. Let's look at an example below. JDBC instance in this example we assume that you have established a phonebook database in Cloudscape and that it 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, we can construct a Statement object and use it to execute a simple SQL query. Finally, loops are used to traverse all the data of the result set and output the contents of the name and phone fields with standard output.

Import java.sql.*;p ublic 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 ();p hone = resultset.getstring (2). Trim (); SYSTEM.OUT.PRINTLN (name + "," + Phone);} catch (Exception e) {//Handle Exception heree.printstacktrace ();}}}

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

Application of JDBC in enterprise application The above examples are actually very basic, may be a little trivial. It assumes a 2-layer structure. In a multi-tiered enterprise application, it is more likely to communicate with an EJB on the client and the EJB will establish a database connection. To achieve and improve scalability and system performance, the WebLogic server provides support for the connection buffer pool connection pools. Connection pool reduces the cost of establishing and releasing database connections. This buffer pool can be built after the system is started, and then there is a request to the database, and the WebLogic server simply pulls the data out of the buffer pool. The data buffer pool can be defined in the Weblogic.properties file of the WebLogic server. Another common database feature that is applied at the enterprise level is transaction processing. A transaction is a set of statement that must be treated as one statement to ensure data integrity. JDBC uses the Auto-commit transaction mode by default. This can be done by using the Setautocommit () method of the connection class. Now that we have some knowledge of JDBC, it's time to turn to Java naming and directory Interface (JNDI), Jndiapi is used to perform name and directory services. It provides a consistent model for accessing and manipulating enterprise-class resources such as DNS and LDAP, the local file system, and the object 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 locate the resource or object it needs through the initialization context by having the directory tree. For example, if you expand an EJB in a WebLogic server and bind the home interface to the name MYAPP.MYEJB, a client of that EJB can locate the home interface with the following statement after obtaining an initialization context:

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

In this example, once you have a reference to the requested object, the EJB's home interface can invoke the method on it. The above discussion of Jndi is just one corner of the iceberg. If you want to further look up objects in the context, Jndi also provides some ways to insert or bind an object to a context. This is very effective when you expand an EJB. Removes an object from the context. Lists all objects in the context. Create or delete a child level context. Next, we're going to start focusing on EJBS.

Third, Enterprise Java Beans (EJB) technology is one of the reasons to win a wide attention is the EJB. They provide a framework for developing and implementing distributed business logic, thereby significantly simplifying the development of scalable and highly complex enterprise-class applications. The EJB specification defines when and how EJB components interact with their containers. The container is responsible for providing common services such as directory services, transaction management, security, resource buffer pooling, and fault tolerance. The EJB specification defines the basic bean type in 3: Stateless session Beans: Provides a single service, does not maintain any state, cannot continue when a server failure occurs, and has a relatively short life span. For example, a stateless session bean might be used to perform temperature conversion calculations. The Stateful session bean:t provides conversation interaction with the client and can store the state to represent a customer. A typical example is a shopping cart. The Stateful session bean cannot survive the server failure, and the life gas is relatively short. Each instance is used for only one single thread. Entity Beans: Provides representations of consistent data-usually in a database-that can continue to exist after a server failure occurs. Multiple users can use EJBS to represent the same data. A typical example of entity EJB is customer account information. Despite these differences, all ejbs have a lot in common. They all handle 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 performs the primary 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 published in the application server. WebLogic Server 5.1 has an EJB deployer tool to assist in handling the release of EJBS. When you use EJB deployer tool, you define the Jndi name used by the client to locate the EJB. Deployer tool generates wrapper classes to handle communication with the container and to bind 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. 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, finally, the client can use the handle to call the party in the beanMethod. After learning about EJBS, let's look at the JSP again. Iv. JavaServer Pages (JSPs) Many of us may already be familiar with Microsoft's active Server Pages (ASP) technology. JSP and ASP are corresponding, but more platform-polarized. They are designed to help Web content developers create dynamic Web pages, and require a relatively small amount of code. Even if web designers don't know how to program, they can use JSP, because JSP applications are convenient. JSP pages are made up of HTML code and embedded Java code. 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. Now let's look at a simple example of a JSP. It shows only the current date and time of the server. Although the specific explanation of the syntax is beyond the scope of this article, we can see intuitively that Java code is placed in the middle of the symbol, while the Java expression is placed between the symbols.

The date JSP samplethe the current date is.

You may have heard of jhtml sometimes. This is an older standard that JSP used to have. The WebLogic server can support both JSP and jhtml. Note that, by default, the JSP is not in a valid state on the WebLogic server. To make this work, you can edit the Weblogic.properties file. If the Web server is not yet in a valid state, make it valid first. The servlet situation is the same as the JSP. The Java Servletsservlet provides most of the functionality that is similar to JSP, but is implemented in a different way. JSP is typically a small amount of Java code embedded in most HTML code, while Servlets is written in Java and generates HTML. A servlet is a small Java program that expands the functionality of a Web server. As a server-side application, it is similar to a CGI Perl script to start executing when requested. A big difference between servlets and CGI scripts is that each CGI requires a new process to start at the beginning--and Servlets is running on a separate thread in the servlet engine. As a result, Servlets provides a good improvement in scalability. When developing servlets, you often need to extend the Javax.servlet.http.HttpServlet class and override some of its methods, including:

Service (): As dispatcher to implement the command-definition Method doget (): Processing the client's HTTP GET request. DoPost (): HTTP POST operation

Other methods include handling different types of HTTP requests--you can refer to the HttpServlet API documentation. The above description is a variety of methods for the standard Java Servlet API. The WebLogic server provides a complete way to implement the API. Once you have developed a servlet, you can register it in weblogic.properties and then configure it in the WebLogic server. Through the Java Servlets, we have reached the end of the main technology of EE. But this is not the end of what the Java EE offers. In the following paragraphs we will briefly look at some of the existing technologies, including RMI, Java IDL and CORBA, JTA, and XML. Vi. Remote Method Invocation (RMI) as its name indicates, the RMI protocol calls some methods on a remote object. It uses sequential sequential methods to pass data on both the client and server side. RMI is a lower-level protocol that is used by EJBS. Java Idl/corba with the support of Java IDL, developers can integrate Java with CORBA. They can create Java objects and enable them to expand in a CORBA orb, or they can create Java classes and serve as customers for CORBA objects that are expanded with other orb. The latter approach provides another way through which Java can be used to integrate your new application with the legacy system.

The Java Transaction Architecture (JTA)/java Transaction Service (JTS) JTA defines a standard API from which application systems can access various transaction monitoring. JTS is the basic implementation of CORBA OTS transaction monitoring. JTS provides a way to implement the transaction manager. The transaction manager is the Java Transaction API (JTA) specification at the top level, and the OMG OTS specification is implemented at the lower levels of the Java image. The JTS transaction Manager provides transactional services for application servers, resource managers, stand-alone applications, and communication Explorer. The JavaMail and JavaBeans activation Frameworkjavamail 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. A MIME byte stream can be converted to a Java object or converted from a Java object. As a result, most applications do not need to use JAF directly. X. Java messaging Service (JMS) JMS is an application interface (API) for communicating with message-oriented middleware. It supports point-to-point domains, has domains that support the Publish/subscribe (Publish/subscribe) type, and provides support for the following types: 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. Xi. Extensible Markup 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 independent of each other, but it is the same goal with Java is platform independence. By combining Java and XML, you can get a perfect platform-independent solution. There are many different companies working on the combination of Java and XML at the moment. If you want to learn more about this, you can access the Sun's Java-xml page, or IBM developerworks XML Zone.