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.

6 comments:

sexy said...

情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣用品,情趣,情趣,情趣,情趣,情趣,情趣,情趣,情趣,A片,視訊聊天室,聊天室,視訊,視訊聊天室,080苗栗人聊天室,上班族聊天室,成人聊天室,中部人聊天室,一夜情聊天室,情色聊天室,視訊交友網a片,a片


免費A片,AV女優,美女視訊,情色交友,免費AV,色情網站,辣妹視訊,美女交友,色情影片,成人影片,成人網站,A片,H漫,18成人,成人圖片,成人漫畫,情色網,日本A片,免費A片下載,性愛

A片,色情,成人,做愛,情色文學,A片下載,色情遊戲,色情影片,色情聊天室,情色電影,免費視訊,免費視訊聊天,免費視訊聊天室,一葉情貼圖片區,情色,情色視訊,免費成人影片,視訊交友,視訊聊天,視訊聊天室,言情小說,愛情小說,AIO,AV片,A漫,avdvd,聊天室,自拍,情色論壇,視訊美女,AV成人網,色情A片,SEX,成人論壇

情趣用品,A片,免費A片,AV女優,美女視訊,情色交友,色情網站,免費AV,辣妹視訊,美女交友,色情影片,成人網站,H漫,18成人,成人圖片,成人漫畫,成人影片,情色網


情趣用品,A片,免費A片,日本A片,A片下載,線上A片,成人電影,嘟嘟成人網,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,微風成人區,成人文章,成人影城,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,臺灣情色網,色情,情色電影,色情遊戲,嘟嘟情人色網,麗的色遊戲,情色論壇,色情網站,一葉情貼圖片區,做愛,性愛,美女視訊,辣妹視訊,視訊聊天室,視訊交友網,免費視訊聊天,美女交友,做愛影片

av,情趣用品,a片,成人電影,微風成人,嘟嘟成人網,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,成人文章,成人影城,愛情公寓,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,色情,寄情築園小遊戲,情色電影,aio,av女優,AV,免費A片,日本a片,美女視訊,辣妹視訊,聊天室,美女交友,成人光碟

情趣用品.A片,情色,情色貼圖,色情聊天室,情色視訊,情色文學,色情小說,情色小說,色情,寄情築園小遊戲,情色電影,色情遊戲,色情網站,聊天室,ut聊天室,豆豆聊天室,美女視訊,辣妹視訊,視訊聊天室,視訊交友網,免費視訊聊天,免費A片,日本a片,a片下載,線上a片,av女優,av,成人電影,成人,成人貼圖,成人交友,成人圖片,18成人,成人小說,成人圖片區,成人文章,成人影城,成人網站,自拍,尋夢園聊天室

said...

A片,A片,成人網站,成人漫畫,色情,情色網,情色,AV,AV女優,成人影城,成人,色情A片,日本AV,免費成人影片,成人影片,SEX,免費A片,A片下載,免費A片下載,做愛,情色A片,色情影片,H漫,A漫,18成人

a片,色情影片,情色電影,a片,色情,情色網,情色,av,av女優,成人影城,成人,色情a片,日本av,免費成人影片,成人影片,情色a片,sex,免費a片,a片下載,免費a片下載

情趣用品,情趣用品,情趣,情趣,情趣用品,情趣用品,情趣,情趣,情趣用品,情趣用品,情趣,情趣

A片,A片,A片下載,做愛,成人電影,.18成人,日本A片,情色小說,情色電影,成人影城,自拍,情色論壇,成人論壇,情色貼圖,情色,免費A片,成人,成人網站,成人圖片,AV女優,成人光碟,色情,色情影片,免費A片下載,SEX,AV,色情網站,本土自拍,性愛,成人影片,情色文學,成人文章,成人圖片區,成人貼圖

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

清朝美女 said...

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

色情影片
芮孟的財產成人影片估計成人達六億五千萬英鎊(台幣將a片近四百億),由於他名下事業大多分布在倫敦夜生活區蘇活區色情成人因此擁有「蘇活情色視訊之王」日本av的稱號。
部落格

他的成人電影公司「保羅芮孟集團」旗成人網站下發行多a片種情色雜av誌,包括「Razavzav女優leavdvd」、「男性世界」以及「Mayfai情色電影r」。色情a片
a片下載
色情
芮孟情色本名傑福瑞.安東尼.奎恩,父av女優親為搬運承a片包商。芮孟十五歲離開學校,矢言要在表演事部落格業留名,起先表演讀心術,後來成為巡迴歌舞雜耍表演av女優的製作情色人。


