[ejb] expert-systeem

[Alarmnummer]

Voor de Rijks Universiteit Groingen heb ik de afgelopen paar jaar gewerkt aan oa een expertsysteem. Hierin zat een eenvoudige declaratieve taal en konden oa bewerkingen op databases plaats vinden en communiciatie via de gebruiker.

Ik ben bezig om een volledig nieuw systeem op te zetten met de kennis die ik de afgelopen paar jaar hebt vergaard. Oa komt er een fantastisch mooi typesysteem in te zitten met geparametriseerde types, record types, union types en functie types. Verder komen er nog een aantal leuke zaken in zoals recursieve polymorfisme (niet dat het erg nuttig is ) Dit type-systeem is intussen al gedeeltelijk klaar.

Maar verder moet de communicatie via de database ook een stuk beter gaan. Ik heb voor het oude systeem een simpel or mapping framework geschreven, maar dit is eigelijk totaal niet geschik voor client-server omgevingen. Daarom wil ik het dus nu in 1 keer goed gaan opzetten en hier EJB voor gebruiken. EJB heeft dit allemaal al voor me klaar staan, waardoor ik me kan concentreren op de essentie van de zaak.

Op de EJB-server komen de entity beans (CMP natuurlijk). Verder kan ik aan de hand van de deployment descriptor alle record informatie wel extraheren en er voor zorgen dat de records van het expert-systeem gekoppeld zijn aan de bij behorende entitybeans. (Het zijn trouwens geen normale records, omdat aan een entitybeans natuurlijk strengere eisen gesteld worden dan aan 'normale' records, een entity-record moet bv altijd identificeerbaar zijn om maar iets te noemen).

Verder wil ik dat de draaien van de redeneerbestanden plaats vind dmv session beans.

Ik heb trouwens verder weinig praktische ervaring met het gebruik van ejb en dit is voorlopig alleen een experiment (en leuke stof om (eindelijk) mijn afstudeerscriptie maar eens te schrijven). Maar wat voor problemen kan ik allemaal verwachten?

Ik heb intussen de volgende bedacht:
-traagheid van het redeneer gedeelte.
-traagheid van ejb. EJB heeft natuurlijk overhead omdat EJB`s nu eenmaal geen POJO`s zijn.
-complexiteit van configuratie. Alleen iemand die thuis is in EJB kan het configureren.

Ik zie dat deze post nog redelijk wazig is en je zult je misschien wel afvragen, waar wil ie heen? Ikweet het eerlijk gezegd zelf nog niet eens zo goed. Ik heb al een aantal keren wat geschreven om hier te posten, maar heb ik zat iedere keer ook met mijn handen in het haar. (is trouwens lastig voor iemand die om de paar dagen zijn hoofd scheert)

Maar ik sta open voor advies en commentaar. Ik hoop dat we er in ieder geval een leuke discussie over kunnen voeren.

[Verwijderd]

Ik heb eigenlijk niet echt een idee wat je voor antwoord verwacht maar het gaat over Java en EJB en dat vind ik beide wel interessant...

Commentaar op het eerste stukje over types en recursieve polymorfism (klinkt leuk, kan me der alleen niks bij voorstellen) zal ik maar overslaan en ik zal eens kijken of ik voor de rest wat nuttigs kan melden.

EJB heeft dit allemaal al voor me klaar staan, waardoor ik me kan concentreren op de essentie van de zaak.

In principe kan EJB heel veel voor je regelen, oa. transactions, persistency, thread-safe en ga zo maar door. Maar zoals je ook verderop al meldt, dit krijg je niet gratis en de performance en resources zijn der ook wel na. Je zegt dat je je wilt concentreren op de essentie van de zaak. Je moet wel rekening houden dat het goed opzetten van je EJBs en je deployment descriptors best wat werk met zich meebrengt. Er zijn hier gelukkig tooltjes voor die het allemaal makkelijker maken (XDoclet bijv.), maar door te profilen hoe je applicatie zich gedraagt en aan de hand daarvan je descriptors/server instellingen wijzigen kan het verschil beteken tussen een applicatie die niet vooruit te branden is en eentje die gewoon goed werkt.

