[java] ejb/ruleengine/callback

[Alarmnummer]

Ik ben op dit moment een ruleengine aan het schrijven en het is de bedoeling dat deze oa onder een ejb omgeving gaat draaien. De ruleengine kan zelf weer contact opnemen naar zijn omgeving mbv een callback, bv als een gebruiker gegevens moet invoeren, of als uit de database info gehaald moet worden. Tot zover geen probleem. Ik vraag me alleen af hoe dit het beste in een EJB omgeving geplaatst kan worden.

Ik wil een statefull sessionbean gebruiken die een referentie heeft naar de ruleengine, een interface implementeerd (via een innerclass uiteraard), waarmee de ruleengine callbacks kan doen op de omgeving waar hij in draait. Als een database (of entitybeans) aangesproken moeten worden dan is het geen probleem, maar ik zit even moet hoe bv een client van die sessionbean weer kan aanroepen.

Ik weet dat het mogelijk is om callbacks te doen met ejb (ik geloof dat het met rmi wel mogelijk was). Maar ik zit even met het feit hoe ik de sessionbean moet achterlaten. Moet de callback naar de client een synchrone call worden? Of een asynchrone? Als het een asynchrone call gaat worden wat ga ik dan met die bean doen?

Gewoonlijk zou ik de ruleengine wrappen in een object met zijn eigen thread, en zo gauw de ruleengine een callback doet, een down doen op een semafoor en zo gauw de info weer beschikbaar is, weer een up doen op de semafoor zodat de engine weer verder kan. Het is ejb omgevingen echte niet toegestaan om zelfs met threads aan de slag te gaan, dus ik zit vanaf dit punt eigelijk een beetje met mijn handen in het haar.

[edit]
Het kan trouwens voorkomen dat er niet de mogelijkheid is om een callback te maken omdat de client technology dit niet toelaat. Wat is dan de beste manier? De sessionbean om de zoveel seconden te pollen over zijn toestand? {antwoordennodig,foutmelding,klaar,....} en op basis daarvan nieuwe acties te ondernemen?

[ Voor 10% gewijzigd door Alarmnummer op 06-07-2004 11:08 ]

[zneek]

IS dit niet op te lossen met een soort van message tussenlaag? De ruleengine zet een message klaar, en de SessionBean doet daar op het moment dat hem uitkomt iets mee, en zet eventueel een antwoord message klaar voor de ruleengine?

De client bepaalt uiteindelijk wat er gebeurt, die vult wel of niet iets in waar de ruleengine iets mee kan. De ruleengine kan alleen wachten tot hij iets zinnigs heeft terug gekregen. Of dat nu via een directe callback gaat, of dat er een message queue gepollt wordt maakt niet zoveel uit toch? Zeker gelet op de client, die misschien niet direct kan reageren, en de onmogelijkheid om met threads te werken in de SessionBean.

[Alarmnummer]

zneek schreef op 06 juli 2004 @ 11:30:
IS dit niet op te lossen met een soort van message tussenlaag? De ruleengine zet een message klaar, en de SessionBean doet daar op het moment dat hem uitkomt iets mee, en zet eventueel een antwoord message klaar voor de ruleengine?

De ruleengine heeft wel een thread nodig om op te draaien. Op het moment dat de sessionbean de ruleengine aan de praat heeft geslingerd, en je maakt geen eigen thread voor die rule engine aan, is die bean dus niet meer aanspreekbaar van buitenaf (zijn thread staat volledig in dienst van de ruleengine). Als je dus van buitenaf gaat vragen: heej.. ben je klaar.. of heb je al antwoord? En je zet er geen timeout op, dan krijg je pas antwoord op het moment dat de ruleengine klaar is (en dat wil je niet).


voor de duidelijkheid:
ik werk samen met zneek aan deze opdracht

[edit]
Als je de rulengine wel zijn eigen thread geeft, dan kan het idd met messages (states) opgelost worden. Via een statemachine zou je perfect die ruleengine kunnen aansturen zonder dat je bang hoeft te zijn om de engine in een verkeerde toestand te brengen. En de thread kan je aansturen vanuit de statemachine:
http://www.patternscentra...9&highlight=state+machine

[ Voor 23% gewijzigd door Alarmnummer op 06-07-2004 11:41 ]

[Verwijderd]

Wat voor component is die rule engine precies? Zijn dit ook EJB's??? Je hebt het over een Thread, dus ik neem aan dat je geen EJB's zult gebruiken.

Ook raad ik je het scenario met Stateful Session Beans af.
SFSB zijn door de regel ellendige dingen en zouden eigenlijk niet meer gebruikt moeten worden.

Voor meer info hierover check deze site:

http://c2.com/cgi/wiki?Do...llyUseStatefulSessionBean

Als ik je bovenstaand verhaal goed beluister zou ik eens kijken naar een Message driven beans en message queue's (JMS).

