J2EE layered model component service

The following statements are taken from the network articles and summarized and merged by yourself.

J2EE hierarchy

Early network systems were often designed with a three-tier structure. The most common structure is the presentation layer, domain layer, and infrastructure layer.

The N-layer structure is proposed to adapt to the current needs of developing Web applications in B/S mode. The traditional brown model refers to: presentation layer (presentation), control/mediation layer (Controller/mediator), Domain Layer (domain), data mapping layer (data mapping ), and data source ). In fact, it adds two intermediate layers to the three-tier architecture. The control/mediation layer is located between the presentation layer and the domain layer, and the data ing layer is located between the domain layer and the infrastructure layer.

The J2EE specification puts forward its own hierarchy.

　　

 

One of the basic principles of J2EE is to minimize the decoupling or coupling of each layer. The final implementation can be implemented to switch any layer.

For example, in the data ing layer, you can use BMP, CMP, Or hibernate of EJB.

Or use JDO. This is determined by the deployment environment.

Figure 1. J2EE Application Model

J2EE uses a multi-layer distributed application model. The application logic is divided into components by function, and each application component is distributed on different machines according to their layer. In fact, Sun designed J2EE to solve the disadvantages of the two-layer mode (Client/Server). In the traditional mode, the client plays too many roles and is bloated. In this mode, the first deployment is relatively easy, but it is difficult to upgrade or improve, and the scalability is not ideal, and it is often based on a proprietary protocol ?? It is usually a database protocol. It makes it very difficult to reuse business logic and interface logic. The multi-tier enterprise application model of J2EE divides different layers of the two-tier model into multiple layers. A multi-layer application can provide an independent layer for different services, which are the Client Tier running on the client machine) web Tier running on the Web server and business tier running on the EJB Server) and the enterprise information system layer (enterprise information system tier) running on the EIS server. The web layer and business layer form the middle layer of the three-tier J2EE application, the other two layers are the Client layer, storage layer, or enterprise information system layer. In general, many open vendors publish web servers and EJB Server products together, called application servers or J2EE servers. The J2EE Platform specification also defines components at the corresponding layer:
I. Client layer components
The application client and browser are client-layer components. Client-layer components can be web-based browsers serving as web servers, or independent applications based on traditional methods (non-Web-based, you can complete tasks that cannot be completed by thin clients.
Ii. web layer components
Java Servlet and JavaServer Pages (JSP) are web layer components. As shown in customer Layer 2, the web layer may contain some JavaBean objects to process user input and send the input to the enterprise Bean running on the business layer for processing. According to J2EE specifications, static html pages and applets are not web layer components. In addition to sharing the name "JavaBean", the JavaBean and EJB (Enterprise JavaBean) are completely irrelevant. Many articles use EJB as the original "JavaBean" extension, which is wrong. EJB does not extend or use the JavaBean Component Mode. The original JavaBean (Java. Beans package) is used inside the process (intraprocess), while EJB (javax. EJB package) is a component used between processes (interprocess. That is, the original Javabean is not set for distributed components. It is the best component mode. It may be the best internal component mode developed in the process found so far, but it is not a server-side component mode. EJB can solve the problems brought about by the management of multiple distributed business objects in a three-tier structure.

 

Iii. business layer components
Enterprise JavaBeans (EJB) is a service layer component. The logic of the business-layer code is used to meet the needs of special business fields such as banking, retail, and finance. It is processed by ejbs running on the business layer. Figure 3 shows how an EJB receives data from a client program for processing (if necessary) and sends it to the enterprise information system layer (EIS) for storage, this process can also be reversed.
There are three enterprise-level beans: session beans, entity beans, and message-driven beans. Session Bean indicates temporary interaction with the client program. After the client program is executed, the Session Bean and related data will disappear. On the contrary, the Entity Bean represents a permanent record in a database table. When the client program is terminated or the server is shut down, there will be potential services to ensure that the data of the entity bean can be saved. The message-driven bean combines the characteristics of the Session Bean and the message listener of JMS, allowing a service layer component to receive JMS messages asynchronously.

Iv. enterprise information system layer components
The software used to process enterprise information systems includes enterprise infrastructure systems such as enterprise resource planning (ERP), mainframe transaction processing, database systems, and other legacy information systems. For example, the J2EE application component may need to access the enterprise information system for database connection.

 

J2EE models and components

Web containers and EJB containers are clearly differentiated-this means they are relatively independent from each other. An enterprise's Web Container and EJB container can be products from different vendors.

Both containers can enjoy Enterprise Services. In other words, components in the Web Container can access the database like those in the EJB container, use email and directory services, and send messages.

Only enterprise services that exist in the form of drivers and adaptation programs can access EIS resources.

All application server environments have Java virtual machines, that is, all application servers have Java runtime environments.

During project implementation, it is necessary to separate the custom services and libraries that are frequently used by application components. In the above model, these services are called "Custom Component Libraries ".

The "Custom Component Library" is developed based on the needs of specific projects and is not an integral part of the J2EE Application Server Standard. These libraries tend to grow as the project progresses.

Another typical phenomenon is that when developers access enterprise services, they will find that some core services are the most commonly used. List these services as a separate layer, which corresponds to the "Service Access Database" in Figure 1 ".

In short, the "service access library" should be a subset of J2EE APIs, which varies with enterprise projects. It should be noted that the "Custom Component Library" and "service access library" are not found in the J2EE Application Programming Model officially released by Sun, but in actual development, the existence of these two databases is necessary.

J2EE application components

After reading the relationship between components and services, next we will examine them one by one to understand their respective roles in a complex enterprise computing solution.

Web Container Components

· Java Servlet

Servlet is a logical component that runs on the server end and runs in a Web container. Just as applet extends the basic functions of Web browsers, Servlet extends the functions of web servers-providing programming and dynamic web page generation capabilities.

The main function of servlet is to receive HTTP requests from the client web browser, process input parameters, and then return the results in the http mode that the browser can display.

For example, we can use servlet to develop a simple web-based authentication system. The servlet receives the username and password from the client browser, processes the authentication request, and then sends the authentication result back.

In addition to receiving requests from the client browser, servlets can also call each other.

· Java Server Page (JSP)

Although servlet can generate HTTP output, a better way to display the processing result is to use JSP components (Java Server Page, Java Server Page ). Like servlet, JSP is also a logical layer component running in a Web container. The two components have slightly different functions.

JSP combines HTML and Java. That is to say, jsp can contain both HTML code and Java code. The HTML code is directly sent to the browser, while the Java code is removed and left for explanation and execution by the server. Therefore, JSP is very useful for improving the intelligence of HTML tags.

The best way to add reusable Java code blocks in JSP is to use the JSP tag library. The JSP tag library is easy to develop. It not only facilitates adding Java code to HTML tags, but also enables the HTML code and Java code to be well isolated and easy to maintain.

In Web containers, JSP is often used as a supplement to servlet to display servlet processing results. In addition, the combination of JSP and JavaBean is also very typical.

· JavaBean

Javabean is a basic data model component, which appeared before the emergence of J2EE technology. In the J2EE architecture, JavaBean is common at the customer layer and the presentation logic layer. It can be used with applet or JSP.

Bean Component Construction is easy, as long as some appropriate attributes are defined for a piece of Java code. For example, a simple Java class with a small number of variables, and then add methods such as get_attribute () and set_attribute () defined for the variables, is a standard bean component.

In addition to naming similarities, JavaBean and Enterprise JavaBean (that is, EJB) have no major associations. EJB is another type of Enterprise Java application component.

EJB container Components

· Enterprise JavaBean (EJB)

Enterprise JavaBean or EJB is a distributed and scalable service logic component in J2EE Middleware. In Enterprise Java projects, the EJB component is used to encapsulate core business logic and data model elements.

The running environment of the EJB component is the EJB container. J2EE defines the relationship between the application ebj code and the container environment (contract) in the specification ).

During enterprise application development, developers must comply with certain interface specifications when compiling ejbs. Methods defined in interfaces are implemented by developers and provided by EJB container vendors (or application server developers. Through this mechanism, EJB achieves isolation between the implementation of business logic (the method written by the developer) and the infrastructure supply (the method provided by the container.

An EJB component can be connected to another EJB component, which may be in the same container as the former or in another container of a remote server. As shown in 1, The EJB component can use all enterprise services, as well as custom Component Libraries and service access libraries.

The EJB specification defines the following four types of ejbs to meet the needs of different applications:

· Stateless Session Bean

· State Session Bean

· Entity Bean

· Message-driven Bean

 

To sum up, the combination of various J2EE components, such as EJB, Servlet, and JSP, finally forms an enterprise application system based on MVC with high flexibility and reusability.

J2EE Enterprise Services

As mentioned above, J2EE enterprise services are provided to application components of Web containers and EJB containers. Components access EIS resources through Enterprise Services. There are a variety of access requirements, such as database operations, or complex mainframe communication in a messaging/CICs environment.

The J2EE Service API provides a standard Java interface for specific services such as database access and directory access. This interface completely hides detailed implementation details. Therefore, programmers only need to deal with standard APIs instead of specific resources, which helps them easily use different services.

For example, from the perspective of J2EE application components, accessing the Sybase Database is similar to accessing the Oracle database. The only difference is that you need to select different JDBC drivers and different database files. Since there is almost no need to make any code-level modifications, programmers can easily access different databases.

JDBC (Java Data Base connectivity)

Similar to ODBC, JDBC provides a standard and transparent public programming interface for database connection. developers can implement their underlying drivers according to JDBC standards. The J2EE component Accesses Different Types of relational databases through a unified interface. Because the application code is independent from specific database calls, the code modification overhead can be minimized when the code needs to be transferred from one database to another.

JNDI (Java Naming and directory interfaces, Java Naming/Directory Interface)

In a distributed environment, naming and directory services make it possible to reasonably distribute resources across the entire network. Each resource has a unique name in the distributed Hierarchy Tree. The client obtains the resource handle by accessing the directory service. JNDI sets standards for enterprise naming/directory service calls, and proposes some unified interfaces, which are implemented by developers. Currently, directory services on the market mainly include LDAP, Novell, and Active Directory Services. JNDI defines a service layer on these developer products, users can access various underlying services through a unified interface.

JMS (Java messaging services, Java Message Service)

Message Service plays an important role in a heterogeneous environment. Communication between enterprise mainframe information systems or other legacy systems and fully heterogeneous systems such as J2EE Middleware components relies on the installation of Message Service on both ends. During communication, the applications at both ends communicate with the messaging service processes at the local end, And the messaging service processes in the network transmit messages in sequence through point-to-point or asynchronous mode.

Jmsapi standardizes the call of message service products. Currently, such products are mainly ibm mq series, Microsoft MSMQ, and tibco rendezvous. JMS defines an additional layer on the respective message API calls of these products to unify all these products into one interface. In this way, J2EE applications can be relatively independent from specific developers' product implementation.

Javamail/JAF (JavaBeans activation Framework)

As shown in the name, javamail API provides the e-mail service for J2EE components. It is located at the upper layer of the implementation of specific mail services such as SMTP and POP3. It provides unified access interfaces for all public services such as email format identification, sending and receiving, and determining whether there are attachments.

The javamail API works with JAF (JavaBean activation framework.

RMI (Remote Method invocation, remote method call)-IIOP/Java IDL

The two technologies implement two-way communication between the J2EE component and the CORBA component. Java IDL is the recommended method to access the CORBA object in the J2EE environment; on the contrary, RMI-IIOP is the method to call the J2EE component in the CORBA client program.

Jax (Java API for XML)

Java xml api facilitates users to call XML documents in the J2EE environment. The services provided by Jax API include XML syntax analysis (Sax and Dom), XML binding to Java objects, XML message sending and XSLT conversion.

Jax supports Web services to facilitate the application of J2EE business logic components in various environments.

JCA (Java connector)

JCA is used to connect J2EE applications and EIS architectures, such as ERP, mainframe transaction processing, databases, and other legacy information systems, to help developers seamlessly integrate different types of EIS. The JCA connector establishes a system-level connection with the J2EE application server and an application-level connection with the application components that access the EIS resources. Similar to other service APIs, JCA APIs provide space for developers to develop dedicated resource adapter products while providing unified interfaces.

JTA (Java transaction API, Java transaction Interface)

JTA provides distributed transaction services for the J2EE Platform