E-learn Weblog of Willem van Valkenburg

Afgelopen donderdag ben ik samen met vele anderen bij de Surf-bijeenkomst "Over de grenzen van de ELO II" geweest. Door een spoedklus dit weekend, was ik nog niet toegekomen aan een verslag hierover. Inmiddels zijn al enkele bloggers die erover geschreven hebben: Marc Dupuis, Wilfred Rubens, Pierre Gorissen, Stanley Portier. Hier een eerste deel van mijn verslag.

Sakai
De bijeenkomst begon met de presentatie van Chuck Severance, de executive director van de Sakai Foundation. Deze man is duidelijk een performer en gaf dan ook een er goede presentatie met enkele interesante opmerkingen:

• Sakai is nog een amateurproject, het is nog niet volwassen. Dit duurt nog zeker 2 jaar voordat het kan concurreren met commerciële producten.
• Voor de ontwikkeling van Sakai houden ze hetzelfde model aan als de Apache Foundation.
• Sakai is een collaboration and learning environment geïnspireerd op Lotus Notes en minder op bestaande ELO's.
  Ter illustratie van hiervan toonde hij onderstaande figuur.
  
  Waarin hij aangeeft dat Sakai nu nog niet is waar ze willen zijn. Wat natuurlijk niet klopt is het feit dat andere producten niet ook dezelfde richting op gaan. Als je nu kijkt naar de hele Blackboard Academic Suite dan is dat al veel meer collaboration/groupware dan hoe het staat gepositioneerd.

SOA's variaties

Chuck Severance maakt in zijn verhaal onderscheid in 3 typen SOA's:

• Within Application SOA
  A pattern for decomposing a single application into manu distinct components, each with a well-defined data model and contract and indepent implementation.
  
• Distributed One-Way Enterprise SOA
  The authoritative source of enterprise-wide data is outside of any single application - no application is allowed to be a stovepipe.
  
• Distributed Two-way Enterprise SOA
  Fine grained component pluggability from multiple vendors allowing applications to be constructed from small units.

Op dit moment is One-Way het meest gebruikt. Dit is ook eenvoudig te implementeren. Bij Two-way ligt het probleem voornamelijk bij de organisatie en niet specifiek bij de techniek. Dit is ook mijn ervaring met de implementatie hiervan op de TU, want het betekent dat iemand anders dan de huidige beheerder informatie kan toevoegen en wijzigen.

Presentatie Erik Saaman over Surfnet en SOA's

Surfnet heeft net een onderzoek laten uitvoeren naar de status van de implementatie SOA's binnen instellingen. Erik gaf in zijn presentatie duidelijk aan dat er twee kanten zitten aan SOA's:

• Architectuur (componenten):
  • analyse van bedrijfsprocessen
  • opsplitsen in onafhankelijke deelsystemen
  • totaalplaatje van systemen en relaties daartussen
• Webservices (aansluitingen):
  • koppelingen tussen systemen
  • via een webprotocol
  • gegevens in xml-formaat
  • onafhankelijk van de onderliggende techniek

Als je vanuit een strikt technisch oog kijkt naar webservices dan is het SOAP ( + bijbehorende standaarden). Een meer liberale blik zegt dat alles wat aan de definite voldoet ook een webservice, zoals RSS, REST, OAI-PMH, WebDAV, SRU, etc). Persoonlijk vind ik de keuze voor een meer liberale blik natuurlijk beter, vooral ook omdat dit realistischer in de praktijk.

Enkele punten waar je volgens Erik zeker op moet letten bij de implementatie van webservices:

• SOAP allen is onvoldoende standaard. Het is alleen een transportlaag, het legt de service zelf niet vast (syntax en semantiek). Alleen SOAP afspreken geeft veel ellende
• Let op de performance
• Let op de beveiliging.

Surfnet heeft de afgelopen tijd al wat ervaring op gedaan met webservices:

• Valkuilen bij webservices
  • ontwerpen overlaten aan externe partij (consultant/bouwer)
  • rechtstreeks vertalen van API naar SOAP
  • Service op niet uitgekristalliseerde processen
  • problemen tussen systeem en interface
  • beveiliging
  • service levels (performance)
  • support
  • marketing (doelgroep: management vs techneuten)
• Sleutel: gebruik standaarden!!!
• Het is duur
• Ontwerp en documentatie interface is lastig

Bij de implementatie van SOA kan je dus eigenlijk kiezen tussen twee invalshoeken: webservices vs architectuur. Als je kiest voor de architectuur dan is het doel vooral het managen van het proces. Hierbij moet je de bedrijfsprocessen zichtbaar maken en de samenhang in kaart brengen. Het betreft vaak de binnenkant van de ICT-architectuur.
Als met services start gaat het om de functionaliteiten zichtbaar maken, interfaces definiëren. Het betreft vaak de buitenkant van de ICT-architectuur. Het doel is om webservices te creëren.

Beide beide invalshoeken zijn de standaarden erg belangrijk.

Aan het eind gaf Erik ook nog een persoonlijke boodschap:

• Geef ruimte aan creativiteit
• Wees pragmatisch
• Kijk ook naar web2.o, mashup
• Verlies je niet in grootschalige architecturen.

Erik gaf onderstaand plaatje als voorbeeld: