System and method for generic data mapping between wireless component applications and application data sources

An application gateway is configured to facilitate message communication between an application executing on a wireless device and a backend server. The application gateway comprises a message interface, a backend connector and a transformer. The message interface facilitates communication between the wireless device and the application gateway in a compact format. The backend connector facilitates communication between the application gateway and the backend server using a schema-based internal format. The transformer translates data between the compact format and the internal format. The transformer further includes a transformer mapping document for correlating elements in the compact format with elements in the internal format.

This application relates generally to schema-based documents and specifically to a system and method for using such documents to facilitate generic data mapping between wireless component applications and corresponding application data sources.

BACKGROUND OF THE INVENTION

Due to the proliferation of wireless networks, there are a continually increasing number of wireless devices in use today. These devices include mobile telephones, personal digital assistance (PDAs) with wireless communication capabilities, two-way pagers and the like. Concurrently with the increase of available wireless devices, software applications running on such devices have increased their utility. For example, the wireless device may include an application that retrieves a weather report for a list of desired cities or an application that allows a user to shop for groceries. These software applications take advantage of the ability to transmit data of the wireless network in order to provide timely and useful services to users, often in addition to voice communication. However, due to a plethora of different types of devices, restricted resources of some devices, and complexity of delivering large amounts of data to the devices, developing software applications remains a difficult and time-consuming task.

Currently, devices are configured to communicate with Web Services through Internet based Browsers and/or native applications. Browsers have the advantage of being adaptable to operate on a cross-platform basis for a variety of different devices, but have a disadvantage of requesting pages (screen definitions in HTML) from the Web Service, which hinders the persistence of data contained in the screens. A further disadvantage of Browsers is that the screens are rendered at runtime, which can be resource intensive. Applications for browsers are efficient tools for designing platform independent applications. Accordingly, different runtime environments, regardless of the platform, execute the same application. However, since difference wireless devices have different capabilities and form factors, the application may not be executed or displayed as desired. Further, browser based application often require significant transfer bandwidth to operate efficiently, which may be costly or even unavailable for some wireless devices.

On the other hand, native applications are developed for a specific wireless device platform, thereby providing a relatively optimized application program for a runtime environment running on that platform. However, a platform dependent application introduces several drawbacks, including having to develop multiple versions of the same application and being relatively large in size, thereby taxing memory resources of the wireless device. Further, application developers need experience with programming languages such as Java and C++ to construct such native applications.

Further, client applications running on wireless devices are often required to transfer data between the wireless device and an application data server, generically referred to as a backend server. Accordingly, an intermediary server facilitates message communication between the wireless device and the backend server. In order to accomplish this, the messages and their parts are mapped between client applications and the backend servers.

However, for the wireless paradigm it is useful to limit the data volume exchanged with a wireless device. Thus, although certain backend servers may provide valuable information, it may be impractical to wirelessly communicate this information in the absence of an accommodating schema transformation that will also optimize the data structure at the handheld level.

Accordingly there is a need for a system and method to facilitate providing a developer with access to a plurality of different backend servers while developing an application in order to overcome some of the disadvantages of the prior art.

SUMMARY OF THE INVENTION

In accordance with the present invention there is provided an application gateway configured to facilitate message communication between an application executing on a wireless device and a backend server, the application gateway comprising: a message interface for facilitating communication between the wireless device and the application gateway in a compact format; a backend connector for facilitating communication between the application gateway and the backend server using a schema-based internal format; and a transformer for translating data between the compact format and the internal format, the transformer including a transformer mapping document for correlating elements in the compact format with elements in the internal format.

In accordance with a further aspect of the present invention there is provided a method for translating data from an internal format used for facilitating communication with a backend server to a compact format used for communicating with a wireless device, the method comprising the steps of: receiving a message in the internal format; retrieving a corresponding transformer mapping document; and mapping data from the received message in the internal format to the compact format in accordance with the transformer mapping document for communication to the wireless device.

