OSGi - "Seduced by technology in search of a problem" :) ?

I was listening to a very interesting talk at QCon by Rod Johnson of SpringSource. The talk was titled "Things I Wish I'd known" and was about lessons he learned as an entrepreneur, which was very interesting!

Around 37:00 into the talk, he had a slide "Some things we got wrong at SpringSource" and it contained bullets about the over investment in OSGi for 2 years, which I quote below:

 - Seduced by technology in search of a problem
 - Clever technology but didn't solve most pressing customer problems

"Classic example of falling in love with a technology without considering the business implications.

We significantly over invested in OSGi and our dm-server technology for a couple of years. It wasn't a bad technology. Unfortunately, it simply solved a set of problems that a very small number of customers had., and yeah, we should have spent more time listening to the pressing problems our potential customers actually had.

That ultimately was something that we worked around, but we spent millions of dollars that we could have spent elsewhere."

Its interesting to note that about an year back, Ross Mason of MuleSource blogged about using OSGi in the Mule ESB in the post OSGi? No Thanks and said:

OSGi is a great specification for middleware vendors, but a terrible specification for the end user. This is because OSGi was never build for application developer consumption

Digital Content and Service Provider Jesta Digital Migrates to the UltraESB

Zero-Copy proxying and Non-Blocking IO allows three node cluster to process ~80 million messages a day at just 5% CPU utilization and 300MB heap memory usage

AdroitLogic, developer of the high performance Open Source Enterprise Service Bus (ESB) UltraESB, today announced that Jesta Digital, a leading global provider of next generation entertainment content and services for the digital consumer, successfully migrated their ESB clusters to the UltraESB. Jesta Digital is behind Bitbop wireless subscription service to deliver on-demand commercial-free television and films to personal computers, tablets and smartphones, and home to a number of well-known and established brands including Jamba and Jamster, which deliver branded content, music, games and apps to millions of mobile consumers.

"In a very demanding and rapidly changing market it is of utmost importance to be able to quickly adjust the technical platform to support product innovation and change. The UltraESB was able to demonstrate to the Jesta Digital Technology team in Berlin that its simplicity, testability, extensibility and performance is made for a matching foundation" said Eric Hubert, the Executive Director of Strategy and Architecture at Jesta Digital.

