Klient / server er død. Det er brummen nu, hvor nyere internetbaserede teknologier blomstrer. Men disse nye teknologier er blot den naturlige udvikling af tidligere tilgange, implementeret med nyere, mere åbne protokoller og designet til at give større skalerbarhed, håndterbarhed og mangfoldighed.
Omfanget af denne udvikling er forbløffende. De fleste af de største klient- / serverleverandører har moderniseret deres produkter og dirigerer nu deres marketingdollar til tredelt teknologi. I de fleste tilfælde er de nyere produkter Java-centreret og Internet-protokol-centreret. For eksempel identificerede jeg mindst 46 Java middleware-produkter ved sidste optælling. For to år siden ville det have været svært at komme op med halvdelen af dette tal.
Dette er den første af en todelt artikelserie, der er dedikeret til at forklare Java-middleware til almindelig brug i sine nuværende former. I denne første artikel vil jeg undersøge funktionerne i aktuelle produkter og forklare, hvorfor disse funktioner er vigtige. I anden del vil Anil Hemrajani undersøge Enterprise JavaBeans (EJB) og vise, hvordan den nuværende generation af Java middleware-produkter forholder sig til og understøtter denne vigtige komponentstandard.
Baggrund
Lad os først definere Java middleware. Udtrykket omfatter applikationsservere som BEA WebLogic, messaging-produkter som Active Softwares ActiveWorks og Push Technologies's SpiritWAVE og hybridprodukter, der bygger på en DBMS-arv og tilføjer serverbaserede Java-eksekveringsfunktioner. Jeg kunne have fokuseret på et mere snævert segment, såsom applikationsservere, men det ville have været uretfærdigt over for de mange produkter, der ikke passer præcist til denne kategori, men alligevel bør overvejes for multitier-applikationer. Yderligere, selv blandt applikationsservere er der et ganske spektrum, herunder dem, der primært er servlet-servere såvel som dem, der er ORB-baserede eller OODB-baserede. Det bliver stadig vanskeligere at trække en linje mellem alle disse produkter. Den samlede funktion er dog, at de alle forsøger at løse implementeringsproblemet med flere niveauer ved hjælp af Java- og internetteknologier.
Business case til at bruge Java i middleware er overbevisende; blandt fordelene ved Java middleware er følgende:
Internets evne til økonomisk sammenkobling af kontorer og organisationer
Behovet for organisationer at samarbejde ved at dele data og forretningsprocesser
Ønsket om at konsolidere generiske tjenester og styring af disse tjenester
Ønsket om at give centraliseret applikationsadministration, herunder opstart, nedlukning, vedligeholdelse, gendannelse, belastningsbalancering og overvågning
Ønsket om at bruge åbne tjenester og protokoller
Ønsket om at omlægge forretningslogik efter ønske og ikke begrænset af infrastruktur; dette nødvendiggør brug af åbne API'er og protokoller, som understøttes bredt på tværs af de fleste infrastrukturprodukter
Behovet for at understøtte samarbejdende applikationer med blandet arkitektur
Ønsket om at flytte netværks- og serviceinfrastrukturbeslutninger ud af applikationsområdet, så systemadministratorer kan træffe infrastrukturbeslutninger uden at blive hæmmet af applikationer, der afhænger af proprietære protokoller eller funktioner
Ønsket om at reducere mangfoldigheden og niveauet af de nødvendige kvalifikationer for programmørpersonale og minimere behovet for avanceret værktøjsopbygningskompetence inden for projekter
- Ønsket om at udnytte objektorienteret ekspertise ved at udvide den til serverområdet - dermed nyere objektorienterede serverprodukter og objekt-til-relationelle broer
Målet med middleware er at centralisere softwareinfrastruktur og dens implementering. Klient / server stammer fra en æra med integration inden for en enkelt afdeling. Organisationer forsøger nu ofte at integrere på tværs af afdelingsgrænser - selv fra en organisation til en anden. Internettet - som lokker virksomheder med dets evne til at tjene som et globalt netværk, der lader afdelinger og partnere interconnect effektivt og hurtigt - har skabt efterspørgslen efter denne integration.
Java giver en lingua franca for let at sammenkoble data og applikationer på tværs af organisatoriske grænser: I et distribueret globalt miljø, hvor du ikke har kontrol over, hvilke teknologivalg dine partnere kan foretage, vælger smarte virksomheder åbne og platformneutrale standarder. Virksomheder kan ikke forudse, hvem der bliver deres kunder, partnere eller datterselskaber to år nede, så det er ikke altid muligt at planlægge en fælles infrastruktur med ens partnere. I denne usikre situation kan den bedste beslutning være at bruge de mest universelle og tilpasningsdygtige teknologier muligt.
Java giver dig mulighed for at reducere antallet af programmeringssprog og platforme, som dit personale skal forstå. Hvorfor? Fordi Java nu er implementeret i så forskellige sammenhænge som internetbrowsere, lagrede procedurer i databaser, forretningsobjekter inden for middleware-produkter og klientside-applikationer.
I en alder af tre er Java-teknologien dog stadig noget umoden, og dette gælder for de produkter, der er diskuteret i denne artikel. På den anden side kan vi nu befinde os i en æra, hvor produkter aldrig virkelig modnes, fordi de underliggende teknologier, som de er baseret på, ændrer sig så hurtigt. Faktisk har jeg fundet betydelige problemer med stort set alle middleware-produkter, jeg har brugt, herunder angiveligt modne produkter, der har været på markedet i et par år og for nylig er kommet ud med betydelige nye funktioner. Pointen er, at når en leverandør formår at løse problemer, er der tilføjet nye funktioner. Cyklussen til tilføjelse af nye funktioner er nu meget kortere, end den nogensinde har været, og så produkter har ikke tid nok til at blive stabile, før de inkluderer det næste store funktionssæt. Dette kan være noget, vi skal vænne os til, og at lære styrker og svagheder ved de produkter, vi vælger, er en vigtig del af enhver applikationsdesign og prototypecyklus.
Mål for middleware
EJB-standardvarekomponentstandarden blev udviklet med følgende mål:
At give komponentinteroperabilitet. Enterprise bønner udviklet med forskellige værktøjer vil arbejde sammen. Bønner udviklet med forskellige værktøjer kører også i ethvert EJB-miljø.
At give en brugervenlig programmeringsmodel, samtidig med at du opretholder adgangen til API'er på lavt niveau.
At løse livscyklusproblemer, herunder udvikling, implementering og runtime.
At sørge for kompatibilitet med eksisterende platforme, hvilket gør det muligt at udvide eksisterende produkter til at yde support til EJB.
For at opretholde kompatibilitet med andre Java API'er.
At give interoperabilitet mellem EJB- og ikke-Java-applikationer.
- At være kompatibel med CORBA.
Fokus for EJB-standarden er derfor at skabe en interoperabilitetsstandard for Java-middleware, der afskærmer programmører fra at skulle håndtere mange af de vanskelige problemer, der opstår, når der udvikles distribuerede applikationer. Dette giver softwareudviklere mulighed for at koncentrere sig om forretningslogik i stedet for at skrive sofistikeret hjemmelavet infrastruktur og værktøjer. Som et resultat kan virksomheder lægge det meste af deres uddannelsesmæssige ressourcer i uddannelse af personale i forretningsprocesser, hvilket typisk er det, der giver den største udbytte.
Til listen ovenfor tilføjer jeg følgende yderligere mål for Java-mellemware i virksomhedsklasse. Disse produktfunktioner er nødvendige på lang sigt for at kunne køre og vedligeholde et middleware-baseret miljø:
Det skal rumme samtrafik mellem flere forretningsenheder, virksomheder og kunder i en distribueret infrastruktur uden at gå på kompromis med sikkerheden eller indføre kaos
Det bør tillade fleksible, men pålidelige adgangskontrolmekanismer for at sikre, at forretningspartneroplysninger kun er tilgængelige på de tilsigtede måder og kun af de tilsigtede parter
Det skal tillade systemadministratorer at administrere et distribueret computermiljø, der indeholder et stort antal forretningslogikomponenter på en ensartet måde uden at skulle forstå eller anvende unikke procedurer på bestemte komponenter
det skal tillade systemadministratorer at foretage valg af infrastrukturkomponenter uden at påvirke applikationer og at indstille og skalere disse komponenter og have et ensartet og generisk middel til at måle ydeevne og ressourcebehov for alle applikationer
Det skal gøre det muligt at flytte forretningskomponenter mellem klienter og servere uden at påvirke arkitekturen for nogen af dem
Det skal tilvejebringe en sikkerhedsmekanisme, der giver bestemte brugere mulighed for at tilføje nye komponenter uden at skulle give serveradministratoren adgang til alle komponenter og datakilder (dette er en fantastisk mulighed for værditilvækstfunktion, da det er afgørende for ekstranet- og partnerskabsapplikationer )
Komponenter og funktioner på Java middleware-platforme
Den hurtigst voksende kategori af Java-middleware i dag er sandsynligvis applikationsservere. Det er dog vigtigt at indse det store udvalg af applikationsservere (og andre slags middleware-produkter), der findes. Sondring mellem Java middleware-produktkategorier i dag er ikke repræsenteret af en linje, men af et stort middleware-kontinuum. Jeg vil nu diskutere funktionerne i Java middleware baseret på mine egne arbejdssammenligninger, som omfatter hver klasse af Java middleware-produkt, jeg kender til.
Objekt-, komponent- og containermodeller
Applikationskomponenter skal overholde en runtime-implementeringsmodel, der specificerer, hvordan komponenten kommunikerer med sit miljø; (muligvis) hvordan det installeres, startes, stoppes og kaldes; og hvordan den får adgang til tjenester, der er vigtige for sit miljø. Populære Java-centrerede server-komponent runtime- og containermodeller inkluderer RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages) og Java-lagrede procedurer. Derudover kan komponentmodellerne udtrykkes på en række underliggende sprog, herunder Java, IDL, C ++ og mange andre.
Der er overlapning med forskellige komponentmodeller. For eksempel er RMI en triviel komponentmodel med meget basale faciliteter til aktivering og placering af objekter og er primært en fjernanvendelsesstandard, hvorimod EJB udnytter RMI og specificerer RMI som sin primære objektindkaldelsesmodel. EJB understøtter også CORBA. Faktisk er ingen af disse modeller eksklusive, og mange Java-applikationsservere understøtter de fleste eller alle ovenstående modeller.
Mange Java-middlewareservere kører flere forretningsobjektforekomster (som CORBA-verdenen nu kalder tjenere) inden for en enkelt Java-virtuel maskine (JVM). Typesikkerheden af Java-sproget gør det muligt for en enkelt JVM-proces at servicere anmodninger fra flere klienter og bruge programdatastrukturer og klasselæssere til at holde klientdata adskilt. Så længe tjenere ikke anvender deres egne native metoder, er det ikke muligt for en tjener at bringe andre ansatte ned, hvis den går ned (medmindre den støder på en fejl i selve JVM) eller få adgang til data, der er private for andre klasser . En korrekt designet objektserver beskytter sine private objekter og forhindrer vildfarne objekter i at få adgang til det, der hører til andre objekter.
Data, der er erklæret statisk i en Java-klasse, kan dog deles mellem klienter inden for den samme JVM, hvis klienterne bruger den samme klasselæsser, så regler skal defineres for at diktere, hvornår en separat JVM (eller svarer til en separat JVM ved hjælp af hukommelse) partitioneringsteknikker) eller separat klasselæsser er nødvendig for at give en klient sit eget statiske datarum. Sådanne regler er blevet specificeret for applets, men ikke for andre eksekveringsmiljøer. Suns Java Web Server bruger en enkelt JVM til alle servlets og et separat klassenavn til servlets med en anden kodebase. EJB omgår problemet ved at forbyde ikke-endelige statiske data.
Ydeevnen kan øges, hvis objekter inaktiveres eller passiveres, når de ikke er i brug, hvilket frigør ressourcer såsom databaseforbindelser. Af denne grund passiverer og serverer mange servere objekter efter behov. På samme måde opbevarer nogle produkter ofte oprettede objekter i en pool eller cache i initialiseret tilstand og klar til øjeblikkelig brug. Objektbeholderen skal styre passivering og genaktivering såvel som de samlede ressourcer, der er påvirket af passivering.
EJB-kompatibilitet (version)
EJB-modellen bliver allerede universelt understøttet. Næsten alle mellemvareleverandører har lovet at støtte det, og mange gør det allerede. Desuden har Object Management Group (OMG) indarbejdet en kortlægning til EJB som en del af det foreslåede CORBA-komponentspecifikation. Det er svært at forestille sig, at selv Microsoft, den enlige og standhaftige holdout, ikke i sidste ende giver og leverer EJB-containere til DCOM.
Mens forskellige EJB-kompatible middleware kan distribuere og betjene de samme applikationskomponenter (så længe disse komponenter kun bruger standard krævede EJB-funktioner), er der stadig en stor variation blandt EJB-kompatible servere. For det første udvikler EJB-specifikationen sig. Et vigtigt spørgsmål ved evaluering af Java middleware-produkter er derfor: Understøtter serveren den nyeste version af EJB, eller understøtter den kun en tidligere version? Et andet nøglespørgsmål er: Er produktet EJB-centreret, eller er EJB-support kun inkluderet i produktets merværdifunktioner (og dermed ikke tilgængelig, når EJB-tjenester eller API'er bruges)? Og endelig: Hvilke valgfri EJB-funktioner er inkluderet (for eksempel enhedsbønner og containerstyret persistens)?
