Middleware Matters

It was a good interview Steve. Your analysis on the switch from mostly mainstream to the embedded market regarding CORBA's acceptance is true and i personnally liked your thoughts around reflexion and the interface repository.

Steve,

I very much enjoyed listening to your interview. I like your pointed, no-nonsense style of communicating.

I continue to be perplexed as to why the language bindings aren't being updated as C++ and Java mature. (I've previously posted some comments here: http://www.orbzone.org/?p=100#more-100) Legacy code can be dealt with by using options to turn off new features. but then developers choosing to use the new features can if they want. I would think IONA would have some real influence given that they are one of the largest ORB vendors out there!

I also wonder why CORBA's binary streams are immediately labeled as brittle or hard to version and maintain compared to XML. With your new reflection API or even with the Interface Repository approach, the streams can be parsed dynamically with a "Just in Time Parser" based on the interface definition. The scripting language bindings such as Combat do this already. In fact, Combat's mappings of structs and Value Object to lists of name/value pairs allows structs to grow over time without any changes to the consuming code, just as with XML. If the parameter name is changed or removed things break, but that applies to XML as well. A more general dynamic parser might work like Java's RMI serialization scheme where new parameters are ignored if they don't exist in the local class and default values are used if the parameter isn't found.

Of course, one advantage of using the new CORBA reflection approach is that the data definition is guaranteed to be consistent with the serialized data. The IR doesn't seem to support versioning very well and if the interface definition is cached by the consumer (client or server) then they have to be told to flush their cache or be restarted. (It'd be nice if versioning was supported more explicitly by the IR.)

Hi Rob, thanks for the comments and compliments.

The non-changing language mappings are due to multiple factors, not the least of which is the fact that enterprise customers don't seem interested in such changes. This is because most of their applications are already written and in production, and any new ones are written by CORBA veterans who have no issues with using the mappings as they currently stand. Therefore there are no business incentives for vendors like us to make such language mapping changes, which BTW are extremely technically hard to do and quite expensive as they ripple through everything from the IDL compiler to the ORB runtime and services. I've been saying for years that changes in language mappings should be driven by the real-time/embedded communities, since they're primarily the ones writing new applications. Several starts along these lines have occurred within the OMG, but they always peter out because of the sheer size of the task.

As for CORBA reflection, yes, it does open some new possibilities. Unfortunately, though, the mindset of the typical CORBA programmer doesn't seem geared to making use of the new reflection capabilities, assuming the ORB provides them. And yes, Orbix does provide them, of course. :-) Yet, even if you go out of your way to use more dynamic approaches for dealing with type evolution of parameters and return types, brittleness still exists because the rules for how given CDR messages need to look on the wire don't give much, if any, wiggle room for versioning or evolution of messages. There's even brittleness inherent in the fact that you need an ORB, which is not a trivial piece of infrastructure no matter what language it's written in, on both sides of the wire.

Generally, SOA-oriented systems often take a "language first" approach to make the developers' lives easier, counting on tooling to generate interfaces, messages, etc. and thus hide "all that hard stuff," which ultimately means that what might seem like an innocuous tweak by the developer at the language level turns into large changes in interfaces or on the wire, which in turn makes graceful and independent evolution of clients and services virtually impossible. These kinds of issues are what has led to a more "message first" style of development with approaches like REST that treat distribution as something to be directly considered and dealt with rather than something to be hidden. See my latest IC column for more info:

http://www.iona.com/hyplan/vinoski/pdfs/IEEE-REST_Eye_for_the_SOA_Guy.pdf

Hi Steve,

Thanks for the great reply.

In regards to the language bindings, I understand that a lot of legacy code/services depends on the old bindings, but with flags to turn on the new bindings if desired, the old code wouldn't have to change (similar to how Sun has dealt with adding new keywords to the Java language without breaking old code.) The CDR representation of the data would be the same when old and new services communicated with each other so the new bindings wouldn't prevent communication with already deployed services as well. The only down side I see is that the vendors/open source developers have to support two different approaches of code generation, but the new bindings might also sell more product by attracting new developers.

I like the way ZeroC has allowed developers to choose the type-safe Java collection sequences are mapped to in the Slice definition. (It is nice to have a hashmap/dictionary as well.) It would be great to leverage the Java enumerations rather than the CORBA-specific ones. (It might be nice to get rid of the ugly "_" delimited naming convention rather than the typical camelCase naming convention for Java. IDL with _ could be automagically translated into camelCase for Java if desired.) If EJB can radically evolve as the language changes and new design patterns have been learned, why can't CORBA?

In regards to the versioning issues with CDR, I believe that with CORBA reflection support that versioning might not have to be directly supported by the CDR since the interface and data stream are guaranteed to be at the same version.

With XML communication, the raw XML might be converted into an intermediate DOM object and then the desired data might be extracted from the object and mapped to Java objects. Missing data would need to use default values. (This may occur when services expecting a new version of the XML document received an old version of the document.)

A similar approach could be used for binary streams as well. For instance a nested "struct" data structure could be mapped into a hashmap of hashmaps or even a DOM object that would be used as a sort of parse tree. Then the generated parser would extract the info it needed by name from the parse tree perhaps even using XML style processing such as XPATH and such. Of course, the performance of the parsing would be worse than the typical stream parsing, but it might be less susceptible to versioning issues when new variables are added to a struct (or Value object) for instance. (Extra data would be ignored.)

As I mentioned earlier, this doesn't solve the case where the data structure is radically refactored (deleted fields, renamed fields, moved fields, etc.), but I don't believe an XML-based approach can deal with that either. Code still breaks if required variables don't exist at the expected location.

With the document based approach developers can create custom logic that deals with each version of a document on a case by case basis. But the pain has just been moved down into the application code then.

A similar approach could be done with CORBA by using DII/DSI combined with the interface description or by embedding a version identitifier as the first element of every data structure. BTW, IDL already supports version identifiers through the pragma mechanism (usually 1.0 right now), why isn't that feature being further developed? For instance, perhaps the IR should be enhanced to store multiple versions of an interface or data structure with the same names, but different versions.

With versioning better supported, high performance stream parsers could be generated in the static stubs for every version and then there would be logic to switch parsers based on version identifier. New versioned objects might use inheritance or interface implementation to handle the new data fields and provide a backward compatible interface for old code.

Thanks,

Rob