“Here be Dragons”…

23 June 2010, 11:24 AM   |  

In “andere tijden” van de cartografie schreef men “Here Be Dragons” in nog niet goed in kaart gebrachte gebieden. In meerdere opzichten geld die term nu ook nog voor het domein ‘interoperabiliteit’. Veel verhalen, veel meningen, veel inzichten. Een aantal ‘ontdekkingsreizigers’ doen verhaal van hun ervaringen en maken het soms dramatischer dan de werkelijkheid.

image image

In de praktijk ervaren we als “digital native” dagelijks ‘ongemerkt’ vele vormen van uitwisseling van informatie en ervaren we ‘gemerkt’ soms een aantal drempels. Software applicaties kennen verschillende middelen om informatie uit te wisselen en interoperabiliteit te bieden. in hoofdlijnen zijn de belangrijkste drie:

  • Application Programming Interface (API)
  • Protocol
  • Formaat

 image

In een vereenvoudigde representatie zou je kunnen zeggen dat de ieder van deze drie middelen een eigen verbijzondering van interoperabiliteit kan bieden:

  • API – functionele interoperabiliteit
  • Protocol – transactionele interoperabiliteit
  • Formaat – informatie interoperabiliteit

Via een API kan een applicatie van extra functionaliteit worden voorzien. Bijvoorbeeld functies die niet door de oorspronkelijke ontwikkelaar/uitgever zijn voorzien. Bekende voorbeelden zijn de APIs van Microsoft Windows en Microsoft Office. Succesvol toegepast door een zeer groot aantal ondernemingen en individuele ontwikkelaars voor eigen toepassingen en uitbreidingen.

Middels een protocol kunnen applicaties synchroon interactief informatie uitwisselen.  Bekende voorbeelden zijn HTTP voor uitwisseling van informatie via internet ‘browsers’.

Formaten zijn in feite de representatie van informatie. Voor opslag en/of transport. Bekende voorbeelden  zijn het binaire bestandsformaat voor Microsoft Office (de bekende: doc, xls, en ppt bestanden), en HTML voor world wide web pagina’s.

image

De broncode van een software applicatie kan ook de basis zijn voor het realiseren van interoperabiliteit. Maar de API, protocol en formaat middelen bieden een laagdrempeliger, goedkoper en beheersbaardere mogelijkheid voor interoperabiliteit. Interoperabiliteit via (of afhankelijk van) inzicht en het aanpassen van broncode is de meest kostbare vorm van interoperabiliteit. Je kunt je voorstellen hoe onpraktisch, tijdrovend en foutgevoelig het zou zijn om voor interoperabiliteit tussen web browsers afhankelijk te zijn van de broncode van die browsers.

Voor de API, protocol en formaat geldt een spectrum aan mogelijkheden voor het gebruik van deze middelen. Van volledig voorbehouden aan de eigenaar/ontwikkelaar van de software toepassing (gesloten), of volledig open en zelfs zonder beheer (“free”).

image

Daartussenin liggen voor interoperabiliteit de meest interessante opties. Voor de meeste API’s (interfaces), protocollen en formaten geldt dat ze gepubliceerd worden in een handleiding, of onder betaalde of gratis licentie worden aangeboden. Een aantal wordt gepubliceerd voor vrij gebruik door iedereen (open of vrije specificatie) zonder dat daar een licentie voor nodig is. En een aantal API’s, protocollen en formaten zijn “open standaard” waardoor er onafhankelijkheid is in de ontwikkeling.

Iedere kolom in het spectrum heeft eigen consequenties, voor- en nadelen. In de praktijk is het niet zo dat één kolom andere verdringt, ze vullen elkaar aan. De gebruiker, ontwikkelaar, en de bedenker van de interface, protocol of het formaat hebben keuzes en afwegingen te maken. Die afwegingen hebben te maken met factoren zoals beschikbaarheid, kwaliteit, functionaliteit, adoptie, gebruik, dynamiek van/in het domein en meer.

Broncode is duidelijk niet de eerste keuze voor het bereiken van interoperabiliteit. Maar broncode is wel in diverse opzichten relevant. Eén blik op dat onderwerp is wat men met de broncode zou willen kunnen. Wederom is daar keuze voor zowel de gebruiker, ontwikkelaar, en de bedenkers van de software toepassing.

image

