Component based development

[Poiter]

Voor een project ben ik bezig met het zoeken naar de juiste architectuur voor een n-tier applicatie. We willen een object-georienteerd business-model implementeren in een aparte tier. Een soortgelijk iets heb ik al eens succesvol geimplementeerd, maar met andere technologie. Deze keer willen we Visual Studio.NET gebruiken om het geheel te implementeren. Hierbij moet het zowel mogelijk zijn om een gewone windows-applicatie als een Web-appicatie op de business-logica aan te sluiten.

De meeste projecten die object-oriënted programmeren bedoelen hiermee dat ze de programma-code als objecten zien en behandelen, wij willen een implementatie waarbij ook de data zelf echte objecten worden. Voor elk entiteit zal dus een class gedefinieerd worden(simpel gezegt).

Met deze randvoorwaarden blijven er echter nog genoeg vragen en moeilijkheden over. Moeten we per class een component maken? Moeten deze componenten statefull of stateless zijn? (of misschien een combinatie?) Moet de businesslaag zelf misschien ook nog uit meerdere lagen bestaan? Hoe gaan we om met transacties naar de database? Hoe zit het met threading problematiek in COM+ ?? Kortom allemaal vragen waar nog een antwoord op moet komen.

Er zijn meerdere oplossingen van het vraagstuk mogelijk, ik zoek dus naar pro's en contra's van de verschillende mogelijkheden, en naar mensen die hier ervaring mee hebben. Ook links naar documentatie hierover is welkom. Genoeg over OO te vinden, maar toch maar heel weinig over deze vraagstukken.

[CyberSnooP]

Dit vraagt om een XML pleidooi van mbravenboer of andere xml-freaks

[Verwijderd]

Ik heb zoiets met Java een keer geimplementeerd. Een Framework gemaakt waarbij voor elke dataclass een object werd gemaakt, voor lijsten van objecten zat het net even iets anders, maar dat ging ook goed. Met dit framework wordt de database door de code zelf aangepast ten opzichte van de geladen classes. Daarnaast kan de flow van het hele programma met behulp van custom Businessrules bepaalt worden. De views van de objecten worden ook default gegenereerd en zijn ook custom te maken. Het grote voordeel van dit framework is dat het heel goed reproduceerbaar is, mits het goed is opgezet. Met dit framework kan je nu snel een grote databaseapplicatie in elkaar draaien.

[mbravenboer]

CyberSnooP: Dit vraagt om een XML pleidooi van mbravenboer of andere xml-freaks

Het gaat hier volgens mij vooral om de implemtatie van de 'business-logica' (ik verzin het niet ) en niet zozeer om de vraag hoe je gaat communiceren met deze laag. Voor deze communicatie is XML wellicht interessant, maar dat legt .NET in feite al op .

De meeste projecten die object-oriënted programmeren bedoelen hiermee dat ze de programma-code als objecten zien en behandelen, wij willen een implementatie waarbij ook de data zelf echte objecten worden. Voor elk entiteit zal dus een class gedefinieerd worden(simpel gezegt).

Hum, dit vind ik een erg vaag stuk. Als je in een OO-applicatie geen klassen hebt voor je entiteiten/domein-objecten/hoe-je-het-ook-wilt-noemen ben je behoorlijk verkeerd bezig .

Je zou eens wat documentatie door kunnen nemen over Enterprise Java Beans (EJB, Java dus). Dit is een manier van werken die een makkelijk raamwerk biedt om component-georienteerde te werken en je logica op een fraaie wijze te implementeren als je zelf geen idee hebt hoe je dit beter aan kunt pakken (business logic voor newbies dus). J2EE verplicht absoluut niet het gebruik van EJB, maar biedt deze oplossing aan als standaard-architectuur.

Java is natuurlijk een heel ander terrein, maar omdat EJB is al vrij 'established' en er is veel documentatie over te vinden. Het vergelijken van aanpakken lijkt mij hier dus wel zinvol .

[Poiter]

Ik heb al twee projecten gedaan, waarbij een volledig statefull business model met succes is geïmplementeerd. Een newbe guide zit ik dus niet echt op te wachten Ook heb ik me al het leplazerus gezocht op internet, maar er is gewoon erg weinig dokumentatie over te vinden. Heel veel over OO, maar heel weinig over praktische implementaties met componenten in een aparte business-laag. De voorbeelden die je dan vind zijn van 2 of 3 object systemen zonder interferentie.