Bij www.theserverside.com staan de boeken 'Mastering Enterprise Beans' en 'EJB design patterns' online. Als je echt serieus met EJBs door wilt gaan moet je die echt eens doorlezen.

p de EJB-server komen de entity beans (CMP natuurlijk). Verder kan ik aan de hand van de deployment descriptor alle record informatie wel extraheren en er voor zorgen dat de records van het expert-systeem gekoppeld zijn aan de bij behorende entitybeans

Ik snap niet precies wat je hiermee bedoelt. Wil je uit de deployment descriptors van je beans, informatie halen die je weer in je applicatie gebruikt? Of bedoel je hier de mapping van de entity beans naar de POJO's die je in je expertsysteem gebruikt?

Maar wat voor problemen kan ik allemaal verwachten?

Traagheid van je redeneer gedeelte zal wel meevallen. Performance van SLSB's is niet slecht, de grootste bottleneck (iig in ons systeem) zit hem in de communicatie/rmi laag en zodra er 10duizenden entitybeans in ons systeem rondzweven.

Configuratie valt ook wel mee, ALS (erg grote ALS) alles maar 1 keer goed geconfigureerd is. Dit kan heel veel uit maken. Ik heb bij ons pas door met de deployment descriptors te testen (en eindelijk eens de documentatie door te nemen) performance met een factor 10 kunnen verhogen.

Tja, of ik EJB's zou aanraden. Ik weet het niet helemaal. Je moet wel zeker weten dat je ze nodig gaat hebben. Als je alleen een manier wil om je objecten te persisten, kun je mischien beter kijken naar andere O/R mapping tools zoals Hibernate of JDO (waar ik trouwens geen fan van ben). Dan kun je nog steeds je Session Beans gebruiken om makkelijk je methodes aan de clients aan te bieden maar voor de achterliggende laag gebruik je dan Hibernate of JDO of ... of ...

[mbravenboer]

Ik heb voor het oude systeem een simpel or mapping framework geschreven, maar dit is eigelijk totaal niet geschik voor client-server omgevingen. Daarom wil ik het dus nu in 1 keer goed gaan opzetten en hier EJB voor gebruiken. EJB heeft dit allemaal al voor me klaar staan, waardoor ik me kan concentreren op de essentie van de zaak.

Merk wel op dat je met EJB (gelukkig) ook nog steeds zelfs de conversie van en naar relationele data moet implementeren. EJB regelt wel aardig wat, maar is geen beperkende omgeving wat dat betreft. Misschien dat hibernate in dit geval aardig is om te overwegen als licht framework voor or mapping in combinatie met EJB. Ik heb het echter nog nooit in de context van EJB gebruikt, dus klaag me niet aan het als het toch niet handig blijkt te zijn (heb eigenlijk sowieso alleen maar over EJB gelezen ). Wellicht dat Sosume nog iets over deze combo kan zeggen...

complexiteit van configuratie. Alleen iemand die thuis is in EJB kan het configureren.

Als je van de configuratie een echt systeem wilt maken kan je JMX gaan gebruiken. In een artikel wat ik moet reviewen (kan je geen digitale versie geven) wordt deze aanpak voorgesteld in een praktisch systeem en ik geloof dat het wel een aardige oplossing is. Als je JMX en MBeans gebruikt, is het mogelijk om eenvoudig via verschillende tools de applicatie te managen, terwijl deze draait. Als je in dit onderdeel tijd wilt steken is dat een interessant gebied en wellicht leuke materie voor je scriptie.

Een goed artikel om kennis te maken met deze mogelijkheid:
TheServerSide.com - J2EE Application Management - The Power of JMX

[Alarmnummer]

Verwijderd schreef op 23 April 2003 @ 17:02:

