.Net: Webservices voor toegang Business laag

[neothor]

Voor een project waar ik mee bezig ben wil graag de business/data laag scheiden van de presentatie laag door middel van webservices. De business assembly zal dus niet direct gebruikt worden alleen maar de webservices.

Ik wil dit doen zodat het makkelijk de zelfde business laag gebruikt kan worden door meerdere presentatie lagen of 3den voor export/import.

Het idee is dus als volgt.


De code hiervoor is niet heel spannend en daar maak ik me ook geen zorgen om. Wel vraag ik me af wat is de impact hiervan performance technisch gezien. Ik zou graag van andere horen wat hun mening hierover is.

[RobIII]

neothor schreef op maandag 13 juli 2009 @ 15:23:
Wel vraag ik me af wat is de impact hiervan performance technisch gezien.

Tja; je hebt de "overhead" van de webservice en natuurlijk de impact van de snelheid van de lijn etc.; veel zinnigers valt er, denk ik, op je nogal brede vraag niet te zeggen. Waar ben je precies naar op zoek (als in: welke gegevens)? Wat versta je onder "performance technisch gezien"?

[ Voor 12% gewijzigd door RobIII op 13-07-2009 15:40 ]

[Niemand_Anders]

Elke vorm van 'abstractie' zorgt voor iets performance verlies. Afhankelijk van hoe je de webservice aanbied bepaald het verlies van performance. De grootste performance verlies post is de serialisatie/deserialisatie slag en het transport van de geserialiseerde informatie. XML is groter dan binary serialization en kost dus meer tijd om over te sturen bij gelijke snelheid.

Maar stel dat de import tweemaal zo lang duurt, is dat dan zo erg? Het grote voordeel van een webservice ipv van een losse assembly is dat zij (derde partijen) vanuit PHP, Ruby of Java ook zeer eenvoudig kunnen aansluiten.

Persoonlijk zou ik de presentatie laag niet gebruik laten maken van de webservice. De webservice moet je meer zien als een alternatieve presentatie laag. Een blog heeft normaal een HTML presentatie maar middels een feed webservice kun je de informatie anders tonen.

[ Voor 1% gewijzigd door Niemand_Anders op 13-07-2009 15:41 . Reden: typos ]

[riezebosch]

Sowieso lijkt het mij een goed idee om met WCF te gaan werken in plaats van "oude" webservices (asmx).

[whoami]

riezebosch schreef op maandag 13 juli 2009 @ 15:59:
Sowieso lijkt het mij een goed idee om met WCF te gaan werken in plaats van "oude" webservices (asmx).

Waarom ?
Ok, WCF is nieuwer, maar biedt het in de situatie van de TS een toegevoegde waarde ? WCF is ook wat complexer qua config, etc.... Er komt gewoon veel meer bij kijken.

Performance-verlies komt er zowiezo bij kijken, bij deze aanpak. Zoals Niemand_Anders al aangedragen heeft, kan je niet om het serializeren/deserializen en transport heen.

Zorg er zeker voor dat je geen 'chatty' interface hebt, maar eerder een chunky interface; het is dus beter om een beperkt aantal keren een roundtrip te doen naar je webservice, en desnoods meer informatie dan nodig terug te krijgen, dan meerdere keren je service aan te spreken, en bij iedere roundtrip een klein beetje info terug te krijgen.

[Janoz]

Ik vraag me af of je wel de juiste keuze aan het maken bent. Ik krijg een beetje een 'premature overdesign' gevoel. Nu ken ik uiteraard de feature en requirements lijst niet, maar staat bijvoorbeeld nu al vast dat er meerdere presentatielagen gebruik gaan maken van je business layer? Je argument dat ook 3en gebruik willen maken van de laag lijkt me niet steekhoudend. Ik zou daar het liefst nog een laag tussen hebben voor authenticatie en authorisatie. Daarnaast is er vast maar een subset aan functionaliteit die je extern aan wilt bieden.

IMHO is de enige valide situatie om de scheiding tussen presentatie en business logic op deze manier toe te passen wanneer je nu al weet dat de business logic en de presentation logic op aparte servers draaien gaat. In alle andere gevallen zou ik het inderdaad wel via interfaces loskoppelen, maar vervolgens 'native' implementeren. Een scheiding kan dan later altijd nog geimplementeerd worden mocht het ooit nodig zijn.

[OMX2000]

De enige reden waarom ik webservices zou gebruiken als je een open interface wilt aanbieden. Dus wanneer je een dienst wilt aanbieden die op een gestandaardiseerde platform-onafhankelijke manier wordt ontsloten.

Dus als je nu al weet dat je verschillende soorten clients van je business laag dan zou ik voor webservices gaan. Zo niet neem dan een native interface.

[Daspeed]

