Interface-ontwerp (in XML)

Bij MARKOV Solutions kunt u terecht voor programmeerwerk in Perl en C, bijvoorbeeld op het gebied van XML of email verwerking. Hoewel de ervaring heel breed is, zijn er ook een paar vermeldenswaardige specialiteiten. Een daarvan is op het gebied van XML.

"XML" is een manier van lijntjes trekken op papier: hoewel voor sommigen XML als synoniem stellen aan "Open Standaard", is het op zich niets meer dan een nette manier om informatie in te schrijven. Wat er op die `lijntjes' geschreven wordt moet nog altijd worden geschreven en gepubliceerd om het tot een "Open" standaard te maken.

Er zijn erg veel alternatieve syntaxen voor XML, zoals YAML en JSON, maar bedrijven kiezen bijna altijd voor XML omdat andere bedrijven ook voor XML hebben gekozen. Het sterke punt van XML is eigenlijk niet de syntax van XML zelf, maar de standaarden die eromheen ontwikkeld zijn. Populaire standaard zijn bijvoorbeeld XML-schema's, WSDL, UDDI, SOAP en XMPP.

XML-Schema's en WSDL

XML-schema's beschrijven de structuur en inhoud van XML berichten in detail. Het is een extreem krachtige beschrijvingstaal, maar ook uitermate "inventief": de XML schema specificatie is uitzonderlijk onleesbaar en complex. Aan de andere kant is het een van de weinige beschrijvingsmechanismen van berichtenverkeer, en in ieder geval verreweg de meest bekende.

Waar de XML-schema's worden gebruikt om de structuur van berichten te definiën, wordt dat in een WSDL gecombineerd met de beschrijving van internet-diensten, meestal servers die gebruik maken van SOAP.

Zelf doen of een specialist inhuren?

Schema's en WSDL's maak je om gegevens uit te wisselen met anderen of om zelf gegevens op te slaan, vaak voor langere tijd. Deze definities hebben (horen te hebben) een veel langere levensduur dan de applicaties, omdat wijzigingen op meerdere plekken pijn doen. Alleen daarom al moet je zeer serieus en in een vroeg stadium van een project voldoende tijd steken in dit onderdeel van softwareontwikkeling.

Kunt u zelf een goed schema ontwikkelen, of haalt u daar een paar dagen een specialist bij? Probeer deze check-list van schema-kennis eens. Beweeg over "antwoord" voor een popup die de uitleg geeft.

1. Wat is het verschil tussen nillable="true" en minOccurs="0"? Antwoord

Nillable is bedoeld als expliciete "dit mist nog", terwijl minOccurs een impliciete "hebben we niet" voorstelt.

Bijvoorbeeld: als een adres "nillable" is, dan kunnen we aangegeven dat die data er eigenlijk zou moeten zijn, maar er nog niet is. Is het adres optioneel, dan mag het weggelaten worden zonder consequenties.

Vooral oudere schema's gebruiken vaak onterecht nillable. Soms wordt het gebruikt om aan te geven hoe een bericht nog meer kan worden gebruikt. Is daar de documentatie niet een betere plaats voor? De meeste mensen lezen niet voor hun plezier een XML bericht.

2. Wanneer gebruik je xsi:type en wanneer substitionGroup? Antwoord

Het substitutionGroup mechanisme is pas een jaar of acht oud, dus een aantal mensen hebben daar nog niet over gelezen. Het xsi:type mechanisme is veel ouder en wordt dus nog veel gebruikt... helaas.

Volgens de schema specificatie mag het type van elk element in een bericht via een xsi:type attribute worden veranderd in een willekeurig ander type wat op het type van dat element is gebaseerd. Denk aan de mogelijkheden voor anyType! Omdat het schema nu niet vertelt op welke plaatsen het attribute kan worden gebruikt, haalt deze feature het voornaamste doel van een schema onderuit.

Elementen met een substitionGroup kunnen op de plaats komen van het element dat expliciet genoemd wordt. Niet het type data wordt vervangen, maar het hele element. Duidelijk, eenduidig en onderhoudbaar.

3. Wat is het verschil tussen dateTime en date? Antwoord

Het antwoord zou kortweg kunnen zijn dat dateTime ook een tijdstip bevat. Maar dat is iets te simpel. Een date verwijst naar een dag: een tijdspanne, waar dateTime een een moment aangeeft.

Bij relaties zoals tijdsduur (duration) of een vervaldatum is het cruciaal om voor een dateTime te kiezen, niet simpelweg een dag. Zelfs als het moment op de dag dat het plaatsvindt niet hard vaststaat.

4. Welk type hebben elementen en attribute waarbij (per ongeluk) is is aangegeven wat verwacht wordt? Antwoord

Als geen type wordt gespecificeerd, dan wordt de default gebruikt. Bij een element is dat anyType, een eenvoudig data-element of een genest element. Oftewel: totaal onduidelijk, alles is goed.

Een attribute vraagt dan om een anySimpleType, hetgeen ook geen enkele duidelijkheid biedt over de inhoud. Bijvoorbeeld, wat betekenen spaties in het attribute?

Allemaal goed geantwoord? Dan vullen wij niets toe aan het process van de ontwikkeling van uw interfaces.

Mogelijkheden

Tientalle (vaak kostbare) applicaties stellen u instaat om een schema of WSDL bij elkaar te klikken. Naar daarin schuilt niet de complexiteit. Het moeilijkste is om een berichtenstructuur te ontwerpen die lang mee gaat, dat optimaal definieert wat wordt opgeslagen of uitgewisseld. Om dat goed voor elkaar te krijgen moet je een ervaren ontwerper inschakelen. Dat kunnen wij.

Om een goed interface te kunnen maken dient een interface-ontwerper zo vroeg mogelijk in het proces zijn werk te doen. Alleen in de allereerste fasen van de ontwikkeling kan het proces nog in de juiste richting worden bijgestuurd.

Wij hebben ook ervaring met schema-evaluatie achteraf. Meestal durven bedrijven hun specificatie dan niet meer te wijzigingen omdat de test-fase al inspanning heeft gekost. Dan gaan interfaces publiek die bol staan van de klungeligheden. Laat het u niet gebeuren!

Haal ons in huis op de eerste dag van de ontwikkeling van uw XML applicatie. Met luttele dagen aan ondersteuning voorkomt u jaren van problemen.

2011-10-10