KR100982732B1 - Xforms based automated client-page composition system and the client-page composition method - Google Patents

Abstract

PURPOSE: An XForms based automated client-page composition system and a client-page composition method thereof are provided to generate an XForms based client pages on the basis of analyzed contents. CONSTITUTION: A data model generating unit(322) generates a data model for storing an input parameter and result data, and a submission generating unit(324) generates a submission element of which data model position is designated for each method of a service specification. A data path, an input media variable and result data which are referred by a view corresponding to the method are stored at the data model position. A view generating unit(326) uses plural views extracted from the service specification analysis unit and a view flow of the analysis to create a client page in an XForms code.

Description

XForms based automated client-page composition system and the client-page composition method}

The present invention relates to a system for automatically generating a client page based on XForms and a method for automatically generating a client page, and more particularly, to generate a client page providing multiple services in one screen by combining various web services. Schema parsing service specification to derive the type relationship diagram between each service specification, and based on the derived type relationship diagram, extracts a plurality of views that can be provided from each service specification, the view flow diagram between the extracted views XForms-based client page generation system and client page automatic generation that can provide connection and view movement between multiple services in REST-based dynamic service environment by generating It is about a method.

Web services are a service-oriented distributed computing technology, a software system for interacting between different computers on a network. The web service protocol stack consists of XML-RPC, SOAP, UDDI, WSDL, and so on. Web services over SOAP, which can be called an extension or evolution of XML-RPC, were popular because they were platform-independent and easy to acquire because they were XML message-based protocols.

Since the emergence of SOAP, open web services have appeared, but since there was no standardized technical method, it was necessary to refer to each service description in order to use it. Therefore, a standard for describing an interface is needed, and accordingly, an XML-based WSDL has emerged. In addition, with the proliferation of Web 2.0 in 2003, REST (Representational State Transfer) web service has emerged, which actively utilizes the basic functions of HTTP such as GET and POST, and also supports the transmission of messages in XML format.

As REST web services have been in the spotlight among developers, various methods for describing the interface of REST web services have begun to be proposed. Although there are many languages for describing REST API, the mainstream has not been formed yet. Existing WSDL was extended to describe REST as well as SOAP in 2.0, but it is not used much because of the complexity. Sun Microsystems released a simple yet versatile Web Application Description Language (WADL).

WADL is an XML-based file format that provides machine-readable technology for HTTP-based web applications. It is platform and language independent and aims to increase application reusability. WADL can model the resources provided by services and the relationships between them, and is useful for developers who deploy and use REST web services by automatically generating stub / skeleton code.

However, in the case of WADL, there is no tool that automatically generates client code by analyzing WADL documents like WSDL. Therefore, developers have to write their own server and client code. It has been a serious obstacle to providing better services.

In particular, a client page of a user interface (UI) providing a combination of various web services should have a code for moving a view or calling the next service. In particular, in a mobile environment, a client application having multiple views moves or moves between views. While the calling order must be able to be expressed, WADL has been inconvenient for developers because it does not yet have the technology to automatically generate the client page code of the web service assembly user interface.

 The present invention is to solve the above problems according to the prior art. That is, an object of the present invention is to generate a client page that provides multiple services on one screen by combining various web services, schema parsing WADL-based service specification to derive a type relationship diagram between each service specification, After extracting a plurality of views that can be provided from each service specification based on the derived type relationship diagram, the view flow diagram between the extracted views is derived, and an XForms-based client page is generated based on the analyzed contents. It provides XForms-based client page automatic generation system and client page automatic generation method that can provide connection and view movement between multiple services in dynamic service based environment.

