Middleware Matters

I just finished my paper for the ICEIS Web Services Workshop, for which I'll be delivering the keynote address. There seems to be a new rule (new to me, anyway) for some of these conferences and workshops where the keynote speaker is expected to submit a paper. What's worse is when they invite you to give a keynote, and then after you've accepted, they inform you that you're expected to submit a paper. I've already been fooled twice in this manner, so shame on me!

The paper is about extending WSDL with bindings for things other than SOAP -- things like MQ Series, CORBA, Tuxedo, TIBCO, JMS. Such extensions allow applications written on these different middleware systems to interconnect fairly seamlessly, with WSDL providing the unifying abstraction, and sophisticated middleware doing the actual integration underneath. In our case, the sophisticated middleware is our Artix product, and there's really nothing else like it in the industry.

Artix allows you to non-invasively turn existing applications hosted on middleware systems like those mentioned above into web services accessible over their native protocols and network data transfer formats. Artix performs any conversions needed to switch messages from one protocol/format combination to another, but without using EAI-like canonical protocols and formats in the middle. Canonical == slow, so we don't go there.

If OTOH you don't mind modifying the application, you can rehost it on top of Artix, turning it into a multi-protocol service that can handle messages over multiple protocols simultaneously, transparently to your business logic. Artix dynamically loads the necessary functionality for handling each different protocol and transfer format as needed. Applications like this are easy to integrate, because they effectively speak multiple languages and don't need a translator in the middle.

At the heart of Artix is ART -- IONA's Adaptive Runtime Technology. I joined IONA in 1996 specifically to create ART. We've been shipping ART-based products since 2000, starting with what was then called Orbix 2000, now called Orbix 6.1. We've used ART to implement products for CORBA, products for J2EE, and multiple Web Services products, including Artix. ART is essentially a very fast and very flexible distributed computing engine that implements patterns common to distributed middleware infrastructures. In ART, virtually everything is an interceptor. Messages are processed by chains of interceptors, and interceptors can be dynamically loaded on the fly as needed. We've implemented ART in both Java and in C++.

If this sort of system appeals to you, feel free to visit our Artix Tech Zone, where you can download a free Artix developer's kit.

Oh, BTW, don't bother asking me for the ICEIS paper just yet -- I can't really share it until it's published. However, some of the same concepts it describes are discussed in my Nov/Dec 2003 Internet Computing column.

As noted in our Call for Papers (CFP), Doug Lea and I are co-guest-editing six special issues of IEEE Internet Computing this year on the general topic of middleware.

Unfortunately, when we issued our CFP, we didn't make our deadlines terribly clear. We hoped to get all submissions in by May, giving us time to work with the authors of selected submissions to get them into shape for publication over the course of the year, so we put May as the deadline. In reality, we have deadlines that are generally about two months prior to each issue's publication. It now seems that everyone is just waiting for the May deadline to get something to us, which admittedly has left us scrambling a bit for the upcoming May/June issue.

If you're planning to submit something, please do so anytime, starting now! If you'd like to submit something but don't think you can meet the May deadline, email me or Doug (or both) and let us know what topic you're thinking of writing about and when you can get your submission to us. We'll be happy to work with you.

I hate to ask, but if you've emailed me anytime since last Friday evening March 5, please resend your message. I know I received several messages related to the various conferences I'm involved in, but before I could answer they disappeared due to a major Exchange meltdown here over the weekend. Thanks!

My latest IEEE Internet Computing "Toward Integration" column, entitled "Web Services Notifications," which Werner recently alluded to in his blog entry on the same topic, has now been published. You can either get the PDF from the IC website, or get my version of the PDF from my home page.

