IBM recently announced that DataPower XI50 appliance now supports transformations developed using WebSphere Transformation Extender design studio. This is the same technology used in the Message Broker product. Additionally, support for WebSphere Registry and Repository has been added. From the announcement:
New offerings being announced today include the WebSphere DataPower Integration Appliance XI50, which now supports direct database connectivity including IBM’s DB2 data server extending the XI50’s enterprise service bus capabilities. It also adds support for WebSphere Transformation Extender design studio providing common data transformation tooling across IBM’s ESB portfolio. The XI50, along with a new version of the WebSphere DataPower XML Security Appliance XS40, now integrates with the IBM WebSphere Service Registry and Repository (WSRR) to offer enhanced governance capabilities and improve service interoperability, reuse and connectivity.
So why is it significant?
XML appliances that were previously used mostly as firewalls are morphing into full-blown ESB products that compete with software ESB offerings. DataPower XI50 has always provided a good set of ESB-like features; however its transformation capabilities were limited mostly to XSLT. Non-XML formats were supported but required a third-party tool for developing transformation logic. With this newly added transformation support, the product’s feature set becomes more complete.
I think this trend will continue and, most likely, will accelerate. More and more SOA implementations are going to use appliances as their primary (and only) ESB product.
The idea of off-loading all integration functionality into a low-maintenance, highly secure device that is also optimized for performance is extremely appealing to developers and IT departments. Implementing “proper” software-based ESBs involves complicated installation and configuration. Configuration of a self-contained device is a much easier task. It is also easier to find people with the necessary skills to support these devices; these people don’t have to be developers with in-depth knowledge of Java EE or .NET (although some development skills are certainly desirable).
The beauty of a good XML appliance is that it encapsulates functions of several different products: XML gateway/firewall, XML accelerator, crypto accelerator and now even ESB. This is pretty powerful.
Another thing that is currently happening is that people begin to realize that SOA doesn’t make IT infrastructure any simpler. On the contrary, SOA, being a distributed environment, introduces more complexity and require much more sophistication to manage it. XML appliances can help reduce this complexity.
I agree this is the next phase in the evolving SOA Platform as it becomes more distributed.
In my opinion the XML appliance will likely be a subset of the ESB and be networked with an ESB to provide a distributed solution. You can check out a couple of my blogs where I discuss this trend.
http://soanetworkarchitect.com/2007/02/08/the-evolving-soa-platform.aspx
http://soanetworkarchitect.com/2006/12/16/esb-functionality-in-the-net–mark-richards.aspx
Regards,
Gary E. Smith
SOA Network Architect
SOA Networks
Few questions:
1) How do the appliances work in environments where there are multiple networks? Say for instance, I have an intranet that I use for development and an internet connection on which I deploy my product to the outside world. Do I need two appliances? The reason I ask is that pitching management on purchasing these devices for multiple environments has been challenging on the projects which I have worked on. Usually they want to use a free alternative on development networks and testing networks (obviously not ideal). With application servers, it has been fairly straightforward to use say Geronimo on the development network, but Websphere on the production network.
2) Last I looked at these appliances, their cost was quite high. As such I only recommended them if the horsepower was required to get the job done. Does it make sense to use a software implementation when performance isn’t a bottleneck?
3) You mention that they are fairly easy to support… My experience has been that it is not only difficult to find IT guys that will support application servers, but they usually end up needing the developers because they just don’t have the background required to understand all the parameters. Have these appliances finally reached a stage where development skills aren’t required?
Jon,
1) Most appliances can be configured to have multiple network cards, however, you still want to have your production appliance as a separate device. So at the very least you’ll need two devices (a device can then be partitioned into multiple logical environments, say for development and testing).
2) There are quite a few different appliance vendors (DataPower, Layer7, reactivity, others). You can shop around. The cost is comparable to the cost of the software ESB products from leading vendors, these products are not cheap either.
3) You still need developers to put together mediations deployed to an appliance. The developers, however, could be more junior than in case of application servers since there are no prerequisites for in-depth knowledge of J2EE, .NET and OO.
I happen to blog recently about the features of IBM datapower at http://mkosaraju.wordpress.com
Coming to your topic, YES, the roadmap of these appliances clearly shows that they are trying to support most of the ESB features to make it look more than an ESB gateway solution.
As I mentioned in my blog, support for transaction co-ordination, state management, process synchronization etc are not there yet.
There are very few blogs on these bleeding edge topics and I am glad I found yours :-)
Cheers,
Murali Kosaraju
I haven’t encountered this software yet, but I’ve hear some rumors about it! is this the newest version? I’m not really familiar with software’s, cause I’m not giving much attention to my programming class but now?maybe I should.great post.
search appliance enterprise