Sunday, March 31, 2013

My all time favorite advertisement

Here’s to the Crazy Ones.
The misfits.
The rebels.
The troublemakers.
The round pegs in the square holes.
The ones who see things differently.
They’re not fond of rules.
And they have no respect for the status quo.
You can quote them, disagree with them,
disbelieve them, glorify or vilify them.
About the only thing that you can’t do, is ignore them.
Because they change things.
They invent. They imagine. They heal.
They explore. They create. They inspire.
They push the human race forward.
Maybe they have to be crazy.
How else can you stare at an empty canvas and see a work of art?
Or, sit in silence and hear a song that hasn’t been written?
Or, gaze at a red planet and see a laboratory on wheels?
We make tools for these kinds of people.
While some may see them as the crazy ones, we see genius.
Because the ones who are crazy enough to think that they can change the world,
are the ones who do.


Go to the People.
Live among them,
Love them,
Learn from them.
Start from where they are,
Work with them,
Build on what they have.
But with the best leaders,
When the task is accomplished,
The work completed,
The people all remark:
We have done it ourselves.

-Lao Tzu

Just Do IT

You will tell them YES!

If by Rudyard Kipling

If you can keep your head when all about you
Are losing theirs and blaming it on you;
If you can trust yourself when all men doubt you,
But make allowance for their doubting too:
If you can wait and not be tired by waiting,
Or, being lied about, don't deal in lies,
Or being hated don't give way to hating,
And yet don't look too good, nor talk too wise;

If you can dream---and not make dreams your master;
If you can think---and not make thoughts your aim,
If you can meet with Triumph and Disaster
And treat those two impostors just the same:.
If you can bear to hear the truth you've spoken
Twisted by knaves to make a trap for fools,
Or watch the things you gave your life to, broken,
And stoop and build'em up with worn-out tools;

If you can make one heap of all your winnings
And risk it on one turn of pitch-and-toss,
And lose, and start again at your beginnings,
And never breathe a word about your loss:
If you can force your heart and nerve and sinew
To serve your turn long after they are gone,
And so hold on when there is nothing in you
Except the Will which says to them: "Hold on!"

If you can talk with crowds and keep your virtue,
Or walk with Kings---nor lose the common touch,
If neither foes nor loving friends can hurt you,
If all men count with you, but none too much:
If you can fill the unforgiving minute
With sixty seconds' worth of distance run,
Yours is the Earth and everything that's in it,

And---which is more---you'll be a Man, my son!

Wednesday, March 27, 2013

One way, only way, "the" way = Hard Work

It takes elite performers a minimum of 10,000 hours of deliberate focused practice to become experts. Deliberate practice does not mean doing what you are good at; it means challenging yourself, doing what you are not good at.

There is broad consensus among researchers of expert performance that inborn talent does not account for much more than a threshold; you have to have a minimum amount of natural ability to get started in a sport or profession. After that, the people who excel are the ones who work the hardest.

 -Mary Poppendieck

Sunday, March 24, 2013

Dreaming in Code

Dreaming in code : two dozen programmers, three years, 4,732 bugs, and one quest for transcendent software, written by Scott Rosenberg in 2007, is a wonderful read for any software developer, and it is just as unique as it's name.

It begins with the following quotation and goes on to prove that with a true story. 
Software is hard — Donald Knuth, author of The Art of Computer Programming

As the author himself  explains;

"The shelves of the world are full of how-to books for software developers. This is not one of them.

It poses a question and tells a tale. Why is good software so hard to make? Since no one seems to have a definitive answer even now, at the start of the twenty-first century, fifty years deep into the computer era, I offer, by way of exploration, the tale of the making
of one piece of software—a story about a group of people setting their shoulders once more to the boulder of code and heaving it up the hill, stymied by obstacles old and new, struggling to make something useful and rich and lasting.

This book had me hooked in the past few weeks. It felt like being around silicon valley, listening to fables of software history and time traveling through the decades in the world of computing. I've shared some of the insights from the book in my previous posts.

Kudos to the author for the excellent work.

