Middleware Matters

My May/June 2004 IEEE Internet Computing magazine "Toward Integration" column is now available. This one, entitled More Web Services Notifications, is a follow-on from the previous column. It covers the WS-Notification spec, which I couldn't cover last time because it wasn't published yet.

Note that, unfortunately, the published version has a minor error in the references, which I've fixed in my online version. The problem is that the real reference 5, which should refer to the WS-Addressing spec, is missing. Doh! With the real reference 5 in place, the references currently listed as 5 and 6 should really be 6 and 7.

As with all my publications, all feedback on this new column is welcomed.

IONA has long been active in the telecommunications industry, with over 170 of the world's telecommunications companies using our Orbix distributed computing and integration infrastructure. Based on our many years of experience in telecommunications, we've put together a free Telecom Toolkit. It supplies a network management framework that supports both the TeleManagement Forum (TMF) 814 and Third-Generation Partner Project (3GPP) network management standards. Please read our toolkit description for more details, or better yet, feel free to download the free open source toolkit.

On Thursday May 13, Ram Krishnamurthy and I will be giving an audio webcast on Web Services security. We'll talk about the issues surrounding the use and deployment of security solutions in real-world enterprise systems, and how we at IONA address those issues in our Artix product. Ram is a senior engineer on the Artix team, and he's personally implemented a number of our Artix security features. The webcast is at noon EDT, and will last about an hour. If you're interested in listening in, please register for the webcast. See you there.

IEEE Internet Computing (IC) magazine has a number of cool special issues coming up. Have you considered submitting an article?

For example, real-world computing systems require reliability and dependability. That's why so much attention is being paid these days to autonomic computing and self-healing systems. For its March/April 2005 issue, IC is seeking articles addressing recovery-oriented approaches to dependability. I know for certain that a number of IONA customers have created middleware-based recovery and dependability approaches that would qualify for this special issue. Why not write these approaches up and submit them?

If you're interested in submitting something on this topic or on the other topics for which IC is seeking articles, please read the full call for papers.

A competitor of ours just announced a new product that (in their words)...

...extends and bridges proprietary message-oriented middleware (MOM) products, like TIBCO Rendezous, IBM WebSphereMQ (formerly MQ Series), SonicMQ and any other JMS-based solution, to support any standards-based Web services endpoint.

The product described above is a gateway (in fact, it has the word "gateway" in its name). Gateways are simplistic -- anyone can write one. Gateways add moving parts to your system that must be deployed, maintained, and managed, and since they're intermediaries, gateways increase overall system complexity while reducing performance, throughput, and scalability. Worst of all, if they're done poorly, gateways can be single points of failure, reducing overall system reliability and availability.

If you were traveling in another country where they spoke a different language, would you prefer to be able to read and speak that language yourself, or would you rather have to rely on translators to allow you to converse with the natives? The preferred approach should be fairly obvious -- the overhead of the translator route is significant, making it hard to get anything done. Gateways are similarly poor solutions for most integration cases.

Disintermediation is where it's at. Adding support for multiple protocols, transports, and wire formats directly into the service and consumer applications themselves allows them to converse directly with each other even though they might be built on totally different platforms or technologies. As I explained in a previous blog entry, service capabilities and business logic should be independent of whatever transports, wire formats, or protocols are used to talk to them.

Supporting disintermediation is precisely why we designed our Artix web services product in a way that allows it to be embedded directly into applications, thus providing them with multi-middleware capabilities. Artix supports MQ, TIBCO, JMS, Tuxedo, CORBA, and SOAP over HTTP/S for C++ and Java applications. And when SOAP or the others eventually get displaced by some newer fancier protocol, which of course is inevitable, your Artix-based application will be able to adopt them quite simply via new dynamically-loaded plug-ins (all Artix transports are implemented that way).

Of course, supporting multiple transports and protocols isn't easy. But even harder than that is supporting security and management across those multiple approaches. Since we know that our solution wouldn't be viable without such support, we provide significant enterprise-quality security support and management solutions.

It all has to perform well too, and Artix performance is outstanding, especially given its high degree of flexibility.

About the only place where it's OK to suffer a gateway is a situation in which the applications involved absolutely can't be touched. For such situations, Artix can also deployed as an intermediary. However, unlike some of our competitors, we give you the choice of using a gateway or taking the disintermediation route, rather than forcing you to adopt a slow, high-maintenance gateway for all cases.

Given all the above, if I had to compete against Artix, I'd personally be embarrassed to issue a press release touting a mere gateway.

Anyway, like I always say, find out for yourself: download Artix and give it a try.

Apparently someone over at the competition took issue with my previous posting. He called my posting a "rant," apparently so he could justify writing an actual rant of his own in response. The unfortunate part for him is that, like most rants, it contains nothing at all technical or worthwhile. Rather, it makes unsubstantiated market-related claims, attempts to insult my company, and then attempts to compare two products that simply can't be compared. After all, if the product he mentions could really already do what Artix can do, then his company wouldn't need a gateway, would they?

No, instead his rant just (poorly) attempts to insult IONA without basis, saying we're "late to the WS game" and "fighting with (our) own legacy stuff." Now those are laughable statements. We've been working on WS for many years now. For example, my friend Don Box called me years ago to run SOAP by me while it was still a work in progress. Our XMLBus product started shipping years ago and has been a successful precursor to Artix, and is still used in production. As for our "legacy" stuff, it brings in millions in revenue each year, allowing us to be a public company with $54 million in the bank and no debt. The person who was apparently unable to respond to my post technically certainly can't say anything even remotely close about the financial strength of his company. "Fighting with legacy stuff" is a problem they'd like to have.

