On Wed, 2005-03-09 at 10:22 -0500, Caleb Epstein wrote:
On Wed, 9 Mar 2005 08:45:52 +0000 (UTC), Jarl Lindrud <jlindrud@hotmail.com> wrote:
As for messaging vs RPC, I think the same thing applies; it is easier to build an RPC layer on top of messaging than the other way around.
If you have oneway RPC's, why would it be difficult to build messaging on top of that? The two seem to me to be almost the same thing.
Messaging is often built on top of a broadcast or multicast transport, so one does not need to locate or connect to a remote endpoint in order to publish messages.
In most, if not all messaging systems you do have connect to an end point. The remote server provides various QoS and you need to register your subject or channel and whether you are a push or a pull publisher. Oh 8-) I think I'm re-inventing the CORBA Notification service. What a surprise.
I don't think one-way RPCs are an adequate replacement for publish-subscribe semantics like these if you have a large fanout. Simple one-way RPCs don't have a return value and can't throw exceptions an so there not a good way for messaging if you want QoS other than best efforts. The fan out is irrelevant using multi-cast.
/ikh
On Wed, 9 Mar 2005 16:25:34 -0000, Iain Hanson <Iain.Hanson@videonetworks.com> wrote:
In most, if not all messaging systems you do have connect to an end point. The remote server provides various QoS and you need to register your subject or channel and whether you are a push or a pull publisher. Oh 8-) I think I'm re-inventing the CORBA Notification service. What a surprise.
This is not how TIBCO RV works. You need to connect to the RV daemon (which can be auto-started on your local host) but you do not need to pre-register anything if you're using the normal "reliable" QoS. There is no direct communication between subscribers and the publisher. If a subscriber (or really its RV daemon) detects a gap in sequence, it will request a retransmission automatically and, if the message is still in-core on the sender side, the sending RVD will resend it. I'd call this NAK-based processing and it is overall quite effective. With their Certified Messaging protocol, however, each subscriber registers with the publisher and must ACK each message. -- Caleb Epstein caleb dot epstein at gmail dot com
----- Original Message ----- From: "Caleb Epstein" <caleb.epstein@gmail.com> [snip]
On Wed, 9 Mar 2005 16:25:34 -0000, Iain Hanson <Iain.Hanson@videonetworks.com> wrote:
In most, if not all messaging systems you do have connect to an end point. The remote server provides various QoS and you need to register your subject or channel and whether you are a push or a pull publisher. Oh 8-) I think I'm re-inventing the CORBA Notification service. What a surprise.
This is not how TIBCO RV works. You need to connect to the RV daemon (which can be auto-started on your local host) but you do not need to pre-register anything if you're using the normal "reliable" QoS. There is no direct communication between subscribers and the publisher. If a subscriber (or really its RV daemon) detects a gap in sequence, it will request a retransmission automatically and, if the message is still in-core on the sender side, the sending RVD will resend it. I'd call this NAK-based processing and it is overall quite effective.
With their Certified Messaging protocol, however, each subscriber registers with the publisher and must ACK each message.
I may be responsible for some confusion here. If that is the case then perhaps this will help. I believe I introduced the term "messaging" to this discussion. I chose the word because I hoped it would be less confusing than terms I am used to, i.e. signaling. CORBA Notification is a fine thing. Messaging systems (involving store and forward) are also fine things. But neither are really in the same domain as the original discussion. Which does not necessarily detract from yours :-) Lastly I think that Jarls responses (and others) have followed my original meaning. All good, Scott
On Thu, Mar 10, 2005 at 09:41:13AM +1300, Scott Woods wrote:
I believe I introduced the term "messaging" to this discussion. I chose the word because I hoped it would be less confusing than terms I am used to, i.e. signaling.
Sorry, but I still don't understand what you mean by messaging then. could you please elaborate. Regards /ikh
participants (4)
-
Caleb Epstein -
Iain Hanson -
Iain K. Hanson -
Scott Woods