And to my fellow developers, this is highly, I repeat HIGHLY, recommended.

Thursday, March 21, 2013

We do it again & again & again... :)

Birth of Ruby on Rails

37 Signals began as a Web design consulting firm and branched out into software development at first simply to meet its own needs. It built some internal tools to manage projects. Then it needed a way to communicate with clients, so it opened up parts of its system to them. Before they knew it, they had the makings of a Web-based application.

With four months more work, they turned their software into a service called Basecamp. Launched in February 2004, it quickly became a leader in the parade of new, rich, Web-based applications like Google's Gmail and Flickr.

37 Signals had only one developer, a young whiz named David Heinemeyer Hanssonk. He was keen on working with Ruby, a dynamic object-oriented programming language.

37 Signals set out to create some small programs, not to build an ambitious new platform or application framework. But in the course of building Basecamp, Hansson had written some useful and innovative code that streamlined and simplified the basic chores that all Web applications had to perform in the course of storing and retrieving data. After Basecamp's launch, he and 37 Signals decided to take that work and release it as an open source platform called Ruby on Rails.

Rails, as it came to be called,made writing Web applications easier, in part by limiting the programmer's options. "Flexibility is overrated. Constraints are liberating," Hansson says.

Rails was ready-made for the AJAX-style interface enhancements that were making those Web-based programs credible competition to their desktop equivalents.

- Summarized from 
Dreaming in code : two dozen programmers, three years, 4,732 bugs, and one quest for transcendent software by Scott Rosenberg.

In the Beginning There Was... Spaghetti Code!

In many of the dominant programming languages of 1960s, like Fortran and Basic, the computer moved sequentially through a list of numbered instruction statements, and the programmer could jump from one point in the sequence to another using a statement called GOTO. Like a film editor making a jump cut, GOTO simply dropped one story line that a program was developing and picked up another. It handed off control from one point in a program to another unconditionally, taking nothing else into account—neither the values of different variables nor the state of the program and its data.  As a result confused tangles of software that came to be known as "spaghetti code" was generated.   

Advocates of a methodology known as "structured programming" proposed a set of practices to banish the plague of procedural pasta. The central idea was to compose a program as a collection of subunits, each of which had only a single point of entry and a single point of exit.    

The specific injunctions of structured programming would quickly be codified in the design and syntax of new generations of programming languages. Its broader imperative—that "each program layer is to be understood all by itself"—has driven one innovation after another in subsequent decades as programmers have devised new ways to isolate, "modularize," and "encapsulate" the moving parts of software from one another. 

A certain Frederick Brooks led a 360 programming team in IBM to deliver a OS named OS/360. The project inspired his seminal writing in The Mythical Man-Month. He led the team through the concept and design phase,but he departed before the ideas were implemented, and after he left, the project got into "serious trouble."  

Serious trouble: Slippage. Delay. Revised schedules that slipped again. And more delay.  

A young Watts Humphrey took over the reins of software management at IBM in 1966. he was stunned by its state, he wrote;  

"My first need was to find out where the work stood. . . . In each laboratory I visited, I asked management for their plans and schedules. No one had anything other than informal notes or memos. When I asked for the managers' views on the best way to manage software, they all said they would make a plan before they started development. When I asked why they did not do this, their answer was that they did not have time. This was clearly nonsense! The right way to do the job was undoubtedly the fastest and cheapest way. It was obvious that these managers were not managing but reacting. They were under enormous pressure and had so much to do they could only do those things that were clearly required for shipping code. Everything but the immediate crisis was deferred. I concluded that the situation was really my fault, not theirs. As long as I permitted them to announce and ship products without plans, they would continue to do so."

He went to his boss. "I told him that since all the delivery schedules were not worth anything anyway, I intended to cancel them. Next, I would instruct all the software managers to produce plans for every project. From then on, we would not announce, deliver, or fund programming projects until I first had a documented and signed-off development plan on my desk. . . . It took the laboratories about sixty days to produce their first plans. This group, who had never before made a delivery schedule, did not miss a date for the next two and a half years."  

