Thoughts on ESB

Planning SOA is a complicated process and there is a strong temptation to let a vendor offer up easy answers. Lawrence Wilkes of CBDI really drives home why it is problematic to select an ESB (Enterprise Service Bus) vendor instead of simply viewing it as an architectural pattern useful in achieving SOA goals...

"Don’t make the mistake of thinking it is safe to 'standardize' on an ESB product on an internal basis. The whole point of SOA is to provide the agility so that business and IT capability can be bestsourced. What is internal today may be external tomorrow, and vice versa.

"For these reasons," he concludes, "it is better to think of ESB as a service architecture of infrastructure capabilities, and then to consider what products best provide an implementation of each of the infrastructure services required. This may result in the selection of a product (or products) bearing the ESB label, or it may not."

Additional key thoughts from the article... (which make it a must read IMO)

• The goal of SOA is solutions based on loosely coupled, agile, federated, reusable Services. This should not just apply to the delivery of business solutions, which is rightly the organization’s prime focus, but also the implementation of the IT infrastructure. Organizations need to take care that in delivering business solutions they don’t lock themselves in infrastructure products that inhibit IT agility, and ultimately business agility.
• The capabilities required are unlikely to be delivered by a single product, nor may not be best delivery in a single product. Part of this lies in the fact that there is no common agreement on what an ESB is. ESB products often contain a mixture of service mediation, transport, management, and security capabilities. This is a useful set of capabilities to support SOA, but clearly overlaps with many other product categories. As different products in each category become better service enabled, they may be better (because of their specialization) at delivering that capability than a single “jack of all trades”.
• Federation requires the loose coupling, not just of business services and solutions, but of infrastructure. Service Providers cannot place ESB product demands on Service Consumers. Don’t make the mistake of thinking it is safe to “standardize” on an ESB product on an internal basis. The whole point of SOA is to provide the agility so that business and IT capability can be bestsourced. What is internal today may be external tomorrow, and vice versa.

Expect that line of thinking to gain momentum. At ThoughtWorks we've been advising our clients on how to resist vendor lock-in .

New Home and Articles

After many years, I finally have a personal website again. I will be posting articles there on a regular basis. The first is about Semantic Web technologies and Ruby (and a lot of other stuff) and the second is about hacking Rails for a new open-source project that I'm in the process of kicking off with Michael Granger.

Check it out at http://obiefernandez.com and let me know what you think.

SAP on Rails

The following news shouldn't be a surprise to anyone who's got their groove on with Ruby on Rails. In a new article on SAP Developer Network, german Ruby on Rails developer Piers Harding describes how to easy it is to integrate Ruby on Rails applications to SAP business-related functions via BAPI.

SAP on Rails focuses on providing an alternative type of Model template to the default - ActiveRecord. This is done via SAP::Rfc which allows RFC calls to SAP from Ruby, with automatic handling of data types, and discovery of interface definitions for RFCs. Some of this has been covered in a previous article, and on SDN. The model templating class is SAP4Rails. It's job is to automatically build up connections to R/3, look up the interface definitions for the collection of associated RFCs, and to hold the attribute definitions for the given model. This, coincidentally, corresponds to the SAP Business Objects view of the world in BAPIs.

Where's My Radar Detector

I swear someone should write a toolkit called Radar Detector that integrates your code and runs tests on a low-priority background thread while you're coding. Kind of like Eclipse does the continual compiling thing. I thought of this while reading James Shore's third great entry about continuous integration, where he says in part:

1. I often see teams using CruiseControl that don't have the shared agreement and feeling of responsibility for "we will never check in code that won't build" that underlies true continuous integration. Instead, one or two people feel that way and are using CruiseControl to force the "bozos" to step into line. You can imagine how well this works.

   If you're on an agile team and using a tool to solve a people problem, you're missing the point. "People and interactions over processes and tools," as the agile manifesto says. Get everybody to agree to take responsibility for the build, then install CruiseControl.

2. A second problem I see is teams using CruiseControl to catch their mistakes, not act as a rarely-needed safety net. This is a real and common problem--the team lets their build times get out of control, they stop running all of the tests themselves, and of course they start running into escalating build problems.

Having been on teams that displayed one or both of these anti-patterns, I understand exactly where James is coming from: Continuous integration is an attitude, not a tool and CruiseControl is a traffic cop: it doesn't help you follow the rules; it just tells you when you've broken them.

On the other hand, I've lost a lot of my idealism for being able to put together teams that maintain the right attitude and follow the rules all the time. Human nature is to follow the path of least resistance, and on a team with a continuous build server, that path is usually to check-in without thorough integration testing. Again quoting the agile manifesto, "People and interactions over processes and tools," I wonder if it isn't better to accept that people will tend to break the build and work on improving tools that prevent that from happening.

Connecting to ActiveMQ with Ruby

Oh man this rocked my socks tonight: Communicating transparently between Ruby and Java using JMS !!!

I spent the day using the web services libraries that come with Ruby to do some SOAP calls on my current project. I had some issues with getting the parameters of my SOAP envelope sorted out with the other team providing the service, but being able to code it in Ruby made it a little less stressful. I was glad to read the link above and realize I'm not the only Java guy that does this sort of thing in Ruby.

Dynamic Typing for my .NET Homies

Check this out -- Wesner Moise talks about dynamic typing and other possible changes in store for C# 3.0. I can't help but wonder if dynamic language features such as described in teh article are above the heads of both Mort and Elvis. I mean, those of us that understand the benefits of programming with a dynamic language are already using Ruby and Python. Why wait?

Deep Integration of Ruby and Semantic Web

My personal research has focused nowadays on how to best bring together two hot technologies: Semantic Web and Ruby

A significant number of people have been coming across my various blog entries about it and writing me to find out the status of my work. I have less time to work on this than I would like, but I expect to be launching an open source project within the next few weeks. In the meantime, here is a draft of my presentation that introduces the underlying technologies and key concepts. It is essentially the same version that I presented informally to various people at the 2005 International Protege Conference last week in Madrid.

Deep Integration of Ruby with Semantic Web Ontologies

Feedback welcome.