Entries from August 2008 ↓

From OSCON via O’Reilly Radar here’s a good case study of an architectural decision driven by the system requirements rather than the usual religious considerations that pollute the bloggosphere.

FriendFeed needed update info from Flikr but a REST-based “pull” approach is highly inefficient in this case. Instead the solution architects opted for a “push” approach using xmpp as the message transport. This is a really good presentation because it goes into the architectural choices and implications of “push” versus “pull”.

I characterize this as “pull vs push” rather than “REST vs xmpp” (or “REST vs *” or “why REST is crap”) because fundamentally it comes down to the best choice of how to synchronize changes between systems. You make this choice based on the usage characteristics of the different systems, the likely traffic volumes this will result in and the consequential resource impacts. Having made the choice between push or pull you then choose the appropriate message transport.

The web doesn’t do a lot of “push” and consequently there is not a lot of discussion about push and REST. Dare Obasanjo characterises it nicely:

Polling is a good idea for RSS/Atom for a few reasons

• there are a thousands to hundreds of thousands clients that might be interested in a resource so the server keeping track of subscriptions is prohibitively expensive
• a lot of these end points aren’t persistently connected (i.e. your desktop RSS reader isn’t always running)
• RSS/Atom publishing is as simple as plopping a file in the right directory and letting IIS or Apache work its magic

The situation between FriendFeed and Flickr is almost the exact opposite. Instead of thousands of clients interested in document, we have one subscriber interested in thousands of documents. Both end points are always on or are at least expected to be. The cost of developing a publish-subscribe model is one that both sides can afford.

Inside the firewall, the situation is often more akin to that between FriendFeed and Flikr. This is why messaging is more common inside the firewall than outside – not because of any universal superiority between REST versus messaging, but because the system requirements are different and often favour a push approach rather than pull.

While your over at Dare’s excellent Blog, be sure to also check out his discussion of push versus pull in the context of scaling Twitter and MS Exchange.  These are important considerations for designers of federated systems such as federated databases or federated messaging systems. The example of FriendFeed to Flikr could be considered as the first incremental step toward a federation.

In addition to having an affinity for IBM, ILOG has jumped in bed with Microsoft with ILOG Rules for .NET.

I am not easily impressed, however I must say that this product earns a lot of points in my book. It took several weeks of in depth research for this article, but I came away with a very positive impression of the product and the .NET platform in general. If Microsoft’s WCF performance figures are to be believed, anyone building enterprise applications on .NET  need look no further. They even eat their own dogfood.

The copy editor (a new one) had a heavy hand with this one, but the message is still clear. You can read the review of ILOG Rules for .NET and it’s applicability to the enterprise over at InfoWorld magazine.

It is certainly ‘interesting times’ in the BRMS space. With the union of JRules & Filenet through the IBM acquisition, one wonders if this shotgun marriage isn’t the final step on the BRMS/BPM/SOA consolidation. FairIsaac seems to be on the ropes, with little choice but to accept an acquisition. That leave only a handful of commercial vendors. Perhaps we’ll see the rise of open source BRMSs? I’ve already seen more uses of JBoss Rules (Drools) in the field this year that I’ve seen in the past three, and it’s improving by leaps & bounds with each release.

Interesting times indeed.

In 2002 Sonic Software invented the term ESB to differentiate their middleware from everyone else’s middleware. This is an old marketing tactic when you can’t differentiate your product from the others – just invent a new category. To lend credence, you need the collusion of an analyst and Gartner was there to knock this marketechture into the hype-stratosphere. We can also thank Sonic for the crap notion that an “ESB is a prebuilt SOA“.

ESBs have been back in the news again with the usual attendant vitriol and this has revived the perpetual question – “what is an ESB and why do I need one“?

I’ve seen ESBs referred to in two rather broad contexts. The first context refers to a distributed infrastructure that allows your Service Providers and Service Consumers to find each other and work together in a scalable and loosely coupled manner. This is often referred to as the “ESB as design pattern” and I think it is what many people would like ESB to mean. This “Service Bus” is effectively an extension of the “Message Bus” concept and is what I had in mind when I wrote about this subject a while ago.

The second context is ESB as a tool or a “thing you buy from a vendor” and this seems to be the terminology that calls forth all manner of vituperations. In this context ESB is secret marketing code for what used to be called “integration middleware.” This is also the thing that Jim Webber calls the “Erroneous Spaghetti Box.”

In this context, the eternal ESB question becomes – “in an SOA world, do I really need integration middleware?” I really think you can make more sense of the ESB debate by recasting into this terminology. The SOA pragmatists (including myself) see that there is a role for “integration middleware” as tools within your SOA infrastructure.

Eric Roch thinks of an ESB as a “productivity tool for integration” and points out that The legacy integration problem hasn’t gone away yet.

ZapThink say that an ESB could play the role of a Service Intermediary where transformations and content-based routing are essential requirements.

Todd Biske characterises five different types of ESB product each supporting different functions such as legacy integration, orchestration, mediation and transport, SOAP wrapping and gateways. The key insight here is how the label “ESB” has come to be applied to so many disparate products. “ESB” has come to mean everything and nothing and should be banished from our vocabulary.

So I agree with the pragmatists – design your SOA infrastructure to support your business requirements. Consider the so-called ESB products as tools and if you need mediation, or orchestration or transformation or integration to legacy systems then consider using the scads of tools – both proprietary and opensource – out there that support this stuff. And whatever you do, don’t try to author XSLT using Notepad.