As the number of high-profile distributed systems continues to grow, managers will have to ensure that developers...
can re-think basic approaches to design applications. It is not easy. This is not something programmers learn in school.
Programmers have traditionally looked to control the order of events in an application, but such programs take time to complete a process and sequential dependencies mean that one dead program can break the system. The rise of social networks like Facebook and large e-commerce sites like Amazon, which must handle numerous tasks quickly and reliably, has interested many businesses in rearchitecting Web applications along asynchronous, message-oriented middleware (MOM) lines.
David Dossot, CTO at Pug Pharm Productions, a social gaming developer in Vancouver, British Columbia emphasizes that the asynchronous approach requires developers to cede power over sequences in an application. "When you start working with messaging systems you need a mind shift," said Dossot. "You need to kind of let go the control you have on the orchestration."
"Inventory, invoicing, shipping etcetera—you want that to occur asynchronously," said Dossot, who uses Erlang and RapidMQ for messaging at Pug Pham and has been reviewing Mule MQ, a new Java Message Service (JMS) implementation from San Francisco-based MuleSoft, Inc.
"The traditional [programmatic approach] is to have things operating through subsystems. [But] if one of these subsystems is down, the system will have to try again later," does Dossot.
To power asynchronous applications, developers rely on message-oriented middleware (MOM). Message-oriented middleware allows independent queuing and distribution of messages between programs. "The message middleware acts as a central third party," said Dossot. "It allows you to decouple subsystems. If one goes down, the infrastructure works."
That shift seems to be underway. "Developers nowadays are very much aware of this approach," Dossot said. "People are discussing more and more the issues of setting up systems that use message queuing."
MuleSoft announced Mule MQ last week. The product can be deployed with the Mule ESB or can be a stand-alone messaging service. Dossot evaluated the product prior to its official release.
Dossot was impressed that Mule MQ does not require a database. "Most JMS implementations require a relational database behind the scene. That's cool, but it is an extra bit of infrastructure," said Dossot. "Mule MQ handles its own persistence in the file system."
He also commented on the usability of the management console. "It's very rich. This is something that is very much lacking in most of the open source implementations," he said.
Dossot noted that Mule MQ can be easily integrated. "The client is a standalone JAR, so you can very easily drop it in an existing application," he said.
Adding message-oriented middleware to an infrastructure may require operations departments to undergo a mindshift of their own. "Traditionally, for operations, the critical piece of infrastructure was the database," said Dossot. "Now you have, for example, distributed caches and MOM."
Dossot believes it is important that operations understands where middleware fits in the infrastructure. "Operations, initially, tend to look at an MQ provider as an application," said Dossot. "[Operations] people tend to go for SLAs that are oriented for applications."
An SLA, though, may not give message-oriented middleware the attention it needs to function reliably. "Persons will need to be very close to this infrastructure," said Dossot.