Humphrey's success at enforcing schedule discipline at IBM stood on two principles: Plans were mandatory. And plans had to be realistic. They had to be "bottom-up," derived from the experience and knowledge of the programmers who would commit to meeting them, rather than "topdown," imposed by executive fiat or marketing wish.  

After retiring from IBM Humphrey joined forces with the Software Engineering Institute (SEI) at Carnegie Mellon University. At SEI, Humphrey and his colleagues created the Capability Maturity Model (CMM) as a kind of yardstick for judging the quality of software development organizations. The CMM provides a five-step ladder for programming teams to climb.   

An organization at Level 1 is basically not doing much of anything. At Level 2, they're doing some planning, tracking, configuration management, they make some noises about quality assurance, that kind of stuff. A Level 3 organization begins to define processes—how they work, how they get things done, trainable things. At Level 4 they're using measurements. They have a framework for actually tracking and managing what they do, something statistically trackable. Level 5 organizations have a continuously improving process.   

For decades the organization of the typical project followed the "waterfall model." The waterfall approach—the label first surfaced in 1970—divided a project into an orderly sequence of discrete phases, like requirements definition, design, implementation, integration, testing, and deployment. One phase would finish before the next began. This all seemed logical on paper, but in practice it almost invariably led to delay, confusion, and disaster. Everything took forever, and nothing worked right. Programmers would either sit idle, waiting for the requirements, or give up and start design work and coding before they got the requirements. "Big design up front" led to big delays, and "big-bang integration"—writing major chunks of code separately and then putting them all together near the end of the project—caused system collapse. By the time the finished product arrived, so much time had passed that the problems the program aimed to solve no longer mattered, and new problems clamored for solutions.   

The waterfall model gradually acquired the bad reputation it deserved. In the mid-eighties, Boehm defined an alternative known as the "spiral model," which broke development down to "iterations" of six months to two years—mini-waterfalls dedicated to producing working code faster and allowing feedback from use of the resulting partially completed product to guide the next iteration. The spiral became standard in the realm of large-scale government-contracted software development, where a typical project's "acquisition cycle" might span as long as a decade. For the accelerating world of commercial software, however, it was still too slow.

In the nineties, the software industry's methodology devotees adopted the banner of Rapid Application Development (RAD), which promised to speed up the delivery of finished software through quick prototyping, more aggressive iteration cycles, and reliance on new tools that let the computer itself handle some of programming's more mundane tasks. RAD helped software companies work more nimbly. But soon after it began to take hold, along came the Web, which ratcheted up the industry's hunger for speed yet again, to the manic pace of Internet time.    

In 2001, a group of seventeen leaders in the field, gathered at a Utah ski resort to try to find common ground among their related but diverse approaches.   

The meeting found a more virile name for the movement—Agile Software Development—and produced a manifesto that reads in its entirety:   

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation »
• Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 

Agile development was more of an umbrella for shared values than a roadmap of specific processes.   

A variety of related but distinct agile methodologies have flourished since the manifesto's publication. One, Scrum, divides projects into thirty-day "sprints" and emphasizes daily meetings to keep work on track. The most popular species of agile methodology by far, though, is Extreme Programming.  

Extreme Programming's label mostly refers to the way it adopts a set of widely accepted methods and then pushes them to their limits.  

Is testing important? Then have developers write their tests before they write their code. Is it good for the development team to talk with the customer? Then keep the customer on hand to answer the developers' questions. Instead of periodic code reviews, have developers work in pairs all the time so that every line of code has more than one set of eyes on it from the moment it is written. Above all, accept that the customer's requirements, and thus the software's goals, are going to keep changing, and organize your project to "embrace change."  

XP introduced a new and sometimes strange vocabulary to the software development world. It mandated breaking projects down into "stories." Each story represents a feature request that the customer lays out for the developers in a narrative that explains what the program should do. The programmers go off and code the "story." If it does what the customer wants, they're done and ready for the next story. Under XP's radical incrementalism, there is no "big design up front." Coding starts almost immediately. This appeals to many programmers, whose itch to start cranking out code is often thwarted by lengthy design processes. The license XP grants to forget about writing detailed specifications and documentation of code is also popular.  

