04. august 2004 - 20:34Der er
11 kommentarer og 1 løsning
problemet med ejb
Nu ved jeg ikke meget om ejb, har læst lidt på det og lavet et par små programmer men jeg har fulgt med i debatten om ejb3 som ser interresant ud. Det jeg godt kunne tænke mig at vide er hvilke specifikke problemer der er i de nuværende implementationer der gør at det er så kompliceret at arbejde med?
Jeg går ud fra at hvis man vil arbejde med j2ee kan man ikke komme uden om at lære om 2.1 da der vil gå tid før at 3 bliver taget rigtigt i brug så man kan vel ligeså godt lære 2.1 først?
en sidste ting. jeg ser tit websphere nævnt i forbindelse med job opslag. er klar over at de har forskellige produkter, men jeg går ud fra der menes applications serveren. Adskiller den sig meget fra mange andre ligende produkter at det er noget der tager lang tid at sætte sig ind i så den kan være et krav for et job.. for den er vel bygget på en standard?
Der er flere kritik punkter ved EJB 2.x: - du skal skrive selve koden (bean klassen) + 2-4 interfaces + måske en primary key klasse du skal definere den i 1-3 deployment descriptorer, altså meget trivelt arbejde - mange mener at entity beans er for heavyweigth og foretrækker mere ligthweigth data objekt typer
Du kan roligt lære 2.1. For det første varer det nok et godt stykke tid inden 3.0 standarden releases og det vil vare endnu længere tid inden de versioner af app-serverne der supporterer den bliver taget i brug rundt omkring.
De 3 mest brugte J2EE app-servere er IBM WebSphere (WAS), BEA WebLogic (WL) og JBoss.
I Danmark bruges J2EE primært i den finansielle sektor. Og den finansielle sektor i Danmark er utrolig blå. Derfor er WebSphere mest udbredt i Danmark.
Alle serverene overholder standarden, så principielt er det fra en udvikler synsvinkel ligegyldigt hvilken det er. Det betyder kun noget for drifts folkene. I praksis er der imidlertid lidt relevante forskelle det er kun den ene deployment descriptor som er standard - de andre er app-server specifikke. Sommetider bruger man nogle ikke standard features i en app-server etc.. Så når der annonceres efter en udvikler til en specifik app-server så er det 25% de små forskelle der reelt er og 75% personale afdelingen der ikke aner hvd en standard er.
Ok når du siger ligthweigth så går jeg ud fra du mener hibernate/jdo Jeg hører også tit spring i forbindelse med ejb diskusioner. Ved du hvor det er at det ligthweigth ikke kan hamle op med ejb Jeg går ud fra det er når det skal være distribueret men er der andre ting?
Han fremhæver selvfølgelig spring, hibernate og jdo meget. Han kigger på den klassiske ejb arkitektur med remote homes, vs local homes vs ad hoc vs lightweight frameworks og sætter dem op imod hinanden med fordele/ulemper.
En af problemerne siger han er at man ofte forsøger at forberede sig på requirements som muligvis slet ikke kommer og at man ofte kun har brug for en lille del af specifikationen og så er ejb måske slet ikke det man leder efter.
han går igennen det som ejb har at tilbyde og nævner i forbindelse med det alternativer. f.eks transaktioner som kan håndteres med aop.
Problemerne han kommer ind på er at det er: Svært at teste - afhængighed af containeren Komplekst arkitektur - som kan føre til performance problemer, dyr vedligeholdelse m.m Ikke særligt objekt orienteret - f.eks entity beans hvor du ikke kan lave en nedarvning og mere "objekter" der representere en tilstand end rigtigte objekter Han siger bla: "My personal view is that entity beans are simply a bad technology"
Der hvor han kan se ejb nyttig er hvis man virklig har brug for remote objekter. Han nævner f.eks at der hvor der skal laves store udregninger hvor prisen for udregningen er mindre en prisen for det remote kald kan det betale sig. Stateless session beans mener han kan have sine fordele men også ulemper og alternativer.
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.
