Read part two.
What is the relationship between the new WSO2 Enterprise Service Bus and the Apache Synapse project you are also working on? |
|
|
|
| Paul Fremantle | |
|
|
Requires Free Membership to View
When you register, you'll begin receiving targeted emails from my team of award-winning writers. Our goal is to keep you informed on recent service-oriented architecture (SOA) and SOA-related topics such as integration, governance, Web services, Cloud and more.
Hannah Smalltree, Editorial Director
The core runtime engine is Apache Synapse and if we have enhancement to that the code always goes back to Apache Synapse. We're not trying to keep back any kind of core code, but fundamentally the core runtime is based on the Apache project. What is the WS02 value add then?
We're offering support for the ESB whether it's commercial high quality training, support, services. Then we have a graphical user interface. It's a completely Web-based user interface that allows you to configure, monitor and manage the underlying Synapse. Is that an Ajax-based Web interface?
It is an Ajax-based Web interface. One of the things it does is expose all of the management APIs as services as well. So you can call them from other interfaces. So this is an ESB with management built-into it?
Absolutely, but this is all completely open source including the management console. Are there other differentiators?
We have two things that help us with performance. First, we compose messages in constant memory without large trees or message models in memory. There are cases where you do have to build the message model in memory. You can't always stream it. But where we can stream we do. The second one is that we have a complete unblocking transport model. So we can handle very high numbers of connections without running out of threads or blocking. We prioritized on having a very solid runtime that will scale up. We've also prioritized on simplicity with a very clean, simple model. Some vendors are trying to offer both an open source and what they are calling a "closed source" ESB. Do you think that work?
When I was with IBM I was involved in situations where they had open source and closed source, and I always found that very difficult to differentiate for customers, especially as open source increased in quality over the last few years in terms of capabilities. That's one of the reasons why we don't have any kind of enterprise versions and standard versions and free versions and paid-for versions. We just have a straightforward open source offering that you can buy support for. We just thought it was much simpler for our customers. Is there going to be a place for closed source ESBs in the future?
My feeling is that there are some products that are very niche. For example, there are some financial institutions that have incredibly high performance messaging requirements. If you need to do a million messages a second, you're going to need very complex highly tuned software to do that. And the market for that is maybe 30 to 100 customers. It's not a wide open market. So if I had a product like that, I wouldn't open source it.
But on the other hand, an ESB is becoming a de facto, just-what-I-need kind of thing. And even small companies are seeing the benefits of having an ESB. So for that marketplace, I see open source just completely taking over. Why would I have a proprietary product in a space where there are two or three high quality open source equivalents that do the job well, have a lower cost of ownership and I don't end up locked into a particular vendor's approach?
|
||||
|
|
|||
|
||||
Yes. I think we have stabilization in the first projects. We're come out of 2007 with a much more solid platform for SOA. We're talking to much larger organizations, Fortune 500 companies that are now seriously considering open source for SOA. Beyond the ESB, are there new projects or new technology in open source for SOA that you find particularly interested in?
We've just started our SOA registry project based on REST. There are open source UDDI projects and there are projects based on ebXML, but that is a space where I see people buying very expensive proprietary products. For our project we looked at UDDI and we looked at ebXML and we felt they were both kind of heavyweight and overly complex solutions. So we went back to first principles and when we looked at it we realized that fundamentally the Web resources are the most important when you look at a registry/repository. It's really about managing resources. So that took us to the REST model. So we're building a completely REST-based registry/repository.
In part two of this interview tomorrow, Freemantle discusses infrastructure software and standards for service-oriented architecture (SOA).