De vragen waar ik voornamelijk mee zit zijn deze:
-Elk object een component?

Zo ja: stateless of statefull?
Bij stateless krijg je langere parameterlijsten en meer database-actie. Bij statefull heb je veel meer resources(geheugen) nodig, systeem wordt complexer vanwege bijhouden van alle objecten in geheugen. Hiervoor zul je dus ook een overkoepelend iets moeten hebben die dit regelt.

Zo nee: welke scheiding breng je dan aan in je componenten? Ook weer vraag Statefull of stateless etc..

-Hoe implementeer je relaties tussen objecten? (parent- child) Denk bv aan order met order-regels. Kan een order-regel object geinstantieerd zijn zonder z'n parent? Denk hierbij ook aan early- en late-binding, loosly coupled of niet?.

Zoals al gezegt heb ik ervaring in 2 van dit soort projecten waar al deze vraagstukken op een bepaalde manier zijn opgelost. De vraag is nu hoe je het met de huidge technologie van .NET het beste zou kunnen aanpakken. Graag dus reacties van mensen die hier praktisch ook ervaring mee hebben......

[Verwijderd]

COM+ en .NET??? COM is dood, lang leve COM.

Verder: ik lees hier technisch interessante overwegingen, maar wat ga je maken, wat zijn de vereisten. Tenzij je hobby aan het doen bent, moet je eerst de eisen en randvoorwaarden verzamelen.

Kortom, vertel meer!

[Verwijderd]

Het lijkt me toch volledig van je doel af te hangen.
of je wel of niet stateless enz moet kiezen, tja dat hangt van de situatie af.
misschien is het verstandig om wat meer info te geven over wat je precies wilt met je systeem, in wat voor omgeving enz.

[mbravenboer]

Poiter: Ik heb al twee projecten gedaan, waarbij een volledig statefull business model met succes is geïmplementeerd. Een newbe guide zit ik dus niet echt op te wachten

Nou ik bedoelde eigenlijk niet dat EJB wat voor jou is omdat het voor newbies geschikt is . EJB is meer een 'voorstel' voor een design van business logic. Dit is handig omdat je zo een goed uitgedachte architectuur tot je beschikking krijgt zonder dat je je heel erg diep hoeft te verdiepen in deze stuff.

Voor jou is dat aspect niet interessant, wat denk ik wel interessant is, is om deze architectuur eens te bekijken zodat je ideeen kunt combineren en een bredere kijk op de zaak krijgt .

Heel veel over OO, maar heel weinig over praktische implementaties met componenten in een aparte business-laag. De voorbeelden die je dan vind zijn van 2 of 3 object systemen zonder interferentie.

En das precies m'n punt: van EJB is al wel erg veel documentatie. Complete boeken (ook gratis online), veel artikelen, design patterns voor EJB enzovoorts.

Zoals al gezegt heb ik ervaring in 2 van dit soort projecten waar al deze vraagstukken op een bepaalde manier zijn opgelost.

Ik bedoelde de newbie term dus nogal anders, dus voel je niet aangevallen .

De vraag is nu hoe je het met de huidge technologie van .NET het beste zou kunnen aanpakken. Graag dus reacties van mensen die hier praktisch ook ervaring mee hebben......

Ik heb veel met .NET Remoting gewerkt, maar op vrij technische niveau (brug naar Java RMI). Als je nog niet gewerkt hebt met .NET Remoting zou ik dat eerst eens doen voordat je keuzen gaat maken. .NET Remoting biedt niet alleen web-services maar in feite een compleet gedistribueerd object systeem wat vrijwel alle mogelijkheden biedt qua state, levensduur van remote objecten enzovoorts.

Complete component systemen heb ik nog niet in .NET opgezet, wel in Java, maar aangezien je vooral informatie wilt over de toepassing in .NET lijkt die ervaring misschien niet relevant. In werkelijkheid zijn de verschillen niet zo groot.

[Poiter]

Op maandag 18 februari 2002 23:14 schreef Doekman het volgende:
COM+ en .NET??? COM is dood, lang leve COM.

