[xml] data opsturen naar server...

[Verwijderd]

Ik heb een beetje lopen spitten in de documentatie...

xml latern genereren via asp pagina's op server en dan laten uitlezen door client gaat wel lukken....

maar kan ik ook gegevens in xml opsturen naar de server die dan realtime worden verwerkt... opgeslagen in db o.i.d.

het is de bedoeling dat een client gegevens naar de server toestuurt...

bv in een executable wordt een verbinding met de server gemaakt en dan de gegevens verstuurd... deze gegevens worden door de server geinterpreteerd en afgehandeld....

gaat dit via http protocol lukken..?! of moet je met winsock eigen protocol schrijven voor iets dergelijks... het moet eigenlijk zo simpel mogelijk...

oplossign zou kunnen zijn via ftp versturen, en dat de server dan iedere paar minuten met een job gaat kijken of er bestanden zijn... maar dan is het niet meer realtime....

samenvatting:

client stuurt gegevens naar server... zonder dat hij dat echt verwacht... gegevens worden daarna door server gelezen --> validatie en verder afgehandeld --> weggeschreven, gekopieerd whatever...

is dit mogelijk..?! via js/vb (clientside/serverside) webservice, VB Standalone exe...!?

[tomato]

Ja, dit is heel goed mogelijk. Juist met HTTP is dit de meest voor de hand liggende richting van communicatie, aangezien de genoemde 'server' al een HTTP Server is. Data naar deze server versturen kan heel eenvoudig, andersom kan eventueel eerder een probleem worden (in het geval de server uit zichzelf data naar de client zou moeten sturen).

Maar om verder hier op in te gaan en te kijken of HTTP eigenlijk wel een goede keuze voor je is zul je meer informatie moeten geven

[mulder]

Ja.

Doormiddel van een simpele post kun je al data naar de server sturen. Waarom dus dan geen xml.

[Verwijderd]

ja ik weet ej dat info kan versturen via http...

ga uit van een standaard formulier.... (let ff niet op de source van xml, dit is een voorbeeld)

code:

<formulier id="1234">
<clientid>1234</clientid>
<password>test</password>
<voornaam>Jan</voornaam>
<acternaam>Visser</achternaam>
<opmerking>Dit is een test <br />Regel 2.........</opmerking>
</formulier>

De server moet dit bericht veriferen, kijken of naam/ww goed zijn... gebruiker rechten heeft en dan het zaakje in de db schrijven....

tot hier kom ik er wel uit...

maar hoe regel ik nu dat dit wordt verzonden door client, wordt gelezen door server en wordt afgehandeld...

[tomato]

Wat is je client? Maak je er zelf een, gebruik je een browser, iets anders, of kan het alledrie?

[Verwijderd]

in eerste instantie: via browser, daarna komt standalone versie... en in de toekomst mis iets anders....

ik heb ff gekeken... je kunt het hele zaakje natuurlijk makkelijk in een formulier stoppen en dan naar de server toezenden... alleen heb je dan enigszins het probleem dat de naam/ww in de source v/e html pagina staan....

[MrBrown]

Is wat je beschrijft eigenlijk niet een beetje een eigen implementatie van SOAP maken? Misschien kan je daar eens naar kijken. Er is iets te weinig info om te kijken of dat echt toepasbaar is voor jou, maar het klinkt er erg naar....

[Verwijderd]

jess.... daar lijkt het wel heel erg op.... ik was er al naar op zoek geweest... maar niet iets gevonden wat ik echt nodig heb... maar dit lijkt er wel vrij sterk op... thnx... ik zla er naar kijken

[tomato]

Verwijderd schreef op 23 augustus 2002 @ 21:55:
ik heb ff gekeken... je kunt het hele zaakje natuurlijk makkelijk in een formulier stoppen en dan naar de server toezenden...

Maar dan krijgt de server de data niet in een XML formaat. Tenzij je met scripting op de client het geheel volgens een XML formaat in een formulier veld plaatst natuurlijk.

alleen heb je dan enigszins het probleem dat de naam/ww in de source v/e html pagina staan....

Ik snap niet zo goed wat je hier mee bedoelt. Doel je op naam/wachtwoord die de gebruiker in moet vullen
Of doel je op naam/wachtwoord die nodig zijn om de XML data naar de server te verzenden? In dat geval zullen die natuurlijk sowieso bekend moeten zijn op de client en of dat nu in de HTML source te zien is of niet, ze zullen naar de client gestuurd moeten worden dus dat maakt verder niet zo veel uit.

