nogle hævder at EJB'ere er for java 2 enterprise edition er hvad java beans er for java - men det er vist en sandhed med modifikationer. Udover hvad Arne siger (som jeg aldrig vil betvivle) vil jeg måske sige at EJBere er komponenter skrevet i java - de skal overholde en række definitioner (bla. implementere EJBHome interfacet) og afvikles af en Java Enterprise Container.
Hvorfor er de smarte i den virkelige (kommercielle) verden.
Er det fordi at man kan lave et system som kører på flere hardware servere, og så hvis det er belastet stikker man bare en server til ind og alt kører fint videre ?
Er der andre ting der gør EJB smart ? Kan det andet ?
Det har du helt ret i. At de har kaldet det Enterprise Java Beans ligner mest af alt et forsøge på PR mæssigt at lukere lidt på ar Java Beans er et kendt begreb.
En Java Bean er en enkelt class.
En EJB er 2-4 userwritten interfaces + 1 userwritten class + 2-4 container generated classes.
ja - flere af de kommercielle servere (WebLogic fra Bea kan i al fald) kan køre i et cluster og hvis man sætter en maskine til ind i clusteret bliver den automatisk opdateret med programmerne.
Endvidere kan applikationsserverne køre two-fased commits. Det vil sige at hvis du skal skrive til flere forskellige databaser så er du sikker på at data er konsistent inden for samme transaktion (enten bliver data skrevet i alle databaserne eller også bliver ingen af data skrevet).
Nu er der ikke engang enighed om at EJB'er smarte i din virkelige verden !
:-)
EJB er eihvertfald i teorien en meget god måde at designe genbrugelige, skalerbare enterprise komponenter på.
Kritikerne siger, at de er svære at bruge (læs: dyre at udvikle) og performer dårligt.
Jeg er pro-EJB. Ja de er svære at bruge, men det er distribueret computing uanset hvilken teknologi man bruger. Og de performer dårligt hvis man bruger dem forkert, men det kan man jo heller ikke give teknologien skylden for.
en af de ting som jeg personligt synes er rigtigt smart er at når man benytter sig af entity beans, så slipper man mere eller mindre for at tænke på at der er en database bag applikationen, men man skriver bare til java objekter. Så sørger containeren for at skrive data til databasen for een.
Men hvad hvis man ligesom har et sytem med en foretninglogik, hvor der ligger noget information gemt i nogen instanser af nogen klaser (jeg er klar over at den så vil forsvinde ved genstart af systemet).
Det kan man da ikke smide ud på flere servere vha EJB eller hvad ?
Altså hvis du f.eks har en klasse som hedder personOnline og så skriver du
new personOnline (id="x232", "IE","1010022032", etc).
Så kan du jo ikke skrive
personOnline.getByID("x232") med mindre du stadig er på den samme server i clusteret eller kan man eller hvad.
en god designmæssig ting ved EJBere er desuden at man (omend ikke tvinges så bliver guidet i retning af) skelner skarpt mellem forretningslogik og præsentations logik. I ASP/PHP ligger meget af databehandling i forbindelse med de enkelte sider. Det betyder at hvis man skal ændre i designet/finder en fejl i forretningslogikken så skal man igennem mange af de enkelte sider og foretage disse ændringer her. Med EJBere er det (forhåbenligt) kun eet sted man skal foretage ændringen.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.