COM+ wordt nog levendig gebruikt hoor in .NET. Je moet .NET componten in COM+ onderbrengen wil je gebruik kunnen maken van object-pooling, MTS, etc....

We zijn bezig met een pilot-project om de mogelijkheden en onmgelijkheden van .NET te leren kennen, wel met als doel om uiteindelijk in de praktijk toe te passen.

De vraag is niet zozeer hoe we onze specifieke situatie moeten oplossen, dan wel wanneer wat het beste gebruikt kan worden. Dus wanneer wel stateless, of wanneer wel statefull?? Of is hier in het algemeen iets over te zeggen? En is het uberhaupt wel mogelijk om het op de 1 of de andere manier te implementeren; zijn er geen technische beperkingen met .NET??

Wat java en EJB betreft, daar wil ik me op dit moment eigenlijk niet te veel in verdiepen, eerst .NET dan zien we wel verder Maar als er van java/EJB goede dokumentatie over dit onderwerp is, dan ben ik ook zeker geinteresseerd! (links please!) Binnen de .NET dokumentatie (en dat is er nogal wat) ben ik tot nu toe ook niet echt iets hierover tegengekomen, maar ik blijf zoeken. Zal inderdaad het .NET remoting verhaal nog wel eens goed doorspitten

Iedereen in elk geval alvast bedankt voor de reacties!!! (maar waar blijven de links?? )

[Verwijderd]

Wat je volgens mij wil is de:

DataLogica
Bussinesslogica
GUIlogica

scheiden.
Deze manier kun je prima beschrijven volgens UML. Een UML ontwerp kun je vervolgens 1 op 1 vertalen naar je ontwikkel-taal.

UML werkt voortdurend met objecten. Voordat je een regel codeert ligt alles al in het ontwerp vast. De gehele interactie tussen de objecten, etc.

Ik kan je een boek zeer aanraden:

Praktisch UML
van Jos Warmer en Anneke kleppe
ISBN: 90-6789-937-2

Ontwerp maken met Rational Rose (Microsoft Visual Modeler) en automatisch code genereren in VB of C (Volgens mij ook .NET)

[Poiter]

UML ken ik wel en is inderdaad heel handig voor het definieren van je classes en de relaties daartussen. Mijn probleem ligt toch meer bij de praktische invulling van het geheel op de "applicatie-server". Ik ben inmiddels zelf tegen het volgende Microsoft project aangelopen, wat veelbelovend lijkt!! :

http://communities.msn.com/objectspaces

(en de nieuwsgroep microsoft.public.objectspaces )

Voor een ieder die hier ook belangstelling voor heeft

Verder blijkt er inderdaad voor EJB's ook soortgelijke technieken te bestaan, maar daar heb ik me verder nog niet in verdiept.....

[Verwijderd]

de core logic als een webservice bouwen, en 2 clients daarop bouwen: 1 voor windows en 1 voor het web. Dat zijn schillen met eigen gui-support code per client, die voor de data en de applicatie logica gebruik maken van de webservice.

De webservice bouw je in meerdere lagen, waar bij je de core database logic in je DBMS stopt (bv sqlserver) dmv stored procedures, triggers en views, en daarboven verschillende objects bouwt: enerzijds database supporting components die dus dicht bij de database staan en anderzijds de logic waar je applicatie om draait.

n-tier development gaat over het plaatsen van functionaliteit in verschillende lagen. BINNEN die lagen kun je dan kijken naar OO-laagjes met objects, maar staar je er niet blind op. Het is veel belangrijker dat je je functionaliteit in de juiste tier plaatst en implementeert met een nette interface, zodat lagen die leunen op die tier er efficient en scalable mee kunnen werken.

Een n-tier applicatie laat zich dan ook niet in termen van OO designen. Zolang je dus aan dat model vasthoudt, wordt het niet wat. In .NET kun je wel verschillende lagen samennemen en dmv de CLR met elkaar laten samenwerken en dus objects sharen etc. maar een applicatie met een webinterface is stateless, en je vervalt dan automatisch in het storen van state in de database, de bottom tier. OO met allerlei mooie objects is leuk dan, maar dat is stateful programming. Voor de rangschikking van je functionaliteit onmisbaar maar binnen 1 tier, niet als compleet applicatiemodel.

