JMS provider with plug-able business logic

• US 8,161,168 B2
• Filed: 03/14/2007
• Issued: 04/17/2012
• Est. Priority Date: 03/18/2006
• Status: Active Grant

• Current Assignee: Metafluent LLC
• Original Assignee: Metafluent LLC
• Inventors: Lankford, Peter, MacGaffey, Andrew
• Primary Examiner(s): DONAGHUE, LARRY D
• Application Number:
  US12/225,218
• Publication Number:
  US 20090313338A1
• Time in Patent Office: 1,861 Days
• Field of Search: None
• US Class Current: 709/227
• CPC Class Codes: H04L 45/00 Routing or path finding of packets in data switching networks routing or path finding in wireless networks H04W40/00
• CPC Class Codes: H04L 45/24 Multipath
• CPC Class Codes: H04L 67/1001 for accessing one among a plurality of replicated servers
• CPC Class Codes: H04L 67/1008 based on parameters of servers, e.g. available memory or workload monitoring of computer activity G06F11/30
• CPC Class Codes: H04L 67/14 Session management for real-time applications in data packet communications networks H04L65/1066

Abstract

The invention provides plug-in framework, enabling embedding of content-based processes to in a messaging paradigm provider service. In the preferred embodiment, the messaging paradigm is JMS and the invention provides a plug-able framework embedded in a JMS Provider. The plug-able server is particularly suited for efficient and secure transmission of real-time, streaming data.

Claims

1. A Java Message Server (JMS) comprising:

a processor;

a computer readable medium comprising instructions that when executed by the processor comprises;

a plurality of plug-ins, each plug-in corresponding to one of a plurality of JMS session providers;

receiving a first request from a JMS client to establish a JMS session, wherein the first request comprises an application context name; and

in response to the first request, analyzing names of the plurality of JMS session providers to match the application context name and to establish the JMS session;

wherein the established JMS session has a configured JMS destination provider to which it delegates servicing of subsequent destination publish-subscribe requests.

2. The Java Message Server of claim 1, wherein the configured JMS destination provider delegates the servicing of destination publish-subscribe requests to one of a plurality of configured second JMS destination providers sorted according to destination name filters, further comprising:

receiving via the established JMS session, one or more second requests from the JMS client to access one of the second JMS destination providers for the JMS session; and

analyzing the sorted JMS destination providers to find a matched second JMS destination provider that gives the best match for the requested destination name.

3. The Java Message Server of claim 2, wherein the sorted JMS destination providers comprises a sorted sequence with JMS destination providers having a specific filter listed before JMS destination providers having a generalized filter.

4. The Java Message Server of claim 2, wherein the matched JMS destination provider implements an application-level messaging protocol interaction with a JMS client application.

5. The Java Message Server of claim 4, wherein the application-level messaging protocol comprises processing subscription requests, processing publication requests, and generating or routing messages to and from the JMS client application.

6. The Java Message Server of claim 2, wherein the matched second JMS destination provider provides publish-subscribe access to one or more streams of dynamic data, where the access comprises interaction with locally cached data or interaction with external systems in conjunction with message transformations.

7. The Java Message Server of claim 6, wherein the matched second JMS destination provider uses a dictionary to optimize JMS MapMessages relating to one or more streams of dynamic data conveyed over a single destination.

8. The Java Message Server of claim 7, wherein the dictionary provides message optimization comprising:

for each field that may be present in a JMS MapMessage, the field is assigned an index starting from zero;

the dictionary describes the number of fields and the name and type of each field;

when JMS MapMessages are sent, the encoded map message data is preceded by a variable length bitmap indicating which fields are present in the message;

when the bitmap is encoded it comprises a minimal size to accommodate the largest index for fields actually present in the message;

when full image messages are sent, all bits in the bitmap are fully populated;

when update messages are sent, the bitmap is sparsely populated, having bits set to 1 only for those indices corresponding to fields in the message;

when receiving the sparsely populated bitmap, a receiver can work through the encoded bit map and encoded data in sequence where the presence of a 1-bit in the bit map conveys the index of the dictionary entry and the technique for decoding the subsequent bytes in the data portion of the encoded message.

9. The Java Message Server of claim 7, wherein each destination relays messages relating to one or more dynamic data streams, wherein each dynamic data stream conforms to one of a plurality of possible combinations of fields.

10. The Java Message Server of claim 9, wherein for each unique combination of fields the server generates a dictionary and assigns an id.

11. The Java Message Server of claim 10, wherein the sender sends to the client only those dictionaries that are required on an as-needed basis before sending any encoded message that rely on the dictionary.

12. A computer readable medium having instructions stored thereon that, when executed by a processor, causes the processor to function as a Java Message Server (JMS), the instructions comprising:

a plurality of plug-ins, each plug-in corresponding to one of a plurality of JMS session providers;

receiving a first request from a JMS client to establish a JMS session, wherein the first request comprises an application context name; and

in response to the first request, analyzing names of the plurality of JMS session providers to match the application context name and to establish the JMS session;

wherein the established JMS session has a configured JMS destination provider to which it delegates servicing of subsequent destination publish-subscribe requests.

13. The computer readable medium of claim 12, wherein the configured JMS destination provider delegates the servicing of destination publish-subscribe requests to one of a plurality of configured second JMS destination providers sorted according to destination name filters, further comprising:

