Ruwan Linton schrieb:
Jens,
Hi Ruwan,
First of all the idea seems cool but I am wondering whether we need a
new type of a proxy for this, because Upul is writing an Atom mediator
and we should be able to extend that to meet these requirements.
Ok, this sound good at first.
On Thu, Feb 28, 2008 at 12:03 AM, Jens Goldhammer
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
Hello Mailinglist,
I have a certain form of dynamic recpient list / dynamic router in my
mind and I want to share this idea if this would make sense to
implement
in Synapse:
It would be nice if Synapse can offer a subscription-mechanism. All
interested recipients subscribe to a certain topic and receive all
messages to the specified Adress which they are interested in.
This can
be done with a new type of definition- the "subscriber Proxy".
Maybe you
can say, all recipients pass a xpath-expression and the replyTo-Field
and define in this way a dynamic router (enhanced cbr). All messages
passed to this proxy will be delivered to the interested recipients
based on the specified xpath-expression. The answers must be
aggregated
because there can be several clients with the same interest and the
message will be send to more than one provider.
I am sorry. I didn't get this aggregation part, why do you think it is
a must to aggregate the answers, I cannot imagine an aggrgation here.
The aggreation is needed if I want to have a solicit response mex. The
notified client should also send a response to the server (maybe only an
ack or even a new message).
Let me explain in a more detail:
- There is JMS with the publish-subscribe mechanism with topics. Simple
and it works. Maybe we should consider that, too? Possibility is to
include activeMq into Synapse (optional) and provide configuration
messages like described in EIP-book of Hohpe/Woolf. Maybe I am
completely wrong with this approach, but I think more on deliver
messages to more than one party, maybe a "request and multiple replies"
Pattern. That´s the reason of thinking about aggregation. In my eyes it
is more a --dynamic-- recipient list with aggregation where the
interested parties can subscribe on, get messages and answer to them and
the publisher gets one or more messages back (depending on the
aggregation strategy).
- How would this look like with ATOM? Maybe you can keep an eye on the
new specs like WS-EventNotification?
Implementation offers:
- Apache Muse (WS-Notification specs)
- Apache Savan (WS-Eventing spec)
- own implemenation of a new offering protocol
The subscriptions must be shown in the admin console to have a
control
who wants to have the messages, to kick them and to have an overview.
Well, we can define a special type of a control message to the atom
mediator so that those control messages will not be published but will
be used to subscribe users to the atom instead, WDYT?
Yeah, thats a good point. Maybe you can tell me more about the ATOM
mediator?
Thanks,
Jens
Thanks,
Ruwan
