Research on the Construction Method of the Service-Oriented Web-SWMM System

: On a global scale, with the acceleration of urbanization and the continuous expansion of cities, the problem of urban ﬂooding has become increasingly prominent. An increasing number of experts and scholars have begun to focus on this phenomenon and build corresponding models to solve the problem. The storm water management model 5 (SWMM5) is a dynamic rainfall-runo ﬀ simulation model developed by the US Environmental Protection Agency (EPA); this model simulates urban ﬂooding and drainage well and is widely favored by researchers. However, the use of SWMM5 is relatively cumbersome and limited by the operational platform, and these factors hinder the further promotion and sharing of SWMM5. Based on the OpenGMS platform, this study ﬁrst encapsulates, deploys, and publishes SWMM5 and further builds the Web-SWMM system for the model. With Web-SWMM, the user can conveniently use network data resources online and call SWMM5 to carry out calculations, avoiding the di ﬃ culties caused by the localized use of SWMM5 and enabling the sharing and reuse of SWMM5.


Introduction
In recent years, the acceleration of urbanization has led to a sharp increase in the urban impervious area; under the influence of extreme weather such as heavy rain and typhoon, urban flooding is highly prone to occur [1][2][3]. To solve urban flood disasters and build a sponge city, modeling is used to quantitatively simulate flooding that may occur and to carry out key drainage treatment in places where flooding may occur according to the simulation results [4][5][6].
The storm water management model (SWMM) is a dynamic rainfall-runoff simulation model developed by the US Environmental Protection Agency (EPA) [7]. SWMM is widely used in rainfall-flood simulation and water pollution analysis in urban areas [8][9][10][11][12][13][14]. This model was originally developed in 1971, and has undergone several major upgrades [15]. The latest EPA SWMM5 is one of the best representations of the global hydrological model. ("SWMM" is used hereafter to refer to the latest EPA SWMM5.) SWMM is mainly composed of modules such as the hydrologic module, hydraulic module, and water quality module. The use of SWMM to simulate floods in subcatchments requires a comprehensive consideration of rainfall, vegetation interception, soil infiltration, surface filling, and evapotranspiration. In addition, the surface runoff is treated by a storage system consisting of pipelines, open channels, water storage facilities, pumps, and regulators to calculate the water ISPRS Int. J. Geo-Inf. 2019, 8, x FOR PEER REVIEW 3 of 20

Encapsulating and Packaging SWMM
In order to shield the differences in multi-source heterogeneous geographic data, encapsulate the model, and publish it as a web service, some organizations have proposed solutions. For example, web map service (WMS), web feature service (WFS), and web process service (WPS), proposed by open geospatial consortium (OGC), provide a spatial data interoperability specification based on web service. However, these methods are generally limited to spatial data processing, which means they are not suitable for describing the semantic information of model input and output.
Geographic model encapsulation proposed by this paper follows a set of defined protocols and methods. The geographic model is encapsulated into an executable program or script with standard forms and behavioral features to shield the complexity and heterogeneity of the model. The geo-modeling encapsulation standard defines three basic interfaces for encapsulating geographic models: the model description interface, the model execution interface, and the model deployment interface. In this way, the model wrapper helps model providers to focus on disciplinary knowledge of a model, and to pass it to model users.
This paper analyzes the characteristics and operating mechanism of SWMM and encapsulates SWMM according to the model encapsulation standard. First, the model description language (MDL) file [47,48], which consists of summary of the model and detailed description of three interfaces, is used to describe the model. Then, the model encapsulation code is written to encapsulate the model. The process is as follows: 1. In the MDL file, the ModelClass node is used to summarize the SWMM service. In this node, the name (the name of the model service), uid (the GUID used to distinguish the model service), and style (the style of the model service, which is a simple calculation model service for SWMM) are specified. An example is shown in Figure 2.

Encapsulating and Packaging SWMM
In order to shield the differences in multi-source heterogeneous geographic data, encapsulate the model, and publish it as a web service, some organizations have proposed solutions. For example, web map service (WMS), web feature service (WFS), and web process service (WPS), proposed by open geospatial consortium (OGC), provide a spatial data interoperability specification based on web service. However, these methods are generally limited to spatial data processing, which means they are not suitable for describing the semantic information of model input and output.
Geographic model encapsulation proposed by this paper follows a set of defined protocols and methods. The geographic model is encapsulated into an executable program or script with standard forms and behavioral features to shield the complexity and heterogeneity of the model. The geo-modeling encapsulation standard defines three basic interfaces for encapsulating geographic models: the model description interface, the model execution interface, and the model deployment interface. In this way, the model wrapper helps model providers to focus on disciplinary knowledge of a model, and to pass it to model users.
This paper analyzes the characteristics and operating mechanism of SWMM and encapsulates SWMM according to the model encapsulation standard. First, the model description language (MDL) file [47,48], which consists of summary of the model and detailed description of three interfaces, is used to describe the model. Then, the model encapsulation code is written to encapsulate the model. The process is as follows: 1.
In the MDL file, the ModelClass node is used to summarize the SWMM service. In this node, the name (the name of the model service), uid (the GUID used to distinguish the model service), and style (the style of the model service, which is a simple calculation model service for SWMM) are specified. An example is shown in Figure 2.