In accordance with yet a further aspect of the present invention there is provided a method for translating data from an internal format used for facilitating communication with a backend server to a compact format used for communicating with a wireless device, the method comprising the steps of: receiving a message in the internal format; retrieving a corresponding transformer mapping document; and mapping data from the received message in the internal format to the compact format in accordance with the transformer mapping document for communication to the wireless device.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

For convenience, like numerals in the description refer to like structures in the drawings. Referring toFIG. 1, a communication infrastructure is illustrated generally by numeral100. The communication infrastructure100comprises a plurality of communication devices102, or simply devices102, a communication network104, an application gateway106and a plurality of backend servers108.

The devices102include both wired and wireless computing devices such as a desktop computer, a laptop or other portable computer, a smart phone, a personal digital assistant (PDA), and the like. The devices102are in communication with the application gateway106via the communication network104. Accordingly, the communication network104may include several components such as a wireless network110, a relay112, a corporate server114and/or a mobile data server116for relaying data between the devices102and the application gateway106.

The application gateway106comprises a gateway server118a provisioning server120and a discovery server122. The gateway server118is in communication with both the provisioning server120and the discovery server122. The gateway server110is further in communication with a plurality of the backend servers108, such as web services108a, database services108b, as well as other enterprise services108c, via a suitable link. For example, the gateway server110is connected with the web services108aand database services108bvia Simple Object Access Protocol (SOAP) and Java Database Connectivity (JDBC) respectively. Other types of backend servers108and their corresponding links will be apparent to a person of ordinary skill in the art. Accordingly, it can be seen that the gateway server118acts as a message broker between the devices102and the backend servers108.

Each wireless device102is initially provisioned with a service book establishing various protocols and settings, including connectivity information for the corporate server114and/or the mobile data server116. These parameters may include a Uniform Resource Locator (URL) for the application gateway server118as well as its encryption key. Alternately, if the wireless device102is not initially provisioned with the URL and encryption key, they may be pushed to the wireless device102via the mobile data server116. The mobile device102can then connect with the application gateway106via the URL of the application gateway server118.

Referring toFIG. 2, a more detailed view of the application gateway106is shown. The application gateway server118includes three layers of service; a base services layer202, an application gateway services layer204and an application services layer206. The application gateway server118further includes an administration service208.

A provisioning service210and a discovery service212are provided by the provisioning server120and discovery server120, respectively.

At the lowest level, the base services layer202offers basic, domain independent system services to other components in higher levels. Thus, for example, all subsystems in the application gateway services layer204and the application services layer206can utilize and collaborate with the subsystems in the base services layer202. In the present embodiment, the base services layer202includes a utilities subsystem210, a security subsystem212, a configuration subsystem214, and a logging subsystem216.

The application gateway services layer204provides wireless component application domain specific services. These services provide efficient message transformation and delivery to backend systems108and provide wireless device102and component application lifecycle management. In the present embodiment, the application gateway services layer204includes a lifecycle subsystem220, a connector subsystem222, a messaging subsystem224, a mapping subsystem225, and a transformation subsystem226.

The application services layer206sits at the top of the architecture and provides external program interfaces and user interfaces using subsystems provided by the lower layers. For example, various applications such as a service provider lifecycle application, a packaging application and a message listening application provide external program interfaces since they communicate primarily with applications on external systems. Similarly, an administration application provides a user interface by providing a user with ability to access and potentially modify application gateway data and/or parameters.

The administration service208is responsible for administrative system messages, administration of the wireless devices102, runtime administration of the application gateway subsystems, support and display system diagnostics, and administration of default implementations of the provisioning and discovery services. Relevant portions of the application gateway are described in details as follows.

Message Listening Application

The messaging listening application provides an interface for receiving messages from the devices102as well as external sources and forwarding them to the messaging subsystem. Further, the message listening application typically authenticates that the source of the message is valid.

Referring toFIG. 3, the message listening application is shown in greater detail. The message listening application includes several listeners; a notification listener302, a compact message listener304, and a mobile data service acknowledgement listener306. The notification listener302receives notification and response messages from event sources108cvia a notification interface303.

