Middleware Matters

I'm happy to report that last week in Montreal the OMG Technical Committee voted to issue the CORBA binding for WSDL RFP. This RFP calls for submissions that propose a standard way of expressing connectivity to CORBA objects for WSDL-based applications.

On a related note, Savas responded to my previous posting regarding a CORBA binding for WSDL. He makes some good points -- at least from an architecture point of view. Let me try to address each of his points.

• "In object-orientation we have objects and that suggests, to me at least, that we have state (even if we don’t see it), an interface to that state, and a reference to that state." Well, distributed objects do not imply state any more than distributed services do. I've seen plenty of stateless distributed objects in my time. An IDL interface is no more an interface to state than HTTP verbs are. And references to state? A reference to a distributed object is no more guaranteed to be a reference to state than a URI is. I must be missing something here.


• "It is my belief, though, that object-orientation (please note that I am separating the architecture from the implementation technologies and I am concentrating on the former) is not the best model for building internet-scale applications." I wouldn't argue with that. In fact, I don't believe anything I've said or written in the recent past even implies anything to the contrary. Either way, a CORBA binding for WSDL has nothing to do with this.


• "I am not an expert in CORBA so I am ready to be corrected from heavyweights like Steve but I thought that CORBA encourages an architecture that is object-oriented in nature. It encourages the creation of distributed applications where the abstractions are the objects and the way of 'communication' is the method invocation (again, I am talking about architecture abstractions and not implementation details)." True, but somewhat immaterial. CORBA method invocation is largely a programming language abstraction that allows people to write objects and applications in a syntax with which they're comfortable. On the wire, it's some headers, a target identifier, and data that's passed to the thing processing the request. That's why I talked about CORBA object "virtualness" in my last posting. But I'm not sure what Savas's point here has to do with a CORBA binding for WSDL. The fact that CORBA runs a lot of mission-critical systems out there that aren't going away anytime soon, and the fact that, for business purposes and to achieve return on investment, those systems have to be integrated with non-CORBA systems, is why creating a CORBA binding for WSDL is a good idea. Trying to analyze whether the existence of a standard CORBA binding for WSDL somehow mars or destroys some utopian uniform architecture seems like a waste of time.


• "I have no problem with describing message exchanges using WSDL and then binding those message exchanges to various underlying transports or other distributed objects technologies." Excellent! Because that's precisely what this RFP is about -- nothing more, nothing less.


• "What I am afraid of is how such bindings are going to be (mis)used when building systems that directly expose their implementation details because that will be the easy thing to do." To which I say: who cares? Try your best to prevent such misuse, and I guarantee you that someone somewhere will find a way around it and use it to create a mess. I've seen blatant disasters created in every technology I've ever worked with. No amount of worrying about architectural purity will fix this.


• "Is there anyone who doesn’t see tools emerging which will be generating CORBA objects stubs in Java from WSDL documents?" Sorry, but such tools already exist. FWIW, though, the RFP explicitly states that generating CORBA artifacts from WSDL is explicitly out of scope.

Architectural purity was not on my mind as I pushed the RFP through the OMG. Rather, I knew that CORBA bindings for WSDL have already been proven in practice to facilitate the integration of CORBA systems with other systems. From what I've seen and experienced, doing it this way works better than other approaches I've tried or seen others try.

Last week in Montreal the OMG Technical Committee voted to issue my CORBA Reflection proposal for comment. This proposal adds introspection capabilities to CORBA objects in a non-intrusive way, as I've previously explained.

I've proposed this addition using the OMG Request For Comments (RFC) process, not the Request For Proposal (RFP) process, mainly because I knew nobody else was working on anything like this, and to fast-track the work as much as possible. Overall, it's taken only nine months of standards work to get this issued, which in the standards world is very quick. I implemented this idea in Orbix 6 last summer, then published the idea in Doug Schmidt's and my "Object Interconnections" column in the C/C++ Users Journal (CUJ) last December. The proposal has been refined since then over the course of four OMG meetings, starting last November, mainly by simplifying the interface hierarchy and adding support for retrieving Interface Repository full interface description structs.

The proposal is now officially in its comment period, which lasts until October 6. Anyone, OMG member or not, may make a comment on the proposal by sending them to the OMG. All comments of substance on the proposal collected during that period will be vetted by the OMG Middleware and Related Services (MARS) Task Force to see if any constitutes a significant objection to adopting the proposal. If no such objections are received, the proposal then becomes part of the CORBA spec.

My latest "Toward Integration" column in Internet Computing is now available. This one's entitled "Is Your Middleware Dead?" It analyzes our industry's penchant for declaring everything but the latest technologies as being "dead" despite the fact that many such "dead" technologies continue to be used to drive critical systems well after their obituaries appear to have been have been written. This one's a little outside the pure technology realm, as it examines the issue from a customer perspective and a technology market perspective. The link above is to the PDF version, or read it via the IEEE Distributed Systems Online journal.

Earlier this week, an opinion piece I wrote was published on the Loosely Coupled site, which is a great source of information about architectures, approaches, and products in the middleware and integration space. The article, entitled "CORBA In a Loosely Coupled World," discusses how existing CORBA applications can be successfully integrated into the larger enterprise via CORBA bindings for WSDL. Many thanks to Phil Wainewright for publishing the article on his site.