Encapsulating and Packaging SWMM
In order to shield the differences in multi-source heterogeneous geographic data, encapsulate the model, and publish it as a web service, some organizations have proposed solutions. For example, web map service (WMS), web feature service (WFS), and web process service (WPS), proposed by open geospatial consortium (OGC), provide a spatial data interoperability specification based on web service. However, these methods are generally limited to spatial data processing, which means they are not suitable for describing the semantic information of model input and output.
Geographic model encapsulation proposed by this paper follows a set of defined protocols and methods. The geographic model is encapsulated into an executable program or script with standard forms and behavioral features to shield the complexity and heterogeneity of the model. The geo-modeling encapsulation standard defines three basic interfaces for encapsulating geographic models: the model description interface, the model execution interface, and the model deployment interface. In this way, the model wrapper helps model providers to focus on disciplinary knowledge of a model, and to pass it to model users.
This paper analyzes the characteristics and operating mechanism of SWMM and encapsulates SWMM according to the model encapsulation standard. First, the model description language (MDL) file [47,48], which consists of summary of the model and detailed description of three interfaces, is used to describe the model. Then, the model encapsulation code is written to encapsulate the model. The process is as follows: 1. In the MDL file, the ModelClass node is used to summarize the SWMM service. In this node, the name (the name of the model service), uid (the GUID used to distinguish the model service), and style (the style of the model service, which is a simple calculation model service for SWMM) are specified. An example is shown in Figure 2.
<ModelClass name="SWMM" uid="cf6a71b2-6bc7-42a5-9317-77249e38f3e3" style="SimpleCalculation">  The model description interface is implemented by describing the categories and related concepts of SWMM in the AttributeSet node of the MDL file. In the category subnode, the path attributes are specified to describe where the model is located in the classification system. LocalAttributes subnode assigns local language (the language used to describe this node), localName (the name of the model described in local language), and wiki (the url associated with SWMM, such as the address of the introduction entry for SWMM on the OpenGMS platform) attributes. Keywords subnode lists the keywords for the model, and Abstract subnode gives a brief introduction of the model. An example is shown in Figure 3. 2. The model description interface is implemented by describing the categories and related concepts of SWMM in the AttributeSet node of the MDL file. In the category subnode, the path attributes are specified to describe where the model is located in the classification system. LocalAttributes subnode assigns local language (the language used to describe this node), localName (the name of the model described in local language), and wiki (the url associated with SWMM, such as the address of the introduction entry for SWMM on the OpenGMS platform) attributes. Keywords subnode lists the keywords for the model, and Abstract subnode gives a brief introduction of the model. An example is shown in Figure  3.  3. The model execution interface is described in the behavior node of the MDL and programmed to implement the interface. First, the input, output, and execution behavior of SWMM are analyzed and described in the StateGroup node of the MDL file: (1) The state subnode abstracts and describes the entire execution process of the SWMM program as a behavior. In this subnode, the id (uniquely identifies the execution behavior), name (name of the execution behavior), and description (description of model execution behavior) attributes are specified; (2) The behavior of the model request input data (.inp format data) and output result data (.rpt and .out format data) are abstracted into three events and described in three event subnodes. The three event subnodes specify the type (the input data is response, and the output data is noresponse) and optional (whether the data are optional) attributes. The rest of the properties are similar to those in the state subnode. An example is shown in Figure  4.

