Abstract:
Many different web services require different application programs to access their data, and it is not practical for a wireless device to contain a sufficient number of application programs such that the device would be able to access all the available web services. Further, as new web services are developed, they may not be compatible with current application programs. Systems and methods are presented for dynamically generating components of an application program for interaction with a selected schema defined service, the application for execution on a terminal coupled to the service via a network. One method comprises obtaining schema definitions of the service from a source and parsing the schema definitions for identifying an interface element. The interface element can include a plurality of element definitions. This method also builds a model of a service interface for representing the service, the service interface including the identified interface element. This method also generates an application template according to the model, the template including at least one of the element definitions comprising the interface element, wherein the template is configured for customization for assembling the application for execution by the terminal.

Description:
[0001]     This application claims the benefits of earlier filed provisional application No. 60/503,978, filed Sep. 17, 2003, which is herein incorporated by reference. 
     
    
     BACKGROUND  
       [0002]     The present application relates to generation of applications for interaction of terminals with schema defined services.  
         [0003]     Current access to backend services is through a web service that formats the data obtained from the back end services in the form of HTML pages for communication through a web server to a networked client device. Disadvantages of this architecture include static access of the back end data by the client device through non-editable HTML pages, which can consume device resources.  
         [0004]     Preferably, the client device would like to intelligently access the data provided by the back end services. However, current client devices do not have the tools necessary for this type of interaction. Further, the current web services do not have the capability of direct interaction with the client devices based on the initial queries submitted by the client device.  
         [0005]     Many different web services require different application programs to access their data, and it is not practical for a wireless device to contain a sufficient number of application programs such that the device would be able to access all the available web services. Further, as new web services are developed, they may not be compatible with current application programs.  
         [0006]     Systems and methods are disclosed herein that provide a dynamic generation system and method of schema-defined service applications to obviate or mitigate some of the above presented disadvantages.  
       SUMMARY  
       [0007]     Many different web services require different application programs to access their data, and it is not practical for a wireless device to contain a sufficient number of application programs such that the device would be able to access all the available web services. Further, as new web services are developed, they may not be compatible with current application programs. Contrary to current generation methods for application programs there is provided a system and method for dynamically generating components of an application program for interaction with a selected schema defined service, the application for execution on a terminal coupled to the service via a network. The method comprises obtaining schema definitions of the service from a source and parsing the schema definitions for identifying an interface element. The interface element can include a plurality of element definitions. The method also builds a model of a service interface for representing the service, the service interface including the identified interface element. The method also generates an application template according to the model, the template including at least one of the element definitions comprising the interface element, wherein the template is configured for customization for assembling the application for execution by the terminal.  
         [0008]     A method for dynamically generating components of an application program for interaction with a selected schema defined service, the application for execution on a terminal coupled to the service via a network is disclosed, the method comprising the steps of: obtaining schema definitions of the service from a source; parsing the schema definitions for identifying an interface element, the interface element including a plurality of element definitions; building a model of a service interface for representing the service, the service interface including the identified interface element; generating an application template according to the model, the template including at least one of the element definitions comprising the interface element; wherein the template is configured for customization for assembling the application for execution by the terminal.  
         [0009]     There is further provided a server for dynamically generating components of an application program for interaction with a selected schema defined service, the application for execution on a terminal coupled to the service via a network, the server comprising: a network interface for obtaining schema definitions of the service from a source; a parser module for parsing the schema definitions to identify an interface element, the interface element including a plurality of element definitions; a model module configured for representing a model of a service interface for representing the service, the service interface including the identified interface element; a builder module for generating an application template according to the model, the template including at least one of the element definitions comprising the interface element; wherein the template is configured for customization for assembling the application for execution by the terminal.  
         [0010]     Also disclosed is a computer program product for dynamically generating components of an application program for interaction with a selected schema defined service, the application for execution on a terminal coupled to the service via a network, the computer program product comprising: a computer readable medium; a network interface module stored on the computer readable medium for obtaining schema definitions of the service from a source; a parser module stored on the computer readable medium for parsing the schema definitions to identify an interface element, the interface element including a plurality of element definitions; a model module coupled to the parser module configured for representing a model of a service interface for representing the service, the service interface including the identified interface element; a builder module coupled to the model module for generating an application template according to the model, the template including at least one of the element definitions comprising the interface element; wherein the template is configured for customization for assembling the application for execution by the terminal. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0011]     These and other features will become more apparent in the following detailed description in which reference is made to the appended drawings by way of example only, wherein:  
         [0012]      FIG. 1  is a block diagram of a network system;  
         [0013]      FIG. 2  is a block diagram of a dynamic generation and customization configuration of the system of  FIG. 1 ;  
         [0014]      FIG. 3  is illustrates the relationship between templates and a service of  FIG. 1 ;  
         [0015]      FIG. 4  is a block diagram of a generation server of  FIG. 1 ;  
         [0016]      FIG. 5  is a flowchart illustrating a method of building the application templates of  FIG. 2 ; and  
         [0017]      FIG. 6  is a diagram of a system for customizing the templates of  FIG. 1 ; 
     
    
     DESCRIPTION  
       [0000]     Network System  
         [0018]     Referring to  FIG. 1 , a network system  10  comprises a plurality of terminals  100  for interacting with one or more template generation servers  106 , via a coupled Wide Area Network (WAN)  104  such as but not limited to the Internet. These generic terminals  100  can be any suitable terminal such as but not limited to wired devices such as personal computers  116 , wireless devices  101 , PDAs, self-service kiosks and the like. The generation server  106  provides application templates  107  through messages  105  to the terminal  100 . The application templates  107  are sent from the server  106  to the terminal  100  when requested, for customization. It is recognized that the application templates  107  could also be sent by the generation server  106  to an independent customization provider  120 , which can be a development environment for customizing the application User Interface (Ul), communication with the web service  110  and the applications  122  process workflow. In this case, the provider  120  would send completed applications  122  to the terminal  100 . The terminal  100  uses the applications  122  to access or otherwise communicate with a web service  110 , or other schema-defined services such as but not limited to SQL databases. It is recognised that the server  106  could be an independent server or provided by the web service  110 .  
         [0019]     The terminal  100  contacts the generation server  106  to ultimately obtain the applications  122 . The terminal can first become aware of the web service  110  through a Universal Description, Discovery, and Integration (UDDI) service registry  124 , which contains reference to the web service  110 . The server  106  can use the registry  124  and/or the web service  110  to generate the model templates  107  based on the definition of the service  110 . The service can be defined according to a structured definition language, such as but not limited to WSDL. It is recognized that repositories or databases  128 , accessed by a repository server  130 , can be used to store completed templates  107  and/or applications  122  if desired. Further, the system  10  can also have a gateway server  112  for connecting the desktop terminals  116  via a Local Area Network (LAN)  114  to the server  106 . Further, the system  10  can have a wireless network  102  for connecting the wireless devices  101  to the WAN  104 . It is recognized that other terminals and computers (not shown) could be connected to the server  106  via the WAN  104  and associated networks other than as shown in  FIG. 5 . The generic terminals  100 , wireless devices  101  and personal computers  116  are hereafter referred to as the terminal for the sake of simplicity. Further, the networks  102 ,  104 ,  112  of the system  10  will hereafter be referred to as the network  104 , for the sake of simplicity. It is recognized that there could be multiple servers  106 ,  112 ,  130  if desired.  
         [0000]     Customization Environment  
         [0020]     Referring to  FIGS. 1 and 2 , the terminal  100  first becomes aware of or otherwise discovers a particular user selected web service  110  through, for example, a registry service such as the UDDI  124 . The UDDI  124  can contain a reference or link to the generation server  106 , whereby the terminal  100  can obtain the appropriate application  122  for interaction with the web service  110 , such as by request/response messages  105  using an appropriate communication protocol such as, but not limited to, Simple Object Access Protocol (SOAP). It is also recognized that the terminal  100  could get knowledge of existing generation servers  106  and/or services  110  available over the Internet (WAN  104 ) by third parties (not shown), or that the terminal  100  could hold the address of the generation server  106  in the terminal  100  memory.  
         [0021]     The terminal  100  then contacts the appropriate generation server  106  with the request  105  for the Application Program  122  to be able to interact with the selected web service  110 . The generation server  106  then obtains a definition  300 ,  302 ,  304  (see  FIG. 3 ) of the services offered by the web service  110 , such as but not limited to services expressed in a structured definitional language (e.g., Web Services Description Language (WSDL)). It is recognized that the generation server  106  can obtain the web service  110  definition from registry  124 , or directly through contact with the web service  110 , or through a service provider of the web service  110  (not shown). It is further recognized that the general schema defined service (e.g. WSDL) of the web service  110  can also contain additional web service metadata definitions, such as but not limited to metadata definitions in Business Process Execution Language (BPEL). One example of an additional definition is information on linking between messages  105 .  
         [0022]     Using the web service definitions  300 ,  302 ,  304  (see  FIG. 3 ), the generation server  106  then generates the appropriate Application Templates  107 , containing message  300 , data  302  and/or presentation definitions  304 . The generation server  106  then submits the Application Templates  107  directly to the terminal  100  for subsequent customization to produce the desired Application  122  for interaction with the selected web service  110 . It is also recognized that the Application Template  107  could be customized by the customization provider  120  before being submitted to the terminal  100 . For example, the terminal  100  making the request  105  for application  122  generation may be allowed to customize new or existing applications  122  and/or templates  107 , if the user is authorized to customise.  
         [0023]     It is recognised that the repository  128  can be split as two dedicated repositories, one for applications  122  and one for templates  107 . The Application Template Repository  128  can represent a centralized location for storing application templates  107 . The application templates  107  can be stored and provided to other users requesting customizations of the same web service  110 . The Application Repository  128  can represent a centralized location for storing completed applications  122  and making them available to other users.  
         [0000]     Application Templates  107   
         [0024]     Referring to  FIG. 3 , Application Templates  107  are intermediary entities of the application  122  generated by the Generation Server  106 . Application Templates  107  can consist of interface elements such as : message definitions  300 ; data definitions  302 ; workflow components  303  and/or presentation definitions  304  obtained from the general schema of the web service  110 .  
         [0025]     The client application programs  122  can be defined as a set of platform-neutral component templates  107 , namely for data  308  and message  306  components, and presentation components  310  using XML (or any other suitable structured definition language). The server  106  can generate component templates  107  based on meta-definitions  300 ,  302 ,  304  obtained from the web service  110 , as further described below. With a large variety of terminal  100  runtime environments, cross-platform standards such as XML or ECMAScript can be used to define application metadata instead of pre-building the application programs  122 . This delayed binding can allow generic application definitions of the application programs  122  to be run on a wide variety of terminal system environments, represented by various different devices  100 .  
         [0026]     In some implementations, expressing the data  308 , message  306 , and presentation  310  templates using XML or its derivatives, and the workflow elements  303 , see below, using the ECMAScript and XML languages or their subsets, can allow an application developer to abstract the Web Service  100  client from any specific platform or environment and implement in principle “develop once run everywhere” applications. The following example shows how a Web Services  100  client application program  122  could be expressed using a structured definition language, such as but not limited to XML, and a platform neutral scripting/programming language, such as but not limited to ECMAScript, to generate the templates  306 ,  308 ,  310 , and a workflow template  312 , and a mixed template  314  as further described below.  
         [0000]     Message Definitions  300   
         [0027]     The message definition  300  contains message elements for defining a communication message  105  to be exchanged between the client application  122  and the Web Service  110  (see  FIG. 1 ). The message  105  consists of field (element) definitions identifying for each the type of the field to be sent as part of a communication. The message definitions  300  can be written in a structured definition language such as but not limited to XML. The message definition  300  can contain fields of complex type. Such fields are defined by the data definition  302  and may contain multiple data fields. The message definition  300  can be mapped to the data definition  302  in which case each field of the data implies a corresponding field in the message. In this case the message can be completely constructed out of a particular instance of the data definition  302 . If the message  105  is a response message then an instance of the mapped data definition  302  is dynamically created or updated upon receiving of the response. The definitions  300 ,  302 ,  304  can be used by the generation server  106  to create the message templates  306 .  
         [0028]     Example Message Template  306  in XML  
                                                                       &lt;msg name=“ordConfirmation” type=”response”           action=“mhConfirmation”&gt;                &lt;part name=“orderId” type=“String“ /&gt;           &lt;part name=“status” type=“String“ /&gt;                &lt;/msg&gt;                      
 
 Data Definitions  302  
 
         [0029]     The data definition  302  defines a data structure used in and/or by the application  122 . The data definition  302  consists of a set of field (element) definitions. Field definitions identify the data type of each field. Fields can be of complex type in which case its type is defined by another data definition  302 . Multiple data instances of each data definition  302  may exist. Every instance is identified by a field recognized as primary key. The primary key field is indicated in the data definition  300  and must contain only unique values. The data definitions  300  can be written in the structured definition language such as but not limited to XML. The definitions  300 ,  302 ,  304  can be used by the generation server  106  to create the data templates  308 .  
         [0030]     Example Data Template  308  in XML  
                                   &lt;data name=“Order”&gt;              &lt;item name=“orderId” type=“Number” key=“true”/&gt;              &lt;item name=“items” type=“String“ array=“true”/&gt;              &lt;item name=“user” comp=“true” compName=“User”/&gt;              &lt;item name=“orderStatus” type=“String”/&gt;           &lt;/data&gt;                  
 
 Presentation Definitions  304  
 
         [0031]     The presentation definition  304  defines the appearance and functionality of such as one screen in the application  122 , or other presentation element provided by a user interface of the terminal  100 . The presentation definition  304  can consist of UI control (element) definitions and menu item (element) definitions. The presentation definition  304  may have as an input parameter the data definition  302 . In this case during execution a data instance of the specified data definition  302  is supplied and used by the screen to populate its UI control with data. The presentation definitions  304  can be written in a structured definition language such as but not limited to XML. Some UI elements of the screen may initiate an outgoing communication by sending the message definition  300  to the Web Service  110 . Further, the presentation definitions  304  can also include workflow components  303 , such as but not limited to the definitions of navigation between screens.  
         [0032]     Example Presentation Template  308  in XML with Workflow  303   
                                   &lt;screen name=“scrConfirmation” title=“Order Confirmation”       param=“Order”&gt;            &lt;layout type=“vertical”&gt;            &lt;widget type=“label” value=“Order Confirmation Result:”/&gt;              &lt; widget type=“edit” value=“@Order.orderStatus”/&gt;            &lt;/layout&gt;            &lt;menu&gt;              &lt;item label=“Continue” navigate=“@scrMain”/&gt;              ...            &lt;/menu&gt;       &lt;/screen&gt;                  
 
         [0033]     Further, it is recognised that the mixed definition templates  314  (combination of the definitions  300 ,  302 ,  303 ,  304  ) and the workflow templates  312  written in such as but not limited to script may also be included in the templates  107 . The workflow templates  312  could include navigation instructions between screens, as well as other workflow components  303  specifying the behavior of the message  300 , data  302 , and presentation definitions  304 .  
         [0000]     Generation Server  
         [0034]     The server  106  performs generation of the templates  107  from the definitions  300 ,  302 ,  303 ,  304  (see  FIG. 3 ) of the web service  110 . Referring to  FIG. 4 , the server components  400  use descriptions of the service  110 , such as defined in WSDL and/or BPEL, for parsing, such that the application template  107  is generated. The definitions of the web service  110  as obtained by the generation server  106  can include the optional BPEL metadata, for building the component definitions of the application template  107 .  
         [0035]     Referring again to  FIG. 4 , the server components  400  can include, without limitation, a WSDL Parser  402  for parsing the WSDL definition of the Web Service  110  and building a WSDL model  406  containing the parsed elements of the definitions  300 ,  302 ,  303 ,  304  (see application template description above). The server components  400  can, in some instances, also include a BPEL Rule Extractor  404 , which extracts rules and transaction information from the BPEL definition or from another source of Web Service metadata. The extracted rules can be placed in a rule database  408  or other suitable repository. The server components  400  can also include a Message Builder module  412 , which uses the message definitions to build message templates of the templates  107 . A Data Builder module  410  uses the data definitions to build data templates of the templates  107 . A Presentation Builder module uses the presentation definitions, a well as message and data definitions, to build presentation templates of the templates  107 . It is recognized that the builders  410 ,  412 ,  414  can use workflow definitions  303  (see  FIG. 3 ) to build the templates  107 , as well as interchanging the definitions to build the mixed definition templates  314 , as desired.  
         [0000]     Generation Stage  
         [0036]     During the generation stage, the application template  107  is generated from the service schema of the Web Service  110 . To improve the generation process additional input parameters may be supplied such as BPEL or another source of Web Service metadata.  
         [0037]     Referring to  FIGS. 4 and 5 , the generation  500  of the application templates  107  can be as follows.  
         [0000]     Step  502 : Service Schema Analysis  
         [0038]     This step can consist of two parts: 
        Parsing the input information including 
            parse definition, for example, using the WSDL parser  402  for a definition in WSDL and build the model  406  of the Web Service  110  interface, and/or     parse Web Service  110  metadata, for example, using the extractor  404  the BPEL or any additional Web Service  110  metadata; and    
            Discovery of the interface elements of the definitions  300 ,  302 ,  303 ,  304  (see  FIG. 3 ) such as but not limited to 
            identify Web Service messages  105  and their parameters     identify any complex types such as can be defined in the WSDL     identify message  105  sequences or transaction boundaries out of addition Web Service metadata. 
 
 Step  504 : Generate Message Definitions 
   
               
 
         [0046]     During this step the message definition  300  (see  FIG. 3 ) is generated by the message builder  412  for each message  105 . The message  105  can be defined using a structured definition language such as WSDL. Each parameter of the Web Service  110  message produces a corresponding field in the message definition  300 .  
         [0000]     Step  506 : Generate Data Definitions  
         [0047]     During this step the data definitions  302  (see  FIG. 3 ) for the application template  107  are generated. The data definition  302  can be generated by the data builder  410 : for each message definition generated in Step  504 ; and for each complex type contained in another data definition  302 . In addition data definitions  302  may be generated as a result of parsing any additional Web Service metadata such as BPEL definition.  
         [0000]     Step  508 : Generate Presentation Definitions  
         [0048]     During this step the presentation definitions  304  (see  FIG. 3 ) for the application template  107  are generated. Presentation builder  414  can generate a number of different types presentation definition  304 . Various implementations can include one more of the following: 
        Main screen—the starting screen for the application  122 . It presents the user with a choice of operations. Each operation corresponds to the message definitions  300  identified in Step  504 . By selecting one of the operations on the main screen the user activates one of the message form screens;     Message form screens—the screens where the user can supply input data for each message  105  sent to the service  110 . One message form screen is generated for each message definition  300 . The message form screens contain UI elements for each field (element) in the message definition  300 . In addition a Submit button is generated that will submit the message  105  when the user has completed entering data;     Result screens—the screens displaying the result of the message  105  sent to the service  110 . One result screen is generated for each response message  105 . The result screen contains UI components corresponding to the fields (elements) in the message  105 . In addition a Continue button is generated that will return the control to the main screen;     Notification dialogs—the dialogs alerting user on notification events. These dialogs could be defined for Web Service  110  notifications (correlated and uncorrelated). Notification dialog could display the values in the notification message  105  and navigate user to the main screen (same as Result screens) or just alert user on notification event and redirect to associated Result screen; and     Navigation instructions between screens and other workflow components  303  (see  FIG. 3 ) for specifying the behavior of the message  300 , data  302 , and presentation  304  definitions.        
 
         [0054]     Further, if additional metadata is available for the Web Service  110 , then multiple screen definitions  304  can be chained together corresponding to a sequence or a transaction definition in the Web Service  110 .  
         [0055]     At step  5   10 , the constructed definitions are assembled  5   10  into the application templates  107 . It is recognized that interchanging definitions can be used by the process  500  to build the mixed definitions to result in mixed templates  107 , as desired. At step  512 , the templates  107  are made available such as to the user of the terminal  100  or the customization process  120  (see  FIG. 1 ).  
         [0000]     Customization Stage  
         [0056]     The Customization Environment (customization provider)  120  (see  FIG. 1 ) can include, without limitation, one or more of the following components (see  FIG. 6 ): a Screen Designer  606  for providing presentation editing functionality of the template  107 ; a Data Designer  608  for providing data editing functionality of the template  107 ; and a Message Designer  610  for providing message editing functionality of the template  107 .  
         [0057]     Once the application templates  107  have been generated, a Customization stage  600  (see  FIG. 6 ) can be provided in some implementations to give the application developer (or others) the opportunity to modify the application template  107  in a more desirable and user friendly way, depending on the context of each application  122  and potentially a runtime environment consideration of the terminal  100 . The developer can add, remove and modify relations between data, message and screen definitions of the templates  107 , such as but not limited to workflow component  303  definitions for modeling the behavior of the data  302 , message  300  and screen  304  definitions. As a result of the customization stage  600 , a final application  122  can be generated for execution on the terminal  100 .  
         [0058]     As is apparent, the generated application templates  107  can be used to generate application  122  without use of a customization stage  600 . In such implementations, the applications templates  107  are used directly from the template generation process to create application  122 .  
         [0059]     Referring to  FIG. 6 , the following Customization procedure  600  can be used.  
         [0000]     Step  601 : Edit Screen Definitions  304   
         [0060]     In this step the user can perform the following operations: modify screen transitions in a way that is meaningful and practical for the given application  122  context; define relations between screens  304  and data  302  definitions; define relations between screens UI components and data fields; improve usability and appearance by adding, removing or modifying UI functionality; and binding messages submitting to UI actions such as menu items and buttons.  
         [0000]     Step  602 : Edit Data Definitions  302   
         [0061]     In this step the user can perform the following operations: add, remove or modify data  302  definitions in order to improve the data model of the application  122 ; and redefine relations with message  300  and screen  304  definitions due to changes of an existing data definition.  
         [0000]     Step  603 : Edit Message Definitions  300   
         [0062]     In this step the user can perform the following operations: remove messages that are not used by the application  122 ; and adjust mapping relations between message  300  and data  302  definitions.  
         [0000]     Step  604 : Add Workflow Component Definitions Other than Defined in Step  601   
         [0063]     The workflow components  406  can be defined using ECMAScript (or any other suitable platform-neutral scripting language).  
         [0064]     Based on the above system  10 , it is recognised that application generation and customization can be initiated by the user of the terminal  100  discovering the web service  110  using such as but not limited to: a device browser; an email attachment; or a dedicated web service discovery application. The user then makes the request for generation of the application template  107  for subsequent communication with discovered web service  110 . The user can make the request using one of two options, namely: Option  1  the user makes the request to the dedicated generation server  106 ; and Option  2  the user makes the request directly to the UDDI registry  124  specifying the client type (e.g. wireless client). The registry  124  can have enabled special components to generate (or retrieve a stored one) the client template  107 . The request for customization can be sent to a dedicated design body or to the originating user if she/he is authorized for application  122  customizations, or to such as but not limited to an administrator or an entity for certifying or otherwise authorizing new web services  110 . The finalized application  122  can be stored on the client device  100  and optionally provisioned back to application repository  128  for access by other users. The user can start the application  122  and access the web service  110 .  
         [0065]     The above description relates to one or more exemplary systems and methods. Many variations will be apparent to those knowledgeable in the field, and such variations are within the scope of the application. For example, although XML and a subset of ECMAScript are used in the examples provided, other languages and language variants, such as but not limited to HTML and XSML, may be used to define the template  107 . Further, it is recognized that the server can comprise hardware and/or software components for implementing the system  10 , such as: a network interface module for obtaining schema definitions of the service from a source; a parser module for parsing the schema definitions; and a model module for representing a model of a service interface for representing the service; a builder module the application template according to the model.