Enterprise Service Bus (ESB) Magic

What drives talent out?

2013-02-23T10:52:00.000-08:00

A few days back I saw the famous presentation from Netflix about its culture, and three interesting slides from it was about what drives talent out of a company.

Today I came across a poster created by හිච්චි කොලුවා which shows another aspect from a more Sri Lankan point of view, and it says its the 'තිත්ත ඇත්ත' .. interesting points to think about!

PS: If you aim the moon, believe that you WILL get there. If a planes' limit is the clouds.. get onto a rocket.. do not deviate from achieving your goal!

How to stop biting, when you cant chew more..

2012-11-05T23:46:00.001-08:00

This is a follow up to my earlier post 'Does Tomcat bite more than it can chew?' and illustrates a pure Java program that utilizes Java NIO to stop accepting new messages when one is not able to handle the load, without any dependence on the TCP backlog etc.

Program Implementation

We open a selector, and invoke the startListening() method, that opens a ServerSocketChannel and then binds it to port 8280. The channel is configured as non-blocking, and finally we register our interest in OP_ACCEPT to handle incoming connections.

    private void startListening() throws IOException {
        server = ServerSocketChannel.open();
        server.socket().bind(new InetSocketAddress(8280), 0);
        server.configureBlocking(false);
        server.register(selector, SelectionKey.OP_ACCEPT);
        System.out.println("\nI am ready to listen for new messages now..");
    }

If you telnet to the port via a command line after the server starts up, you would see a message "Hi there! type a word". The server accepts the incoming connection as a non-blocking connection, and registers OP_READ to read the content typed in.

To illustrate how the server can prevent another client from connecting to it while it serves the currently connected client, it prints "I accepted this one.. but not any more now" on its console, cancels the SelectionKey and closes the channel.

A new telnet session will see the "Connection refused" error as expected.

Next, I would type a small word into the first telnet session, and the server would print it in its console, and close the connection.

At the same time, it prints the message "I am ready to listen for new messages now.." on its console, and invokes the above startListening() method again - making it ready to listen and accept a new client.

We re-try the connection from the same command prompt that received the 'Connection refused' earlier, and as expected are greeted with the welcome message again.

What did we learn?

A low level NIO server can stop accepting new connections, if it can determine that its not able to serve new clients. Once it stops accepting connections this way, any client connection attempt will see a 'Connection Refused' error. This may not be the case if our server was implemented differently (See my last article and its example and how Tomcat behaves under load).

Complete source code

import java.io.IOException;
import java.net.InetSocketAddress;
import java.nio.ByteBuffer;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.ServerSocketChannel;
import java.nio.channels.SocketChannel;
import java.util.Iterator;

public class TestAccept2 {

    private ServerSocketChannel server = null;
    private Selector selector = null;

    public static void main(String[] args) throws Exception {
        new TestAccept2().run();
    }

    private void run() throws Exception {
        selector = Selector.open();
        startListening();

        while (true) {
            selector.select();

            for (Iterator i = selector.selectedKeys().iterator(); i.hasNext(); ) {
                SelectionKey key = i.next();
                i.remove();
                if (key.isAcceptable()) {
                    SocketChannel client = server.accept();
                    client.configureBlocking(false);
                    client.socket().setTcpNoDelay(true);
                    client.register(selector, SelectionKey.OP_READ);

                    System.out.println("I accepted this one.. but not any more now");
                    key.cancel();
                    key.channel().close();
                    sayHello(client);

                } else if (key.isReadable()) {
                    readDataFromSocket(key);
                }
            }
        }
    }

    private void startListening() throws IOException {
        server = ServerSocketChannel.open();
        server.socket().bind(new InetSocketAddress(8280), 0);
        server.configureBlocking(false);
        server.register(selector, SelectionKey.OP_ACCEPT);
        System.out.println("\nI am ready to listen for new messages now..");
    }

    private void sayHello(SocketChannel channel) throws Exception {
        channel.write(ByteBuffer.wrap("Hi there! type a word\r\n".getBytes()));
    }

    private void readDataFromSocket(SelectionKey key) throws Exception {
        SocketChannel socketChannel = (SocketChannel) key.channel();
        ByteBuffer buffer = ByteBuffer.allocate(32);
        if (socketChannel.read(buffer) > 0) {
            buffer.flip();
            byte[] bytearr = new byte[buffer.remaining()];
            buffer.get(bytearr);
            System.out.print(new String(bytearr));
            socketChannel.close();

            startListening();
        }
    }

}

