Browse Prior Art Database

A method to allow conversation sharing across multiple “messaging clients triggered by different processes” connecting to the same messaging engine.

IP.com Disclosure Number: IPCOM000201556D
Publication Date: 2010-Nov-15
Document File: 5 page(s) / 102K

Publishing Venue

The IP.com Prior Art Database

Abstract

A method to allow conversation sharing across multiple messaging clients triggered by different processes connecting to the same messaging engine

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% of the total text.

Page 01 of 5

A method to allow conversation sharing across multiple "messaging clients triggered by different processes" connecting to the same messaging engine .

Conversation sharing or multiplexing of connections from a single messaging client is a common practice implemented in every messaging middleware products. Multiplexing allows an application to spawn multiple connections to use a single TCP/IP socket connection to a messaging engine. This enables lesser usage of network sockets and is extremely useful when there is less traffic on one connection so that the same connection can be shared across different connection objects.

Messaging clients run on a variety of operating systems. Several of the clients run on Personal Computer's (PC's), hand held devices (mobile, Personal Digital Assistant [PDA]), edge components where every connection that is spawned has a cost associated with it (in terms of resource utilization). One such scenario is the usage of hand held devices on which the messaging clients run. We have several customers using edge devices like PDA's, Mobiles, Microbroker clients, *Java/*Java Messaging Server (JMS), .

NET, C, C++ clients to

communicate with the enterprise system. All these devices execute a small footprint of a messaging client. There are instances where 5-6 various applications run simultaneously connecting to the messaging engine.

For instance, if the messaging client is a JMS application it runs on a single *Java Virtual Machine(JVM) and has the scope of multiplexing is only limited to that JVM. Similarly, when a non-JMS application is running on the device, the scope of multiplexing is limited only to that

process that executes the application.

In the above said scenario, it is required there are 5-6 different physical connections created to communicate with the messaging engine, because they are running across multiple process/JVM'
s.

As resource utilization is one of the key importance for a product success, enabling multiple messaging clients running across process to use a single connection will enable reduce the amount of physical connection to be created between the clients and the server. Hence this invention tries to provide a mechanism to allow multiple messaging clients running across multiple processes to share the conversation as opposed to the method of sharing the conversation only within a single messaging client running in a single process.

In order to enable multiple messaging clients to share the conversations it is important we create a layer of an abstraction over a single socket thereby eliminating the usage of multiple socket/file descriptors (system resources). Since each of the messaging clients running across processes will have different process ID's we have to use the process id to distinguish connection across multiple clients.

A common problem across server client interaction based applications is the need for creation and management of multiple connections. The apparent effect...