Arkitekturen i J2EE
Alle de førende producenter af applikationsserver-software har deres egen net-strategi. Uanset om navnet er .Net eller J2EE, så er målet det samme, nemlig at kunne kontrollere informationsstrømme internt i virksomheden og eksternt i forhold til kunder, leverandører og slutbrugere. To af de store spillere her er selvfølgelig Microsoft og Sun, der har hver sin implementeringen af, hvad der langt hen af vejen handler om at tilbyde målgrupperne de samme muligheder.
Microsoft har endnu engang vist sin evne til at markedsføre dets produkter og har fået .Net op i overskrifterne, mens J2EE lever sit liv blandt udviklerne. Med tanke på Suns intensive og succesfulde markedsføring af Java, så kunne man fristes til at tro, at det er de højere magters måde at fordele sol og vind lige på. Dot-Nets kernefunktioner, som blandt andet dækker programmeringsproget C#, fortolkede platformsuafhængige sprog, distruberede komponenter (DCOM) samt internetservices er der allerede skrevet meget om. Derfor vil vi her gennemgå, hvad Sun kan tilbyde udviklere og markedstrateger.
Arkitekturen i J2EE
Intentionen med J2EE er at skabe en platform til udvikling, implementering og håndtering af informationssystemer, naturligt nok baseret på Java, som efterhånden er blevet Suns kerneteknologi. J2EE ligger op til platformsuafhængig udvikling, og som vi skal se senere, er det faktisk en af arkitekturens centrale styrker. De enkelte dele af arkitekturen består blandt andet af:
- Enterprise JavaBeans
- Java Naming and Directory Interface
- JDBC, Javas database-API
- JavaServer Pages (JSP)
- Javabaserede transaktionsstyringsteknologier (JTA, JTS)
- Javabaserede teknologier til kommunikation imellem applikationer (JMS, RMI)
- CORBA, Unix-verdenens komponent-arkitektur, som modsvarer Microsofts COM og DCOM
Uafhængighed af leverandører og platforme
Enterprise JavaBeans
JavaBeans er Javas objekt-arkitektur, som det kendes fra COM og CORBA. Ideen i en komponent er, at den skal opføre sig som en "sort kasse", en selvstændig enhed som ved hjælp af en simpel, standardiseret grænseflade kan implementeres uden nøjere kendskab til objektes interne struktur.
Enterprise JavaBeans er en specifikation for JavaBeans til udvikling af professionelle serverbaserede systemer. Mens JavaBeans kan benyttes i alle sammenhænge, retter Enterprise JavaBeans sig specifikt mod serversystemer.
En kernefunktion i Enterprise JavaBeans er transaktionsstyring. EJB-specifikationen understøtter automatisk distribuerede transaktioner. Det gør det muligt for udvikleren at skabe applikationsdele, som kan håndtere både flere datakilder og flere brugere samtidig - noget, der ellers let kan blive en temmelig kompleks affære.
Således kan man forestille sig en situation, hvor mange brugere fordelt over hele verden samtidig kan manipulere informationssystemer, der består af flere uafhængige databaser og datakilder.
Uafhængighed af leverandører og platforme
Da J2EE ikke er en applikationsserver, men en arkitektur, kan virksomheden købe J2EE-kompatible applikationsservere fra flere forskellige leverandører.
Sun har bygget en demonstration, hvor otte forskellige J2EE-applikationsservere kører en applikation, Java Petstore, på deres maskiner. Alle maskiner kører nøjagtig samme version af Java Petstore uden modifikationer.
Da Java tillige i udstrakt grad er platformsuafhængig, kan J2EE-aplikationerne flyttes fra en platform til en anden. Det er klart, at det giver indlysende fordele med hensyn til skalerbarhed og uafhængihed af leverandører.
Sun argumenterer også med, at 90 procent af alle applikationsservere er Java-baserede, og et flertal af de amerikanske universiteter har Java som tvunget fag. Der er således flere Java-udviklere end Visual Basic-udviklere - ifølge Sun.
I en efterfølgende artikel sammenligner vi J2EE og .Net og kårer en utvetydig vinder - sådan da.
