Enterprise JavaBeans (EJB) har skabt en stor spænding siden meddelelsen om Enterprise JavaBeans Specification Version 1.0. Virksomheder som Oracle, Borland, Tandem, Symantec, Sybase og Visigenic, blandt mange andre, har annonceret og / eller leveret produkter, der overholder EJB-specifikationen. Denne måned vil vi se på højt niveau på, hvad Enterprise JavaBeans er. Vi gennemgår, hvordan EJB adskiller sig fra den originale JavaBeans-komponentmodel, og diskuterer, hvorfor EJB har skabt en så enorm interesse.
Men først en rådgivende: vi ser ikke på kildekode eller vejledningsemner denne måned. Denne artikel er ikke en tutorial; snarere er det en arkitektonisk oversigt. EJB dækker meget territorium, og uden først at forstå de involverede grundlæggende begreber er kodestykker og programmeringstricks meningsløse. Hvis der er interesse fra JavaWorldlæsere, kan fremtidige artikler muligvis dække detaljerne ved at bruge Enterprise JavaBeans API til at oprette dine egne Enterprise JavaBeans.
For at forstå hvorfor EJB er så attraktiv for udviklere, har vi brug for en historisk baggrund. Først ser vi på historien om klient / serversystemer og den aktuelle situation. Derefter diskuterer vi de forskellige dele af et EJB-system: EJB-komponenter - som lever på en EJB container løber inde i en EJB-server - og EJB objekter, som klienten bruger som en slags "fjernbetjening" af EJB-komponenter. Vi gennemgår de to typer EJB'er: session og enhed genstande. Du vil også læse om hjem og fjern grænseflader, der opretter EJB-forekomster og giver henholdsvis adgang til EJB's forretningsmetoder. I slutningen af artiklen har du en idé om, hvordan udvidelige servere kan bygges ved hjælp af Enterprise JavaBeans. Men først et blik tilbage i tiden.
Klient / server historie
Oldtidshistorie
I starten var der mainframe-computeren. Og det var godt. (Eller så godt som det blev, alligevel.) Den nyeste teknologi inden for informationsbehandling gennem 1960'erne bestod primært af store, dyre maskiner, der blev brugt af store organisationer til at støtte deres daglige forretningsdrift. Minicomputere og timesharing i 1970'erne øgede tilgængeligheden af computerkraft, men information og behandling var stadig centraliseret på individuelle maskiner. De første personlige computere i 1980'erne rodede hurtigt virksomhedslandskabet med tusindvis af bittesmå øer med information, alt sammen utrætteligt udrangerede rapporter af variabel kvalitet, mistede kritiske data, da de styrtede ned og blev hurtigt inkonsistente med hinanden.
Klient / server til undsætning
Klient- / serverarkitekturen er en af de mest almindelige løsninger til sammenfaldet med, hvordan man håndterer behovet for både centraliseret datakontrol og udbredt datatilgængelighed. I klient- / serversystemer opbevares information relativt centraliseret (eller er partitioneret og / eller replikeret blandt distribuerede servere), hvilket letter kontrol og konsistens af data, mens det stadig giver adgang til de data, som brugerne har brug for.
Klientserver-systemer er nu ofte sammensat af forskellige antal niveauer. Det gamle gamle mainframe- eller timesharing-system, hvor brugergrænsefladen kører på samme computer som databasen og forretningsapplikationer, er kendt som enkelt niveau. Sådanne systemer er relativt lette at administrere, og datakonsistens er enkel, fordi data kun gemmes ét sted. Desværre har enkeltniveausystemer begrænset skalerbarhed og er tilbøjelige til tilgængelighedsrisici (hvis en computer er nede, går hele din virksomhed ned), især hvis kommunikation er involveret.
De første klient / serversystemer var to-lags, hvor brugergrænsefladen kørte på klienten, og databasen levede på serveren. Sådanne systemer er stadig almindelige. Én havevarietype af to-lags server udfører det meste af forretningslogikken på klienten og opdaterer delte data ved at sende streams af SQL til serveren. Dette er en fleksibel løsning, da klient / server-samtalen finder sted på niveauet med serverens databasesprog. I et sådant system kan en korrekt designet klient modificeres for at afspejle nye forretningsregler og betingelser uden at ændre serveren, så længe serveren har adgang til databaseskemaet (tabeller, visninger osv.), Der er nødvendige for at udføre transaktionerne. Serveren i et sådant to-lags system kaldes en databaseserver, som vist nedenfor.
Databaseservere har dog nogle forpligtelser. Ofte er SQL for en bestemt forretningsfunktion (for eksempel at tilføje en vare til en ordre) identisk med undtagelse af de data, der opdateres eller indsættes, fra opkald til opkald. En databaseserver ender med at analysere og omparse næsten identisk SQL for hver forretningsfunktion. For eksempel er alle SQL-sætninger til at føje et element til en ordre sandsynligvis meget ens, ligesom SQL-sætningerne til at finde en kunde i databasen. Den tid, som denne parsing tager, ville være bedre brugt til faktisk behandling af data. (Der er afhjælpning af dette problem, herunder SQL-parsecacher og lagrede procedurer.) Et andet problem, der opstår, er versionering af klienterne og databasen på samme tid: alle maskiner skal lukkes for opgraderinger, og klienter eller servere, der falder bagud i deres softwareversion kan normalt ikke bruges, før de er opgraderet.
Applikationsservere
En applikationsserver arkitektur (se næste billede) er et populært alternativ til en databaseserverarkitektur, fordi det løser nogle af de problemer, som databaseservere har.
Et databaseservermiljø udfører normalt forretningsmetoder på klienten og bruger serveren hovedsagelig til vedholdenhed og håndhævelse af dataintegritet. I en applikationsserver køres forretningsmetoder på serveren, og klienten beder om, at serveren udfører disse metoder. I dette scenario bruger klienten og serveren typisk en protokol, der repræsenterer en samtale på niveauet for forretningstransaktioner i stedet for på niveauet med tabeller og rækker. Sådanne applikationsservere fungerer ofte bedre end deres databasemodstykker, men de lider stadig under versioneringsproblemer.
Både database- og applikationssystemer kan forbedres ved at tilføje yderligere niveauer til arkitekturen. Såkaldt tre-lags systemer placerer en mellemkomponent mellem klienten og serveren. En hel industri - middleware - er dukket op for at imødegå forpligtelser i to-lags systemer. EN transaktionsbehandlingsmonitor en type middleware, modtager strøm af anmodninger fra mange klienter og kan afbalancere belastningen mellem flere servere, give failover, når en server fejler, og administrere transaktioner på en klients vegne. Andre typer middleware leverer oversættelse af kommunikationsprotokoller, konsoliderer anmodninger og svar mellem klienter og flere heterogene servere (dette er især populært i forbindelse med ældre systemer i genprojektering af forretningsprocesser) og / eller leverer servicemåling og netværkstrafikinformation.
Flere niveauer giver en fleksibilitet og interoperabilitet, der har resulteret i systemer med mere end disse tre servicelag. For eksempel, n-niveau systemer er generaliseringer af tre-trins-systemer, hvor hvert lag af software giver et andet serviceniveau til lagene over og under det. N-niveau-perspektivet betragter netværket som en pulje af distribuerede tjenester snarere end blot midlerne for en klient til at få adgang til en enkelt server.
Efterhånden som objektorienterede sprog og teknikker er kommet på mode, har klient- / serversystemer i stigende grad bevæget sig mod objektorientering. CORBA (Common Object Request Broker Architecture) er en arkitektur, der gør det muligt for objekter inden for applikationer - endda objekter skrevet på forskellige sprog - at køre på separate maskiner afhængigt af behovene i en given applikation. Applikationer, der blev skrevet for mange år siden, kan pakkes som CORBA-tjenester og interoperere med nye systemer. Enterprise JavaBeans, som er designet til at være kompatibel med CORBA, er en anden indgang i den objektorienterede applikationsserverring.
Formålet med denne artikel er ikke at give en tutorial om klient- / serversystemer, men det var nødvendigt at give en vis baggrund for at definere kontekst. Lad os nu se på, hvad EJB har at tilbyde.
Enterprise JavaBeans og udvidelige applikationsservere
Nu hvor vi har kigget lidt på historien og har forståelse for, hvad applikationsservere er, lad os se på Enterprise JavaBeans og se, hvad det tilbyder i den sammenhæng.
Den grundlæggende idé bag Enterprise JavaBeans er at skabe en ramme for komponenter, der kan "tilsluttes" til en server og derved udvide serverens funktionalitet. Enterprise JavaBeans svarer kun til de originale JavaBeans, da det bruger nogle lignende koncepter. EJB-teknologi styres ikke af JavaBeans komponentspecifikation, men af det helt andet (og massivt) JavaBeans Enterprise-specifikation. (Se Ressourcer for detaljer om denne spec.) EJB Spec opfordrer de forskellige spillere i EJB-klient / serversystemet, beskriver, hvordan EJB interagerer med klienten og med eksisterende systemer, stave EJBs kompatibilitet med CORBA og definerer ansvaret for de forskellige komponenter i systemet.
Enterprise JavaBeans mål
Det EJB Spec forsøger at nå flere mål på én gang:
EJB er designet til at gøre det let for udviklere at oprette applikationer, der frigør dem fra systemoplysninger på lavt niveau ved håndtering af transaktioner, tråde, belastningsbalancering osv. Applikationsudviklere kan koncentrere sig om forretningslogik og overlade detaljerne til styring af databehandling til rammen. Til specialiserede applikationer er det dog altid muligt at komme "under emhætten" og tilpasse disse tjenester på lavere niveau.
Det EJB Spec definerer de vigtigste strukturer i EJB-rammen og definerer derefter specifikt kontrakterne mellem dem. Ansvaret for klienten, serveren og de enkelte komponenter er alle klart angivet. (Vi gennemgår, hvad disse strukturer er på et øjeblik.) En udvikler, der opretter en Enterprise JavaBean-komponent, har en meget anden rolle end en person, der opretter en EJB-kompatibel server, og specifikationen beskriver hver enkelt ansvarsområde.
EJB sigter mod at være standardmetoden for klient- / serverapplikationer, der skal bygges på Java-sproget. Ligesom de originale JavaBeans (eller Delphi-komponenter eller lignende) fra forskellige leverandører kan kombineres for at producere en brugerdefineret klient, kan EJB-serverkomponenter fra forskellige leverandører kombineres for at producere en brugerdefineret server. EJB-komponenter, der er Java-klasser, vil naturligvis køre på enhver EJB-kompatibel server uden rekompilering. Dette er en fordel, som platformsspecifikke løsninger ikke kan håbe at tilbyde.
- Endelig er EJB kompatibel med og bruger andre Java API'er, kan interoperere med apps, der ikke er Java, og er kompatibel med CORBA.
Sådan fungerer et EJB-klient / serversystem
For at forstå, hvordan et EJB-klient / serversystem fungerer, er vi nødt til at forstå de grundlæggende dele af et EJB-system: EJB-komponenten, EJB-containeren og EJB-objektet.
Enterprise JavaBeans-komponenten
En Enterprise JavaBean er en komponent, ligesom en traditionel JavaBean. Enterprise JavaBeans udfører inden for en EJB container, som igen udfører inden for en EJB-server. Enhver server, der kan være vært for en EJB-container og levere den med de nødvendige tjenester, kan være en EJB-server. (Dette betyder, at mange eksisterende servere kan udvides til at være EJB-servere, og faktisk har mange leverandører opnået dette eller har meddelt, at de agter at gøre det.)
En EJB-komponent er den type EJB-klasse, der mest sandsynligt betragtes som en "Enterprise JavaBean." Det er en Java-klasse, skrevet af en EJB-udvikler, der implementerer forretningslogik. Alle de andre klasser i EJB-systemet understøtter enten klientadgang til eller leverer tjenester (som vedholdenhed osv.) Til EJB-komponentklasser.
Enterprise JavaBeans-containeren
EJB-containeren er, hvor EJB-komponenten "bor." EJB-containeren leverer tjenester såsom transaktions- og ressourcehåndtering, versionering, skalerbarhed, mobilitet, vedholdenhed og sikkerhed til de EJB-komponenter, den indeholder. Da EJB-containeren håndterer alle disse funktioner, kan EJB-komponentudvikleren koncentrere sig om forretningsregler og overlade databasemanipulation og andre sådanne fine detaljer til containeren. For eksempel, hvis en enkelt EJB-komponent beslutter, at den aktuelle transaktion skal afbrydes, fortæller den simpelthen sin container (på en måde defineret af EJB Spec, og containeren er ansvarlig for at udføre alle tilbageførsler eller gøre alt, hvad der er nødvendigt for at annullere en igangværende transaktion. Flere EJB-komponentforekomster findes typisk inde i en enkelt EJB-container.
EJB-objektet og den eksterne grænseflade
Klientprogrammer udfører metoder på eksterne EJB'er ved hjælp af en EJB-objekt. EJB-objektet implementerer "fjerngrænsefladen" til EJB-komponenten på serveren. Den eksterne grænseflade repræsenterer EJB-komponentens "forretningsmetoder". Fjerninterfacet udfører det egentlige, nyttige arbejde med et EJB-objekt, f.eks. Oprettelse af en ordreformular eller udsættelse af en patient til en specialist. Vi diskuterer fjerngrænsefladen mere detaljeret nedenfor.