許多評論a片成人電影認為,他把情色表演帶進主流社會,一九五九部落格年主持破天荒的脫衣舞表演,後來成人影片更靠著在蘇活區與成人光碟倫敦西區開發房地產賺得大筆財富。


有人形容芮孟是英國的海夫納,地位等同美國的「花花公子」創辦人海夫納。

元美女 said...

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

活動計畫負責人米里根承諾:「要搞浪漫、誘惑人、玩虐待,你渴望的我們都有。」

他說:「時髦的設計與華麗女裝,從吊飾到束腹到真人大小的雕塑,是我們由A片今年展出a片的數千件產品精選出情色成人網站一部分,參展產品還包括時尚服飾、貼身女用內在美、鞋a片下載子、珠寶、玩具、影片、藝術、圖書及遊戲,更不要說色情性愛輔具及馬術裝備。」
av女優
參觀民眾遊覽兩百五十多個攤位,有性a片感服裝、玩具及情色食品,迎合各種品味。A片下載
情色
大舞台上表演的是美國野蠻搖滾歌手瑪莉蓮曼森的前妻─成人電影全世界頭牌情色電影脫衣舞成人電影孃黛塔范提思,這是她今年在英國唯一一場表演。

以一九四零年代風格演出的黛塔范提思表成人影片演性感av的天堂鳥、旋轉木AV馬及羽扇等舞蹈。色情影片
成人影片
參展攤位有的推廣情趣用品,有的公開展示人體AV女優藝術和人體雕塑,也有情色藝術家工會成員提供建議。

boogleboy said...

成人網站,av女優,成人網站,a片,成人影片,h漫,成人電影,成人電影,色情,成人影片,免費A片,色情,成人影片,色情,免費A片,微風成人,情色,成人網站,av女優,成人網站,a片,成人影片,h漫,色情,成人電影,色情,成人電影,色情,成人影片,免費A片,成人影片,免費A片,情色,微風成人,成人網站,av女優,成人網站,a片,成人影片,h漫,成人電影,成人電影,色情,成人影片,免費A片,色情,成人影片,色情,免費A片,





微風成人,情色,成人網站,av女優,成人網站,a片,成人影片,h漫,色情,成人電影,色情,成人電影,色情,成人影片,免費A片,成人影片,免費A片,情色,微風成人,情趣用品,情趣用品,情趣用品,情趣用品,打卡鐘,跳蛋,持久液,成人網站,成人網站,成人網站,成人網站,色情網站,色情網站,色情網站,色情網站,av女優,av女優,av女優,av女優,色情,色情,色情,色情,h漫,h漫,h漫,h漫,sex,sex,sex,sex,成人影片,成人影片,成人影片,成人影片,成人電影,成人電影,成人電影,成人電影,av女優,a片,a片,a片,a片,成人網站,







成人網站,成人網站,成人網站,成人影片,成人影片,成人影片,成人影片,av女優,av女優,av女優,av女優,色情,色情,色情,色情,h漫,h漫,h漫,h漫,sex,sex,sex,sex,情色,情色,情色,情色,黃金回收,黃金回收,黃金回收,黃金回收,借錢,借錢,借錢,借錢,植牙,植牙,植牙,牙醫,牙醫,牙醫,a片,a片,a片,a片,情趣用品,情趣用品,情趣用品,情趣用品,成人網站,成人網站,成人網站,成人網站,成人影片,成人影片,



成人影片

,成人影片,av女優,av女優,av女優,av女優,色情,色情,色情,色情,h漫,h漫,h漫,h漫,sex,sex,sex,sex,情色,情色,情色,情色,黃金,黃金,黃金,黃金,黃金價格,黃金價格,黃金價格,黃金價格,黃金買賣,黃金買賣,黃金買賣,黃金買賣,當舖,當舖,當舖,當舖,鑽石價格,鑽石價格,鑽石價格,鑽石價格,鑽石回收,鑽石回收,鑽石回收,鑽石回收,鑽石買賣,鑽石買賣,鑽石買賣,鑽石買賣,黃金存摺,黃金存摺,黃金存摺,







黃金存摺,辣妹視訊,辣妹視訊,辣妹視訊,辣妹視訊,080視訊聊天室,080視訊聊天室,080視訊聊天室,080視訊聊天室,美女交友,美女交友,美女交友,美女交友,情色視訊,情色視訊,情色視訊,情色視訊,哈啦聊天室,哈啦聊天室,哈啦聊天室,哈啦聊天室,ut聊天室,ut聊天室,ut聊天室,ut聊天室,聊天室,聊天室,聊天室,打卡鐘,火鍋吃到飽,創業加盟,賺錢,吃到飽麻辣鍋

buy viagra online said...

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