Cicero Rautenbach

Currently, the only standards specification I can find for ESBs is the Java Technology Specification JSR 208 – Java^TM Business Integration (JBI).

This standard is closely tied to Java and J2EE/J2SE. This is perhaps not strange as almost all commercial and open source ESBs are developed using Java. As a matter of fact, I know of only one ESB product not based on Java technology; Microsoft’s BizTalk.

The architecture of JBI is interesting as a baseline for understanding ESB architecture using a common and well described terminology and to help you evaluate ESBs against each other using this common terminology, and not the vendor specific and bias terminology.

JSR 208 calls for 4 types of components making up the ESB:

• A Normalized Message Router (NMR) – ESB vendor supplied component that moves the payload (Normalized Message) between Service Engines and Binding Components.
• Service Engines (SE) – Components that does some useful work (transformations and/or business logic in the enterprise for example a SAP Service Engine allowing you to extract SAP data, an JDBC component allowing you to issue SQL calls to a relational database or an XSLT transformation component. The SEs can come from anywhere as long as they comply to the interface standards.
• Binding Components (BC) – Components that receive and send data outside the ESB for example a File Binding Component that will monitor a directory for changes and pick up new files for processing or an e-mail Binding Components. The BCs can come from anywhere as long as they comply to the interface standards.
• JMX based Administration tools supplied by the ESB vendor to manage the Normalized Message Router, deploy Service Engines and Binding Components and to manage the runtime life cycle (start/stop/end) of all components.

Communication between the Normalized Message Router and the Service Engines/Binding Components are based on a mediated message exchange based on WSDL (Web Services Description Language) and the 4 WSDL-defined Message Exchange Patterns (WEPs).

The Normalized Message Router is responsible for delivering the Normalized Message to the Service Engines (SE) and Binding Components (BC). The structure of the Normalized Message consists of the following parts:

• XML message
• Message context containing meta data about the message and data that may be used by Service Engines and Binding Components (key/value pairs)
• Attachments (normally binary and non-XML)

From what I could determine, only Apache ServiceMix, Bostech’s ChainBuilderESB and the Sun Community effort OpenESB are based on the JSR 208 specification. Many of the commercial ESB vendors participated in setting this standard. A lot of these vendors are now very negative about JBI and various blog entries can be found on their sites badmouthing JBI. This is somewhat understandable as the JBI architecture provides for a pluggable architecture where any component complying with the standard can be plugged in. The only components that the vendor have to supply are the Normalized Message Router and the JMX based administration tools. Any vendor’s components (Service Engines and Binding Components) can be plugged into the Normalized Message Router. This architecture does however have huge potential for providing professional services around the JBI compliant ESB.

My view is that the most likely pricing model for a JBI compliant ESB will be the base package (Starter Edition) consisting of the Normalized Message Router and Admin tools with a few basic (but important) Service Engines and Binding Components included. More complex and valuable Service Engines and Binding Components can be bundled with predefined bundles like the Work Group Edition, Enterprise Edition or SAP Edition. These components can also be priced individually. It is however very likely that customers will use Open Source Service engines and Binding Components. My suspicion is that this is really where vendors are making their money, and not on the base products thus making JSR208 compliancy unattractive for these vendors.

So how would I use the JBI architecture to evaluate a non-JBI ESB?

1) Binding Components – Look at the binding components available, the protocols supported and other software needed to make them work. Are there Binding Components available for the enterprise applications and databases you are using in the enterprise? How easy is it to create your own Binding Component when you need to do that. My list of basic Binding Components includes File System, Scheduler, JDBC, SMTP, FTP, SOAP and JMS.

2) Service Engines – What Service Engines are available and how do you develop and deploy your own. My list of basic Service Engines includes Transformation, Conversion (office documents to XML, ini files to XMLs etc.), JDBC gateways, JMS gateways, SOAP gateways, SMTP Gateways.

3) Look at the Normalized Message. Can binary attachments be handled? What happens if the only message you have is the binary document (no XML)? Are there Service Engines available to surface the contents of the binary attachments, for example extract the contents of an Excel spreadsheet into XML? Can you inspect the message context and do content based routing using it?

4) Distribution – How can Binding Components and Service Engines be distributed in the network to ensure high availability and load sharing. Can the Administration Components manage these distributed components.

5) What does the API look like to add Service Engines or Binding Components?

6) Normalized Message Router – How well does the Normalized Message Router perform?

Here is a list of all the ESBs I could locate. As a base definition for what an ESB is, I am using the definition as found on Wikipedia.

