Java EE Framework __java

four-layer model of Java EE

Java EE uses a multi-tier distributed Application model, where the application logic is divided into components by function, and each application component is distributed on different machines based on the layer they are in. In fact, Sun Design Java EE is designed to solve the drawbacks of the two-tier model (Client/server), in the traditional mode, the client has too much role to appear bloated, in this mode, the first deployment is easier, but difficult to upgrade or improve, extensibility is not ideal, And often based on a proprietary protocol-usually some kind of database protocol. It makes it very difficult to reuse business logic and interface logic. Now Java EE's multi-layer enterprise application model divides the different layers in the two-layered model into many tiers. A multi-tier application can provide a separate layer for each service, and the following is a typical four-tier architecture of Java EE:

Client layer components running on the client machine
Web-tier components running on Java EE servers
Business Logic layer components running on Java EE servers
Enterprise Information System (Enterprise information System) layer software running on an EIS server

Java EE application components
Java EE applications are composed of components. Java EE components are stand-alone functional software units that pass a four-layer model of the relevant Java EE

Java EE uses a multi-tier distributed Application model, where the application logic is divided into components by function, and each application component is distributed on different machines based on the layer they are in. In fact, Sun design Java-EE is designed to solve the drawbacks of the two-tier model (Client/server), in the traditional mode, the client has too much role to appear bloated, in this mode, the first deployment is easier, but difficult to upgrade or improve, scalability is not ideal, And often based on a proprietary protocol-usually some kind of database protocol. It makes it very difficult to reuse business logic and interface logic. Now Java EE's multi-layer enterprise application model divides the different layers in the two-layered model into many tiers. A multi-tier application can provide a separate layer for each service, and the following is a typical four-tier architecture of Java EE:

Client layer components running on the client machine
Web-tier components running on Java EE servers
Business Logic layer components running on Java EE servers
Enterprise Information System (Enterprise information System) layer software running on an EIS server

Java EE application components
Java EE applications are made up of components. The Java EE component is a self-contained software unit that is assembled into a Java EE application through related classes and files and interacts with other components. The Java EE specification defines the following Java EE components:
Application client programs and applets are customer layer components.
The Java servlet and JavaServer Pages (JSP) are web-tier components.
Enterprise JavaBeans (EJB) is a business layer component.

Customer Layer Components
Java EE applications can be web-based or based on traditional methods.
The Web Layer component Java EE Web Layer component can be either a JSP page or a servlets. According to the Java EE specification, static HTML pages and applets are not web-tier components.

As the customer tier shown in the following illustration, the Web layer may contain some JavaBean objects to handle user input and send the input to the enterprise bean running on the business layer for processing.

Business Layer Components
The logic of the business layer code is used to meet the needs of special business areas such as banking, retailing, finance, and processing by enterprise beans running on the business tier. The following figure shows how a enterprise bean receives data from a client program, processes it (if necessary), and sends it to the EIS layer to store it, which can be reversed.

There are three enterprise-class beans: Session beans, Entity (entity) beans, and message driven (Message-driven) beans. The session bean represents a temporary interaction with the client program. When the client program finishes executing, the session bean and related data disappear. Instead, the entity bean represents a row of persistent records in the database's table. When the client program aborts or the server shuts down, there is a potential service to ensure that the entity bean's data is saved. Message-driven beans combine the characteristics of session beans and JMS message listeners, allowing one business layer component to receive JMS messages asynchronously.

Enterprise Information System Layer
Enterprise Information System layer processing enterprise Information System software includes enterprise infrastructure systems such as enterprise resource Planning (ERP), mainframe transaction processing, database system, and other legacy information systems. For example, the Java EE Application component may require access to enterprise information systems for database connectivity

We will elaborate on the various components, services, and APIs of Java EE to see how to flexibly use and combine different components and services when developing different types of enterprise applications, depending on their needs and objectives.

· Servlet

The servlet is a CGI technology on the Java platform. The servlet runs on the server side and dynamically generates Web pages. The Java servlet is more efficient and easier to use than traditional CGI and many other CGI-like technologies. For a servlet, a duplicate request does not cause multiple reprint of the same program, and it relies on threading to support concurrent access.

· Jsp

JSP (Java Server page) is a technology that implements mixed coding of ordinary static HTML and dynamic page output. From this point of view, very similar to Microsoft ASP, PHP and other technologies. With the help of the separation of formal content and appearance, the task of Web page making can be easily divided into page designers and programmers, and easily synthesized by JSP. In the runtime, the JSP will be converted into a servlet first and run in the form of a servlet, so its efficiency and functionality are no different from those of the servlet, and are of high efficiency.

