[alg/java] Server-client vs Stand-alone - Softwareontwikkeling

donderdag 6 februari 2003 12:30

Acties:

(inspiratie == 0) -> true

Topicstarter

Ik was even aan het brainstormen (met mezelf

) over een applicatie voor m'n werk; het moet bijv. kostprijsberekening bevatten, offertes kunnen maken, e.d.

Da is opzich natuurlijk niet zo'n probleem, maar ik ben er nog steeds niet uit of ik er een server-client app van maak of stand-alone, en als het server-client wordt, wat er dan allemaal door de server afgehandeld moet worden en wat door de client.
De DB kan ik waarschijnlijk het beste direct aanspreken, dat scheelt weer een laag (en dus tijd). Maar hoe zit dat bijv. met logging, het is wel handig als dat op een centrale plek (op de server) gebeurd, en niet voor elke pc een andere log-file. En het aan- en af-melden van users, gaat dat naar de server, of zetten we een boolean veld in de DB (persoonlijk vind ik het netter om dat via de server te doen).

Mijn vraag komt dus hierop neer:
- Wanneer maak je gebruik van server-client
- Wat wordt er door de server afgehandeld en wat door de client (in geval van server-client uiteraard)

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

donderdag 6 februari 2003 13:07

Acties:

whoami

NetForce1 schreef op 06 February 2003 @ 12:30:

De DB kan ik waarschijnlijk het beste direct aanspreken, dat scheelt weer een laag (en dus tijd).

Da's niet de goeie manier van denken.

In de initiele fase zal het misschien tijd schelen, maar wat als uw applicatie ook met andere data-sources moet kunnen praten? Het is toch wel het handigst om uw software in verschillende lagen op te splitsen.

Mijn vraag komt dus hierop neer:
- Wanneer maak je gebruik van server-client
- Wat wordt er door de server afgehandeld en wat door de client (in geval van server-client uiteraard)

Wanneer maak je gebruik van client/server? Als je meerdere clients hebt die dezelfde data moeten kunnen accessen.
Wat doe je op de server: Op de database server doe je alles wat met de databank te maken heeft: zorg ervoor dat je zoveel mogelijk stored procedures gebruikt ipv 'plain queries', dat scheelt in performance en zorgt ook voor meer veiligheid.
UI doe je op de client

https://fgheysels.github.io/

donderdag 6 februari 2003 13:39

Acties:

NetForce1

(inspiratie == 0) -> true

Topicstarter

zorg ervoor dat je zoveel mogelijk stored procedures gebruikt ipv 'plain queries', dat scheelt in performance en zorgt ook voor meer veiligheid.

Nu het toch over veiligheid gaat, is het ook handig om het dataverkeer tussen de server en de client te versleutelen? Dit is uiteraard beter, wanneer gebruikt gemaakt wordt van een WLAN, maar dat is niet het geval. Ook draaien er maar vier pc's. Zelf denk ik dat het wel beter is, want TCP/IP gooit de data gewoon in plain text over de draad toch?

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

donderdag 6 februari 2003 13:40

Acties:

whoami

NetForce1 schreef op 06 februari 2003 @ 13:39:
[...]

Nu het toch over veiligheid gaat, is het ook handig om het dataverkeer tussen de server en de client te versleutelen? Dit is uiteraard beter, wanneer gebruikt gemaakt wordt van een WLAN, maar dat is niet het geval. Ook draaien er maar vier pc's. Zelf denk ik dat het wel beter is, want TCP/IP gooit de data gewoon in plain text over de draad toch?

Hmm.... Zoiets heb ik nog nooit gedaan. Ik denk ook niet dat het echt veel nut heeft. Misschien dat anderen daar een ander idee over hebben...

https://fgheysels.github.io/

donderdag 6 februari 2003 14:03

Acties:

kenneth

achter de duinen

Encryptie moet op netwerkniveau gebeuren, anders zou iedere App die iets met het netwerk doet zelf 'n encryptielaag implementeren. Lijkt me erg redundant.

Look, runners deal in discomfort. After you get past a certain point, that’s all there really is. There is no finesse here.

donderdag 6 februari 2003 14:22

Acties:

Bobco

I used to dream about Verona.

whoami schreef op 06 February 2003 @ 13:07:

Wanneer maak je gebruik van client/server? Als je meerdere clients hebt die dezelfde data moeten kunnen accessen.
Wat doe je op de server: Op de database server doe je alles wat met de databank te maken heeft: zorg ervoor dat je zoveel mogelijk stored procedures gebruikt ipv 'plain queries', dat scheelt in performance en zorgt ook voor meer veiligheid.
UI doe je op de client

UI kun je ook prima op de server implementeren. In een pure Java-oplossing zou je zoiets doen met JSP en servlets. JSP's voor de 'echte' presentatie en servlets voor het afhandelen van de business logica en het benaderen van de database.

Een weboplossing is erg makkelijk doordat je gewoon een bestaande web browser kunt gebruiken, en dat kan veel bouwwerk schelen.

With the light in our eyes, it's hard to see.

donderdag 6 februari 2003 14:42

Acties:

whoami

[nohtml]

Bobco schreef op 06 February 2003 @ 14:22:
[...]

UI kun je ook prima op de server implementeren. In een pure Java-oplossing zou je zoiets doen met JSP en servlets. JSP's voor de 'echte' presentatie en servlets voor het afhandelen van de business logica en het benaderen van de database.

Als je het over een webapplicatie hebt, dan kan je UI ook gedeeltelijk op de server implementeren.
Echter, om een goede response te hebben, zal je ook gebruik moeten maken van JavaScript, wat dan weer op de client gebeurd.

