EAI Blog

I continue working on the Term Paper.
The more I read about ESB, the more I can see how controversial the topic is.  

People cannot agree on almost everything related to ESB.
For example, some people think that an ESB is not a product, but an architectural pattern.
Others, however, describe ESB as a coherent piece of infrastructure available for purchase through a number of vendors.

I believe that both notions are correct. ESB is definitely an architectural pattern with some distinctive features, but at the same time, it is a coherent piece of software and not just a composition of traditional middleware in a new packaging. 

I was also finally able to create a short homemade ESB definition based on the Dave Chappel's article: “ESB is a SOA-based Enterprise Application Integration Broker”. I think that the definition above gives a good idea of what ESB really does and what role it plays in the enterprise architecture.

   Lab 3b

   I have completed the second part of Lab 3. Everything seemed to be fine until I tried testing the whole configuration and received an error message saying that the Receiver Agreement was not found.

   I inspected the Receiver Agreement and did not find any errors in it. Then I compared it with the already existing agreements and eventually discovered that instead of being active, my Receiver Agreement was still in the "Being Processed" state.

   It turned out that although I was activating all the entities, some of them failed to activate which I did not notice because the errors were displayed in the very small window at the bottom of the screen.

  After I activated all the entities, the test started working properly and I was able to complete the lab.

   Term paper

   I started working on the term paper and found out that it was not so easy to find a good definition of the ESB. Most of the articles introduce the ESB just by describing its key features without giving any formal definition. Therefore, I had to perform some additional web search in order to find a clear, compact, and useful definition of the ESB.

   Surprisingly, most of the experts turned out to be not in favor of the ESB. Their thoughts were somewhat similar to those available in the interesting Steve Vinoski’s Blog entry.

   If I remember correctly they put the ESB in one row with the many failed attempts (like EJB, for example) to create a software "silver bullet" that will solve all the application integration problems.    As Steve notices in his blog "Many developers just want to write some code and plug it into a magical framework that transparently handles all the distribution, persistence, security, transactions, and reliability underneath. Chuckle. Underlying frameworks just grow and grow as they try to provide all this, and so they develop more bugs, more inconsistencies, more special cases, less flexibility, and less reliability as time goes on, not to mention foisting on the unwary the XML configuration hell..."

   Another their point was that the ESB is heavy utilized by software giants like IBM, Microsoft, Oracle, etc. trying to lure naive customers into a trap of an exclusive contract and make them heavily dependant on one particular vendor product.
   At first, it looked more like a  exaggeration to me. Just the following Monday, however,  I learned that Cape Clear, the ESB vendor that company where I work uses, was acquired by Workday. According to the article, Workday also mentioned that "the Cape Clear ESB will no longer be available as a standalone offering". The future of the ESB at my company has suddenly become uncertain.

   Another misconception mentioned in Steve's article is that "Large enterprises believe they can save themselves a lot of money and trouble if they can just get the whole enterprise to agree on a single integration architecture". In reality, states Steve, it never happens.

   Both Greater Wisconsin Software Symposium experts and Steve agree that in most of the cases dynamic languages and REST provide much better solution for lowering software development costs and achieving integration and extensibility than the ESB does.

   Well, this is definitely something to think about.

While working on the second reading assignment (John S. Webster, "Health Services," Computerworld, July 2005) I came across the familiar name of John Halamka - a controversial CIO of Boston-based CareGroup.

Apparently, John Halamka has recovered from the famous 2002 fiasco which is known to the public as "Beth Israel's Health-Care IT Disaster" and is considered to be one of the worst health-care IT disasters in the history of mankind. The detailed description of that case can be found in the excellent Harvard Business School study.

After reviewing the study, I came to conclusion that CareGroup’s senior IT management concentrated their efforts on the technology side of IT and paid too little attention to the actual IT management. The case clearly shows that even the latest and greatest IT solutions are not able to prevent system failure if they are not supplemented with proper management and governance.

It looks like Care Group IT, being very proud of the highest level of the implemented technology, did not have a solid disaster recovery plan or a reliable backup process. Security management, network planning, and change control processes did not seem to be of good quality either.

Now Halamka is very excited about “seamless data integration” and web services. In the Computerworld article he calls them “… the glue that you can use to create a virtual system”. However, he does not even mention the challenges of SOA Governance, which seems to be an alarming symptom to me. I hope that the Care Group IT avoids another disaster.

The Enterprise Service Bus (ESB) is becoming one of the important elements of Application Integration at my work. I have some practical experience in working with the ESB. All new web services that we develop are added to the Service Registry and are accessed by consumers through the ESB.

That is why I decided to pick "ESB" as a topic for my term paper. Specifically I am interested in how ESB is related to SOA and in how ESB solutions can be implemented in the organizations that use SOA.

I am looking forward towards participating in Greater Wisconsin Software Symposium that will last from Friday, February 29 until Sunday, March 2. It is also known as "No Fluff, Just Stuff" conference. 

I went to that conference two years ago and liked it a lot. The speakers were excellent, the topics were very interesting and informative, and the overall organization was great.

This year they again are offering many interesting sessions. I am particularly interested in Filthy Rich Clients with the Google Web Toolkit presented by David Geary because I am thinking about using GWT to develop a web site for the neighborhood where I live.

Another example of a very useful session is 10 Tips for Getting Your Project Back on Track  presented by Jared Richardson. After taking the excellent BUS 748 "Information Technology Project Management" course taught by Professor Ramamurthy I became very interested in Project Management and did not want to miss a chance to learn more about it.

Good day, all!

I have completed reading chapters 6 and 7 of the textbook.

The chapters give a good idea of

-what types of middleware are available on the market;

-what the main, defining characteristics of those types of middleware are;

-what advantages, disadvantages and main applications each type of middleware has.

However, the book does not seem to give a good feel of how some complex types of middleware work. It also does not provide clear, visual, easy-to-understand examples on the topic.

As a result, the author succeeds in two cases:

1) when the described technology is relatively simple (RPC, Messaging)

2) when the reader has at least some basic understanding of the subject (in my case it was the understanding of application servers, transaction monitors, and database-oriented middleware).

It seems to me that the author is not so successful in describing complex types of middleware to readers, who do not have any prior knowledge of the subject.

For example, CORBA and COM+ concepts have always been difficult to understand for me, even though I had some limited experience in working with COM+. After reading the chapter I still have a relatively vague idea of the mechanisms that enable CORBA and COM+ to perform their functions.

As of XML Exercise, I was impressed by how easy and developer-friendly the Visual Studio makes performing basic operations with XML.  

Mike

I have completed reading chapter 11 of the textbook.

I liked the way the author clearly described the power and limitations of both XML and XSLT.

I already have some job-related experience working with XML and SOAP. However, the author helped me to see the "big picture" and to better understand the role XML and XSLT play in intracompany and intercompany (B2B) integration.

It was also very interesting to read the detailed description of what happens behind the scene during XSLT transformation. I used to consider XSLT as a "black box" that works in mysterious ways and is capable of transforming XML document into a different XML document or into a document of a different format (HTML, PDF, etc.). Now I have a much better understanding of how XSLT really works including the concepts of "input tree" and "output tree".

Talking about the opportunities for improvement I would like to mention various examples of XML and XSLT files listed in the chapter. Those examples are not accompanied by clear and detailed explanation. It makes it very difficult for person whose knowledge of XML and XSLT is limited to understand the examples.

I was able to understand XML examples because I had prior experience working with XML. However, it was difficult to understand XSLT example without using additional literature.