From my own experience of implementing solutions using the earliest ESB prototypes from late 1999 and early 2000 (yes, even before anybody coined the term ESB and before any services standardization) this definition is pretty accurate. It is also open for public discussion and moderation through the WikiPedia process.

The other source I found useful is the book “Enterprise Service Bus” by David Chappell (Publisher: O’Reilly Media, Inc.; 1st edition (June 2004) ISBN-10: 0596006756; ISBN-13: 978-0596006754). Although this book is now almost 4 years old, it is still valid and a useful resource.

WARNING: For some of these products you need a fair bit of imagination to recognize the ESB functionality. That however does not stop the vendors from trumpeting their products as ESBs. Anyways, more power to them – you can fool most people most of the time but not all people al of the time. Sooner or later your customers will find out as the tale goes, that the emperor (no relation to the now infamous club with the same name) has no clothes. Unfortunately this stinks up the world for the true ESB vendors but who am I to judge them.

• osESB -Open Source ESB
• Apache Servicemix – The Apache Software Foundation [Open Source JBI Compiant]
• OpenESB – Open ESB A Sun Open Cummunity effort [JBI Compliant]
• WSO2 ESB – WSO2
• Mule ESB – MuleSource Inc. [Open Source]
• ChainBuilderESB – Bostech Corporation [JBI Compliant]
• BizTalk – Microsoft
• Cape Clear ESB – Cape Clear
• Cordys ESB – Cordys
• Fiorano ESB – Fiorano
• FusionWare Integration Server – FusionWare Corporation
• Iona Artix ESB – Iona
• PolarLake Integration Suite – PolarLake
• Progress Sonic ESB – Progress Software
• JBoss ESB – JBoss (RedHat)
• WebSphere Enterprise Service Bus – IBM
• BEA Aqualogic Service Bus – BEA
• Sun Java Enterprise Service Bus Suite – Sun Microsystems
• webMethods ESB Platform – Software AG
• Oracle SOA Suite – Oracle

(The sequence of the listed products and companies does not have any meaning.)

After some recent projects I did and looking at the performance of other projects I am beginning to form a definite opinion about using an ESB for batch processing.

What do I consider to be batch processing? Gathering up data for a period of time, daily, weekly, monthly, quarterly or yearly and then submitting it all at once for processing by the ESB. I am definitely not talking about running the ESB in the background.

Firstly it must be stated that there is normally no difference in processing data in batch or in real-time, except for the timing and the volume. The ESB does not have any concept of batch or real-time and can not tell the difference. by definition the ESB is loosely coupled to consumers of its services.

I often hear the comment from customers and consultants that the ESB is adding no value. “I can do everything that the ESB does with a simple Java object or Java Servlet. This is often true but also frequently misguided. The idea behind the ESB is not compete with Java technologies for the job. Using an ESB allows you to configure rather than develop the processes. This allows for easier debugging, maintenance and flexibility in deployment architectures. These benefits are seldom apparent up-front but will become apparent over time. Unfortunately this configuration to tie loosely coupled components together in a flow/sequence or orchestration is not as performant as a tightly coupled Java object or Servlet.

This fact have servere implications for batch processing. If each data element takes 50% longer to process through the ESB than through a Java object, this can add hours to the processing of the batch. Handling errors also becomes a bigger challenge when there is a potential for a high volume of errors.

For these reasons I have become of the opinion that that the enterprise is much better served by executing ESB processes in real-time or near real-time

It is pretty clear that the Telecom companies engaged in activities that gave spy agencies access to all telephone conversations that started and/or ended in the USA or that crossed a wire running through the USA. They have done the same for e-mails and web traffic. We have seen the pictures and schematics of these taps, read the reports from whistle blowers and read the investigative reports.

Do I have a problem with it? No way. I could not care who reads or listens to what I do.

So why am I even bothering commenting on this? Because this is not about what happened but how it happened and about that I care.

The law is clear – In order to allow the use of their facilities for spying, the spy needs to produce a court/presidential order to the telecoms company before they can legally allow them to tap into their network. So the solution seems simple. Produce that court/presidential order to a judge and the case is over. I am even willing to go as far as allow the administration to pick their own judge and hold the hearing in the inner sanctum of the White House to make sure that it stays secret. Not that there should be any secrets to be revealed. The chances are slim that the telecoms executives have security clearances so they should not have access to any secret information. They also have no idea what the agencies did with the information they tapped from their networks so no danger there either.

If they can not produce these court orders, they should confess publicly. May I suggest an extra page in the bill I get from them every month, asking my forgiveness and promising never to break the law in this way ever again. Not even God will forgive you your sins without you confessing them first. Only then can congress consider retroactive immunity and amend the law to make sure that these executives never get out of jail again if they do this again.