[Alarmnummer]

Verwijderd schreef op 06 juli 2004 @ 12:00:
Wat voor component is die rule engine precies?

Dat is een echte POJO (Plain Old Java Object).

Je hebt het over een Thread, dus ik neem aan dat je geen EJB's zult gebruiken.

Ik het het meer in het algemeen over threads. Aangezien threads icm ejb in principe niet mag, ben ik dus aan het kijken wat de beste oplossing is.

Ook raad ik je het scenario met Stateful Session Beans af.
SFSB zijn door de regel ellendige dingen en zouden eigenlijk niet meer gebruikt moeten worden.

Ik ben die referentie naar die ruleengine nodig.

Als ik je bovenstaand verhaal goed beluister zou ik eens kijken naar een Message driven beans en message queue's (JMS).

Ik zal eens denken hoe mom te rijmen valt met dit verhaal.

[Janoz]

Het eerste waar ik ook aan dacht was JMS. Wat wil je precies met de callback gaan doen? Als dit enkel voor het opleveren van het antwoord is zou je de client gewoon aan een topic kunnen hangen waarop je je resultaten zet.

[Alarmnummer]

Janoz schreef op 06 juli 2004 @ 12:11:
Het eerste waar ik ook aan dacht was JMS. Wat wil je precies met de callback gaan doen? Als dit enkel voor het opleveren van het antwoord is zou je de client gewoon aan een topic kunnen hangen waarop je je resultaten zet.

Het probleem aan alleen JMS is dat het alleen maar een stukje MOM is. Je moet zelf wel een server hebben waar de clients en servers leven. Het voordeel aan EJB is dat je dat er ook meteen bij krijgt met nog 10.000 andere dingen. JMS is dus geen volwaardig alternatief tov een EJB omgeving. Het is maar een heel klein deel van de oplossing.

Het is verder de bedoeling dat we nu alleen een flash client erop gaan aansluiten, maar in de toekomst gaan we er bv ook servlets ed op aansluiten.

[ Voor 11% gewijzigd door Alarmnummer op 06-07-2004 12:17 ]

[zneek]

Janoz schreef op 06 juli 2004 @ 12:11:
Het eerste waar ik ook aan dacht was JMS. Wat wil je precies met de callback gaan doen? Als dit enkel voor het opleveren van het antwoord is zou je de client gewoon aan een topic kunnen hangen waarop je je resultaten zet.

De ruleengine stelt de vraag, de client moet een antwoord geven. Vandaar ook het probleem. Dit antwoord komt in de volgende request binnen (web applicatie). En dus kan er niet 1 aanroep gedaan worden waarin de vraag wordt meegegeven en het antwoord direct op kan worden teruggegeven (aan de ruleengine).

[Alarmnummer]

Ik heb me verdiept in flash remoting (dat is de eis) en ik zie dat het helemaal niet noodzakelijk is om EJB te gebruiken. Flash remoting werk op ieder platform dat servlets ondersteunt, dus hierdoor onstaan er andere mogelijkheden.

[Verwijderd]

Alarmnummer schreef op 07 juli 2004 @ 12:13:
Ik heb me verdiept in flash remoting (dat is de eis) en ik zie dat het helemaal niet noodzakelijk is om EJB te gebruiken. Flash remoting werk op ieder platform dat servlets ondersteunt, dus hierdoor onstaan er andere mogelijkheden.

Waarom heb je precies die callback nodig? Waarom wil je een ref behouden naar de RuleEngine? Kun je de rule engine niet beter implementeren als een EJB? Zodat je er vanuit je Session bean altijd aan kunt?

[Verwijderd]

Ik heb eigenlijk nog weinig argumenten gezien waarom je EJB zou moeten gebruiken. Ik heb niets tegen EJB maar het zijn nogal zware objecten om zonder echte onderbouwing te gebruiken. Zeker als je het hebt over 'statefull sessions beans'

[Alarmnummer]

Verwijderd schreef op 07 juli 2004 @ 14:30:
Ik heb eigenlijk nog weinig argumenten gezien waarom je EJB zou moeten gebruiken.

'Het' argument om EJB te gebruiken was dat er voor flashremoting, gebruikt gemaakt moest worden van een EJB omgeving. Dus vandaar.

Voor de duidelijkheid: ik heb me vanmorgen verdiept in flash remoting en het is daarin noodzakelijk dat er een servlet omgeving is nodig is en een ejb omgeving is dus niet verplicht. De Flashremoting voor java werkt namelijk met een servlet die de flashdata omzet naar java aanroepen, en java resultaten weer omzet naar flash data.

razorharm
Waarom heb je precies die callback nodig? Waarom wil je een ref behouden naar de RuleEngine? Kun je de rule engine niet beter implementeren als een EJB? Zodat je er vanuit je Session bean altijd aan kunt?

