@ColinE: The reason you are having trouble getting additional answers is because you have a slightly loaded question. I think you have at least two questions:
1.) "Why buy third-party programming components?" (broad and vague question) and
2.) "Given my specific use case, should I buy a third-party real-time messaging component?" (depends on your conditions and less about general knowledge)
I will crack it, trying to balance the broad knowledge for anyone who could read this, to find out, and then turn to your specific use case. I work for a company that publishes a version of Comet / Bayeux for WebSync, so I have a lot of experience with this material. For the sake of equality, I will try to be very agnostic in my terminology, but it is fair to assume that the function / features / advantages of the real-time messages that I list are based on my extensive experience with WebSync. I don’t know much about Java and Apache implementations.
Why buy third-party components?
For almost any third-party programming component, there is an open source alternative available somewhere on the web. Although it’s difficult to apply third-party evaluation versus open source for the same size, I would say that my experience is that open source materials (like CodeProject articles) tend to be short-lived service without long term support. These open source style implementations are often created by one person who is trying to avoid the cost of a paid component to solve one particular use case. For this reason, they often implement only the most important functions for their application.
When you buy a third-party component, you rarely buy only the main idea. You are buying:
- wider functional implementation, tested and verified by hundreds of customers
- with a solid history as well as a plan for the future
- all wrapped in a promise of excellent technical support.
- and the availability of contracts from experienced developers, if you need it
So, the purchase decision goes something like this: How many hours will it take to realize my own comet? What is the value of that time at my bid? Is this amount less than the price of a third-party component?
Of course, then you need to think about the risks and the future: how could my own implementation be used for future projects? What risks will I take if the project volume increases? Could my budget time load double or triple if the scope of change changes? How much time can I spend on tuning performance for scalability or testing load balancing systems? What is my boss / client promoting another platform for our project in the future?
Quite often, if the project you are working on is a professional professional project, your own time savings and support available to the third-party component will cost much higher than the price paid for it. If your project is a non-profit, open source, social launch, you probably prefer to pack your pocket book a bit and enlist the support of the community to fill in the gaps.
Differentiation of a comet from Ajax poll
Your question also eludes a fixed interval of ajax polling as an alternative to comets. I want to clarify the differences a bit to help make a final decision.
Definitions
One of the challenges in the industry is the bewildering people of Comet, Bayeux and Streaming. The comet originally specifically referred to a lengthy survey and has now become a bit of a general term for delivering messages in real time over simple HTTP (protocol agnostic). Bayeux is a specification of how this data should look "over the wire" (protocol). Streaming is the idea of sending something in real time over the Internet. People often use them interchangeably, implying a single system with all three characteristics / capabilities. Some comets, like systems, do not use the industry standard bayeux protocol . They are not alone, but you will find that bayeux is supported by several major industry players and indicates how we talk about comets like applications with our servers. Bayeux is also what makes realistic standard implementations good together (good). I can even mix these terms a little, but at least now you know what I'm talking about when I say "Bayeux".
Explorer data duplication vs Initial state + Differential updates
With a fixed interval polling mechanism, you get exactly what it sounds like a fixed interval. With Bayeux, the idea is to avoid duplicating data over the wire. If the data has not changed, why send it again? This saves you bandwidth and overhead on your server. And very real financial costs affect your decision. On the other hand, if the data does change 3 times per second, the comet will not have delivery problems for you.
Following this step, Bayeux allows for the concept of " initial state + differential updates ." This means that when your javascript client starts up, you subscribe to a channel that returns the initial state for your 100 objects (possibly a heavy data object), then the Comet mechanism continues to provide incremental differential updates. Example: Entity 1 was just deleted, Entity 7 was just edited, we just inserted another object into the list, etc ... these are differential updates to the initial state. You never send a collection of 100 objects (unless all 100 objects have really changed in the last 1/3 second).
If you lose the connection (Wi-Fi is disconnected), the client will re-subscribe and start from a new initial state, and then continue differentiated updates. This ensures that you never miss an update. If you try to do this with a simple Ajax poll, you either duplicate the data (use bandwidth) or run the risk of skipping differential updates (unreliable).
With this arrangement, you are always equal or better in performance, bandwidth usage and overhead than the ajax long polling mechanism. In most cases, you use bandwidth much better.
Bayeux Packaging
Bayeux provides a “channel system” for segmenting data sent to clients. For example, if you did an AJAX survey, you will have one large block of data that you need to analyze (and create the server side). With a channel system, you publish channels like "/ entityA", "/ entityB" or even multi-level channels like "/ entityA / fooMessages" and "/ entityA / barMessages". The comet server will send all published messages to the client, where the client can distribute messages to the appropriate javascript handlers for each data segment (each channel).
Server side support
Not yet available in all Comet / Bayeux implementations, I know that WebSync has an excellent server-side event mechanism that allows you to "check" all messages arriving on or off your server. In these server-side events, you can upload new data, convert existing data, register diagnostic information, evaluate authentication status, call a third-party cross-domain API, etc. A lot of energy is here for preparing / processing the data that you want for distribution to your customers.
Should ColinE buy a third-party comet component?
So, now we have a wide structure for evaluating the choice of an open source exit or buying a commercial implementation. So let's look at the options that you gave me in your question.
Each client requires 100 objects with 3 updates per second. Thus, 300 separate JSON objects / messages fly for each client. This is a lot of data that needs to be promoted. I would say that everything you can do to reduce duplicated data on the wire will be of great benefit to you, so I would recommend the implementation of a comet with initial states + differential updates. Plus, with tracking many objects, segmenting data with channels will really help you in coding and save your time.
Option: Polling server 3 times per second with AJAX.
Pros:
- Cheap and easy
- JavaScript light weight
Minuses:
- Updates 3 times per second, regardless of the frequency of actual data changes (possible waste of bandwidth and processing overhead).
- You must implement 100% of the JSON generation on the server side and on the client side for a large (100 objects) JSON object. (No channel data segmentation)
- You must build all the error handling logic. What happens if my Wi-Fi drops by 3 seconds? Will your requests add up? Will you skip updates? How do you catch up / reload the page? Or will you just send ALL data 3 times per second?
Option: Buy a multifunctional comet implementation .
Pros:
- Minimizes bandwidth usage versus fixed interval polling (save money)
- Channels provide easy data segmentation (time savings in implementation / parsing)
- Batching Saves HTTP Requests (Higher Performance / Low Bandwidth)
- Excellent error handling with reconnection logic, customizable timeouts (increased reliability)
- Server-side support for working with events / messages / data (powerful and fast server code)
- Proven reliability, scalability and client platform support.
- Professional technical support, documentation, an affordable contract, if you need help.
Minuses:
- Upfront Licensing Costs
- Rich translates to larger JavaScript than simple AJAX polling