Tervela Message Medium Blog | May 2009

But it worked in the lab... A deep and profound (please read it a couple of times) post by Kirk Wylie.  He claims that he's not trying to be down on best effort messaging, but he does have some valid points that we often hear from customers.

Here's a quote:

Best Effort = Development Win, Production Fail

 

Because the problem is that Best Effort systems seem much better than that in development. In development, you can run days without dropping a single message, no matter what size it is. In testing, you can run many test iterations without being able to force a message drop [2]. More importantly, you really can't force a message drop, at least not without implementing a lossy Decorator on top of the MOM interfaces. And that's a problem.

Best effort messaging is meant to be fast.  That's good.  But hardware (with some decent architecture) can make guaranteed messaging fast.  Check out our last post.  The reality is that there are many types and qualities of service when it comes to messaging.  Pick the one that makes the most sense for the applications you're running.  And be realistic.  To Kirk's point: a little bit of diligence in the lab will go a long way to avoiding surprises in production.

=rob.ciampa

Tags: best effort messaging (1) guaranteed messaging (2) kirk wylie (1) 

Comments (0)

Guaranteed messaging.  Guaranteed Delivery.  Durable Consumer.  Reliable.  Blocking.  Non-blocking.  Persistent.  Lots of descriptors attached to the concept of guaranteed messaging.

But what does guaranteed mean?  Where do the guarantees occur?  Is it really a guarantee or is it just statistical?  What price must I pay for a guarantee?  What’s my time window for assurance? How different is a guaranteed messaging flow from a best effort flow?  Are there different types of guarantees?

We’ve spent a good deal of time and R&D dollars on guaranteed messaging.  Though we’ve had for some time a guaranteed connected quality of service that seamless overcomes temporary operational issues, we needed something for major outages and debilitating breaks in continuity.  We opted, however, not to cobble something together that would perform like a sick dog and treat the term “guarantee” lightly.  Our base architecture was designed anticipating the need to have multiple qualities of services that were unified, seamless and fully functional.  Guaranteed messaging was not going to incur a tax.

Today we announced our “Real-Time Guaranteed Messaging Service” - but we claimed it was the “Industry’s First.”  Why?  Because it is both real-time and real-guaranteed.  Together for the first time.  What were our objectives?

• Give customers true assurance without the debilitating deficiencies of traditional guaranteed service
• Be the highest performing guaranteed messaging on the market
• Provide true guarantees, not statistical likelihoods
• Scale cleanly from workgroup to enterprise
• Leverage architectural differentiators that our competitors just can’t match

It’s a different market and information is far too important to implement guaranteed messaging the same old way.  It’s all about the architecture.  That's what drives business advantage.

=rob.ciampa

Tags: guaranteed messaging (2) quality of service (1) durable consumer (1) 

Comments (0)