But programmers often find some other XP tenets difficult to follow, especially the rallying cry of You Aren't Gonna Need It, or YAGNI. YAGNI takes the just-in-time manufacturing method, in which factories don't collect the parts to build a product until a customer places an order, and applies it to the world of knowledge goods. The principle advises, 'Always implement things when you actually need them, never when you just foresee that you need them." In other words: Your meeting-scheduling program may someday need to support users in different time zones, but if your company has only one office right now, that can probably wait. This is practical but painful counsel for the habitual axe sharpeners of the programming tribe.  

Conventional wisdom holds that agile development and XP are best for small teams of experienced coders. Though XP has found enthusiastic converts in pockets all over the software industry, it's a demanding discipline if you try to obey all of its mandates.  

Critics have argued that XP often serves as an excuse for lazy coders to ignore the discipline demanded by specifications, documentation, planning, and all the other onerous burdens of "heavyweight" process.  

- Summarized from 
Dreaming in code : two dozen programmers, three years, 4,732 bugs, and one quest for transcendent software by Scott Rosenberg.

Monday, March 18, 2013

Target: Deliver a baby

  • A Project Manager is a person who thinks nine women can deliver a baby in one month.
  • A Developer is a person who thinks it will take four and a half months to deliver a baby.
  • The Onsite Coordinator is one who thinks single woman can deliver nine babies in one month.
  • A Marketing Manager is a person who thinks he can deliver a baby even if no man and woman are available.
  • The Resource Optimization Team thinks they don’t need a man or woman; they’ll produce a child with zero resources.
  • HR Manager thinks a Donkey can deliver a Human Baby – if given 9 Months !!!
  • The Documentation Team doesn’t care whether the child is delivered, they’ll just document 9 months.
  • The User Interface Team will design a baby with three arms and one leg and ask if it can be done.
  • The Quality Auditor is the person who is never happy with the process to produce a baby.
  • A Tester is a person who always tells his wife that this is not the right baby.
  • The Client is the one who doesn’t know why he wants a baby.

Friday, March 8, 2013

Maven on Ubuntu

Install:   sudo apt-get install maven
Verify:    mvn -version

The command apt-get, install the Maven in /usr/share/maven.


Configure a proxy in settings.xml
      <host>_internal proxy address_</host>
      <port>_proxy port_</port>

Install a jar manually
mvn install:install-file -Dfile= -DgroupId= -DartifactId= -Dversion= -Dpackaging= -DgeneratePom=true

mvn install:install-file -Dfile=/home/kl40306/Desktop/jars/camel-http-2.10.0.fuse-71-047.jar -DgroupId=org.apache.camel -DartifactId=camel-http -Dversion=2.10.0.fuse-71-047 -Dpackaging=jar -DgeneratePom=true

Thursday, March 7, 2013

Integrating Code-quality Reports to Teamcity

How do we display the code-quality reports like PMD, Findbugs, Checkstyle in Teamcity?
I wasted a lot of time to find this out. I guess it's a common problem, hence posting the steps.
Option 1:
Generate your quality reports in html format.

Configure the report (eg: FindbugReport.html) as an artifact in Teamcity

Administration -> Project -> Build Configuration -> Edit Configuration Settings -> 1. General Settings -> Artifact paths

Add report file path with the name. It should be relative to the Build Checkout Directory.

After the next build, report is seen as an artifact and you can click on it to view the report.

Option 2:
You can also display the report as a project tab.
But if you have several build configurations under the project, this can be misleading since you define the tab to display a report corresponding to a single configuration even-though the tab appear commonly to all configurations as a project tab. If you have only one configuration in project it should be fine.

Follow the steps in option 1.

Administration -> Project -> Report Tabs -> Create new report tab

You can simply give the report name (not the path) here since you have defined it as an artifact.

Report will be displayed under a new tab with the tab name you defined.
If the artifact is not available it will not be seen.

Option 3:
Use the Teamcity code inspection feature. Teamcity generates a report by combining the xml quality reports.