Vergeet niet dat als je met webservices werkt, het werken met (database) transacties wel wat lastiger wordt (WCF heeft daar geloof ik wel weer wat voor).

[whoami]

Daspeed schreef op maandag 13 juli 2009 @ 19:20:
Vergeet niet dat als je met webservices werkt, het werken met (database) transacties wel wat lastiger wordt

Hoezo dan ?
Je webservice is dan gewoon verantwoordelijk voor het afhandelen van transacties, en je zal je webservice zo moeten ontwerpen dat je geen transacties over meerdere requests spant.

[RobIII]

whoami schreef op maandag 13 juli 2009 @ 20:51:
Je webservice is dan gewoon verantwoordelijk voor het afhandelen van transacties, en je zal je webservice zo moeten ontwerpen dat je geen transacties over meerdere requests spant.

En zélfs dat kan nog wel maar vereist wel wat meer werk en of het verstandig is hangt van de implementatie af en laat ik verder, in het algemeen, in 't midden.

[Daspeed]

whoami schreef op maandag 13 juli 2009 @ 20:51:
[...]

Hoezo dan ?
Je webservice is dan gewoon verantwoordelijk voor het afhandelen van transacties, en je zal je webservice zo moeten ontwerpen dat je geen transacties over meerdere requests spant.

Dat kan in sommige gevallen nog best een uitdaging zijn. En ja, het kan waarschijnlijk in heel veel gevallen wel, maar 't wordt nooit zo makkelijk als wanneer je gewoon alles in-process zou doen

Maar misschien had ik mijn reply beter als volgt kunnen formuleren:

Vergeet niet dat als je met webservices werkt, het werken met (database) transacties in sommige situaties wel wat lastiger kan worden

[ Voor 18% gewijzigd door Daspeed op 13-07-2009 22:09 ]

[neothor]

Ik zou graag webservices willen gebruiken zodat het makkelijker is voor import en export van gegevens en integratie binnen een ander project. Daarnaast maakt het mogelijk om makkelijk een nieuwe app er op te bouwen (php, windowsforms).

En natuurlijk zal er autorisatie en authenticatie worden uitgevoerd.We willen immers niet dat iedereen allerlij aanpassingen kan maken.

Maar ik merk aan de hand van dit topic dat ik maar eens de voor en nadelen voor mezelf moet opstellen. Ben wel bereid wat performance op te geven voor uitbreidbaarheid. Maar ben niet de enige in het project

Thnks

[whoami]

neothor schreef op dinsdag 14 juli 2009 @ 08:47:
Ik zou graag webservices willen gebruiken zodat het makkelijker is voor import en export van gegevens en integratie binnen een ander project. Daarnaast maakt het mogelijk om makkelijk een nieuwe app er op te bouwen (php, windowsforms).

Daar hoef je toch niet persé webservices voor te gebruiken ?
Als je je project zo structureert dat je herbruikbare logica in een goed objectmodel zit, in aparte assemblies, dan kan je dat toch ook ?

Daarbovenop kan je dan een WS laag schrijven die je kan gebruiken in bepaalde gevallen mocht dat nodig zijn. (Natuurlijk ga je die WS laag pas schrijven als het nodig is)

[ Voor 14% gewijzigd door whoami op 14-07-2009 08:57 ]

[neothor]

Ik wil dus de assemblies zo min mogelijk verspreiden.

[Janoz]

Ik blijf erbij dat je verkeerd om aan het redeneren bent. "Ik wil webservices want.....". Webservices zou juist het eindpunt van de redenatie moeten zijn, niet het beginpunt. JE maakt het project op dit moment nodeloos complex omdat je alles geforceerd op dezelfde plek wilt ontkoppelen. En dat terwijl er op dit moment nog geen concrete voorbeelden zijn van de verschillende implementaties. Je voegt niet een beetje performance verlies toe, maar een enorme berg performance verlies plus een extra berg complexiteit. Transacties, security, applicatie en server inrichting.

IMHO is de enige legitieme reden voor een dergelijke ontkoppeling een situatie waarbij de view op een andere server draait dan de business logic, maar dat heb ik eerder ook al gezegd. Als ik jou was zou ik gewoon beginnen met netjes middels interfaces gescheiden tiers die vervolgens native geimplementeerd zijn, waarbij rekening gehouden wordt dat ze remote uitgevoerd kunnen worden (zorg er dus voor dat doorgegeven objecten of immutabel zijn, of een deep copy). Dan kun je het ontkoppelen later altijd nog doen mocht het nodig zijn.

Sowieso zou ik externe applicaties niet rechtstreeks laten koppelen. Daarvoor kun je beter een aparte view implementeren. Op die manier houd je je interne interfaces helemaal in eigen beheer en hoef je alleen de externe view stabiel te houden bij het onderhoud.