[WebServices] Nette foutafhandeling

[jsiegmund]

Ik ben op het moment bezig aan het programmeren van een aantal webservices die verschillende applicaties met elkaar koppelen. Dat werkt allemaal fijn en geweldig, maar hoe regel je foutafhandeling een beetje netjes?

Een paar verschillende voorbeelden vragen:
- Stel, de service die je aanroept is om welke rede dan ook uit de lucht. Je wilt er toch graag voor zorgen dat de databases van beide applicaties in sync. zijn; hoe los je dit op? Je kunt bijvoorbeeld om 0:00 een taak draaien die alsnog zorgt voor een synchronisatie, je kunt een wachtrij maken voor webcalls en die periodiek (of bij de volgende aanvraag) afwerken en zo zijn er nog wel een aantal opties te bedenken.
- Stel je roept een functie aan en de webservice kan dat verzoek om een of andere rede niet afhandelen. Bijvoorbeeld bij een verkeerde parameterwaarde. Je kunt netjes een melding / bool teruggeven om aan te geven dat de functie is mislukt: maar dan? Foutmelding richting de gebruiker? Mailtje richting een of andere admin? Logbestandje ergens?

Ik stel deze vragen omdat ik het idee heb dat je bij het gebruik van webservices altijd wel tegen dit soort dingen aan zult lopen en er dus meer mensen over nagedacht moeten hebben. Beetje onzinnig om het wiel dan 2x uit te vinden. Dus ik zou zeggen: brand los met uw schitterende oplossingen voor dit soort problemen.

[MTWZZ]

Misschien dat je naar iets als message queuing (bijv MSMQ) te kijken? Dat soort oplossingen heeft over het algemeen voorzieningen voor dit soort dingen.

[jsiegmund]

Dat ziet er al veelbelovend uit, eens kijken hoe handig dat te programmeren valt. Moet ook wel bruikbaar zijn binnen andere typen applicaties als .NET.

[ Voor 30% gewijzigd door jsiegmund op 02-04-2007 13:40 ]

[jsiegmund]

Op zich een aardige oplossing, maar het moet mijns inziens netter kunnen. Het meest ideale zou eigenlijk een service zijn die een webservice periodiek aanroept en de bestanden in een queue doorstuurt wanneer er verbinding is. Dat kan ik programmeren met MSMQ, maar bestaat zoiets niet standaard al? Ik ben vast niet de eerste met dit probleem?

[whoami]

Hebben je databases die je in - sync wilt houden dezelfde structuur ?
Maak je gebruik van hetzelfde dbms ?

Zoja, is (merge) replication dan geen oplossing ?

[ Voor 40% gewijzigd door whoami op 02-04-2007 16:51 ]

[jsiegmund]

whoami schreef op maandag 02 april 2007 @ 16:41:
Hebben je databases die je in - sync wilt houden dezelfde structuur ?
Maak je gebruik van hetzelfde dbms ?

- nee
- nee

Databases zijn geheel anders, zowel qua structuur als dbms als ontwikkelplatform. Is in het ontwerp ook geen rekening gehouden met een eventuele koppeling, anders hadden we dat inderdaad wel anders aangepakt.

[mulder]

Is het nou zo dat 1 applicatie de andere moet syncen, of dat je 2 applicaties moet aansturen en in sync moet houden? Denk niet dat hier een standaard oplossing voor is misschien BizzTalk?

[Slagroom]

Ik heb het opgelost door een error object te retouneren. Hierin zit een statuscode en een melding. Is de statuscode 100 dan is de request geslaagd en een andere code geeft een fout aan. Werkt goed al zeg ik het zelf.

[jsiegmund]

Don Facundo schreef op maandag 02 april 2007 @ 19:52:
Is het nou zo dat 1 applicatie de andere moet syncen, of dat je 2 applicaties moet aansturen en in sync moet houden? Denk niet dat hier een standaard oplossing voor is misschien BizzTalk?

Ingevoerde gegevens uit 1 applicatie moeten gekopieerd worden naar 2 andere applicaties. Daarvoor heb ik een soort observer structuur gemaakt die de input van een webservice kan kopieren naar meerdere services met dezelfde definitie.

Slagroom schreef op maandag 02 april 2007 @ 21:41:
Ik heb het opgelost door een error object te retouneren. Hierin zit een statuscode en een melding. Is de statuscode 100 dan is de request geslaagd en een andere code geeft een fout aan. Werkt goed al zeg ik het zelf.

