The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Miko Matsumura on Jun 28, 2006
InfoQ had the opportunity to chat with Dr. Mark Little, JBoss Director of Standards and ESB development manager about the recent announcement that JBoss had acquired Rosetta ESB.
InfoQ: can you tell us a bit more about how JBoss ESB came to acquire the Rosetta ESB?
Mark: We've been working on our own implementation for a while and have had a lot of community participation. However, when this ESB came to our attention, it was something that we couldn't ignore. I'm a strong proponent of buy versus build, where it makes sense ;-)
InfoQ: what makes this esb special?
Mark: It's an ESB that has been in production deployment for 3 years. Although it may not have all of the features that we associate with ESBs of today, there are very few ESB implementations that can point at such long-term deployments. Furthermore, this system has been the backbone of a mission-critical insurance broker, so it has high reliability and management characteristics: again something that would be hard for some other implementations to point at. I think it's fair to say that we traded off functionality and standards compliance for pedigree. So when you look at the capabilities of the new JBossESB, it would be unfair to try and do a tick-box bake-off between its capabilities and those of today's ESBs. You need to take into account the important fact that this implementation has been running 24/7 for 3 years. Plus, we have all of the JEMS components with which to enrich it over time anyway.
InfoQ: what are you excited about with this development?
Mark: I'm excited because it's an ESB core with pedigree that very few of the other "players" in this space can compare with. It's also got an architecture that is close to what we've been working on. It's not an exact match, but it's close enough that we can modify it as the product evolves. It also means that we have a solid product from the initial release - again not something many of our competitors can match up to.
InfoQ: what are the problems with the ESB marketplace?
Mark: Too many offerings! Plus not enough standards. JBI is only one piece in the puzzle. The way we see ESB in JBoss is as an SOA infrastructure. With that in mind, an infrastructure shouldn't be language specific (Java's great, but there are other languages out there that people want to develop services against) and it should be flexible: SOA doesn't mean just JMS, for example. Neither does it mean just Web Services. I'd like to see more standards at the various levels within ESB/SOA infrastructure. For example, contract definition languages (WSDL and WS-Policy are OK as far as they go for Web Services, but they're not sufficient); service composition rules, etc. Currently people see JBI as a tick-box on their ESB and think that they've got portability and interoperability with other ESBs: that's not the case, but I'd like us to move towards that nirvana.
InfoQ: why go open source?
Mark: Commoditise the infrastructure. For the same reason that I believe Web Services have benefited from open source implementations and, obviously, the J2EE Application Server space, the best route to commoditization is through open source.
InfoQ: If open source, why not servicemix?
We looked at it and there may be components within it that we'd like to use as our ESB evolves. At the moment it's too early to say for sure though. Plus the pedigree factor played very heavily in our decision to go with Rosetta.
InfoQ: why not Celtix?
Mark: Eric Newcomer's a close friend and we've been talking around Celtix since I was at Arjuna Technologies. And we're still talking, so I think cooperation of one sort or another will happen here. Watch this space!
InfoQ: why not synapse?
Mark: Same answer as ServiceMix.
Mark: To be honest, I'd like to see more cross-implementation cooperation. As I said at a panel session at JavaOne, I think it'll be years (if ever) before a single ESB implementation takes over the world. We all need to co-exist and SOA is all about leveraging existing infrastructural investments. An ESB that becomes part of the legacy problem isn't a good implementation IMO. One of the things I'd like us (JBoss) to do in this space is spearhead a more cooperative approach to other ESB implementations. The fact is that multiple implementation deployments are going to be a fact of life (at least for a while), so we should work with each other.
Getting Started with Stratos - an Open Source Cloud Platform
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
agility@scale eKit: 10 Principles, Scaling Model, Metrics, Collaboration
Complimentary Gartner (Hype Cycle for Cloud Security Report)
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.
Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.
Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?
No comments
Watch Thread Reply