Does Tomcat bite more than it can chew?

2012-10-31T21:55:00.002-07:00

This is an interesting blog post for me, since its about the root cause for an issue we saw with Tomcat back in May 2011, which remained unresolved. Under high concurrency and load, Tomcat would reset (i.e. TCP level RST) client connections, without refusing to accept them - as one would expect. I posted this again to the Tomcat user list a few days back, but then wanted to find out the root cause for myself, since it would surely come up again in the future.

Background

This issue initially became evident when we ran high concurrency load tests at a customer location in Europe, where the customer had back-end services deployed on multiple Tomcat instances, and wanted to use the UltraESB for routing messages with load balancing and fail-over. For the ESB Performance Benchmark, we had been using an EchoService written over the Apache HttpComponents/Core NIO library that scaled extremely well and behaved well at the TCP level, even under load. However, at the client site, they wanted the test run against real services deployed on Tomcat - to analyse a more realistic scenario. We used a Java based clone of ApacheBench called the 'Java Bench' which is also a part of the Apache HttpComponents project, to generate load. The client would go up-to concurrency levels of 2560, pushing as many messages as possible through the ESB, to back end services deployed over Tomcat.

Under high load, the ESB would start to see errors while talking to Tomcat, and the cause would be IO errors such as "Connection reset by peer". Now the problem to the ESB is that it had already started to send out an HTTP request / payload over an accepted TCP connection, and thus it does not know if it can fail-over safely by default to another node, since the backend service might have performed some processing over the request it may have already received. Of-course, the ESB could be configured to retry on such errors as well, but our default behaviour was to fail-over only on the safer connection refused or connect timeout errors (i.e. a connection could not be established within the allocated time) - which ensures correct operation, even for non-idempotent services.

Recent Observations

We recently experienced the same issue with Tomcat when a customer wanted to perform a load test scenario where a back-end service would block for 1-5 seconds randomly, to simulate realistic behaviour. Here, again we saw that Tomcat was resetting accepted TCP connections, and we were able to capture this with Wireshark as follows, using JavaBench directly against a Tomcat based servlet

As can be seen in the trace, the client initiated a TCP connection with the source port 9386, and Tomcat running on port 9000 accepted the connection - note “1”. The client kept sending packets of a 100K request, and Tomcat kept acknowledging them. The last such case is annotated with note “2”. Note that the request payload was not complete at this time from the client – note “3”. Suddenly, Tomcat resets the connection – note “4”

Understanding the root cause

After failing to locate any code in the Tomcat source code that resets established connections, I wanted to simulate the behaviour with a very simple Java program. Luckily the problem was easy to reproduce with a simple program as follows:

import java.net.ServerSocket;
import java.net.Socket;

public class TestAccept1 {

    public static void main(String[] args) throws Exception {
        ServerSocket serverSocket = new ServerSocket(8280, 0);
        Socket socket = serverSocket.accept();
        Thread.sleep(3000000); // do nothing
    }
}

We just open a server socket on port 8280, with a backlog of 0 and start listening for connections. Since the backlog is 0, one could assume that only one client connection would be allowed - BUT, I could open more than that via telnet as follows, and even send some data afterwards by typing it in and pressing the enter key.

telnet localhost 8280
hello world

A netstat command now confirms that more than one connection is opene:

netstat -na | grep 8280
tcp        0      0 127.0.0.1:34629         127.0.0.1:8280          ESTABLISHED
tcp        0      0 127.0.0.1:34630         127.0.0.1:8280          ESTABLISHED
tcp6       0      0 :::8280                 :::*                    LISTEN
tcp6      13      0 127.0.0.1:8280          127.0.0.1:34630         ESTABLISHED
tcp6      13      0 127.0.0.1:8280          127.0.0.1:34629         ESTABLISHED

However, the Java program has only accepted ONE socket, although at the OS level, two would appear. It seems like the OS also allows more than two connections to be opened, even when the backlog is specified as 0. On Ubuntu 12.04 x64, the netstat command would not show me the actual listen queue length - but I believe it was not 0. However, before and after this test, I did not see a difference in the reported statistics for "listen queue" overflow, which I could see with the "netstat -sp tcp | fgrep listen" command

Next I used the JavaBench from the SOA ToolBox and issued a small payload at concurrency 1024, with a single iteration against the same port 8280

