More on Object-XML and Object-Relational Impedance Mismatch

In a very early (late 1950's) avatar, I was a studio and transmitter engineer for Berkeley's listener-sponsored FM station, KPFA and later majored in electrical engineering at UC Berkeley. Thus my initial reaction to the term "impedance mismatch" was from the audio and RF environments where mismatches cause serious problems, such as standing waves in antenna transmission lines. The advent of object-oriented programming has added a new meaning to the term. Wikipedia's Object-SQL Impedance Mismatch topic and Scott Ambler's The Object-Relational Impedance Mismatch essay provide an introduction to the usage in object/relational mapping (O/RM) scenarios. Dare Obasanjo's The Impedence Mismatch between W3C XML Schema and the CLR post discusses XML serialization of object state and conversion of XML to objects. The latter topic includes a reference to Programming with Circles, Triangles and Rectangles by Erik Meijer, et al. Following are additional links to other posts about impedance mismatch between objects, XML documents, and relational data from the CORBA, Java and LINQ perspective: Middleware Matters: Obsessed with the impedance mismatch—IONA Technologies' Steve Vinoski discusses mismatch issues between objects and XML, with a reference to COmega:

Basically, unless I'm real busy doing something else, my thoughts invariably turn to the impedance mismatch problem. I spend a fair bit of time searching for what others are doing to solve it, and I know about Comega and some of the domain-specific language ideas, but finding relevant work is hard because AFAIK there's no crisply defined category for such work.

Oracle Developer JAVA MONKEY: Advances in Java's Relationship to Data—Rene Bonvanie discusses "Understanding new and existing features of J2EE and EJB for working with data" and quantifies the programming effort to overcome impedance mismatch between objects and relational data:

With the ease of use associated with JDBC and SQLJ, however, comes what is frequently called impedance mismatch. Both cater directly to the relational database—working in rows and columns. Java, on the other hand, is naturally object-oriented and is designed to help developers think in classes and business objects. Additional work, estimated as high as up to 40 percent of the initial development effort, may be spent resolving this mismatch. [Emphasis added.]

Abstraction Impedance: Hidden Barriers and Explicit Boundaries—Dion Hinchcliffe (Sphere of Influence) qualifies impedance with "abstraction" and distinguishes "structural" and "behavioral" abstraction impedance:

The premise of the LINQ project, and many others like it, is the following: Now that the object-oriented paradigm has become established as the predominate model of abstraction in software development, developers have been incurring a large amount of overhead in mapping it to other abstractions, specifically XML and relational databases. ... Abstraction impedance isn't just a developer productivity tax. It leads to subtle and pernicious defects in software, contortions of design, and severely degraded performance. All of these lead to low quality software that doesn't deliver the expected value to the customer. ... So, I find the LINQ effort to be admirable and extremely interesting and I'm eager to see how effective it is. Solving this problem well may end up being one of the bigger advances in software development this decade.

Stay tuned for additional links about the LINQ Project, O/R or O/X mapping, and impedance mismatch.

--rj

Technorati: LINQ DLinq XLinq COmega