Distribuert systemutvikling vokser raskt ettersom programvareutviklere bygger systemer som må følge med de stadig økende kravene som e-handel stiller. Men aldri før har design og implementering av et meldingsbehandlingslag i et distribuert system vært så komplisert som det er i dag. Dette skyldes for det meste den dramatiske økningen i potensiell funksjonalitet som er muliggjort av standarder som Java Message Service (JMS) som kobler mange leverandørers teknologier i et enkelt system. I tillegg har spredningen av Internett gitt nye, ekspansive brukerbaser og har gjort tilgjengelig flere protokoller for kommunikasjon i et distribuert system. Slike protokoller inkluderer CORBA IIOP (Internet Inter-ORB Protocol), Microsoft DCOM (Distribuert komponentobjektmodell) og Java RMI (Remote Method Invocation).
Den naturlige utviklingen av disse protokollene har ført til innføring av meldingsorientert mellomvare (MOM), som muliggjør løsere kobling innen distribuerte systemer ved å abstrakte oversettelse, sikkerhet og de underliggende kommunikasjonsprotokollene fra klienter og servere. Middleware-løsninger inkluderer SOAP (Simple Object Access Protocol) og JMS. Proprietær mellomlagstransaksjonsbehandling har eksistert siden de første dagene av COBOL (Common Business Oriented Language), men det var ikke veldig komplisert på grunn av begrensninger for tidlig meldings teknologi.
Med fremveksten av standarder som JMS, kan utviklere nå koble til mange teknologier. Beslutninger om utforming av distribuert system er vanskeligere, og deres implikasjoner for dataintegritet og distribusjon er avgjørende for systemets suksess eller fiasko.
En gjennomgripende og stilltiende antagelse er at introduksjonen av teknologi er en ressurs mens gjeldene ofte blir ignorert. Å ikke regnskapsføre forpliktelsene resulterer ofte i et system som enten er unødvendig komplisert og / eller overkonstruert. En grunnleggende forståelse av JMS og dens iboende kvaliteter (systemuavhengige kvaliteter), etterfulgt av en nøye analyse i forhold til spesifikke distribuerte systemscenarier, kan indikere hvor godt JMS kan løse systemkrav kontra enten å endre eksisterende problemer eller til og med introdusere nye.
JMS oversikt
JMS, introdusert av Sun Microsystems i 1999 som en del av Java 2 Platform, Enterprise Edition (J2EE) spesifikasjonen, er et sett med standarder som beskriver grunnlaget for et meldingsbehandling mellomvarelag. JMS lar systemene kommunisere synkront eller asynkront via både punkt-til-punkt- og publiser-abonnementsmodeller. I dag tilbyr flere leverandører JMS-implementeringer som BEA Systems, Hewlett-Packard, IBM, Macromedia og Oracle, slik at JMS kan samhandle med flere leverandørteknologier.
Figur 1 viser et enkelt JMS-basert system med en utgående kø befolket med meldinger for klienter å behandle, og en innkommende kø, som samler klientbehandlingsresultatene for innsetting i en database.
Som nevnt ovenfor tillater MOM (som JMS) løsere kobling i distribuerte systemer ved å abstrahere oversettelse, sikkerhet og de underliggende kommunikasjonsprotokollene fra klientene og serverne. Et av hovedfordelene for meldingsbehandling er at fordi det introduserer dette abstraksjonslaget, kan implementeringen av enten klienten eller serveren endres, noen ganger radikalt, uten å påvirke andre systemkomponenter.
To spesifikke scenarier
I denne delen presenterer jeg to distribuerte systemer som er potensielle kandidater for JMS og forklarer hvert systems mål og hvorfor systemene er JMS-kandidater.
Scenario 1
Den første kandidaten er et distribuert kodingssystem (vist i figur 2). Dette systemet har et sett med N klienter som henter kodingsjobber fra en sentral databaseserver. Klientene utfører deretter den faktiske transformasjonen (koding) fra digital master til kodede filer, og avsluttes med å rapportere statusen for etterbehandling (f.eks. Suksess / mislykket) tilbake til den sentrale databaseserveren.
Typene koding (f.eks. Tekst, lyd eller video) eller transformasjoner (f.eks. .pdf til .xml, .wav til .mp3, .avi til .qt) spiller ingen rolle. Det er viktig å forstå at koding er CPU-intensiv og krever distribuert behandling over flere klienter for å skalere.
På et øyeblikk er dette systemet en potensiell JMS-kandidat fordi:
- Behandlingen må distribueres ettersom den er ekstremt prosessorintensiv (CPU)
- Fra et systemytelse synspunkt kan det være problematisk å koble flere klienter direkte til en enkelt databaseserver
Scenario 2
Det andre JMS kandidatsystemet er et globalt registreringssystem for en Internett-portal. Global registrering håndterer forespørsler om oppretting av nye brukere (registrering), pålogging og autentisering.
Spesifikk registreringsinformasjon (f.eks. Navn, adresse, favorittfarge) og brukergodkjenningsmetoder (f.eks. Bruker-objekter på serversiden, HTTP-informasjonskapsler) er uviktig. Det er imidlertid viktig at dette system skalerer for å håndtere millioner av brukere, og bruksmønstre er vanskelig, om ikke umulig, å forutsi. (Under et TV-spilt ESPN-verdensmesterskap sier kunngjøreren: "Logg inn og stem i vår online avstemning. Vi presenterer resultatene på slutten av showet." Plutselig logger 500 000 brukere seg på i løpet av tre minutter intervall. 3 minutter = 180 sekunder; 500 000 brukerinnlogginger / 180 sekunder = 2778 brukerinnlogginger / sek.)
Dette systemet er en potensiell JMS-kandidat av følgende grunner:
- Systemet må distribueres for å skalere transaksjonsvolumet
- Transaksjoner er atomare (f.eks. Innlogging), så de er statsløse og derfor kandidater til distribusjon
De to systemene er arkitektonisk like. Flere klientmaskiner trekker ut data fra en sentral databaseserver (muligens replikert til M skrivebeskyttet databaseservere), utfør litt logikk på klienten, og rapporter deretter statusen tilbake til den sentrale databaseserveren. Ett system leverer kodede filer til et filsystem over UNC / FTP; den andre leverer HTML-innhold til nettlesere via HTTP. Begge systemene er distribuert.
Dette er så langt som mange ingeniører går med analysene sine før de bruker JMS. I resten av denne artikkelen forklarer jeg at selv om disse systemene deler mange egenskaper, blir hensiktsmessigheten av JMS tydeligere og mer divergerende når vi undersøker hvert systems krav, inkludert systemytelse, datadistribusjon og skalerbarhet.
Systemanalyse: Å integrere eller ikke integrere
JMS har iboende, systemuavhengige egenskaper. Noen av disse egenskapene (fordeler betegnet med +, ulemper betegnet med -) som gjelder for begge systemene inkluderer:
- (+) JMS er et sett med standarder laget av flere leverandørimplementeringer; derfor unngår du de fryktede leverandørinnlåsing problem.
- (+) JMS tillater abstraksjon (via en generisk API) mellom klient og server; du kan endre et databaseskjema eller en plattform uten å endre applikasjonslaget (implisitt her er andre potensielle systemendringer, isolert fra hverandre av meldingslaget).
- (+)/(-) JMS kan hjelpe en systemskala (en proff). Ulempen er at ethvert system som skalerer med JMS kan skaleres uten det.
- (-) JMS er komplisert. Det er et helt nytt lag med et nytt sett med servere. Administrasjon av programvareutrulling, serverovervåking og sikkerhet er bare noen få av de ikke-private problemene knyttet til en JMS-utrulling. Kostnader bør også vurderes.
- (-) Leverandører tolker ikke alltid og implementerer derfor standarder nøyaktig på samme måte, så det er forskjeller mellom forskjellige implementeringer.
- (-) Med JMS trenger du flere systemkontroller og saldoer. Du introduserer ikke bare et nytt lag, du introduserer også asynkron datadistribusjon og bekreftelse, som har den ekstra kompleksiteten til asynkron varsling.
- (-) Ingen meldingsrapportering / oppdatering / overvåking av køer uten tilpasset programvare.
JMS har også systemavhengige kvaliteter. Hvorvidt JMS er hensiktsmessig, avhenger av hvor godt disse egenskapene tilordnes til problemstillingen du prøver å løse. Noen av disse egenskapene og hvordan de forholder seg til de to interessesystemene følger:
Caching
Caching er et primært hensyn til kapasitetsplanlegging i ethvert distribuert system. JMS har mange funksjoner som tillater bruk som cache-teknologi (hovedsakelig at den er distribuert, synkron eller asynkron, og datautveksling som objekter i meldinger). Derfor kan en eksisterende JMS-installasjon benyttes som en infrastruktur for hurtigbufring hvis nødvendig.
Når du vurderer kodingssystemet, er caching generelt ikke nyttig for å øke den totale systemytelsen, da de fleste filtransformasjoner utføres en gang og flytter til et vertsanlegg eller SAN (lagringsnett), og det er lite innhold overlapper hverandre mellom kundene. Global registrering er en hovedkandidat for en brukerinformasjonsbuffer, ettersom brukere vanligvis logger på, blar og deretter logger av. Pålogging oppretter en brukers cacheoppføring, og dette objektet gir påfølgende brukerautentisering mens brukeren er på nettstedet.
Behandlingsordre
Innenfor det globale registreringssystemet er det ingen planlegging og / eller bestilling for transaksjonsbehandling. Pseudo-tilfeldige brukere kommer inn i systemet med pseudo-tilfeldige intervaller ved pålogging, blar gjennom innhold (og blir derfor autentisert når de får tilgang til begrenset innhold og / eller applikasjoner), og deretter logger av.
Innenfor kodingssystemet bestilles behandling. Innholdspartier i grupper for levering avhengig av tilgjengeligheten til flyttbar lagring (f.eks. DLT-løsninger eller lagring av nettverksapparater). Innhold leveres ikke før batchen er fullført, så batchene må utføres i rekkefølge (selv om transformasjoner i en batch potensielt kan være uordnet). Implementering av prioritetskøer i JMS for å bevare behandlingsordren er mulig, men å opprettholde denne rekkefølgen på meldingsbatcher mellom flere JMS-servere og flere køer blir ganske komplisert. En relasjonell databaseserver med støtte for transaksjoner er en mer passende teknologi for å håndtere denne arbeidsflyten.
Sikkerhet
Sikkerhet er ikke en del av JMS-spesifikasjonen. Sikkerhetsproblemet endres ikke nødvendigvis med en JMS-basert implementering (hvis du har et sikkerhetskrav før JMS, vil du ha et lignende sikkerhetskrav etter JMS). Når du vet dette, er det viktig å forstå hvordan JMS kan forholde seg til eksisterende infrastruktur sikkerhet.
Generelt, jo mer teknologi du bruker, jo mer sårbart blir systemet ditt for hackere og sikkerhetsbrudd. Fordi den globale registreringsapplikasjonsserveren er vendt mot nettet, blir sikkerhetsfeil oppdaget i leverandørenes JMS-implementering og publisert i nyhetsgrupper på Internett raskt sikkerhetsforpliktelser for nettstedet ditt. Også fordi JMS er en generisk API, er den mer utsatt for sikkerhetsbrudd enn et proprietært system som bruker en upublisert API.
Mens du kan utnytte din eksisterende brannmur og IP-baserte nettverkssikkerhet for å beskytte din back-end (les: ikke web-vendt - ordspill beregnet) applikasjon og databaseservere mot sikkerhetsbrudd, er det en betydelig sikkerhetsrisiko skapt ved å eksponere JMS-applikasjonsservere direkte til Internett.
Kodingssystemet eksisterer vanligvis på samme nettverk (også et nettverk isolert fra Internett). Så det er ingenting som ligger i dette systemets nettverkstopografi som er relatert til JMS og utnytter denne topografien for å gi sikkerhet (det er langt færre sikkerhetskrav til kodingssystemet, da det ikke er web-vendt).
Skalerbarhet
Fordi det globale registreringssystemet er underlagt innfall av en stor og lunefullt klikkende brukerbase, garanterer systemets skalerbarhetskrav JMS. JMS hjelper ikke bare med å skalere systemet, det vil også kjøpe transaksjoner, selv om det ikke vil være mye hjelp når brukerforespørsler oversvømmer systemet.
Fordi det distribuerte kodingssystemet har nøye regulert datatrafikk (da det antagelig er et selvstendig system), er ikke systemets skalerbarhetskrav like formidable. For distribuert koding kan du koble til O [100] klienter direkte til databasen din og strup trafikken for å balansere kodingsgjennomstrømningen med databaseserverytelsen.
Opptreden
Innføringen av en enkelt JMS-server kan endre ytelsesproblemer i stedet for å løse dem. Av denne grunn bør et JMS-system utformes med flere JMS-servere (og derfor flere køer). Figur 4 viser hvorfor ytelsesproblemer endres i stedet for løses. Det illustrerer prosesseringslagene som kreves for at en generisk dataserver skal svare på forespørsler om klienttilkobling:
Datautveksling mellom klient og server er en todelt prosess, enten dette er en klient-til-database eller klient-til-JMS-server:
- Datatilgang
- Tråd- og sokkelhåndtering, pooling og caching
En JMS og en databaseserver ser helt like ut (figur 4). De håndterer stikkontakter, trådadministrasjon og tilgang til serverens data.
Med bare en JMS-server pendler potensielle ytelsesproblemer ganske enkelt fra databaseserveren til JMS-serveren. I tillegg til mulig ytelsesnedbrytning assosiert med kontekstbytte på databaseserveren, er ytelsesproblemer nå potensielt større på grunn av JVM-ytelsesproblemer på JMS-serveren.
En enkelt JMS-server tilfører systemet betydelig kompleksitet og kan også introdusere ytelsesproblemer knyttet til tilkobling av flere klienter til en enkelt server. Effekten av flere JMS-servere på systemdesign og dataflyt kan bety forskjellen mellom en vellykket eller mislykket systemutrulling.
Oppsummert ser funksjoner versus potensiell JMS-innvirkning slik ut:
Funksjoner kontra JMS-innvirkning
