Browse Prior Art Database

Method to allow pub/sub broker to register the subscriptions in bulk at deploy time using static registration method

IP.com Disclosure Number: IPCOM000199916D
Publication Date: 2010-Sep-21
Document File: 6 page(s) / 145K

Publishing Venue

The IP.com Prior Art Database

Abstract

In a publish/subscribe model if one client wants to register a subscription on a topic, then the client needs to create an associated session and a subscriber on that topic. If the same client is interested in ‘n’ number of ‘unrelated’ topics then the client needs to create ‘n’ number of subscriber instances one by one for each topic. For example in WebSphere Message Broker , for subscribing to a topic, each time the client sends a subscribe request, the registration of the client on that topic is carried out by the broker. The client is given a unique client-id for identification purpose. As soon as the client is disconnected the de-registration happens dynamically. For durable subscribers the connection creates a durable registration which remains with the broker (in a persistent store) even when the client disconnects. If the client subsequently connects to the server with the same client id it can continue the subscriptions without re-registration. Currently there is no facility to register multiple topics in a single request what we call here as Bulk registration. Here we are not referring to wildcard topics like (Sport/Soccer/State/LatestScore/#) which has a common root and this belongs to a single subscriber only. Following problems are observed with the present functionality of pub-sub broker. 1) In a large pub-sub domain where there are many subscribers wanting to subscribe to various topics, there needs to be those many number of individual subscribe request that needs to be sent to the broker for registration. 2) If a particular subscriber is interested in ‘x’ number of topics (unrelated) then there is no facility to send such registration request in one single subscription request. 3) There is no method available to pre-load the pub-sub broker with the set of registrations topics independent of the subscriber. We call this as a static subscription. 4) Migration of pub-sub domain from one broker to another. This disclosure describes the methodology to overcome the above problems . 1) The wildcard option allows to subscribe for the set of topics (that has common root topic ) but it does not address the condition where there is a need to subscribe for ‘n’ unrelated topics. 2) Send ‘n’ number of subscription requests for ‘n’ number of topics. Drawback of such method is, it’s a lengthy , tedious, time consuming activity.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 46% of the total text.

Page 1 of 6

Method to allow pub/sub broker to register the subscriptions in bulk at deploy time using static registration method

In order to achieve the objective of bulk subscriptions, it is important that we try to make the subscription activity independent of the subscribers being actually available.

That will provide greater flexibility during migration, redo of the subscription activities.

We describe the implementation in the form of following three cases.

Implementation details :

Case 1:

In order to decouple broker and subscriber from the registration step, we can utilize the deploy method of broker to send the registration request at the deploy time.

The WebSphere Message broker currently provides facility to deploy various artifacts like message flows, message sets ,

                  ar files, xsl stylesheets etc. We allow the subscription registration task through this deployment descriptor , which will enable us to send an aggregated request to broker for the set of subscription topics. We can collate all the topics that needs to be registered into an xml file in the following format and validate it against the product xsd file to ensure that all members in the subscription list are valid requests.

< Reg xmlns:xsi =" http://www.w3.org/2001/XMLSchema-instance " xsi:noNamespaceSchemaLocation =" BulkReg.xsd ">

RegSub <

/

j

Command >

…<

           Topic >

…<

/

/

             SubPoint >

<

/

          Filter >

…<

/

             SubName >

…<

/

               SubIdentity >

…<

/

                SubUserData >

…<

/

            RegOpt >

<

/

               QMgrName >

…<

/

QName >

<

/

psc >

<

/

   Subscribe >
< Subscribe id="uniqueID" >

DeRegSub <

/

Command >

          Topic >

<

/

<

/

             SubPoint >

<

/

          Filter >

…<

/

             SubName >

<

/

               SubIdentity >

<

/

SubUserData >

1

Page 2 of 6

<

/

RegOpt >

<

       psc > <

/

/

Subscribe >

<

   SubscribeList > <

/

/

Reg >

Sample XSD to validate the XML is provided here

<xsd:schema xmlns:xsd="http://www.w3.org

/2001

/XMLSchema">

<

/xsd:sequence>

<

/xsd:complexType>

<

/xsd:element>

<

/xsd:sequence>

<

/xsd:complexType>

<

/xsd:element>

<

/xsd:sequence>

<

/xsd:complexType>

<

/xsd:element>

<

/xsd:choice>

<

/xsd:complexType>

<

/xsd:element>

2

Page 3 of 6

<

/xsd:sequence>

<

/xsd:complexType>

<

/xsd:element>

<

/xsd:sequence>

<

/xsd:complexType>

<

/xsd:element>

<

/xsd:schema>

Such topics will need to be anticipated in your business environment. When broker receives such xml file over the deployment operation, it would store it in it registry and would notify the a new component called 'Subscription Analyser'. The subscription analyzer would read the deployed xml file,

            arse it to identify and segregate the individual subscription requests by looking at the

folder . When there are multiple <

p

p

                                      sc> elements under the same Subscribe folder is found , then the flow will interpret it as multiple topic subscription requested by the same subscriber. Finally, these individual requests are put onto the broker's pub-sub queue, SBCQ (SYSTEM.BROKER.CONTROL.QUEUE) for the internal pub-sub control flow to perform the necessary subscript...