Dan weet je dat het fout gaat en je request is mislukt. Zo'n soort mechanisme heb ik al, maar dan kun je alleen een foutmelding tonen en gaat je wijziging alsnog verloren. Die zul je dus moeten opslaan om later nog eens te proberen.

[ Voor 34% gewijzigd door jsiegmund op 03-04-2007 08:47 ]

[lier]

Volgens mij stel je een functionele vraag en worden er vele technische antwoorden opgegeven. Misschien kan je het proces beschrijven en benoemen welke fases er zijn en hoe ermee omgegaan moet worden ?

Even een klein voorschotje:

Gegevens worden aangeboden aan webservice
Twee smaken: het lukt (boeit verder in dit verhaal niet) of het lukt niet

Indien het niet lukt:
- Wat moet er gedaan worden ?
- Wil je bijvoorbeeld elke (gelukte/mislukte) poging loggen en wil je opnieuw aanbieden ?


Ben benieuwd...

[jsiegmund]

lier schreef op dinsdag 03 april 2007 @ 09:02:
Volgens mij stel je een functionele vraag en worden er vele technische antwoorden opgegeven. Misschien kan je het proces beschrijven en benoemen welke fases er zijn en hoe ermee omgegaan moet worden ?

Even een klein voorschotje:

Gegevens worden aangeboden aan webservice
Twee smaken: het lukt (boeit verder in dit verhaal niet) of het lukt niet

Indien het niet lukt:
- Wat moet er gedaan worden ?
- Wil je bijvoorbeeld elke (gelukte/mislukte) poging loggen en wil je opnieuw aanbieden ?


Ben benieuwd...

Het idee is dat een call die mislukt op de een of andere manier niet verloren gaat. Hoe interesseert me verder niet zoveel, hoewel de meest handige oplossing natuurlijk voorkeur heeft . M'n idee is nu om een mislukte aanroep in een queue te stoppen om deze later nog eens te proberen, bijvoorbeeld bij de volgende aanroep van de service, of op een bepaald interval.

Ik ben inmiddels eens aan het kijken bij het 3.0 framework; de Windows Communication Foundation. Daar zit reliable messaging in, wat eigenlijk zo'n beetje doet wat ik graag wil. Ik ben alleen nog niet zover dat ik nu duidelijk heb hoe dat implementatie technisch gezien gaat werken. Heb al wel een service-je draaiend gekregen, maar of die nu meteen 100% reliable is vraag ik me af (in dat geval heb je er echt erg weinig code voor nodig ). Verder heb ik in de richting van MSMQ gekeken wat je kunt gebruiken om queues te implementeren, MS gebruikt dit in 3.0 zelf ook op eenzelfde manier. Allemaal interessant maar het heeft dus nog wel wat ogen en haken om het eenmaal aan de praat te krijgen.

[sonix666]

Als je WCF gebruikt (wat ik je ten zeerste aanraad), dan kun je vanuit je service een SoapFault<T> (of zoiets) throwen, waarbij T een data contract is met je specifieke error informatie. Dat vertaalt WCF naar een echte exceptie in het SOAP protocol. Op die manier zou je met fouten om moeten gaan in mijn opinie.

Indien guaranteed delivery zeer belangrijk is zou je in WCF ervoor kunnen kiezen dat je je method call one-way maakt (dus de aanroeper hoeft geen antwoord) en dan zo de boel te configureren dat MSMQ als transport kanaal gebruikt wordt. Als je dan wat speelt met de instellingen dat je transacties aan ontvangende kant gebruikt, dan kunnen er geen berichten verloren gaan.

Een minpuntje, MSMQ als transport protocol is niet standaard een WS-* standaard.

[jsiegmund]

Kijk, dat klinkt opzich allemaal prima. Maar ik zie door alle bomen inmiddels het bos niet echt meer. Kun je me misschien in de richting wijzen van een goede tutorial of iets dergelijks? De voorbeelden die ik vind zijn allemaal aardig ingewikkeld en lijken me veel te uitgebreid voor de redelijk eenvoudig service die ik wil bieden. Ik had verwacht dat het implementeren van zo'n reliable service een kwestie van een vinkje zou zijn. Dat is natuurlijk lichtelijk overdreven, maar mijns inziens moet het toch mogelijk zijn om een redelijk traditionele web service te bouwen (wat echt niet moeilijk is) en die eenvoudig als "reliable" te markeren waarna WCF het van me overneemt. Of denk ik dan echt te rooskleurig?