As expected, all requests failed, but my Wireshark trace on port 8280 did not detect any connection resets. Pushing the concurrency to 2560 and the iterations to 10 started to show tcp level RSTs - which were similar to those seen on Tomcat, though not exactly the same.

Can Tomcat do better?

Yes, Possibly .. What an end user would expect from Tomcat is that it refuses to accept new connections when under load, and not to accept connections and then reset them halfway through. But one would ask if that is achievable? Especially considering the behaviour seen with the simple Java example we discussed.

Well, the solution could be to perform better handling of the low level HTTP connections and the sockets, and this is already done by the free and open source high performance Enterprise Service Bus UltraESB, which utilizes the excellent Apache HttpComponents project underneath.

How does the UltraESB behave

One could easily test this by using the 'stopNewConnectionsAt' property of our NIO listener. If you set it to 2, you wont be able to even open a Telnet session to the socket beyond 2.

The first would work, the second too

But the third would see a "Connection refused"

And the UltraESB would report the following on its logs:

INFO HttpNIOListener HTTP Listener http-8280 paused
WARN HttpNIOListener$EventLogger Enter maintenance mode as open connections reached : 2

Although it refuses to accept new connections, already accepted connections executes without any hindrance to completion. Thus a hardware level load balancer in front of an UltraESB cluster can safely load balance if an UltraESB node is loaded beyond its configured limits, without having to deal with any connection resets. Once a connection slot becomes free, the UltraESB will start accepting new connections as applicable.

Analysing a corresponding TCP dump

To analyse the corresponding behaviour, we wrote a simple Echo proxy service on the UltraESB, that also slept for 1 to 5 seconds before it replied, and tested this with the same JavaBench under 2560 concurrent users, each trying to push 10 messages in iteration.

Out of the 25600 requests, 7 completed successfully, while 25593 failed, as expected. We also saw many tcp level RSTs on the Wireshark dump - which must have been issued by the underlying operating system.

However, what's interesting to note is the difference - the RSTs occur immediately on receiving the SYN packet from the client - and are not established HTTP or TCP connections, but elegant "Connection Refused" errors - which would be what the client can expect. Thus the client can safely fail-over to another node without any doubt, overhead or delay.

Appendix : Supporting high concurrency in general

During testing we also saw that the Linux OS could detect the opening of many concurrent connections at the same time as a SYN flood attack, and then start using SYN cookies. You would see messages such as
-->

Possible SYN flooding on port 9000. Sending cookies

displayed on the output of a "sudo dmesg", if this happens. Hence, for a real load, it would be better to disable SYN cookies by turning it off as follows as the root user
-->

# echo 0 > /proc/sys/net/ipv4/tcp_syncookies

To make the change persist over reboots, add the following line to your /etc/sysctl.conf
-->

net.ipv4.tcp_syncookies = 0

To allow the Linux OS to accept more connections, its also recommended that the 'net.core.somaxconn' be increased - as it usually defaults to 128 or so. This could be performed by the root user as follows,
-->

# echo 1024 > /proc/sys/net/core/somaxconn

To persist the change, append the following to the /etc/sysctl.conf
-->

net.core.somaxconn = 1024

Kudos!

The UltraESB could not have behaved gracefully without the support of the underlying Apache HttpComponents library, and the help and support received from that project community, especially by Oleg Kalnichevski - whose code and help has always fascinated me!

2012-09-07T11:55:00.000-07:00

First they ignore you, then they try to ridicule you, then they fight you, then you win

2012-08-23T23:32:00.002-07:00

"First they ignore you, then they try to ridicule you, then they fight you, then you win" - is thought to have been said by Gandhi.

AdroitLogic Announces API Management Solution Based On Its High Performance ESB

2012-08-21T04:05:00.002-07:00

We've just announced the APIDirector! an API and Services management solution based on our high performance Enterprise Service Bus UltraESB.

One of the key differences of the APIDirector is that it will offer both API and Services management features for enterprises, including support for AS2 and other legacy/traditional B2B and service protocols.

We've announced results of the 6th Round of ESB Performance Benchmarking earlier in August, although I've missed blogging about it previously, as my father was ill during those few days. The benchmark results showed the extreme performance as well as the stability of the UltraESB, which are both key elements of any API management solution.

