EFFICIENT TRANSACTIONAL MESSAGING BETWEEN LOOSELY COUPLED CLIENT AND SERVER OVER MULTIPLE INTERMITTENT NETWORKS WITH POLICY BASED ROUTING

• US 20110276636A1
• Filed: 03/29/2010
• Published: 11/10/2011
• Est. Priority Date: 03/29/2010
• Status: Abandoned Application

• Current Assignee: KonaWare, Inc. (Digisec Group LLC)
• Original Assignee: KonaWare, Inc. (Digisec Group LLC)
• Inventors: Cheng, Wesley, Gronberg, Martin
• Application Number:
  US12/749,412
• Publication Number:
  US 20110276636A1
• Time in Patent Office: Days
• US Class Current: 709/206
• CPC Class Codes: H04L 51/214 using selective forwarding
• CPC Class Codes: H04L 69/14 Multichannel or multilink protocols
• CPC Class Codes: H04L 69/18 Multiprotocol handlers, e.g. single devices capable of handling multiple protocols

Abstract

The KonaWare Framework is a collection of software components that provide bi-directional transactions between wireless/mobile devices and enterprise server applications. Transactions are achieved between client and server by breaking up the sequence such that the client does not have to wait until the transaction is completed before relinquishing the network connection. By using asynchronous messaging, the message is persisted at every step and can be handed off to the next stage without waiting. The reply from the server comes back to the client as an asynchronous message and completes the transaction. Bi-directional messaging is achieved using server-initiated push techniques such as modem signaling, http listener, SMS or polling using an efficient decaying algorithm. Messages are sent via communication channels that can be a combination of a physical network and a service provider. Networks are automatically detected by observing changes in the TCP/IP route table and configured by altering the default route. Service providers are determined by using identification servers accessible only in specific networks; if reachable, then it is that network. Transmission rules are formed using regular expressions to combine system, message and channel parameters. These are changed at any time and sent dynamically as system messages to target devices. Loosely coupled client-server applications are developed without coding by declarative programming using relating business objects and graphical objects and mapping them into messages using properties sheets. Conflict-free database synchronization is achieved by assigning a master database and making the others slave databases whose updates are considered pending until confirmed by the master database. A lightweight LUCID (Logic Up, Consistent Information Down) model works by sending acknowledgement messages instead of the entire reply record.

Claims

1. A method for reducing the cost of sending messages over intermittent networks via one or more communication channels, the method comprising:

(a) creating a first message on a server, the message intended to be sent to a mobile device over multiple intermittent networks;

(b) applying a first policy containing one or more rules to determine whether to send the first message to the mobile device, each rule being a function of one or more messaging attributes of messages, channels or system environment; and

(c) dynamically updating the first policy by sending a second message to the mobile device, the second message being a system message that results in the addition, deletion or other modification of the rules contained in the policy.

2. A method for implementing efficient guaranteed transactional messaging on an intermittent network of computing devices, the method comprising the steps of:

(a) creating a first transaction on a first device, the first transaction including one or more messages intended to be exchanged with a second device over the network;

(b) creating a first device queue on the first device, the first device queue reflecting the current status of the first transaction, including which messages of the first transaction have been successfully or unsuccessfully sent or received;

(c) creating a second device queue on the second device, the second device queue reflecting the current status of the first transaction, including which messages of the first transaction have been successfully or unsuccessfully sent or received; and

(d) guaranteeing receipt by the first device of a notification that a message of the first transaction sent by the first device was successfully or unsuccessfully received by the second device, even in the event that the first device or the second device loses network connectivity prior to the first device receiving such notification.

3. The system of claim 2, comprising automatically detecting networks by observing changes in a TCP/IP route table and configured by altering the default route

4. The system of claim 2, comprising running loosely coupled client-server applications without coding by declarative programming using relating business objects and graphical objects and mapping the objects into messages using properties sheets.

5. A system, comprising:

a server;

a plurality of wireless networks coupled to the server; and

one or more mobile devices coupled to the wireless networks with intermittent access to the wireless networks, the plurality of wireless networks providing messaging between client and server applications over multiple intermittent connections.

6. The system of claim 5, comprising means for reducing the cost of sending messages over intermittent networks via one or more communication channels.

7. The system of claim 5, comprising code to:

(a) create a first message on a server, the message intended to be sent to a mobile device over multiple intermittent networks;

(b) apply a first policy containing one or more rules to determine whether to send the first message to the mobile device, each rule being a function of one or more messaging attributes of messages, channels or system environment; and

(c) dynamically update the first policy by sending a second message to the mobile device, the second message being a system message that results in the addition, deletion or other modification of the rules contained in the policy.

8. The system of claim 5, comprising code to provide bi-directional transactions between wireless/mobile devices and enterprise server applications.

9. The system of claim 5, comprising code tobreak up the sequence such that the client does not have to wait until the transaction is completed before relinquishing the network connection.

10. The system of claim 5, comprising code to perform asynchronous messaging, where the message is persisted at every step and can be handed off to a next stage without waiting.

11. The system of claim 5, comprising code to process a reply from the server t as an asynchronous message and complete the transaction.

12. The system of claim 5, comprising code to perform bi-directional using server-initiated push.

13. The system of claim 5, wherein messages are sent via communication channels comprising a combination of a physical network and a service provider.

14. The system of claim 5, wherein networks are automatically detected by observing changes in the TCP/IP route table and configured by altering the default route.

15. The system of claim 5, wherein service providers are determined by using identification servers accessible only in specific networks.

16. The system of claim 5, wherein transmission rules are formed using regular expressions to combine system, message and channel parameters.

17. The system of claim 5, comprising loosely coupled client-server applications developed without coding by declarative programming using relating business objects and graphical objects and mapping the objects into messages using one or more properties sheets.

18. The system of claim 5, wherein conflict-free database synchronization is achieved by assigning a master database and making the others slave databases whose updates are considered pending until confirmed by the master database.

19. The system of claim 5, comprising a lightweight LUCID (Logic Up, Consistent Information Down) model.

20. The system of claim 5, comprising code to support a lightweight LUCID (Logic Up, Consistent Information Down) model works by sending acknowledgement messages instead of the entire reply record.