The importance of data call between norms
------ From the perspective of data exchange between subsystems to see the efficiency and code of the code and other
First, consider from the perspective of software architecture:
1) The current situation of our software architecture: our main technical critical part of our architecture consists of two parts MVC frame 2 HTML page generation mechanism to company for more than 4 months, with the understanding and coding experience of this architecture, I think Our existing architecture can handle low-coupling between modules, but effective solutions between subsystems have increased possible: that is, improves code reuse and high cohesion of a single module, maximizing repetitive logic modules.
With the expansion speed of our software new modules and the needs of group-level business, the continuous upgrading of technology architecture has also become urgent.
Many mature open code architecture in this process has a good practice for our architecture. 2) What kind of architecture should the software architecture should be
It is also depicted now. . . 3) What kind of ideas should be used to complete the transformation from 1) from 2): Software architecture upgrade can be more difficult than the software function upgrade, the difficult point includes how to prove that new architecture changes can be better The role, how to ensure the smooth transition of business logic during this adjustment.
Generally, the pilot and distribution are often used.
In order to test changes to the new architecture, you can check the pilot in the new module. Gradually adapt to new architectures in key business points, gradually advance to complete this transition.
For example, if the company needs the workflow system, the practice of putting the business system on the workflow system is not good in terms of risk. If the workflow system is proved in a non-critical business module, the code reconstruction is re-divided on the business subsystem, and the smallest code unit is re-divided to migrate the business module to the workflow system. 4) Significance for standard subsystem calls for 3)
At the last technical training meeting, Liu has proposed a problem with data interaction between subsystems with object-oriented methods. This problem is a very forward-looking problem based on the continuous increase in the interaction between the software modules and the increase in data interaction between subsystems. Simply specifying subsystem data exchange this problem does not make sense.
But change angle to see:
1. From the aspect of improving system efficiency: For example: Many modules are used to extract code during the current accounting. The current approach is that each module has its own function, each calling needs to be connected to the database. If you use standard interfaces and appropriate design patterns, this problem can get a better solution.
2. From the perspective of the code logic repeat: such as: Many subsystems need to make accounting credentials. The current approach is that each module has its own logic to make this process. A slight analysis can be found that the production credential logic is fixed, which can be separated into a standard interface to improve the reuse of the code.
3, from the group-level software composition method: Group-level software, subsystems, and frequent data interaction. Especially for software services for different states, such as the group software of a large store, supermarket, convenience store. For a customer, a software is a software, it is to do a project, and the shortcomings are obvious, and XX is responsible. How to solve this contradiction? Improved software configurable levels are the most effective way to build industry software libraries. For example: Kim Think ERP has more than 2,000 configurable business components. To establish a business component library, how to define data interactions between organization components is the key.
My starting point is: theoretically don't have to work, others' models may not be suitable for our architecture, but from the technical improvement of software competitiveness is the core competitiveness of software companies, we have to work in this direction.
Below, if you specify the subsystem interaction, I talk about my understanding and opinion, that is, a prototype. Below is my solution proposed to this question: I call it: Subsystem service engine. Prototype Realization:
A total of three parts: (refer to the current architecture HANDler generating mechanism).
1. Configure the call interface between the subsystem with XML. (Sample see final)
XML configuration is divided into two categories: 1 Define the service type, which can be ordinary Java, JMS, workflow, SOAP, etc. 2 Description of the specific call interface: Define the incoming parameters of the specific call and return parameters. Description of XML is defined for all interfaces in each subsystem.
2, the specific interface is implemented in EJB: it realizes the implementation of EJB in the architecture.
3. Through a master file, the distribution of interface calls
If the above prototype is implemented, the way this interface call can be called: service engine.
The advantages are as follows: 1. Avoid disadvantages directly using the SQL operation database;
2. Avoid the same, or similar business logic has written a lot of drawbacks, improve development efficiency; Many successful projects have proved that the reasonable use of cache is important for improving Java efficiency.
Why don't you use the subsystem to access the EJB method implementation?
Because: If the interaction of subsystem data is all EJB, the disadvantage is not protruding from a simple data exchange.
But as perhaps complex and diversified, only EJB is used to call its expansion.
For example,: 1, you need to use JMS to exchange data (work message release);
3, the control of the permissions between subsystem data calls is not flexible.
In addition: Even if you directly access EJB, interface definition techniques should also be used instead of direct access. In this way, it can guarantee that the logical logic is changed by the caller, and it will at least affect the call to the calling party.
Operability of this program:
From the workload, you must implement the service engine, the main workload is concentrated in: the implementation of the master service distribution logic. This process of this and the process of the current architecture Handler is as sufficient. There is no difficulty in technology.
This way is used to call the return type of the data result. There is only one MAP data type. Because the port calls are called, the data can only be transmitted in the type of package. The benefit is that MAP can be serialized, and can be transmitted on the HTTP protocol, and can even provide and call the WebService service if needed.
XML definition reference format:
Class Name = "xxx.xxx.xxx.xxx" method name = "setxxx"> Based on the above prototype, according to our existing architecture Handler's implementation and call mode, it can be achieved well, and the access and implementation of data between subsystems is reasonable. As long as the interface does not change, the accessed subsystem business logic changes, and the access system does not need to be modified. I have entered a big step forward for our system.
