Thursday, May 03, 2007

SQS: Messaging Backplanes in Communications Architectures

For me, 2007 looks like the year of messaging backplanes. As an architect, it's a wonderful thing. Long a staple of enterprising messaging architectures, such as financial transaction applications, I believe it to be a very valuable addition to the standard telecom architecture. I'm doing two independent designs at the moment based on enterprise messaging technologies. The first is a gateway between two messaging architectures, designed to help customers migrate legacy messaging applications. An excellent project for me, as if you want to truly understand a protocol, do a gateway that converts it to something else.

The second project is an internal project we'll announce sometime later on in the year. For this one, we are using a hosted messaging backplane from Amazon called Simple Queue Service. (In fact, we are using nearly all of the Amazon APIs in the hosted version of this project, including the elastic computing cloud, simple storage service and, of course, the Turks.) Simple Queue Service, or SQS for short, is a simple, but extraordinarily powerful idea. SQS allows software to send messages between applications in a reliable and scalable way, using Amazon's hosted service. Messages are created by message producers, stored in the queue, and read by message consumers. Many different message producers may add to the same queue, as many different consumers may read from it. Amazon guarantees that a message is read at least once, and will hold a message for at least fifteen days. In practice, messages tend to be consumed nearly instantaneously, but it's good to know you've can go get a cup of coffee and not worry too much about missing a message. Messages can hold any data and, when combined with Amazon's simple storage service, can hold any data of arbitrary size.

An example might help here. Imagine you are designing a billing system for a large telecom carrier. If you have a switch creating call detail records, you could store those CDRs as an XML records in a local database. You could also take that XML data, and put it into an SQS queue to be read by a far end billing system. The billing system would wait for the XML record, and when it arrives, record it, bill it, invoice it, whatever. The calls to SQS are very simple and straightforward, and the service itself is quite inexpensive. Today's alternative implementation would probably use a standard such as Radius, which is supported in the billing world, has no traction outside of ISP billing in the Web world. SQS is a simple and straightforward alternative.

The advantages are numerous. First, since many producers can add to the same queue, you could use SQS to aggregate information from several sources. So, to extend our example, you could aggregate CDR data from many switches into a single outbound stream. Since SQS carries data only, different manufacturers can submit their XML into the queue without any impact to the billing system that consumes the data. Let's keep with the CDR example, and imagine that one of your twenty switches uses a different XML format than the other nineteen. Pretty simple with SQS. Create a piece of software that reads all of the XML from the aggregated stream, looks for the messages that need to be translated, translates and puts them back on the aggregated queue. Worried about the bottleneck? Don't be, as you can have as many instances of translators as you wish, as SQS guarantees that a message is read at least once, and if you wish, only once. The same argument is made for redundancy. You can have as may consumers or producers as you wish. If one fails, your throughput does drop, but the rest of the system is unaffected. (By the way, this is where the elastic computing cloud just rocks. Throughput dropping? Take 60 seconds to spin up a hundred or so servers to take care of it until you catch up, then give the servers back. Since a server costs about ten cents an hour.... well, you do the math.) This also makes components that hang off the message stream safer to deploy in production environments, as you can fractionally deploy components without affecting the core system.

The downside? Messaging backplanes do introduce a bit of delay into the system, and are probably inappropriate for communication between components where real time operation and response times must be guaranteed. As I think about the heuristics of real time design for web services based communications infrastructures, my gut tells me that the logical place for components is where real time communication is critical, where bottlenecks would occur, or where linear scaling is critical. Those components would then be best implemented in an Web Services, or SOA, architecture with messaging backplanes as the scaling and communication backplane.

We've been talking about Amazon SQS, which is undeniably the only reasonable hosted choice we have today. In a platform environment, there's a number of good choices ranging from legacy offerings from Tibco, down to the open source ActiveMQ offering. But honestly, the Amazon web services suite is so easy and inexpensive to use, it would take a lot for me to deploy my own platform. I suppose if you're Verizon, you could match the Amazon platform. Maybe. Either way, I expect to see communications architectures move from the inherently fragile legacy telecom designs towards new, service oriented designs, all on the backs of messaging solutions.


sexy said...













交友,AIO交友愛情館,AIO,成人交友,愛情公寓,做愛影片,做愛,性愛,微風成人區,微風成人,嘟嘟成人網,成人影片,成人,成人貼圖,18成人,成人圖片區,成人圖片,成人影城,成人小說,成人文章,成人網站,成人論壇,情色貼圖,色情貼圖,色情A片,A片,色情小說,情色小說,情色文學,寄情築園小遊戲, 情色A片,色情影片,AV女優,AV,A漫,免費A片,A片下載

清朝美女 said...

(法新社倫敦四日電) 英國情色大亨芮孟的a片下載公司昨天AV片說,芮孟日成人影片前去成人網站世,sex享壽八十二歲;色情這位身av價上億的房地產開發情色電影商,曾經在倫敦推成人網站出第一場脫衣舞表av演。





元美女 said...

(法新社a倫敦二B十WE四日電) 「情色二零零七」情趣產品大產自二十三日起在倫敦的肯辛頓奧林匹亞展覽館舉行,倫敦人擺脫對性的保守態度踴躍參觀,許多穿皮衣與塑膠緊身衣的好色之色情徒擠進這項世界規模最大的成人生活展,估計三天展期可成人網站吸引八萬多好奇民眾參觀情色電影




boogleboy said...







buy viagra online said...

Hello, I do not agree with the previous commentator - not so simple