Links

  • 1. Sogeti
  • 2. JBoss
  • 3. IBM
  • 4. Oracle
  • 5. SpringSource
  • 6. NL-JUG
  • 7. Java

Archives

Syndication  RSS 2.0

RSS 1.0
RSS 2.0

Bookmark this site

Add 'JCN Blog' site to delicious  Add 'JCN Blog' site to technorati  Add 'JCN Blog' site to digg  Add 'JCN Blog' site to dzone

Posted by Ruud Steeghs at 22:19 on Monday 7 April    Add 'Introduction to Websphere Services Registry and Repository (WSRR)' site to delicious  Add 'Introduction to Websphere Services Registry and Repository (WSRR)' site to technorati  Add 'Introduction to Websphere Services Registry and Repository (WSRR)' site to digg  Add 'Introduction to Websphere Services Registry and Repository (WSRR)' site to dzone

Een webservice bouwen is niet moeilijk. Een webservice gebruiken is ook niet moeilijk. Een webservice aanpassen ook niet. Maar…. hoe weet jij wie gebruikt maakt van jouw webservice en wat de impact is van een wijziging van je webservice? Wanneer het gaat om een handjevol services is het niet zo moeilijk om dit beeld compleet te houden. Spreken we echter van een groot bedrijf met een groot (…) aantal services die door veel partijen gebruikt worden, dan wordt het lastig om dit helemaal in de smiezen te houden. Wat doe je dan?

Het antwoord op deze (en andere vragen) is een Registry. De oplossing van IBM hiervoor heet Webservices Registry and Repository (WSRR) en is een product dat heel nauw samenwerkt met de ESB.

Om te zorgen dat de services opgenomen zijn in WSRR, moeten de service gepubliceerd worden in WSRR. Dit betekent dat de WSRR tevens een Repository is van alle bestaande services. En in een repository kun je… services opzoeken. Dus de WSRR is tevens de plek waar services gepubliceerd worden en waar services gevonden kunnen worden. Voorbeeld: ik moet een proces implementeren en één van de processtappen is het opzoeken van de klantgegevens. Wat doe ik dan? Ik  ga naar de WSRR om te zoeken of deze service al bestaat. In de WSRR vind ik dan wie de eigenaar is van de service en kan ik afspraken maken over het gebruiken van de service.

Een ander mooie functionaliteit die WSRR biedt, is het dynamisch selecteren van een service op basis van de inhoud van het bericht of andere parameters. Het gaat hier dan niet om functionele differentiatie, maar eerder om niet-functionele differentiatie zoals op basis van kosten van het gebruik van de serivice of beschikbaarheid van de service. Hierbij moet je dan voorstellen dat er twee versies van een service beschikbaar zijn die verschillende beschikbaarheid hebben.

Bovenstaande zijn allemaal runtime features die WSRR biedt. Daarnaast biedt WSRR ook design time functionaliteit. In WSRR kun je de rollen onderkennen die jij in je software development methodiek onderkent (bijvoorbeeld: business analist, designer, developer, tester, manager). Standaard zitten er een aantal rollen is. De fase overgang van de service in zijn lifecycle (identified, designed, implemented, tested, in production)  is dan gekoppeld aan rollen; maw alleen als jij een bepaalde rol hebt, dan mag jij zorgen dat de service naar de volgende fase gaat. Dus alleen de business analist mag services kiezen en aangeven dat de service ontworpen mag worden. Alleen de ontwerper mag aangeven dat de service klaar is voor ontwerp, etc, etc.

Tegenwoordig biedt WSRR ook een Eclipse plugin die in je favoriete Eclipse-based IDE kunt hangen zodat WSRR beschikbaar is in die IDE en het product dus ook inzetbaar is in omgevingen waar geen WSAD of WID gebruikt wordt.

Samengevat biedt WSRR de volgende functionaliteit:

- opzoeken van services

- runtime governance van service: overzicht van gebruik van de service

- designtime governance: lifecyclemanagement van services


© 2020 Java Competence Network. All Rights Reserved.