Toon posts:

Beheer web services

Pagina: 1
Acties:
  • 137 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
*Dit topic heeft niet direct betrekking op "ontwikkelen" maar hangt er wel nauw mee samen. Helaas is er geen beheerforum...*

Hi all,

Ik zit met een issue. Web services van een systeem bevinden zich in de beheerfase. Zoals gebruikelijk is bij software wordt er ook onderhoud gepleegd. :)

En dat onderhoud/beheer is nu zo "lastig". Er zijn namelijk tientallen partijen die hun back-offices aan deze services hebben gekoppeld; 1 wijziging (bijv. nieuw aanvullend argument voor een web method) en al deze back-offices moeten die aanpassingen direct doorvoeren (anders worden de bedrijfsprocessen verstoord).

Hoe gaan jullie daar mee om? Ik zit aan een transitieperiode te denken waarin zowel de "oude" als de vernieuwde services operationeel zijn en na een X aantal dagen de oude web services verdwijnen.

Ben benieuwd naar jullie ervaringen/tips m.b.t. beheer van remote interfaces.

Thanks!

  • Janoz
  • Registratie: Oktober 2000
  • Laatst online: 12-05 22:46

Janoz

Moderator Devschuur®

!litemod

Ikzelf zorg dat de interface niet veranderd. Waneer een argument toegevoegd wordt dan blijven beide methodes bestaan, maar roept de oude methode de nieuwe aan met een default waarde voor dat argument die dezelfde output opleverd als de vorige versie. Dit werkt echter alleen bij uitbreidingen van de functionaliteit. Aanpassingen gaan een stuk lastiger. In de gevallen waar ik zelf tegenaan gelopen ben houden we bijde instanties instant todat echt 100% zeker is dat de oude niet meer wordt gebruikt.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'


Verwijderd

Topicstarter
Dat lijkt me inderdaad de juiste manier...

Verder heb ik nog zaken waar ik in ieder geval ook nog aan denk:
- testware beschikbaar stellen (zodat de kwaliteit direct weer getoetst kan worden)
- versiebeheer (wat is veranderd? wanneer? etc)
- procedures (Change Management --> ITIL)
- performance & usage stats (t.b.v. bijsturen)
- helpdesk

  • Rac-On
  • Registratie: November 2003
  • Niet online
wij werken hier op kantoor vrij simpel. We hebben een uitgebreide xml interface, die (ff virtueel, echte nummers zijn anders) als versie nummer 4.1 heeft. Daarnaast hebben we de oude interface (4.0) en de beta interface (4.2). Aanpassingen e.d. maak ik op de beta interface (4.2) en communiceer ik naar onze gebruikers.
Als ik op moment X vind dat ik versie 4.2 dusdanig 'af' vind dat hij de "main versie" moet worden, stuur ik een mail naar alle gebruikers met daarin:
- de mededeling dat 4.2 main gaat worden
- de mededeling dat de ondersteuning en beschikbaarheid van 4.0 opgeheven gaat worden
- de mededeling dat er niet langer ontwikkelt wordt aan 4.1 en deze versie nog beperkt beschikbaar blijft
- de mededeling dat er een nieuwe versie 4.3 als beta komt
- de mededeling dat ze 2 maanden de tijd hebben voordat bovenstaande in werking treedt

als gevolg hiervan:
- kan iedereen die het wil al vroegtijdig nieuwe functionaliteit gebruiken van 4.2
- blijft de oude interface enkele maanden beschikbaar
- hoef je niet ondereindig lang oude versie's te bewaren

uitgaande van het feit dat ik ongeveer 2 keer per jaar een versie opschuif, heeft een klant vanaf het moment dat mijn mailtje wordt verstuurd, 2 maanden zeker plus gemiddeld nog 6 maanden extra de tijd om zijn systemen van de oude interface naar de main versie te migreren. Daar de functies over het algemeen zo veel mogelijk hetzelfde worden gehouden, is dit lang genoeg.

doet niet aan icons, usertitels of signatures