Generate your quality reports in xml format.

Administration -> Project -> Build Configuration -> Edit Configuration Settings -> 3. Build Step: Ant -> Additional Build Features -> Add Build feature

Select "XML report processing" from the drop down

Select report type, PMD, findbugs etc

In Monitoring rules add the file path (the same way you add the artifact path, relative to the Build Checkout Directory.)

You can see a single Code Inspection report as seen below. But here you cannot have a format you want like in option 1 and also it doesn't say which ones are findbugs issues and which are PMD.
Build results summarize the inspections total.
And a tab and a link as shown below.

Report is displayed like this

Monday, March 4, 2013

Differentiating between ESB implementations

Most ESB implementations provide all of the services that are used to define an ESB, so it is hard to differentiate ESB implementations based on features. A better way to differentiate between them is to use the following four measures.

Supported deployment / runtime environments
Many ESB solutions are designed to be deployed into application servers, other heavy weight containers, or proprietary runtime environments. These types of ESB solution is ideal for distributed computing. They also contribute to vendor lock-in.
Ideally, an ESB solution should have flexible deployment requirements so that it can be distributed through out an enterprise.

Container/component model
Does the ESB solution use a standardized container model, such as J2EE, JBI, or OSGi, for managing deployed services? Or does it use a proprietary model?
Ideally, an ESB solution should use a standardized container model. Standard models ensure maximum compatibility and lessen the learning curve needed for adoption.

Coupling to other infrastructure components
ESB solutions often leave out infrastructure components like orchestration engines and advanced transports like CORBA. Instead they rely on plug-ins or other components to provided the functionality. Many ESB solutions require a tight coupling between the ESB and the added components. This means that you are limited to only using the added components supplied by the ESB vendor or must learn complex APIs to extend the ESB yourself.
Ideally, an ESB solution would provide a loose coupling or provide a standardized interface between the ESB and any added components. This allows the ESB to be extended easily and in a flexible manner.


ESB solutions have a lot of moving parts and complex dependencies. Some ESB solutions handle these dependencies by locking themselves into using proprietary solutions for things like security or JMS implementations. Others rely on standardized implementations as much as possible.
Ideally, an ESB solution would only depend on widely available standardized libraries to make dependencies easy to manage.

-Fuse ESB Getting Started with Fuse ESB Version 4.3.1

Frog's eggs

We don't always have to look elsewhere to find inspiration!

Acres of diamonds could be just beneath our feet.

Sunday, March 3, 2013

Three Stonecutters

A favorite story at management meetings is that of the three stonecutters who were asked what they were doing.

The first replied, "I am making a living." The second kept on hammering while he said, "I am doing the best job of stonecutting in the entire country." The third one looked up with a visionary gleam in his eyes and said, "I am building a cathedral."

The third man is, of course, the true "manager." The first man knows what he wants to get out of the work and manages to do so. He is likely to give a "fair day's work for a fair day's pay."

It is the second man who is a problem. Workmanship is essential, . . . but there is always a danger that the true workman, the true professional, will believe that he is accomplishing something when in effect he is just polishing stones or collecting footnotes.

-Peter Drucker

What is OSGi?

It’s a modularity layer for the Java platform. Modularity refers to the logical decomposition of a large system into smaller collaborating pieces.

Nearly all but the simplest of applications can benefit from the modularity features OSGi provides.

Common scenarios where OSGi can be helpful
  • ClassNotFoundExceptions when starting your application because the class path wasn’t correct. OSGi can help by ensuring that code dependencies are satisfied before allowing the code to execute.
  • Execution-time errors from your application due to the wrong version of a dependent library on the class path. OSGi verifies that the set of dependencies are consistent with respect to required versions and other constraints.
  • Type inconsistencies when sharing classes among modules: put more concretely, the dreaded appearance of foo instanceof Foo == false. With OSGi, you don’t have to worry about the constraints implied by hierarchical class-loading schemes.
  • Packaging an application as logically independent JAR files and deploying only those pieces you need for a given installation. This pretty much describes the purpose of OSGi.
  • Packaging an application as logically independent JAR files, declaring which code is accessible from each JAR file, and having this visibility enforced. OSGi enables a new level of code visibility for JAR files that allows you to specify what is and what isn’t visible externally.
  • Defining an extensibility mechanism for an application, like a plugin mechanism. OSGi modularity is particularly suited to providing a powerful extensibility mechanism, including support for execution-time dynamism.

