icon blogAltijd iets te leren

Adoptie van (open) standaarden

03-09-2012 door Jan Fluitsma

De tijd dat voor elke toepassing binnen een bedrijf een stand-alone (stove-pipe) oplossing wordt gemaakt ligt allang achter ons. Ook gebruik van grote totaaloplossingen welke dusdanig aan de eigen omgeving werden aangepast dat het uiteindelijk nog net zo duur is als zelf bouwen ligt achter ons.

Adoptie van (open) standaarden

Nu wordt veel meer gebruik gemaakt van kleinere brokken functionaliteit (services) welke alleen nog naar eigen inzicht aan elkaar worden geknoopt middels BPM en ESB oplossingen. Dit wordt mede mogelijk gemaakt door standaardisatie, met name voor de integratie van deze functionaliteit.

De vraag is: Wordt hier wel optimaal gebruik van gemaakt?

De mens is slecht in het accepteren van consequenties of nadelen van een beslissing. We zien dat in het dagelijkse leven, maar ook in de ICT.

Dit was al het geval bij de eerder genoemde totaaloplossingen, pakket X werd aangeschaft maar vervolgens moest er voor veel geld en tijd worden verbouwd, omdat we niet met de beperkingen van het pakket wensten om te gaan.

 

Voorbeeld 1; XML en XML-Schema standaarden

Hetzelfde hebben we gezien bij de introductie van XML als berichtformaat. Bij een keuze voor XML kies je inherent voor alle mogelijkheden die de standaard je biedt en beperkingen die de standaard je oplegt. Wat we veel zagen gebeuren is dat er 'eigen' XML-parsers werden geschreven. Maar hier werd helemaal niet naar de standaard gekeken waardoor deze 'parsers' niet aan de standaard voldeden. Menig 'parser' op een mainframe kon alle berichten in EBCDIC aan terwijl de standaard ondersteuning van zowel utf-8 als utf-16 voorschrijft. Ook character-references (&, &#20ac;) werden niet of slechts beperkt ondersteund, om over namespaced nog maar te zwijgen.

Problemen ontstaan als één van beide partijen wel met een XML-parser gaat werken of zelfs XML-schema gebruikt en ook controleert. De gegenereerde XML kan er opeens anders uit gaan zien, bijvoorbeeld doordat namespace prefixen worden gegenereerd terwijl de ontvanger van een vaste namespace prefix uit gaat (ze kijken niet naar element 'X' in namespace 'Y' maar naar element 'prefixY:X'). Of berichten die de verzender maakt voldoen niet aan het schema en worden opeens niet meer geaccepteerd door de ontvanger.

Juist doordat steeds meer XML-parsers met XML-schemacontrole beschikbaar komen (zelfs in cobol), komen ook de problemen steeds vaker voor. Recentelijk zien we dit in bijvoorbeeld de WebSphere Mesage Broker waar twee oud XML-formaten moet worden vervangen door een volledige XML-parser met schemacontrole. Gevolg is dat ook aanleverende en/of afnemende applicaties moeten worden gewijzigd omdat zij zich niet aan XML of het schema houden.

 

Voorbeeld 2; SOAP Standaard

SOAP wordt steeds meer gebruikt en ondersteund. Voordeel van gebruik van SOAP is dat dit ten eerste is losgekoppeld van de fysieke communicatie maar ook dat afhandeling en er mee omgaan wordt opgelost door applicaties, zover dat SOAP zelf ook intern in applicaties wordt gebruikt.

SOAP beschrijft niet alleen hoe gecommuniceerd wordt maar ook hoe foutafhandeling eruitziet. Toch zien we regelmatig dat de foutafhandeling niet wordt geaccepteerd en dat een eigen manier van foutafhandeling wordt voorgeschreven. Hieraan kleven wat problemen.

Ten eerste wordt een groot deel van SOAP afgehandeld vóór de controle aan een applicatie wordt gegeven. Als in deze afhandeling een fout ontstaat wordt er een SOAPFault teruggestuurd, hier is niks aan te doen.

Als er vanuit een aangeroepen service een fout wordt geretourneerd, als SOAPFault of ook weer een eigen manier, dan is enige vorm van transformatie nodig welke tot verlies van informatie kan leiden.

En wordt er gebruik gemaakt van bijvoorbeeld een BPM-laag die intern op SOAPFaults reageert, dan zal de eigen fout eerst moeten worden omgezet in een SOAPFault om uiteindelijk weer naar een eigen fout te moeten worden omgezet. En dan hopen dat dit op de juiste plaats kan worden ingevoegd.

Toepassen van standaarden zou een stuk makkelijker en goedkoper worden als de consequenties van invoering van de standaard goed wordt overwogen en een organisatie de standaard als geheel accepteert, inclusief de nadelen.

Dit is uiteraard geen garantie dat alles werkt. Als dan nog blijkt dat out-of-the-box ondersteuning zich niet aan de standaard conformeert dan kan de leverancier hierop worden aangesproken.