· Ejb

EJB defines a reusable set of components: Enterprise Beans. Developers can use these components to build distributed applications like building blocks. When assembling components, all enterprise beans need to be configured to the EJB server (General WebLogic, WebSphere, etc. java application servers are EJB servers). The EJB server manages the EJB container as a bridge between the container and the lower platform and provides the container with the ability to access the system services. All EJB instances are running in the EJB container. The EJB container provides a system-level service that controls the lifecycle of the EJB. The EJB container facilitates the development of business logic by hosting technical links such as security, remote connectivity, lifecycle management, and transaction management for its developers. Three kinds of enterprise Beans are defined in EJB:

Session Beans

Entity Beans

Message-driven Beans

· Jdbc

The JDBC (Java database Connectivity,java DB connection) API is a standard SQL (structured query Language) database access interface that enables database developers to use standard Java API to write database applications. The JDBC API is primarily used to connect databases and directly invoke SQL commands to execute various SQL statements. Using the JDBC API, you can execute generic SQL statements, dynamic SQL statements, and stored procedures with in and out parameters. JDBC in Java is equivalent to the ODBC (Open Database connectivity) in the Microsoft platform.

· Jms

The JMS (Java Message Service,java Messaging service) is a set of Java application interfaces that provide services for creating, sending, receiving, and reading messages. The JMS API defines a set of common application interfaces and corresponding syntaxes that enable Java applications to communicate with various messaging middleware, including IBM Mq-series, Microsoft MSMQ, and pure Java SONICMQ. By using the JMS APIs, developers do not have to master the use of different messaging products or use a unified JMS API to manipulate various message middleware. By using JMS, you can maximize the portability of messaging applications. JMS supports both point-to-point message traffic and publish/subscribe messaging.

· Jndi

Because Java EE application components are generally distributed across different machines, a mechanism is needed to facilitate component client consumers to find and reference components and resources. In the Java EE system, use Jndi (Java naming and Directory Interface) to locate various objects, including EJBS, database drivers, JDBC data sources, and message connections. The JNDI API provides the application with a unified interface to perform standard directory operations, such as locating and locating the object through object properties. Because Jndi is independent of the directory protocol, applications can also use Jndi to access a variety of specific directory services, such as LDAP, NDS, and DNS.

· Jta

The JTA (Java Transaction API) provides a standard interface for processing transactions in Java EE, which supports the start, rollback, and submission of transactions. At the same time, on the general Java EE platform, a JTS (Java Transaction service) is always provided as a standard transaction processing service, and developers can use JTA to use JTS.

· Jca

The JCA (Java EE Connector architecture) is part of the Java EE Architecture, providing developers with an architecture to connect various enterprise information systems (EIS, including ERP, SCM, CRM, and so on) for EIS developers, They only need to develop a set of JCA-based EIS connection adapters that developers can connect to and use on any Java EE application server. The implementation of the connection adapter based on JCA needs to involve service components such as transaction management, security management, and connection management in Java EE.

· Jmx

The predecessor of JMX (Java Management Extensions) is Jmapi. JMX is committed to solving the problem of distributed system management. JMX is a collection of application programming interfaces, extensible objects and methods, which can be used to develop seamless integrated system-oriented, network and service management applications across a variety of heterogeneous operating system platforms, system architectures, and network transport protocols. JMX is a complete network management application development environment that provides the complete list of features that vendors need to collect, a list of resources to generate, a graphical user interface, a network API to access SNMP, remote procedure calls between hosts, database access methods, and so on.

· Jaas

The JAAS (Java authentication and Authorization Service) implements a Java version of the standard pluggable authentication Module (PAM) framework. Jaas can be used to authenticate users so that it is reliable and safe to determine who is executing Java code. At the same time, Jaas can also implement user-based access control by authorizing the user.

· Jacc

JACC (Java Authorization Service Provider Contract for containers) defines a connection between the Java EE Application Server and a specific authorized authentication server. To insert a variety of licensing authentication servers into the Java EE product.

· Jax - rpc

By using JAX-RPC (Java API for xml-based RPC), existing Java classes or Java applications can be repackaged and published as Web services. JAX-RPC provides an API for encoding and decoding RPC parameters (in/out), enabling developers to easily use SOAP messages to complete RPC calls. Similarly, for commercial applications that use EJB (Enterprise JavaBeans), Jax-RPC can also be packaged as Web services, and the Web Servoce WSDL interface is consistent with the original EJB approach. JAX-RPC wraps up the deployment and implementation of Web services for users, and soap/wsdl becomes transparent to Web service developers, which facilitates the accelerated development cycle of Web services.