The OSGi Service Platform is composed of two parts:
  • OSGi framework
  • OSGi standard services

The framework is the runtime that implements and provides OSGi functionality. The standard services define reusable APIs for
common tasks, such as Logging and Preferences.

If you use an IDE to do your Java development, it’s possible you already have experience with OSGi.

OSGi layered architecture
  • Module layer—Concerned with packaging and sharing code.
  • Lifecycle layer—Concerned with providing execution-time module management and access to the underlying OSGi framework
  • Service layer—Concerned with interaction and communication among modules, specifically the components contained in them

General approach when creating an OSGi-based application
  1. Design your application by breaking it down into service interfaces (normal interface-based programming) and clients of those interfaces.
  2. Implement your service provider and client components using your preferred tools and practices.
  3. Package your service provider and client components into (usually) separate JAR files, augmenting each JAR file with the appropriate OSGi metadata.
  4. Start the OSGi framework.
  5. Install and start all your component JAR files from step 3.
-OSGi in Action

Saturday, March 2, 2013

Fuse ESB

FuseSource was formed when Progress Software spun off this open source effort into a separate organization in mid-2010. It was acquired by RedHat in mid-2012 to enhance Red Hat's JBoss middleware portfolio.

Fuse ESB is the core product of FuseSource.

Fuse ESB is an open source integration platform. It is a flexible, standards-based enterprise service bus based on Apache ServiceMix. It combines features from the Apache ServiceMix ESB, the Apache Camel integration framework, the Apache ActiveMQ message broker, and the Apache CXF web services framework.

You can download it now from RedHat downloads page, but I wonder  if the 90 day evaluation  story here is a mistake or not! Isn't it open source any more???

Fuse ESB has a pluggable architecture that allows organizations to use their preferred service solutions in their SOA. Any standard JBI or OSGi-compliant service engine or binding component – including BPEL, XSLT or JMX engines – may be deployed to a Fuse ESB container, and Fuse ESB components may be deployed to other ESBs.

It differentiates itself in the following ways:
  • Fuse ESB kernel is lightweight and can run on most platforms.
  • Fuse ESB kernel uses the OSGi framework to simplify componentization of applications.
    • The OSGi framework is a standard for managing the dependencies between application components. It also provides a standard mechanism for controlling the life-cycle of components.
  • Fuse ESB supports the Java Business Integration (JBI) specification.
    • JBI is a well defined standard for packaging, deploying, and managing components deployed to the ESB.
  • Fuse ESB can be coupled to other infrastructure services over a variety of transport protocols and message formats.
    • Out of the box, the Fuse ESB supports JMS, HTTP HTTPS, FTP XMPP, Web services, and a number of other bindings. In addition, you can easily extend its connectivity options using other components that conform to either the OSGi or JBI specification.
  • Fuse ESB employs standards as much as possible to limit dependencies.

In addition, Fuse ESB supports event driven architectures. Services deployed into the Fuse ESB container can be fully decoupled and will simply listen on the bus until an appropriate service request arrives. Fuse ESB also supports events that occur outside of the bus. For example, a JMS service can listen on a topic that is hosted outside of the bus and only act when an appropriate message arrives.

Architecture Overview

Fuse ESB employs a layered architecture comprised of the following:
  • Kernel: A lightweight runtime that extends OSGi with powerful features for handling and managing OSGi bundles.
  • Technology layer: A layer of component technologies that sits on top of the kernel.

Fuse ESB kernel is based on Apache Karaf, an OSGi-based runtime that provides a lightweight container into which you can deploy various components and applications.