It does not matter how much you dress their actions up in die American Flag or how much you scare people into submission, these companies are public for profit companies. The have investors and customers around the world and they operate in the regulated American business world because the American people allow them to do so without too much interference. I myself allowed them to bring a phone and data line into my house, not for spying on me but for providing me with a service for which I pay handsomely and in exchange for that I expect them operate within the laws and regulatory framework of the USA.

If they can produce these court orders then they should have done so months ago before wasting all our time and energy over this. I am however getting the impression that there is something we are not being told. I am really getting sick and tired of watching this on the news – grow up and get a life.

I am regularly amazed by the lack of a sense of right and wrong from politicians and business people. Maybe it is just because I am living in the Washington DC area that this is so pronounced.

It should not amaze me – perhaps I am naive. Perhaps it is the sheer scale and absolute lack of shame of the people doing this that is amazing me. I am however worried about the example this sets for young people entering the job market and perhaps this is the biggest threat thatsuch actions hold for society – it is becoming more and more acceptable without anybody speaking out against it – political leaders, community leaders, business leaders, religious leaders or parents.

It is also particularly worrying that the words right and wrong are often replaced by the words legal and illegal to justify actions. The fact that something you are doing is legal, does not unnecessarily make it right. This is particularly relevant at the edges of legality and where strange reasoning is used to justify things. the same can be said with manipulating and omitting facts from an argument. These ethically and morally wrong actions will normally harm a specific group of people. In contrast it is not always clear that it will advance the perpetrator or his/her group.

Lets look at a few examples from the political world:

Suspending Habeas Corpus for political prisoners is legal. The President of the USA proudly ordered it so and until a court of law finds it unlawful, it is lawful. It is however morally and ethically deplorable and wrong.

Waterboarding is legal. The President of the USA declared it so. It is however ethically and morally wrong and should be condemed in the strongest terms.

Declaring that Global Warming is not a scientific fact but still debated in the scientific world is legal. It is however an ethically and morally corrupt thing to do as it is normally done to delay the actions needed to overcome it.

Voting yourself a nice fat salary increase, pension and medical insurance while denying an increase in the minimum wage while you are in congress is legal. Doing so while people are working 3 jobs to clothe and feed their families and dying because they can;’t afford health care is wrong.

This list can go on for page after page but I think I made my point.

In the business world, it is just as easy to find examples:

When the board and executive officers vote themselves excessive pay packages while denying good performing workers lower in the organization is legal. It is however wrong.

Appointing your own friends and family to senior positions in a company is legal. It is however wrong and will cost the organization dearly in the long run.

Classifying, reclassifying what constitute product sales, support, maintenance and services is legal (within certain bounds). It is however ethically wrong as it is normally done to serve the purpose of obscuring financial facts.

Selling products to customers because it might meet their demands partially despite the fact that somebody else’s product will fully meet their needs without being totally honest with the customer about what your product is lacking is legal. It is however deplorable and ethically wrong.

Taking a job to get the title and salary only to use it as a short term stepping stone to another job outside your company is legal but not ethical.

It has been my experience that eventually these people’s actions catch up with them. Unfortunately it is normally not soon enough. Having an alert and active press and a good board should however be enough.

IBM just announced their new IBM z10 EC mainframe series. All I can say is WOW! These machines are truly the monsters of enterprise class (EC) computing. These machines are not cheap at around $1 million but the features are impressive.

• Up to 1.5TB of memory
• Up to 64 Quad Core processors specially developed for this machine
• Special energy efficient features (yes, a Green Monster) and it’s even got a green panel to prove it
• Small size (between 1300Kg and 2300Kg and 2.83 Sq meters)
• Built in encryption, internal Coupling Facility (CF) and many other security features
• On demand virtualization
• Up to 60 LPARs
• Up to 1Mb Page Frames
• 668 of 894 instructions implemented in hardware
• More than 50 new instructions to make use of the new hardware
• Specialized engines for Java and for Linux

In short this is a monster machine and as far removed from the System 360 box I started on 25 years ago as the horse and buggy is from the space shuttle. That machine had 32Mb of memory, 2 single core water cooled CPUs and supported an incredible workload. We had databases with over 80 million records giving sub-second response time to hundreds of online users working on old 3270 terminals (now you know how old I am )

In my opinion IBM just busted Moore’s law and produced a next generation server at least 3 times as powerful as the previous generation. So much for doubling the state of the art.

Read more about this monster at IBM z10 EC Announcement.

Disclaimer: Of course all these acronyms and model numbers are trademarked by IBM.