| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Subscription Points = tight coupling? |
« View previous topic :: View next topic » |
| Author |
Message
|
| Sandman |
 Posted: Mon Apr 17, 2006 8:47 am Post subject: Subscription Points = tight coupling? |
 |
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Hi,
Can someone who has some experience w/ these please provide some input on this?
If a publishing flow were to have separate paths for each of its known (at design time) subscribers that do the transformation, and ultimately end w/ their own Pub. node (using sub. pts.), doesn't this yield a tightly-coupled design? IOW, every new subscriber that comes along would force a change to the publication flow.
Wouldn't it be more flexible to not use sub. pts. and instead layer adapters for transformation (both on pub and sub sides)?
Thank you in advance. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Apr 17, 2006 9:12 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It kind of depends on what the subscription points are.
The example given in the documentation is not, in my opinion, a tightly coupled scenario. The publisher provides two subscription points - one in dollars and one in pounds. It is expected that there will be many different subscribers for each subscription point. Pub/Sub is all about one-to-many, right? So there is a fairly loose coupling. But it's still a coupling - it's still an interface and thus a "contract" between the publishers and the subscribers. The publisher can't just decide to start publishing Euros and rupees, instead.
If a subscriber needs, for example, kronur- the subscriber has two choices. The first is to subscribe to whichever value is easier to convert to krona and handle the transformation. The second option is to have the publisher produce another subscription point in kronur. This then becomes a standard decision about reuse - how many other subscribers are likely to need to recieve subscriptions in kronur?
This also assumes that the work of doing the transformation has the same "cost" when done on the subscriber as on the publisher. If, for example, the subscriber is actually a fairly lightweight JSP... then you might not want to add the cost of doing the conversion there no matter that there's only the one subscriber.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Sandman |
| Posted: Mon Apr 17, 2006 9:24 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Thanks for the quick reply Jeff.
In our scenario, the transformation at this point is likely just primary key translation (using a centralized cross-ref table that the Hub references). However, some near-future subscribers will also require XML:flat transformation, as well as some possible code conversions (i.e. postal state codes to legacy numeric codes), using another database table, etc..
It would seem that these types of transformation have very little chance of reuse, and therefore would be considered extremely tight coupling, correct? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 17, 2006 9:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If they have little reuse, then they are better served on the subscription side. And if the publisher does them, then, yes, it's what I would consider a tight coupling. It's putting knowledge about the subscriber into the publisher.
But there's no reason a subscriber can't be a publisher as well - as we talked about previously.
On the third hand, if a particular topic is best published in a particular format...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