The kernel provides the following features:
  • Console: Karaf can be administered via an extensible console shell that supports secure, remote access.
  • Dynamic logging: A dynamic logging backend provided by Log4J supports different APIs (JDK 1.4, JCL, SLF4J, Avalon, Tomcat, OSGi).
  • Hot deployment: When a JAR file is added to the InstallDir/deploy folder, it is automatically installed inside the runtime.
  • Provisioning: Application provisioning through file-drop, Maven repository and remote download.
  • Dynamic configuration: Changes to the properties files contained in the InstallDir/etc directory are monitored and propagated to the relevant services.
  • Security: Security framework based on Java Authentication and Authorization Service (JAAS).

Whoopee! More fertilizer for my garden!

Found this shared on FB and it was just what I wanted to hear. If I may use the analogy here, I was sinking in a pit full of dung!

UNPLEASANT THINGS, like becoming last in our class, happen in life. They happen to everyone. The only difference between a happy person and one who gets depressed is how they respond to disasters.

Imagine you have just had a wonderful afternoon at the beach with a friend. When you return home, you find a huge truckload of dung has been dumped right in front of your door. There are three things to know about this truckload of dung :
1. You did not order it. It's not your fault.
2. You're stuck with it. No one saw who dumped it, so you cannot call anyone to take it away.
3. It is filthy and offensive, and its stench fills your whole house. It is almost impossible to endure.

In this metaphor, the truckload of dung in front of the house stands for the traumatic experiences that are dumped on us in life. As with the truckload of dung, there are three things to know about tragedy in our life :
1. We did not order it. We say 'Why me?'
2. We're stuck with it. No one, not even our best friends, can take it away (though they may try).
3. It is so awful, such a destroyer of our happiness, and its pain fills our whole life. It is almost impossible to endure.

There are two ways of responding to being stuck with a truckload of dung.

The first way is to carry the dung around with us. We put some in our pockets, some in our bags, and some up our shirts. We even put some down our pants. We find when we carry dung around, we lose a lot of friends! Even best friends don't seem to be around so often."Carrying around the dung" is a metaphor for sinking into depression, negativity, or anger. It is a natural and understandable response to adversity. But we lose a lot of friends, because it is also natural and understandable that our friends don't like being around us when we're so depressed. Moreover, the pile of dung gets no less, but the smell gets worse as it ripens.

Fortunately, there's a second way. When we are dumped with a truckload of dung, we heave a sigh, and then get down to work. Out come the wheelbarrow, the fork, and the spade. We fork the dung into the barrow, wheel it around the back of the house, and dig it into the garden. This is tiring and difficult work, but we know there's no other option.Sometimes, all we can manage is half a barrow a day. We're doing something about the problem, rather than complaining our way into depression. Day after day we dig in the dung. Day after day, the pile gets smaller. Sometimes it takes several years, but the morning does come when we see that the dung in front of our house is all gone.

Furthermore, a miracle has happened in another part of our house. The flowers in our garden are bursting out in a richness of colour all over the place. Their fragrance wafts down the street so that the neighbors, and even passers-by, smile in delight. Then the fruit tree in the corner is nearly falling over, it's so heavy with fruit. And the fruit is so sweet; you can't buy anything like it. There's so much of it that we are able to share it with our neighbors. Even passers-by get a delicious taste of the miracle fruit.

"Digging in the dung" is a metaphor for welcoming the tragedies as fertilizer for life. It is work that we have to do alone: no one can help us here. But by digging it into the garden of our heart, day by day, the pile of pain gets less.It may take us several years, but the morning does come when we see no more pain in our life and, in our heart, a miracle has happened. Flowers of kindness are bursting out all over the place, and the fragrance of love wafts way down our street, to our neighbours, to our relations, and even to passers-by. Then our wisdom tree in the corner is bending down to us, loaded with sweet insights into the nature of life. We share those delicious fruits freely, even with the passers-by, without ever planning to.

When we have known tragic pain, learnt its lesson, and grown our garden, then we can put our arms around another in deep tragedy and say, softly, 'I know.' They realize we do understand. Compassion begins. We show them the wheelbarrow, the fork, and the spade, and boundless encouragement. If we haven't grown our own garden yet, this can't be done.