Je data in objects stoppen lijkt aardig, maar in de praktijk wil je een dataset gebruiken, die is bindable met een gui, en makkelijk te verwerken in code, makkelijk te passen naar andere tiers etc. Immers, een n-tier applicatie is bijna altijd stateless, dus data in objects stoppen is er niet bij.

(ik doe dit werk al een aantal jaar, full time, ik heb dezelfde vragen moeten oplossen vorige week, toen ik keek naar een testtraject voor .net (via een testproject leren wat het platform inhoudt) en mijn door de jaren heen verfijnde methodiek mbt n-tier development daar niet 1:1 op afbeeldbaar bleek. Gebruik een webservice voor je logic, en bouw de clients afzonderlijk, dat is mijn conclusie. ZEKER als je meerdere typen clients wilt ondersteunen.)

[Poiter]

Ja dat is ook inderdaad de bedoeling, met een webservice. Het statefull zijn zal alleen binnen de businesslaag zelf gelden, niet naar clients. (dat is ook niet te doen met je transactielogica). Binnen de businesslaag inderdaad meerdere lagen, een data-laag voor de communicatie met de onderliggende datasource (database, files, etc..), een business-object laag, en een interface-laag.

Tot zover geen probleem. Nu het volgende voorbeeld: Client 1 roept een functie aan via de webservice, en deze brengt bv een order-object in de lucht. Als na client 1 een tweede client nu diezelfde functie aanroep doet, is dat order-object dan nog in de lucht? of is er alleen nog een stateless component in de lucht zonder data? of is er helemaal niks meer in de lucht van de eerste aanroep?

[Nielsz]

Op maandag 18 februari 2002 23:14 schreef Doekman het volgende:
COM+ en .NET??? COM is dood, lang leve COM.

COM is zeker niet dood, en het is zeker nog de moeite om je er ff in te verdiepen voordat het niet meer compatible is. .NET is volledig compatible met COM+. Tegen de tijd dat COM dood is kan je nog wel zo'n 5 jaar wachten denk ik.

[Verwijderd]

Op woensdag 20 februari 2002 22:21 schreef Poiter het volgende:
Ja dat is ook inderdaad de bedoeling, met een webservice. Het statefull zijn zal alleen binnen de businesslaag zelf gelden, niet naar clients. (dat is ook niet te doen met je transactielogica). Binnen de businesslaag inderdaad meerdere lagen, een data-laag voor de communicatie met de onderliggende datasource (database, files, etc..), een business-object laag, en een interface-laag.

Nee je hebt geen 'stateful' lagen naast 'stateless' lagen in 1 applicatie, met 1 uitzondering: de laag waar je je state bewaart, maakt niet uit wat er gebeurt. Dit kan alleen maar in een opgeslagen vorm, bv database of file. Je hebt dus vanaf de client datastromen naar beneden tot aan de database en dan terug naar boven. Je bewaart niets in een tussenlaag. Dat kan ook niet, als je bak crasht is je systeem niet meer consistent.

Tot zover geen probleem. Nu het volgende voorbeeld: Client 1 roept een functie aan via de webservice, en deze brengt bv een order-object in de lucht. Als na client 1 een tweede client nu diezelfde functie aanroep doet, is dat order-object dan nog in de lucht? of is er alleen nog een stateless component in de lucht zonder data? of is er helemaal niks meer in de lucht van de eerste aanroep?

Wat je moet definieren is: waar zit de state van de applicatie? Zoals ik al zei: dat kan alleen in een opgeslagen manier, tenzij de applicatie bv maar 1 laag heeft zoals een fat client (word of excel bv). Als iemand een functie aanroept en die maakt een order aan, dan is die order opgeslagen in je database. _DAAR_ is je state. Je kunt wel een object aanmaken en daar je data in bewaren maar wanneer ga je dat opslaan? Een volgende user roept dezelfde logica aan en creeert ook een order. Wordt ook opgeslagen in de database. Het enige wat je eventueel op de client opslaat als 'state' zijn bv order ID's behorende bij de order die ze net hebben gecreeerd. Je in objects gevatte logica is in feite leeg, data is niet opgeslagen in running components.

[Poiter]

Op donderdag 21 februari 2002 09:38 schreef Otis het volgende:
Nee je hebt geen 'stateful' lagen naast 'stateless' lagen in 1 applicatie, met 1 uitzondering: de laag waar je je state bewaart, maakt niet uit wat er gebeurt.

