1. SessionBean och RMI

Denna sida är till för dig som redan kan RMI och vill veta vad som skiljer ett RMI-anrop från ett anrop till en sessionsböna. Sessionsbönor (och entitetsbönor också för den delen) kan utnyttja RMI för att möjligjöra att klienter på andra maskiner gjör fjärranrop mot servern, en teknik som beskrivs på sidan om  RMI . Nedan visas en figur som föreställer en typisk implementation av RMI. I figuren vill vi att klassen Z ska utnyttjas från en klient på en annan maskin:



Jämför detta med arkitekturen för en sessionsböna:



Det finns några skillnader mellan hur sessionsbönor och RMI fungerar:

1. I RMI finns skelettklasser som pratar med stubbarna. I EJB behöver man inte bry sig om skelettklasserna.
2. I RMI utför klassen Z all affärslogik. Klienten har tillgång till Z-stubben och kan därför nå objektet direkt via Z-stubben. I EJB når klienten ZObject via ZObject-stubben. Men ZObject är bara en autogenererad skalklass. Affärslogiken finns istället i klassen ZBean som skyddas av EJB-behållaren, vilket ger en extra nivå av säkerhet. Eftersom klienten inte har direkt kontakt med instansen av ZBean kan behållaren under ytan byta instans mellan klientens anrop, mer om detta i avsnittet om StatelessSessionBean.
3. I EJB finns en speciell klass ZHomeImpl som används för att skapa instanser av ZBean och instanser av ZObject. Någon motsvarighet till ZHomeImpl brukar inte användas i RMI.

2. Protokoll i EJB och RMI

EJB och RMI använder inte samma protokoll för kommunikation mellan datorer:

• RMI använder JRMP som protokoll.
• EJB använder IIOP som protokoll, som låter objekt kommunicera genom CORBA.

3. Problem med modellen?

Det är lätt att man ställer sig frågan: Om Z definierar affärslogiken hos bönan, varför ärver inte även ZBean från Z så att man är garanterad att affärslogiken verkligen implementeras i bönan? Som det är nu kan Z definiera upp en affärslogik som helt ignoreras av ZBean.

Svaret är: Jo, så borde det vara. Men, eftersom Z ärver av EJBObject kommer i så fall ZBean också att ärva av EJBObject. Detta resulterar i att ZBean tvingas att implementera en mängd funktioner som bönan inte använder. Det är till och med en säkerhetsrisk att göra på detta sätt, eftersom bönan då implementerar metoder som gör den tillgänglig för klasser som inte har rätt till den. Om man verkligen vill lösa problemet kan man göra såhär:



Här bestämmer man affärslogiken i ZBusiness och låter både Z och ZBean ärva från det gränssnittet. Nu måste ZBean implementera affärslogiken.