Messaging proxy system
09906487 ยท 2018-02-27
Assignee
Inventors
Cpc classification
H04W88/182
ELECTRICITY
H04L69/16
ELECTRICITY
H04L67/34
ELECTRICITY
H04L67/565
ELECTRICITY
H04L69/169
ELECTRICITY
H04L67/04
ELECTRICITY
H04L67/2876
ELECTRICITY
International classification
Abstract
A messaging proxy system is disclosed for the purpose of delivering data in the form of a portable message format from a producer running on a mobile or non-mobile computer, over any wireless network, by passing this data through an intermediary proxy computer program, to one or more recipients running on mobile or non-mobile computers. The system includes a message proxy computer program with at least one pluggable transport protocol adapter. The proxy contains a command subsystem for sending and receiving command- and message-tokens to and from the mobile clients. The system further includes a thin messaging middleware client to run on mobile devices. The thin messaging middleware client includes at least one pluggable protocol adapter. The client also comprises a command subsystem for sending and receiving command- and message-tokens to and from the proxy The proxy also contains a communication subsystem for sending and receiving messages via a state of the art message oriented middleware.
Claims
1. A system comprising: a server comprising at least one processor, a proxy being configured to operate on the at least one processor, the proxy being configured to: receive a first command token from a client, the first command token containing subscription information of a topic to which the client wishes to subscribe, the first command token further containing a publisher code for the topic, the publisher code being a number; subscribe to the topic on behalf of the client according to the subscription information; associate the publisher code with identification information of the subscribed topic, the identification information being larger than the publisher code; receive a second command token from the client, the second command token comprising the publisher code and a first message, the second command token not including the subscription information of the topic; retrieve the identification information of the subscribed topic according to the publisher code in the second command token; and publish the first message on the subscribed topic.
2. The system of claim 1, wherein the proxy is further configured to: receive a third command token from the client, the third command token comprising the publisher code and an indication that the client wishes to unsubscribe from the topic; retrieve the identification information of the subscribed topic according to the publisher code in the third command token, the third command token not including the subscription information of the topic; and unsubscribe from the subscribed topic on behalf of the client.
3. The system of claim 1, wherein the client is a wireless client.
4. The system of claim 1, wherein the proxy is further configured to: receive a second message from a message oriented middleware system related to the topic; and send the second message to the client using the identification information.
5. The system of claim 1, wherein the proxy is configured to maintain the identification information in a database.
6. The system of claim 1, wherein the proxy is further configured to maintain messages sent to the client in a database.
7. The system of claim 1, wherein the proxy is further configured to send messages to the client according to a guaranteed quality of service.
8. A system comprising: a user device comprising at least one processor, a message client being configured to operate on the at least one processor, the message client being configured to: create a publisher object for a topic, create a first command token in response to the creation of the publisher object, the first command token comprising a create-publisher command code, a topic code for the topic, and a publisher code, the publisher code being a number, send the first command token to a proxy to subscribe to the topic, create a message using the publisher object; create a second command token in response to the creation of the message using the publisher object, the second command token comprising a publish command code, the message, and the publisher code, the second command token not including the topic code for the topic, and send the second command token to the proxy.
9. The system of claim 8, wherein the message client is further configured to: create a third command token, the third command token comprising an unsubscribe command code and the publisher code, the third command token not including the topic code for the topic, and send the third command token to the proxy.
10. The system of claim 8, wherein the message client is not configured to have an actual representation of the topic.
11. The system of claim 8 further comprising a database adapter configured to maintain messages sent to the proxy in a database.
12. The system of claim 8 further comprising a protocol adapter configured to send messages sent to the proxy according to a guaranteed quality of service.
13. The system of claim 8, wherein the publisher code is a one-byte number.
14. A system comprising: a user device comprising at least one first processor, a message client being configured to operate on the at least one first processor; and a server comprising at least one second processor, a proxy being configured to operate on the at least one second processor; wherein: the message client is configured to create a publisher object for a topic, the message client is configured to create a first command token in response to the creation of the publisher object, the first command token comprising a create-publisher command code, a topic code for the topic, and a publisher code, the publisher code being a number, the message client is configured to send the first command token, the proxy is configured to receive the first command token, the proxy is configured to subscribe to the topic according to the topic code, the proxy is configured to associate the publisher code with identification information of the subscribed topic, the identification information being larger than the publisher code, the message client is configured to create a first message using the publisher object, the message client is configured to create a second command token in response to the creation of the first message using the publisher object, the second command token comprising a publish command code, the first message, and the publisher code, the second command token not including the topic code for the topic, the message client is configured to send the second command token to the proxy, the proxy is configured to receive the second command token, the proxy is configured to retrieve the identification information of the subscribed topic according to the publisher code in the second command token, and the proxy is configured to publish the first message on the subscribed topic.
15. The system of claim 14, wherein: the message client is configured to create a third command token, the third command token comprising an unsubscribe command code and the publisher code, the third command token not including the topic code for the topic, the message client is configured to send the third command token to the proxy, the proxy is configured to receive the third command token, the proxy is configured to retrieve the identification information of the subscribed topic according to the publisher code in the third command token, and the proxy is configured to unsubscribe from the topic.
16. The system of claim 14, wherein the proxy is further configured to: receive a second message from a message oriented middleware system related to the topic, and send the second message to the user device.
17. The system of claim 14, wherein the proxy is configured to maintain the topic code and the publisher code in a database.
18. The system of claim 14, wherein the proxy is further configured to maintain messages sent to the user device in a database.
19. The system of claim 14, wherein the user device comprises a database adapter configured to maintain messages sent to the proxy in a database.
20. The system of claim 14, wherein: the proxy comprises a first protocol adapter configured to send messages to the user device according to a guaranteed quality of service, and the user device comprises a second protocol adapter configured to send messages to the proxy according to the guaranteed quality of service.
Description
BRIEF DESCRIPTION OF THE DRAWINGS
(1) In the following, an example of an embodiment of the invention is described with reference to drawings. In the drawings;
(2)
(3)
DESCRIPTION OF THE PREFERRED EMBODIMENTS
(4) Now with reference to the drawing,
(5) The block diagram is but one example of a message proxy infrastructure deployment. Any number of message proxies, thin JMS message clients, message oriented middleware products, and message oriented middleware product clients can be present in a specific installation.
(6) The message proxy 1 may be implemented on a conventional computer network server, e.g. on a Windows-NT-server and may e.g. run in the background. It maintains client connections, maintains client subscriptions to JMS topics and queues, receives and forwards JMS messages, and stores JMS messages in its database, such that they will not be lost when a client is disconnected from the proxy.
(7) The message proxy 1 comprises at least one pluggable transport protocol adapter.
(8) The message proxy 1 also comprises a database adapter. This allows the proxy to store messages and client subscription information into arbitrary databases.
(9) On startup, the message proxy 1 reads its configuration data and initializes ail configured protocol adapters. It also initializes the topic and queue subscriptions of all the message clients which are known to the proxy. At runtime, additional protocol adapters can be started, or running protocol adapters can be stopped, without interrupting the message proxy service (however, if a specific protocol adapter is stopped, service over this adapter is no longer available). At runtime, additional clients can be connected to the proxy, or existing clients can be disconnected from the proxy.
(10) Each thin JMS message client 2, 2, 2 is installed on a mobile wireless device such as a mobile phone, a small laptop computer with a wireless modem, a palmtop device or any other device comprising a processor, a memory and communication means for communicating wirelessly. It contains a JMS programming library which is identical or similar to at least a part of the programming library used by messaging middleware 3 of the state of the art. The thin JMS message client library is small enough to be loaded into the memory of the mobile devices which have constrained memory and processing power.
(11) Such a small footprint of the thin JMS message client library is achieved by offloading from the client to the proxy most of the computations and most of the state information which a JMS client application ought to perform or to maintain. The thin JMS message client mainly consists of the JMS interface. Most of the Java code necessary for implementing the interface is running on the proxy, and not on the thin JMS message client. The proxy also maintains the JMS state information associated with the client. For example, the proxy stores the JMS messages which have not been acknowledged by the client yet. Also, the thin JMS message client does not need to store the names of the queues and topics it is subscribed to. This information is stored only by the proxy. Internally, the thin JMS client uses code information, such as number values, to refer to topics and queues. This code information can be as small as one byte. The actual representation of those queues and topics, which can be hundreds or thousands of bytes for each topic or queue, is contained in the proxy. When the thin JMS client wishes to publish a message on a certain topic, the client sends to the proxy only the JMS message and the code information related with the topic. All this considerably reduces the footprint of the thin JMS client.
(12) The thin JMS message client 2 also contains a command and message transmission system comprising a transport protocol adapter 2a, 2a, 2a used for informing the proxy of what JMS topics and queues the client wants to subscribe to.
(13) The message client 2, 2, 2 also comprises a database adapter. This allows the client to store JMS messages and other information locally, using arbitrary databases. The message database is necessary to ensure that JMS messages and JMS subscriptions submitted by the client are not lost in case the client cannot communicate with the proxy due to lack of wireless network coverage, or because the proxy is not running.
(14) A message client 2, 2, 2 links to the message proxy 1, using its transport protocol adapter 2a, 2a, 2a. If a matching protocol adapter is running on the proxy, the connection is successful. Further communication between message client and message proxy is according to the familiar publish/subscribe or point-to-point model of JMS.
(15) JMS topics or JMS queues are named and administered independently of the protocol adapters involved. If a client connects to the proxy using the WAP protocol adapter, it can communicate with a client that connected using the GPRS protocol adapter, if both clients use the same JMS topic or queue.
(16) The protocol adapters encapsulate, at least one logic needed to; Interface with a transport protocol, such as HTTP, WAP or GSM Data. Specify and guarantee a quality of service for the message delivery.
(17) Certain transport protocols operate in a best effort delivery mode. Thus, simply adapting to a specific protocol is not always enough (unless best effort is the desired message delivery guarantee). Thus, protocol adapters consist of both the transport protocol mechanism, and a quality of service mechanism to improve the basic network delivery guarantee.
(18) Network reliability is improved as follows. The sending protocol adapter attaches a reliability indicator such as a sequence number to all outgoing messages. The reliability indicator is varied in a predefined manner upon sending a message. E.g., the sequence number is incremented by one after each sent message. The receiver application uses the reliability indicator of the incoming message to detect whether a message was lost. In the described example, this is the case when the sequence number of the just received message is greater than the sequence number of the previous message, plus one. In the event of message loss, the receiver sends a command token to the sender indicating which messages are to be retransmitted. The sender then retransmits the requested messages. The sender keeps messages in a local database to be able to fulfill a message retransmission request.
(19) The database adapters encapsulate at least one logic needed to: Interface with a database product, such as PointBase, Oracle, DB/2, or Sybase, OR to interface with a portable database access software such as JDBC or ODBC. Store and retrieve JMS messages and JMS subscription requests.
(20) The message client 2 implements e.g. the JMS API from Sun Microsystems. It cooperates with the proxy to achieve full JMS functionality. When the client wants to subscribe to a JMS queue or topic, its command subsystem creates a command token containing the subscription information. The command token is then sent to the proxy using wireless communication. To this end, the token is sent via a protocol adapter 2s, 2a, 2a at the client side and received by a protocol adapter 1a, 1b, 1c, 1d, 1e, 1f or 1g at the proxy side.
(21) On receipt of a command token, the proxy 1 reads the subscription information contained in the token, and performs a JMS subscription with the state of the art middleware, on behalf of the client.
(22) Further command tokens are generated when the client wants to unsubscribe from a JMS topic or queue, when the client wants to transmit a JMS message, or for any other JMS action which is requested by the client.
(23) When a JMS message is received on a topic or queue the proxy 1 is subscribed to on behalf of the client, the proxy creates a message token containing the data of the JMS message. The message token is then sent to the client 2 using wireless communication. For that the token is sent via a protocol adapter 1a, 1b, 1c, 1d, 1e, 1f or 1g at the proxy side, and received by the protocol adapter 2a, 2a, 2a at the client side.
(24) On receipt of such a message token by a thin JMS message client 2, a JMS message is created by the client. Then, the JMS message is processed by the client. For example, the message can be visualized in a graphical user interface.
(25) The JMS message oriented middleware 3 according to the state of the art can be any JMS messaging middleware product, for example, IBM's MQSeries, SoftWired's iBus, or Progress' SonicMQ.
(26) The JMS message oriented middleware client 4 is a client application implemented on a non-mobile computer, i.e. on a computer connected to a wired computer network, using a state of the art JMS message oriented middleware 3. One or more JMS message oriented middleware clients 4 according to the state of the art can be present.
(27) For the describing an example of the communication between different examples, it is assumed that the thin JMS message client 2 is subscribed to a topic T. Such a topic T can, depending on the application, denote a stream of stock quotes, of sports news, or denote a transmission channel carrying digital audio. When a state of the art JMS message oriented middleware client 4 sends a JMS message to topic T, the message is passed first to the state of the art JMS message oriented middleware 3. The message will then be received by the proxy 1 on behalf of thin client 2. Next, proxy 1 transmits the JMS message to client 2 in the form of a message token using one of its transport protocol adapters 1a, 1b, 1c, 1d, 1e, 1f or 1g. Finally client 2 receives the JMS message on topic T as if it was accessing the state of the art JMS message oriented middleware 3 directly.
(28) In order to show this procedure in more detail, in the following an example of the method for delivering information between applications running on mobile wireless devices and serving as clients and applications running on non-mobile computers is described with reference to
(29) The sequence diagram of
(30) 1. A JMS TopicPublisher object Pub is created, upon request of the application, for JMS publish/subscribe topic T. Later, Pub will allow the mobile client application to publish a JMS message on topic T.
(31) 2. The Thin Message Client Library creates a command token containing the information which is needed by tire proxy for allocating a JMS TopicPublisher, on behalf of the client. The command token contains a code information (e.g. a one-byte number) denoting a Create a publisher command. It also contains the JMS topic T the publisher shall be tied to (e.g. a one-byte number), as well as an information Code P (e.g. a one-byte number) denoting the publisher.
(32) 3. The proxy creates a JMS TopicPublisher Pub for topic T on behalf of the thin client.
(33) 4. The proxy associates Topic-Publisher Pub with the code information P. This can be done by storing the TopicPublisher Pub into a data dictionary, using code information P as the search key.
(34) 5. The client application creates a JMS message msg containing application specific information, e.g., a book order. This step, of course, as well as the subsequent step 6, can be carried out following to or simultaneously to steps 3 and 4.
(35) 6. The client application now publishes JMS message msg on topic T, using TopicPublisher Pub.
(36) 7. The Thin Message Client Library creates a command token containing the information which is needed by the proxy for publishing the message using state-of-the-art JMS middleware. The command token contains a code information (e.g. a one-byte number) denoting a Do publish command. It also contains the code information for the TopicPublisher (Code P) as well as the message msg.
(37) 8. The proxy retrieves the TopicPublisher Pub, which is associated with Code P. This publisher pub was associated with Code T in Step 4.
(38) 9. Finally, the proxy publishes the JMS message msg on topic T using a state of the art JMS middleware. Concretely, the proxy forwards the message msg on topic T to a state of the art JMS application using JMS.
GLOSSARY OF TERMS USED
(39) TCP: Transmission Control Protocol
(40) IP: Internet Protocol
(41) HTTP: Hypertext Transfer Protocol
(42) WAP: Wireless Application Protocol
(43) WDP: WAP Wireless Datagram Protocol
(44) SSL: Secure Socket Layer
(45) JMS: Java Message Service (http://java.sun.com/products/jms/)
(46) PDA: Personal Digital Assistant
(47) SMS: Short Messaging Service
(48) GSM: Global System for Mobile Telecommunication
(49) DAB: Digital Audio Broadcast
(50) JDBC: Java Database Connectivity (http:/java.sun.com/products/jdbc/)
(51) ODBC: Microsoft's Open Database Connectivity
(52) MOM: Message Oriented Middleware