In principe kan EJB heel veel voor je regelen, oa. transactions, persistency, thread-safe en ga zo maar door. Maar zoals je ook verderop al meldt, dit krijg je niet gratis en de performance en resources zijn der ook wel na. Je zegt dat je je wilt concentreren op de essentie van de zaak. Je moet wel rekening houden dat het goed opzetten van je EJBs en je deployment descriptors best wat werk met zich meebrengt. Er zijn hier gelukkig tooltjes voor die het allemaal makkelijker maken (XDoclet bijv.), maar door te profilen hoe je applicatie zich gedraagt en aan de hand daarvan je descriptors/server instellingen wijzigen kan het verschil beteken tussen een applicatie die niet vooruit te branden is en eentje die gewoon goed werkt.

Bij www.theserverside.com staan de boeken 'Mastering Enterprise Beans' en 'EJB design patterns' online. Als je echt serieus met EJBs door wilt gaan moet je die echt eens doorlezen.

Ligt al naast mijn bed En ben ik de afgelopen tijd weer veel aan het doorlezen

Ik snap niet precies wat je hiermee bedoelt. Wil je uit de deployment descriptors van je beans, informatie halen die je weer in je applicatie gebruikt? Of bedoel je hier de mapping van de entity beans naar de POJO's die je in je expertsysteem gebruikt?

Aan de hand van de deployment descriptor kan ik afleiden wat voor entity-record types voor het expertsysteem beschikbaar zijn. Ik moet er dan voor zorgen dat als het redeneerproces een bewerking uitvoert op zo`n entity-record dat dit vertaald wordt naar een bewerking op een entity-bean. Verder blijven die entity-records en entity-beans allemaal op de applicatie server aanwezig, dus mijn entity-record werkt als een soort proxy naar de daadwerkelijke entitybean. Mijn entity-records dragen dus zelf eigelijk geen data, maar laten dit dragen door de entity-beans. Ik hoop dat je zo beter begrijpt wat ik ermee bedoel

Traagheid van je redeneer gedeelte zal wel meevallen.

Op dit moment zit er een evaluator in die verder niet echt wegcompileerd en waar ik dus gebruik maak van eigen stackframes. Verder worden geparametriseerde functies bv ook niet gecached. Deze oplossing voldoet voor mijn huidige eisen (proof of concept), maar er zal zeker iets gedaan moeten worden aan de snelheid

Performance van SLSB's is niet slecht, de grootste bottleneck (iig in ons systeem) zit hem in de communicatie/rmi laag en zodra er 10duizenden entitybeans in ons systeem rondzweven.

Ik ben dus zelf ook vrij bang dat er enorm veel entity beans gaan rondzwerven als het redeneer-proces te veel records eruit loopt te trekken. Dit kan natuurlijk gedeeltelijk lazy plaatsvinden, maar het maakt het er niet gemakkelijker op.

Tja, of ik EJB's zou aanraden. Ik weet het niet helemaal. Je moet wel zeker weten dat je ze nodig gaat hebben. Als je alleen een manier wil om je objecten te persisten, kun je mischien beter kijken naar andere O/R mapping tools zoals Hibernate of JDO (waar ik trouwens geen fan van ben). Dan kun je nog steeds je Session Beans gebruiken om makkelijk je methodes aan de clients aan te bieden maar voor de achterliggende laag gebruik je dan Hibernate of JDO of ... of

Er zijn meer eisen dan alleen opslag. Ik heb een echte client-server omgeving nodig, waarmee meerdere clients op dezelfde data gaan werken. Daarnaast kan er sprake zijn van gevoelige informatie, dat hoef ik dan in ieder geval ook niet te schrijven. EJB`s geven me dus al veel dingen aan zoals transacties, concurrency control ed, en ik heb eigelijk weinig behoefte om dat zelf ook allemaal nog eens te gaan programmeren.

[Alarmnummer]

mbravenboer schreef op 23 April 2003 @ 17:30:
[...]
Merk wel op dat je met EJB (gelukkig) ook nog steeds zelfs de conversie van en naar relationele data moet implementeren. EJB regelt wel aardig wat, maar is geen beperkende omgeving wat dat betreft. Misschien dat

Als je gebruik maakt van CMP dan hoef je alleen de deployment-descriptors te maken. De datalaag wordt voor je geregeld.

