Enterprise JavaBeans (EJB) har skapt stor spenning siden kunngjøringen om Enterprise JavaBeans spesifikasjon versjon 1.0. Bedrifter som Oracle, Borland, Tandem, Symantec, Sybase og Visigenic, blant mange andre, har kunngjort og / eller levert produkter som overholder EJB-spesifikasjonen. Denne måneden ser vi på høyt nivå på hva Enterprise JavaBeans er. Vi vil gå gjennom hvordan EJB skiller seg fra den opprinnelige JavaBeans komponentmodellen, og diskutere hvorfor EJB har generert så enorm interesse.
Men først, en rådgivende: vi vil ikke se på kildekode eller veiledningstemaer denne måneden. Denne artikkelen er ikke en veiledning; det er heller en arkitektonisk oversikt. EJB dekker mye territorium, og uten å først forstå de grunnleggende konseptene som er involvert, er kodebiter og programmeringstriks meningsløse. Hvis det er interesse fra JavaWorldLesere, fremtidige artikler kan dekke detaljene ved å bruke Enterprise JavaBeans API for å lage dine egne Enterprise JavaBeans.
For å forstå hvorfor EJB er så attraktivt for utviklere, trenger vi litt historisk bakgrunn. Først vil vi se på historien til klient / server-systemer, og på den nåværende situasjonen. Deretter vil vi diskutere de forskjellige delene av et EJB-system: EJB-komponenter - som lever av en EJB container løper inne i en EJB-server - og EJB objekter, som klienten bruker som en slags "fjernkontroll" av EJB-komponenter. Vi går gjennom de to typene EJB: er: økt og enhet gjenstander. Du vil også lese om hjem og fjernkontroll grensesnitt, som skaper EJB-forekomster og gir tilgang til henholdsvis EJBs forretningsmetoder. Mot slutten av artikkelen får du en ide om hvordan utvidbare servere kan bygges ved hjelp av Enterprise JavaBeans. Men først, et blikk tilbake i tid.
Klient / server historie
Antikkens historie
I begynnelsen var det stordatamaskinen. Og det var bra. (Eller så bra som det ble, uansett.) Den nyeste teknologien innen informasjonsbehandling gjennom 1960-tallet besto hovedsakelig av store, dyre maskiner som ble brukt av store organisasjoner for å støtte deres daglige forretningsdrift. Minidatamaskiner og timesharing på 1970-tallet økte tilgjengeligheten av datakraft, men informasjon og prosessering var fortsatt sentralisert på individuelle maskiner. De første personlige datamaskinene på 1980-tallet rotet raskt bedriftslandskapet med tusenvis av små øyer med informasjon, alt sammen utrettelig rapporter om variabel kvalitet, mistet kritiske data når de krasjet og ble raskt inkonsekvent med hverandre.
Klient / server til unnsetning
Klient- / serverarkitekturen er en av de vanligste løsningene for hvordan man skal håndtere behovet for både sentralisert datakontroll og utbredt datatilgjengelighet. I klient- / serversystemer holdes informasjonen relativt sentralisert (eller partisjoneres og / eller replikeres blant distribuerte servere), noe som letter kontroll og konsistens av data, samtidig som det gir tilgang til dataene brukerne trenger.
Klientserver-systemer er nå ofte sammensatt av forskjellige antall lag. Det gamle gamle hovedrammen eller timesharing-systemet, der brukergrensesnittet kjører på samme datamaskin som databasen og forretningsapplikasjonene, er kjent som enkelt nivå. Slike systemer er relativt enkle å administrere, og datakonsistens er enkel fordi data lagres bare ett sted. Dessverre har enkeltnivåsystemer begrenset skalerbarhet og er utsatt for fare for tilgjengelighet (hvis en datamaskin er nede, går hele virksomheten din ned), spesielt hvis kommunikasjon er involvert.
De første klient / server-systemene var to-lags, hvor brukergrensesnittet kjørte på klienten, og databasen bodde på serveren. Slike systemer er fremdeles vanlige. En hagesort-type to-lags server utfører mesteparten av forretningslogikken på klienten, og oppdaterer delte data ved å sende strømmer av SQL til serveren. Dette er en fleksibel løsning siden klient / server-samtalen skjer på nivået med serverens databasespråk. I et slikt system kan en riktig designet klient modifiseres for å gjenspeile nye forretningsregler og betingelser uten å endre serveren, så lenge serveren har tilgang til databaseskjemaet (tabeller, visninger og så videre) som trengs for å utføre transaksjonene. Serveren i et slikt to-lags system kalles a databaseserver, som vist under.
Databaseservere har imidlertid noen forpliktelser. Ofte er SQL for en bestemt forretningsfunksjon (for eksempel å legge til en vare i en ordre) identisk, med unntak av at dataene oppdateres eller settes inn, fra samtale til samtale. En databaseserver ender med å analysere og ompakke nesten identisk SQL for hver forretningsfunksjon. For eksempel vil alle SQL-setninger for å legge til en vare i en ordre sannsynligvis være veldig like, og det samme er SQL-setningene for å finne en kunde i databasen. Tiden det tar å analysere tar det bedre å behandle data. (Det er rettsmidler for dette problemet, inkludert SQL-parsebuffere og lagrede prosedyrer.) Et annet problem som oppstår er versjonering av klientene og databasen samtidig: alle maskiner må slå av for oppgraderinger, og klienter eller servere som kommer bak i deres programvareversjon er vanligvis ikke brukbar før de er oppgradert.
Applikasjonsservere
An applikasjonsserver arkitektur (se neste bilde) er et populært alternativ til en databaseserverarkitektur fordi den løser noen av problemene databaseservere har.
Et databaseservermiljø utfører vanligvis forretningsmetoder på klienten, og bruker serveren hovedsakelig for utholdenhet og håndheve dataintegritet. I en applikasjonsserver kjøres forretningsmetoder på serveren, og klienten ber om at serveren utfører disse metodene. I dette scenariet vil klienten og serveren vanligvis bruke en protokoll som representerer en samtale på nivå med forretningstransaksjoner, i stedet for på nivå med tabeller og rader. Slike applikasjonsservere presterer ofte bedre enn databasemotsvarene, men de lider fortsatt av versjonsproblemer.
Både database- og applikasjonssystemer kan forbedres ved å legge til flere nivåer i arkitekturen. Såkalt tre-lags systemer plasserer en mellomkomponent mellom klienten og serveren. En hel bransje - mellomvare - har dukket opp for å takle forpliktelsene til to-lags systemer. EN transaksjonsbehandlingsmonitor, en type mellomvare, mottar forespørselsstrømmer fra mange klienter, og kan balansere belastningen mellom flere servere, gi failover når en server mislykkes, og administrere transaksjoner på en klients vegne. Andre typer mellomvare gir oversettelse av kommunikasjonsprotokoller, konsoliderer forespørsler og svar mellom klienter og flere heterogene servere (dette er spesielt populært når det gjelder eldre systemer i reengineering av forretningsprosesser) og / eller gir informasjon om tjenestemåling og nettverkstrafikk.
Flere nivåer gir en fleksibilitet og interoperabilitet som har resultert i systemer med mer enn disse tre tjenestelagene. For eksempel, n-nivå systemer er generaliseringer av tre-trinns systemer, hvert lag med programvare gir et annet servicenivå til lagene over og under det. N-nivå perspektivet anser nettverket som et basseng av distribuerte tjenester, snarere enn bare midler for en klient å få tilgang til en enkelt server.
Etter hvert som objektorienterte språk og teknikker har kommet i mote, har klient / server-systemer i økende grad beveget seg mot objektorientering. CORBA (Common Object Request Broker Architecture) er en arkitektur som lar objekter i applikasjoner - til og med objekter skrevet på forskjellige språk - kjøre på separate maskiner, avhengig av behovene til en gitt applikasjon. Søknader skrevet for mange år siden kan pakkes som CORBA-tjenester og samarbeide med nye systemer. Enterprise JavaBeans, som er designet for å være kompatibel med CORBA, er en annen oppføring i den objektorienterte applikasjonsserverringen.
Hensikten med denne artikkelen er ikke å gi en opplæring om klient / server-systemer, men det var nødvendig å gi litt bakgrunn for å definere kontekst. La oss nå se på hva EJB har å tilby.
Enterprise JavaBeans og utvidbare applikasjonsservere
Nå som vi har sett på litt historie og har forståelse for hva applikasjonsservere er, la oss se på Enterprise JavaBeans og se hva den tilbyr i den sammenhengen.
Den grunnleggende ideen bak Enterprise JavaBeans er å gi et rammeverk for komponenter som kan "plugges inn" på en server, og derved utvide serverens funksjonalitet. Enterprise JavaBeans ligner bare de opprinnelige JavaBeans fordi de bruker noen lignende konsepter. EJB-teknologi styres ikke av JavaBeans komponentspesifikasjon, men av den helt andre (og massive) Enterprise JavaBeans spesifikasjon. (Se Ressurser for detaljer om denne spesifikasjonen.) EJB spes kaller ut de forskjellige aktørene i EJB klient / server system, beskriver hvordan EJB samarbeider med klienten og med eksisterende systemer, stavar EJBs kompatibilitet med CORBA, og definerer ansvaret for de forskjellige komponentene i systemet.
Enterprise JavaBeans mål
De EJB spes prøver å møte flere mål samtidig:
EJB er designet for å gjøre det enkelt for utviklere å lage applikasjoner, frigjøre dem fra systemnivåer på lavt nivå ved håndtering av transaksjoner, tråder, lastbalansering og så videre. Applikasjonsutviklere kan konsentrere seg om forretningslogikk og legge detaljene i håndteringen av databehandlingen til rammeverket. For spesialiserte applikasjoner er det imidlertid alltid mulig å komme "under panseret" og tilpasse disse tjenestene på lavere nivå.
De EJB spes definerer de viktigste strukturene i EJB-rammeverket, og definerer deretter spesifikt kontraktene mellom dem. Ansvaret til klienten, serveren og de enkelte komponentene er tydelig stavet. (Vi vil se på hva disse strukturene er i et øyeblikk.) En utvikler som lager en Enterprise JavaBean-komponent, har en helt annen rolle enn noen som oppretter en EJB-kompatibel server, og spesifikasjonen beskriver ansvaret til hver enkelt.
EJB har som mål å være standard måten klient- / serverapplikasjoner skal bygges på Java-språket. Akkurat som de originale JavaBeans (eller Delphi-komponentene, eller hva som helst) fra forskjellige leverandører kan kombineres for å produsere en tilpasset klient, kan EJB-serverkomponenter fra forskjellige leverandører kombineres for å produsere en tilpasset server. EJB-komponenter, som Java-klasser, vil selvfølgelig kjøres på en hvilken som helst EJB-kompatibel server uten rekompilering. Dette er en fordel som plattformspesifikke løsninger ikke kan håpe å tilby.
- Til slutt er EJB kompatibel med og bruker andre Java API-er, kan samarbeide med ikke-Java-apper, og er kompatibel med CORBA.
Hvordan et EJB-klient / serversystem fungerer
For å forstå hvordan et EJB-klient / serversystem fungerer, må vi forstå de grunnleggende delene av et EJB-system: EJB-komponenten, EJB-beholderen og EJB-objektet.
Enterprise JavaBeans-komponenten
En Enterprise JavaBean er en komponent, akkurat som en tradisjonell JavaBean. Enterprise JavaBeans kjører i en EJB container, som igjen kjøres innenfor en EJB-server. Enhver server som kan være vert for en EJB-container og gi den de nødvendige tjenestene, kan være en EJB-server. (Dette betyr at mange eksisterende servere kan utvides til å være EJB-servere, og faktisk har mange leverandører oppnådd dette, eller har kunngjort at de har til hensikt å gjøre det.)
En EJB-komponent er den typen EJB-klasse som mest sannsynlig blir betraktet som en "Enterprise JavaBean." Det er en Java-klasse, skrevet av en EJB-utvikler, som implementerer forretningslogikk. Alle de andre klassene i EJB-systemet støtter enten klienttilgang til eller tilbyr tjenester (som utholdenhet og så videre) til EJB-komponentklasser.
Enterprise JavaBeans-containeren
EJB-containeren er der EJB-komponenten "bor." EJB-containeren tilbyr tjenester som transaksjons- og ressursadministrasjon, versjonering, skalerbarhet, mobilitet, utholdenhet og sikkerhet til EJB-komponentene den inneholder. Siden EJB-containeren håndterer alle disse funksjonene, kan EJB-komponentutvikleren konsentrere seg om forretningsregler, og overlate databasemanipulering og andre slike fine detaljer til containeren. For eksempel, hvis en enkelt EJB-komponent bestemmer at den nåværende transaksjonen skal avbrytes, forteller den bare sin container (på en måte som er definert av EJB spesifikasjon, og containeren er ansvarlig for å utføre alle tilbakeførsler, eller gjøre det som er nødvendig for å avbryte en pågående transaksjon. Flere EJB-komponentforekomster eksisterer vanligvis i en enkelt EJB-container.
EJB-objektet og det eksterne grensesnittet
Klientprogrammer utfører metoder på eksterne EJB-er ved hjelp av en EJB-objekt. EJB-objektet implementerer det "eksterne grensesnittet" til EJB-komponenten på serveren. Det eksterne grensesnittet representerer "forretnings" -metodene til EJB-komponenten. Det eksterne grensesnittet gjør det faktiske, nyttige arbeidet til et EJB-objekt, for eksempel å lage et bestillingsskjema eller utsette en pasient til en spesialist. Vi vil diskutere det eksterne grensesnittet mer detaljert nedenfor.