Die callback is nodig om een oproep te doen aan een client proces dat er informatie nodig is (of omdat een bepaald event is opgetreden zoals een ruleengine error, ruleengine finished etc). Het kan bv aan een swing gebruiker zijn, of aan een omgeving waarin database info opgehaald kan worden (om maar een paar mogelijkheden te noemen).

Een callback is handig als je werkt met synchrone calls. Als je kan werken met asynchrone calls dan zou je kunnen werken met messages (en ook je eigen threads opstarten) en ben je die hele callback niet eens meer nodig. (In principe is die er wel.. maar wordt aangestuurd via messages).

[ Voor 62% gewijzigd door Alarmnummer op 07-07-2004 15:39 ]

[zneek]

Het gebruik van EJB en Statefull Session Beans is niet strict noodzakelijk. Wel is het zo dat bij voorkeur hetzelfde platform gebruikt moet worden als bij andere FlashRemoting applicaties die we gebouwd hebben. Het enige waar de SSB voor nodig is, is voor de sessie. Als er een andere manier is om binnen de OpenAMF (opensource FlashRemoting) omgeving met sessie afhankelijke objecten te werken, dan is misschien een betere oplossing.

[Verwijderd]

[b][message=21164421,noline]Alarmnummer schreef op 07 juli 2004 @

Een callback is handig als je werkt met synchrone calls. Als je kan werken met asynchrone calls dan zou je kunnen werken met messages (en ook je eigen threads opstarten) en ben je die hele callback niet eens meer nodig. (In principe is die er wel.. maar wordt aangestuurd via messages).

Lijkt mij alleen maar robuuster om JMS te gebruiken. Stel je voor: Client meld zich aan. Ref naar client wordt opgeslagen op server. Client crashed / stopt. Rule Engine geeft event. Event wordt gemeld aan client. Bam! (Error! Kan niet, want client is weg) Kun je afvangen. Maar wat doe je dan met het event? Laat je het erbij, ga je het later nogmaals proberen? Of probeer je het een aantal keren voordat je het opgeeft, etc...

Zelfde scenario met JMS is veel robuuster. Rule Engine geeft event. Event wordt omgezet in message en opgeslagen op de queue of topic. Of de client er nu nog is of niet. Op het moment dat de client opnieuw opstart kan hij weer bijwerken met alle events die nog op de queue aanwezig waren.

[Alarmnummer]

Verwijderd schreef op 07 juli 2004 @ 16:20:
[...]
Lijkt mij alleen maar robuuster om JMS te gebruiken.

JMS is denk ik een beetje een overkill oplossing. Maar een message bases aanpak zou een goeie oplossing zijn. Maar dan moet dit ook mogelijk zijn (ivm de flashremoting + EJB (nu dus servlets)).

Zelfde scenario met JMS is veel robuuster. Rule Engine geeft event. Event wordt omgezet in message en opgeslagen op de queue of topic. Of de client er nu nog is of niet. Op het moment dat de client opnieuw opstart kan hij weer bijwerken met alle events die nog op de queue aanwezig waren.

Ik heb dit al een paar keer voorbij horen komen, maar JMS (en mom) is alleen een stukje middleware. Het creeert geen omgeving waarin een object kan leven en voorzien is van allerlei mooie extra`s zoals je in ejb omgevingen terug ziet. Clustering/loadbalancing, automatisch swappen naar hd indien nodig, etc.

Ik wil niet zeggen dat EJB de beste oplossing is. Maar met JMS alleen ben je niet klaar omdat je een server zult maken waarop de ruleengines draaien en zelf alle zaken moet implementeren die je anders van een EJB omgeving krijgt.

[Verwijderd]

Alarmnummer schreef op 07 juli 2004 @ 16:28:
[...]

JMS is denk ik een beetje een overkill oplossing. Maar een message bases aanpak zou een goeie oplossing zijn. Maar dan moet dit ook mogelijk zijn (ivm de flashremoting + EJB (nu dus servlets)).


[...]

Ik heb dit al een paar keer voorbij horen komen, maar JMS (en mom) is alleen een stukje middleware. Het creeert geen omgeving waarin een object kan leven en voorzien is van allerlei mooie extra`s zoals je in ejb omgevingen terug ziet. Clustering/loadbalancing, automatisch swappen naar hd indien nodig, etc.

Ik wil niet zeggen dat EJB de beste oplossing is. Maar met JMS alleen ben je niet klaar omdat je een server zult maken waarop de ruleengines draaien en zelf alle zaken moet implementeren die je anders van een EJB omgeving krijgt.

Dat begrijp ik, maar elke zichzelf beetje respecterende J2EE applicatie server biedt ook ondersteuning voor JMS (Message driven beans). Dit geldt iig voor JBoss, BEA Weblogic, IBM websphere en Oracle AS (Orion)).

(Ik heb ooit een soortgelijke applicatie opgezet in JBoss).