If there is anybody who is a champion for data abstraction when it comes to SOA, it's me. Moreover, if there is anybody who is a champion for open source SOA technology, it's me. So, how about if there was a company who provided both? That's the concept behind XAware's new open source offering, which follows a few other SOA open source players, including open source ESBs and application servers. XAware, If there is anybody who is a champion for data abstraction when it comes to SOA, it’s me. Moreover, if there is anybody who is a champion for open source SOA technology, it’s me. So, how about if there was a company who provided both? That’s the concept behind XAware’s new open source offering, which follows a few other SOA open source players, including open source ESBs and application servers. XAware, who has provided a data management and data abstraction technology for years, has recently moved into the open source world with their XAware 5 offering. What’s cool about this product is that it lowers the cost of entry into the world of data abstraction for SOA, and puts the end user in direct control. XAware is looking to build a community around this product, as well as a support infrastructure, which is critical to any open source play. XAware provides data abstraction tool that allows the architect to create a logical database before linking existing physical data stores to it. Thus, this allows the architect to work from the design to the implementation, and provides complete independence from the physical instances of data. This is critical when following my recommendations that first you have a complete semantic understanding and logical structure, before hooking up the physical data sources. These in turn become the data access layers for the services, providing agility at the data layer. If you think that I think that data abstraction is a clear need for most SOAs…you’re right. I think open source, when it comes to SOA, 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. To the first point, SOA technology is expensive. I’m talking ESBs that cost as much as Bentleys expensive. Thus, anything that can reduce (or eliminate) costs makes good sense when they are considered with the mix of technology you need to build a SOA. Guys like XAware, for instance, can provide you with key SOA technology at a very low price point. Mule Source is an example of an open source ESB player with a low price point as well, and there are other open source SOA players out there, all offering their wares at a discount. 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. Software Development