1. EOS application architecture
What EOS solves is to provide a complete set of application architecture for J2EE applications, and to provide a support environment for development, operation, management and maintenance based on this architecture. The core of EOS is the idea of component-oriented, and its goals are mainly to reduce the technical complexity of J2EE applications, improve the development speed of applications, improve the manageability and reuse of components, enhance the maintainability of applications and the ability to adapt to changes in demand .
So, what is the so-called component-oriented architecture of applications developed based on EOS? From the aspect of application function, business functions are carried through component packages. An application can be composed of multiple component packages, each component package implements a set of related business functions. In fact, component packages can be understood as business Functional modules after functional decomposition. The component package is the basic unit of development and deployment on the EOS platform. From the software level dimension, each component package abstracts and forms component elements at different levels according to the idea of MVC, including page component layer, presentation component layer, business component layer, operation component layer, and data component layer from top to bottom. Each level has distinct characteristics and completes the corresponding mission (see the detailed description of each level component below). At the same time, the XML bus technology with strong scalability is introduced to realize data transfer between various levels and improve each level. data scalability.
1.1 Data component layer
Using XR Mapping technology, it mainly realizes the data entity mapping with the enterprise system database, achieves the purpose of data persistence layer management, reduces the coupling between the application and the database structure and database type, and improves the expansion capability of the enterprise application at the data level. Its implementation principle is: EOS encapsulates database operations, completes the conversion and access of database data and XML bus data, and provides a unified and standardized XML interface-based API for application development. As an atomic service, the business processing layer only data can be accessed through it. In addition, the data layer also provides the management capability of the data dictionary, which makes the business configuration of the application layer highly flexible, and the changes of basic data attributes can be completed through parameter configuration.
1.2 Computational component layer
In fact, it is a component-based encapsulation of computer processing operations, because the business functions of the application are ultimately completed by the computing power of the computer, and the specific computing processing of the computer itself is independent of the business (only a certain computing processing is combined with the business operation. process and business data become relevant to the business), the application architecture provided by EOS abstracts the computing processing level to form an independent level, the computing processing must be related to the code, and depends on the specific computer language, precisely because of this level It has nothing to do with business and can be implemented in advance. EOS products provide a wealth of components at this level through the basic component library, so that when developing an enterprise application, basically the computing functions required for business processing have been provided. . Of course, the development tools provided by EOS allow this level to be extended. Even if the application is not enough, new computing components can be developed using JAVA. Overall, in the process of developing an enterprise application, the amount of work spent at this level will become less and simpler.
1.3 Business component layer
It mainly realizes the processing process of application logic. The realization method is to combine many computing components into a complex business processing process (application logic) in a visual way through the component assembly environment, so as to improve the efficiency of development, testing and maintenance. The process of using code to implement business logic in the traditional way has become the process of drawing business flowcharts under the EOS application architecture. It also effectively separates the application logic from the specific code implementation.
1.4 Display component layer
It is an intermediate level connecting the user interface and business processing. For example, a certain processing request (button or connection) of the page will activate the corresponding presentation component, and the presentation component will transfer the data submitted by the user to the corresponding business component for invocation. Return, locate another user interface, and pass the return data of business processing to the corresponding page (somewhat similar to the concept of BEA Workshop page flow, but in EOS, a presentation logic (a concrete implementation in a presentation component) only Handle a business call and page flow relationship between a WEB request (Request) and a response (Response). EOS also provides visual development tools to develop, modify and maintain presentation components.
1.5 Page Component Layer
It mainly provides support for the user interface of the application system. The page component technology provided in EOS is actually a completely standard JSP technology. It mainly provides page components such as page tags (Tag), page controls and RichClient to realize the visual rapid development of the user interface. .
1.6 XML data bus
It is a very important technical feature of the EOS platform. In EOS, through the DOM method of XML, the three major data areas of the application are encapsulated: Session data area (SessionContext), Request data area (RequestContext), business processing data area (BizContext) , which constitutes the data bus area of the entire application. In this way, in the application of EOS, all kinds of data are standardized into XML format, and the data transmission adopts Xpath addressing mode. This data transfer method makes the interface processing in application development quite different from the original method based on object interface. The interface of the component in EOS is equivalent to determining the fixed position of the interface data in the bus. According to different instances at runtime, the content of the corresponding position may be different, while the traditional interface only determines the object type of the interface and the variable name of the object. The instantiation of the object is done when the concrete interface is called. For details on the data bus, see the data flow chapter of the EOS application.
From the above description, we can see 2 important features of this architecture:
1) Application logic and code are relatively separated. The application logic in the application system reflects the business characteristics and management concepts of the enterprise, and is the carrier of the business knowledge and management process of the enterprise, while the business content and management mode of the enterprise grow dynamically, which requires the maintenance of the application system to adapt to the this change. When the application logic is implemented independently of the specific code, the application logic expressed graphically becomes easy to adjust to adapt to new changes.
2) Application logic and data are relatively separated. In the traditional way, code, business logic, and data are three-in-one. When the data is independent of the application logic through the XML bus, the application system will greatly improve the data expansion capability.
2. The operating mechanism of EOS applications
After understanding the architecture of EOS applications, what is the representation of J2EE applications developed through EOS products? How is the implemented application run and managed? We'll delve deeper into this in this section.
First of all, let's take a look at the content to be implemented in developing applications with EOS, including JSP pages, presentation logic (an interface implementation of a presentation component), business logic (an interface implementation of a business component), and operation logic (not all component packages need to develop operation logic. ), data entity files, the following is a detailed description of the form of each content during development and runtime:
2.1 JSP page file
The development follows the standard JSP mechanism and specification. EOS provides a set of page TAG for JSP development to realize the binding of page data and XML data bus data. In addition, the submission action (Action) of the page form (Form) will be directly Mapping to represent logical names, the following is the content of a typical JSP page file:
<%@ page language="java" contentType="text/html; charset=GBK"%>
<%@ taglib uri="/WEB-INF/hci-html.tld" prefix="html" %>
<%@ taglib uri="/WEB-INF/hci-bean.tld" prefix="bean" %>
<%@ taglib uri="/WEB-INF/hci-dict.tld" prefix="dict" %>
<%@include file="/internet/common.jsp"%>
<SCRIPT language="JavaScript" src="/pageComponent/resources/scripts/dataformcheck.js"></SCRIPT>
<SCRIPT language="JavaScript" src="/pageComponent/resources/scripts/calendar.js"></SCRIPT>
<link rel="stylesheet" href="/pageComponent/resources/theme/style.css" type="text/css">
<br>
<FORM name="inputForm" action="CUSTMgr.pr.prCUSTInsert.do" method="post" target="_top">
<TABLE width="80%" cellPadding="0" align="center" class="pg_add" border="0" cellSpacing="0">
<TBODY>
<TR>
<TD class="pg_add_title" colSpan="6">增加客户信息</TD>
</TR>
<TR>
<TD class="pg_add_head">客户名称:</TD>
<TD class="pg_add_content">
<html:text onblur="checkInput(this)" attributesText='eos_isnull="true" eos_maxsize="10" eos_displayname="客户名称"' property="CUST/CUSTNAME" />
</TD>
<TD class="pg_add_head">身份证号:</TD>
<TD class="pg_add_content">
<html:text onblur="checkInput(this)" attributesText='eos_isnull="true" eos_maxsize="20" eos_datatype="IDno" eos_displayname="身份证号"' property="CUST/CARDID" />
</TD>
<TD class="pg_add_head">性别:</TD>
<TD class="pg_add_content">
<dict:select property="CUST/SEX" nullLabel="" nullOption="true" businTypeId="BNDICT_gender" />
</TD>
</TR>
<TR class="pg_add_bottom">
<TD colSpan="6">
<DIV align="center">【<A href="javascript:check(document.inputForm);">提交</A>】 【<A
href="javascript:resetData(document.inputForm);">重置</A>】 【<A href="javascript:history.go(-1);">返回</A>】</DIV>
</TD>
</TR>
</TBODY>
</TABLE>
</FORM>
It can be seen that CUSTMgr.pr.prCUSTInsert.do in action="CUSTMgr.pr.prCUSTInsert.do" actually corresponds to a presentation logic (suffixed with .do), <html:text />, <dict:select /> is a tag (Tag) provided by EOS. The attribute property="CUST/CUSTNAME" in the tag is parsed into HTML and becomes the corresponding NAME of the tag. After this NAME is submitted to the WEB container, it is mapped to the data bus by the WEB Driver. path. The input information is mapped to the value on the corresponding path of the data bus. For details, please refer to the "Data Flow of EOS Application" chapter. The JSP file belongs to the same file during development and deployment, with the suffix .jsp. The JSP file is deployed in the WEB module of the application server.
[Description] If the content corresponding to the action is suffixed with ".do", it is regarded as the presentation logic, which is determined by the web.xml configuration file of the WEB server. In the web.xml file, there is the following configuration information:
<servlet>
<display-name>EOS Server</display-name>
<servlet-name>webDriver</servlet-name>
<servlet-class>com.primeton.tp.web.driver.webdriver.WebDriverUpload</servlet-class>
……
</servlet>
<servlet-mapping>
<servlet-name>webDriver</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
……
The above configuration shows that: if the request submitted to the WEB container based on the HTTP mechanism, if it ends with .do, it will be handed over to webDriver for processing, and the implementation class of webDriver is com.primeton.tp.web.driver.webdriver.WebDriverUpload, this The class will call the presentation logic of the corresponding name, and transfer the form data submitted by the HTML page to the data bus RequestContext.
2.2 Display logic files
It is divided into description files and compiled files, with .prg and .pra as the file suffixes respectively. The presentation logic description file prg is generated during development (which can be understood as the presentation logic source code), and mainly describes the relationship between the primitives and primitives of the presentation logic diagram. The location, primitive description, business logic path of the call, page path of the call, and parameter information, etc., the content of the prg file is in XML format, which can only be converted into visible graphics through EOS Studio. The compiled file pra that displays the logic is generated after the prg file is compiled by EOS Studio. It is a runtime file and needs to be deployed to the server. The content of this compiled file is also in XML format, which mainly describes the calling relationship and parameter information of the presentation logic.
2.3 Business logic files
It is also divided into description files and compiled files, with .bzg and bza as the file suffixes respectively. The business logic description file bzg is generated during development (it can be understood as business logic source code), and mainly describes the graphic element relationship and graphic element location of the business logic. , primitive description, calling operation logic path, and parameter information, etc. The content of the bzg file is in XML format, which can only be converted into visible graphics through EOS Studio. Retaining the business logic description file is convenient for application management and maintenance. The compiled file bza of the business logic is generated after the bzg file is compiled by EOS Studio. It is a runtime file and needs to be deployed to the server. The content of this compiled file is also in XML format, which mainly describes the calling relationship and parameter information of the business logic.
2.4 Operation logic file
It is a standard JAVA file. The operation logic (commonly known as BL method) is a static method in the operation logic class. Of course, the operation logic method has strict interface specification requirements. The basic component library of EOS provides basic and sufficient operation logic. In the application project, the operation logic based on JAVA code needs to be written only in the following cases:
l The user already has some general-purpose or highly specialized JAVA packages (such as security processing, etc.), and they need to encapsulate these JAVA methods through operation logic and become drag-and-drop operation components
l Some business processing is too complicated to implement through business logic, and there are efficiency problems, which need to be encapsulated by java code
l In some applications, there are some specific protocol communication with other systems, and it is necessary to encapsulate the communication method based on the code to form a computing component
l The computing components provided by the basic component library are indeed insufficient or the functions are not satisfied, and need to be expanded
The operation logic class is developed as a JAVA file, and compiled into a class file. It is packaged to form a jar file and deployed to the server's classpath environment for use.
2.5 Data entity file
It mainly realizes the persistence of data, which is actually the description of the structure of database tables (or views) through XML language, and also supports the establishment of corresponding data entities according to a SQL statement. The data entity file is suffixed with .ent (corresponding to a table or view), ens (corresponding to SQL query), and .dtr (corresponding to a custom data tree), and its file content is also XML. The data entity file is the same file at development time and runtime, and all data entity files are deployed in the datadict directory of eosserver.