For example, the notification interface303may be implemented using Web Service (WS) Eventing. Web services often want to receive messages when events occur in other services, such as the event sources, and applications. A mechanism for registering interest is provided in the art by WS Subscription. WS Subscription defines a protocol for one Web service, referred to as a subscriber, to register interest with another Web service, referred to as an event source for receiving messages about events, referred to as notifications. When the event source notifies the subscriber of an event, it is referred to as WS Eventing.

The compact message listener304receives messages from the devices102via a compact message interface305. The mobile data service acknowledgment listener306receives and acknowledges notifications from the mobile data service116via a mobile data service interface307. Each of the listeners302,304and306receive administrative messages from the administration service208via a listener administrative interface311.

In the present embodiment the listener interfaces303,305,307and311are configured using Hypertext Transfer Protocol/Hypertext Transfer Protocol over Secure Socket Layer (HTTP/HTTPS). However, it will be appreciated by a person skilled in the art that these protocols have been selected as a design choice and other protocols may be used when desired. Accordingly, external systems transmit a HTTP/HTTPS request, which is received by the appropriate listener. The listener takes the message, makes minimal transformations, and forwards it to the messaging subsystem224. The transformations include copying HTTP header information into message object fields. For example, the HTTP header information may identify the mobile data service116and wireless device102from which the message originated.

As previously described, the message listening application authenticates that the source of the message is valid, be it the mobile date service116, the wireless device102or event source108. Further, if reliable messaging is required, service availability is ensured and the listeners deal with availability attack solutions. In order to facilitate this, the messaging subsystem defines a threshold for a maximum number of messages and connections for a given time period from any backend server108, component application or device102. The administrator can modify this threshold as desired, as well as allow for specific exceptions via the administration service208.

Further, since message interception and replay attack are possible, the listeners detect and prohibit this attack using mechanisms that identify replayed messages. These mechanisms typically include the use of a nonce. A nonce is defined as parameter that varies with time. A nonce can be a timestamp or other special marker intended to limit or prevent the unauthorized replay or reproduction of a message. Because a nonce changes with time, it can be used to determine whether or not a message is original, or a replay or reproduction of the original message. The use of a nonce for preventing interception and replay attacks is known in the art and need not be described in detail, as standard implementations are utilized.

Further, other technologies, such as sequencing, can also be used to prevent replay of application messages in addition to, or in lieu of, the time timestamp technique. Once again, such techniques are known in the art and need not be described in detail, as standard implementations are utilized.

Messaging Subsystem

The messaging subsystem224handles messages that are either system or component application specific. The messaging subsystem224is also responsible for the integrity and maintenance of all messages to be delivered by the application gateway106. Upon receiving a message, the messaging subsystem224queues it, optionally stores it (for reliability both to and from the application gateway106) and prepares it for further delivery to its destination.

Referring toFIG. 4a, the messaging subsystem224is shown in greater detail. The messaging subsystem224includes a message broker402and a message depot404. A message processor interface406couples the message broker402with the message listeners232, the connector subsystem222, the transformation subsystem226and other application gateway subsystems. A message processor administration interface408couples the message depot404with the administration subsystem208and provides an interface to administer and configure the messaging subsystem224.

The message broker402is responsible for validating, processing and forwarding messages in the appropriate format to the proper connector in the connector subsystem. The message broker402communicates with the lifecycle subsystem220to retrieve information about wireless devices102and component applications. If a message mapping targets multiple wireless devices, the message broker402creates a message for each wireless device. The message broker404further performs scheduled message maintenance jobs. Primarily, this results in removing expired messages. An administrator can schedule the time and frequency of these maintenance jobs via the administration subsystem.

The message broker402further manages subscription information and broadcasts messages to all subscribers when notified.

The message depot404is used to store information about messages, any information related to reliable mapping, messaging, subscriptions and correlation information.

Mapping Subsystem

