[Webservices] Globale opzet

[MadFly]

Beste GOT-ers,

Voor mijn stage moet ik een koppeling maken tussen twee databases. Een MS SQL en MySQL. Eerst maar even een schetjes middels ASCII om de boel een beetje te verhelderen:

code:

- - - - - - - - - - lokale netwerk
|                          |
  [ Pc's met delphi-prog ] 
|           |              |
            |              
|     [ MS SQL DB ]        |
            |              
|           |              |   
    [ Webservice 1 ]      
|           |              |              
- - - - - - - - - - - - - -
            |            
            |
- - - - - - - - - - hostingprovider
|           |              |
     [ Webservice 2 ]      
|           |              |
            |
|     [ MySQL DB ]         |
            |
|     [ Moodle / PHP       |
- - - - - - - - - - - - - -

Die koppeling moet gebeuren middels webservices (poort 80) van de opdrachtgever, omdat de boel anders schijnbaar niet over het internet kan (firewalls bla die bla).

De opdracht: Eens in de zoveel tijd (zeg bijv. 2 uur) moet webservice 1 controleren of er wijzigingen zijn in de MS SQL DB, en indien die er zijn dan moet de boel omgezet worden en doorgepompt worden naar webservice 2 welke het vervolgens in de MySQL DB moet pleuren. Overigs zijn beide server voorzien van MS IIS.

Naar heel wat ge-google, kom ik eigenlijk nergens voorbeelden tegen met twee webservices die met elkaar praten. En is het in mijn geval handig om gewoon voor allebei te systemen ASP.NET C# Webservices te gebruiken. Iemand tips over de globale opzet, en heb ik misschien toch maar 1 webservice nodig?

[ Voor 3% gewijzigd door MadFly op 18-04-2005 22:12 ]

[Suepahfly]

MadFly schreef op maandag 18 april 2005 @ 22:05:

Die koppeling moet gebeuren middels webservices (poort 80) van de opdrachtgever, omdat de boel anders schijnbaar niet over het internet kan (firewalls bla die bla).

Correct me if i'm wrong maar webservices gaan wel degelijk over internet.

Wat je zou zou kunnen doen is webservice1 de wijziging laten weg schrijven naar een xml bestand en webservice2 de xml laten parsen en wegschrijven in mySQL. Met een datadictionary zou je dan de verschillen in veld typen kunnen afvangen.
ADOdb heeft een soort gelijke functionaliteit, maar dat is geschreven in PHP.

[LauPro]

Je kan SOAP gebruiken. Een echte webservice doe je echter niet over poort 80, maar over een beveiligde verbinding (SSL, SSH etc). SOAP is een protocol gebaseerd op XML. Je kan middels een DOM-object SOAP-documenten (XML files dus) aanmaken welke je dan aan de andere kant weer parsed (via een DOM eventueel). Voordeel van XML is dat het erg schaalbaar is. Je kan in een XML file 10 records zetten maar ook 1.000.000. Let wel dat dat laatste niet bepaald een performance improvement is .

De DOMS zijn in verschillende talen aanwezig, zeker in ASP(.net)-en consorten bij PHP heb je kans dat het wat lastiger wordt, er is echter wel goede ondersteuning.

Nadeel van SOAP is echter wel dat je zelf een soort protocol moet maken, zeker wanneer je complexe aanvragen hebt waar bijvoorbeeld 10 berichten worden verzonden over en weer. Je moet al die berichten tracken (unique sessie id oid) en weer parsen en kijken of het klopt.

SOAP wordt met name gebruikt om systemen te syncroniseren of aan te sturen (vaak externe design, back-up, BMS etc.).

[ Voor 13% gewijzigd door LauPro op 18-04-2005 22:31 ]

[MadFly]

Bedankt voor jullie snelle waardevolle reacties. Daar kan ik wel het een en ander mee.

Echter wil ik de boel zo simpel mogelijk houden (heb niet erg veel tijd meer ). Is SOAP niet de schil van de manier waarop xml-data wordt verzonden? Kan ik iets van http_post en http_get gebruiken ofzo.

Iig, wat heb ik nodig... Ik heb momenteel al Visual Studio .NET geinstalleerd. Sorry voor al deze vragen, echt ben echt een beginneling Lekkere begeleiding op stage

[ Voor 9% gewijzigd door MadFly op 18-04-2005 23:07 ]

[LauPro]

SOAP is slechts een standaard zoals XHTML is voor XML. Er zijn wel een aantal andere factoren zoals ik aan gaf. De opstarttijd die je nodig hebt voor SOAP zal misschien iets langer zijn maar je krijgt er wel veer voor terug. Als je zelf een protocol gaat bakken kom je al snel op ASCII bestanden uit. Dat gaat erg vervelend worden bij veel data, met name qua escaping e.d., XMS heeft dit allemaal al ingebouwd (CDATA) dus waarom het wiel opnieuw uitvinden?

[Verwijderd]

Ik ga niet inhoudelijk in op de discussie maar heb wel een paar opmerkingen:

• SOAP is een gestandariseerd protocol (Simple Open Access PROTOCOL) in XML. De vergelijking XHTML en XML gaat dus niet helemaal op.
• Webservice gaan wel degelijk over het Web via HTTP (anders zou het geen WEBservice heten he ) Je zou het inderdaad over een beveiligde lijn kunnen gooien (via SSL) maar dan is het nog steeds Internet.

[RobIII]

LauPro schreef op maandag 18 april 2005 @ 23:15:
SOAP is slechts een standaard zoals XHTML is voor XML. Er zijn wel een aantal andere factoren zoals ik aan gaf. De opstarttijd die je nodig hebt voor SOAP zal misschien iets langer zijn maar je krijgt er wel veer voor terug. Als je zelf een protocol gaat bakken kom je al snel op ASCII bestanden uit. Dat gaat erg vervelend worden bij veel data, met name qua escaping e.d., XMS heeft dit allemaal al ingebouwd (CDATA) dus waarom het wiel opnieuw uitvinden?

Met alle respect, maar ik heb het idee dat je de klok hebt horen luiden, maar nog niet weet waar de klepel hangt. Een korte, goede omschrijving van SOAP vind je hier. Zo gaat SOAP doorgaans, dus niet altijd, gewoon over HTTP.
Wat betreft de "opstarttijd" Waar heb je het over? En waarom zou je een CDATA gebruiken als SOAP dit al voor je doet, en als je het toch met de hand wil doen zijn er zat andere methodes bedenkbaar, zoals BASE64 enz.

LauPro schreef op maandag 18 april 2005 @ 22:30:
De DOMS zijn in verschillende talen aanwezig, zeker in ASP(.net)-en consorten bij PHP heb je kans dat het wat lastiger wordt, er is echter wel goede ondersteuning.

Waarom zou het in ASP.Net moeilijker zijn dan in een andere .NET omgeving

LauPro schreef op maandag 18 april 2005 @ 22:30:
Nadeel van SOAP is echter wel dat je zelf een soort protocol moet maken, zeker wanneer je complexe aanvragen hebt waar bijvoorbeeld 10 berichten worden verzonden over en weer. Je moet al die berichten tracken (unique sessie id oid) en weer parsen en kijken of het klopt.

Uhm, SOAP is een protocol, daar staat de P in SOAP zelfs voor. Daar wil je niet eens aankomen...

LauPro schreef op maandag 18 april 2005 @ 22:30:
SOAP wordt met name gebruikt om systemen te syncroniseren of aan te sturen (vaak externe design, back-up, BMS etc.).

Wederom wrong. SOAP wordt gebruikt om remote procedure calls uit te voeren via een standaard over het HTTP protocol (doorgaans) (al dan niet SSL).

[ Voor 42% gewijzigd door RobIII op 19-04-2005 10:34 ]

[Verwijderd]

Onlangs heb ik wat liggen rommelen met webservices. Ik heb toen een webservice gebouwd die aan de hand van een vraag van een bezoeker een wisselkoers uit een database haalt en dit min of meer als XML presenteert. Om de database te vullen gebruik ik een asp.net pagina die een XML bestand van de Europese centrale bank opvraagt.

Ik heb de database en de broncode in dit zip bestandje gezet. Wellicht kun je er iets mee. Als je de eerste keer de database gaat vullen moet je er wel rekening mee houden dat het script ruim een half uur nodig heeft om de database te vullen met ruim 44000 records. (wellicht kan iemand mij uitleggen waarom dit zo lang duurt) De database bijwerken duurt gelukkig een stuk minder lang.

Al met al is mijn broncode niet wetenschappelijk onderbouwd, maar misschien kun je er toch je voordeel ermee kunt doen.

Als je nog meer theoretische informatie wilt over webservices wilt dan is dit document van gigaport wellicht de moeite waard: www.gigaport.nl/download/highlights_webservice.pdf

[LauPro]

RobIII schreef op dinsdag 19 april 2005 @ 10:28:
Met alle respect, maar ik heb het idee dat je de klok hebt horen luiden, maar nog niet weet waar de klepel hangt. Een korte, goede omschrijving van SOAP vind je hier. Zo gaat SOAP doorgaans, dus niet altijd, gewoon over HTTP.

Imo ben je onverantwoord bezig als je dergelijke SOAP-transmissies plain text over inet verstuurd. Zeker als er bedrijfskritische informatie bij komt kijken, dan wil je dat echt wel via SSL of bijvoorbeeld over een VPN laten lopen. De voorbeeld bij SOAP gaan idd gewoon uit van poort 80, maar dat is slechts ter educatie of voor publieke webservices (IM oid).

Wat betreft de "opstarttijd" Waar heb je het over? En waarom zou je een CDATA gebruiken als SOAP dit al voor je doet, en als je het toch met de hand wil doen zijn er zat andere methodes bedenkbaar, zoals BASE64 enz.

Opstarttijd als in extra tijd die je kwijt bent aan ontwikkeling van een platform om SOAP-messages af te handelen. Je zult een structuur moeten opzetten e.d.. En zoals ik al impliceer, SOAP heeft een aantal dingen ingebouwd, zoals CDATA.

Waarom zou het in ASP.Net moeilijker zijn dan in een andere .NET omgeving

Ik bedoel dat het *mogelijk* in ASP(.Net) (of andere .Net dingen) wat eenvoudiger zal zijn dan met php. Dit komt omdat ik bij PHP met XML constructies gezien hebt waarbij je functies aan roept vanuit een functie, imo ranzig - maar dat is even een andere discussie.

Uhm, SOAP is een protocol, daar staat de P in SOAP zelfs voor. Daar wil je niet eens aankomen...

Natuurlijk is SOAP een protocol op zich. Alleen als je in je applicatie een constructie maakt waarbij je afwisselend meerdere messages heen en weer stuurt dan moet die constructie ook binnen een protocol vallen (zie het als bij FTP dat weer TCP/IP als protocol geruikt om te communiceren maar waarbij FTP op zichzelf ook een protocol is.).

Wederom wrong. SOAP wordt gebruikt om remote procedure calls uit te voeren via een standaard over het HTTP protocol (doorgaans) (al dan niet SSL).

HTTP hoeft niet per definitie over poort 80, en het ging mij er alleen maar om dat je dus niet klakkeloos kritieke bedrijfsinformatie (stel je voor je stuurt een persbericht onder embargo via SOAP) plain-text over internet jaagt. En waarom zou het maken van een backup niet als een remote procedure call gezien kunnen worden?

[alienfruit]

Ik zie dat je ook gebruik maakt van Delphi, waarom kijk je niet naar thin clients, door middel van .NET Remoting.


[1] http://bdn.borland.com/bo...aper/0,1963,32260,00.html

[Dennis]

Twee webservices met elkaar laten communiceren is ook niet echt hetgene wat je zoekt. Je zoekt gewoon een ASP.NET applicatie die met webservices aan de andere kant op IIS kan communiceren. Dit gaat via een gewone HTTP request (poort 80), eventueel over SSL.

[Brakkie]

En is het in mijn geval handig om gewoon voor allebei te systemen ASP.NET C# Webservices te gebruiken.

Volgens mij is een van de voordelen van een web service dat het een interface is tussen twee systemen die niet afhankelijk is van het platform of de programmeertaal waar de twee systemen mee werken. Je kan dus prima aan de ene kant een php client hebben die communiceert met bijvoorbeeld een Java server.

[Dennis]

Brakkie schreef op dinsdag 19 april 2005 @ 11:31:
Volgens mij is een van de voordelen van een web service dat het een interface is tussen twee systemen die niet afhankelijk is van het platform of de programmeertaal waar de twee systemen mee werken. Je kan dus prima aan de ene kant een php client hebben die communiceert met bijvoorbeeld een Java server.

Yep, je zit nu alleen wel met twee IIS servers, dus dan is het makkelijk te kiezen voor ASP.NET. Anders zou je inderdaad sneller geneigd zijn iets anders te gebruiken. De SOAP implementatie in ASP.NET is trouwens zeer goed.

[TlighT]

Dennis schreef op dinsdag 19 april 2005 @ 11:44:
Yep, je zit nu alleen wel met twee IIS servers, dus dan is het makkelijk te kiezen voor ASP.NET. Anders zou je inderdaad sneller geneigd zijn iets anders te gebruiken. De SOAP implementatie in ASP.NET is trouwens zeer goed.

Het is mij niet duidelijk of de topicstarter zowel op client als op server van .NET gebruik wil maken, anders kan TS ook kiezen voor remoting over een HttpChannel, wat icm een binary formatter betere performance zou moeten geven dan webservices.

[Not Pingu]

Met een ASP.NET webservice kun je heel goed een thread definieren die om de zoveel tijd een bepaalde webservice aanspreekt en uitleest. Het is echter niet de meest logische manier om dat met 2 webservices te doen, maar gezien problemen met firewalls is een webservice wel het meest toegankelijk.

[kasper_vk]

Ik heb de indruk dat de meeste suggesties het alleen maar moeilijker maken en over daarnaast te veel over niet-gevraagde implementatie details gaan.

MadFly schreef op maandag 18 april 2005 @ 22:05:

code:

- - - - - - - - - - lokale netwerk
            |              
|     [ MS SQL DB ]        |
|           |              |   
    [Webservice 1 ]      
|           |              |              
- - - - - - - - - - - - - -
            |            
- - - - - - - - - - hostingprovider
|           |              |
     [ Webservice 2 ]      
|           |              |
            |
|     [ MySQL DB ]         |
            |
- - - - - - - - - - - - - -

...
De opdracht: Eens in de zoveel tijd (zeg bijv. 2 uur) moet webservice 1 controleren of er wijzigingen zijn in de MS SQL DB, en indien die er zijn dan moet de boel omgezet worden en doorgepompt worden naar webservice 2 welke het vervolgens in de MySQL DB moet pleuren. Overigs zijn beide server voorzien van MS IIS.

... Webservices te gebruiken. Iemand tips over de globale opzet, en heb ik misschien toch maar 1 webservice nodig?

Klinkt alsof je in 1 richting wil data wil pushen; vanaf je lokale DB naar een DB bij de hostingprovider.
Het initiatief voor die actie ligt (als ik je TS lees) dus bij de lokale toepassing. Die zal dus 'iets' moeten aanroepen / aftrappen bij je hosting provider: een webservice bijvoorbeeld.
Je hebt helemaal geen webservice aan de lokale kant nodig, gegeven je topicstart. 1 webservice dus, niet 2.

Je plaatje wordt dus (ingekort) dit:

code:

- - - - - - - - - - lokale netwerk
|     [ MS SQL DB ]        |
|           |              |   
  [Synchronize-prog ]      
- - - - - - - - - - - - - -
            |            
           \|/
            '
- - - - - - - - - - hostingprovider
     [ Webservice]      
|           |              |
|     [ MySQL DB ]         |
- - - - - - - - - - - - - -

Heb je uitgezocht of je ook webservices bij je hosting-provider kunt uitrollen? Al dan niet via SSL?
(al vraag ik me af of je dat uberhaubt wel kunt blokkeren, als provider dan)

Waarmee je die webservices aanroept, dus het programma aan de lokale kant, is inderdaad implementie onafhankelijk; dat kun je in C, Java, *.NET, Dephi of whatever doen, zolang je maar soap-aanroepen kunt doen.

[ Voor 4% gewijzigd door kasper_vk op 19-04-2005 13:11 ]