· Jaxr

JAXR (Java API for XML registries) provides APIs that interact with multiple types of registration services. JAXR runs the Client access Web servcices that is compatible with the JAXR specification, where Web Services is the registration service. In general, registration services are always run as Web services. JAXR supports three types of registration services: JAXR pluggable Provider, registry-specific jaxr Provider, JAXR Bridge Provider (support for UDDI Registry and ebXML Registry/repository, etc.).

· SAAJ

SAAJ (soap with attachemnts APIs for Java) is an enhancement of Jax-RPC, providing support for low-level SOAP message manipulation.

the structure of Java EE

This component-based, platform-independent Java EE architecture makes Java EE programs easy to write because business logic is encapsulated into reusable components, and the Java EE Server provides back-office services for all component types in the form of containers. Because you don't have to develop this service yourself, you can focus on solving the business problems at hand.

Containers and Services

The container settings customize the internal support provided by the Java EE server, including security, transaction Management, JNDI (Java naming and Directory Interface) addressing, remote connectivity, and other services to address the most important of these services:

The Java EE security model allows you to configure Web Components or enterprise beans so that only authorized users can access system resources. Each customer belongs to a particular role, and each role only allows specific methods to be activated. You should declare the role and the method that can be activated in the Enterprise bean's layout description. Because of this declarative approach, you do not have to write rules to enforce security.

The Java EE transaction management (Transaction Management) model lets you specify the relationships between all the methods in a transaction, so that all the methods in a transaction are treated as a single unit. When the client activates a method in a enterprise bean, the container is involved in an administrative transaction. Because of a container-managed transaction, it is not necessary to encode the bounds of the transaction in the Enterprise bean. Code that requires control over distributed transactions can be very complex. Instead of writing and debugging complex code, you simply declare the transaction attributes of the enterprise bean in the layout description file. The container will read this file and handle this enterprise bean transaction for you.

The Jndi Addressing (Jndi Lookup) service provides a unified interface to multiple names and directory services within an enterprise so that application components can access the name and directory services.

The Java EE remote client Connectivity model manages low-level interactions between clients and enterprise beans. When a enterprise bean is created, a client can call its method as if it were on the same virtual machine as the client.

The Lifecycle Management (Life Cycle Management) model manages the creation and removal of enterprise beans, and a enterprise bean will go through several states in its lifetime. The container creates the enterprise bean and moves it in the available instance pool and the active state, and eventually removes it from the container. Even if you can call the Enterprisebean create and remove methods, the container will perform these tasks in the background.

Enterprise-Class application examples

Let's take a look at the application of various components and services by assuming a Java EE implementation of an enterprise application. Suppose the Application object is the sales system of the manufacturer/retailer of the computer product, which can distribute product information through its own website, and can also transmit the product catalogue to the computer product trading market. The sales system can accept orders online (from its own web site or from the computer product market) and then transfer it to the internal enterprise management system for subsequent processing.

See Figure 1, this enterprise application can be architected in this way. The core of this enterprise application is the business logic of product catalog management and product order management, implemented using EJB and deployed in EJB container. Because the product catalog and order information need to be persisted, use JDBC to connect to the database and use JTA to complete the database access transaction.

Figure 1 Java EE application example

Then use Jsp/servlet to implement the Web performance of the application: online product catalog browsing and online ordering. In order to send a product catalog to a specific trading market, JMS is used to implement asynchronous, message based product catalog transmissions. To enable more other external markets to integrate product catalogs and order operations, it is necessary to use Web services technology to package the implementation of business logic. Because product order management needs to be handled by in-house employees, it is necessary to integrate user systems and access control services within the company to facilitate employee use, use the JACC integrated internal access Control service, use the Jndi integration internal user directory, and use Jaas for access control. Because the product ordering transaction triggers subsequent enterprise ERP system related operations (including warehousing, finance, production, etc.), it is necessary to use JCA to connect Enterprise ERP.

Finally, in order to incorporate this application into the overall system management system of the enterprise, a management client (with other enterprise application management applications deployed on a single machine) is used by the application client architecture, and the enterprise application is managed through JMX.

(These Jca,jdbc,jta,jni,jacc,jaas, etc. APIs are used in the business layer, that is, the EJB component layer, in the writing EJB, according to the specifications required by these APIs, the implementation of the EJB container for macro management, regulation.) ）