The mapping subsystem225provides mappings for use during execution of the application. Typically, when a new application is provisioned on the application gateway, the mapping subsystem225generates a pair of mappings that are used by the transformation subsystem226during runtime.

Referring toFIG. 4b, the mapping subsystem225is shown in greater detail. The mapping subsystem225includes a mapping module452that operates on several pieces of data provided in an application bundle for the new application. Such data includes a portion of the application definition454, a mapping document456, and a corresponding Web Service Definition Language (WSDL) document.

WSDL is a document written in XML for describing a web service, the details of which will be apparent to a person skilled in the art. Further, since WSDL is inherently extensible, it can be used for allowing WSDL documents to describe services other than web services, such as, for example, a relational database. The use of WSDL extensibility to connect to different backend servers, however, is beyond the scope of the present invention and therefore need not be described in detail.

A complete WSDL definition includes all of the information used to invoke the backend server. Thus, in addition to messages, operations, and interfaces, a WSDL document specifies the location of a backend server and the operations the backend server exposes. Accordingly, a person skilled in the art will appreciate that WSDL provides a way to group messages into operations and operations into interfaces. It also provides a way to define bindings for each interface and protocol combination along with the endpoint address for each one. Thus, the WSDL document effectively decouples the messages for communicating with a backend server from the connectivity information required to make the connection. Developers that want to make it easy for others to access their backend servers, publish their WSDL definitions.

Accordingly, when an application is developed, the application developer or the application development environment provides the component application definition454, the corresponding WSDL document458, and the mapping document456as part of a bundle. When an application is installed on the application gateway a first time, the mapping module uses the component application definition454, the corresponding WSDL document458, and the mapping document456for building an application transformation mapping460and a WSDL mapping462.

The application transformation mapping460comprises a field binding path for each relevant field in the component application definition454. The WSDL mapping462comprises a mapping for each operation used by the component application definition454along with its associated messages, including requests, responses, and notifications.

In operation, the application transformation mapping460is used as a binding path for each application message to a lookup table. The WSDL mapping462is used to map the messages in the WSDL document to the lookup table. Accordingly, it can be seen that the lookup table acts as an intermediary buffer between messages transmitted between the application gateway and the wireless device and messages transmitted between the application gateway and the backend server. This provides an application developer with the flexibility to alter the presentation or structure of the application, without affecting the communication between the backend server, as long as the mapping456accurately reflects the relationship between the application and the WSDL document.

Since WSDL effectively compartmentalizes messages, operations, interfaces and bindings, it will be appreciated that the same mapping456can be implemented regardless of the type of backend server with which the component application is in communication. Accordingly using such a mapping mechanism can reduce complexity at the application gateway, thereby enhancing scalability, especially with respect to scalability across a plurality of heterogeneous backend servers.

Referring to Appendix A, a sample, mapping schema used in accordance with the present embodiment is provided. Referring to Appendix B, a sample transformer mapping file for a corresponding component application is provided. A corresponding WSDL file, excluding binding information, for the transformer mapping file in Appendix B is provided in Appendix C.

Transformation Subsystem

The transformation subsystem226transforms messages flowing between the wireless devices102and application gateway106into either an internal message format or a compact message format. The internal message format is convenient for internal subsystems. The compact message format is used for transmission over the air to the wireless device102in order to minimize the bandwidth used.

Referring toFIG. 5, the transformation subsystem226is shown in greater detail. The transformation subsystem226comprises a compact transformer502and a decompact transformer504, each of which communicate with the message subsystem224via a compact interface506and a decompact interface508, respectively. When the message subsystem224receives a message from an internal subsystem that is destined for a wireless device102, it is likely that the message will be in the internal message format. Therefore, the message subsystem224transforms the message into the compact message format using the compact transformer502. When the message subsystem224receives a message from a wireless device102that is destined for an internal subsystem, it is likely that the message will be in the compact message format. Therefore, the message subsystem224transforms the message into the internal message format using the decompact transformer504. It will be apparent to a person of ordinary skill in the art that custom transformers can be added to the transformation subsystem226to facilitate custom message formats.