Awhile back I wrote about how I added the ability to plug my iPod into the factory CD changer in my Honda Accord. Unfortunately, that wasn't the end of the story. I kept running into noise problems -- I was hearing alternator whine through the sound system, which increased in volume and frequency at highway speeds, and a low-level buzzing from my cellphone charger that became intolerable when I had to increase the volume when traveling on the highway. Putting noise suppressors between the iPod and the car system did not help at all.

Fortunately, I have two things in my favor: audio has been a lifelong hobby, and I have a BSEE degree. :-) I knew that these issues were at least partially caused by ground loops. I had tried earlier to get the mobile electronics guys who were doing the installations for me to fix them, but sadly enough they didn't seem to get it. So, I learned how to take my own center console apart to reach the factory CD changer's auxiliary input. After that, it was easy. My connections go like this:

• A Soundgate SNHOND3 adapter plugs into the factory CD changer auxiliary adapter. It has no power connections, and it provides RCA jacks for input.
• A Precision Interface Electronics (PIE) EIS-ILNO noise eliminator plugs into the Soundgate adapter. This provides protection against radiated noise, such as what I was picking up from my cellphone charger. This is a passive component (i.e., no power hookup).
• A PIE LD-1 adjustable line driver plugs into the noise eliminator. This boosts the line level of my iPod (which is an old mechanical wheel model) so that it roughly matches that of the CD player and radio. It requires a 12VDC hookup.
• A Radio Shack ground loop isolator plugs into the line driver. Despite the fact that the line driver is tied into the same power and ground lines that I use to power the iPod, I was still getting noise, and this isolator eliminates it.
• A Metra NF-12 noise filter for the power hookup. This eliminates the alternator whine. I used a 12 amp filter rather than the NF-5, rated at 5 amps, because the power port in the Accord center console is rated at 10 amps. I hooked this into the power line that leads to the center console power port, then powered the LD-1 line driver off the same line.
• I use a Sik Imp to power my iPod. It's not the most sturdy thing in the world, since twisting it (as you often need to do to push it into the power port) can make it lose its connection, but plug it into the center console power port and leave it there, and you're fine. Note that since I plug this into the center console, the NF-12 cleans the power for it too.
• A simple RCA to 1/8" adapter cable runs from the iPods into the ground loop isolator. I just ran the cables out of the bottom of the center console near the front passenger seat. From there, I can easily plug it into the iPod, and then rest my iPod in one of the center drink holders.

With all this in place, there is no audible noise whatsoever. Most excellent.

By way of my brother Jim: Who could have ever imagined that one of the best heavy metal bands of all time, Iron Maiden, would receive a tribute in National Review Online? No matter where you fall within the political spectrum -- at the conservative end or at the Chris Ferris end :-), John J. Miller perfectly captures the essence of Iron Maiden in this article.

Powerslave is indeed an incredibly good album, but they've also put out two really good CDs fairly recently: Brave New World (2000) and Dance of Death (2003). Jim, my daughter Erin, and I saw them last year at the Worcester Centrum on their Dance of Death tour, and they were damn good.

And coincidentally, just as I finished writing this, the song "Journeyman" from Dance of Death came on in my iTunes random play -- cool!

I arrived in Aarhus (Bjarne's hometown) today for JAOO, my favorite conference. The trip over was so-so, primarily because I nearly missed my connection to Copenhagen in Newark due to the poor weather in Boston, and because the plane seat seemed to be extra small (and no, I haven't gained any weight lately!).

At 5pm I was out walking around in Aarhus. I was quite comfortable -- sweating a bit, even -- wearing shorts and a T-shirt. The natives were wearing long pants/trousers, sweaters, jackets, and scarves. Am I missing something?

I just finished my slides for my talk tomorrow, which is entitled, "What SOA Doesn't Stand For: Debunking the Myths of Service Orientation." In this talk I use a series of three-word phrases that all have the acronym "SOA" to discuss certain misunderstood aspects of service orientation. More on this later.

At the end of last week I returned home from JAOO. It rules! Thanks to the great presentations, great panels, great organization, great social events, and overall great fun, it remains my favorite conference.

Mark among others would be happy to know that in the SOA track and panel on the first day of the conference, we all agreed that the term "SOA" was misleading, in the sense that it's not really an architecture, but at best a set of guidelines and good approaches. I suggested using the term "service-oriented approach" or even just "service orientation" instead. The panel also largely agreed that service orientation was all about the message.

Some of the audience disliked the fact that the panel couldn't come up with a strict definition for service orientation. Actually, this is a good thing. This is basically because there's no "one size fits all" solution. Phil Wainewright said it well: "In a loosely coupled service oriented architecture, you have a choice." I would state it more strongly: you need a choice.

The panelists also largely agreed with current negative sentiment toward the WS-* specification collection, perhaps stated best by Tim Bray. Despite the need for choice as described above, I consider myself among the ranks of the dubious when it comes to these specs. Knowing what I know about standards, for example, it will take many years to iron all these specs out so that they're comprehensive, complete, complementary, and practical, even if they're somehow fast-tracked. And if they're not properly standardized, with broad, fair, and even input from across the industry, then they're proprietary -- there's no gray area here. I agree in principle with Phil that you can choose what to use, but have fun telling that to the customer who has all these specs on their vendor selection checklist.

One of the best stories I heard over beer at JAOO was from Beat regarding some bug reports about a certain town in Austria being missing from some mapping software. ;-)

Anyway, everything about JAOO was great, except for the wet walk in the rain to get to the conference dinner. So mark your calendars: JAOO will be held September 25-30 next year. Trust me, you won't want to miss it. See you there.