Over the years I've written a fair bit about the impedance mismatch problems that crop up when mapping from one representation/abstraction to another. Perhaps all the pain of being involved in OMG language mappings for many years is what started it all. One of my first Toward Integration columns from a few years back outlined problems with mapping existing technologies straight to web services (PDF), and a Object Interconnections column from four years ago co-written with Doug Schmidt discussed why mapping CORBA straight to web services wasn't such a good idea. I also later wrote a Toward Integration column explicitly about the mapping problem. I've given talks about the problem at several conferences over the years as well.
After reading Steve Loughran's and Edmund Smith's excellent paper (PDF) about the mapping problem as it relates to JAX-RPC earlier this summer, I've been obsessed with the problem. My upcoming September/October Toward Integration column will discuss it, for example. 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.
Can you help? If you know of work going on to eliminate or overcome the impedance mismatch problem between programming languages and distributed messages, especially where XML is concerned, please drop me a line with a pointer. Please don't limit things to Java, either, and extra points for work in dynamic languages, especially Python. I'll collect and summarize here later.
Comments (2)
Hi Steve,
Here is my opinion about the x/o impedance mismatch. First, I understand by x/o impedance mismatch any mismatch between XML and OO that cannot be solved by the toolkit.
I have read the article 'Rethinking the Java SOAP stack' and I have to say that I don't agree with some of the mismatches:
1) XML->clases. (x->o) They give a pattern restriction example. However, a toolkit can perfectly support pattern checking for value compliance (inside the class construct or in the setter method).
4) unportable types -> (o->x) regarding Hashtable, I agree. Regarding datetime, the workaround is to put the time in UTC, so where is the problem?
8) mixing of XML and serialized data in JAX-RPC -> I would like to see a real situation where this can occur.
Regarding C-omega, I read "programming with Rectangles,trianges and Circles, and I didn't find many issues that cannot be solved by the toolkit:
1) Edge-labelled vs. Node-labelled. -> I don't understand this mismatch. I don't agree that an xml element is always a type. I would better say that an xml element has associated a type. For example, in .. x has associated type int, but x is not a type itself (you can reference Point, but you can't reference element x from another element). Similarly, in object-oriented languages class Point {int x, int y} x has associated type int.
2) Attributes versus elements. -> I don't agree. The toolkit can define define classes with booleans that indicate if the class attributes are xml attributes or not.
3) Elements versus complex and simple types. -> I don't agree. (note that I have named Point elements) is perfectly mapeable to class Line{ Point p1; Point p2}
4) Multiple occurrences of the same child element. -> I don't agree. A toolkit could generate a class that manages this situation.
5) Substitution groups vs derivation and the closed world assumption. -> They say "At first glance simple types seem to correspond to primitive types in Java or C#... primitive types in most object-oriented languages are sealed (final), and cannot be further specialized" I don't agree. Why is not possible to define wrapper classes for primitive types?
6)Namespaces, namespaces as values. -> They say " For instance in C# or Java field names are never qualified." Why would you need namespaces is fields?
7) Occurence constraints part of container instead of type. -> I don't agree. Why can't a toolkit generate a class with a counter of array elements and check for the max limit?
8) Mixed content. I don't agree. A toolkit can maintain a list of content.
In summary, many of the issues they say are mismatches IMHO aren't not.
Best regards,
-Enric Jaen Villoldo
Posted by Enric Jaen Villoldo | August 26, 2005 11:40 AM
Posted on August 26, 2005 11:40
I've been aware of the kind of impedance match that you mention, although I don't work in the regime that has your attention. It also comes up for me in cases of metaphor shear and also in examples of incoherence in distributed systems.
I think this case is about needing to know the external abstraction that must be preserved. Going from one level of representation to another, without knowing the external, invariant abstraction and the contstraints that were chosen for maintaining fidelity in the first representation, it is difficult to know what an abstraction/constraint-preserving re-representation will be.
Does that sound like what you are running into? I'm at work in how this can be conveyed in pattern work as part of assuring conceptual integrity, but don't have much to offer on the web just yet. I'm not sure whether the work I will be doing over the next 3 weeks as part of a dissertation crunch will be useful to you or not. There's a weak hint of my focus at TROSTing: System Lifecycle Collisions, <http://TROSTing.org/info/2005/08/i050801c.htm >.
Posted by orcmid | August 26, 2005 2:51 PM
Posted on August 26, 2005 14:51