hibernate in dit geval aardig is om te overwegen als licht framework voor or mapping in combinatie met EJB. Ik heb het echter nog nooit in de context van EJB gebruikt, dus klaag me niet aan het als het toch niet handig blijkt te zijn (heb eigenlijk sowieso alleen maar over EJB gelezen ). Wellicht dat Sosume nog iets over deze combo kan zeggen...

Ik heb meer nodig dan alleen een or-mapper. Dus ik denk niet dat hibernate voor me geschikt is.

Als je van de configuratie een echt systeem wilt maken kan je JMX gaan gebruiken. In een artikel wat ik moet reviewen (kan je geen digitale versie geven) wordt deze aanpak voorgesteld in een praktisch systeem en ik geloof dat het wel een aardige oplossing is. Als je JMX en MBeans gebruikt, is het mogelijk om eenvoudig via verschillende tools de applicatie te managen, terwijl deze draait. Als je in dit onderdeel tijd wilt steken is dat een interessant gebied en wellicht leuke materie voor je scriptie.

Een goed artikel om kennis te maken met deze mogelijkheid:
TheServerSide.com - J2EE Application Management - The Power of JMX

[/quote]
Ik zal er eens naar kijken. Ik moet me trouwens ook eerst eens echt goed gaan verdiepen in depoyment descriptors, voordat ik echt een uitspraak kan doen over hoe lastig het is om zoiets te schrijven.

