The most frequent question I was asked at last week's conference was around the use of open source technology for SOA. Here is my general response:
When it comes to SOA, I think open source provides two major advantages:
- First, it's typically much less expensive than the tools and the technology that are proprietary.
- Second, they are typically much more simplistic and easier to understand and use.
The argument that the larger players are making against open source SOA tools is that you get what you pay for. While this is true in some instances, it's mostly not true when it comes to SOA. Most of the open source SOA players that I see provide many of the same features and functions, just in different ways. Once again, your requirements should come before you pick your technology. If an open source SOA player works as a solution and you're comfortable with the company, than the price should be a nice benefit as well.
[ Read more of David Linthicum's observations on SOA in his Real World SOA blog. ]
This does not mean, however, that open source tools are always the right solution. It means that you need to consider them in the mix, taking into consideration the benefits of using open source. Don't send me angry e-mails if your open source SOA vendor misses the mark. That's on you. You need to figure out your requirements and test the darn thing before accepting it as a solution, proprietary or open.
To the second point, simplicity. The open source SOA vendors seem to take a much more rudimentary approach to SOA, and their tools seem to be much easier to understand and, in some cases, use. While some people want complex, powerful tools, the reality is that most SOAs don't need them. If you're honest with the requirements of the project, you'll see that good enough is, well, good enough. As a result, you end up with less expensive technology that provides only a subset of the features and functions of the larger big stack players. If you don't need them, they only make things more complex, and SOA is complex enough as is.
One of the major mistakes that a SOA architects can make is to rely upon the big stack players to provide them with all of the components they need to build their SOA. While this seems like the most logical solution, the fact is that while the big SOA stack guys are able to provide the right technologies at some layers, they are typically the wrong technology at other layers. Again, requirements to technology, not the other way around.