https://fgheysels.github.io/

donderdag 6 februari 2003 15:32

Acties:

NetForce1

(inspiratie == 0) -> true

Topicstarter

Bobco schreef op 06 februari 2003 @ 14:22:
[...]

UI kun je ook prima op de server implementeren. In een pure Java-oplossing zou je zoiets doen met JSP en servlets. JSP's voor de 'echte' presentatie en servlets voor het afhandelen van de business logica en het benaderen van de database.

Een weboplossing is erg makkelijk doordat je gewoon een bestaande web browser kunt gebruiken, en dat kan veel bouwwerk schelen.

Ik denk dat het handiger is om daar nu nog niet aan te beginnen, aangezien in nog een aardige newbie ben in Java lijkt het me beter om eerst Java goed onder de knie te krijgen, en daarna naar Servlets en JSP te kijken.

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

donderdag 6 februari 2003 21:46

Acties:

NetForce1

(inspiratie == 0) -> true

Topicstarter

En een protocol, hoe kan ik dat het beste regelen?
Ik dacht zelf aan zoiets:

client: FUNCTIE ARG1, ARG2
server: OK of FOUT FOUTNR, BESCHRIJVING

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

donderdag 6 februari 2003 21:52

Acties:

Alarmnummer

-= Tja =-

Waarom zou je een protocol willen maken? Het is vooral handig als de client en server in volledig andere talen opgesteld moeten worden, en er niet van zo`n complex systeem als Corba gebruikt gemaakt kan worden.

Als jij java/java gaat doen, dan zou ik gewoon RMI gebruiken omdat dit veel handiger is dan zelf een protocol in elkaar te zetten.

donderdag 6 februari 2003 22:04

Acties:

hobbit_be

dan nog wel liever XML-RPC wat toch meer standaard is... en als je het mooi abstract maakt maakt het dan ook niet meer uit waar je je code doet.

donderdag 6 februari 2003 22:18

Acties:

NetForce1

(inspiratie == 0) -> true

Topicstarter

Alarmnummer schreef op 06 februari 2003 @ 21:52:
Waarom zou je een protocol willen maken? Het is vooral handig als de client en server in volledig andere talen opgesteld moeten worden, en er niet van zo`n complex systeem als Corba gebruikt gemaakt kan worden.

Als jij java/java gaat doen, dan zou ik gewoon RMI gebruiken omdat dit veel handiger is dan zelf een protocol in elkaar te zetten.

hobbit_be schreef op 06 februari 2003 @ 22:04:
dan nog wel liever XML-RPC wat toch meer standaard is... en als je het mooi abstract maakt maakt het dan ook niet meer uit waar je je code doet.

Oke thanks, ik had alleen nog maar ff in me Java Bijbel zitten kijken. Zal over beide opties es wat info opzoeken, als u toevallig nog een linkje weet hou ik me aanbevolen

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

donderdag 6 februari 2003 22:31

Acties:

mbravenboer

Java Tutorial: RMI en Corba.

Java Web Services Tutorial: Java API for XML-based RPC, Java API for XML Messaging

XML-RPC standaard: http://www.xml-rpc.com/

XML en Corba zijn goede oplossingen als er de kans bestaat dat er ooit nog eens samengewerkt moet worden met componenten die geschreven worden in andere talen. XML is op dit punt waarschijnlijk toch nog wel te verkiezen boven een Corba oplossing, maar je moet wel rekening houden met een mindere performance bij uitwisseling van berichten in XML formaat.

RMI is interessant als je waarschijnlijk toch wel in Java blijft. RMI is in feite echter slechts een notatie standaard voor gedistribueerde systemen en kan je ook gebruiken op basis van Corba en zelfs eigenlijk op basis van een XML protocol.

Blog, Stratego/XT: Program Transformation, SDF: Syntax Definition, Nix: Software Deployment

donderdag 6 februari 2003 23:15

Acties:

NetForce1

(inspiratie == 0) -> true

Topicstarter

Een vriend van mij gaf net aan over de chat dat hij het onzin vond om zelf een server te bouwen, omdat ik alleen met de DB communiceer.
Zijn er hier mensen die er ook zo over denken of moet ik het iets genuanceerder zien?

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

maandag 10 februari 2003 15:34

Acties:

NetForce1

(inspiratie == 0) -> true

Topicstarter

niemand meer?

De wereld ligt aan je voeten. Je moet alleen diep genoeg willen bukken...
"Wie geen fouten maakt maakt meestal niets!"

maandag 10 februari 2003 15:53

Acties:

Alarmnummer

-= Tja =-

NetForce1 schreef op 06 February 2003 @ 23:15:
Een vriend van mij gaf net aan over de chat dat hij het onzin vond om zelf een server te bouwen, omdat ik alleen met de DB communiceer.
Zijn er hier mensen die er ook zo over denken of moet ik het iets genuanceerder zien?

Als jij altijd maar 1 applicatie hebt om met de db te praten dan maakt het volgens mij niet zoveel uit. Maar als er na verloop van tijd meerdere applicaties ontwikkeld gaan worden dan zal je dus meerdere keren domein logica moeten gaan implementeren.En verder gaat het vrij lastig worden om nog iets aan de structuur te veranderen, omdat er meerdere applicaties van afhankelijk zijn.

Als je gaat werken met een domein laag (2e tier) die door meerdere clients gebruikt kan worden, dan kan je in ieder geval alle domein logica daar naar toe verhuizen. En verder gaat het wat eenvoudiger worden om iets aan het model te veranderen, omdat je dan (hopelijk) alleen bij die 2e tier iets hoeft aan te passen.