In order to facilitate the transformation for a given application, the application transformer mapping460and WSDL transformer mapping are used for identifying the transformation needs to occur for a given message. It should be noted that a malicious transformer mapping could cause an arbitrary transformation to be performed, which may have negative security implications, such as executing an infinite loop and exhaust system resources. Accordingly, transformer mappings are validated when they are deployed.

Connectors Subsystem

The connector subsystem222provides transport services between the application gateway106and external destination systems using the required transport protocols. Further, the connector subsystem222receives synchronous responses from destination systems, and passes them to the message subsystem224for processing.

Referring toFIG. 6, a more detailed view of the connector subsystem222is shown. The connector subsystem222includes a MDS connector602, a system connector604and a set of backend connectors606. The MDS connector602is coupled with the message subsystem224via a MDS connector interface603. The system connector604and backend connectors606are coupled with the message subsystem224via a connector interface605.

The MDS connector interface603is a Java API for message delivery to the wireless devices102in the compact message format. The connector interface605is a Java API for message delivery to internal subsystems or backend systems. The messages are in the internal message format.

The MDS connector602delivers compact messages to the wireless device via the MDS116. The MDS connector602works as push initiator to push messages to wireless devices102. In the present embodiment the MDS connector602supports basic push as well as the reliable push to MDS through the Wireless Application Protocol (WAP) to Push (PAP) standard protocol, although other standards can be supported as they are developed.

The system connector602delivers system messages to the lifecycle subsystem220, the administration subsystem208, or the messaging subsystem224. Delivery of system messages to any of the specified subsystems is performed by direct API calls. The system connector receives the messages in the internal message format and performs java API calls to the appropriate subsystem.

The backend connectors606include several standard connectors, including a database connector608, a SOAP connector610and a WS Eventing connector612. Further, both the connector interface605and the internal message format will be published and, therefore, third party integrators can implement custom backend connectors as required.

The database connector608receives messages in the internal message format and transforms them into Structured Query Language (SQL) statements. The database connector608then executes the SQL statements against a destination database server through JDBC. Using mapping information defined for each message, the database connector608creates a JDBC connection and prepares and/or executes the SQL statements. The database connector608receives the query result from the destination database server108band passes it back to the messaging subsystem in the internal message format.

The SOAP connector610receives messages in the internal message format, transforms them to SOAP format, and delivers the SOAP request messages to backend Web Services108using the Web Service SOAP binding over HTTP protocol. Both Remote Procedure Call (RPC)-style and Document-style Web Services are supported. The SOAP connector610also receives synchronous SOAP response messages to each request from backend Web Services, transforms the message to the internal message format, and passes it to the messaging subsystem224.

The SOAP connector610further supports encryption of SOAP messages to Web Service backend destinations through the standard HTTPS protocol. It should be noted that end-to-end security could be achieved if both the application gateway and the secure Web Service are deployed behind the same firewall.

The WS-Eventing connector612is a specialized SOAP connector that supports the WS-Eventing protocol for handling WS-Eventing subscription requests.

Accordingly, it will be appreciated by a person skilled in the art that other backend servers108can be accessed by providing a corresponding connector. In the present embodiment, this functionality is provided by developing connectors to explicitly implement an extended WSDL document. The binding and service elements of the WSDL document are programmed specifically to take advantage of the corresponding connector.

Transformer Mapping

In the present embodiment, for example, the compact message format is a minimal messaging format, which may or may not be binary coded, and the internal message format is compliant with WSDL.

Referring toFIG. 7, the operation of creating the application transformer mapping460is illustrated generally by numeral700. In step702, an application is installed on the application gateway, which is provided with a bundle including the application definition454, the mapping document456, and the WSDL document458.

In step704, mapping module452parses the mapping document456and the application definition454and creates a list of the operations used by the application. The mapping module452also creates the field binding path for fields in the messages used by the application and a corresponding look up table. This combination of information is referred to as the application transformer mapping460. In step706, the mapping module452parses the mapping document456and the WSDL document458and creates the WSDL transformer mapping462.

