13 Core Technologies of Java EE (i.)

Java EE was originally in the browser and the client machine. 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 is comprised of a suite of service (services), application interfaces (APIs), and protocols that provide functional support for developing web-based multi-tier applications.





in this article I will explain 13 core technologies that support Java EE: JDBC, JNDI, EJBs, RMI, JSP, Java servlets, XML, JMS, Java IDL, JTS, JTA, JavaMail, and JAF, and 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, in order to give you a better sense of the real application of Java EE, I will introduce these technologies in the 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





in the past, the two-layered applications-often called client/server applications-were 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.





uses Java EE to develop n-tier applications, including dividing the different layers of the two-layered structure into many layers. 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 Generation display: Although browsers can complete some dynamic content display, in order to be compatible with different browsers, these dynamic build work should be done on the Web server, using JSP, Servlets, or XML (Extensible Markup Language) and (Extensible Stylesheet Language).





business logic: business logic is suitable to be implemented with session EJBs (described later).





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





Background System integration: 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.





is based on JAVA2 Platform Standard Edition (J2SE), so 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 EE 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 the WebLogic server create more scalable and maintainable applications that provide increased availability for a large number of users.





Java 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.





Java Database Connectivity (JDBC)




The
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, the Jdbc-odbc bridge was clearly very useful, and through the Jdbc-odbc Bridge, developers could 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 Bridge




The
JDBC 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 Bridge




The
JDBC 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 of
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.





below let's look at an example.





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.*;


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




Application of
JDBC in Enterprise-class application





The above examples are actually very basic, may be somewhat insignificant. 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.




The
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. (Refer to the example in the Weblogic.properties file for more detailed reference information in the WebLogic server's documentation)





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, let's turn to Jndi.