Browse Prior Art Database

Graphical Design and Deployment of Messaging Architecture

IP.com Disclosure Number: IPCOM000209178D
Publication Date: 2011-Jul-29
Document File: 6 page(s) / 97K

Publishing Venue

The IP.com Prior Art Database

Abstract

By their nature, messaging architectures based on messaging systems have a very broad base in terms of the number of platforms they can encompass, and the number of queue managing artifacts, storage artifacts and communication channels they contain. Very often in a single messaging architecture a large number of platforms can be linked together in terms of messaging communication and these platforms can all have many queue managers and objects which can themselves all link together just within the domain of a single machine. This can cause a spaghetti like mix of messaging objects causing accurate depictions of the architecture to be extremely hard to create, visualise and navigate. The problem is compounded when the user comes to add new objects and connections to the architecture. As there is no dynamic visual representation of the messaging system as a whole, which shows how the objects link together, the creation of new objects and connections can be laborious and prone to error. A further difficulty is the application of best practices in terms of naming conventions and an awareness on the part of the user of the salient configuration options to ensure a robust messaging infrastructure. This article outlines a method of being able to graphically map and create messaging connections /objects spanning multiple machines in a visual manner and provides the user with structured best practice basis .to create new or additional elements to the architecture. It also offers the user a level of abstraction away from the 'nuts and bolts' of the messaging infrastructure by determining from the users actions/graphical depiction what manner of object would be required..

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

Page 01 of 6

Graphical Design and Deployment of Messaging Architecture

The method outlined in this article comprises of a central graphical user interface which works in concert with messaging administration agents and runs on all of the platforms/machines within the scope of the architecture. The GUI would provide a drop down list of all machines which have the messaging administration agents running on them. The user can drag machines from the list onto the GUI for manipulation. When the machine is selected and dragged into the GUI the messaging agents on that box are notified and they perform a check of all queue managers/objects and connections from that box and pass that back to the GUI. This map of the MQ objects on the box is then replicated onto the GUI to provide the user with a full depiction of all of the messaging components on that machine. This includes queue managers and their respective queues and channels (with connections between other queue managers shown).

    The user is provided with the means to choose to add more messaging objects to the infrastructure. The gui presents them with a selection of best practice naming convention templates (with an indicator suggesting the convention which is currently being used). The GUI will allow the user to drag other machines onto the GUI and create connections between machines/queue managers by dragging channel objects from one queue to another. Using the selected naming convention, the objects would be automatically created using the template naming convention. Also the GUI will infer from the user's actions what MQ objects need to be created. This will include objects such as remote queue definitions and channels. It will also determine the correct naming convention depending on how the user links to or from the object.

In summary the GUI will provide the following functions


1. A machine level rather than queue manager level scope for administration (spanning multiple queue managers on a single machine)


2. A GUI which works in concert with message administration agents to determine the current messaging infrastructure on the machine and represent that infrastructure graphically to the user


3. A GUI which works in concert with message administration agents to allow the user to create objects and link them with to the existing infrastructure graphically


4. The ability to provide the user with a choice of best practice naming conventions to be used in the creation of new objects


5. The ability to determine (where possible) the current naming convention used for the current objects and present that as the preferred choice of naming convention to the user


6. The ability to discern from the actions of the user when creating connections, which objects are to be used as remote queue definitions, which are to be created as channels and which are to be named as the queue to receive messages.

    This is best described as a Use Case. The following example shows how a user can use the GUI to quickly...