This operation can be exemplified with reference to the WSDL document illustrated in Appendix C, the mapping document illustrated in Appendix B, and a corresponding relevant portion of a component application definition illustrated in Appendix D.

In step702, the mapping document is parsed and the list of operations used by the application is retrieved. In the present example only one operation “whatCar” is used.

In step704, a field binding path is created for each field in each message in the mapping document. These fields include “plate”, “name”, “phoneNumber”, “emailAddr”, “make”, and “year”, and the field binding path is:

Further, a lookup table is created with tags for each field in lookup table labelled in accordance with the second column of the field binding path.

In step706, it is realized that the WSDL transformer mapping462is, in fact, the fully qualified WSDL path. Accordingly, it will be appreciated that the second column in the field binding path corresponds with the fully qualified WSDL path and an additional lookup table does not need to be created. Rather, upon parsing the WSDL document and the field binding path, the correlation between the WSDL message definitions and the application message can be determined.

Referring toFIG. 8, a flow chart illustrating the operation of using the created transformer mappings for facilitating communication between an application on a wireless device and the connector is illustrated generally by numeral800. In step802, the wireless device transmits a message to the application gateway, the message including one or more tags and associated data. In step804, the application gateway receives the message, identifies the originating application, and communicates the information to the transformation subsystem. In step806, the decompactor retrieves the corresponding application transformer mapping and applies it to the received message for populating the lookup table with the appropriate message values.

In step808, the transformation subsystem constructs the outgoing message to be sent to the backend server. The transformation subsystem uses the WSDL transformer mapping to retrieve the received data from the lookup table for constructing the request. If a required value was not received from the application, a default value or predefined value may be used. In step810, the outgoing message is transmitted to the connector subsystem for transmission to the backend server. The connector subsystem encapsulates the message is defined by a binding element of the WSDL document and connects with the backend server in accordance with a service element of the WSDL document.

In step812, a response is received from the backend server at the transformation subsystem via the connector subsystem. In step814, the response is mapped to the lookup table using the WSDL transformer mapping462and the field names as keys. In step816, the compactor determines which fields of the lookup table the application is expecting as part of the response. In step818, the values from the lookup table are applied to the corresponding message fields and are transmitted from the application gateway to the wireless device.

This operation can be exemplified by continuing the previous example. In step802, the application transmits a message named “whatCarReq” comprising field name “plate” having a value “ABC123”. In step806, the decompactor applies the application transformer mapping460and stores “ABC123” in lookup table field named “plate”

In step808, the transformation subsystem determines that for the operation “whatCar”, the input message “impl:whatCarReq” has only one part named “plate”, which maps to “plate”. Accordingly, the lookup table is parsed for the value of “plate” and the request constructed is as follows:

In step812, a response is received in the form:

In step814the transformation subsystem parses the response so that it is in the following form:

Once the data has been parsed it is mapped to the lookup table using the previously defined WSDL transformer mapping462, which is simply the fully qualified WSDL document listed above.

In step816, the transformation subsystem determines that the response to be sent to the wireless device include the field “car”, which is a complex type comprising “owner”, “make”, and “year”. Further, owner is a complex type comprising “name”, “phoneNumber”, and “emailAddress”. Therefore, the fields that need to be sent to the wireless device include “name”, “phoneNumber”, “emailAddress”, “make”, and “year”. Accordingly, in step818, the values for these fields are retrieved from the lookup table using the field binding path of application transformation mapping460and transmitted to the wireless device.

Accordingly, it will be appreciated that the transformation and mapping subsystems described above, and the operations thereof, decouple the definition and structure of messages in an application from the WSDL definition of the messages to be communicated with the backend server. Thus, an application developer has the flexibility to create completely a different structure for application to that defined for the backend server if desired, as long as the required values are provided in the message fields.

Although the embodiment described above refers specifically to WSDL and XML, a person of ordinary skill will appreciate that the standards described herein can be adapted to conform to other standards or proprietary schema that provide similar functionality, as desired.