[java/client/server] verouderde objecten

[Alarmnummer]

Hoe kun je het beste omgaan met veroudering van objecten? In mijn geval heb ik een erg complex object (een ruleengine) die kan verouderen doordat op de ruleengineserver een nieuwe is geplaatst. Hoe kan ik het beste de client laten weten dat er een nieuwe engine is, en hoe moet je omgaan als hij nog midden in een langdurig proces zit. Als je doorgaat loopt hij dus te werken met een verouderde (en eventueel incorrecte) ruleengine, maar als je hem laat stoppen dan gaat er misschien een lading werk verloren.

Ik had zelf al zitten denken aan messages versturen via een jms server. De client die registreerd zich bij de jms-server als listener voor een bepaalde rule-engine. En als op de server een nieuwe ruleengine komt, verstuur je een event naar de jms server voor dat topic en dan moeten de clients hun werk maar doen.

Persoonlijk vind ik dit wel een redelijk zware oplossing en er moet ook een extra service draaien wat zorgt voor extra complexiteit. Je zou hetzelfde in principe ook voor elkaar kunnen krijgen met een beetje rmi.

[ Voor 4% gewijzigd door Alarmnummer op 24-04-2004 17:03 ]

[Macros]

Ik denk dat je zelf het beste de oplossing kan zoeken. Jij bent zelf hier op het forum 1 van de betere Java/OO guru's en bijna niemand kan je nog iets vertellen. Daarbij komt nog eens dat alleen jij weet hebt van de structuur die je al hebt.

En inderdaad, je kan dat het beste doen met een listener service, hoe, wat en welk systeem je daarvoor gaat gebruiken is afhankelijk van heel veel variabelen. Waar alleen jij de waardes van weet.
Misschien is het makkelijker om elke dag of aantal uur even te kijken of er een update is van de ruleengine. Dan kan de client zelf patchen als dat belangrijk is voor die client.

btw. dan zou ik het simpel houden met wat http/ftp connecties die de files updaten en daarna de applicatie herstarten of de classen opnieuw inladen.

[ Voor 12% gewijzigd door Macros op 24-04-2004 17:12 ]

[Alarmnummer]

Macros schreef op 24 april 2004 @ 17:11:
Daarbij komt nog eens dat alleen jij weet hebt van de structuur die je al hebt.

Idd. Maar mijn kennis is op dit gebied (client/server zaken) theoretisch goed genoeg, maar praktisch minder. Ik heb last van.. ojee.. zoveel keuzes.. welke zal ik kiezen

En inderdaad, je kan dat het beste doen met een listener service, hoe, wat en welk systeem je daarvoor gaat gebruiken is afhankelijk van heel veel variabelen. Waar alleen jij de waardes van weet.

Mijn probleem zit hem in het feit dat ik dus (te) veel wegen naar rome weet En dat ik dus nu een beetje zit met welke ik moet kiezen. Het voordeel aan een JMS-server is dat de client/server onafhankelijk van elkaar uit kunnen gaan zonder dat ik bang hoef te zijn dat er geen events meer verstuurd kunnen worden (na opstarten). In dit opzicht heeft jms mijn voorkeur. En verder is het eigelijk helemaal voor dit soort dingen gemaakt. Wederom is JMS mijn keuze. Maar ik zit nu wel met een extra service die gedraait moet worden voor iets relatief kleins. Valt het te rechtvaardigen dat je nu ineens voor dit kleine dingetje zo`n heavy duty oplossing vraagt. Eindgebruikers (developers) moeten nu ineens een extra service onderhouden zowel qua configuratie en updates maar ook je zit ook vast aan extra hardware/geheugen eisen (niet dat zo`n service nou zoveel resources vreet).

btw. dan zou ik het simpel houden met wat http/ftp connecties die de files updaten en daarna de applicatie herstarten of de classen opnieuw inladen.

Ik zat zelf te denken aan een server die alle rule-engines beheert. Mbv bv een webinterface (zit je ook nog een keer vast aan een webapplicatiserver) kan je het beheer op die server laten plaatsvinden en de ruleengines zelf wil ik gewoon serializen naar de client toe. Ik wil niet dat hij nog iets te maken heeft met specifieke ruleengine problematiek (dus parsen etc) maar in principe alleen start/stop etc functionaliteit.

[ Voor 7% gewijzigd door Alarmnummer op 24-04-2004 17:30 ]