Over SOAP (of XML-RPC, wat wellicht een veel betere oplossing voor je is): er zijn voor de grote browsers SOAP en XML-RPC client implementaties te vinden als je even zoekt, bijvoorbeeld in Javascript.

[Verwijderd]

Ik snap niet zo goed wat je hier mee bedoelt. Doel je op naam/wachtwoord die de gebruiker in moet vullen

nee dat snap ik nou ook niet helemaal eigenlijk... krijg je ervan als je de hele dag logica krijgt op school... tuurlijk heb je gelijk dat ze op de client bekend moetne zijn :}O

ehh ik heb bij MS de toolkit op gehaald en ben die nu aan t doorspitten...

even voor de zekerheid... SOAP is platform onafhankelijk, dus je kunt het ook in ASP scripten zonder het .NET framework..?!! ik heb daar toe geen mogelijkheid... (anders gaan er dooie vallen) onder IIS 4/5 met ASP 2.0/3.0 werkt het ook..?!

Iedereen heeft het over .NET maar het zou ook op PHP/APACHE moeten werken...

[blender]

Een woord:

SOAP

[Verwijderd]

5 woordjes:

daar was ik al achter

[tomato]

Verwijderd schreef op 23 augustus 2002 @ 22:51:
even voor de zekerheid... SOAP is platform onafhankelijk, dus je kunt het ook in ASP scripten zonder het .NET framework..?!! ik heb daar toe geen mogelijkheid... (anders gaan er dooie vallen) onder IIS 4/5 met ASP 2.0/3.0 werkt het ook..?!

Iedereen heeft het over .NET maar het zou ook op PHP/APACHE moeten werken...

SOAP is in principe inderdaad platform-onafhankelijk. Maar sommige implementaties zijn dit in de praktijk niet. Kijk erg uit wanneer je alleen Microsoft SOAP oplossingen gebruikt, het kan erg moeilijk worden daar later mee te communiceren vanaf en non-Microsoft platform (het kan altijd, maar in sommige gevallen wordt het je praktisch onmogelijk gemaakt).
Maar dat ligt niet aan SOAP an sich. Doe je het goed, dan kun je SOAP geheel platform onafhankelijk gebruiken.

Kijk toch ook nog even naar XML-RPC, wellicht voldoet dat ook aan je eisen en je bent gelijk van een hoop SOAP bloat. Hier is verder al heel wat over gezegd op GoT en misschien vind je ook wat nuttige opmerkingen op Javahova (hier bijvoorbeeld).

[mbravenboer]

SOAP is een onvolledige standaard. Vergelijk het maar eens met een papiertje in een envelop. SOAP specificeert hoe de envelop er uit moet zien en op welke manier deze envelop getranspeert kan worden over HTTP. Het zegt echter maar heel weinig over wat je nu echt op het papiertje wilt melden aan de ontvanger. Als een chinees jou een brief stuurt zal je er maar weinig van begrijpen, ook al geeft hij er een grammatica voor chinees bij (vergelijkbaar met een XML Schema). XML-RPC is een volledig standaard en specificeert volledig hoe de berichten er uit kunnen zien.

Beide methoden hebben voordelen en nadelen . Zie voor meer discussie inderdaad de draad op Javahova die tomato linkt ...

[Verwijderd]

ik heb het allemaal uitvoerig bestudeerd...

xml-rpc lijkt me niet de juiste oplossing omdat ik geen remote procedures wil opstarten... maar alleen een one way informatie wil sturen...

soap leek mij opzich aardig, maar er zit teveel overhead op een package... het is moeilijk uit te lezen en zou performance opeten...

wat ik nu van plan ben is een xml document laten genereren op de client die via een HTTP post command sturen naar de server... daar laten inlezen in een XML parser en dan verder afhandelen...

Dit lijkt me het meeste simpelst en snelst...

of denken jullie er anders over.>!?

[Verwijderd]

Wanneer performance belangrijk is dan lijkt mij een eigen oplossing het snelst. Ik heb zelf ook wel eens zoiets gebouwd. Bestond uit een VB client die een post deed naar een PHP pagina. Deze consumeerde de XML gegevens en gaf als response weer een XML document terug met daarin de resultaten van de operatie. Je kunt misschien ook even naar ASP.NET kijken. Deze heeft ingebouwd support voor webservices waarbij gebruik wordt gemaakt van SOAP. Het is erg simpel om een functie te exporteren naar het web (kwestie van een attribuut toevoegen) en deze method te consumeren via een client. Misschien wat overkill maar wel leerzaam .