[ie/moz/ns] web-services

[Explore]

Op de site van Netscape staat uitgelegd hoe je een web-service in Mozilla/Netscape laat draaien. Op Microsoft Explorer mis ik zoiets nog (zal er wel zijn, maar kan 't niet vinden). Ik ben (nog) totaal niet thuis in web-services, maar ik wil 't tot op de bodem uitzoeken. Volgens mij hebben web-services een enorme potentie, maar op een of andere manier lijken de resources schaars.

Bestaat er zoiets als een cross-browser library waarmee je vanuit IE/Mozilla/NS een web-service kan aanspreken? Ik wil graag zoiets maken om uit te zoeken hoe het allemaal werkt, maar kan dus bijzonder weinig vinden.

Help!

[gorgi_19]

Is serverside benaderen van een webservice dan geen optie?

Voor ASP.Net: Zie http://www.asp.net/Tutorials/quickstart.aspx
(onderdeel: XML Web services created using ASP.NET)

[ Voor 52% gewijzigd door gorgi_19 op 05-12-2003 21:34 ]

[Explore]

Nee, de server-side wil ik juist zelf maken. In PHP bij voorkeur, liever niet in ASP of Java (al schijnt dat wel een goede taal te zijn voor web-services). Aan Apache/Axis heb ik ook gedacht, maar dat staat nog een beetje ver van m'n bed en schijnt ook vrij lastig te installeren te zijn heb ik mogen vernemen van een collega, die er de grootste moeite mee had.

[gorgi_19]

Explore schreef op 05 december 2003 @ 21:38:
Nee, de server-side wil ik juist zelf maken. In PHP bij voorkeur, liever niet in ASP of Java (al schijnt dat wel een goede taal te zijn voor web-services). Aan Apache/Axis heb ik ook gedacht, maar dat staat nog een beetje ver van m'n bed en schijnt ook vrij lastig te installeren te zijn heb ik mogen vernemen van een collega, die er de grootste moeite mee had.

Wat heeft serverside dan uberhaupt te maken met de browser? De link die jij geeft, geef, voor zover ik kan zien, een clientside oplossing. En dan speelt browser wel meer een invloed.

Als je een webservice serverside wil benaderen, dan maakt de browser absoluut niets uit; desnoods is het opera 1.0 of IE 3.0.

En nu dus een antwoord op je vraag:

Bestaat er zoiets als een cross-browser library waarmee je vanuit IE/Mozilla/NS een web-service kan aanspreken

Als je een webservice serverside benaderd (ASP, PHP, etc.), dan is deze per defintie crossbrowser (tenzij je eigen code niet crossbrowser is)

[ Voor 19% gewijzigd door gorgi_19 op 05-12-2003 21:44 ]

[chem]

http://developer.apple.co...vices/ie5webservices.html

[Explore]

Ehm ja, dat snap ik ook wel. Ik denk niet dat je begrijpt wat ik bedoel - zal wel aan mijn beroerde uitleg liggen. Oke, nog een poging...

Stel, ik heb een (zelf gemaakte) web-service in PHP (met NuSOAP oid) draaien op m'n server.

Deze service wil ik vanuit de browser aanspreken, net zoals het voorbeeld op de Netscape site. Maar deze client-side moet wel cross-browser zijn, zodat het ook werkt in IE enzo.

Ik wil dus niet gebruik maken van een publieke service, maar er zelf een maken. Om de client-side te testen is een publieke service overigens wel handig, daar niet van hoor.

[djc]

Wat bedoel jij precies met een Web-Service? Dat blijft hier enigszins onduidelijk. Moet er via SOAP data gecommuniceerd worden tussen een client en een server?

[curry684]

Ik snap eigenlijk ook het doel van dit topic nog niet. Gaat het je nu om de client-code voor IE/Mozilla/Netscape of om de code van de webservice zelf?

[Genoil]

Laten we voor het gemak maar even aannemen dat je een SOAP service wilt maken in PHP en daar ook een client voor wilt schrijven. Waarom is het dan zo belangrijk voor je dat die SOAP-client in een browser (bv. mbv JavaScript) draait? Als je het gewoon crossbrowser wilt hebben, kun je m.i. veel beter de SOAP-client ook in PHP doen (zoals ook al wordt aangedragen in de link die chem post).

Als je je nu af gaat vragen waarom je straks zowel je SOAP server als je SOAP client op dezelfde webserver draaien en jij de enige bent die met je eigen client tegen die server aankletst, weet je meteen waarom je helemaal geen webservice nodig hebt . Maar voor educatieve doeleinden natuurlijk niks mis mee...

Bij de keuze voor een PHP implementatie zou ik voor PEAR::SOAP gaan, daar zit de vaart van de ontwikkeling nog goed in en gaat straks met PHP5 helemaal relaxed worden (snel, Schema <-> PHP en meer)

[gorgi_19]

Explore schreef op 05 december 2003 @ 21:52:
Deze service wil ik vanuit de browser aanspreken, net zoals het voorbeeld op de Netscape site. Maar deze client-side moet wel cross-browser zijn, zodat het ook werkt in IE enzo.

Samengevat: Je wilt dus clientside Javascript hebben, welke crossbrowser is, en een webservice kan openen / benaderen.

Je wilt dus clientside een webservice aanroepen, in plaats van serverside?

[ Voor 4% gewijzigd door gorgi_19 op 06-12-2003 09:33 ]

[Genoil]

gorgi_19 schreef op 06 december 2003 @ 09:32:
[...]

Samengevat: Je wilt dus clientside Javascript hebben, welke crossbrowser is, en een webservice kan openen / benaderen.

Je wilt dus clientside een webservice aanroepen, in plaats van serverside?

Ja toch nog maar even een beetje geGoogled (zou er zelf immers ook niet geheel vies van zijn), maar een crossbrowser javascript soap implementatie bestaat gewoon (nog) niet. Je zou zelf een wrapper kunnen gaan schrijven voor de verschillende implementaties maar dat lijkt me ook maar niks.

Je zou ook naar een goed alternatief op SOAP kunnen kijken:XMLRPC.
Daarvan heb ik zojuist een Javascript implementatie bekeken die het zowel op Moz als IE leek te doen:

http://xmlrpc.kollhof.net/index.xhtml

SOAP is wel heel hip enzo maar met XMLRPC kun je bijna net zoveel als het om RPC gaat. 't alleen niet echt de standaard (meer), da's toch SOAP geworden.

http://www.xmlrpc.org

[gorgi_19]

Ja toch nog maar even een beetje geGoogled (zou er zelf immers ook niet geheel vies van zijn), maar een crossbrowser javascript soap implementatie bestaat gewoon (nog) niet. Je zou zelf een wrapper kunnen gaan schrijven voor de verschillende implementaties maar dat lijkt me ook maar niks.

Klopt, maar even de vraag duidelijk stellen; wat hij nu eigenlijk precies wil c.q. zijn probleem is.

Ik blijf het trouwens vreemd vinden dat je zoiets clientside wil gaan afvangen, om eerlijk te zijn, maar dat is denk ik mijn mening.

[Genoil]

gorgi_19 schreef op 06 december 2003 @ 10:32:
[...]

Ik blijf het trouwens vreemd vinden dat je zoiets clientside wil gaan afvangen, om eerlijk te zijn, maar dat is denk ik mijn mening.

mwoah ik kan me er wel iest bij voorstellen hoor. toen ik voor het eerst met webservices in aanraking kwam wilde ik precies hetzelfde als TS, maar dan met XMLRPC . en er zijn inmiddels best wel wat client-side platforms die SOAP ondersteunen (Flash MX bijvoorbeeld), of daar zelfs behoorlijk afhankelijk van zijn (.NET)

Flash MX is trouwens behoorlijk cross-browser? is dat geen oplossing?

[gorgi_19]

.Net is niet per definitie een clientside platform. Wel kan je makkelijk webservices gaan inlezen met winforms of benaderen met webforms.

Maar .Net is er niet afhankelijk van.

[Genoil]

gorgi_19 schreef op 06 december 2003 @ 10:50:
.Net is niet per definitie een clientside platform. Wel kan je makkelijk webservices gaan inlezen met winforms of benaderen met webforms.

Maar .Net is er niet afhankelijk van.

Mja ok we dwalen af...laat ik dan stellen dat de communicatie tussen .NET apps afhankelijk is van SOAP. Toch? (ik steek al jaren m'n kop in het zand wat .NET betreft dus ik weet er eigenlijk weinig vanaf)

[gorgi_19]

Genoil schreef op 06 december 2003 @ 10:54:
[...]


Mja ok we dwalen af...laat ik dan stellen dat de communicatie tussen .NET apps afhankelijk is van SOAP.

Erhm... afaik hoeft dat niet. Ik ben niet genoeg thuis in SOAP; maar je bent niet gebonden aan webservices c.q. soap implementaties tussen applicaties.

[Genoil]

gorgi_19 schreef op 06 december 2003 @ 10:55:
[...]


Erhm... afaik hoeft dat niet. Ik ben niet genoeg thuis in SOAP; maar je bent niet gebonden aan webservices c.q. soap implementaties tussen applicaties.

ok ok ik geef het op . 't is iig een goede zaak dat MS ook SOAP gebruikt voor webservices, kan iedereen die noodgedwongen tegen een (SOAP enabled) .NET-service aan moet kletsen dat lekker met z'n eigen implementatie doen zonder ook maar iets van .NET te hoeven snappen

sorry TS dat we zo oeverloos offtopic gegaan zijn, maar we zitten gewoon in spanning af te wachten wat je nou eigenlijk wilt met die clientside SOAP

[Explore]

Jullie dwalen inderdaad een beetje af, maar dat is niet erg. Ik heb ook altijd m'n kop in 't zand gestoken wat .NET betreft. Hoe dan ook, wat gorgi gokte is inderdaad precies wat ik wil:

gorgi_19:
Samengevat: Je wilt dus clientside Javascript hebben, welke crossbrowser is, en een webservice kan openen / benaderen.

Je wilt dus clientside een webservice aanroepen, in plaats van serverside?

Helaas kwam ik tot dezelfde conclusie als jullie: er is nog geen cross-browser client library te vinden. En om nou pioneering werk te gaan doen op een oefen project lijkt me niet verstandig. De kans van slagen is dan nihil.

Op zich is de link die chem geeft een beetje vreemd: een IE web-service op de site van Apple. Waarom is er op msdn niks te vinden? Althans, er is natuurlijk dit, al ligt de focus daar erg veel op .NET enzo.

Ik weet ook dat Flash MX met web-services overweg kan. Dat is ook een reden dat ik de web-service niet puur server-side wil: ik wil een service in verschillende clients kunnen gebruiken. Voornaamste doel is eigenlijk om een 'thin-client' te maken: een web-interface die eigenlijk uit niet meer bestaat dan een dhtml-library voor weergave van dialog-windows met informatie en een communicatie library om de server-side aan te spreken.

Momenteel is het zo dat in m'n clients alle data van de server naar de client wordt gestuurd, die dan het eea. dynamisch kan weergeven. Dit opzetten is vrij onhandig, ook al werkt het resultaat best goed. Maar met een web-service zou dat niet meer nodig zijn: dan kan je alleen DIE gegevens ophalen die je nodig hebt. Met XMLRPC kan dat ook, inderdaad, maar wat je zelf al zegt: XMLRPC is inmiddels achterhaald. Net als WDDX enzo. Web-services is de toekomst en ik besteed nu liever niet mijn tijd aan achterhaalde technologie-en.

Ik wil een web-service gebruiken in bijvoorbeeld een calender/agenda (zie een ander pas gestart topic van iemand anders) of een photo-album web-applicatie. Die laatste zou goed in Flash MX kunnen, maar op zich net zo goed in dhtml/javascript. Daarom wil ik expliciet de server-side scheiden van de client-side service.

Op zich zou je verwachten dat er in de lijst die op xmethods staat wel wat bruikbare voorbeelden staan. Die voorbeelden daar werken zowel in Moz/NS als IE, als ik me niet vergis.

Maar geen cross-browser javascript library...?

[Genoil]

Explore schreef op 06 december 2003 @ 13:02:
Jullie dwalen inderdaad een beetje af, maar dat is niet erg. Ik heb ook altijd m'n kop in 't zand gestoken wat .NET betreft. Hoe dan ook, wat gorgi gokte is inderdaad precies wat ik wil:


[...]


Op zich zou je verwachten dat er in de lijst die op xmethods staat wel wat bruikbare voorbeelden staan. Die voorbeelden daar werken zowel in Moz/NS als IE, als ik me niet vergis.

Maar geen cross-browser javascript library...?

Ja die voorbeelden werken gewoon omdat de soap-client achter de "try it" gewoon een server-side soap-implementatie is die een 'normale' crossbrowser webinterface genereert.

Overigens wel een helder verhaal, dat van die "thin-clients" die je wilt maken. Maar jammergenoeg dus geen cb-js-implementatie...

ik zou zeggen begin gewoon met het bouwen van je service, juist DOOR het gebruik van SOAP maakt het geen moer uit wat voor soap-clients je gebruikt...

handig lijstje om in de gaten te houden:
http://www.soapware.org/directory/4/implementations

[crisp]

als we alle buzzwords even buiten beschouwing laten en puur gaan kijken waartoe de client precies in staat moet zijn. In mijn ogen is dan puur en alleen de communicatie van en naar de server van belang; het is meestal het grootste probleem om daar een mooie generieke crossbrowser oplossing voor te vinden.
Zowel IE als Mozilla zijn in staat remote XML op te halen en dat clientside te parsen. In IE kan je daarvoor het MSXML ActiveX object gebruiken, en Mozilla kent native javascript addons om XML te laden ( linkje ). Opera wordt wat lastiger, maar het gebruik van de object-tag biedt misschien mogelijkheden ( linkje ).
Voor de rest is het niet zo heel lastig om clientside logica in te bouwen mbv javascript; zolang je verder geen exotische plugins nodig hebt, en geen toegang tot het bestandssysteem nodig hebt op de client heb je genoeg aan de core javascript methoden die door alle moderne browsers ondersteund worden. DOM biedt je een goede mogelijkheid om crossbrowser je HTML document dynamisch op te bouwen en te manipuleren (hooguit zal je voor IE hier en daar wat uitzonderingen moeten maken).

Ik denk echter dat je hier en daar toch behoefte zal hebben aan data opslag op de client; in IE en Mozilla is dat mogelijk (respectievelijk Jscript/VBscript en XUL), maar zolang de data beperkt is (< 4KB) kan je ook cookies gebruiken.

Meestal is er dus wel een mouw aan te passen toegespitst op de mogelijkheden die de clientside applicatie in zich moet hebben. Uiteraard zijn er wel cross-browser javascript libraries, maar die beperken zich meestal tot 1 bepaalde functionaliteit (zoals het voorbeeld van webFX). Zelf je eigen cross-browser library schrijven is op zich ook nog niet eens zo moeilijk, maar daarvoor heb je veel kennis nodig van de mogelijkheden van de verschillende browsers. Vergaande kennis van de core javascript methods is sowieso onontbeerlijk.

Een voorbeeld van een crossbrowser (IE en Mozilla) webservice die ik heb gemaakt is uiteraard de GoT Tracker. Een goed voorbeeld van de mogelijkheden van DHTML op crossbrowservlak is natuurlijk Lemmings / Pumpkins. Bedenk echter dat ik al zo'n 4 jaar ervaring heb met javascript, en dan voornamelijk op het experimentele vlak.

Ik snap het verhaal van de thin-clients in dit opzicht echter niet helemaal; dat wil volgens mij zeggen dat er op de client helemaal geen logica of opslag gedaan wordt, maar het puur een interface is. Die interface moet dus door de server dan verzorgt worden. Misschien begrijp ik ook nog niet zo goed wat een webservice precies inhoudt en hoe ik dat voor me moet zien in combinatie met een crossbrowser javascript library.

[ Voor 10% gewijzigd door crisp op 06-12-2003 13:44 ]

[Genoil]

crisp schreef op 06 december 2003 @ 13:39:

Ik snap het verhaal van de thin-clients in dit opzicht echter niet helemaal; dat wil volgens mij zeggen dat er op de client helemaal geen logica of opslag gedaan wordt, maar het puur een interface is. Die interface moet dus door de server dan verzorgt worden. Misschien begrijp ik ook nog niet zo goed wat een webservice precies inhoudt en hoe ik dat voor me moet zien in combinatie met een crossbrowser javascript library.

heh je hebt eigenlijk wel gelijk ja, een javascript applicatie die mbv DOM en DHTML de presentatielaag afhandelt is veel "thicker" dan bijvoorbeeld deze GoT-reply pagina . Maar wat op zich wel interessant is, dat de client-logica puur presentatie-logica is, en de server-logica puur business-logica. zo'n soort project zit ik nu zelf ook in, met als verschil dat er meerdere servers (3 a 4) betrokken zijn, die verschillende lagen en onderdelen van het totaalsysteem omvatten. De communicatie tussen de clients en de "presentatie-server" houden we echter voorlopig (prototypestadium) gewoon lekker "traditioneel" met HTML pagina's over GET en "normale" POST.

There are reasons you shouldn't use SOAP:

• Normal application logic
• Dynamic content retrieval in web pages
• Because it's there
• Taking showers, PLEASE USE SOAP

[Explore]

WebFX ken ik en heb ik al eens eerder gebruikt. 't Is inderdaad de 'next best thing'. Het lijkt er op dat de belofte van platform- en taal onafhankelijkheid van web-services weer eens de mist in gaat als het op browsers aankomt. Er zijn genoeg pioneers op dit gebied en op eoa. manier heeft nog niemand een crossbrowser oplossing gemaakt. Dat zegt toch wel wat.

Ik denk dat ik Genoil's raad maar opvolg en gewoon begin met m'n web-service op te zetten en het eea. ga uitproberen in de verschillende clients - elk op z'n eigen wijze...

[Explore]

Genoil schreef op 06 december 2003 @ 15:11:
heh je hebt eigenlijk wel gelijk ja, een javascript applicatie die mbv DOM en DHTML de presentatielaag afhandelt is veel "thicker" dan bijvoorbeeld deze GoT-reply pagina . Maar wat op zich wel interessant is, dat de client-logica puur presentatie-logica is, en de server-logica puur business-logica. zo'n soort project zit ik nu zelf ook in, met als verschil dat er meerdere servers (3 a 4) betrokken zijn, die verschillende lagen en onderdelen van het totaalsysteem omvatten. De communicatie tussen de clients en de "presentatie-server" houden we echter voorlopig (prototypestadium) gewoon lekker "traditioneel" met HTML pagina's over GET en "normale" POST.

Tsja, misschien hebben jullie gelijk en moet ik 't maar bij de WebFX library houden. Deze is al in staat kleine stukjes data heen-en-weer te sturen tussen server en client. En dat in zowel IE als Moz/NS. Op zich heel netjes.

Het doel was inderdaad de client puur presentatie-logica te laten afhandelen en de server de business-logica. Client en server zijn dan wel 'made for eachother'. Dat wil zeggen dat de server niet zonder de client kan en vice versa.

Misschien is over een jaartje of wat de tijd rijp...