Het lijkt me handig als ik ook uitleg hoe dit systeem gebruikt gaat worden. Ik ben programmeur en zorg voor de technische invulling van het systeem. Maar de toepassing van het systeem gebeurt niet door mij. Stel dat voor een notariskantoor zo`n systeem gemaakt zou moeten worden, dan maakt iemand anders aan analyse van het datamodel. Op basis hiervan wordt de database opgezet, en kunnen ook de deployment descriptors worden opgezet. Voor een 'proof of concept' kan ik die desploymentdescriptors wel opstellen. Maar uiteindelijk zal de 'knowledge engineer' dat moeten gaan doen. Ik geef dus geen invulling aan het systeem.

Hou er verder rekening mee dat het team waar ik in werk niet groot is aan de uitvoerende kant (managment kant geen probleem ), dus iedereen loopt meer dan1 taak te doen

En het is dus echt alleen een proof-of-concept. Ik ontwikkel dit in mijn eigen tijd dus als ik het hier niet voor wil gebruiken dan heeft niemand er iets over te zeggen:)

[Verwijderd]

Aan de hand van de deployment descriptor kan ik afleiden wat voor entity-record types voor het expertsysteem beschikbaar zijn

Ik denk dat ik begin te begrijpen wat je wilt, maar ik zelf zou het niet uit de deploymentdescriptor halen. Als je perse deze informatie uit een externe bron wil halen zonder reflectie oid. dan zou ik liever bijv. mijn eigen javadoc tags definieren en dan met xdoclet of code of een xml file generen en die daarvoor gebruiken. Maar dat staat eigenlijk buiten deze discussie....

Ik ben dus zelf ook vrij bang dat er enorm veel entity beans gaan rondzwerven als het redeneer-proces te veel records eruit loopt te trekken.

Als ze voornamelijk gelezen worden en er maar weinig naar toe geschreven wordt dan maakt het niet zo veel uit.. Die worden allemaal wel gecached door de container. Als je veel scrijf/create/delete acties hebt die dan ook nog eens binnen transacties lopen zul je heel secuur moeten werken om hier nog goede performance uit te halen.

..en ik heb eigelijk weinig behoefte om dat zelf ook allemaal nog eens te gaan programmeren...

Dat was voor ons ook een van de voornaamste reden om te switchen naar een EJB gebaseerde architectuur.

Als je gebruik maakt van CMP dan hoef je alleen de deployment-descriptors te maken. De datalaag wordt voor je geregeld.

Je hoeft zelfs niet eens de deployment-descriptors te schrijven. Met xdoclet definieeer je op bean/methode niveau de eigenschappen van de bean en de methode. Dus met een paar simpele tags geef je aan of de methode in de local/remote interface voorkomt. Welk transaction type hij heeft. De relaties tussen entity beans etc..etc..

Als je van de configuratie een echt systeem wilt maken kan je JMX gaan gebruiken

JMX is zeker iets waar je eens naar zou moeten kijken. Niet alleen voor configuratie doeleinden maar ook als (deel) van je applicatie framework. Wat wij hebben gedaan is bepaalde 'services' die niet binnen het EJB/J2EE framework vallen (timers / socketcomm / filesystem zaken) gedefinieerd als een MBean. Deze MBean zijn losse componenten die compleet onafhankelijk van de EJBs bepaalde simpele diensten aanbieden.
Met behulp van een RMIConnector kunnen de beans met deze services praten. En de beans praten gewoon via de remote interface met de beans.

[Alarmnummer]

Verwijderd schreef op 23 April 2003 @ 21:37:
Ik denk dat ik begin te begrijpen wat je wilt

gelukkig

maar ik zelf zou het niet uit de deploymentdescriptor halen. Als je perse deze informatie uit een externe bron wil halen zonder reflectie oid. dan zou ik liever bijv. mijn eigen javadoc tags definieren en dan met xdoclet of code of een xml file generen en die daarvoor gebruiken. Maar dat staat eigenlijk buiten deze discussie....

Hmm.. ik denk dat dit voor de toepassing die ik in gedachten heb juist omslachtiger is. Een knowledge engineer vult in principe de deployment descriptor en het zou onhandig zijn om hem eerst java icm xdoclets te laten maken om vanuit daar deployment descriptors te genereren.


En verder hoef ik ook niet te werken met reflectie. Ik kan aan de hand van de deployment descriptor eenvoudig de entity record types achterhalen. Ik zou een vast formaat kunnen bedenken waar deze entity records in beschreven staan, en dit mbv de deployment descriptor en XSLT kunnen genereren. En anders zou ik eventueel rechtstreeks de deployment descriptor kunnen gebruiken als entity-record-declaratie bron. Alles wat ik nodig heb staat daar gewoon in.

Als ze voornamelijk gelezen worden en er maar weinig naar toe geschreven wordt dan maakt het niet zo veel uit.. Die worden allemaal wel gecached door de container. Als je veel scrijf/create/delete acties hebt die dan ook nog eens binnen transacties lopen zul je heel secuur moeten werken om hier nog goede performance uit te halen.

Ik denk dat er veel meer gelezen gaat worden dan geschreven. In de meeste gevallen hoeven maar enkele gegevens te worden afgeleid doormiddel van veel leesacties.

Dat was voor ons ook een van de voornaamste reden om te switchen naar een EJB gebaseerde architectuur.

Voor wat ik in gedachten heb is EJB denk ik ook de beste oplossing.

JMX is zeker iets waar je eens naar zou moeten kijken. Niet alleen voor configuratie doeleinden maar ook als (deel) van je applicatie framework.

Ik zal me er eens in gaan verdiepen. Als het project ooit serieus ingezet gaat worden, dan moet het wel te configureren zijn.

[edit]
bedankt voor je input trouwens

[ Voor 3% gewijzigd door Alarmnummer op 24-04-2003 00:38 ]

[Verwijderd]

....een knowledge engineer vult in principe de deployment descriptor.....

en...

Ik zou een vast formaat kunnen bedenken waar deze entity records in beschreven staan, en dit mbv de deployment descriptor en XSLT kunnen genereren. En anders zou ik eventueel rechtstreeks de deployment descriptor kunnen gebruiken als entity-record-declaratie bron.

Ik snap nu al steeds meer wat je wil, maar ben het hier toch nog met je oneens , gelukkig maar anders werd het hier een heel saaie boel. Vooral het stukje 'de knowledge engineer vult de deployment descriptor in' zit ik een beetje mee. Je deploymentdescriptor is , voor mij iig, een beschrijving van je beans binnen het systeem (de ejb-jar.xml iig). Dit bestand is niet meer dan een 1 op 1 mapping van oa. de entitybeans die je geschreven hebt.

Als je dit bestand in laat vullen door derden, hoe wil je het dan ooit overeen laten komen met de entitybeans binnen je systeem? Definieer je zelf een entitybean die alle mogelijke velden heeft en de knowledge engineer selecteerd een subset daarvan door in de deployment descriptor bepaalde velden weg te laten? Of zit ik er nu compleet naast?

Ik zou een vast formaat kunnen bedenken waar deze entity records in beschreven staan, en dit mbv de deployment descriptor en XSLT kunnen genereren

Hier kan ik me meer in vinden. Alleen als je dan toch al een stylesheet gebruikt voor het transformeren van data, waarom dan vanaf de deployment descriptor en niet gewoon van een xml bestandje dat je knowledge engineers maken? Hang er een strak schema aan en ze kunnen bijna niks meer fout doen.

Hmm... koffie op....... nieuwe......... halen............. snel............................

[Alarmnummer]

Verwijderd schreef op 24 april 2003 @ 08:27:
Ik snap nu al steeds meer wat je wil, maar ben het hier toch nog met je oneens , gelukkig maar anders werd het hier een heel saaie boel. Vooral het stukje 'de knowledge engineer vult de deployment descriptor in' zit ik een beetje mee. Je deploymentdescriptor is , voor mij iig, een beschrijving van je beans binnen het systeem (de ejb-jar.xml iig). Dit bestand is niet meer dan een 1 op 1 mapping van oa. de entitybeans die je geschreven hebt.

Ik hoef zelf eigelijk geen entity-beans te schrijven. Als de knowledge engineer bedenkt dat bv een kinderen-van-de-overledene tabel handig is, dan voegt hij dit toe aan de deployment descriptor. Als de bestanden voor de expertsysteem gecompileerd worden, dan kan de deployment descriptor oa gebruikt worden om te controleren of velden wel bestaan, vb kinderen.leeftijd. En verder kunnen dan de proxies voor het expertsysteem gegenereerd worden. Zo`n proxy is dus een 'wrapper' om een entity beans heen. Hij heeft wat extra informatie zoals oa zijn type. Maar zo`n proxy draagt dus zelf geen data, maar laat dat doen door zijn entitybean.

Als je dit bestand in laat vullen door derden, hoe wil je het dan ooit overeen laten komen met de entitybeans binnen je systeem? Definieer je zelf een entitybean die alle mogelijke velden heeft en de knowledge engineer selecteerd een subset daarvan door in de deployment descriptor bepaalde velden weg te laten? Of zit ik er nu compleet naast?

De proxies voor de entitybeans worden gegenereerd aan de hand van de deployment descriptor. Als de knowledge-engineer een extra tabel of veld nodig is, dan voegt hij dit toe aan de deployment descriptor en bij het compileren van de expertsysteem bestanden worden automatisch de proxies aangemaakt. Ik schrijf dus nooit specifieke entitybeans.

Hmm... koffie op....... nieuwe......... halen............. snel..........................

[Verwijderd]

Volgens mij mis ik nog steeds een paar stappen

Ik hoef zelf eigelijk geen entity-beans te schrijven. Als de knowledge engineer bedenkt dat bv een kinderen-van-de-overledene tabel handig is, dan voegt hij dit toe aan de deployment descriptor.
...
Maar zo`n proxy draagt dus zelf geen data, maar laat dat doen door zijn entitybean.
...
De proxies voor de entitybeans worden gegenereerd aan de hand van de deployment descriptor. Als de knowledge-engineer een extra tabel of veld nodig is, dan voegt hij dit toe aan de deployment descriptor en bij het compileren van de expertsysteem bestanden worden automatisch de proxies aangemaakt. Ik schrijf dus nooit specifieke entitybeans.

