ESBs: translators in an SOA world

A strange article has popped up on zJournal about SOA. I am not sure I fully understand the content but it seems to be an advice to CIOs basically saying: SOA is difficult to get right and ESBs are a bad thing.

This is the first time I read something clearly hostile to the ESB architecture. The author seems to believe that they are too complex and that they mostly try to imitate old EAI systems, rather than embracing SOA.

The article seems to imply that the only way to pure SOA is rewriting applications is such a way that they are natively service enabled. It states, in several places, that "API"s are a bad thing.

Following this idea, I guess you would have to replace SQL, SMTP, JMS, Excel macros,... by Web Services.

It's a little bit as if you were saying: all these languages that people speak around the world make communication difficult, let's all speak Esperanto.

As long as we are not all speaking Esperanto, there will be a need for Translators. I guess that's why ESB's are so useful to an SOA.

Mainframes are not open source friendly

IBM is a strange beast. On one hand, they gave away Eclipse and the Apache Software Foundation but on the other, they don't seem to embrace open initiatives when mainframes are involved.

You can read more about what happened to PSI and T3 Technologies on openmainframe.org. These examples are more on the hardware side but there is no sign of IBM opening up any of its z/OS software.

Most of the open source initiatives I have heard of such as http://www.opencobol.org/ or http://h3270.sourceforge.net/index.html are from third parties and do not attempt to run on z/OS itself.

I think that IBM's attitude toward open source on z/OS is harming the mainframe community and is counterproductive in the long term.

Mainframe-centric integration costs

Gregg Wilhoit, DataDirect's chief architect, is one of the smartest professionals I have met. He continues to drive the Shadow line of products.

Shadow is rooted in the data integration space but has evolved over time to include programmatic integration as well.

From an architecture standpoint, Shadow is a mainframe-centric integration solution. It is probably one of the fastest and most stable products available that runs natively on the mainframe (Other such products are GT Software's Ivory, HostBridge, SOA Software SOLA and IBM's CICS Web Services support).

The major argument against mainframe centric integration solutions is usually one of cost. With the broad adoption of SOA for instance, all mainframe-centric solutions suffer from the cost of XML parsing/formatting. This is a CPU intensive activity that affects the overall mainframe cost of ownership (On mainframes, the more CPU you consume, the higher your software license fees are).

Gregg was one of the first (maybe the first as far as I know) who made it possible to reduce such CPU costs by exploiting IBM's specialty engines on system z. These co-processors can offload java and DB2 related payloads from the main processors therefore avoiding the license fees inflation. Since then, other companies have jumped in.

Although the ZIIP/zAAP offloading is good news for mainframe centric solutions, I doubt this will significantly reduce their total cost. One important aspect of integration is that it needs monitoring for instance. It is a whole lot trickier to tune mainframe centric solutions than distributed ones. It also requires very specific and costly skills and software.

When comparing distributed integration to mainframe-centric integration, it is important to compare development costs, administration costs and ultimately exit costs. I doubt that the total would be in favor of mainframe centricity.

In my opinion, the major argument for mainframe-centric solutions is one of performance and stability. The cost though will probably remain high.

Openworld Forum

Went to the open world forum last week. This is the first time I attend and found the event quite interesting.

There were a lot more business suits than I expected and most of the topics revolved around the business aspects of open source.

Had a chance to listen to Nick Halsey from Jaspersoft, Josep Mitja from openbravo and Yves de Montcheuil from Talend. I find it much more interesting to listen to these relatively young, yet quite successful, open source companies, than to the older organizations such as Apache, Eclipse and Linux which seem out of reach.

It seems these smaller OSS companies make their money mostly by selling subscriptions. This model has been very successful for Redhat of course but I am still wondering if it is as efficient for server technologies. I thought services would be an important secondary source of revenue for them but this does not seem to be the case. The explanation could be that these companies heavily rely on SI's to get them into accounts and therefore they can't sell too much services for fear of openly competing with these same SI's. The bright side is that this forces them to focus on software engineering rather than diverting their resources on services.

The most impressive presentation I saw was from Mark Shuttleworth, the Ubuntu project founder. He had 3 slides with a single word on each of them. This is the first time I can remember 100% of a presenter slides content without taking a single note!

ANTLR and Terence Parr

I am reading Terence Parr 's The definitive ANTLR reference. I have to say that it is not often that I regret not being 25 years younger to attend Terence courses at the University of San Francisco.

Theories behind compilers are still complex but Terence is doing a great job at making things clearer for people like us, with concrete problems on their hands.