Talk:Publish/subscribe

From Wikipedia, the free encyclopedia

	This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
???	This article has not yet received a rating on the quality scale.
???	This article has not yet received an rating on the importance scale.

• I'm removing the following paragraph from the "Disadvantages" section. Broadcasting or multicasting messages does not typically lead to greater network load than traditional client/server (which normally uses Unicast). For any given volume of messages, broadcast or multicast will almost always lead to less network load than unicast since unicast-based systems must transmit a separate copy of each message to each subscriber. The whole point of multicast is to prevent this duplication of data. Perhaps the author was thinking of UDP or raw IP v.s. TCP. Most UDP or raw IP protocols do not have the sophisticated congestion control that TCP does. TCP will automatically slow down publishers to prevent network overload, whereas UDP protocols will not. Since broadcast and multicast protocols always UDP or raw IP, it might be easy to blame the addressing mode for the lack of congestion control. I thought about simply re-working the paragraph to reference UDP and raw IP, but the problem of network overload is far from universal even there. Some multicast pub/sub systems offer other methods of congestion control, such as rate limiters. In reality, network overload is a characteristic of individual implementations of pub/sub, not of the paradigm, addressing method, or underlying protocol. Here is the original paragraph I'm removing. Fordsfords 03:23, 11 March 2007 (UTC)

Messages are often broadcast or multicast over a network, allowing for a more dynamic network topology. However as the volume of messages increase, this can result in overloading of the network without appropriate management or pruning strategies. This may be mitigated by the fact that hardware typically enjoys better economies of scale than software.

Whats the point of keeping an article on "click fraud" in the Articles section? —Preceding unsigned comment added by 203.200.84.194 (talk) 16:05, 4 September 2007 (UTC)

I'm sorry to all contributors, but that article is quite awful.

• The disadvantages section sounds like it was written by angry Linux wannabe admin who failed to solve all his problems by installing pub/sub DB.
• "Pub/sub" itself sounds awful. And it's not good as a google bait.
• The article fails to explain that guaranteed message delivery is something common... in good Publish/subscribe databases.
• Also, WTF has failure of some subscriber's logging system has to do with Publish/subscribe architecture? That could happen with any data source. I download something from FTP or MySQL or even Oracle and my computer crashes! I need to edit Oracle article because it's unreliable! /sarcasm.
• I'm not an expert, but I've worked with JMS in EAI area.

Analytik (talk) 17:27, 5 February 2008 (UTC)

[edit] Conflict of interest and outdated information

I have removed the following paragraph, as it appears to be nontopical (nothing to do with pub-sub as such) and the writer, User:Ken Birman is biased (being one of the inventors and having a financial stake in it).

Virtual synchrony is an example of a distributed execution model that can be applied to pub/sub systems to endow them with stronger fault-tolerance and consistency guarantees.

Furthermore, Publish-subscribe networks is a topic under heavy research. I'd update to the newest state of the art, but am having trouble finding sources that aren't behind pay walls such as ACM. Still, a lot of the disadvantages are simply incorrect. What should be done about them? Anaholic (talk) 12:54, 8 February 2008 (UTC)

First, and for the record: I have absolutely no "financial interest" at stake here whatsoever. I did once, 10 years ago, but for 10 years I have not held any kind of financial investment or had anything to sell in that field, and none of my personal investments are in any way connected to publish-subscribe. Even my textbook (which does discuss both technologies -- accurately -- is royalty free: when it gets sold, I get zero. I'm not sure how you can speak with authority about anyone's financial interests, but in my case, you are simply incorrect. I would like to request that you remove that claim from your comment (at which point you have my permission to remove this rebuttal from this paragraph). Thanks.

I understand your point, but the revision you have made creates a historical inaccuracy. The first publish-subscribe system was the "news" subsystem in the Isis Toolkit and was described in the 1987 ACM Symposium on Operating Systems Principles conference, in a paper "Exploiting Virtual Synchrony in Distributed Systems. 123-138". The publish-subscribe technology described there was invented by Frank Schmuck, who probably should get the credit as the first person to ever invent a fully functional publish-subscribe solution.

Encyclopedia articles need this sort of historical content or they basic write people out of history. I've studied the Wiki policy on POV and COI, and the rules are written to legislate against self-serving Wiki entries. They explicitly make it clear that experts (who will often have a COI) can and should participate, and they also make it clear that accuracy of the type expected from an encyclopedia outweighs superficial COI concerns.

True, Frank was my student, and indeed, the first paper really describing that work didn't actually have his name on the author list. Nonetheless, it was his work we're discussing here. Omitting that information has the effect of removing a critical first page from the history of publish-subscribe. Moreover, the reality is that publish-subscribe emerged from work on virtual synchrony.

I'm going to suggest that you fix the section to be historically accurate, thus avoiding any argument about COI. But eliminating references to Frank's seminal work is unfair to the real inventor who should get credit for inventing this entire field of research, and I certainly hope you'll fix the section in a way that does justice to his contribution!

As for disadvantages, I'll just note that many of the world's largest data center operators are reporting serious instability issues with publish-subscribe as implemented by some of the largest publish-subscribe vendors. This is just truth. I would hope that your edits don't somehow reduce the accuracy of the article... but again, I won't edit the article myself. I'm comfortable with others doing so. Ken Birman (talk) 13:25, 12 February 2008 (UTC)

It appears that you are correct about no longer having a financial stake in things; I was working on outdated information. Obviously I should have checked first.

Still, I don't believe this invalidates the rest of my reasoning. You still have a stake in virtual synchrony - you'd have t be superhuman not to - and it does not deserve to be mentioned in the /introduction/ any more than logical clocks does. It is simply one technique among many, not a technique that is central to implementing pub-sub systems or one that is only useful in pub-sub systems.

You would be very welcome to add a historical perspective to the article, however, preferably in a section on history. It may well be right that it was the *first* practical pub-sub system, it simply is no longer a very central one. Anaholic (talk) 14:01, 12 February 2008 (UTC)

In fact, I'll go ahead and move said paragraph to a historical section on my own. It will of course be a rather meagre one.. expansion would be good. I'm not going to remove any comments on this page, though. I'm a big believer in history, but consider the my claim that you have a financial stake officially redacted. Anaholic (talk) 14:08, 12 February 2008 (UTC)