Middleware Matters

IONA has a self-proclaimed fan. I looked up the word "fan" in the thesaurus (on my nice new 15" PowerBook!), and it lists the following synonyms:

enthusiast, devotee, admirer, lover; supporter, follower, disciple, adherent, zealot; expert, connoisseur, aficionado; buff, bum, fiend, freak, nut, addict, junkie, fanatic, groupie.

These words would seem to imply that a "fan" would be quite knowledgeable of whatever it is that he or she is a fan of. Why, then, does our self-proclaimed fan demonstrate an almost complete lack of factual knowledge about IONA and its products?

The one thing our fan gets right is that we have been helping our customers build successful SOAs for many years. That much is true, given that a variety of our customers built enterprise SOAs in the mid to late 1990s using our CORBA software, and those systems are still running today. Credit Suisse's CORBA-based information bus, which handles millions of financial transactions daily, is a good example here. In telecom, Orbix is so widely deployed that pretty much anytime you make a phone call in much of the world, you're going through Orbix in one fashion or another.

Since then, we've been leading the way in bringing web services approaches to the enterprise SOA world. Our first web services product, XMLBus, was quite successful, and was in production in several customer enterprises before any of our established competitors had even heard of web services. Hot on the heels of XMLBus, based on experiences with it and with our CORBA systems, we produced Artix, the world's only truly Extensible Enterprise Service Bus (ESB).

Now, when all your SOA knowledge is based on the horrible failure that is EAI, as seems to be the case with our self-proclaimed fan, it's easy to be completely unaware of what successful technology actually looks like. For example, our fan mistakenly states that Artix is "and (sic) ESB solution which is information- not service-oriented." Our fan then points to an article to try to explain the difference between "information-oriented" and "service-oriented." If you read the article, you find that "information oriented" is the use of web services to access information locked in a business system, while "service oriented" is leveraging a remote method or behavior in a remote system.

If our fan were as much a fan as he claims, he might have taken the time to actually look into what Artix actually is, and might have even spoken to the customers using it. Had he bothered, one thing he would have learned is that Artix has been shipping for a couple years now, and is not just following on the heels of the competition as he claims. Late to market? Not at all -- we've been there for awhile now. The others are playing catch-up, not us.

More importantly, he would have learned that Artix does not prescribe itself to the same ESB definition that companies like Sonic and other ESBs do. For them, an ESB is basically a web service wrapper around JMS messaging technology. Kinda lame, really. Artix, on the other hand, is a highly distributed set of infrastructure components that enables existing software assets -- business systems, infrastructure components, transactions, etc. -- to be easily shared and reused inside of newly-developed composite applications and business process flows.

The flexibility of Artix means that just about anything, even those expensive-yet-worthless EAI packages that folks like our self-proclaimed fan tricked you into buying, can work seamlessly with other services in your SOA Network. And unlike EAI, Artix doesn't force you into using proprietary protocols, data formats, and loads of adapters. You want your .NET clients to talk seamlessly to your legacy CORBA systems? Use Artix -- one of customers is doing just that, running a call center in production on version 1 of Artix. We can handle a wide variety of protocols and data formats, such as JMS, MQ, TIBCO, Tuxedo, CORBA/IIOP, and of course SOAP and HTTP, switching between them as needed and without forcing a canonical protocol or format in the middle. The ability to embed or deploy Artix directly into the major application platforms -- J2EE, .NET, CICS/IMS on the Mainframe, CORBA, Tuxedo, etc. -- is what separates IONA and Artix from the other ESB players. Our fan should know that Artix is not a messaging layer that moves information around between systems; it is a flexible and unique approach to enabling one software entity to perform a unit of work on behalf of another. Our unique plugin architecture -- the same patented Adaptive Runtime Technology (ART) that powers Orbix 6 -- enables us to support a broad set of enterprise backbone protocols and message formats, plus the ability to plug high-value QoS services for security, management, and transaction coordination directly into any Artix service endpoints. Try that with the centralized, server-centric, bloated, ultra-expensive, and -- most importantly -- failed EAI systems that our fan foisted on some of you.

We ask only one thing of our fans: that they get their facts straight. This one obviously didn't bother. We invite you to learn the true facts by downloading Artix and trying it yourself.

Via Mark (whose CORBA comparison is BTW off the mark), a story about how CIOs will fail with SOA. The problem with the story is that it's missing some important facts.

The story implies great expense related to SOA implementation. While one could certainly incur great expense in implementing SOA, one need not (hence the title of this blog entry). Our customers have proven this for themselves. Such expense is usually due to falling victim to believing that one needs to massively "rip and replace" existing systems to gain the benefits of SOA. This is entirely wrong.

Imagine being able to take an existing service, be it implemented on the mainframe or Windows or Solaris or Linux on top of .NET or J2EE or CORBA or Tuxedo or CICS or IMS or TIBCO or MQ or JMS or whatever, and with a few mouse clicks being able to expose that service into a SOA Network usable immediately by other applications in your enterprise, regardless of their underlying OS or implementation technology. Wouldn't that be cool? And wouldn't it be cooler if you didn't need to touch the existing service in any way whatsoever — no coding, no recompilation, no redeployment, nothing — to make it available in this manner?

Well, I get tired of repeating myself, but this is possible today with Artix. Our customers are doing exactly this in production now with great success. Download it for yourself and give it a try.

Folks making dire predictions like Mark and Jeff have never used Artix.

Back in my January/February IC column, I wrote about the power of reflection. As most of you probably already know, it's quite a useful tool, especially in middleware where, for better or worse, you're often trying to hide infrastructure from users. Reflection can assist with adaptivity, which is also an important trait for middleware for purposes of reconfiguration and extensibility in important areas like protocols, policies, and qualities of service.

These topics are covered by one of my favorite workshops: The 4th Workshop on
Adaptive and Reflective Middleware. This year it will be held in conjunction with the Middleware 2005 conference in late November in Grenoble, France. This workshop always has a number of good papers and some good discussion, so I encourage you to submit a paper and to attend.

Today IONA announces Celtix, an open source Java Enterprise Service Bus (ESB).

There are a lot of open source projects out there, but many of them are essentially closed designs based on little more than some unproven ideas in a couple peoples' heads. We're building Celtix based on the Java Business Integration (JBI) standard. Because JBI incorporates lessons from real-world business integration systems, including our own, it will provide firm direction for the effort.

JBI avoids the errors of EAI by promoting service-based integration without requiring hubs and canonical protocols and formats. Another important feature of JBI is that it's a standard, whereas everything EAI was purely proprietary. JBI's use of WSDL enables a high degree of integration flexibility. In fact, some of JBI's design features bear a close resemblance to Artix, which, as our customers have already proven on numerous projects, enables high-performance integration with extreme flexibility and adaptability. Nobody knows how to build this kind of SOA infrastructure better than we do, and we'll prove that again with Celtix.

We're sponsoring the project under ObjectWeb, mainly because of their open source middleware focus and because they, like IONA, have a global presence.

I think this is gonna be fun!

My May/June Internet Computing "Toward Integration" column is available in both PDF and over at DSOnline. It covers WS-Addressing metadata. Feedback welcomed, as always.