On the main ESB cluster, Jesta Digital processes around 80 million messages a day with a peak 3,000 TPS across three nodes. The average CPU utilization has been just 5% with the heap memory usage at 300MB with very low GC overheads due to the efficient use of a RAM disk coupled with Zero-Copy and Non-Blocking IO. Prior to the migration, Jesta Digital customized the ESB Performance Benchmark (http://esbperformance.org) to compare the performance of the UltraESB for both SOAP and Hessian messages over HTTP/S for a sample scenario. Benchmark results similar to those published recently on the ESB Performance site were independently verified by Jesta Digital during this exercise. Furthermore the UltraESB showed extreme stability during stress tests executed over multiple days.

"We have a top notch technical team at Jesta Digital in Berlin and it was a great pleasure to work with subject-matter experts who combined first-hand knowledge, passionate work on their product and dedication to tackle the customer's challenges" said Eric.

During the migration process, AdroitLogic also worked with the Jesta Digital team to include some key features for even better enterprise deployment support. Among these is the ability to switch a live configuration with zero down time while messages are being processed. Previously servers had to be gracefully shutdown for updates, resulting in an unequal distribution of traffic across the nodes after a configuration switch, leading to connection related issues. In addition, AdroitLogic developed a feature to easily manage and monitor services and endpoints via automatic registration against a Zabbix monitoring server, using predefined or customized templates via JMX.

The UltraESB is clustered using the Apache ZooKeeper framework, and thus a single node, or the whole cluster can be managed from any of the nodes via a remote web based console, command line interface or via JMX/jconsole.

AdroitLogic was founded in January 2010 by Asankha Perera, the former lead contributor of the Apache Synapse ESB and the original architect of the WSO2 ESB. In September 2011, Ruwan Linton who initially succeeded Asankha at WSO2 as its next ESB architect, also joined AdroitLogic as its Director of Engineering. AdroitLogic published a new round of ESB benchmark results in October across 8 open source ESBs, which showed a very clear lead in performance against its competitors. In addition to performance, the UltraESB is also one of the simplest ESB's to use effectively, with support for IDE based step-through debugging, Unit testing and a light weight deployment with over 70 samples. AdroitLogic is also one of the very few - if not the only - ESB vendors that publishes code coverage statistics along with continuous builds and code quality reports publicly.

"It was a great pleasure to work with subject-matter experts who combined first-hand knowledge, passionate work on their product and dedication to tackle the customer's challenges"

Read the full Press Release and Download the Case Study on Migration to the Free and Open Source UltraESB

Past, Present and Future of ...: UltraESB Documenation

AdroitLogic has released the first phase of the official documentation for the UltraESB. This documentation is a complete reference of the...
Does your ESB vendor charge you for access to Premium Content? Well, all UltraESB documentation, including our premium Production Support guides are free!

Drag-and-Drop Integration with Graphical Models and Studios - how effective are they?

Recently I was asked by a prospective user about the graphical tooling support of the UltraESB, and the answer I prepared is summarized below in this blog post.

• Updates to a graphical configuration is sometimes difficult
• Graphical models are not easily unit testable
• How do you debug graphical models?
• Graphical models cannot be version controlled easily, or backed-up and restored for production system changes quickly
• Graphical models does not allow easily inserted and usable comments
• Graphical models are vendor specific “language”s you need to learn from the start
• Text based configurations support – visual code review and auditing of changes 
• Real world management of graphical configurations are more difficult
• Graphical tools are sometimes limited on extensibility
• Vendors ship some IDE based “Studio” which may not be user friendly to some

We will consider the effectiveness of the graphical "Studios" and vendor customized "IDEs" and compare how effective they are for real world production system development, change management and auditing, code review and unit testing etc among other topics.

Now if you'd want to know what I am talking about, do a Google search for "ESB (Studio OR IDE)" and look at the results of the Image search.. You will find plenty from some ESB vendors.

In-contrast, an UltraESB configuration is held in files

In contrast, The UltraESB configurations are held in one or more configuration files. These files are human readable and understandable, and are Spring framework configuration files already familiar to many developers. Typically a configuration is split into two files namely ultra-root.xml to define the more
static aspects such as transports, JMX configuration etc, while the ultra-dynamic.xml defines the more dynamic aspects such as services, mediation sequences and endpoints of the business scenario. Where required the dynamic components can be split into any number of sub configurations.

Changes to the dynamic aspects does not require a server re-start, and can be applied to live production servers without disrupting existing or in-flight messages, and the UltraESB guarantees that a message flow will only use the configuration version available at the start of its processing. This makes the
configuration updates both safe and efficient, and is much more than whats typically offered as 'hot-deployment' by some products.

Holding the configuration in a concise XML document makes it easy to quickly:
– Understand the flow
– Take a backups
– Track changes across versions
– Add new services, change/remove/disable or co

Yet, still the UltraESB allows auto-completion and step-through debugging with your preferred IDE - See this 5 minute screen cast!


Comparison with Graphical Drag-and-Drop tools

The graphical tools will present themselves as “easy to use for any beginner” - which I do not contradict. However is its usefulness also limited when you are not a beginner anymore?

When you move into real world usage you will quickly understand that:

1. Updates to a configuration (e.g. disabling an address from a load balance endpoint in a production system) will require a developer to open up a heavy weight IDE Studio, open up the latest version of the project, make the necessary change, build a new deployable binary artifact and then deploy this to a production server.
• When this needs to be done quickly for emergency changes etc, it would be difficult for a system administrator, or just "any" developer to do – the availability of a configured developer environment would be needed to effectively use the graphical Studios.
• Furthermore, a binary deployable artifact generated by a developer would be difficult to verify for correctness. It will also depend on the developers local user settings and local properties files etc. used at the build time, and may not be the ideal artifact with the correct settings for quick production deployments.
2. Graphical models are not easily unit testable. Any UltraESB configuration can be easily unit tested with popular frameworks such as JUnit. Most of the samples we ship are automatically unit tested for each continuous build.
• Check our unit tests here, or take a look at one single sample test here
• As an exercise: Ask any other ESB vendor how they suggest that you perform unit testing, and automated end-to-end configuration testing. Try out their suggestions by yourself, and verify how effectively they will work in your real world use
3. Graphical models cannot be version controlled easily / Cannot backup and revert production system changes quickly. They will either use binary artifacts, or generate loads of meta XML which cannot be humanly understood, backed up or safely managed via a source control system for historical difference checking.
• As all UltraESB configurations are simple and human readable and understandable XML files, changes can be checked into any version control system such as CVS, SVN, Mercurial, GIT etc, and tagged after development for QA testing, staging and production deployments. This allows one to quickly undo changes to revert back to a previous configuration level within a matter of seconds.
• Here is a sample diff for you to verify which shows some changes over time on a UltraESB configuration. Our large enterprise users integrate the ESB configuration into version control systems for better management, visibility/openness and control of changes and auditing.
• The UltraESB conf/ directory is typically checked into a version control system. When developers make changes they can commit locally (i.e. with Mercurial etc) and when ready push changes for QA / integration testing. Once changes are accepted for deployment, they would then be tagged by QA. The operations teams would map the source repository to the conf/ directory of the live servers, and to deploy changes, they would pull changes from the source repository. Depending on the change, a simple UTerm “cau – Configuration Add or Update” command or a graceful restart (e.g. if third party JARs etc are required for a new change) can then be initiated. Before updates, the configuration can be easily backed up, and if something goes wrong, the configuration can just as be easily reverted to the previous tag or restored configuration file which was backed up before.
4. Graphical models does not allow easily inserted and usable comments. Some comments on graphical models maybe hidden as meta information in the huge models. They are not seen at all, or are rarely seen on a production configuration etc. Some models may not allow you to save user specified comments, or loose them during editing even when inserted manually. See how you can comment the UltraESB configurations here
5. Graphical models are a vendor specific “language”. Yes, your team still needs to learn a new language, refer to its documentation from how to write an “if” condition, and understand which component can be added under or connected to which other. The UltraESB is configured with Java code fragments, classes, or compiled class libraries. In addition, you may use any JSR 223 scripting language such as Javascript, Groovy, Ruby etc which you already know.
• As the UltraESB configuration is in Java, you can use concepts you already know such as:
• Exception handling with a try-catch-finally
• Easily refer to all possibilities of the API using Javadocs
• Easily calling external libraries from within the in-line code you are writing etc. (Compare to calling an external Java library from one of the graphical models)
6. Real world management of graphical configurations are more difficult. Imagine having to make a change to an endpoint URL across hundreds of services. With a graphical model, one would need to load each service and make the necessary changes, save and rebuild deployable artifacts for re-deployment. With a text based configuration you can easily use find-and-replace, sed, grep, find etc to quickly find certain values, or make changes across multiple services easily.
7. Text based configurations support – visual code review and auditing of changes
8. Graphical tools are sometimes limited on extensibility. You cannot easily extend the components available, or develop custom components. Even if you could, as an end user you would be writing an ESB vendors specific UI logic on your developers' time to build such extensions, which may break with new vendor releases etc. If you just concentrate on your business logic, you could write any extension as a Java library etc, and reuse the method from within the UltraESB from multiple locations.
• Furthermore, some tools may not allow you flexibility. As an example, consider you are getting a message header “XXX-NNN-YYY” and you want conditionally perform a routing just looking at the “NNN” part. If your graphical editor provides a “if-then-else” construct, most definitely if will allow you to check if this complete header is equal to something or not. (See example screenshot). However, your mind will tell you that you just need to perform a substring(4,7) on the header and do the comparison. This is easily possible with the UltraESB configuration, where-as fixed UI “components” of most vendors would not allow you to go deeper than the beginner level use.
9. Vendors ship some IDE based “Studio” which may not be user friendly to some. Most vendor studios are based on Eclipse or other such frameworks, and may not be easy for use for IDEA, NetBeans and other IDE users. The UltraESB allows its users to use any of their preferred IDEs.
10. How do you debug graphical models? Usually, studios hide the actual execution code with very high level constructs, and hence users ultimately ends up using the log files for debugging which is sad. You cannot easily set a breakpoint at one of the nice graphical boxes, and evaluate message properties at the time a message reaches it. You cannot then step-through debug the configuration from there on.
• With the UltraESB, you are at the actual execution code level. You can set real breakpoints, evaluate variables, and step-through debug as you've always known with your favorite IDE. Ofcourse, you can start the ~35 MB UltraESB within the IDE in its full glory, so you do not end-up having to remotely debug a monster server running with elsewhere.

ESB performance testing - Round 5 Results for 8 Open Source ESBs

AdroitLogic Private Ltd. announced today the results of the fifth round of ESB Performance testing. This round compares the WSO2 ESB, Mule ESB CE, Fuse ESB, Apache ServiceMix, Talend ESB, Petals ESB, JBoss ESB and the UltraESB. The ESB performance benchmark has been in use since June 2007 by vendors such as WSO2, AdoritLogic, Mulesoft and BEA to compare ESBs across different loads and message sizes for six common use cases. This round also publishes an EC2 AMI to easily reproduce the results by average users, and also publishes all source configuration for the 8 different ESBs in a public BitBucket repository

What's significant about this test suite is that it has now been accepted as a de-facto ESB performance test suite by vendors such as WSO2, BEA and Mulesoft in the past, who have reported results against their implementations publicly. This has also been used extensively by end users for ESB comparison, and load testing of configurations before production deployments.

Although 8 open source ESBs were considered, 4 of these failed without being able to complete the load test. One ESB had a 3-4% error rate, while three completed successfully. The test includes two variants of the free and open source UltraESB. The enhanced version is supercharged with the power of VTD XML which allows the UltraESB to perform XPath evaluation on XML payloads without XML parsing. This works nicely with the RAM Disk based file cache used by the UltraESB to provide both Zero-Copy and Java Non-Blocking IO for the extreme levels of performance.


Full information available at http://esbperformance.org

Former WSO2 ESB and Apache Synapse ESB Architect Ruwan Linton Joins AdroitLogic

It gives me great pleasure to announce that Ruwan Linton has joined AdroitLogic!

Ruwan was the former architect and product manager of the WSO2 ESB, taking over the position when I left WSO2 in October 2008. We've worked in the past together for over 2 years and contributed over 80% of the Apache Synapse ESB which is also the core of the WSO2 ESB.

Ruwan is a brilliant architect, and a good friend. We both understand each other perfectly well, and thus he will be a great addition to AdroitLogic as its new Director of Engineering!

Here is the full press release: Former WSO2 ESB and Apache Synapse ESB Architect Ruwan Linton Joins AdroitLogic

ESB Performance Testing.. Getting ready for the next round

Its been sometime since we've compared the performance of free and open source ESBs.. and now its time for the next round..

Amazon EC2 AMI to be published!
At the end of this round, we will publish an Amazon EC2 machine image (AMI) with the selected ESBs so that any end-user can simply fire up an instance of this image, and re-run the performance suite to compare the ESBs of his choice!

This will also make it easier to extend the performance test to include any custom test cases of the user etc, before selecting an ESB for use. But most of all, it will allow a true apples-to-apples comparison of the ESBs of choice, without any vendor bias, as each ESB could be tested on the same EC2 instance, and only allowed to talk to itself on the localhost - preventing a requirement for stringent network isolation.

In the past different vendors used the performance benchmark on different hardware configurations, and also it was not easy for a newbie to re-run the test suite on his own without investing some time to learn things and setup the various ESBs. However, the soon to be published EC2 AMI will contain everything required to fire-up the different ESB's of choice - preventing anyone from having to spend hours to learn and set-up the different ESBs for comparison. A vendor or another end user can also modify the configurations of the ESBs to better tune them, and republish the new image again, making the process simpler and easier for everyone!

The free and open source ESB's evaluated in this round include:

• UltraESB v1.5.1
• WSO2 ESB v4.0.0
• Mule CE v3.1.2
• ServiceMix v4.3.0

It has not been easy to set-up all these different ESB's, and we've found that its pretty difficult to get some of the ESB's to execute all test scenarios.. More on this will be published soon as we try to overcome these difficulties.. so stay tuned!!

If you would like any other ESB to be included into this round, do let us know, and share a compatible configuration.

Visit the ESB Performance site for more details..