Observer Design Pattern i J2ee\"callback\"

Læs den her:

http://www.javaworld.com/javaworld/javatips/jw-javatip110_p.html

Har læst eksemplet. Og ja det er Observer Pattern. Men dette pattern laver callback til bønnen(Bean) og ikke en applikationsklient. Har et eksempel der kører, men i dette laver jeg callback via RMI/IIOP. Det er selvfølgelig ok, men jeg synes derved lidt af ideen ved J2EE går af fløjten, idet J2EE jo ligger ovenpå RMI/IIOP. vil gerne beholde mit J2EE for at beholde abstraktionsniveauet. Har tænkt mig at lave en JMS som mellemled imellem min klient og server, og derved gøre gavn af J2EE. Men hvordan det gøres er jeg ikke endnu kommet frem til. Men JEG GIVER ALDRIG OP :-)

lukker spørgsmålet

Jeg synes da du opgiver hurtigt nok at have denne her liggende. Jeg måtte finde den blandt de lukkede :-)

Man har lidt travlt til daglig, så det er svært med tid til alle spørgsmål, men lad mig kommentere lidt på din situation.

I J2EE Opnår man referencer til remote locationer (homes og ejbs) via en naming service. Den returnerer en stub, som altid matcher interfacet, men klassen er ukendt. Denne klasse kan være en genereret stub fra containeren (fra deployment) eller en stub med metadatainformation.

Det reelle objekt befinder sig på en remote maskine, og for at du kan få callback tilbage, er der 3 løsninger, som kan bruges.

1 enten skal serveren initialisere et call-back til clienten
2 klienten kontrollerer for svar hos serveren.
3 Brug af message køer

ad 1
Hvis serveren skal initialisere et callback, skal den have en reference til din lokale maskine. Da transport laget i J2EE kan være enten RMI eller CORBA, bliver man nødt til at facilitere en af disse. F.eks. er RMI et glimrende valg, da RMI-IIOP skulle være med i J2EE. Dvs. du bliver nødt til at serialisere et remote reference til dit lokale objekt hen til serveren, som den kan anvende.

Du har prøvet det, og det virker. Det er den synkrone måde at gøre det på.

Hvis du skal gøre det asynkront, er der de næste 2 at vælge:

ad 2 polling
Du kan anvende en polling løkke hos din klient for at se om serveren skulle være færdig:

while(!condition)
  try { wait(milliseconds); }catch (InterruptedException e) {}

Det gør løsningen mere asynkron, og du har en del busy waiting, som selvfølgelig skal køre i en separat tråd, men alligevel...

Endelig er der JMS. Det kræver selvfølgelig at du har en JMS implementation til rådighed. Så vidt jeg husker eksisterer der så mulighed for både polling og blocking message retrieval, men ellers poster din server beskeden til MSQ, og det kan være som persistent eller ikke persistent (Skal meddelelsen overleve eller ej i køen, hvis maskinen crasher).

Så generelt set, hvis det sker på server siden, er det RMI man skal kunne på klient siden, og hvis det er på klient siden, skal man kunne lidt trådning :-)

Jeg ved godt du drømmer om den \"fede\" løsning, men en sådan eksisterer aldrig rigtig i et distribueret miljø

Logical du har ganske ret. Man kan lige netop vælge en push/pull strategi eller bruge JMS. Jeg må vel acceptere, at den \"fede løsning\" ikke findes, Selom jeg hader, når det ikke lykkedes som jeg nu gerne vil ha det :-)

Takker for korrespondancen.

NB: Rent praktisk er RMI/IIOP jo egentlig en meget simpel løsnig, men pt. accepterer jeg det som løsningen på mit problem.