[C#.NET] Web Service proces flow

[Verwijderd]

Hoi, Ik hoop dat ik op het goede forum zit, maar ik probeer een bestaande web applicatie om te zetten in een webservice, zodat deze geiintegreerd kan worden in andere webapplicaties.

Nu is er een bepaalde procesflow voor deze functionaliteit, en die wou ik graag vasthouden voor de webservice. Bijvoorbeeld Stap 1: Invoering gegevens. Stap 2: Webservice wordt aangeroepen, doet wat en het volgende scherm komt tevoorschijn.

Mijn vraag is hoe kan ik dit het beste doen?

alvast bedankt.

[RobIII]

Hoe kun je wat het beste doen? Het volgende scherm tonen Of ...
Misschien kun je je beter eerst even inlezen in de materie en een tutorial ofzo volgen, want ik krijg niet de indruk dat je nu precies weet wat een webservice (bijv.) is. Daarnaast wil ik je graag even wijzen op onze Programming Beleid Quickstart waarin je kunt lezen wat we graag zien in een topic in PRG en dan zul je net als ik concluderen dat er nogal wat ontbreekt in je topic

[MrBucket]

Regel 1: de webservice is stateless

D.w.z. dat het niet de bedoeling is dat je een soort van 'sessie' opbouwt tussen de client van de webservice en de webservice zelf (zoals dat meestal wel gedaan wordt in een webapplicatie).

Elke call naar de webservice moet op zichzelf staan. Je moet met een call dus genoeg parameters meegeven zodat de webservice op basis van alleen die parameters de benodigde handelingen kan uitvoeren.
Zo is het bijvoorbeeld niet de bedoeling dat, als je een personeelsadministratie-systeem onwerpt, dat de webservice onthoud welke medewerker jij als laatste in je client hebt geopend. In plaats daarvan zul je de webservice met elke call moeten vertellen op welke medewerker je de betreffende operatie uitvoert.

Dus, een goed begin lijkt me om je workflow op te splitsen in elementaire method-calls naar de webservice die:
- niet zo generiek zijn dat je 50 calls naar de webservice nodig hebt om een enkele operatie uit te voeren, maar ook
- niet zo specifiek zijn dat ze nooit meer hergebruikt kunnen worden.

[Verwijderd]

Ten eerste excuses voor de vage omschrijving.

Ik weet dat web services alleen maar function calls zijn, maar wat ik graag wil is de interface vastleggen.
De functionaliteit is op dit moment gesplits in meerdere functies, die gebruikt kunnen worden door een webservice.
Derde partijen die hier gebruik van maken kunnen hierdoor hun eigen interface maken en het proces flow veranderen, wat ik dus niet wil.

Wat mij het mooiste lijkt is het complete proces, dus inclusief
de interface als webservice willen aanbieden.
Nou lijkt mij een functie dat van serverside html uitspuugt niet de goede
manier, en ook problematisch is omdat er dan geen events aan de interface
gekoppeld kunnen worden. Maar toen zag ik AJAX en nu ik zie de mogelijkheid om dit te doen. Iets van een .js bestand dat html in een divje zet, en met javascript bepaalde events kan aanroepen.

Graag zou ik jullie mening hierover willen hebben en of er misschien alternatieven zijn.

[RobIII]

Verwijderd schreef op donderdag 21 juni 2007 @ 15:19:
Ik weet dat web services alleen maar function calls zijn, maar wat ik graag wil is de interface vastleggen.

WSDL?

Verwijderd schreef op donderdag 21 juni 2007 @ 15:19:
De functionaliteit is op dit moment gesplits in meerdere functies, die gebruikt kunnen worden door een webservice.
Derde partijen die hier gebruik van maken kunnen hierdoor hun eigen interface maken en het proces flow veranderen, wat ik dus niet wil.

Dan maak je die methods private?

Verwijderd schreef op donderdag 21 juni 2007 @ 15:19:
Wat mij het mooiste lijkt is het complete proces, dus inclusief de interface als webservice willen aanbieden.
Nou lijkt mij een functie dat van serverside html uitspuugt niet de goede manier, en ook problematisch is omdat er dan geen events aan de interface gekoppeld kunnen worden. Maar toen zag ik AJAX en nu ik zie de mogelijkheid om dit te doen. Iets van een .js bestand dat html in een divje zet, en met javascript bepaalde events kan aanroepen.

In principe heeft AJAX geen drol met webservices te maken. En IMHO horen methods 1 resultaat te returnen (van eender welk type) dat door de client wordt omgezet naar de juiste opmaak (dan kan HTML zijn maar denk ook aan "Windows" applicaties die zo'n call zouden kunnen maken)

[Niemand_Anders]

@MrBucket. WebServices hoeven niet static te zijn. De WebMethodAttribute class kent namelijk de eigenschap 'EnableSession' waarje je sessies kunt gebruiken. Echter deze sessie is *niet* dezelfde sessie als welke de bezoeker van je website heeft. Immers de bezoeker heeft verbinding met jouw website en jouw website heeft verbinding met de WebService. Echter twee aanroepen naar een WebService op dezelfde server delen wel dezelfde sessie. Echter het gebruik van sessies wordt ten stelligste afgeraden (ontwerp en gebruik wordt namelijk minder transparant).

Als antwoord op de vraag van Lermo. WebServices worden in het algemeen alleen gebruikt als data laag. Bijvoorbeeld op ophalen (wegschrijven) van customer gegevens. Echter zorgt het gebruik van WebServices wel voor enige overhead en daarmee voor performance verlies. Een WebService bied meestal pas voordelen als twee applicaties (websites) gebruik maken van dezelfde data zoals een gemeenschappelijke login of een data feed (product info, nieuws berichten, etc)

Maar wat is het wat je precies wilt doen? Je klint een beetje als mijn baas. Die praat ook alleen maar in buzzwords..

Als derde partijen gebruiken maken van jouw webservice(wat in dat geval de interface is), dan kun JIJ de presentatie helemaal niet doen, wat dan doen die derde partijen.

Mijn vragen aan jouw:
- Wat bied JIJ aan wat voor derde partijen interessant is?
- Hoe komen die derde partijen momenteel aan hun data (SOAP, XML http posts, RSS feed, IFrame, etc)?
- Wie doet de validatie van de (aangepaste) gegevens?

[Verwijderd]

Niemand_Anders schreef op donderdag 21 juni 2007 @ 15:56:

Als derde partijen gebruiken maken van jouw webservice(wat in dat geval de interface is), dan kun JIJ de presentatie helemaal niet doen, wat dan doen die derde partijen.

En dat is juist wat ik wel wil

Vandaar dat ik de oplossing voor AJAX aankaarte, zodat de derde partij met 1 function call de presentatie ophaalt (of te wel HTML) met daarin events voor het vastleggen van de flow.

[RobIII]

Verwijderd schreef op donderdag 21 juni 2007 @ 16:09:
met daarin events voor het vastleggen van de flow.

Je bedoelt javascript in de HTML ofzo?
Ik kan er geen touw aan vast knopen en heb het idee dat je wel wat buzzwords hebt gehoord maar geen idee hebt waar je het over hebt (en dat is NOFI hoor). Kun je een voor eens-en-altijd duidelijk uitleggen wat je nou precies wil?

[OZ-Gump]

Verwijderd schreef op donderdag 21 juni 2007 @ 16:09:
[...]

En dat is juist wat ik wel wil

Vandaar dat ik de oplossing voor AJAX aankaarte, zodat de derde partij met 1 function call de presentatie ophaalt (of te wel HTML) met daarin events voor het vastleggen van de flow.

Volgens mij is het dan praktischer om een WebPart te bouwen welke door derden gebruikt kan worden. Deze WebPart kan voor de (business) functionaliteit gebruik maken van WebServices, terwijl de state in de WebPart bijgehouden kan worden. Jij hebt dan alsnog de presentatie in handen, terwijl de bijbehorende onderdelen ook alleen verantwoordelijk zijn voor hun eigen domein.

WebServices die statefull zijn en ook nog eens user interface over de lijn gooien, dat is niet echt een gebruikelijke manier van werken. Ik vraag me ook af hoe soepel het loopt om in je HTML ingebakken AJAX calls naar andere WebServices mee naar voren te geven en dat deze dan ook geaccepteerd gaan worden door alle browsers.

[Verwijderd]

OZ-Gump schreef op donderdag 21 juni 2007 @ 16:20:
[...]
WebServices die statefull zijn en ook nog eens user interface over de lijn gooien, dat is niet echt een gebruikelijke manier van werken. Ik vraag me ook af hoe soepel het loopt om in je HTML ingebakken AJAX calls naar andere WebServices mee naar voren te geven en dat deze dan ook geaccepteerd gaan worden door alle browsers.

Ik vraag me dan toch af hoe Googlemaps dit bijvoorbeeld doet, dat is ook in ajax gemaakt en levert een vaste presentatie van de webservice.

[Niemand_Anders]

Lermo, je haalt nu een aantal systemen van Google door elkaar. Google heeft een GoogleMap webservice welke o.a. benaderbaar is via SOAP. Daarnaast hebben ze een GoogleMap AJAX implementatie, maar die maakt weer gebruik van de WebService voor het verkrijgen van data. In dat geval is het dus niet de webservice welke de presentatie terug geeft. De webservices van Google verzorgen alleen data (Search) en business logica (AdWords) zodat deze ook in Windows GUI programma's gebruikt kunnen worden. En als jouw service direct html terug geeft, dan kan jouw service dus nooit in een Windows programma gebruikt worden.

Persoonlijk raad ik je aan je eerst even te verdiepen in multi-tier oplossingen. De twee meeste gebruikte zijn 2-tier en 3-tier. Bij 3-tier is de data (data laag via webservice), logica (business laag) en een presentatie laag (HTML). Bij 2-tier is de business laag verwezen in de andere twee lagen, maar data en presentatie zijn nog steeds verweven.

Ik denk dat je het beste via de webservice een XML document kunt terug geven. Via een XSLT stylesheet kun je daarvan dan plain html, ajax html of in javascript aanbieden. De webservice is dan bereikbaar via bijv. formmail.asmx en de html implementatie via formmail.aspx (welke zelf weer formmail.asmx) gebruikt.

Maar heb je er al over nagedacht hoe JIJ er dan voor gaat zorgen dat JOUW html past in de website van die derde partij (breedte, hoogte, kleur gebruik, wel of geen tables, voorkoming van conflicterende CSS stylen, etc)?

Ik weet niet wat voor soort formulier je aanbied, maar hoe denk je bijvoorbeeld custom aanpassingen voor een derde partij (bijv. een nieuwsbrief opt-in checkbox) te implementeren?