Patent Publication Number: US-7912984-B2

Title: System and method for generating a wireless application from a web service definition

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of priority under §35 U.S.C. 119(e) to U.S. Provisional Patent Application Ser. No. 60/672,013 filed Apr. 18, 2005, the entirety of which is hereby incorporated by reference. This application is a continuation of U.S. patent application Ser. No. 11/221,820, the entirety of which is hereby incorporated by reference. 
    
    
     MICROFICHE APPENDIX 
     Not Applicable. 
     TECHNICAL FIELD 
     This application relates generally to wireless communications applications and wireless communications devices and, in particular, to a method and apparatus for generating a wireless application from a web service definition. 
     BACKGROUND OF THE INVENTION 
     The acceptance of wireless devices as a preferred personal communications medium has created a growing demand for such devices. Users of such devices also increasingly expect more functionality and a broader range of services to be made available through such devices. This demand for more functionality requires the development of new applications for wireless devices. 
     A significant source of information for wireless devices is the Worldwide Web. As is well known, many Worldwide Web services, hereinafter referred to simply as “web services”, are available to web enabled devices. 
       FIG. 1  is a block diagram of a prior art network in which wireless device users  10   a ,  10   b  operate wireless devices to send web service request messages via a public domain carrier  12  to an application gateway  14 . The application gateway  14  forwards the web service request messages through the internet  16  to an appropriate web service  18   a ,  18   b . The messages are processed by the appropriate web service  18   a ,  18   b  and returned through the internet  16  to the application gateway  14 . The public domain carrier  12  forwards the response messages to the wireless device operated by users  10   a ,  10   b  which processes the response and displays response content to the wireless device users  10   a ,  10   b.    
     However, web services generally use complex data structures and complex message formats. Complex data structures and complex message formats introduce a significant memory overhead on wireless devices. This impacts the performance of wireless devices and necessitates the development of wireless applications for providing efficient access to the web services. 
     It is well known that wireless applications for accessing web services from wireless devices can be developed by skilled application developers. It is also known that such application development is time consuming and expensive. 
     Consequently, there exists a need for a system and method for generating a wireless application from a web service definition. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which: 
         FIG. 1  is a block diagram of a prior art wireless network system; 
         FIG. 2  is a schematic diagram illustrating a process for creating and enabling a system in accordance with the invention; 
         FIG. 3  is a block diagram of a proxy in accordance with the invention; 
         FIG. 4  is a block diagram of a wireless device in accordance with the invention; 
         FIG. 5  is a high level overview of messaging between a wireless device and a remote service in a system in accordance with the invention; 
         FIG. 6  is a flow chart of a mainline of an algorithm in accordance with the invention for creating a wireless application from a web service definition; 
         FIG. 7  is a flow chart of a mapPart function of the algorithm shown in  FIG. 6 ; 
         FIG. 8  is a flow chart of a handleElementDeclaration function of the algorithm shown in  FIG. 7 ; 
         FIG. 9  is a flow chart of a handleTypeDefinition function of the algorithm shown in  FIG. 8 ; 
         FIG. 10  is a flow chart of a handleSimpleTypeDefinition function of the algorithm shown in  FIG. 9 ; 
         FIG. 11  is a flow chart of a computeSimpleDataType function of the algorithm shown in  FIG. 10 ; 
         FIG. 12  is a flow chart of a mapEnumeration function of the algorithm shown in  FIG. 10 ; 
         FIG. 13  is a flow chart of a computeAtomicType function of the algorithm shown in  FIG. 11 ; 
         FIG. 14  is a flow chart of a mapDataComponent function of the algorithm shown in  FIG. 9 ; 
         FIG. 15   a  is a flow chart of a handleComplexTypeDefinition function of the algorithm shown in  FIG. 14 ; 
         FIG. 15   b  is a continuation of the flow chart shown in  FIG. 15   a;    
         FIG. 16  is a flow chart of a handleAttributeDeclaration function of the algorithm shown in  FIG. 15   b;    
         FIG. 17  is a flow chart of a handleAnyAttribute function of the algorithm shown in  FIG. 15   b;    
         FIG. 18  is a flow chart of a handleSimpleContent function of the algorithm shown in  FIG. 15   b;    
         FIG. 19  is a flow chart of a handleParticle function of the algorithm shown in  FIG. 15   a ; and 
         FIG. 20  is a flow chart of a handleModelGroup function of the algorithm shown in  FIG. 19 . 
     
    
    
     It will be noted that throughout the appended drawings, like features are identified by like reference numerals. 
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     The invention provides a system and method for generating a wireless application from a web service definition. The system executes program code that embodies an algorithm which receives a web service operation definition and examines the input and output messages and data structures used in the messages to generate corresponding message and data definitions in the wireless application. Additionally, the algorithm outputs a mapping associating each wireless message with a web service message and each wireless data definition with a web service data definition. This mapping is used by a proxy located in a communications path between a wireless device and the web service to translate web service messages to a format used by the application running on the wireless device, and vice versa. 
     System Overview 
       FIG. 2  is a schematic diagram illustrating a process for creating and enabling a system in accordance with the invention. 
     A remote service accessed by the users  10   a ,  10   b  of wireless devices shown in  FIG. 1 , such as web service  20  uses complex message structures to communicate information to users who access the remote service. The web service  20  likewise uses complex data structures for data storage and data retrieval. A wireless application developer  22  uses a specification of the web service  20  and an application developer toolkit to create wireless device applications  24  and message maps  26  for enabling a system in accordance with the invention. The wireless device applications  24  with message formats and wireless data structures is created from a specification for the web service  20 . As will be explained below with reference to  FIGS. 7-19 , the wireless data structures are created using an algorithm for generating a wireless application from a web service definition. The process involves mapping web service messages to wireless messages and data structures. The application developer  22  may then use an automated or semi-automated algorithm for simplifying message and data structures to improve wireless device efficiency and reduce wireless bandwidth usage. 
     The message mapping  26  is used by a proxy at an edge of the wireless network to convert the complex service messages to wireless messages before the wireless messages are sent wirelessly to the wireless device users  10   a ,  10   b . In one embodiment of the invention the proxy that applies the data mapping  26  is an application gateway, as will be explained below with reference to  FIGS. 3 and 5 . 
       FIG. 3  is a block diagram of proxy  40  in accordance with the invention. The proxy  40  is located in a communications path between the wireless device  10   a ,  10   b  and the remote service, for example, a worldwide web service  18   a ,  18   b . In one embodiment of the invention the proxy  40  is an application gateway, and is hereinafter referred to as the application gateway  40 . 
     The application gateway  40  supports a wireless network interface  46  having a link  42  to the wireless network. A message transformation function  48  receives messages from the wireless network interface  46  and processes the messages before forwarding the messages to a service network interface  50 . The service network interface  50  has a link to a service network  44  (the Internet, for example) over which it forwards the messages to an appropriate web service(s). In accordance with the invention, the application gateway  40  is provisioned with a plurality of message maps  52 ,  54 . The message maps  52 ,  54  are created by the wireless application developer  22  using the algorithm in accordance with the invention, and used by the message transformation function  48  to process service request and service response messages, as will be explained below in more detail with reference to  FIG. 5 . One message map  52 ,  54  is created by the application developer  22  for each message type used by each web service  18   a ,  18   b.    
       FIG. 4  is a block diagram of a wireless device  56  in accordance with the invention. The wireless device  56  includes a network connection interface  58  that is well known in the art and used to communicate wirelessly with the public domain carrier  12 . The wireless device  56  further includes a user interface  60 , which may be a keypad, a touch sensitive screen, voice recognition software, or any other user interface for wireless devices. A device infrastructure  62  includes memory, processor(s), peripheral ports, keypad, display and other hardware components required to support the functionality of the wireless device  56 . A runtime environment  66  supports a plurality of data structures  68   a ,  68   n  that store corresponding application data. 
     Operation Overview 
       FIG. 5  provides an overview of wireless messaging using wireless applications in accordance with the invention. In step  70  a wireless device user  10   a  formulates a service request message in a wireless format when the user  10   a  wishes to request a service from web service  18   a . The service request message is forwarded (step  72 ) to the application gateway  40  which performs service request message mapping in step  74  to transform the service request message from the wireless format into a web service request message format required by the web service  18   a . The application gateway  40  forwards the web service request message to the web service  18   a  (step  76 ), which receives the web service request message and processes the message in a manner well known in the art (step  78 ). The web service  18   a  then formulates and returns a web service response message (step  80 ). The application gateway  40  receives the web service response message, correlates the web service response message with the web service request message sent earlier, and performs web service response message mapping in step  82  to transform the web service response message into a response message in the wireless format used by the wireless device  10   a . The application gateway  40  forwards the response message in the wireless format to the wireless device  10   a  in step  84 . The wireless device  10   a  receives the service response message and performs service response message processing in step  86 . The wireless device  10   a  may generate a display of information to the user in step  88 , depending on a content of the service response message processed in step  86 . 
     Application Generation Using a Web Service Definition 
       FIG. 6  is a flow chart of a mainline of an algorithm in accordance with the invention embodied in computer executable code for generating a wireless application from a web service definition. The algorithm shown in  FIG. 6  is, for example, a part of the application developer toolkit  22  ( FIG. 2 ). The algorithm accepts complex web service messages as input and outputs wireless service messages and message maps that permit the complex web service messages to be reconstructed using the wireless service messages and the message maps. 
     As shown in  FIG. 6 , the algorithm in accordance with the invention accepts messages defined by a web service definition and determines in step  100  whether a message specified by the web service definition is an input message or an output message. If the selected message is an input message, an input message object is created (step  102 ). Thereafter, the algorithm creates a componentMapping object in step  104  and links the componentMapping object to a message object and to a web service definition language (WSDL) message (step  109 ). 
     If it is determined in step  100  that the message is an output message, the algorithm creates an output message object (step  106 ). Thereafter, the algorithm creates a componentMapping object (step  108 ) and links the componentMapping object to a message object and to a WSDL message (step  109 ). The algorithm then selects the first message part (step  110 ) and invokes an algorithm function named mapPart (step  112 ). As is understood by those skilled in the art, the algorithm passes the message part information to the mapPart function. When the invoked mapPart function returns control to the mainline shown in  FIG. 6 , it is determined whether another message part exists (step  114 ). If so, the algorithm invokes the function mapPart (step  112 ). Otherwise, the algorithm determines in step  116  whether another message exists in the web service definition. If so, the algorithm returns to step  100 . Otherwise, the application generation is complete and the algorithm terminates execution. 
       FIG. 7  is a flow chart illustrating the algorithm function named mapPart. When mapPart is invoked in step  112 , the algorithm branches to step  120  and a message field object is created in step  122 . Subsequently, a fieldMapping object is created in step  124 . The fieldMapping object is then linked to the message field object and to a WSDL part (step  125 ). It is then determined in step  128  whether the message part passed to the function is an element. If the message part is an element, handleElementDeclaration is invoked (step  132 ). Otherwise, handleTypeDefinition is invoked (step  130 ). 
       FIG. 8  is a flow chart illustrating the algorithm function handleElementDeclaration ( 140 ). In step  142 , the algorithm determines the element type. The algorithm then invokes the algorithm function handleTypeDefinition (step  144 ), to which it passes the type definition information, and returns to step  132  of  FIG. 7 . 
       FIG. 9  is a flow chart illustrating the algorithm function handleTypeDefinition (step  150 ) branched to from step  130  of  FIG. 7 . In step  152  it is determined whether the type data component is a simple type. If so, the algorithm invokes the function handleSimpleTypeDefinition (step  154 ) to which it passes the simple type definition. If not, the algorithm invokes the function mapDataComponent (step  156 ), to which it passes the data component definition. Thereafter the algorithm returns to step  130  of  FIG. 7 . 
       FIG. 10  is a flow chart illustrating the function handleSimpleTypeDefinition ( 160 ) invoked in step  154  of  FIG. 9 . In step  162  it is determined whether the simple data type is an enumeration. If so, the algorithm invokes the function mapEnumeration (step  164 ), to which it passes the enumeration definition. If not, the algorithm invokes the function computeSimpleDataType (step  166 ) to which it passes the simple data type definition. In either case, the algorithm then returns to step  154  shown in  FIG. 9 . 
       FIG. 11  is a flow chart showing the function computeSimpleDataType ( 170 ) invoked in step  166  of  FIG. 10 . In step  172  it is determined whether the simple data type is atomic. If so, the algorithm invokes the function computeAtomicType (step  174 ), to which it passes the Atomic type definition. If the simple data type is not atomic, it is determined in step  176  whether the simple data type is a list. If so, a field array property is set to “true” (step  178 ) and the algorithm branches back (step  180 ) to step  170  with the new parameter. If simple data type is neither atomic nor a list, the type is a union, which is not supported in wireless applications in accordance with the invention. Consequently, the field object and the field mapping object are discarded (step  182 ) and the algorithm returns to step  166  shown in  FIG. 10 . 
       FIG. 12  is a flow chart showing the algorithm function mapEnumeration ( 190 ) invoked in step  164  shown in  FIG. 10 . In step  192  an enumeration object is created. Thereafter, an enumerationMapping object is created (step  194 ), and the enumerationMapping object is linked to the enumeration object and to a simple type definition (step  195 ). For each enumeration value an enumeration literal object is then created and mapped (step  196 ). The algorithm then returns to step  164  shown in  FIG. 10 . 
       FIG. 13  is a flow chart illustrating computeAtomicType ( 200 ) invoked in step  174  shown in  FIG. 11 . In step  202 , a corresponding data type is determined using a translation table in a manner well known in the art. The field is then updated based on the data type (step  204 ) and the algorithm returns to step  174  shown in  FIG. 11 . 
       FIG. 14  is a flow chart illustrating mapDataComponent ( 210 ) invoked in step  156  shown in  FIG. 9 . In step  212 , the algorithm creates a data object, and then creates a componentMapping object (step  214 ). The algorithm then links the componentMapping object to the data object and to a complex type definition (step  215 ). The algorithm then invokes handleComplexTypeDefinition in step  216  and returns to step  156  shown in  FIG. 7 . 
       FIGS. 15   a  and  15   b  illustrate the algorithm function handleComplexTypeDefinition ( 220 ) invoked from step  216  shown in  FIG. 14 . In step  222  the algorithm determines whether the complex type definition has a base type. If so, the algorithm first invokes the function mapDataComponent (step  224 ) shown in  FIG. 14 , on the base type. The algorithm then sets the data object as a prototype for the current complex type (step  226 ) and in step  228  determines a category of the current complex type in a manner well known in the art. In step  230  it is determined whether the category is an empty type. If so, the algorithm branches to step  256  shown in  FIG. 15   b . If not, it is determined whether the category is a simple type (step  232 ). If so, the algorithm invokes the function handleSimpleContent (step  234 ) and branches to step  256  shown in  FIG. 15   b . If not a simple type, the algorithm determines whether the category is a mixed type (step  236 ). If so, the data object and componentMapping object are discarded (step  237 ) and the algorithm returns to step  216  shown in  FIG. 14 . If the category is not a mixed type the algorithm determines whether the category is Element_Only type (step  238 ). If so, the algorithm invokes handleParticle (step  240 ) and branches to stop  256  of  FIG. 15   b . If not, the algorithm selects a first attribute (step  242 ) and determines in step  244  if the attribute is a fixed constraint. If so, it is determined in step  250  whether there is another attribute and the process branches back to step  244 . If the attribute is not a fixed constraint, it is determined in step  246  whether the attribute is a prohibited use. If so, it is determined in step  250  whether there is another attribute and the process branches back to step  244 . If not, handleAttributeDeclaration is invoked in step  248  and the process branches to step  250 . It is determined in step  252  whether the complex type has an “AnyAttribute” type. If so, the function handleAnyAttribute is invoked (step  254 ) and the complex type definition is passed to the function. If not, it is determined in step  256  whether there are any fields in the data object. If there are fields in the data object the algorithm returns to step  216  shown in  FIG. 14 . If there are no fields in the data object, the algorithm discards the data object and the componentMapping object (step  258 ) and returns to step  26  shown in  FIG. 14 . 
       FIG. 16  is a flow chart showing the portion of the algorithm named handleAttributeDeclaration ( 260 ) invoked from step  248  of  FIG. 15   b . In step  262 , the algorithm creates a data field object and in step  264  the algorithm creates a fieldMapping object. Thereafter, the algorithm links the fieldMapping object to the data field object and to attribute declaration (step  265 ) and invokes handleSimpleTypeDefinition (step  266 ) shown in  FIG. 10 . The algorithm then returns to step  248  of  FIG. 15   b.    
       FIG. 17  is a flow chart of the portion of the algorithm function handleAnyAttribute ( 270 ) invoked from step  254  of  FIG. 15   b . In step  272 , the algorithm creates a data field object and in step  274  creates a fieldMapping object. The algorithm then links the fieldMapping object to the data field object and to the anyAttribute (step  275 ) and sets the data field type to “string” (step  276 ). The algorithm then returns to step  254  of  FIG. 15   b.    
       FIG. 18  is a flow chart of an algorithm function called handleSimpleContent ( 278 ) in accordance with the invention. In step  279  the algorithm creates a data field object and in step  280  the algorithm creates a fieldMapping object, then determines the content type (step  281 ). The algorithm then invokes the function handleSimpleTypeDefinition (step  282 ) and passes the content type definition to it. 
       FIG. 19  is a flow chart of the algorithm function handleParticle ( 300 ) invoked from step  240  of  FIG. 15   a . In step  302 , the algorithm determines whether the particle is an element declaration. If not, the algorithm determines whether the particle is “Any” type (step  304 ). If not an element declaration or an “Any” type, (step  306 ) the particle is a model group. If the particle is a model group, the algorithm invokes handleModelGroup (step  308 ). 
     If is was determined in step  302  that the particle is an element declaration, the algorithm creates data field object (step  310 ) and creates a fieldMapping object (step  312 ). The algorithm then links the fieldMapping object to the data field object and to the element declaration (step  318 ). It then determines whether the maximum occurrences is greater than one (step  320 ) and, if so, sets the field array property to “true” (step  328 ) and returns to step  240  of  FIG. 15   a.    
     Otherwise, if the particle is determined to be “Any” type (step  304 ), the algorithm creates a data field object (step  314 ), creates a field mapping object (step  315 ), and the algorithm links the fieldMapping object to the data field object and to an “Any” type (step  316 ). The algorithm then sets the filed type to “string” (step  326 ), and determines whether a maximum number of occurrences is greater than one (step  330 ). If not, the algorithm returns to step  240  of  FIG. 15   a . Otherwise, the algorithm sets a field array property to “true” (step  332 ). The algorithm then returns to step  240  in  FIG. 15   a.    
       FIG. 20  is a flow chart illustrating handleModleGroup ( 283 ) invoked from step  308  of  FIG. 18 . In step  284 , the algorithm selects a first particle in the model group. The algorithm then invokes (step  285 ) handleParticle ( 300 ) shown in  FIG. 19 . The algorithm then determines in step  286  whether there is another particle in the model group. If so, the algorithm once again invokes handleParticle (step  285 ) and this process reiterates until all particles in the model group have been processed. Thereafter, the algorithm returns to step  308  of  FIG. 19 , and subsequently to step  240  of  FIG. 15   a.    
     As will be understood by those skilled in the art, the algorithm set forth above creates a wireless device application from a web service definition. As will be further understood by those skilled in the art, wireless device resources are limited as is data transfer bandwidth available for wireless communications. The data structures and messages created by the algorithm described above with reference to  FIGS. 6-19  are therefore preferably simplified by flattening complex data structures and using other methods of field size and message complexity reduction as described in Applicant&#39;s co-pending patent applications related wireless message and data simplification. 
     As will be further understood by those skilled in the art, the above-described algorithm represents only one way in which a wireless application may be generated using a web service definition. The algorithm described above with reference to  FIGS. 6-19  is therefore intended to be exemplary only. The scope of the invention is therefore intended to be limited solely by the scope of the appended claims.