Waarom zou de businesslaag ook niet statefull kunnen zijn?

Dat kan ook niet, als je bak crasht is je systeem niet meer consistent.

Elke transactie commit je natuurlijk naar de database, maar waarom zou je dan alles afbreken wat je hebt, om even later alles weer op te bouwen uit de database? Als bij "normale" systemen het zaakje crasht tijdens een transactie heb je hetzelfde probleem.

Wat je moet definieren is: waar zit de state van de applicatie? Zoals ik al zei: dat kan alleen in een opgeslagen manier, tenzij de applicatie bv maar 1 laag heeft zoals een fat client (word of excel bv). Als iemand een functie aanroept en die maakt een order aan, dan is die order opgeslagen in je database. _DAAR_ is je state. Je kunt wel een object aanmaken en daar je data in bewaren maar wanneer ga je dat opslaan? Een volgende user roept dezelfde logica aan en creeert ook een order. Wordt ook opgeslagen in de database. Het enige wat je eventueel op de client opslaat als 'state' zijn bv order ID's behorende bij de order die ze net hebben gecreeerd. Je in objects gevatte logica is in feite leeg, data is niet opgeslagen in running components.

Stel actie 1 van een client is het aanmaken van een nieuwe order. Deze wordt aangemaakt, en gecommit naar de database. Actie 2 van diezelfde client is het aanmaken van een order-regel bij deze nieuwe order. In order wordt bijgehouden het totaal van alle order-regels. Dus bij het aanmaken van een nieuwe order-regel heb je order ook weer nodig. Het zijn 2 losse acties die ook apart gecommit moeten worden. Maar als bij actie 2 order nog in de lucht zou zijn (op de applicatieserver niet op de client) dan scheelt dat toch heel wat databaseacties en netwerkverkeer.

Data opslaan in running components moet dus wel kunnen! (Alle acties op de database moet dan wel via deze componenten gaan)

[Verwijderd]

Op donderdag 21 februari 2002 12:52 schreef Poiter het volgende:
[..]
Waarom zou de businesslaag ook niet statefull kunnen zijn?

Omdat dat niet logisch is. Die businesslogic laag werkt nl. op commando: client stuurt actie aan naar beneden, business laag handelt die actie af en geeft eventueel resultaat terug. Einde handshake, einde actie. Zo werkt het naar beneden toe door, dus de lagen in de middle tier naar beneden. In the end, is het systeem weer in ruste en in stationaire toestand. Dit is ook de reden waarom transactions in COM+/MTS niet stateful zijn, het is niet logisch.

[..]
Elke transactie commit je natuurlijk naar de database, maar waarom zou je dan alles afbreken wat je hebt, om even later alles weer op te bouwen uit de database? Als bij "normale" systemen het zaakje crasht tijdens een transactie heb je hetzelfde probleem.

tijdens een transactie wel ja, maar een transactie minutenlang laten duren terwijl een user middels een stateless connectie via een browser acties zit te ondernemen op data in zo'n transactie is niet wat je wilt. Het is: actie started, actie handlen, actie handling results storen, result rapporteren, klaar.

[..]
Stel actie 1 van een client is het aanmaken van een nieuwe order. Deze wordt aangemaakt, en gecommit naar de database. Actie 2 van diezelfde client is het aanmaken van een order-regel bij deze nieuwe order. In order wordt bijgehouden het totaal van alle order-regels. Dus bij het aanmaken van een nieuwe order-regel heb je order ook weer nodig. Het zijn 2 losse acties die ook apart gecommit moeten worden. Maar als bij actie 2 order nog in de lucht zou zijn (op de applicatieserver niet op de client) dan scheelt dat toch heel wat databaseacties en netwerkverkeer.

Je storet die order root in de database, krijgt een ordernummer en maakt dan orderregels aan bij die order root. Wanneer is de user klaar met orderregels toevoegen? -> bij die actie store je de data van alle orderregels in de database en het totaal in het orderroot row.
Weer: actie started, actie handlen, actie handling results storen, resultaat reporten, klaar.

Data opslaan in running components moet dus wel kunnen! (Alle acties op de database moet dan wel via deze componenten gaan)