As a technical idea for achieving the above object, the present invention analyzes the data types defined in the selected service specification using a schema parser, and derives a type relationship diagram by analyzing the inclusion relations between the data types. Based on the type relationship diagram derived from the analysis unit and the data type analysis unit, a list of views to be displayed in the selected service specification is extracted using a WADL parser, and a flow between a plurality of views included in the extracted list. A service specification analysis unit for deriving a view flow diagram by analyzing the data, a data model generation unit for generating a data model for storing input parameters and result data, and a method of data referenced by a view corresponding to a method for each method of the service specification. Sub with the path and input parameters and the data model location where the result data will be stored Submission generation unit for generating option elements, View generation unit for generating a client page that can call the method and view movement using XForms code using a plurality of views extracted from the service specification analysis unit and the corresponding view flow diagram It provides XForms-based client page automatic generation system.

The present invention also provides a method for receiving a service specification selected by the user from a server storing the service specification list, analyzing a data type defined in a selected service specification using a schema parser, and including a relationship between data types. Extracting a list of views that require display from the selected service specification by using a WADL parser, based on the derived type relationship diagram, Analyzing the flow between the included Dash dog views, deriving a view flow chart, generating a data model for storing input parameters and result data, and a view corresponding to a method for each method of the service specification The path and input parameters of the data to be stored and the data model location where the result data will be stored. Generating a submission element, and using the extracted plurality of views and the corresponding view flow diagram, generating a client page in XForms code capable of calling a method and moving a view through information specified in the submission element. It provides XForms-based client page automatic generation method that is configured to include.

The XForms-based automatic client page generation system and client page automatic generation method according to the present invention support a user to easily develop a multi-service device connecting various services in a REST-based dynamic service environment. By automatically generating client page code that had to be written by hand, developers can create more services and provide them faster.

In addition, the service description based on WADL is registered and provided at the same time, it is very useful in the web environment, and multiple web services that create new services by combining several services are attracting attention as an important software architecture. It is expected to provide a foundational technology that can increase productivity and improve developer convenience of multi-web service software development.

1 is a schematic configuration diagram of a system for automatically generating a client page according to an embodiment of the present invention.
FIG. 2 is a block diagram showing the internal structure of the automatic client page generation system shown in FIG.
3 is an example of a method diagram in accordance with one embodiment of the present invention.
4 is an example illustrating a method call relationship in a view according to an embodiment of the present invention.
5 is an example illustrating a movement relationship from a current view to another view according to an embodiment of the present invention.
6 is a flowchart illustrating a method of automatically generating a client page according to an embodiment of the present invention.
7 is an example of a service description according to one embodiment of the invention.
8 is an example of a type relationship diagram according to an embodiment of the present invention.
9 is an example in which a method call relationship in a view is analyzed between service descriptions according to an embodiment of the present invention.
10 is an example in which a movement relationship to another view is analyzed between service descriptions according to an embodiment of the present invention.
11 is an example in which a regional data model code is generated in the service description shown in FIG. 7;
12 is an example in which a submission code is generated in the service description shown in FIG.
FIG. 13 illustrates an example in which a view code is generated in the service specification illustrated in FIG. 7.
14 is an example in which code for a service method call is generated in the service specification shown in FIG. 7;
15 is an example in which code for moving to another view is generated in the service description shown in FIG. 7;
FIG. 16 illustrates an example of a service specification list provided by a service specification list providing server according to an embodiment of the present invention, and a screen for allowing a user to select a service specification accordingly. FIG.
17 illustrates an example in which an XForms-based client page is generated according to an embodiment of the present invention.
18 is an example in which an XForms-based client page is generated according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a schematic diagram of a system for automatically generating a client page according to an embodiment of the present invention.