Since an API management solution will be the entry point for your trading partners, customers and users accessing your exposed APIs - it MUST be capable of withstanding extreme load, as well as deliberate security attacks, without crashing by itself. The Round 6 results and the related information shows how some of the ESBs fail to withstand even legitimate and relatively small amounts of loads, when compared to an external attack.

The APIDirector performs functions such as credential management, service logging, auditing and performance management support, with an easy to use graphical administration interface that also provides analytical features. We also ship the AS2Gateway as an optional module of the APIDirector, and this allows users to deploy a custom AS2 trading gateway - similar to the AS2Gateway we have hosted publicly.

Next week we will be deploying the AS2Director at one of our beta customer sites in the US, and it will initially deal with defining S/FTP file exchanges and SOAP based services, as well as AS2 based B2B exchanges. The APIDirector will be generally available to the public during the first quarter of 2013, although we will be happy to work with customers with beta releases prior to the general availability. Please contact us to learn more about the APIDirector, and how you could participate in the beta!

Original News Release: http://www.prweb.com/releases/prweb9820781.htm

Electronic Invoicing Announced on the AS2Gateway

2012-07-31T04:29:00.000-07:00

We've just announced support for electronic invoicing on the cloud based Free B2B Trading Gateway AS2Gateway! This allows users to invoice trading partners via EDIFACT INVOIC messages over AS2, using a simple and intuitive web interface

Recurrent invoicing is simplified as any invoice can be saved as a template and re-used multiple times. The AS2Gateway converts all the invoice details into an EDIFACT D93A INVOIC message right now, and soon will support the other versions, as well as X12 based messages such as the 810.

In the near future, the platform will add support for parsing and generation of more message types, which will allow users to easily generate an invoice based on a purchase order received; or an advanced shipping notification (ASN) etc.

The AS2Gateway offers a free tier to support most SMEs that are required to electronically invoice trading partners for payment. For larger users, a premium tier is available with advanced options (to be announced shortly!), and for retailers or large corporations, the AS2Gateway is available for on-premise private deployment.

UltraESB Automates AS2/EDI Based B2B Trading for SKB Europe

2012-07-17T03:30:00.002-07:00

We've just published a new case study on how SKB Europe, a leader in high-quality aluminium and plastic cases and boxes, has deployed the UltraESB as an AS2/EDI integration platform for Business-to-Business (B2B) integration.

The system initially integrates the ERP system of SKB Europe with one of its key trading partners Amazon, via EDIFACT based EDI documents exchanged over the AS2 protocol.

Read the news release and Case study from here
http://www.prweb.com/releases/2012/7/prweb9706746.htm

ESB Performance Benchmarking Round 6 is coming..

2012-06-28T09:35:00.000-07:00

AdroitLogic has just announced the Sixth round of ESB Performance Benchmarking today!

Round 5 introduced a public Amazon EC2 AMI image of all the ESB's that were included into the benchmark, and the next round has moved further by requesting vendors and/or contributors for submission of better optimized configurations for the different ESBs to be tested.

Stability and Performance are both important to any ESB, and the last round saw half of the selected ESBs not being able to complete the benchmark successfully. Each ESB has since releases new versions, and we look forward to testing each one successfully!

For more information, visit http://esbperformance.org and email info@adroitlogic.com if you are interested to participate closely with us during this round!

UltraESB Connects Coupon Publishers and Major Retailers in Europe in B2B Solution for HighCo Data Spain

2012-06-25T05:41:00.002-07:00

Today we are happy to announce that Storelabs, a European startup specialized in FMCG/Retail marketing and operations, has deployed an AS2/EDI - FTP/XML Gateway for HighCo Data Spain. The Cloud hosted gateway 'PromoHub' initially integrates the retailer Carrefour Spain, with multiple coupon publishers utilizing the HighCo Data coupon clearing services.

Read the full Press Release and the Case Study

We've just launched our Free EDI/AS2 B2B Gateway - AS2Gateway.ORG

2012-06-20T05:50:00.000-07:00

Since its launch in January 2010, the UltraESB has the only free and open source ESB that natively supported the widely used B2B trading protocol AS2 (Applicability Statement 2). AS2 is used extensively in the US, Europe and Asia for B2B integration especially in the Retail and Manufacturing industries, and the UltraESB has been used by many organizations to integrate EDI/AS2 systems with S/FTP, Web Services and XML style systems.

The UltraESB is now used to integrate with some of the largest retailers in Europe, and the US by multiple organizations and it was natural for us to see the potential in offering a Cloud hosted EDI/AS2 solution as a Service (SaaS).