Het spectrum voor broncode loopt hier van een behoefte tot het gebruik van het eindresultaat (de software applicatie zelf) tot en met een behoefte om de broncode te mogen aanpassen en door ontwikkelen naar eigen inzicht. Software applicaties die onder een ‘gebruiks recht’ worden aangeboden kunnen ook voorzien worden van een recht op ‘inzage’ of ‘verificatie’ van de broncode. Bij applicaties die onder een ‘hergebruiks recht’ worden aangeboden is het verifiëren en de inzage al mogelijk.

Het participeren in de ontwikkeling van de ‘originele’ broncode is niet per definitie “licentie” of model afhankelijk. Vormen van participatie in ontwikkeling kunnen ingericht worden onafhankelijk van de licentie die van toepassing wordt verklaard op de uiteindelijke code onder een software toepassing.

En let ook op dat voor het aanpassen van functionaliteit in een software toepassing, de eerder genoemde Application Programming Interfaces een “beheerste” manier vormen. Voor het uitbreiden, of aanpassen van functionaliteit in een toepassing is niet per definitie toegang tot de orginele broncode noodzakelijk. Software configuratie, opties en API’s zijn daar eveneens ‘beheersbare’ middelen voor.

DUS…

Waar ik over het algemeen een vrolijke dag van krijg zijn de discussies over gesloten software versus open software. Prima, leuk tijdverdrijf, maar in veel gevallen onderschat men de openheid van veronderstelde ‘gesloten software’ en de geslotenheid van veronderstelde ‘open software’. En het bovenstaande kan voor deskundigen lijken op een ‘over simplificatie’, maar dat gaat vele malen meer op voor veel de inhoud van veel  van de ‘versus’ discussies.

Bovenstaande kreeg ik niet goed onder woorden binnen 140 tekens in een reactie op twitter, maar voel je vrij te interacteren :-)

twitter.com/hansbos

Terug
Reacties

Reacties:

23 June, 2010 11:39 AM

PingBack vanaf  Twitter Trackbacks for                 ???Here be Dragons?????? - voortgang         [microsoft.nl]        on Topsy.com

23 June, 2010 11:40 AM

Behalve de drie genoemde middelen van interoperabiliteit, zou je misschien nog een vierde kunnen benoemen, interoperabiliteit via de gedeelde data laag. Een applicatie slaat gegevens op en leest deze uit een database. In de meeste gevallen niet aan te bevelen maar wel vaak toegepast: gebruik de API van de database (voor het gemak: SQL), voeg gegevens toe/modificeer deze en voila, ook een vorm van interoperabiliteit.

PS. die Captcha's worden steeds moeilijker.

23 June, 2010 1:55 PM

@Sandor: Ik herken wat je zegt. maar is het inderdaad een vierde middel, of is het een architectuur invulling?

Je gebruikt een API, protocol of formaat voor uitwisseling tussen applicatie A en B. In de situatie van een gedeelde (tussen)laag gaat het om A<->X<->B. Dat is prima. De drie middelen adresseren het '<->' stukje. Een gedeelde laag is een toepassing/applicatie op zich en voegt functionele mogelijkheden toe en je beperkt het aantal koppelvlakken.

Je zou zo ver kunnen gaan dat het standaardiseren op zo'n gedeelde laag, zal leiden tot een verminderde afhankelijkheid van interoperabiliteits oplossingen... maar je voelt dan ook al een ander/nieuw te bediscussieren probleem opkomen denk ik ;-)

Groeten,

Hans Bos

Vernon
30 September, 2010 10:36 AM

Hallo Hans,

Ik snap niet helemaal waarom een API in bijv. Windows gezien wordt als een uitbreiding van het systeem, terwijl ik bij programmeertalen als PHP heb geleerd dat een API juist een deel van het oorspronkelijke programma is, waarmee andere programmeurs het programma kunnen uitbreiden.

Oftewel: Is het zo dat bij Windows de uitbreiding een API genoemd wordt, en bij PHP de verbinding tussen de uitbreiding en het oorspronkelijke programma?

Groeten,

Vernon

30 September, 2010 12:21 PM

Hi Vernon,

Een API is inderdaad een mogelijkheid tot uitbreiden van het systeem (of toepassing). En hoewel er misschien een grijs gebied is voor externe API's bij 'gedeelde bibliotheken' (denk bijv aan de DLL's), zijn API's inderdaad onderdeel van (of worden aangeboden door) het oorspronkelijke programma.

En door deze rol van een API, is het een middel voor interoperabiliteit tussen software programma's.

Groeten,

Hans

Wat denk jij?

(Verplicht )  
(Optioneel )
(Verplicht )