Ontwerp van Webservices versus traditioneel OO?

[Verwijderd]

Wijkt het OO-design af van de webservices-design? Zo ja, met welke punten? Vooral bij webservices lijkt mij het belangrijk dat er zo min mogelijk calls over het internet gaan? Zijn er echter nog meer punten waar op gelet dient te worden?

Je kunt je JavaBean bijvoorbeeld zo maken dat die als webservice aangeroepen kan worden (via SOAP/XML over HTTP). Maar dat betekent wel dat alle calls via het internet gaan...dus kun je gewoon net zo modelleren als je JavaBean zou maken als die via het interne netwerk wordt aangesproken of zijn er verschillen?

[GraasGast]

Worden webservices dan niet met OO gemaakt?

[mbravenboer]

Object-orientatie is een paradigma van programmeertalen. Web-services (zoals we ze nu zien) zijn een handige manier om functionaliteit aan te bieden aan andere computers op een netwerk (merk op dat ik niet zeg dat ze functionaliteit aanbieden over het web omdat webservices niets met het web te maken hebben ).

Het design van een web-service is dus een compleet ander concept dan het design van een OO-applicatie. Je kunt bijvoorbeeld uitstekend een web-service implementeren in een OO-taal en daarbij het OO-design gebruiken samen met het web-service design. Ook kan je een web-service implementeren in een procedurele taal (C), een functionele (Haskell), een logische (Prolog) of bijvoorbeeld zelfs in een transformatie-taal (Stratego).

Het design van een web-service gaat voornamelijk over de functionaliteit die je aanbiedt, wat de argumenten van een service zijn, wat z'n resultaat is en hoe je functionaliteit groepeert. Dit alles zal echter wel gerealiseerd moeten worden, bijvoorbeeld op basis van een OO-design.

Het idee van web-services is echter juist dat het een implementatie onafhankelijke interface is tot functionaliteit. OO-achtige zaken zouden daarom ook niet zichtbaar moeten zijn als je het design van een web-service bekijkt.

Helaas volgt op dit moment het design van een web-service vaak uit het design van een applicatie in een OO-taal: de interface die bepaalt hoe er wordt gecommuniceerd wordt vaak niet van te voren vastgelegd, maar volgt uit de implementatie. Dat is aan de ene kant jammer, maar aan de andere kant ook wel begrijpelijk.

In een pure OO omgeving wordt remoting vaak heel anders geimplementeerd. Je ziet dit terug in systemen als RMI en Corba maar zelfs ook in .NET Remoting. De client krijgt dan een stub naar een remote object waarop gewoon methode aangeroepen kunnen worden. Deze remote-referenties zou je niet moeten gebruiken in een web-service omdat je je dan vastlegt op een implementatie in een bepaald paradigma of zelfs een bepaald platform. Helaas is het gedistribueerde object systeem van .NET (.NET Remoting) echter ook gebaseerd op web-services en worden daar dus gewoon object-referenties uitgewisseld tussen web-services.

[Verwijderd]

Je kan webservices met of zonder OO maken lijkt me. Ik zie niet in waarom OO negatief zou zijn in webservices design.

[Janoz]

Ik vind het een beetje op appels met peren vergelijken omdat beiden zich niet op hetzelfde niveau afspelen. Ik kan het mis hebben aangezien ik me niet helemaal kan voorstellen wat je met Webservices design bedoeld, maar het lijkt mij een ontwerp techniek die bovenop OO komt

[Tundreq]

JANOZ is nog steeds een FLIKKER

klik

SLUTJUH

[Glimi]

Op donderdag 06 juni 2002 13:16 schreef NestorY2K het volgende:
Wijkt het OO-design af van de webservices-design? Zo ja, met welke punten? Vooral bij webservices lijkt mij het belangrijk dat er zo min mogelijk calls over het internet gaan? Zijn er echter nog meer punten waar op gelet dient te worden?

Je kunt je JavaBean bijvoorbeeld zo maken dat die als webservice aangeroepen kan worden (via SOAP/XML over HTTP). Maar dat betekent wel dat alle calls via het internet gaan...dus kun je gewoon net zo modelleren als je JavaBean zou maken als die via het interne netwerk wordt aangesproken of zijn er verschillen?

Jij haalt echt een paar dingen door elkaar. SOAP staat voor simple Object Access (?) Protocol. Dat betekend dus dat SOAP objecten vervoert (nou niet helemaal, hij beschrijft ze alleen via XML)

Maw je gooit dus een object of een objectcall over het netwerk om die door de webservice te laten uitvoeren. Dit kan Java RMI ook uitvoeren of CORBA.

Het is iig allemaal gericht op het transporteren van objecten of objectcalls. Dus kan jij mij vertellen wat er NIET OO aan is?

[edit] dit is vele malen beter uitgelegd door mbravenboer weer

[Tundreq]

Tweakers forum sucks

[ACM]

Op donderdag 06 juni 2002 13:24 schreef gsjonnie het volgende:
Tweakers forum sucks

Haal jij je mail nou maar es op, de volgende opmerking als deze levert je een ban op.

[D2k]

SVP niet reageren op die gsjonnie en gewoon ontopic blijven

[Janoz]

Aahh D2k.... Alleen ikke nog?

maar iig

gsjonnie, je bent de zwakste schakel.. tot ziens...

[D2k]

en dan nu weer ONTOPIC

<hr>

[Tundreq]

FLIKKERS zijn mensen met rode letters

[Verwijderd]

Op donderdag 06 juni 2002 13:23 schreef Glimi het volgende:

[..]
Dus kan jij mij vertellen wat er NIET OO aan is?

Ik heb niet aangegeven dat het NIET OO is, ik vraag me af of ik een andere interface bovenop, bijvoorbeeld mijn JavaBean, moet zetten om het een goede interface te geven voor mijn webservice.

Webservices worden in mijn geval wel aangeroepen via het internet, dat lijkt me juist een van de grote voordelen van webservices, dus ik vraag me af of er een efficientere interface ontwikkeld kan worden?

[Verwijderd]

Op donderdag 06 juni 2002 13:23 schreef mbravenboer het volgende:
merk op dat ik niet zeg dat ze functionaliteit aanbieden over het web omdat webservices niets met het web te maken hebben ).

Webservices kunnen ook met het web te maken hebben, waarom zou dat niet kunnen?

[mbravenboer]

NestorY2K: Webservices kunnen ook met het web te maken hebben, waarom zou dat niet kunnen?

Het web betreft eigenlijk alleen het netwerk van aan elkaar gelinkte HTML pagina's op het Word Wide Web. WWW != Internet.

Web-services communiceren slechts via HTTP (of andere protocollen, SOAP is transport onafhankelijk). Uiteraard is HTTP wel het protocol waar ook het web gebruik van maakt .

Een betere benaming zou wellicht simpelweg 'service', 'remote-service' of een een of ander vaag acroniem zijn geweest .

[Verwijderd]

Op donderdag 06 juni 2002 13:37 schreef mbravenboer het volgende:

[..]
Een betere benaming zou wellicht simpelweg 'service', 'remote-service' of een een of ander vaag acroniem zijn geweest .

Goed, ik ben het met je argumenten eens dat 'service' of 'remote-service' beter is. In de volksmond (maar dat willen we natuurlijk niet weten...) kan een webservice gewoon via het internet worden aangesproken.