I, however, prefer to keep it technical. I would have much rather have seen a technical response explaining why they think gateways are effective, or an explanation of his inaccurate product claims, by showing how their non-gateway product that he compares to Artix can make, say, seamless non-SOAP transparent invocations of WSDL-defined services over native bindings from a Tuxedo client into an MQ service, for example, without ever having to translate into SOAP, cross over into HTTP, or traverse a slow gateway. But I'll save him the trouble: it can't. Artix can do all that and much more, including the simple pure Web Services stuff that his product and others do.

Due to a highly unlikely series of errors between our replicated web servers and our blog data, I temporarily lost the two blog entries I posted before this one. Luckily, I managed to restore them from a combination of feed readers and web browsers -- thanks Mark, Werner, and Colby -- but I don't know how to restore the two trackbacks (there was one on each entry). Oh well, close enough. What's important is that any links to them created while they originally existed still work.

Don Box recently reminded me of my involvement in the Apollo Network Computing Architecture (NCA). I never worked on NCA itself -- that was reserved for people much brighter than me, such as Nat Mishkin and Paul Leach. Rather, I was only a user of the Network Computing System (NCS), Apollo's NCA implementation.

Back then, I was a hardware/software guy, writing both regular applications and embedded applications. Several years before, I had started my career working on advanced development chips for Texas Instruments, but I eventually discovered that software was both fun and challenging, and gradually switched over to it. At Apollo I worked on both hardware and software. One of my tasks there was to develop a distributed hardware debugger. This application had to run on a regular workstation and communicate with another workstation that was shut down and running only a remote service monitor on its Motorola 68020 service processor. The service monitor had to fit within only 22k of RAM (yes, i said kilobytes).

My first attempt to solve this was to stick a trimmed-down NCS server into the 22k and use RPC to send debugger commands over to it. It worked, but not entirely. The problem was that some perfectly valid and desirable debugger commands could hose the electrical operation of the bus that the network card sat on, which meant that the pings that NCS (and later DCE and COM) sent from client to server would not get through. When the pings failed, the client failed, because it assumed that the server was dead due to the lack of response to its pings.

I attempted to solve this by modifying NCS to make a flag available to turn off pinging. My changes worked technically, but Paul Leach nearly took my head off for them. He explained that NCS was a widely used system and turning off pings would break the protocol. My counter-argument was that the way I had implemented it (using a global shared library variable feature available only in Domain/OS), nobody would even know they had the capability to turn off pings. Nevertheless, the changes were deemed unacceptable, and they never made it into the code base.

I ended up writing my own protocol, which worked extremely well. The project was a big success, especially given that two similar attempts had been made before it and both had failed. I wrote about the project, which was called RISE++, in an article in the IEEE Design & Test of Computers magazine in the early 1990s. If any of you reading this are hardware geeks, "RISE" stood for "remote interactive scan enviroment," and it allowed hardware engineers to use the scan design features of the workstation under test to have virtually complete control over the state and the clocking of the hardware, to the point where they could single-step the hardware itself. Coincidentally, RISE++ also included one of the first uses of Tcl and C++ together, well before there were any public packages available for using Tcl with C++. At the time, John Ousterhout, the creator of Tcl, turned down my offer of Tcl codebase modifications to accommodate C++, essentially stating that he didn't think anyone would ever want to use Tcl and C++ together. Oops, wrong guess there! :-)

Anyway, what my experience with NCS for RISE++ taught me was that protocols can't ever be "one size fits all." The NCS protocol could not work for my application because it required pings, which my hardware couldn't handle. This fundamental realization eventually led to my work to develop multi-protocol middleware, which represents a significant part of my work over the past dozen years. For example, I believe I was the very first to create an ORB that interoperated between two vendors, years before the Internet Inter-ORB Protocol (IIOP) was created, by crudely cramming both IBM's Distributed System Object Model (DSOM) ORB and HP's Distributed Object Management Facility (DOMF) ORB together into the same address space so that any messages arriving would be handled by one or the other appropriately depending on the target. Crude, yet effective. This work eventually led to HP's ORB Plus product, which included amazing multi-protocol and multi-transport support thanks in large part to the extremely brilliant minds of Keith Moore and Evan Kirshenbaum, and then later led to IONA's Adaptive Runtime Technology (ART) which supports even greater flexibility and dynamic pluggability. ART is of course what underlies our Orbix and Artix products.

As part of Middleware 2004 we're hosting a workshop on reflective and adaptive middleware. As the CFP states:

Most of the middleware used and developed today is characterised by its inflexibility in adapting to different target environments and application areas. This lack of adaptability usually comes from the fact that middleware is traditionally built as a single monolithic entity. This inflexibility usually can be characterised by either the inability to adapt the behaviour of the platform, the inability to adapt its structure, or even both.

Sad but true. Inflexible middleware is ultimately useless, creating many more problems than it solves.

Important dates for this workshop are as follows:

• Paper, poster, and demo submission: Saturday, July 10, 2004
• Acceptance notification: Tuesday, August 10, 2004
• Camera-ready-copy of papers and posters: Wednesday, September 1, 2004
• Workshop: Tuesday, October 19, 2004

Check the full CFP for details.

The CFP explicitly mentions researchers, but as always, I would like to see some submissions from other industry types like myself. You know, some write-ups of real-life, working-today-in-production adaptive and reflective middleware systems. I know they're out there.

Maybe I'll submit something about my work on CORBA reflection, which is implemented in Orbix 6. I'm still progressing the work toward OMG standardization, and will be presenting on it further at the June OMG technical meeting.