receiving via the established JMS session, one or more second requests from the JMS client to access one of the second JMS destination providers for the JMS session; and

analyzing the sorted JMS destination providers to find a matched second JMS destination provider that gives the best match for the requested destination name.

14. The computer readable medium of claim 13, wherein the sorted JMS destination providers comprises a sorted sequence with JMS destination providers having a specific filter listed before JMS destination providers having a generalized filter.

15. The computer readable medium of claim 13, wherein the matched JMS destination provider implements an application-level messaging protocol interaction with a JMS client application.

16. The computer readable medium of claim 15, wherein the application-level messaging protocol comprises processing subscription requests, processing publication requests, and generating or routing messages to and from the JMS client application.

17. The computer readable medium of claim 13, wherein the matched second JMS destination provider provides publish-subscribe access to one or more streams of dynamic data, where the access comprises interaction with locally cached data or interaction with external systems in conjunction with message transformations.

18. The computer readable medium of claim 17, wherein the matched second JMS destination provider uses a dictionary to optimize JMS MapMessages relating to one or more streams of dynamic data conveyed over a single destination.

19. The computer readable medium of claim 18, wherein the dictionary provides message optimization comprising:

for each field that may be present in a JMS MapMessage, the field is assigned an index starting from zero;

the dictionary describes the number of fields and the name and type of each field;

when JMS MapMessages are sent, the encoded map message data is preceded by a variable length bitmap indicating which fields are present in the message;

when the bitmap is encoded it comprises a minimal size to accommodate the largest index for fields actually present in the message;

when full image messages are sent, all bits in the bitmap are fully populated;

when update messages are sent, the bitmap is sparsely populated, having bits set to 1 only for those indices corresponding to fields in the message;

when receiving the sparsely populated bitmap, a receiver can work through the encoded bit map and encoded data in sequence where the presence of a 1-bit in the bit map conveys the index of the dictionary entry and the technique for decoding the subsequent bytes in the data portion of the encoded message.

20. The computer readable medium of claim 18, wherein each destination relays messages relating to one or more dynamic data streams, wherein each dynamic data stream conforms to one of a plurality of possible combinations of fields.

21. The computer readable medium of claim 20, wherein for each unique combination of fields the server generates a dictionary and assigns an id.

22. The computer readable medium of claim 21, wherein the sender sends to the client only those dictionaries that are required on an as-needed basis before sending any encoded message that rely on the dictionary.

23. A computer implemented method for providing a Java Message Server (JMS), the method comprising:

a plurality of plug-ins, each plug-in corresponding to one of a plurality of JMS session providers;

receiving a first request from a JMS client to establish a JMS session, wherein the first request comprises an application context name; and

in response to the first request, analyzing names of the plurality of JMS session providers to match the application context name and to establish the JMS session;

wherein the established JMS session has a configured JMS destination provider to which it delegates servicing of subsequent destination publish-subscribe requests.

24. The method of claim 23, wherein the configured JMS destination provider delegates the servicing of destination publish-subscribe requests to one of a plurality of configured second JMS destination providers sorted according to destination name filters, further comprising:

receiving via the established JMS session, one or more second requests from the JMS client to access one of the second JMS destination providers for the JMS session; and

analyzing the sorted JMS destination providers to find a matched second JMS destination provider that gives the best match for the requested destination name.

25. The method of claim 24, wherein the sorted JMS destination providers comprises a sorted sequence with JMS destination providers having a specific filter listed before JMS destination providers having a generalized filter.

26. The method of claim 24, wherein the matched JMS destination provider implements an application-level messaging protocol interaction with a JMS client application.

27. The method of claim 26, wherein the application-level messaging protocol comprises processing subscription requests, processing publication requests, and generating or routing messages to and from the JMS client application.

28. The method of claim 24, wherein the matched second JMS destination provider provides publish-subscribe access to one or more streams of dynamic data, where the access comprises interaction with locally cached data or interaction with external systems in conjunction with message transformations.

29. The method of claim 28, wherein the matched second JMS destination provider uses a dictionary to optimize JMS MapMessages relating to one or more streams of dynamic data conveyed over a single destination.

30. The method of claim 29, wherein the dictionary provides message optimization comprising:

for each field that may be present in a JMS MapMessage, the field is assigned an index starting from zero;

the dictionary describes the number of fields and the name and type of each field;

when JMS MapMessages are sent, the encoded map message data is preceded by a variable length bitmap indicating which fields are present in the message;

when the bitmap is encoded it comprises a minimal size to accommodate the largest index for fields actually present in the message;

when full image messages are sent, all bits in the bitmap are fully populated;

when update messages are sent, the bitmap is sparsely populated, having bits set to 1 only for those indices corresponding to fields in the message;

when receiving the sparsely populated bitmap, a receiver can work through the encoded bit map and encoded data in sequence where the presence of a 1-bit in the bit map conveys the index of the dictionary entry and the technique for decoding the subsequent bytes in the data portion of the encoded message.

31. The method of claim 24, wherein each destination relays messages relating to one or more dynamic data streams, wherein each dynamic data stream conforms to one of a plurality of possible combinations of fields.

32. The method of claim 31, wherein for each unique combination of fields the server generates a dictionary and assigns an id.

33. The method of claim 32, wherein the sender sends to the client only those dictionaries that are required on an as-needed basis before sending any encoded message that rely on the dictionary.