MQSeries.net :: View topic - WBIMB Pub/Sub when subscribers need custom transformation?

Sandman · Posted: Mon Apr 10, 2006 1:37 pm Post subject:

Hi,

I'm hoping you can help me understand this. I've been away from WBIMB the past couple years, but there are still others in our company who still use the product more regularly. I have searched this forum and read a lot about Pub/Sub, and I've also been through the manuals.

Here's our situation:

Though some subscribers can digest our "enterprise" (canonical) message format, others require subscriptions in specific formats (some might not even be XML, i.e. COBOL).

One consideration is the use of Subscription Points. An alternative is an "adapter" approach, attempting to provide looser coupling of Publisher/Subscriber.

Note: Regardless of which approach we take, we are considering creating our own Subscription XML schema to "wrap" the sub commands that an MQ app. can store in the RFH2/psc folder, and having a "Subscription" message flow parse this XML message to perform the actual subscription registrations.

In the Subcription Points approach, in our situation, we'd need to have a separate path through the flow that is processing an external system's "publication" for each unique subscription format. That way, each path would format appropriately, then create a unique Publication Node for its unique subscription format. Then we'd just have any subscribers who require that format specify a subscription point that equates to "their" pub. node.

If this is correct, then would our topics end up something like "ModifyPartyFormat1", "ModifyPartyFormat2", etc.?

In the Adapter approach, the goal is to provide more flexibility (i.e. if/when a non-canonical-compliant subscriber someday gets "on board" w/ our enterprise format, or we replace that component w/ something that does, we could more easily remove the adapter(s)).

For each subscriber app that needs its message format adapted (and can't/won't do it itself), create a pair of queues and message flows (on the broker). For example, for App1, who wants its subscription delivered to Q1, create queues called App1_Sub_Adapter_Q and App1_Pub_Adapter_Q and message flows called App1_Sub_Adapter and App1_Pub_Adapter.

App1 would then send a subscription message to its subscription adapter queue, using the same "ModifyParty" topic that all other subscribers to this event would use (though they would send theirs to the "master" Subscription_Q), and specifying their subscriber queue. The App1_Sub_Adapter message flow would first cache (in a database table) the actual subscriber queue and qmgr names, along w/ the name of its pub adapter queue. Then it would change the subscriber queue in the message from the actual to the pub adapter queue, and send the message to the Subscription_Q, where the Subscription message flow would register the subscription, but to the pub adapter queue.

Now the message flow that does the publishing would only publish "ModifyParty" events, which the broker would detect, and in turn, send a subscription message to the App1_Pub_Adapter_Q queue (and also to any other subscriber queues for apps which did not require custom formats).

The App1_Pub_Adapter message flow - whose sole purpose is to specifically adapt subscriptions for this particular app - would perform custom transformation, then reference the cache table to convert the input queue name on which the message arrived to the actual queue name sent originally by the subscriber (then of course, send the message to it).

Would greatly appreciate input on pros/cons of these 2 approaches, as well as any other approaches.

Thank you,
Mike