J2EE is a set of specifications for Web Service, business objects, data access and message delivery. This set of application programming interfaces determines the communication method between Web applications and the servers that host them.
J2EE focuses on two things. One is to establish standards so that the deployment of Web applications has nothing to do with the server; the other is to enable the server to control the life cycle of components and other resources so as to be able to deal with expansion, concurrency, transaction management and security issues.
The J2EE specification defines the following components: application client components, EJB components, Servlets and JSP, and Applet components. J2EE uses a multi-tier distributed application model, which means that application logic will be divided into several parts according to functions. Users can install J2EE applications composed of different application components on the same or different servers. These levels can be seen in Figure 1.
1 Presentation layer
The J2EE client can be web-based or Java-based. With the help of technologies such as HTML, Java script, and XML, Web browsers can support powerful and fast user interfaces. In fact, if HTML is sufficient to capture and display the information required by the application, HTML is the first choice; if HTML is not sufficient for this purpose, the client should perform the necessary capture and operations. Whether it is an Applet or an independent Java program, it can provide a richer graphical user interface.
Applet can also communicate with the middle layer to further enhance program control and system flexibility. Distributed enterprise applications can include multiple clients at the same time, and these clients can all access the same business logic. As shown in Figure 2: When the client is HTML, the JSP/Servlet combination will become a real client that can achieve business goals. When the client is a Java program or a COM-based program, it can directly access the business logic.
2 Application service layer
In general, the application service layer contains the presentation logic and business logic requested by the presentation layer. The presentation layer is implemented by JSP pages and Servlets that display HTML pages. Business logic is implemented through RMI objects and EJB. EJB relies on the container to implement transaction processing, life cycle and state management, resource pooling, security and other issues. The container is the environment in which EJB runs.
2.1 Servlet
Java Servlet s refers to programs that can extend the functionality of a Web server. The servlet accepts the request from the client, dynamically generates a response, and then sends the request containing the HTML or XML document to the client. Servlet is similar to CGI (Common Gateway Interface), but Servlet uses Java classes and streams, making it easier to write; because Servlet can be compiled into Java bytecode, at runtime, Servlet routines reside in memory, and every user request is A new thread is generated, so their execution speed is also faster.
2.2 JSP
JSP page is a text-based Servlet development method. JSP page has all the advantages of Servlet, if combined with Java Beans class, you can easily separate content and display logic. This makes it possible to update the appearance of the page without knowing the Java code, and the person who updates the Java Beans class does not need to have a deep understanding of the design of the Web page. Compared with CGI, because CGI relies on the platform, consumes more resources, and programs cannot easily access parameter data and other shortcomings, JSP pages and Servlets are more widely used than CGI.
Users can use JSP pages with Java Beans classes to define Web templates to build a Web site composed of similar-looking pages, and Java Beans classes are responsible for organizing data. Users can also use tags and scripts to bundle content and application logic, or embed some Java applets to implement simple Web applications.
2.3 JMS
JMS is a J2EE mechanism that supports information exchange between Java programs. This is also how Java supports asynchronous communication-the sender and receiver do not need to know each other, so they can operate independently.
JMS supports two message propagation modes:
Point to point (pointtopoint). Based on the message queue, the message producer sends the message to the queue. Message consumers can connect themselves to the queue to listen to messages. When the message arrives in the queue, the client can take it from the queue and give a response. Messages can only be sent to one queue and can only be used by one consumer. Consumers can filter messages in order to get the messages they want.
Publish and subscribe (publish/subscribe). The message producer sends the message to a topic (topic), and all consumers registered on this topic can receive these messages. In this case, many consumers can receive the same message.
2.4 JNDI
Since J2EE application components can run independently and run on different devices, the client and application server layer codes must find and refer to other codes and resources in some way. Client and application code use JNDI (Java Naming and Directory Interface, Java naming and directory interface) to find user-defined objects (such as EJB) and environment entities (Entities). In JDBC2.0, data sources can be bound to JNDI and allow application access.
2.5 Transaction processing
The J2EE transaction processing model can define the relationship between the methods that constitute a transaction during the deployment process, so that all methods in the transaction can exist as a whole. If the user wants to complete this task, because the transaction processing is a series of steps, either all executed successfully, or all rolled back. For example, there may be a series of methods in EJB, whose function is to transfer funds from one account to another, by debiting the first account and crediting the second account. The user may wish to treat all operations as a whole, so that if a failure occurs after the debit but before the credit, the debit will be rolled back.
The attributes of transaction processing are determined during the integration process of application components. It can combine various methods into transaction processing between application components, that is, users can easily redistribute transaction processing attributes of application components in J2EE applications without modifying the code and recompiling.
J2EE Transaction Processing API (JTA) and Java Transaction Processing Service (JTS) form the basis of transaction processing support in J2EE, and are more suitable for EJB and JDBC2.0. JTS is a low-level transaction management API, whose main function is to map Java to the object transaction processing service of the Object Management Group (OMG). JTA is a high-level API, including two parts:
-
Transaction processing interface. This interface allows transaction processing to be delimited, and the work is completed by global transaction processing registration through distributed components. This method allows multiple groups of operations to form a transaction.
-
XA resource interface. Based on the X/Open/XA interface that can handle distributed transaction processing, sometimes called two-step commit transaction processing, coordination between multiple resources, such as databases or sequences, is required. Distributed transaction processing is coordinated by a two-step commit protocol, which can span multiple databases accessed with XA-compatible JDBC drivers, such as BEAWeb Logic Driver for Oracle/XA.
The EJB specification defines Bean-managed transaction processing and Container-managed transaction processing. When EJB is deployed with Container-managed transaction processing, the application server will automatically coordinate transaction processing. If the EJB is deployed by bean-managed transaction processing, the EJB parameters must provide transaction processing code. Application code based on JMS or JDBC API can initiate transaction processing, or participate in previously initiated transaction processing. A transaction processing connection is related to the application server thread executing the application, and all transaction processing operations are executed on the thread participating in the current transaction processing. In most cases, users do not need to worry about writing explicit transaction processing with JTA, because this work is done by JDBC, EJB API is handled by Container and configured by application deployment specifier. In this way, users can focus on transaction design rather than implementation.