This column compares, contrasts, and discusses WS-Addressing, WS-Events, and WS-Eventing. Despite the title of the column, it was written before WS-Notification was announced (maybe I'll cover that one in a future column). Overall, I think they're decent specs, but that shouldn't be too surprising given that we should be well past the stage of needing to reinvent the wheel in the events/notification space.

As always, comments and feedback welcome.

Over this past weekend, my son Ryan and I competed together in the New England Indoor Freestyle Championships, and managed to take 4th place. Ryan is 19, soon to be 20, and he played exceptionally well. Unfortunately, I played only so-so, otherwise I think we could have placed higher. This was only our second tournament together.

If you're not familiar with frisbee freestyle, or, more generally, flying disc freestyle, it's somewhat hard to explain verbally or in written form. A picture or video (Windows Media format) really is worth a thousand words in this case. Freestyle, or "jamming" as we call it, is basically throw-and-catch, but the players stand only 10-20 feet apart and throw the disc with as much spin as possible. The spin allows the catcher to "delay" the disc by spinning it on his or her fingernail. The delayed disc can be manipulated by passing it under the legs, pulling it around the body, tipping it, turning it over, rolling it across the chest or back, or an endless variety of combinations of all these moves and more, all leading to an eventual catch. I've been involved in sports all my life, and this one is by far the most challenging one I know of. In competition, players are judged by their peers on difficulty, execution, variety, and presentation. Dropping the disc results in deductions.

The winners of the tournament were Carlos "Pipo" Lopez, from Carolina, Puerto Rico, who's currently ranked 14th in the world, and Toddy Brodeur, from Bellingham, MA, currently ranked 18th.

We had a blast, basically jamming almost non-stop from 10:30am until 6pm. Many thanks to Rick Williams for putting the whole tournament together.

On Thursday, March 18, I will presenting a webcast entitled Building Out from CORBA: Extending CORBA to .NET, MQ, Tuxedo, TIBCO, and JMS. The webcast begins at 1pm EST.

There is no doubt that CORBA is a success -- there are many mission-critical CORBA applications out there, and they're not going away anytime soon. However, other middleware succeeded too. This has resulted in the need to integrate services implemented in different types and styles of middleware.

In this webcast I'll focus on how IONA has innovatively applied Web Services technologies and approaches on top of our rock-solid ART infrastructure to automatically harness existing CORBA systems so that they can be transparently accessed by non-CORBA systems, and so that CORBA clients can transparently access other non-CORBA middleware. In many cases, this integration can be done without modifying your CORBA applications.

If you plan to attend the webcast, please register first. See you there!

Recently I've noticed several blogs containing commentary on my most recent Toward Integration column, entitled "Web Services Notifications". It's always great to get such feedback.

Over in the Brain.Save() blog, Steve Maine questions my comments regarding WS-Eventing's reliance on WS-Addressing. Contrary to Steve's comments, I didn't explicitly say that WS-Addressing pins you down to a specific transport; in fact, I make that pretty clear in the first paragraph in the column section entitled "WS-Addressing" that it's transport independent. Later, though, where I say that WS-Eventing should use WSDL service references rather than WS-Addressing, I did imply that WS-Addressing is limited to SOAP over HTTP, and that's where Steve takes me to task. I should have simply said "SOAP" there and left it at that. What I was really trying to imply there was that WSDL is extensible well beyond just SOAP, allowing for many different types of bindings, and using WSDL service references would make all such bindings usable in a WS-Eventing context.

Steve also questions my concerns about metadata discovery, or the lack thereof, in WS-Eventing. He says that other specs such as WS-Discovery and WS-MetadataExchange provide this, so there's no need for it in WS-Eventing. Steve makes a good point, but this points out a fundamental flaw in the WS-Eventing specification: it makes no mention of its reliance on these other specs. A simple paragraph containing a brief discussion of metadata discovery containing pointers to these other specs would suffice. Turning these specs into real standards would help eliminate such hidden assumptions and their resulting lack of clarity.

Mark Baker also commented on my column. Yes, Mark, I did expect your comments! :-) One of Mark's comments was about my discussion around the difficulties of using URIs to represent some types of endpoints such as message queues. I don't disagree with Mark that you could devise a way to do it, but it's just that there's no good standardized way to do it. I mean, if worse came to worst, you could use a URI with the stringified OMG interoperable object reference format ("IOR:" followed by any number of hex digits), especially given that a single IOR can simultaneously represent any number of endpoints, regardless of the complexity of any individual endpoint being represented. But I suspect most people would not want to take that approach. Also, I dislike Mark's suggestion of setting up a service that doles out HTTP URIs to represent resources like message queues, because in a production system, it means you've got another moving part that can not only go wrong but also requires additional deployment, management, and maintenance.

Finally, some bloggers disliked what I had to say about the proprietary nature of specifications such as WS-Eventing. For example, in addition to his comments described above, Steve Maines also commented on this issue. His comments seem to imply that I believe we should go away into some standards never-never land and wait until we have designed-by-committee consensus standards around all these Web Services areas. Hardly! I hate standards bodies as much as the next guy -- probably even more than the next guy, actually, because of all the standards work I've had to do in my career. In reality, I don't fault these companies at all for pushing ahead with these specifications. Instead, I fault them for the following:

1. The heavy IP rights tied to these specifications, which makes it very unclear whether companies or individuals who are not authors can even implement them. If I go implement WS-Eventing, for example, will the authoring companies come after me for taking their IP?
2. The companies seem to intend to standardize these specs, but only when they're good and ready to do so. Meanwhile, others who want to build similar systems are stuck either wondering whether they can use the proprietary spec or whether they should write a competing one. Either way, it's bad for the industry.
3. Standards work is hard because, done properly, it clarifies, tightens, and removes ambiguities from a specification. SOAP 1.2 is a good example. Avoiding standardization just strands these specs at their current relatively low level of quality.

Over in the Centaurs Identity blog, the author seems to imply that standardization equals interoperability. Needless to say, this is false. Yes, the SOAP builders' effort were laudable and fruitful, but they succeeded because all involved were behind SOAP. For event-driven Web Services systems, we have at least two competing specs, WS-Eventing and WS-Notification (assuming WS-Events is now obsolete, since HP is a co-author of WS-Notification). Interoperability testing isn't going to help when there are multiple specs involved. Plus, there's much more to a standard than just interoperability, including APIs and features.

