implementaties niet volledig of niet
exact conform de specificaties zijn.
Ook zijn er soms nog onduidelijkhe
den in de specificaties of bieden de
standaarden ruimte voor interpreta
tieverschillen. Het is daardoor vaak
moeilijk zo niet onmogelijk om een
(willekeurige) cliënt direct op een wil
lekeurige service te gebruiken.
Dergelijke problemen treden voorna
melijk nog op bij de complexere speci
ficaties en/of specificaties die minder
in gebruik zijn. De problemen kunnen
daarmee vaak als kinderziektes wor
den beschouwd, maar zijn wel dusda
nig van aard dat ze volledige techni
sche interoperabiliteit in de weg staan.
Echter, door gebruik van de standaard
kunnen deze problemen gesignaleerd
worden, zodat de applicaties en stan
daarden verbeterd (volwassen) kunnen
worden. Een voorbeeld hiervan zijn de
WMS-services, die veel in gebruik zijn
en over het algemeen niet veel proble
men meer opleveren.
Er moet opgemerkt worden dat de hui
dige services vaak op zichzelf staan.
Met andere woorden: de services zijn
voor specifieke applicaties in de lucht
gebracht. Wel worden steeds vaker
client-applicaties ingezet die meerdere
services gebruiken, bijvoorbeeld om
een kaartbeeld op te bouwen met
meerdere WMS-services. Ketens van
services voor de complexere processen
zijn nog niet of nauwelijks geïmple
menteerd.
Vanuit de standaard ICT-wereld wor
den echter oplossingen aangedragen
om deze services-architectuur verder
te realiseren. Interessant om te zien is
dat het Open Geospatial Consortium
deze oplossingen steeds meer probeert
toe te passen voor de geo-webservices
(tabel 1). Daarvoor moeten de geo-web
services wel voldoen aan de eisen van
standaard webservices.
Tot voor kort was dit niet het geval, on
der andere omdat het OGC voorliep op
de standaard ICT-standaarden - voor
het 'bind'-principe bijvoorbeeld was
het SOAP-protocol nog niet beschik
baar c.q. nog niet common use. Het
OGC heeft daarom in het OWS2-initia-
tief (OGC Web Services fase 2) de door
haar ontwikkelde specificaties van
webservices geanalyseerd en sug
gesties gedaan voor aanpassingen. De
ze aanpassingen moeten ervoor zor
gen dat de webservices (kunnen) voldoen aan de SOAP en
WSDL standaarden. Op het moment van schrijven worden
de specificaties naar aanleiding van OWS2 herzien of zijn
ze al aangepast.
Tabel 1.
De verhouding
van W3C en OGC
standaarden ten
opzichte van het
publish, find, bind
principe bewerkt
voor 0WS2.
Operatie
W3C
(Industrie standaarden)
OGC
Find (Brokering)
UDDI
Registry Services
Describe
WSDL
o.a. GetCapabilities
(WSDL)
Bind (Interact)
HTTP
SOAP
HTTP
(SOAP optioneel)
Chaining/
orchestrating
BPEL (industrie
standaard)
21 Deze wijzigingen
hoeven niet direct
met OWS2 te maken
hebben. Zo is in de
nieuwste WMS spe
cificatie (WMS 1.3)
een en ander gewij
zigd met betrekking
tot de coördinaat
systemen. Deze wij
zigingen worden in
de praktijk vaak als
erg onhandig erva
ren, waardoor de
implementatie van
WMS 1.3 niet zo'n
vaart loopt, maar
wordt teruggevallen
op WMS 1.1.1.
Voor zover de nieuwe specificaties gereed zijn, zullen ze in
de praktijk nog weinig zijn geïmplementeerd. Dit heeft ook
te maken met het feit dat sommige specificaties eerder al
kleine, maar ingrijpende wijzigingen hebben ondergaan2».
Toch is het OGC binnen OWS3 al begonnen aan de volgende
stap. Een van de belangrijkste doelen binnen OWS3 is om
de services beter op elkaar aan te laten sluiten. In OWS3
zullen onder andere de volgende onderwerpen aan bod
komen:
Verfijning van de architectuur om geoprocessing ser
vices te vinden met catalog services (CS-W) en in ketens
te zetten, onder andere met behulp van de Business Pro
cessing Execution Language (BPEL).
Geo-Decision Support Services (GeoDSS). Geo-Decision
Support Services zijn bedoeld om analyses te maken
waarbij gebruik wordt gemaakt van meerdere services.
Daarvoor dienen ketens van services gedefinieerd te wor
den waarmee de analyse wordt uitgevoerd.
Geo-Digital Rights Management (GeoDRM). GeoDRM is
bedoeld om de toegangsrechten te kunnen regelen in de
bestaande geodata-services (zoals WMS en WFS).
Wanneer OWS3 succesvol wordt afgerond en de resultaten
van OWS3 worden doorgevoerd in de specificaties, moet het
mogelijk zijn om de ketens van geo-webservices echt te
gaan gebruiken. Daarbij kan dan dus ook rekening worden
gehouden met de beperkingen van rechten die op zo'n ser
vice gelden, wat voor de aanbieder van de service uiteraard
van groot belang kan zijn.
De huidige ontwikkelingen bieden grote kansen voor het
Gl-werkveld. Een aantal van deze voordelen wordt hieronder
besproken. Een belangrijk voordeel van SOA is dat data bij de
bron kan blijven. Gegevens hoeven niet meer fysiek te worden
opgenomen in de eigen omgeving. Mooi voorbeeld hiervan is
de beschikbaarstelling van de Grootschalige Basislcaart
Nederland door webservices (onder de naam Basislcaart On
Line, BKOL). Vooral voor GlS-gebruilcers (in verband met 'data-
honger', grote datasets, actualiteit) is het een belangrijke stap
om data direct bij de bron te kunnen halen. Het wordt daar
mee mogelijk om beter te kunnen voldoen aan de wensen van
GlS-gebruilcers
GEO-INFO 2005-5
Kansen Service Oriented Architecture voor
het Gl-werkveld