I have known many monks who are skilled in meditation, who are peaceful, composed and serene in adversity. But only a few have become great teachers. I often wondered why.It seems to me now that those monks who had a relatively easy time of it, who had little dung to dig in, were the ones who didn't become teachers. It was the monks who had the enormous difficulties, dug them in quietly, and came through with a rich garden that became great teachers. They all had wisdom, serenity and compassion; but those with more dung had more to share with the world.

My teacher, Ajahn Chah, who for me was the pinnacle of all teachers, must have had a whole trucking company line up with their dung at his door, in his early life.

Perhaps the moral of this story is that if you want to be of service to the world, if you wish to follow the path of compassion, then the next time a tragedy occurs in your life, you may say,

"Whoopee! More fertilizer for my garden!"

 - Opening the Door of Your Heart: And Other Buddhist Tales of Happiness


Friday, March 1, 2013

What really is an ESB?

Even-though all of us think we know what an ESB is, it's actually difficult to give a proper and comprehensive answer to the above question. ESB stands for Enterprise Service Bus, yes, but what kind of a beast it it?

The best answer I found so far is the following, from Java SOA Cookbook published by O’Reilly.

There is no specification for ESB. There is no standard that supports the creation of an ESB, or even a precise definition of what an ESB is. While by now the industry generally agrees on what features should be present in a product calling itself an ESB, vendors offer a wide variety of products with features that differ dramatically from one ESB to the next.
How to create a route in Oracle Service Bus is completely different from creating a route in TIBCO ActiveMatrix or a delivery channel in Apache ServiceMix. They don’t all have the same features, and the common features they do have are implemented in very different ways. So the knowledge you would gain about the specifics of one ESB would not be transferable to any other. A deep dive on Mule would offer very little insight for developers who aren’t using Mule, and there are so many ESBs to choose from.
In some cases, vendors, such as Oracle, Software AG, IBM, TIBCO, and others, offer “SOA suites” that comprise a collection of products such as an ESB, an orchestration engine, a SOAP engine, an enterprise registry/repository, a BPEL engine and design- time tools, Business Activity Monitoring and related tools, and more. The features present in these products from vendor to vendor are not consistent. For example, you might have an ESB from one vendor that handles transformations for you, and another ESB product that delegates transformations to an orchestration engine.  

It can all get very confusing. You can get a standalone orchestration engine, such as Apache ODE or Active Endpoints VOS, as well as standalone ESBs. Some ESBs run on an application server. Some vendors, such as Oracle, include a “light” subset of orchestration functions directly in their ESB but also sell an orchestration product.

The ESB is capable of connecting a variety of messaging systems without forcing you to create point-to-point channels that are visible to application clients. Clients connect to the bus, which serves as a mediation layer that shields clients from the disparate messaging formats and protocols used in the backend systems. The bus choreographs message interactions with a variety of related SOA technologies, such as rules engines (external or embedded), an orchestration engine (employing BPEL or XPDL), adapters for legacy and packaged applications, and internal routing and transformation mechanisms. This allows all of the nodes of the bus to interact without having to create specific routes to each application, thereby reducing the maintenance overhead. Because the bus abstracts and mediates connected nodes, some flexibility is achieved; if you want to swap out one application for another one, you can do so with minimal disruption to the overall solution.  ESBs are the backbone of SOA. They provide the opportunity to really make your entire IT landscape visible, integrated, and ready to participate in new composite applications across EAI, supply chain, B2B, portals, and more.

An ESB is often lightweight, and offers a centralized system for deploying components that can scale independently. 

An ESB allows you to send messages between multiple services in a distributed environment, offering a layer of indirection that provides a rich set of mediating features for those messages. An ESB is typically platform-independent in the sense that it will run on a range of operating systems and is often neutral with respect to application server and programming language. The bus allows you to connect native Java applications, .NET applications, object request brokers, and legacy platforms. To achieve this end, most ESBs offer support for invoking web services and other network-ready application nodes, employ adapters to connect with packaged and legacy applications, offer robust routing support for messages, allow orchestration and transformation of message content, and more.