Web service Search and execution engine (4)-System Architecture Design Based on (3)

Previous summary document Web service Search and execution engine (III)-System Design SchemeIt can be said that it is a physical structure of the system. Based on this structure, we design the following system architecture.

1System Function Diagram

The system function Diagram 1 is shown in. User Management: Service users must register with the system to truly use a service. service users can view their consumption records and other information. The system needs to manage the data of service users. Provider management: The provider must register the system to publish services. The system must manage and maintain the service provider information. Service Release Function: The service provider can publish the service to the system by entering service-related data, such as the description of each part of the service and the WSDL location of the service. Service search: A service user can search for the desired service. The System Searches the service information of all service publishers, finds the appropriate service information, and returns it to the user. Service Execution Function: Service users only need to enter some information on the webpage to call the remote heterogeneous platform service. This is also the ultimate goal of users and systems. Service Management: A service provider can manage its published services, such as modifying service data, deleting the provided services, and viewing the consumption records of the services. Figure 1 system function Diagram 2 System ArchitectureThe system is implemented using J2EE WEB technology and uses the layered architecture of the traditional MVC and Dao modes to organize the entire system. When I first came into contact with this project last semester, I planned to use several popular open-source frameworks to construct the entire system. For example, I used struts to design the display layer and spring to design the core business layer, the use of native JDBC (since Hibernate is only a simple understanding, so I didn't plan to use it at the time), coupled with the index database engine Lucene to design the persistence layer, in the past, the team project did not use STRUTS + spring, but only used spring for small cases, while struts was used for team projects, however, after a pleasant winter vacation, I was not fully prepared for the combination of the two open-source projects. So when I came back from school, I had to submit my work in just one month, however, the two open-source frameworks have not yet been used to design the entire system architecture, and the final decision is to use the method that I used in Architecture team projects: Traditional MVC + standard Dao. That is to say, I use the MVC pattern to design the presentation layer and the DAO pattern to set the persistence layer, while the core business layer uses JavaBean. I think there is another reason for such a combination, the designed system must be scalable. When the team programmed the system a few days ago, it reflected the importance of the architecture. First of all, our system had a diversity of customer performance, that is to say, the system supports JSP page clients and j2's mobile phone clients. During programming, the two clients must avoid repeated programming and reuse existing code, therefore, the presentation layer must be scalable, that is, the presentation layer designed using the MVC mode. The core code of the system should not be affected when the system adds another client presentation mode, that is to say, it embodies the principle of "open-closed", the cornerstone of object-oriented design: A software entity should be open to expansion and closed to modification. Another point is that the persistence layer of the system is special. Because two database storage policies, Lucene index engine and MySQL database, are used, during the design of the persistence layer, I still follow the methods that have been used in previous projects: use the standard DAO mode to design the persistence layer, you can look at seconfig. xml configuration file: <? XML version = "1.0"?>
<Config>
<Daos>
<Dao id = "servicedaolucence"
Type = "com. SWC. se. Dao. Lucene. servicedaolucence"/>
<Dao id = "operationdao"
Type = "com. SWC. se. Dao. JDBC. operationdaojdbc"/>
<Dao id = "servicedaojdbc"
Type = "com. SWC. se. Dao. JDBC. servicedaojdbc"/> <Dao id = "cosuminghistorydao"
Type = "com. SWC. se. Dao. JDBC. cosuminghistorydao"/>

<Dao id = "providerdao"
Type = "com. SWC. se. Dao. JDBC. providerdaojdbc"/>

<Dao id = "consumerdao"
Type = "com. SWC. se. Dao. JDBC. consumerdaojdbc"/>
<Dao id = "detectdao"
Type = "com. SWC. se. Dao. JDBC. detectdaojdbc"/>
<Dao id = "parameterdao"
Type = "com. SWC. se. Dao. JDBC. parameterdaojdbc"/>
</Daos>
</Config> for servicedao, there are two implementation methods: MySQL + Lucene. This interface hides the persistence operation details, and the final implementation details are the storage policies used, it is confirmed by the system runtime. If the system wants to change another storage policy or add a storage method in the future, you can add instructions in this configuration file. I think so too Another object-oriented design principle,Dependency inversion principle: It depends on abstraction and not on specifics. That is, do not implement programming for the interface.
This is also reflected in the IOC framework of the open-source framework spring. For more information, see my blog: A pleasant "DAO mode tour" (3). The final system architecture is as follows: View (V)JSP is used as an interface for users to interact with the system through the Web, and the mobile client is developed using j2s, so that users can perform online operations through mobile devices. Controller (c)The controller uses Java Servlet technology, Com. SWC. se. the Controller receives HTTP requests from the browser, Com. SWC. se. controller. mobile receives HTTP requests from mobile phones, calls the corresponding Logic Based on the requests, and returns the results to the user client. Figure 2 system implementation architecture Model (m)The system logic layer consists of all the processing logic, namely the com. SWC. se. Model package, which includes the database operation module, service parsing module, and search module. The model in MVC mode calls Dao objects in DAO mode. Therefore, the Business Objects at this layer should only focus on the business logic rather than the details of data access. Data access objects must implement specific persistence policies. For example, based on the persistence logic of JDBC and Lucene, the following Dao layer is extracted, DaoAs a data source layer, the model layer communicates with it. If we put all the details that implement data access operations into the high-level model, the structure of the system becomes a little messy at a certain level. The low-level data access logic is separated from the high-level business logic, and a DaO interface is used to hide the details of persistent operations. The ultimate goal of this operation is to make the business objects do not need to know the underlying persistence technical knowledge, this is one of the standard J2EE design patterns and one of the principles that we follow when constructing the entire system. DBDatabase, used to store information about Web Services released by all web service providers, such as Chinese descriptions of service operations and Chinese descriptions of input/output parameters. LuceneThe index library is used to store the main information of all Web Services, and describe the URL and service name of the WSDL. Service Session LayerThe com. SWC. se. util package is mainly used to parse the WSDL transform of the Web Service Description document, and construct the invoke class of the soap message using the SAAJ technology. Figure 3 system core class diagramThe Services released by remote heterogeneous platforms are the final execution part of user requirements. 3 System CoreSome core classes in the system and their relationships are shown in figure 3. 4 Typical business sequence diagram4. Shows the sequence of a user's search for a service and execution of its call. Figure 4 system typical business sequence diagram