As shown in FIG. 1, the automatic client page generation system 300 of the present invention is connected to the client terminal 400 and the service specification list providing server 200 through a wired / wireless internet network, and the user is connected to the client terminal ( When the request is made by selecting the desired service specification from the service specification list provided by the server 200 through 400, the client page automatic generation system 300 analyzes the service specification selected by the user, and the service selected by the user. Automatically creates and provides XForms-based client pages that can be connected and moved between views.

Service specification list providing server 200 is connected to a plurality of service providers 100 provides a service list list based on WADL, which is a set of all services shared on the web, and when a new service appears on the web, the service specification is immediately provided. Registration provides the user with all the services available at that time in real time.

The client page automatic generation system 300 analyzes the requested service specification when the user selects and requests a desired service specification from the WADL-based service specification list provided by the service specification list providing server 200, and analyzes the requested service specification. Automatically creates and provides XForms-based client pages that can be connected and moved between views. To this end, the client page automatic generation system 300, through the schema parsing of the service specifications selected by the user to derive a type relationship diagram between each service specification, based on the derived type relationship diagram a plurality of available from each service specification After extracting the two views, we derive the view flow diagram between the extracted views and create an XForms-based client page based on the analyzed contents. The detailed configuration of the client page automatic generation system 300 will be described in more detail with reference to FIG. 2.

FIG. 2 is a block diagram illustrating an internal configuration of a system for automatically generating a client page shown in FIG. 1.

As shown in FIG. 2, the automatic client page generation system according to the present invention includes an analysis unit 310 and a data model generator 322 including a data type analyzer 312, a service specification analyzer 314, The code generator 320 includes a submission generator 324 and a view generator 326.

First, the data type analyzer 312 of the analyzer 310 analyzes the data types defined in the service specification using a schema parser, and derives a type relation diagram by analyzing the inclusion relations between the data types. By default, a WADL-based service specification is defined as a set of web service methods, which are URLs containing the address and name to call, and input parameter types represented as element names defined in an XML Schema. And result types. Accordingly, the data types of the service specification have inclusion relations with each other by XML schema structure definition, and this inclusion relation enables analysis of the relationship between methods.

The data type analysis unit 312 according to an embodiment of the present invention analyzes an inclusion relationship between data types of a service specification by using an ancestor and descendant relationship on an XML schema, and a type relationship diagram defined by an ancestor and descendant relationship on a schema. To derive

The service specification analyzer 314 extracts a list of views that are required to be displayed in the service specification by using the WADL parser based on the type relationship diagram derived from the data type analyzer 312. In addition, a flow of views is derived by analyzing flows among a plurality of views included in the extracted list.

In order to extract the list of such views, the service specification analyzer 314 first assumes input views and result views for each method included in the service specification. The input view is a view in which the user prepares and confirms parameter data to be sent to the server, and the result view is a view for showing the reply from the server to the user. In this case, when the input parameter data is determined in the previous view and the method can be called immediately, the method may omit the input view, and in the case of the method having no result data, the result view may be omitted. Accordingly, by excluding the input view and the result view that can be omitted for each method, it is possible to extract a list of views that require display from the service specification.

Using the extracted list of views, the service specification analyzer 314 analyzes the flow between the plurality of views included in the extracted list. To analyze the flow between views, we first need to analyze the data types that the view has in terms of the view. The data type of the view includes the input type of the input view and the output type of the result view. In addition, there are data types to be transferred from the current view to other views. The movement relationship between the plurality of views included in the extracted list is analyzed based on the type relationship diagram derived by the data type analyzer 312 based on the definition of the view and the data type.

The movement relationship between views is divided into a relationship between a method call in a view and a relationship from a current view to another view. If the current view is the input view of a method or the data type of the view includes the input data type of a method, it is defined as a relation that can be called by the method in the view. A method callable method in the view allows all calls if other methods provided by the page can be called using the data contained in the current view.

For example, suppose that there is a member list view having a method as shown in FIG. 3, a list having a data type as shown in FIG. 4, and a detail view view having a user as a data type. This item, bound to the first item in the member list view, has the uid required as the input data type of the Get method, so the Get method can be called. Similarly, the detail view includes the uid as a child element of the user, so the Delete method can be called.

Also, to move from the current view to the target view, when the target view is the input view to the calling method and the input data type of the target view includes the data type of the current view, it is defined as a relation that can be moved from the current view to another view. do.

For example, as shown in FIG. 5, in the case of search and create, the user may input data starting with the empty set, so the member list view may move to the input view of search and create, and in the case of update, the existing user Since data is needed as the input view data, the data type becomes user, and the member detail view view has user as the data type, so it is possible to move to the input view of update as well as the input view of create and search.

Through the above process, the service specification analyzer 314 extracts a list of views required for display from the service specification and analyzes the flow between a plurality of views included in the extracted list to derive a view flow chart. Will be.

The data model generator 322 of the code generator 320 generates a data model for storing input parameters and result data. This data model is created through the analysis of the input type and result type of the service method specification. After creating an instance to store the input type and an instance to store the call result, the input and result types for each instance are changed. It is added as a child element.

The data model generated by the data model generator 322 may be viewed as a copy of the data required by the client. The data model may also serve as a memory for the input parameter and may be a space for storing the result data of the service call. The resulting data is stored in the data model in the form of a partial tree, which is updated when the service call returns.

The submission generator 324 generates a submission element for each method of the service specification for the callback operation technique for processing the response after receiving the connection information and the reply from the server. The submission element has a method address and name, an input element and a location and path to store the result data. The address and name of the submission element is obtained from the ID of each method and the address value to be called. In addition, a location and a path for storing the input element and the result data are obtained from the data model generated by the data model generator. As such, when a submission element is obtained, corresponding XForms code may be generated.

The view generator 326 generates an XForms code of a client page capable of calling a method and moving a view through a list of views extracted by the service specification analyzer 314 and a view flow diagram according thereto. The view generator 326 first imports the type of the view to be created as an element of the schema, and analyzes whether the view type includes an iterator for a method to create a user control of the view, and accordingly input view or result view. Create It creates XForms code for calling the service method of the view and XForms code for moving to another view.

In this case, the actual data to be handled by the view may be obtained from the submission element generated by the submission generator 324. That is, when the view is an input view, the data to be handled by the view is the same as the attribute of the input data of the submission, and when the view is the result, it is the same as the attribute of the result data. This is the location of the data that the view actually references. Each view generates XForms code for calling a method and moving to another view, which corresponds to the view flowchart generated by the service specification analyzer 314. However, in order to generate the code for calling the service method of the view and the code for moving to another view, the necessary data must be copied from the reference position data of the previous view to the reference position of the corresponding view.

Although a copy operation can be described by combining several action elements of the XForms standard, in one embodiment of the present invention, a <copy> element is newly added as a copy operation of a tree through insertion and copying of values to simplify code generation and discussion. Defined. The copy action has the form <copy ref = 'path1' value = 'pate2'/>, the ref attribute is the path of the source tree, and value is the path of the element to copy. This action is used to copy data from the resulting instance tree to the parameter tree or in the opposite direction.

6 is a flowchart illustrating a method of automatically generating a client page using a system for automatically generating a client page according to an embodiment of the present invention.

As shown in FIG. 6, a user first selects a desired service from a WADL-based service specification list provided by a service specification list providing server through a client terminal, and then requests automatic generation of a client page through a client page automatic generation system. (S612).

According to the user's request, the client page automatic generation system analyzes the data type defined in the selected service specification using the schema parser through the data type analysis unit (S614), and derives the type relationship diagram by analyzing the inclusion relationship therethrough. (S616).

For example, assuming that the service specification shown in FIG. 7 is analyzed, the data type analyzer checks the element name defined in the XML schema described as the WCDLClient attribute as the root element in the service specification. After that, the calling URL is saved with the base and path attributes of the method element, and the calling method is saved with the name attribute. The param element described as a child element of the request element is an input parameter for invoking the service, and the input type of the param element is analyzed by referring to the element name defined in the WCDLClient attribute of the type attribute of the param element. In addition, the representation element described as a child element of the response element is the result information for the service invocation, and the result type of the result information is analyzed by referring to the element name defined in the WCDLClient attribute of the element attribute of the representation element. The service specification illustrated in FIG. 7 is a service specification having a result in which schedule detail information about a schedule ID, which is an input parameter, is returned as a call result.

Through the above process, the data type analyzer analyzes the data types defined in the service specification. As shown in FIG. 8, the data type analyzer analyzes data types defined in the service specifications by using an ancestor and descendant relationship on the XML schema. Deriving the type relation diagram.

Subsequently, based on the type relationship diagram derived from the data type analyzer through the service specification analyzer, a list of views required for display in the service specification is extracted using the WADL parser (S618). In order to extract the list of views, the service specification analyzer first assumes one input and one result view for all methods included in the selected service specification, and the input parameter data is determined in the previous view so that the method can be called immediately. In this case, the input view of the method is omitted, and in the case of a method without the result data, the result view is omitted, thereby extracting a list of views requiring display from the service specification.

Table 1 below is a table showing an example of a set of views generated by the calling method.

action HTTP method Input type Input view Result type Result view search GET pid, date, string O slist O read sid schedule O create POST schedule O - update PUT schedule O - delete DELETE sid -

As shown in Table 1, the search, read, create, update, and delete actions are defined for each http method, and the GET method has a Read action that returns the contents of the resource by ID, and the contents of the resource by conditions. Can be broken down into a Search action that returns. The schedule resource has an input type and a result type for each action. If the type does not have a view, the view can be omitted, and the action with id as the input type can be called without a input view because the input type is determined in the previous view. The DELETE method has an ID value as an input parameter and no result data. In this case, the input and result views can be omitted. In this way, five views can be defined for each method.

When the list of views requiring display is extracted through the above process, the service specification analyzer analyzes the data type of the view and then analyzes the flow between the plurality of views included in the extracted list (S620). The flow between views is largely divided into a method that can call a method in a view and a view that can move from one view to another.

If the current view is the input view of the method or the data type of the view includes the input type of the method, the method can be called in the view. In this case, the page is provided using the data included in the current view. If all other methods that can be called can be called, all calls are allowed.

For example, as shown in FIG. 9, when analyzing the flow between the view of the read method of the first schedule resource and the read method of the second room resource, the schema of schedule, which is the data type of the result view of the schedule read method, is read in the room. Since the method's input data rid is included as a child element, the room's Read method can be called from the result view of the schedule Read request. Accordingly, a menu for performing a read request of a room in the read read schedule view is added.

Also, in order to move from the current view to the target view, when the target view is the input view to the calling method and the input data type of the target view includes the data type of the current view, the target view is defined as being able to move from the current view to another view. do.

For example, as shown in FIG. 10, when analyzing the flow between the schedule method and the view of the method for updating the schedule, the result view of the schedule request is the same type as the input view of the update method. You will be taken to the input view of the update request.

Subsequently, a data model for a service interface is generated through the data model generator (S622). This data model is created through the analysis of the input type and result type of the service method specification. After creating an instance that stores the input type and an instance that stores the call result, the input and result types for each instance are changed. It is added as a child element.

For example, when a data model is generated using the WADL document shown in FIG. 7, two instances are created, an "inputParam" instance that stores an input type and an "outputResult" instance that stores a call result. Subsequently, an input type schedule id (sch: sid) is created as a child element of the inputparm instance with the id value of the method element as an attribute, and the result type schedule details (sch: schedule) is created as a child element of the outputResult instance. do. In this case, the tree of the result type instance is copied to the XML element returned from the server, so only the root element needs to be created. Through this process, the regional data model code as shown in FIG. 11 is generated.

Next, the service generation element is generated for each method of the service specification through the submission generator (S624). The submission element contains the address and name of the method, and the path to the location to store the input element and result data. At this time, the ID and action attribute of the submission are obtained from the ID, base, and path values of the method, and the positions of the input and result elements are obtained from the local data model. FIG. 12 illustrates a portion of a submission code generated in the WADL document shown in FIG. 7. As shown in FIG. 12, since the input element label of the method is sid, the ref attribute of the submission element attaches the sid element after the XPath of the local data model shown in FIG. Similarly, the path of the element where the result data will be stored is indicated by the instance and target attributes.

Subsequently, the client page capable of calling the view and the method and moving the view through the view code generator generates the XForms code (S626). Client pages are created using the <group> element. The id attribute of the <group> element uses a name, and the nodeset attribute uses the location of the data referenced by the view. FIG. 13 illustrates an example in which a client page is generated using a <group> element in the WADL document illustrated in FIG. 7.

The generated client page contains code for moving to another view and code for calling a service method according to the derived view flow. FIG. 14 illustrates an example of generating code for calling the method "m3" shown in FIG. 7 using the <submit> element. As shown in Fig. 14, finding the corresponding submission element with the submission attribute value of the submit element to call the method "m3", and copying the value to the reference position of the input parameter for calling the method "m3". Setvalue action code was generated.

15 shows an example of automatically generated code for moving from the result view of the method "m3" to the modified view using the <trigger> element. To move to the modification view, a copy action code is generated that copies the data value of the result view of "m3" to the reference position of the modification view. A setfocus action code is generated to move to the modification view.

Through the above process, when the user selects and requests a desired service specification from the service specification list provided by the service specification list providing server, the service selected by the user is combined, and the method call and view movement according to the XForms-based Client pages are automatically generated.

FIG. 16 illustrates an example of a service specification list provided by a service specification list providing server and a screen for allowing a user to select a service specification according to an embodiment of the present invention. FIGS. 17 and 18 illustrate a user selection. The following figure shows an example of creating an XForms-based client page created by combining services.

As shown in FIG. 16, a user may select a desired service specification from a service specification list provided by a service specification list providing server. In the present invention, for a service combination capable of searching for bus information according to a schedule, The following shows an example of a screen for selecting a schedule service specification and a bus information service specification.

The client page automatic generation system analyzes the schedule service specification and the bus information service specification selected by the user, and generates a view necessary for connecting the schedule service and the bus information service as shown in FIG. 17, and as shown in FIG. 18. Provides an XForms-based client page with a menu for navigation and service invocation. Accordingly, by using the generated client page, the user can input the desired date to search the schedule of the date. At the same time, the bus search for the location of the schedule and the route for the bus can be searched. Multiple services can be provided.

The present invention is not limited to the above-described embodiments and the accompanying drawings, and it is common in the art that various substitutions, modifications, and changes can be made without departing from the technical spirit of the present invention. It will be clear to those who have knowledge of God.

100: service provider 200: service specification list providing server
300: automatic client page generation system
310: analysis unit 312: data type analysis unit
314: service specification analysis unit 320: code generation unit
322: data model generation unit 324: service mission generation unit
326: view generating unit 400: client terminal

Claims (15)

A system for generating a client page that provides a multi-service for at least one service selected by a user connected to a server storing a service application list based on a web application description language (WADL),
A data type analysis unit for analyzing a data type defined in the selected service specification using a schema parser, and analyzing a inclusion relationship between the data types to derive a type relationship diagram;
Based on the type relationship diagram derived from the data type analysis unit, a list of views that are required to be displayed in the selected service specification is extracted using a WADL parser, and the flow between a plurality of views included in the extracted list is analyzed. A service specification analyzer for deriving a view flowchart;
A data model generator for generating a data model for storing input parameters and result data;
A submission unit for generating a submission element for each method of the service specification, the path of the data referenced by the view corresponding to the method, an input parameter, and a data model location to store the result data;
A view generator for generating a client page capable of calling a method and moving a view using XForms code using a plurality of views extracted from the service specification analyzer and a view flow diagram thereof;
XForms-based client page automatic generation system characterized in that the configuration, including.
The method of claim 1,
The data type analysis unit,
XForms-based automatic client page generation system, which derives the type relation diagram defined by ancestor and descendant relation by XML schema structure definition.
In accordance with claim 1,
The service specification analysis unit,
After assigning input view and result view one by one to all methods included in the selected service specification, XForms-based client page automatically extracts a list of views requiring display except input view and result view that can be omitted. Generating system.
The method of claim 3, wherein
The service specification analysis unit,
XForms-based client page automatic generation system, characterized in that if input parameter data is determined from previous view and method can be called immediately, input view is skipped and result view is skipped for methods without result data. .
The method of claim 1,
The service specification analysis unit,
An XForms-based automatic client page generation system, which derives a view flow chart defined by a method call from a view and a relationship from a current view to another.
6. The method of claim 5,
In the process of deriving the view flow chart, the service specification analysis unit,
If the current view is the input view of the method or the data type of the view contains the input data type of the method, define as a relation that can be called by the method in the view.
In order to move from the current view to the target view, the target view is the input view to the calling method, and if the input data type of the target view includes the data type of the current view, it is defined as a relation that can be moved from the current view to another view. XForms based client page automatic generation system.
The method of claim 1,
The data model generation unit,
XForms-based automatic client page generation system, characterized in that the input and result types are added as child elements for each instance after creating an instance to store the input type and the result of the call.
The method of claim 1,
In the data model generated by the data model generator,
An input parameter and the result data of a service call are stored, and the result data is stored in the form of a partial tree, and when the response of the service call is returned, the corresponding partial tree is updated.
The method of claim 1,
The submission element,
It consists of address and name, location and path to store input element and result data, address and name of submission element are ID of corresponding method and address value to call, path of input element and result data storage location is the data XForms-based automatic client page generation system, characterized in that obtained from the data model generated by the model generator.
Claims [1] A method of generating a client page by using a system for generating a client page that provides a multi-service for at least one service selected by a user connected to a server storing a web application description language (WADL) -based service specification list.
Receiving a service specification selected by the user from a server in which the service specification list is stored;
Analyzing a data type defined in the selected service specification using a schema parser, and analyzing a inclusion relationship between the data types to derive a type relationship diagram;
Extracting a list of views for which display is required from the selected service specification based on the derived type relationship diagram;
Deriving a view flow chart by analyzing a flow between the views of Dash included in the extracted list;
Generating a data model for storage of input parameters and result data;
Generating a submission element for each method of the service specification, the path of the data referenced by the view corresponding to the method, an input parameter, and a data model location to store the result data;
Generating, by XForms code, a client page capable of calling a method and moving a view through information specified in the submission element by using the extracted plurality of views and a view flow diagram thereof;
XForms-based client page automatic generation method characterized in that the configuration, including.
The method of claim 10,
Deriving the type relationship diagram,
An XForms-based client page automatic generation method characterized by deriving a type relationship diagram defined by an ancestor and descendant relationship by defining an XML schema structure.
The method of claim 10,
Extracting the list of views,
After assigning input view and result view one by one to all methods included in the selected service specification, if input parameter data is determined in the previous view and the method can be called immediately, the input view is omitted and the method has no result data. In the case of XForms-based client page automatic generation method, characterized in that to extract the list of views for display by omitting the result view.
The method of claim 10,
Deriving the view flow chart,
If the current view is the input view of the method or the data type of the view contains the input data type of the method, define as a relation that can be called by the method in the view.
In order to move from the current view to the target view, when the target view is the input view to the calling method and the input data type of the target view includes the data type of the current view, the view flow chart is defined as the relation that can be moved from the current view to another view. XForms-based client page automatic generation method characterized in that the derivation.
The method of claim 10,
Generating the data model,
Automatically create an XForms-based client page, by creating an instance that stores the input type and an instance that stores the call result, and then creating a data model by adding input and result types as child elements for each instance. How to produce.
The method of claim 14,
In the generated data model, input parameters and the result data of the service call are stored, and the result data is stored in the form of a partial tree, and when the response of the service call is returned, the corresponding partial tree is updated. How to automatically generate client pages.

Images