Data opslaan in running components is onzin, ook hier. Want waar leven die components? In de COM+ engine? In MTS? In de webserver? Waar creeer je ze? N.a.v. een event op de webpage in een codebehind event handler?

Misschien houdt die user er wel mee op of hangt zn modem op, weg verbinding, ga jij dan na een half jaar alle objects die nog leven weggooien? Daarom: stateless. Je kunt wel 'semi-stateful' wat referenties bewaren op de client, dus in dit geval bv orderid, of userid bv, maar that's it.

Typisch ASP voorbeeld in een form process page:
- form variables checken
- BL component creeeren
- BL component's properties zetten aan de hand van de form variables
- BL component's method aanroepen die de data verder afhandelt
- BL component's method's resultaat opvangen, eventueel errors afhandelen
- BL component destroyen
- redirect naar volgende page.

[Poiter]

Op donderdag 21 februari 2002 13:12 schreef Otis het volgende:

Omdat dat niet logisch is. Die businesslogic laag werkt nl. op commando: client stuurt actie aan naar beneden, business laag handelt die actie af en geeft eventueel resultaat terug. Einde handshake, einde actie. Zo werkt het naar beneden toe door, dus de lagen in de middle tier naar beneden. In the end, is het systeem weer in ruste en in stationaire toestand. Dit is ook de reden waarom transactions in COM+/MTS niet stateful zijn, het is niet logisch.

Ben ik niet mee eens dat het niet logisch is, het zou juist wel logisch zijn. Iedereen heeft het over object-oriented systemen terwijl ze dat dus eigenlijk helemaal niet zijn.

tijdens een transactie wel ja, maar een transactie minutenlang laten duren terwijl een user middels een stateless connectie via een browser acties zit te ondernemen op data in zo'n transactie is niet wat je wilt. Het is: actie started, actie handlen, actie handling results storen, result rapporteren, klaar.

Dan heb je het niet helemaal begrepen, de transacties worden niks langer of korter hierdoor. Het hele statefull zijn heeft niets met de client te maken. De hele afhandeling vanaf de client veranderd ook niets in.

Je storet die order root in de database, krijgt een ordernummer en maakt dan orderregels aan bij die order root. Wanneer is de user klaar met orderregels toevoegen? -> bij die actie store je de data van alle orderregels in de database en het totaal in het orderroot row.
Weer: actie started, actie handlen, actie handling results storen, resultaat reporten, klaar.

Het hele idee van objcten is dat elk object z'n eigen validaties doet. Een order zal dus z'n eigen validaties moeten doen op het moment dat er iets wijzigt. Mag het wel bij deze status? Wordt niet een maximum overschreden? Op het moment dat je dus een order-regel toevoegd, zul je ook het order-object weer in de lucht moeten brengen. Het stiekem updaten van het totaalveld in de database is het omzeilen van alle controles.

Data opslaan in running components is onzin, ook hier. Want waar leven die components? In de COM+ engine? In MTS? In de webserver? Waar creeer je ze? N.a.v. een event op de webpage in een codebehind event handler?

Ik zou het geen onzin willen noemen, en ik ben ook niet de enige met dit soort denkbeelden, en ik weet ook dat er daadwerkelijk projecten zijn die dit zo uitvoeren! Maar de vraag waar die componenten leven en hoe die worden gemanaged is een hele goeie!

Misschien houdt die user er wel mee op of hangt zn modem op, weg verbinding, ga jij dan na een half jaar alle objects die nog leven weggooien? Daarom: stateless. Je kunt wel 'semi-stateful' wat referenties bewaren op de client, dus in dit geval bv orderid, of userid bv, maar that's it.

Er zal inderdaad iets moeten zijn wat deze componenten managed. Transactiesupport en instance-time-out mechanismes zijn in de meeste applicatie-servers voorhanden.

Typisch ASP voorbeeld in een form process page:
- form variables checken
- BL component creeeren
- BL component's properties zetten aan de hand van de form variables
- BL component's method aanroepen die de data verder afhandelt
- BL component's method's resultaat opvangen, eventueel errors afhandelen
- BL component destroyen
- redirect naar volgende page.

Hoe je het altijd gedaan hebt is natuurlijk geen reden om het tot in lengte van dagen zo te blijven doen. Nieuwe technieken en inzichten kunnen leiden tot andere(betere?) systemen ...