[Database] Directe connectie of Webservice

[IntoDevel]

Ik ben bezig met het ontwikkelen van een applicatie die in wezen uit drie onderdelen bestaat:
- Database
- Desktop Client
- Web Application

Tijdens het ontwerpen loop ik eigenlijk tegen een belangrijke keuze aan. Hoe kan ik het beste de database benaderen? Naar mijn mening zijn er twee opties, doormiddel van een directe verbinding vanuit de desktop client en web app of doormiddel van een tussenliggende webservice die de data bewerkingen doet.

Ik vraag mij af wat de best practice is, ook met betrekking tot security. Bij voorbaat dank!

[Kalentum]

Een webservice. Geen discussie over mogelijk lijkt me. Als je rechtstreeks op de centrale database gaat werken zul je merken dat je code twee keer moet schrijven: 1x voor de webapp en 1x voor de desktop. Dus stop zoveel mogelijk functionaliteit in de tussenlaag. Als je het goed doet zullen die twee applicaties vrijwel uitsluitend code bevatten die voor de user interface nodig is.

Qua beveiliging: kijk eens hoe bekende websites die ook een web-API hebben de beveiliging doen (denk aan Twitter, Facebook, diverse Google-diensten, Delicious etc). Beveiliging hangt ook af van de aard van gegevens: een webservice voor het opvragen van iets als weer-informatie kan zwakker zijn dan een webserivce waar persoonsgegevens in verwerkt worden.

[Janoz]

Webapp gewoon rechtstreeks (uiteraard wel 3 tier). In de webapp ontsluit je de servicelaag vervolgens ook via webservices en deze worden door je desktop app gebruikt.

[IntoDevel]

Thanks voor jullie reactie, erg fijn om bevestigd te krijgen wat ik al vermoedde, ik ga er mee aan de slag.

Als gevolg nog een best practice vraag. Ik heb vaker webservices gebruikt, maar vaak voor kleine dingen, nu is dit project wat groter en dat vereist wat andere keuzes. Stel dat je een database hebt met meerdere tabellen, customers, products, shops enzovoorts. Is het dan beter om webservices te beperken tot een specifiek object, bijvoorbeeld een service die de customers afhandelt, een service voor de producten enzovoorts? Of stop je alles in 1 webservice? Ik heb een object georienteerde achtergrond en het Webservice verhaal gaat daar naar mijn gevoel juist wat tegenin omdat er erg veel functionaliteit op 1 punt komt te liggen, daarom zou ik neigen naar de eerste optie. Wat is jullie mening?

[ Voor 76% gewijzigd door IntoDevel op 11-09-2010 16:00 . Reden: Vervolg vraag ]

[Freeaqingme]

Wanneer jij een goede servicelaag hebt, kan je toch gewoon deze omtoveren tot een webservice via apart entrypoint? Het geheel moet uiteraard 1 service voorstellen. Hoe zou jij meerdere services voor dezelfde applicatie voor je zien?

[YopY]

'Webservice' is in dezen een brede term voor het ontsluiten van je gegevens, en hoewel je het wel als een enkel object zou kunnen modelleren is het beter om het als een module van je programma te bekijken.

Je hebt op zich maar één generieke webservice - de data-toegang webservice. Daar kun je parameters aan doorgeven afhankelijk van de gegevens die je wilt - customer met id zoveel, dat soort dingen. 'customer' en 'id' zijn dan parameters. Intern in je webservice heb je dan weer iets dat requests voor customers afhandelt, of in ieder geval een soort van router die het request doorstuurt naar de juiste service.

Weet niet of dat logisch klinkt, maar de basis is: ga geen code kopiëren. Je hoeft niet aparte webservices te maken voor je data, je moet je ene webservice gewoon eenvoudig houden en verzoeken om gegevens doorsturen naar de relevante module.

