Klient / server er død. Det er suset nå som nyere internettbaserte teknologier blomstrer. Men de nye teknologiene er bare den naturlige utviklingen av tidligere tilnærminger, implementert med nyere, mer åpne protokoller og designet for å gi større skalerbarhet, håndterbarhet og mangfold.
Omfanget av denne utviklingen er forbløffende. De fleste av de store klient- / serverleverandørene har modernisert produktene sine og retter nå markedsføringsdollene sine til tredelt teknologi. I de fleste tilfeller er de nyere produktene Java-sentriske og Internett-protokoll-sentriske. For eksempel identifiserte jeg minst 46 Java middleware-produkter ved siste telling. For to år siden hadde det vært vanskelig å finne på halvparten av dette tallet.
Dette er den første av en todelt serie artikler dedikert til å forklare Java-mellomvare i generell bruk i sine nåværende former. I denne første artikkelen vil jeg undersøke funksjonene til nåværende produkter og forklare hvorfor disse funksjonene er viktige. I den andre delen vil Anil Hemrajani undersøke Enterprise JavaBeans (EJB) og vise hvordan den nåværende generasjonen av Java middleware-produkter forholder seg til og støtter denne viktige komponentstandarden.
Bakgrunn
La oss først definere Java mellomvare. Begrepet omfatter applikasjonsservere som BEA WebLogic, meldingsprodukter som Active Softwares ActiveWorks og Push Technologies SpiritWAVE, og hybridprodukter som bygger på en DBMS-arv og legger til serverbaserte Java-objektutførelsesfunksjoner. Jeg kunne ha fokusert på et mer smalt segment, for eksempel applikasjonsservere, men det ville ha vært urettferdig for de mange produktene som ikke passer akkurat denne kategorien, men som likevel bør vurderes for applikasjoner med flere nivåer. Videre er det til og med blant applikasjonsservere et ganske spekter, inkludert de som hovedsakelig er servletservere, så vel som de som er ORB-baserte eller OODB-baserte. Det blir stadig vanskeligere å trekke en linje mellom alle disse produktene. Den samlende funksjonen er imidlertid at de alle prøver å løse distribusjonsproblemet med flere nivåer ved hjelp av Java og Internett-teknologier.
Business case å bruke Java i mellomvare er overbevisende; blant fordelene som Java middleware tilbyr, er følgende:
Internets evne til økonomisk sammenkobling av kontorer og organisasjoner
Behovet for organisasjoner å samarbeide ved å dele data og forretningsprosesser
Ønsket om å konsolidere generiske tjenester og forvaltningen av disse tjenestene
Ønsket om å tilby sentralisert applikasjonsadministrasjon, inkludert oppstart, nedleggelse, vedlikehold, gjenoppretting, lastbalansering og overvåking
Ønsket om å bruke åpne tjenester og protokoller
Ønsket om å omplassere forretningslogikk etter eget ønske og ubegrenset av infrastruktur; dette nødvendiggjør bruk av åpne APIer og protokoller, som støttes bredt på tvers av de fleste infrastrukturprodukter
Behovet for å støtte samarbeidende applikasjoner med blandet arkitektur
Ønsket om å flytte beslutninger om nettverk og tjenesteinfrastruktur ut av applikasjonsområdet, slik at systemadministratorer kan ta infrastrukturbeslutninger uten å bli hindret av applikasjoner som er avhengige av proprietære protokoller eller funksjoner
Ønsket om å redusere mangfoldet og nivået på ferdigheter som kreves av programmererpersonalet og minimere behovet for avansert kompetanse innen verktøybygging innen prosjekter
- Ønsket om å utnytte objektorientert ekspertise ved å utvide den til serverområdet - derav nyere objektorienterte serverprodukter og objekt-til-relasjonelle broer
Målet med mellomvare er å sentralisere programvareinfrastruktur og distribusjon. Klient / server stammer fra en tid med integrasjon i en enkelt avdeling. Organisasjoner prøver nå ofte å integrere på tvers av avdelingsgrenser - til og med fra en organisasjon til en annen. Internett - som lokker bedrifter med sin evne til å tjene som et globalt nettverk som lar avdelinger og partnere koble sammen effektivt og raskt - har skapt etterspørselen etter denne integrasjonen.
Java gir en Lingua franca for enkelt å koble sammen data og applikasjoner på tvers av organisasjonsgrenser: I et distribuert globalt miljø, der du ikke har kontroll over hvilke teknologivalg partnerne dine kan gjøre, velger smarte selskaper åpne og plattformnøytrale standarder. Bedrifter kan ikke forutse hvem som blir deres kunder, partnere eller datterselskaper to år lenger nede, så det er ikke alltid mulig å planlegge en felles infrastruktur med partnerne. I denne usikre situasjonen kan den beste avgjørelsen være å bruke mest mulig universelle og tilpasningsdyktige teknologier.
Java lar deg redusere antall programmeringsspråk og plattformer de ansatte må forstå. Hvorfor? Fordi Java nå distribueres i så forskjellige sammenhenger som nettlesere, lagrede prosedyrer i databaser, forretningsobjekter innen mellomvareprodukter og applikasjoner på klientsiden.
I en alder av tre er Java-teknologien likevel noe umoden, og dette gjelder for produktene som er diskutert i denne artikkelen. På den annen side kan det hende at vi nå befinner oss i en tid da produkter aldri virkelig blir modne, fordi de underliggende teknologiene som de bygger på endrer seg så raskt. Faktisk har jeg funnet betydelige problemer med nesten alle mellomvareprodukter jeg har brukt, inkludert antatt modne produkter som har vært på markedet i noen år og nylig har kommet ut med betydelige nye funksjoner. Poenget er at når en leverandør klarer å løse problemer, har nye funksjoner blitt lagt til. Syklusen for å legge til nye funksjoner er nå mye kortere enn den noen gang har vært, og slik at produktene ikke har nok tid til å bli stabile før de inkluderer neste store funksjonssett. Dette kan være noe vi må venne oss til, og å lære styrker og svakheter ved produktene vi velger er en viktig del av enhver applikasjonsdesign og prototypesyklus.
Mål for mellomvare
EJB-mellomvarekomponentstandarden ble utviklet med følgende mål:
For å gi komponentens interoperabilitet. Bedriftsbønner utviklet med forskjellige verktøy vil fungere sammen. Bønner utviklet med forskjellige verktøy vil også kjøre i ethvert EJB-miljø.
Å tilby en brukervennlig programmeringsmodell mens du opprettholder tilgangen til APIer på lavt nivå.
For å løse livssyklusproblemer, inkludert utvikling, distribusjon og kjøretid.
Å sørge for kompatibilitet med eksisterende plattformer, som gjør det mulig å utvide eksisterende produkter for å gi støtte for EJB.
For å opprettholde kompatibilitet med andre Java API-er.
Å gi interoperabilitet mellom EJB og ikke-Java-applikasjoner.
- For å være kompatibel med CORBA.
Fokuset på EJB-standarden er derfor å lage en interoperabilitetsstandard for Java mellomvare, som beskytter programmerere fra å måtte håndtere mange av de vanskelige problemene som oppstår når man utvikler distribuerte applikasjoner. Dette lar programvareutviklere konsentrere seg om forretningslogikk i stedet for å skrive sofistikert hjemmelaget infrastruktur og verktøy. Som et resultat kan bedrifter legge mesteparten av utdanningsressursene i opplæringspersonale i forretningsprosesser, noe som vanligvis er det som gir størst utbytte.
I listen over legger jeg til følgende tilleggsmål for Java-mellomvare i bedriftsklasse. Disse produktfunksjonene er nødvendige på lang sikt for å kunne kjøre og vedlikeholde et mellomvarebasert miljø:
Den skal imøtekomme samtrafikken mellom flere forretningsenheter, selskaper og kunder i en distribuert infrastruktur uten å gå på kompromiss med sikkerheten eller innføre kaos
Det skal tillate fleksible, men likevel pålitelige tilgangskontrollmekanismer for å sikre at forretningspartneropplysninger bare er tilgjengelig på de tiltenkte måtene, og bare av de tiltenkte partene
Det skal tillate systemadministratorer å administrere et distribuert databehandlingsmiljø som inneholder et stort antall forretningslogikkomponenter på en enhetlig måte, uten å måtte forstå eller bruke unike prosedyrer på bestemte komponenter
det skal tillate systemadministratorer å velge infrastrukturkomponentvalg uten å påvirke applikasjoner, og å stille inn og skalere disse komponentene og ha et enhetlig og generisk middel til å måle ytelsen og ressursbehovet til alle applikasjoner
Det skal tillate at virksomhetskomponenter flyttes mellom klienter og servere uten å påvirke arkitekturen til noen av dem
Det skal gi en sikkerhetsmekanisme som gjør det mulig for bestemte brukere å legge til nye komponenter, uten å måtte gi serveradministratoren tilgang til alle komponenter og datakilder (dette er en flott mulighet for verdiskapingskapasitet, da det er viktig for ekstranett- og partnerskapsprogrammer. )
Komponenter og funksjoner på Java mellomvare-plattformer
Den raskest voksende kategorien av Java mellomvare i dag er sannsynligvis applikasjonsservere. Det er imidlertid viktig å innse det store utvalg av applikasjonsservere (og andre typer mellomvareprodukter) som finnes. Forskjeller mellom produktkategorier for Java mellomvare i dag representeres ikke av en linje, men av et stort mellomvarekontinuum. Jeg vil nå diskutere funksjonene til Java mellomvare, basert på mine egne arbeidssammenligninger, som omfatter alle klasser av Java mellomvare som jeg vet om.
Objekt-, komponent- og containermodeller
Applikasjonskomponenter må overholde noen distribusjonsmodell for kjøretid, som spesifiserer hvordan komponenten kommuniserer med omgivelsene; (muligens) hvordan den installeres, startes, stoppes og kalles; og hvordan den får tilgang til tjenester som er viktige for miljøet. Populære Java-sentriske server-komponent kjøretids- og containermodeller inkluderer RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages) og Java-lagrede prosedyrer. I tillegg kan komponentmodellene uttrykkes på en rekke underliggende språk, inkludert Java, IDL, C ++ og mange andre.
Det er overlapping med ulike komponentmodeller. For eksempel er RMI en triviell komponentmodell med veldig grunnleggende fasiliteter for aktivering og plassering av objekter, og er primært en ekstern påkallingsstandard, mens EJB utnytter RMI og spesifiserer RMI som sin primære objektpåkallingsmodell. EJB støtter også CORBA. Faktisk er ingen av disse modellene eksklusive, og mange Java-applikasjonsservere støtter de fleste eller alle modellene ovenfor.
Mange Java-mellomvareservere kjører flere forretningsobjektforekomster (som CORBA-verdenen nå kaller tjenere) på en enkelt Java virtuell maskin (JVM). Typesikkerheten til Java-språket gjør at en enkelt JVM-prosess kan betjene forespørsler fra flere klienter og bruke programdatastrukturer og klasselastere for å holde klientdata atskilt. Så lenge tjenere ikke bruker sine egne innfødte metoder, er det ikke mulig for en tjener å bringe andre tjenere ned hvis den krasjer (med mindre den støter på en feil i selve JVM), eller få tilgang til data som er private for andre klasser. . En riktig designet objektserver vil beskytte sine private objekter og forhindre at villfarne objekter får tilgang til det som tilhører andre objekter.
Imidlertid kan data som er erklært statisk i en Java-klasse, deles mellom klienter innen samme JVM hvis klientene bruker samme klasselaster, så regler må defineres for å diktere når en separat JVM (eller tilsvarende en separat JVM som bruker minne- partisjoneringsteknikker) eller separat klasselaster er nødvendig for å gi en klient sin egen statiske datarom. Slike regler er spesifisert for appletter, men ikke for andre kjøringsmiljøer. Suns Java Web Server bruker en enkelt JVM for alle servlets og en egen klasse navneplass for servlets med en annen kodebase. EJB omgår problemet ved å forby ikke-endelige statiske data.
Ytelsen kan økes hvis objekter inaktiveres eller passiveres når de ikke er i bruk, noe som frigjør ressurser som databaseforbindelser. Av denne grunn passiverer og serverer mange servere objekter etter behov. På samme måte holder noen produkter ofte opprettede objekter i et basseng eller en cache i initialisert tilstand og klare til umiddelbar bruk. Objektbeholderen må håndtere passivering og reaktivering, samt de samlede ressursene som er påvirket av passivering.
EJB-kompatibilitet (versjon)
EJB-modellen blir allerede universelt støttet. Nesten alle mellomvareleverandører har lovet å støtte det, og mange gjør det allerede. Videre har Object Management Group (OMG) innarbeidet en kartlegging til EJB som en del av det foreslåtte CORBA komponentspesifikasjon. Det er vanskelig å forestille seg at selv Microsoft, den eneste og standhaftige holdout, ikke til slutt vil gi og gi EJB-containere for DCOM.
Mens forskjellig EJB-kompatibel mellomvare kan distribuere og bruke de samme applikasjonskomponentene (så lenge disse komponentene bare bruker standardkrevde EJB-funksjoner), er det fortsatt stor variasjon blant EJB-kompatible servere. For det første utvikler EJB-spesifikasjonen seg. Et viktig spørsmål ved evaluering av Java-mellomvareprodukter er derfor: Støtter serveren den nyeste versjonen av EJB, eller støtter den bare en tidligere versjon? Et annet sentralt spørsmål er: Er produktet EJB-sentrisk, eller er EJB-støtte bare inkludert i produktets verdiskapende funksjoner (og dermed utilgjengelig når EJB-tjenester eller API-er brukes)? Og til slutt: Hvilke valgfrie EJB-funksjoner er inkludert (for eksempel enhetsbønner og containerstyrt utholdenhet)?
