Impedance mismatch 2.0

BouvetOne 2010-01-28

Lars Marius Garshol, <larsga@bouvet.no>

Impedance mismatch 1.0

• Objects and relations have different structures– causes lots of extra development work– a well-understood problem today

?

Java objects Tables

Impedance mismatch 2.0

• Objects and semantic technologies have the same issue– this is not well understood, however...

?

And the solution is...?

• I don’t suggest that I have it– what I am suggesting is that we need to think

more seriously about this problem

• This talk sketches some approaches– I would be very interested in feedback on

them

Some important concerns

• Whipuptitude– how easy it is to get something up and running

• Manipulexity– how complicated data/interface you can handle

• Knowledge of TMs– is it possible to shield some developers from

TMs?

• Testability– how easy is it to do automated testing?

• Flexibility– how hard is it to change the application?

The one-layer approach

• Write lots of JSPs– put your queries in the JSPs– off you go

• Messy, but effective– high whipuptitude, but brittle– limited manipulexity– usually lots of boilerplate code

• Difficult to test

JSP

JSP

JSP

Write a domain model

• Write a domain model– put as much business logic as possible inside– hide all Topic Maps queries in it– then build JSPs as a thin layer on top

• Scales to higher manipulexity– much easier to test

JSP

JSP

JSP

Domain model

public class Person { public String getName(); public String getEmail(); public Date getDateOfBirth(); // ...}

But...

• Very low whipuptitude– takes a while to figure out how to approach

writing this code– lots of scaffolding to do before you get started

• Wasn’t one of the benefits of TMs flexibility?– now any ontology change has to be followed

by an update to the domain model– this is slow and a lot of work– compared to an RDBMS and an OR-mapper, is

this really any faster?

Generate a domain model

• Use a tool that generates the model– obviously, it must allow custom extensions– saves effort by avoiding most of the routine

work– business logic still has to be written manually

• Scales to even higher manipulexity– whipuptitude no longer quite so bad

JSP

JSP

JSP

Generated domain model

Custom code

http://www.networkedplanet.com/ontopic/2007/07/topic_map_objects_research_pap.html

To make this work...

• Use schema + annotations as input– also conventions instead of config, where

possible– allow ontology annotations to provide

additional generated business logic, where possible• (.NET allows partial classes, avoiding subclassing)

• Generated code not to be edited– all custom logic in separate subclasses

• Might be able to use tolog rules to implement some of the business logic without Java

A portlet approach

• Use generic components for display– at least as far as possible– these rely on configuration and ontology

annotation– note: components reflect interface, not the

domain

• Enormous whipuptitude– manipulexity probably limited

JSP

JSP

JSP

TreePortlet

RelatedTopics

TopicList

Ontology changes

• All applications have some ontology expectations– however, using a generic approach these can

be minimized– sometimes to the point where no code

changes are required for certain ontology changes

• However, this requires the use of generic components– usually also requires some forethought– with a traditional domain model this is not

really possible

Evaluationwhipuptitude

manipulexity

One-layerapproach

Self-written domain model

Genericportlets

Generated domain model

But what do you think?

• Would any of these approaches really solve the problem?

• Do we need more?• Do we need something entirely

different?