The AS2Gateway is powered by our flagship product UltraESB, and offers free EDI/AS2 connectivity for SME's and certainly disrupts the traditional market place in both the features offered and the cost savings. For example, the free tier allows SMEs to trade electronically with upto 5 trading partners and offers 60 messages per month.

We've also just launched AS2Integration.ORG which is a resource site on AS2/EDI integration, as well as the documentation and user guide for the use of the AS2Gateway.

Utilizing the UltraESB underneath means that the flexibility is virtually limitless, and we will soon expand this service to include Electronic Invoicing, EDI document creation and processing as well!

The AS2Gateway begins its 'beta' testing phase today, and you can utilize all of its features for free until we move into production in a few more months! No credit cards are necessary for sign up - so get your AS2/EDI trading account from the Free AS2Gateway!

Read our Press Release about the launch for more details!

Webinar: UltraESB - The Future of Enterprise Integration

2012-05-20T22:54:00.004-07:00

Register for our free Webinar on using the UltraESB, on Tuesday the 29th of May 2012.

Click Here for more details and to Register!

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

2012-01-03T12:54:00.000-08:00

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

2011-11-28T00:09:00.000-08:00

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

2011-10-17T03:20:00.000-07:00

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?

2011-10-05T06:10:00.000-07:00

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:

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.

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

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.

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
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)

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.
Text based configurations support – visual code review and auditing of changes
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.

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.
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

2011-10-04T09:16:00.000-07:00

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

2011-09-13T03:54:00.000-07:00

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

2011-08-08T02:41:00.000-07:00

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..

AdroitLogic announces v1.5.0 of the UltraESB

2011-07-20T09:06:00.001-07:00

"The latest version brings support for Command Line Interface for management, improved JMX support, and integration with monitoring solutions and a high performance RAM disk based file cache.."

Read the full story at http://adroitlogic.org/about/news.html

To build the best ESB, you have to select the best open source components too!

2011-05-06T02:47:00.000-07:00

If you've ever wondered how we build the worlds best Free and Open Source ESB, in terms of performance, features and ease of use; then read about it all on Thanking great Open Source projects and teams!

To build the best Open Source ESB, we *had* to select; and only depend on; the best Open Source components - and not the old cupboards or the stinking kitchen sinks, that some vendors cannot yet entangle themselves from!

Did I mentioned that our complete distribution is just ~35MB? Compare it to some others who call 135MB upto ~1G ESB's as light. I guess after putting lipstick on the Pig, they now like to call it "light-weight" like a damsel too ;) But sadly, some are still stuck in the days of hub-and-spoke messaging, and some made the whole world around them too SOAPy and slippery too soon as they didn't take enough REST at the right time.

Being the youngest ESB in town, and to Win! - we had no choice but to select the best technologies and open source projects that we would depend on and use.

Introducing true Zero-Copy proxying, with memory mapped files and Non-Blocking IO was killer in performance. Some even tried to copy the keywords without implementing the code, and even without understanding what Zero-Copy was :)

We also introduced the concept of using Java (classes or just fragments) or any JSR 223 scripting language (such as Javascript, Groovy, Ruby) for mediation. Although many vendors falsely claim that their ESB is "configuration" only - the configuration language they use is no different from a programming language. However, someone new must learn that "XML"ish language to "program business logic" - and no one is going to tell him the equivalent of a try {} catch {} finally block that can be reliably used in that context :)

Our approach was to let the user decide the way he is going to mediate, using a language and/or technologies he is already aware of. But unlike some ESBs where you write Java code, then use some script to compile, bundle and deploy - the UltraESB just requires you to write the lines - and the compilation is hidden! You can even debug your mediation from within your favourite IDE - either IDEA, Eclipse or Netbeans.

When we wanted to introduce clustering almost an year back, we looked at Apache ZooKeeper and knew at first sight that it was the right one for us - call it link at first sight ;) !

Selecting a UI framework was the most time consuming.. and we looked at GWT based, and other frameworks, based on the servlet model but did not find the right balance. We wanted to use the best of HTML5/CSS3 and be in control always.

The combination of HTML5/CSS3/JQuery/datatables - connected via JSON using Pure - to a Wink REST application secured by Shiro and implemented via JMX with direct calls to the remote ESB was one of the main introductions in this last release! But it was all worth it! Except for a few issues on the IE browser (which statistically a lot fewer people use now) everything has been smooth. But we will follow up a 1.4.1 release with these fixes for IE too.