Ok, je genereerd de proxies naar de entitybeans aan de hand van je deploymentdescriptor. Niet iets wat ik zou doen, maar vind het wel een interessant idee. Entity beans houden dus de data bij, als een van de knowledge engineers een extra veld wil voegt hij dat toe aan de deploymentdescriptor.

Bij het aanmaken van de proxies worden daar dan ook de entitybeans gegenereerd of alleen maar je wrappers?

Het is trouwens de eerste keer dat ik iemand zo de deployment descriptor zie gebruiken.

[Alarmnummer]

Verwijderd schreef op 24 April 2003 @ 09:26:
Volgens mij mis ik nog steeds een paar stappen

*schenkt nog even bakje van zijn koffie in*..

Ok, je genereerd de proxies naar de entitybeans aan de hand van je deploymentdescriptor. Niet iets wat ik zou doen, maar vind het wel een interessant idee. Entity beans houden dus de data bij, als een van de knowledge engineers een extra veld wil voegt hij dat toe aan de deploymentdescriptor.

precies

Bij het aanmaken van de proxies worden daar dan ook de entitybeans gegenereerd of alleen maar je wrappers?

De entitybeans worden al voor 99% gegenereerd aan de hand van de deployment descriptor. Ik hoef verder alleen maar te zorgen dat een proxy, zijn entity bean kan vinden. En verder als het expertsysteem een aanroep doet op een proxy, bv int leeftijd = jan.leeftijd, dan vertaald de proxy dit naar de juiste getter op de entitybean 'jan'. En als ik jan dan een andere leeftijd geef, dan vertaald de proxy dit dus naar een de juiste setter op de entitybean jan.