("ga geen code kopiëren" is ook waarom je dus er een webservice van kunt maken, ipv twee aparte programma's die beide met de database communiceren)

[__fred__]

Webservices zijn imho geen heilige graal en kosten nogal wat extra tijd om te implementeren. Die extra tijd moet je wat mijn betreft kunnen "verantwoorden". Argumenten voor zouden kunnen zijn:

• De applicatie draait over internet. Er zijn nogal wat argumenten waarom het niet prettig is om je SQL queries over internet te laten vliegen.
• Je wilt de functionaliteit van de applicatie beschikbaar stellen als API.

Als je gewoon een intranetwebapplicatie en een desktop client voor op hetzelfde netwerk implementeert, is het prima verdedigbaar om een business layer in de vorm van een DLL te ontwikkelen, die je onder beide applicaties hangt. Je voorkomt daarmee nogal wat plumbing code en een extra abstractielaag met bijbehorende problematiek (performance vanwege (de)serializatie, stateless design om rekening mee te houden, etc).

Als je toch hip services wilt doen dan kun je ook eens naar .NET RIA services kijken, bespaart weer plumbing.

[Hydra]

__fred__ schreef op zondag 12 september 2010 @ 09:47:
Webservices zijn imho geen heilige graal en kosten nogal wat extra tijd om te implementeren.

Vind ik nogal overdreven eigenlijk. Tegenwoordig hoef je webservices niet meer from scratch helemaal zelf te bouwen. De hele SOAP laag heb je niks meer mee te maken. Je zet gewoon in een WSDL in elkaar (en daar heb je prima grafische designers voor), genereert aan de hand van die WSDL je code, en je hoeft van alleen maar je business logic nog maar te implementeren, iets wat je sowieso moet doen. Of je die logica in een business DLL hangt die door beide apps gebruikt wordt of in een webservice maakt kwa tijdsinspanning weinig uit.

Het grote voordeel van webservices is dat je een duidelijk contract hebt kwa interface, en dat eigenlijk alles aan de ahnd van dat contract met je webservice kan praten. Voor vrijwel elke taal zijn er generators beschikbaar die de client classes voor je uitgenereren, dus je kunt enorm simpel een Java webapp samen met een .Net desktop app laten praten met je webservice. Dit is een stuk lastiger met een 'business DLL' omdat je deze zal moeten vertalen tussen bijvoorbeeld .Net en Java (niet onmogelijk, maar zeker niet triviaal).

IntoDevel schreef op zaterdag 11 september 2010 @ 15:46:
Thanks voor jullie reactie, erg fijn om bevestigd te krijgen wat ik al vermoedde, ik ga er mee aan de slag.

Als gevolg nog een best practice vraag. Ik heb vaker webservices gebruikt, maar vaak voor kleine dingen, nu is dit project wat groter en dat vereist wat andere keuzes. Stel dat je een database hebt met meerdere tabellen, customers, products, shops enzovoorts. Is het dan beter om webservices te beperken tot een specifiek object, bijvoorbeeld een service die de customers afhandelt, een service voor de producten enzovoorts? Of stop je alles in 1 webservice? Ik heb een object georienteerde achtergrond en het Webservice verhaal gaat daar naar mijn gevoel juist wat tegenin omdat er erg veel functionaliteit op 1 punt komt te liggen, daarom zou ik neigen naar de eerste optie. Wat is jullie mening?

Ik werk op dit moment mee aan een groot project voor de overheid waarbij alle 'functiepunten' verserviced zijn. Dit houdt dus in dat in het functioneel design functies geidentificeerd zijn, en deze zijn elk in aparte services gehangen. Waarom? Omdat dit kwa uitwerken makkelijker is. Als je een kleine service hebt waaraan je aan de WSDL al precies kan zien wat 'ie als invoer en uitvoer verwacht, kan 1 iemand zonder problemen zo'n webservice aanpassen ook als hij niet de originele programmeur is.

Dus ik zou zeker functionele gebieden afscheiden en onderbrengen in aparte services, in ieder geval kwa interface. Onderhuids kunnen de services natuurlijk nog steeds gebruik maken van gedeelde code in e vorm van libraries.

[ Voor 39% gewijzigd door Hydra op 13-09-2010 12:37 ]

[__fred__]

Hydra schreef op maandag 13 september 2010 @ 12:32:

Vind ik nogal overdreven eigenlijk. Tegenwoordig hoef je webservices niet meer from scratch helemaal zelf te bouwen. De hele SOAP laag heb je niks meer mee te maken. Je zet gewoon in een WSDL in elkaar (en daar heb je prima grafische designers voor), genereert aan de hand van die WSDL je code, en je hoeft van alleen maar je business logic nog maar te implementeren, iets wat je sowieso moet doen. Of je die logica in een business DLL hangt die door beide apps gebruikt wordt of in een webservice maakt kwa tijdsinspanning weinig uit.

Het grote voordeel van webservices is dat je een duidelijk contract hebt kwa interface, en dat eigenlijk alles aan de ahnd van dat contract met je webservice kan praten. Voor vrijwel elke taal zijn er generators beschikbaar die de client classes voor je uitgenereren, dus je kunt enorm simpel een Java webapp samen met een .Net desktop app laten praten met je webservice. Dit is een stuk lastiger met een 'business DLL' omdat je deze zal moeten vertalen tussen bijvoorbeeld .Net en Java (niet onmogelijk, maar zeker niet triviaal).

Ik ging er eigenlijk al vanuit dat de TS de web services zou genereren of een RAD ide zoals visual studio ging gebruiken, niemand bouwt hopelijk meer web services op het niveau van SOAP messages, tenzij het noodzakelijk is. Maar dan nog heb je te maken met stateless design, proxy classes, serialization etc. Als er geen reden is (zoals bijvoorbeeld door jou aangehaald, interoperatiblity tussen systemen) is het overkill. Abstractie om wille van abstractie.

Hydra schreef op maandag 13 september 2010 @ 12:32:

Ik werk op dit moment mee aan een groot project voor de overheid waarbij alle 'functiepunten' verserviced zijn. Dit houdt dus in dat in het functioneel design functies geidentificeerd zijn, en deze zijn elk in aparte services gehangen. Waarom? Omdat dit kwa uitwerken makkelijker is. Als je een kleine service hebt waaraan je aan de WSDL al precies kan zien wat 'ie als invoer en uitvoer verwacht, kan 1 iemand zonder problemen zo'n webservice aanpassen ook als hij niet de originele programmeur is.

Dus ik zou zeker functionele gebieden afscheiden en onderbrengen in aparte services, in ieder geval kwa interface. Onderhuids kunnen de services natuurlijk nog steeds gebruik maken van gedeelde code in e vorm van libraries.

Er zit wellicht een wat zelf documenterend effect in een goede wsdl definitie, maar dat is ook iets wat je met doxygen of een andere documentatietool kunt genereren. Bovendien ontslaat het je niet van verplichtingen om andere documentatie aan te leggen of nog belangrijker: Gewoon een goed ontwerp te maken. Ik heb het vermoeden dat de overheidsapplicatie qua complexiteit en omvang het project van de TS vele malen overstijgt en er aan dat project hele andere eisen worden gesteld.

Het is m.i. slecht verdedigbaar als er op een project maar één programmeur zit, die applicaties ontwikkelt die niet met de buitenwereld communiceren, om dan een volledige servicelayer aan te leggen met als resultaat extra ontwikkeldtijd en een negatief effect op de performance.

[Hydra]

__fred__ schreef op maandag 13 september 2010 @ 17:58:
Het is m.i. slecht verdedigbaar als er op een project maar één programmeur zit, die applicaties ontwikkelt die niet met de buitenwereld communiceren, om dan een volledige servicelayer aan te leggen met als resultaat extra ontwikkeldtijd en een negatief effect op de performance.

Ik vind dat mensen eens moeten ophouden te klagen over die performance. Dat is echt een compleet nonissue. Dat deserializen van een beetje XML valt in de meeste gevallen compleet in het niets bij de querytijden op de achterliggende DB.

Ik ben het met je eens dat als je zeker weet dat je beide applicaties kunnen gaan praten met een business DLL, en je zeker weet dat er verder niks bij gaat komen, je niet voor een WS hoeft te gaan, maar ik ben het niet eens met argumenten daartegen. Het parsen van de XML is een nonissue, evenals de extra ontwikkeltijd, die is t.o.v. het bouwen van een business 'DLL' max een of twee dagen extra. En juist het stateless moeten werken heeft voordelen: als later blijkt dat een 1 appserver de load niet aankan is een stateless WS veel makkelijker te schalen dat een stateful applicatie. Hoeveel programmeurs er op een project zitten maakt m.i. ook niet uit, je moet er NOOIT vanuit gaan dat je de eerste en de laatste dev bent die aan een applicatie werkt.

Wat betreft het 'contract' dat een WSDL is: naast het documenterende effect is het niet alleen maar documentatie, het is ook gewoon een contract. Dus de interface staat vast, en daar zullen beide partijen zich aan moeten houden. Dit heeft als voordeel dat je aan de client side de hele WS client uit kunt laten genereren, en dat je aan de server kant indien mogelijk de hele WS kunt vervangen door een andere met hetzelfde contract, en op die manier volledig transparant de hele backend kunt vervangen.

Helaas heeft de TS niet laten weten op welke platformen de app en de webapp gebaseerd zijn. Als die niet gebaseerd zijn op hetzelfde platform, is al snel een WS 'the way to go'.

Ik zeg niet dat de TS naar een WS architectuur moet gaan, maar een dergelijke architectuur heeft een hoop voordelen en m.i. erg weinig nadelen.

[ Voor 29% gewijzigd door Hydra op 14-09-2010 10:45 ]