Surety is performing system maintenance this weekend. Electronic date stamps on new Prior Art Database disclosures may be delayed.
Browse Prior Art Database

Large Message Distribution in Message/Queueing Application Integration software.

IP.com Disclosure Number: IPCOM000019160D
Original Publication Date: 2003-Sep-02
Included in the Prior Art Database: 2003-Sep-02
Document File: 2 page(s) / 41K

Publishing Venue



Data that is being transferred between systems, particularly in the form of messages is growing. Increasingly there is the issue of large messages (100 Mbytes +) being transferred between systems. It has recently come to light that a user is looking to use a publish subscribe method to transfer 300Mbyte messages to hundreds of subscribers. This can place a huge load on the infrastructure of the systems involved, particularly of the network that the data is being transferred over and storage systems that these messages are being written to. Where the network and systems are already under load, this additional burden of transferring and receiving large messages at an inappropriate time could break or severely impair the systems involved. This disclosure discusses the idea of Instead of transferring the data, send a message with a 'pointer' to a single copy of the original data. This pointer includes enough information for the receiving application to know that there is a data message waiting to be retrieved.

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

Page 1 of 2

  Large Message Distribution in Message/Queueing Application Integration software.

Instead of transferring large amounts of data at a point when the receiving system may be under load, or a time that the network could be busy, applications preferably send a short message that gives details of data that is waiting to be processed. This preferably includes for example time and date posted, expiry date and time, message size. It also preferably includes a unique identifier for the data that has been saved on the local server as well as a unique identifier for the message that has been sent.

    A single copy of the data is saved on a server that is 'local' to the system sending the data. It preferably includes the data's unique identifier as well as a list of the unique identifiers and the queue addresses that relate to all the user applications the data needs distributing to.

    On receipt of the message that indicates there is data for the application to retrieve, the receiving application could immediately process it, or defer it for processing later.

    When it is to process the data, it requests the data from the server. It's request includes the unique id for the data as well as the unique id for the application that is requesting the data. The data is transferred, and the unique ID of the requesting application is deleted from the list of IDs that was saved with the single copy of the information on the server. Once all IDs have been deleted, the data has been transferred to all necessary applications and can either be deleted or archived.

    It is possible that if the data is not retrieved by all the applications (particularly in a publish/subscribe situation), it could in theory remain on the server indefinitely. For this reason time out values are preferable.

    There is preferably a delete time out such that if the time out value is reached the data is deleted.

    There is also pre...