UltraESB Code Quality Metrics - updated for v1.4.0

2011-05-05T10:52:00.000-07:00

We've updated the code quality metrics for the free and open source UltraESB v1.4.0 release recently, and our glad to still have a 43.3% code coverage (46.1% of the lines and 36.2% of branches) and 15.5% of code comments (46% documented API)

The total lines of code increased to 33,563 spread over 69 packages and 426 classes, with v1.4.0 which introduced the web based administration console - UConsole, support for clustering, automated round-robin restarts, XACML and even faster XML performance with FastXML

By building each sample as both an end-user executable, and documented sample, as well as a JUnit test case has paid a lot. AFAIK we ship the most number of samples for any ESB with 48 sample configurations with over 100 sample proxy services!

UConsole - the node/cluster management console of the UltraESB

2011-05-03T19:20:00.000-07:00

Sampath has published a detailed article on the architecture of the UConsole with a brief introduction to some of its functions. The UConsole is an ultra light-weight Jetty based web application that uses HTML5/CSS3 to render the pages. All front end pages and scripts thus can be safely cached by a browser, and all pages fetch data over a JSON API exposed by a REST application deployed using Apache Wink.

The UConsole is the graphical management console, to the re-vamped JMX based UltraESB management API using MXBeans. Thus any function that can be monitored or performed via the UConsole, can be performed via JMX too.

One neat aspect of the UConsole is the ability to connect to any node via its JMX URL. So when you connect to a cluster, you can connect to any single node of the cluster. Apache ZooKeeper ensures that you can perform any cluster wide function from any connected node. There is no "administration server", master or slaves, or any single point of failure!

We intend to develop a command line administration interface over the JSON/REST API in future, when it will add value to the product.

AdroitLogic announces v1.4.0 of the UltraESB

2011-05-02T09:58:00.000-07:00

The latest version brings support for clustering using ZooKeeper, and introduces a web based administration console, and support for Caching, XACML and JSON among many other features.

Singapore - May 2, 2011 - AdroitLogic Private Ltd. announced today the release v1.4.0 of its free and open source Enterprise Service Bus, the UltraESB. The UltraESB is released under the OSI approved GNU Affero General Public License; as well as a zero-dollar non-GPL commercial license which allows unlimited and perpetual use free of charge. First released in January 2010, the UltraESB was the first ESB to utilize memory mapped files and zero-copy, coupled with non-blocking IO to provide extreme levels of performance.

Version v1.4.0 released today offers support for clustering and management of cluster nodes through the new Web based administration console based on JMX. Clustering support is built over Apache ZooKeeper, which is used to manage extremely large clusters of Hadoop nodes. Advanced features such as automatic restart of a complete cluster of nodes - with round-robin processing, or management of a service, or endpoint across a cluster have been made trivial operations. The new version also supports caching, and the current release ships support for ehCache. The new release also ships support for high performance XML processing, utilizing FastXML. This allows end users to integrate third party libraries such as VTD XML with the UltraESB for extremely fast XPath processing, without parsing XML payloads. XACML is supported for fine grained authorization using the PicketBox XACML library, and automatic conversion to/from JSON to XML makes processing JSON payloads even simpler.

In addition to supporting many transports and message formats, the UltraESB also offers support to easily develop JSON based data services with just a single line of configuration, and provides full support for the HTTP transport, including true REST support, basic, digest, NTLM and Amazon S3 authentication using pre-emptive authentication or challenge response mechanisms as applicable. The UltraESB also ships a very high performance WS-Security library that allows it to perform WS-Security operations over 3X faster than solutions based on the WSS4J/Rampart libraries used by other ESBs.

JMX support has been thoroughly improved to utilize MXBeans, and allows detailed monitoring and management of a runtime using JMX consoles such as Zabbix. The UltraESB now ships with a native Zabbix agent for even easier monitoring. As the UltraESB integrates with the Spring framework and supports Java as well as JSR 223 scripting languages, integration with third party libraries and extension is simple and powerful.

UltraESB v1.4.0 development builds are available for feedback!

2011-04-06T12:52:00.000-07:00

Checkout the new blog [http://blog.adroitlogic.org] which describes some of the new features of the upcoming v1.4.0 - including clustering, caching, configuration changes at runtime, XACML and many more!