Het is trouwens de eerste keer dat ik iemand zo de deployment descriptor zie gebruiken.

Eigelijk is het niet zo`n hele vreemde toepassing. De deployment is oa een beschrijven van de recordstrucutren in de database, en ik maak daar ook gebruik van om mijn eigen recordstructuren aan te maken. Hierdoor komt ieder record structuur van mij overeen met een recordstructuur in de database.

[ Voor 9% gewijzigd door Alarmnummer op 24-04-2003 10:28 ]

[Scare360]

Alarmnummer schreef op 24 april 2003 @ 10:25:
Eigelijk is het niet zo`n hele vreemde toepassing. De deployment is oa een beschrijven van de recordstrucutren in de database, en ik maak daar ook gebruik van om mijn eigen recordstructuren aan te maken. Hierdoor komt ieder record structuur van mij overeen met een recordstructuur in de database.

Gewoon een mapping template dus, kan EJB trouwens ook n:n aan?

[Alarmnummer]

paulgielens schreef op 24 april 2003 @ 13:02:
[...]
Gewoon een mapping template dus

Wat bedoel je met een mapping template?

kan EJB trouwens ook n:n aan?

http://www.theserverside.com/books/masteringEJB/index.jsp
hoofdstuk 11: bmp en cmp relationships

[Verwijderd]

Ok, begin te begrijpen waar je heen wilt. Heel je proxy idee begrijp ik wel en is ook een heel logische oplossing. Der zijn alleen nog een paar zinnen in je laatste verhaaltje waar ik het niet helemaal mee eens ben / niet helemaal begrijp.

De entitybeans worden al voor 99% gegenereerd aan de hand van de deployment descriptor.

Bedoel je hiermee dat je de code voor de entitybeans tijdens het hele build process genereerd? Als dat zo is dan begrijp ik wel waar je heen wilt. Niet dat ik het er mee eens ben, maar ik begrijp het wel.

De deployment is oa een beschrijven van de recordstrucutren in de database, en ik maak daar ook gebruik van om mijn eigen recordstructuren aan te maken.

Niet helemaal mee eens. De deploymentdescriptor geeft alleen aan bij entity beans iig welke velden in een entitybean door de container gemanaged worden (het abstracte schema), en wat bean specifieke zaken zoals namen,home-remote interfaces en dat soort geneuzel.

Het type van het veld dat gepersist wordt staat er niet bij beschreven. Dus ook al kun je heel veel gegevens uit de deployment descriptor(s) halen. Je mist toch veel informatie die je normalgesproken in je XXXXBean.java file beschrijft.

[Alarmnummer]

Ik zie idd dat het type van het veld idd mist. Hmmzz.. nouja.. dan moet ik maar een eigen formaat introduceren waarin alle entity-record types staan beschreven en moet ik de bijbehorende javabestanden en deployment-descriptor maar genereren.

[Alarmnummer]

*kick*

Ik loop op dit moment te prakkadenken over wat voor functionaliteit die session bean moet gaan hebben. In sommige gevallen moet de gebruiker aan de hand van een vragensessie nieuwe informatie in het systeem toevoegen, in andere gevallen hoeven er alleen documenten worden opgemaakt of conclusies zichtbaar worden gemaakt.