3.
The model execution interface is described in the behavior node of the MDL and programmed to implement the interface. First, the input, output, and execution behavior of SWMM are analyzed and described in the StateGroup node of the MDL file: (1) The state subnode abstracts and describes the entire execution process of the SWMM program as a behavior. In this subnode, the id (uniquely identifies the execution behavior), name (name of the execution behavior), and description (description of model execution behavior) attributes are specified; (2) The behavior of the model request input data (.inp format data) and output result data (.rpt and .out format data) are abstracted into three events and described in three event subnodes. The three event subnodes specify the type (the input data is response, and the output data is noresponse) and optional (whether the data are optional) attributes. The rest of the properties are similar to those in the state subnode. An example is shown in Figure 4. <State id="9949226b-958f-453f-8bc4-a8a03246d412" name="SwmmModel" type="basic" description="SWMM Model Running State"> <Event name="inpData" type="response" optional="False" description="Input inpData file"> <ResponseParameter datasetReference="inpData" description="Load" /> </Event> <Event name="rptData" type="noresponse" optional="False" description="Output rptData file"> <DispatchParameter datasetReference="rptData" description="Export" /> </Event> <Event name="outData" type="noresponse" optional="False" description="Output outData file"> <DispatchParameter datasetReference="outData" description="Export" /> </Event> Then, the model encapsulation code is written on the basis of the C# language: the path of the model input data (.inp format data) and the output data (.rpt and .out format data) is used as the command line parameter, and the swmm5.exe will be invoked by the command to drive the model to execute the original computing behavior. According to the description of the MDL file, the original behavior of the model is mapped to a standardized behavior by the model encapsulation SDK, thereby encapsulating the original model into a model with a standardized interface. The encapsulation code of the model execution interface is shown in Figure 5. Then, the model encapsulation code is written on the basis of the C# language: the path of the model input data (.inp format data) and the output data (.rpt and .out format data) is used as the command line parameter, and the swmm5.exe will be invoked by the command to drive the model to execute the original computing behavior. According to the description of the MDL file, the original behavior of the model is mapped to a standardized behavior by the model encapsulation SDK, thereby encapsulating the original model into a model with a standardized interface. The encapsulation code of the model execution interface is shown in Figure 5.   The Runtime node of the MDL file describes the SWMM deployment interface: (1) The name attribute indicates the name of the runtime environment, the baseDir attribute, and the entry attribute express the path (for example, $(ModelServicePath)\model\) and name (for example, SwmmModel.exe) of the executable program formed by encapsulation code, and the version attribute expresses the version number of this model package (for example, Version 1.0).
(2) The HardwareConfigures subnode expresses the hardware environment on which the model execution depends. For example, the memory size is 500 M, the disk space is 1 G, etc.
(3) The SoftwareConfigures subnode describes the software environment information that the model runs depend on. For example, the running platform is Windows. The description of the SWMM deployment interface in the MDL is shown in Figure 6. 4. The Runtime node of the MDL file describes the SWMM deployment interface: (1) The name attribute indicates the name of the runtime environment, the baseDir attribute, and the entry attribute express the path (for example, $(ModelServicePath)\model\) and name (for example, SwmmModel.exe) of the executable program formed by encapsulation code, and the version attribute expresses the version number of this model package (for example, Version 1.0).
(2) The HardwareConfigures subnode expresses the hardware environment on which the model execution depends. For example, the memory size is 500 M, the disk space is 1 G, etc.
(3) The SoftwareConfigures subnode describes the software environment information that the model runs depend on. For example, the running platform is Windows.
The description of the SWMM deployment interface in the MDL is shown in Figure 6. After the description and encapsulation of the model are completed, the dependency folder (assembly), encapsulation folder (model), support folder (supportive), and test folder (testify) are packaged into a model deployment package. The dependency folder generally contains model-encapsulated dependencies (SWMM just involve a simple dependency (swmm5.dll), so this dependency is put in the encapsulation folder, and the assembly folder is After the description and encapsulation of the model are completed, the dependency folder (assembly), encapsulation folder (model), support folder (supportive), and test folder (testify) are packaged into a model deployment package. The dependency folder generally contains model-encapsulated dependencies (SWMM just involve a simple dependency (swmm5.dll), so this dependency is put in the encapsulation folder, and the assembly folder is empty. However, some models need more complex dependencies that can be placed in the assembly folder). The encapsulation folder also contains some model encapsulation files, such as the model files (swmm5.exe), the executable program formed by encapsulation code, and its dependent dynamic link library (nxdat.csharp.dll and nxmodel.context.csharp.dll) and model description files (MDL files). The support folder contains the runtime environment dependencies of the model encapsulation (for example, the C# program runs depend on the Microsoft .NET Framework). The default folder in the testify folder stores model test data and its configuration files. The license.txt file describes the model copyright information. The SWMM deployment package is shown in Figure 7.
as the model files (swmm5.exe), the executable program formed by encapsulation code, and its dependent dynamic link library (nxdat.csharp.dll and nxmodel.context.csharp.dll) and model description files (MDL files). The support folder contains the runtime environment dependencies of the model encapsulation (for example, the C# program runs depend on the Microsoft .NET Framework). The default folder in the testify folder stores model test data and its configuration files. The license.txt file describes the model copyright information. The SWMM deployment package is shown in Figure 7.

Model Deployment and Service Publishment
The model service wrapper is a carrier to share the geographic model as a service in a network environment. Based on the geographic model deployment strategy, SWMM is deployed to the existing model service wrappers and published as model services in cyberspace.
First, suitable model service wrappers are found through the OpenGMS portal. The method to find suitable wrappers is to match the software and hardware environment of the model service wrapper according to the running dependencies of SWMM described in the MDL (for example, the operating system needed to run SWMM is Windows, the running memory is at least 500 M, and the hard disk space is at least 1 G), as shown in Figure 8(a). After the suitable model service wrappers are found, the SWMM deployment package can be uploaded to these wrappers. In these wrappers, the package of SWMM deployment package can be published as services, as shown in Figure 8(b). After being published, the SWMM model service is in a state that can be invoked as shown in Figure 8(c). Finally, the model item is created by extracting the information of SWMM from the MDL. The SWMM services can be bound with the model item and registered into the portal, and the user thus can easily query the model service, as shown in Figure 8(d). In addition, when a model service wrapper fails to work properly, the model service can be easily migrated to another model service wrapper in the network environment by automatically copying the model deployment package to other model service wrappers.

Model Deployment and Service Publishment
The model service wrapper is a carrier to share the geographic model as a service in a network environment. Based on the geographic model deployment strategy, SWMM is deployed to the existing model service wrappers and published as model services in cyberspace. First, suitable model service wrappers are found through the OpenGMS portal. The method to find suitable wrappers is to match the software and hardware environment of the model service wrapper according to the running dependencies of SWMM described in the MDL (for example, the operating system needed to run SWMM is Windows, the running memory is at least 500 M, and the hard disk space is at least 1 G), as shown in Figure 8a. After the suitable model service wrappers are found, the SWMM deployment package can be uploaded to these wrappers. In these wrappers, the package of SWMM deployment package can be published as services, as shown in Figure 8b. After being published, the SWMM model service is in a state that can be invoked as shown in Figure 8c. Finally, the model item is created by extracting the information of SWMM from the MDL. The SWMM services can be bound with the model item and registered into the portal, and the user thus can easily query the model service, as shown in Figure 8d. In addition, when a model service wrapper fails to work properly, the model service can be easily migrated to another model service wrapper in the network environment by automatically copying the model deployment package to other model service wrappers.

Web-SWMM Data Preparation Method
After SWMM is encapsulated and deployed, service sharing of the model in the network environment is implemented. However, the correct operation of SWMM in the network environment still requires the driving of relevant data. When the user has the raw input data of SWMM, the raw data can be directly used to drive the model operation, but since the user does not have the raw input data, supporting the user to quickly configure the data required by SWMM or accessing the existing data resources in the network environment are the focus of this section.
To design an online preparation method for SWMM data, a general data expression model that can clearly express complex geographic data in a network environment must be provided. The UDX model is a flexible data description model that provides solutions for heterogeneous

Web-SWMM Data Preparation Method
After SWMM is encapsulated and deployed, service sharing of the model in the network environment is implemented. However, the correct operation of SWMM in the network environment still requires the driving of relevant data. When the user has the raw input data of SWMM, the raw data can be directly used to drive the model operation, but since the user does not have the raw input data, supporting the user to quickly configure the data required by SWMM or accessing the existing data resources in the network environment are the focus of this section.
To design an online preparation method for SWMM data, a general data expression model that can clearly express complex geographic data in a network environment must be provided. The UDX model is a flexible data description model that provides solutions for heterogeneous geographic model data representation. Compared with the raw data format of SWMM, UDX can clearly express the structure and semantics of data, and the user can easily understand the SWMM input data and output data according to the UDX description, which lays a foundation for data preparation.
The UDX model consists of two basic structures: UDX schema is used to describe model data in a structured way; UDX data is used to organize and store the data content of the model. This paper uses UDX schema to clearly express the SWMM input data and build an online data editing tool that is convenient for the user to create UDX data online or configure real-time data resources in the network accordingly. Corresponding data conversion algorithm is designed to convert the user-provided UDX data into raw input data (.inp format data). At the same time, UDX schema is used to express the SWMM output data. The raw output data (.rpt format data) can be converted into online UDX data to facilitate the user in understanding the model calculation results.

UDX Preparation of the SWMM Data
SWMM input data consist of several modules such as subcatchments, junctions, conduits, storages, and raingages, and they include their corresponding attributes. For instance, the subcatchments module involves attributes for name, raingage, outlet, and area.
UdxNode is an element designed to express the hierarchy of the UDX Schema. UdxNode is used to express the raw input data format of the SUBCATCHMENTS module in the following example. This process is shown in Figure 9.
First, UdxNode (subcatchments) is used by setting the type to DTKT_LIST(the list type data) to describe the [SUBCATCHMENTS] module in the raw data. Second, in the child level of subcatchments UdxNode, UdxNode (columns) is put to use by setting the type to DTKT_ANY (this type contains many data types) to represent all columns in the raw data module. Further, some UdxNodes are used by specifying types to DTKT_STRING and DTKT_REAL at the child level of columns UdxNode to express the specific data type in the row.
In this way, the hierarchy of the raw output data is also expressed by the UDX schema. geographic model data representation. Compared with the raw data format of SWMM, UDX can clearly express the structure and semantics of data, and the user can easily understand the SWMM input data and output data according to the UDX description, which lays a foundation for data preparation. The UDX model consists of two basic structures: UDX schema is used to describe model data in a structured way; UDX data is used to organize and store the data content of the model. This paper uses UDX schema to clearly express the SWMM input data and build an online data editing tool that is convenient for the user to create UDX data online or configure real-time data resources in the network accordingly. Corresponding data conversion algorithm is designed to convert the user-provided UDX data into raw input data (.inp format data). At the same time, UDX schema is used to express the SWMM output data. The raw output data (.rpt format data) can be converted into online UDX data to facilitate the user in understanding the model calculation results.

UDX Preparation of the SWMM Data
SWMM input data consist of several modules such as subcatchments, junctions, conduits, storages, and raingages, and they include their corresponding attributes. For instance, the subcatchments module involves attributes for name, raingage, outlet, and area.
UdxNode is an element designed to express the hierarchy of the UDX Schema. UdxNode is used to express the raw input data format of the SUBCATCHMENTS module in the following example. This process is shown in Figure 9.
First, UdxNode (subcatchments) is used by setting the type to DTKT_LIST(the list type data) to describe the [SUBCATCHMENTS] module in the raw data. Second, in the child level of subcatchments UdxNode, UdxNode (columns) is put to use by setting the type to DTKT_ANY (this type contains many data types) to represent all columns in the raw data module. Further, some UdxNodes are used by specifying types to DTKT_STRING and DTKT_REAL at the child level of columns UdxNode to express the specific data type in the row.
In this way, the hierarchy of the raw output data is also expressed by the UDX schema.

Conversion of UDX Data and SWMM Raw Data
A method of conversion between UDX data and SWMM raw data (.inp format data and .rpt format data) needs to be provided so that not only the user can configure the UDX-based input data to be read by SWMM but also a UDX-based online data visualization tool can be

Conversion of UDX Data and SWMM Raw Data
A method of conversion between UDX data and SWMM raw data (.inp format data and .rpt format data) needs to be provided so that not only the user can configure the UDX-based input data to be read by SWMM but also a UDX-based online data visualization tool can be built for the output data. This conversion method is published on the data service container [48], which was designed by OpenGMS group to enable sharing and reuse of the proposed method over distributed networks.
The Java language is used to read the input data configured by the user according to the UDX format, and the method to convert the UDX data to the raw format data of SWMM is constructed according to the correspondence between the nodes in the UDX data and the modules in the raw format data. In the UDX data, XDO is a node designed to express the data of raw format. The user can use XDO to express the raw format data of [SUBCATCHMENTS] module in the following example. This process is shown in Figure 10.
First, the subcatchments XDO is converted to the [SUBCATCHMENTS] in the raw format data. Second, the columns XDO is converted to the columns in the raw format data (for example, name, raingage, outlet, and area).
Third, some XDOs of different types (for example, string and real) are converted into specific data in a row of the raw format data.
In this way, the raw output format data can also be converted to UDX format data. built for the output data. This conversion method is published on the data service container [48], which was designed by OpenGMS group to enable sharing and reuse of the proposed method over distributed networks. The Java language is used to read the input data configured by the user according to the UDX format, and the method to convert the UDX data to the raw format data of SWMM is constructed according to the correspondence between the nodes in the UDX data and the modules in the raw format data. In the UDX data, XDO is a node designed to express the data of raw format. The user can use XDO to express the raw format data of [SUBCATCHMENTS] module in the following example. This process is shown in Figure 10.
First, the subcatchments XDO is converted to the [SUBCATCHMENTS] in the raw format data.
Second, the columns XDO is converted to the columns in the raw format data (for example, name, raingage, outlet, and area).
Third, some XDOs of different types (for example, string and real) are converted into specific data in a row of the raw format data.
In this way, the raw output format data can also be converted to UDX format data.

Web-SWMM Online Service System
The Web-SWMM online service system consists of data module and model module. The data module includes tools such as UDX-based online input data configuration, data editing, and UDX-based output data visualization. Model module includes tools such as computing node selection, model service migration, and model control.
First, the user can configure the input data in the UDX format through the online input data configuration tool, specify the coordinate system of the Proj4js format that matches the data, and display the input data on the background of the geographic base map. Second, the data editing tool is used to view and visually edit the attribute data or model parameters of the geographic objects (such as a subcatchment or a rainwater well) in the SWMM input data. Then, available computing nodes can be selected to call the model service and drive the model for calculation. Finally, the online visualization tool of the output data can be used to visualize the model calculation results and download the output file. In addition, when the selected compute node fails to invoke the model service normally, the SWMM service can also be migrated to other suitable compute nodes through the model service migration tool.

Web-SWMM Online Service System
The Web-SWMM online service system consists of data module and model module. The data module includes tools such as UDX-based online input data configuration, data editing, and UDX-based output data visualization. Model module includes tools such as computing node selection, model service migration, and model control.
First, the user can configure the input data in the UDX format through the online input data configuration tool, specify the coordinate system of the Proj4js format that matches the data, and display the input data on the background of the geographic base map. Second, the data editing tool is used to view and visually edit the attribute data or model parameters of the geographic objects (such as a subcatchment or a rainwater well) in the SWMM input data. Then, available computing nodes can be selected to call the model service and drive the model for calculation. Finally, the online visualization tool of the output data can be used to visualize the model calculation results and download the output file. In addition, when the selected compute node fails to invoke the model service normally, the SWMM service can also be migrated to other suitable compute nodes through the model service migration tool.

UDX-Based Online Input Data Configuration Tool
SWMM input data are generally prepared through different approaches, which are complex and time consuming processes (e.g., converting ESRI shapefile data to SWMM input data). An online data configuration tool is developed to efficiently prepare SWMM input data based on the data expression method mentioned above. The user can conveniently create UDX input data online according to the UDX schema, upload input data in UDX format or configure real-time data resources according to the UDX format in the network, and then convert it into SWMM raw input data as the driving data of the model. The data configuration tool is shown in Figure 11. 4.1.1. UDX-Based Online Input Data Configuration Tool SWMM input data are generally prepared through different approaches, which are complex and time consuming processes (e.g., converting ESRI shapefile data to SWMM input data). An online data configuration tool is developed to efficiently prepare SWMM input data based on the data expression method mentioned above. The user can conveniently create UDX input data online according to the UDX schema, upload input data in UDX format or configure real-time data resources according to the UDX format in the network, and then convert it into SWMM raw input data as the driving data of the model. The data configuration tool is shown in Figure 11. Figure 11. UDX-based online data configuration tool.

Data Editing Tool
When performing interactive editing of data, the binding and linkage between the geographic object and the attribute information in the input data are implemented, and the attribute data in the input data provided by the user is displayed in the data editing tool. The user is allowed to edit the attribute data of the geographic object in the attribute editing tool, as shown in Figure 12; the parameters required for the model to run can be set in the parameter setting tool, as shown in Figure 13. In addition, threshold control on the parameters of SWMM5 is performed to ensure the validity of data. For example, the user is allowed to specify the infiltration model as one of Horton model, modified Horton model, green ampt model, and curve number model.

Data Editing Tool
When performing interactive editing of data, the binding and linkage between the geographic object and the attribute information in the input data are implemented, and the attribute data in the input data provided by the user is displayed in the data editing tool. The user is allowed to edit the attribute data of the geographic object in the attribute editing tool, as shown in Figure 12; the parameters required for the model to run can be set in the parameter setting tool, as shown in Figure 13. In addition, threshold control on the parameters of SWMM5 is performed to ensure the validity of data. For example, the user is allowed to specify the infiltration model as one of Horton model, modified Horton model, green ampt model, and curve number model.

Data Visualization Tool
Data visualization is divided into input data visualization and output data visualization. 1. To visualize the input data, the input data should be displayed on the geographic base map firstly. When building a base map, the OpenLayers front-end map service framework is used to load map service resources published by Open Street Map. Then, the display center of the map is specified by the coordinate range extracted from the geographic data and the projection coordinate system of the Proj4js format is assigned by the user. Finally, the OpenLayers vector map loading interface is used to accurately overlay the geographic data of the input data stream onto the geographic base map. The visualization of the input data is shown in Figure 14.

Data Visualization Tool
Data visualization is divided into input data visualization and output data visualization.

1.
To visualize the input data, the input data should be displayed on the geographic base map firstly. When building a base map, the OpenLayers front-end map service framework is used to load map service resources published by Open Street Map. Then, the display center of the map is specified by the coordinate range extracted from the geographic data and the projection coordinate system of the Proj4js format is assigned by the user. Finally, the OpenLayers vector map loading interface is used to accurately overlay the geographic data of the input data stream onto the geographic base map. The visualization of the input data is shown in Figure 14. 2. To visualize the output data, based on the conversion method between the output data (specifically, the data in the .rpt file) and the UDX data mentioned above, the SWMM output data is converted into the UDX format. The UDX-based output data visualization tool is built. The nodes in the UDX schema are selected as the X-axis and Y-axis in the visualization chart to visualize the SWMM output data, as shown in Figure 15.

2.
To visualize the output data, based on the conversion method between the output data (specifically, the data in the .rpt file) and the UDX data mentioned above, the SWMM output data is converted into the UDX format. The UDX-based output data visualization tool is built. The nodes in the UDX schema are selected as the X-axis and Y-axis in the visualization chart to visualize the SWMM output data, as shown in Figure 15. Figure 14. Input data visualization.
2. To visualize the output data, based on the conversion method between the output data (specifically, the data in the .rpt file) and the UDX data mentioned above, the SWMM output data is converted into the UDX format. The UDX-based output data visualization tool is built. The nodes in the UDX schema are selected as the X-axis and Y-axis in the visualization chart to visualize the SWMM output data, as shown in Figure 15. Figure 15. Output data visualization tool.

Computing Node Selection
When building the computing node selection function, the SWMM deployment package is deployed on several matched model service wrappers, the computing node information is

Computing Node Selection
When building the computing node selection function, the SWMM deployment package is deployed on several matched model service wrappers, the computing node information is displayed, and the user can select a computing node. The corresponding model service is invoked according to the SWMM computing node selected by the user, as shown in Figure 16. displayed, and the user can select a computing node. The corresponding model service is invoked according to the SWMM computing node selected by the user, as shown in Figure 16.

Model Service Migration
The model service migration tool is built on the basis of the model service wrapper. According to the software and hardware environment information in the MDL and the software and hardware information of the existing service nodes (SWMM has not been deployed on these nodes) in the network environment, the matching service nodes are listed. By automatically copying a model deployment package among different model service

Model Service Migration
The model service migration tool is built on the basis of the model service wrapper. According to the software and hardware environment information in the MDL and the software and hardware information of the existing service nodes (SWMM has not been deployed on these nodes) in the network environment, the matching service nodes are listed. By automatically copying a model deployment package among different model service wrappers, the user can conveniently use the model service migration tool to directly migrate the SWMM service from one server to another, as shown in Figure 17.

Model Service Migration
The model service migration tool is built on the basis of the model service wrapper. According to the software and hardware environment information in the MDL and the software and hardware information of the existing service nodes (SWMM has not been deployed on these nodes) in the network environment, the matching service nodes are listed. By automatically copying a model deployment package among different model service wrappers，the user can conveniently use the model service migration tool to directly migrate the SWMM service from one server to another, as shown in Figure 17.

Model Control
Calling and controlling the deployed SWMM on the model service wrapper based on the relevant interface of the model service wrapper are performed as follows: the model data is sent to the model call interface, the call of the model service is implemented to drive the SWMM operation, and the model control interface of the model service wrapper is invoked to

Model Control
Calling and controlling the deployed SWMM on the model service wrapper based on the relevant interface of the model service wrapper are performed as follows: the model data is sent to the model call interface, the call of the model service is implemented to drive the SWMM operation, and the model control interface of the model service wrapper is invoked to implement pause and resume while running the model. In addition, because the model service wrapper is executed in an isolated process, the user can run multiple instances of SWMM in the same computing node.

Prototype Implementation and Experimental Study
This paper implements the web-based SWMM service method. The prototype implementation of Web-SWMM involves two parts. First, the implementation uses Java language as the back-end language. Second, JavaScript and html5 are used as the front-end language to construct the web page of the implementation to interact with the user. In addition, the communication between the front and back ends follows HTTP protocol and the RESTful style API.
Based on the prototype implementation, the practicability of the Web-SWMM system proposed in this paper is verified using the rainwater flood simulation in the Suzhou Meisong Garden Community. The experimental steps are as follows: 1.
The basic geographic data of the Meisong Garden Community is collected and processed, and the rainwater wells (1~108) are numbered. Using the rainwater well as the center, combining the topography factors and taking into account the water-proof effect of the building, the experimental area is divided into 84 subcatchments. In addition, the geographic data and related attribute data are organized into the input data of the UDX format required by the Web-SWMM system, using the UDX-based online data configuration tool.

2.
According to the rain experience formula of the Suzhou region, the Chicago rain type generator is used to simulate a heavy rain, with a return period of 2 years and a rainfall duration of 2 h, and the rainfall sequence is integrated into the UDX input file. 3.
The coordinate system information is obtained from the metadata, and the coordinate system information of the Proj4js format is entered into the coordinate system input box of the Web-SWMM system to ensure that the data is loaded to the exact position on the map. 4.
Uploading the input data in the UDX format through the upload button of the Web-SWMM page, the data on the geographic base map can be browsed. By editing the input data through the data editor, the unreasonable attribute values can be modified. In addition, the required parameters is set by the parameter setting tool (such as simulation start and end time and time step). This process is shown in Figure 18.
proposed in this paper is verified using the rainwater flood simulation in the Suzhou Meisong Garden Community. The experimental steps are as follows: 1. The basic geographic data of the Meisong Garden Community is collected and processed, and the rainwater wells (1~108) are numbered. Using the rainwater well as the center, combining the topography factors and taking into account the water-proof effect of the building, the experimental area is divided into 84 subcatchments. In addition, the geographic data and related attribute data are organized into the input data of the UDX format required by the Web-SWMM system, using the UDX-based online data configuration tool. 2. According to the rain experience formula of the Suzhou region, the Chicago rain type generator is used to simulate a heavy rain, with a return period of 2 years and a rainfall duration of 2 hours, and the rainfall sequence is integrated into the UDX input file. 3. The coordinate system information is obtained from the metadata, and the coordinate system information of the Proj4js format is entered into the coordinate system input box of the Web-SWMM system to ensure that the data is loaded to the exact position on the map. 4. Uploading the input data in the UDX format through the upload button of the Web-SWMM page, the data on the geographic base map can be browsed. By editing the input data through the data editor, the unreasonable attribute values can be modified. In addition, the required parameters is set by the parameter setting tool (such as simulation start and end time and time step). This process is shown in Figure 18.

5.
After browsing and modifying the data, by clicking the model calculation button, a suitable computing node is selected and the model service published by the model service wrapper is called to calculate; then, the calculation result is sent back. The visualization button is clicked to visualize the .rpt file online, and the download button is clicked to download the .rpt file and .out file to the local. As shown in Figure 19, (a) is an online visualization of the conduits' max depth in the output data and (b) is an online visualization of the nodes' max depth in the output data.
computing node is selected and the model service published by the model service wrapper is called to calculate; then, the calculation result is sent back. The visualization button is clicked to visualize the .rpt file online, and the download button is clicked to download the .rpt file and .out file to the local. As shown in Figure 19, (a) is an online visualization of the conduits' max depth in the output data and (b) is an online visualization of the nodes' max depth in the output data. The visual results show that in heavy rain with a return period of 2 years and a rainfall period of 2 hours, the No. 96 and No. 102 rainwater wells in the Meisong Garden Community will overflow, and the drainage capacity of the No. 80 underground conduit will exceed the maximum limit.

Conclusion and Future Work
This paper implements the web-based SWMM service method to construct the Web-SWMM system. Compared with other methods, the approach proposed by this paper provides a systematical, fast, and extensible solution to implement sharing and reuse of SWMM in a The visual results show that in heavy rain with a return period of 2 years and a rainfall period of 2 h, the No. 96 and No. 102 rainwater wells in the Meisong Garden Community will overflow, and the drainage capacity of the No. 80 underground conduit will exceed the maximum limit.

Conclusion and Future Work
This paper implements the web-based SWMM service method to construct the Web-SWMM system. Compared with other methods, the approach proposed by this paper provides a systematical, fast, and extensible solution to implement sharing and reuse of SWMM in a network environment. This system enables the user to configure the SWMM input data online or use online real-time data, visually edit model data and parameters, call model calculations, visualize calculation results, and download model output files through the browser. There is no need to download and install SWMM. The use cost of SWMM is reduced, and the use and sharing of SWMM are promoted. However, this study still has some shortcomings. In future research, this study needs to be improved in the following respects:

1.
This paper adopts manual programming to implement the packaging of SWMM. In the future, an automated model encapsulating and packaging tool should be built to reduce the labor cost and technical threshold of encapsulating the model.

2.
The data preprocessing function should be enhanced to provide a richer UDX online data configuration tool, such as providing a real-time online rainfall data format to UDX format online conversion tool, so that the user no longer needs to carry out complicated data preparation and preprocessing work, which would make it convenient to use SWMM to perform real-time rainfall-flood simulation and master the simulation results in real time.

3.
The web service mode of SWMM should be extended to additional hydrological models to form a hydrological model service theme, which would more effectively promote the sharing and use of hydrological models.