Message selection

Question

guys,
i have a query, i have to develop an application for a bank where the requirement is such that i need to send messages to several subscribers, but not all the messages be sent to all subscribers. What i mean to say is, messages are to be sent to a particular subscriber based upon the criteria set by the subscriber. this criteria is set by the subscriber and is based on his requirement. as far as i know, message selection can be done through message selectors only. how could message be sent to a particular subscriber based upon what he wants to receive depending upon what content is being sent in the message, can somebody help me out in resolving this issue, or tell me if i am wrong anywhere in the concept of message selector. thanks in advance for your kind help
james

Answer 1

Paul,
Please read on for my comments .....
First off. JMS does not specifically state aproperty
value needs to be a String. A property value can be
any one of the JMS primitive types. In my 1stexample
BVAL would clearly have been a float, something far
more efficient than a Java string.That's absolutely correct.
I fail to see why a dictionary containingkey/value
data is any different to an XML document containing
elements, attributes and respective values. As far as the data being published is concered, what
you
are saying is correct. If a piece of information can
be
represented by an xml, it can be represented by a
Dictionary
as well. In other words, the dictionary approach works
perfectly well for the publisher side of the
application.
However, how does one set a message selector on a JMS
consumer
based on what's inside the dictionary object? A JMS
vendor is
only expected to look into message properties while
checking
for message selection and not inside an Object
property.
Of course, a JMS Provider is free to come up with
proprietary
methods that allow consumers to specify selection
criterion
based on what's coming in a Dictionary Object.
However, XML
and XPath is a standard that fits the bill perfectly
and hence
is an obvious choice. This is exactly what Fiorano
did.
As a subscriber in both scenarios you need
to have an understanding of what it is you arelooking
for. Agreed. However, the publisher should not be forced to
know
what are all the consumers looking for. The fact that
a publisher
sets message properties in outgoing message requires
it to
be aware of the fact that interested consumers will be
looking
out for this particular property. A change in
consumer's selector
requires an appropriate change in the publisher.
Hence, a publisher
and a subscriber are not completely de-coupled from
each other.
As I have stated many times before the common
denominator between a subscriber and a publisher isa
queue or topic, the 2 remain decoupled.The above is fine as long as there are no message
selection
rules on the consumer. See note above.
JMS selectors work out well only where this setof
message selectors on a topic is finite and is not
expected to grow in future.
This I suspect is a result of poor implementation.This has nothing to with implementation. Consider an
ever
growing consumer list where each consumer has a
different
type of selector involving a different property name.
I
have already stated an example of such a requirement
in
my earlier post. How do you propose to build such a
system
with standard JMS selectors?
Guneet,
The last thing I want to do is help you, the other people at Fiorano or the people at Modena fix up your product.
Performance tells all and therefore implementation clearly does have something to do with it. Unfortunately for legal reasons we can no longer talk about performance comparisons.
I respectfully suggest that this thread end here.
Regards,
Paul Brant
my-Channels - Technologies working together
http://www.my-channels.com/