En verder baart me het geheugen verbruik ook wel wat zorgen. Een van de dingen die ze will en hebben is een howtree. Waarin je kan zien hoe een conclusie tot stand is gekomen. Ik weet uit ervaring dat dit nogal een kostbare aangelegenheid kan worden.

[Verwijderd]

Tja, beetje moelijk om hier iets nuttigs aan toe te voegen. 'Mijn' sessionbeans hebben zelf niet al te veel functionaliteit. Het enige wat ze doen zis eigenlijk het uitvoeren van usecases.

Je zult met betrekking tot het geheugen altijd een overhead hebben vanwege het gebruik van session beans. Het nadeel ,(of voordeel , ligt eraan hoe je ertegenaan kijkt), is dat elke bean binnen zijn eigen context leeft. Dat betekend dat het gebruik van singletons al snel minder nuttig wordt, aangezien elke session bean zijn eigen singleton heeft. Die is dan binnen de context van de sessionbean wel weer een singleton, maar niet binnen je gehele applicatie.

[Alarmnummer]

Alarmnummer schreef op 24 april 2003 @ 13:54:
Ik zie idd dat het type van het veld idd mist. Hmmzz.. nouja.. dan moet ik maar een eigen formaat introduceren waarin alle entity-record types staan beschreven en moet ik de bijbehorende javabestanden en deployment-descriptor maar genereren.

Ik zou zelf eigelijk ook te denken of ik de syntax van de deployment descriptors kan extenden (zonder dat orginele parser van de deployment descriptor hier problemen mee krijgt)

<!-- type>Int</ type -->

[hobbit_be]

lol misschien kennen jullie OJB ? (ie Persistant Storage voor Objects in RDB) die heeft ook zo'n descriptors, maar net zoals jullie al melden is die een beetje 'dom' dus heb ik de xml ook 'extended' zonder dat de originele erop af knapt. Alleen kon ik enkel 'attributes' (dus geen elements) toevoegen. Toen ik postte (aan de devellopers) dat dit wel eens leuk zou zijn als de xml wat 'looser' zou mogen (of tenminste een 'unsafe' optie). De flames die ik kreeg - niet mooi. DTD is helig blijkbaar Krijg ik op mijn heupen van : zo'n typische academsiche mentaliteit waar alles proper moet . ZUllen die opkijken als je in de echte wereld komt waar het moet werken...

oh ze hadden wel deze syntax:

code:

  <attribute attribute-name="aUserVar" attribute-value="hello" />

kut lelijk XML gedoe...

beetje offtopic maar wel thread gevolgd.

Kun je EJB trouwens op Tomcat loslaten (ie Free )?

[Alarmnummer]

*kick* Ik hoop dat er nog meer EJB`ers zijn die interessante zaken te melden hebben

[mbravenboer]

erg off-topic en ik wil dit topic niet verpesten, dus ga er maar niet teveel op in

hobbit_be: De flames die ik kreeg - niet mooi. DTD is helig blijkbaar

DTD is duivels, niet heilig .

zo'n typische academsiche mentaliteit waar alles proper moet . ZUllen die opkijken als je in de echte wereld komt waar het moet werken...

Dat heeft niets academische mentaliteit of proper te maken. Een uitbreidbaar XML formaat kan juist proper zijn en zelfs op een academische mentaliteit gebaseerd . Net zoals je attributen in C# hebt, kan je ook in XML formaten mogelijkheden bieden om extra informatie toe te voegen die zich richt op een bepaalde applicatie. Je kan hiervoor gescheiden attribuut elementen maken, die dan any content kunnen bevatten, maar je zou zelfs kunnen overwogen om op bepaalde plaatsen alles in een andere namespace dan de namespace van de applicatie toe te staan ...

[Alarmnummer]

Naast de deployment descriptor moet er voor CMP-entitybeans ook nog een entity-mapping bestand worden geleverd. Hierin staan wel de types voor de velden vermeld, dus aan de hand van dit bestand, en de deployment descriptor kan ik mijn entity-record-types opbouwen.