I'm currently in the middle of writing my next column, this time covering WS-Notification, which wasn't out yet when I wrote my previous column. So far I'm pleasantly surprised -- it's got a nice and complete set of features for event-driven systems, the specs are well-written, and all the dependencies between the specs and on other specs are clearly defined. Stay tuned.

More feedback on my comments around standardizing the WS-* specifications. Unfortunately, the author of these comments, Fumiaki Yoshimatsu, seems to be making huge and wholly incorrect assumptions regarding my motives and opinions about standards. I will try one more time to correct these misunderstandings.

I think about standards only in terms of customers, not in terms of vendors, or in terms of standards for standards' sake. Those who know me know that I really can't stand working on standards, partially because too many "standards professionals" are so far removed from actual customers that it's hard to hold fruitful conversations with them.

As Sean McGrath already succinctly and correctly pointed out in response to one of my earlier blog postings, users, not vendors, drive standards. To this end, however, customers often ask their vendors to help drive standards for them. Right now, for example, I'm working on three separate OMG standardization requests from customers, one involving CORBA reflection, one involving WSDL bindings for CORBA, and one involving a C++ mapping for WSDL. Our customers have demanded standards in these areas, so we're working to provide them.

About two years ago IONA hosted 30 or so of the SOAPbuilders here in Boston for an interoperability testing gathering. Why? Because our users were using our tools along with those from other providers, and they wanted assurance that the various tools worked together. This is exactly the kind of user-focused standardization IONA has been involved in from the day we started in 1991.

So, I hope Centaurs Identity will stop putting words in my mouth (or in my blog, as it were) regarding standards. I can be accused of many things, but being a self-serving standards person with no attachment or understanding of the customer is certainly not one of them.

Over in the Loosely Coupled blog, Phil Wainewright shares his insight about "brownfield development." He's right on target (as usual) about the fact that Web Services projects generally involve leaving existing structures and applications in place while building around them.

Phil mentions a couple of vendors in his posting, but IMO there's no better system for "brownfield" web services development than Artix. Artix is purpose-built for brownfield development. Its innovative application of WSDL for middleware integration is unmatched in the industry.

You want to leave an existing service in place and, without touching it, make it accessible to a wide variety of callers, even if those callers are implemented on different middleware than the service? Put Artix in front of it. Artix will speak to the service using its native protocol, transport, and on-the-wire format, such that Artix appears to the service as a normal native caller. To other callers, however, Artix appears as a service that supports their own native protocols, transports, and on-the-wire formats. Artix quickly performs only those conversions necessary to get callers' messages to the service, without forcing a performance-robbing conversion to a canonical format or protocol in between. Brownfield development doesn't get any more non-invasive than that.

Artix hides these various protocols, transports, and formats behind WSDL. In effect, existing services gain WSDL descriptions without being changed in any way. No need to recompile, relink, requalify, retest, or redeploy. This approach also allows you to consolidate middleware by first wrapping an existing service and then later replacing it with a new implementation built over different middleware. Because of Artix's multi-middleware support and WSDL abstraction capabilities, your callers won't even know you replaced the service implementation.

Of course, building Artix into a new greenfield development is also possible. This allows you to build applications that can painlessly and transparently avail themselves of the numerous protocols, transports, and on-the-wire formats that Artix handles. If such an application needs to speak to a new service reachable only over some other protocol, Artix will dynamically load that new protocol on demand.

If you want to know more, download Artix and try it out for yourself. Artix was designed from day one to tackle the brownfield development inherent in Web Services systems.

First, just a reminder that the deadlines for Middleware'04 are approaching quickly. Research paper abstracts are due March 30, and full papers are due April 6.

Second, for the 2nd International Conference on Service-Oriented Computing, we've modified the call for industrial papers to make it clear that the submission and evaluation requirements for such papers are different than those for research papers. This is because we really want to encourage the submission of industry and experience papers, but it's generally hard to get industrial paper submissions because industry people normally don't have time to write full research-style papers. I've included the revised call for industrial papers below:

The conference also encourages high quality submissions covering the application of SOC in practice, including papers describing innovative service-based implementations, novel applications of service-oriented technology, and major improvements to the state-of-practice. Actual case studies from practitioners emphasizing applications, service technology, system deployment, organizational ramifications, or business impact are especially welcomed. Because industry-based authors typically create their submissions on their own time in addition to their normal responsibilities, the conference has different evaluation criteria for industrial and applications papers to ease the burden for such authors. Specifically, such submissions are expected to focus on details and issues surrounding actual implementations and applications, and they need not be as detailed regarding prior art as academic papers are expected to be. Papers submitted to the Industrial Track are also expected to be shorter than academic papers. Industrial Track submissions that do not relate to commercial software and standards, or industrial prototypes in actual use, are not encouraged. Because of these different evaluation criteria, authors must clearly indicate that their submissions are intended for the industrial track. Submissions that do not specifically indicate that they are intended for the Industrial Track will be submitted to the regular track.

So, industry folks, please consider submitting something that shows SOC at work. The submission deadline is May 28 for abstracts, June 4 for full papers.