The past year's economic slump has lead many application architects to explore open source components for their...
SOA middleware stack - even such complex components as the enterprise service bus (ESB). The decision to adopt an open or closed-source ESB can be tough. It requires a company to weigh cost against complexity and gauge its own programming savvy.
"Every vendor is saying they support every file format under the sun," said independent analyst Larry Fulton. "You're just seeing more and more things being packed in." Open source products have evolved with people typically looking at essential ESB elements, he indicated.
Fulton said commercial ESB vendors developed user-friendly tooling and GUIs early on, while the open source community focused mainly on the "engine." As such, open-open source ESBs support fewer protocols and don't tend to have advanced productivity features.
For some, simple may be better.
"Proprietary vendors have been in the business of building a cash cow product and then bolting on other features," said Ross Mason, co-founder and CTO of MuleSource. "With open source, it's tailored to real value. You can say, 'If I don't need complex event processing, don't send it to me."
Open source ESBs are not lacking is in their ability to run effectively in mission-critical situations, Fulton said. They are not as flashy as their commercial counterparts, but when it comes to messaging, routing and service-enablement in general, they are capable, Fulton suggested.
"They give the ability for the architects to put together only the functionality they want," claimed Sanjiva Weerawarana, founder and CEO of WSO2. "If you buy Oracle, you have to adapt your architecture to your middleware. If you go open source, you can adapt your middleware to your architecture."
In many cases, open source technology requires more sophisticated users. It often requires heavy customization and newer advancements are not always well documented.
"It really depends on each organization and their technological maturity," said Burr Sutter, senior product manager at Red Hat's middleware division. "Traditionally, the open source [developers] are more innovative."
Burr said the federal government and the Department of Defense have both begun using open source middleware. He said this is largely because the government wants to be able to examine the source code for security risks and configure everything to its needs.
The most obvious benefit to open source products is that the code is free. Architects and developers can test and explore them for as long as they need to and often, with greater freedom.
"One of the reasons I think developers are fond of them is they can use them without a committee or separate team," said Fulton. "If I'm the solution team, it's my own ESB. And that ESB gives me the ability to interface with anything else in the organization."
Another large draw to open source is the community of developers. Each of the open source ESBs on the market has some kind of following, but there is not a great deal of overlap just yet.
"The open source ESB community is somewhat fragmented across a number of projects," said Jaime Merritt, director of FUSE product management at Progress Software. "With the ESBs that really take the standards-oriented approach, it extends to other communities."
Whether or not open source middleware development will stay fragmented or move toward common standards is anyone's guess. But when IT budgets are tight and features like GUI and productivity add-ons are not necessary, open source ESBs provide a lower-cost backbone to the SOA stack.
"Always understand what the ESB means from a business standpoint," said Fulton. "If its role is intermediating a component inside a single business solution, then there are a lot of things you don't really need that won't add value. That's the sweet spot for open source ESBs."