Skal du gå med JMS?

Distribueret systemudvikling vokser hurtigt, da softwareudviklere bygger systemer, der skal følge med de stadigt stigende krav, som e-handel stiller. Men aldrig før har design og implementering af et meddelelsesbehandlingslag i et distribueret system været så kompliceret som det er i dag. Dette skyldes for det meste den dramatiske stigning i potentiel funktionalitet aktiveret af standarder som Java Message Service (JMS), der forbinder mange leverandørers teknologier i et enkelt system. Derudover har spredningen af ​​Internettet givet anledning til nye, ekspansive brugerbaser og har stillet flere protokoller til rådighed til kommunikation inden for et distribueret system. Sådanne protokoller inkluderer CORBA IIOP (Internet Inter-ORB-protokol), Microsoft DCOM (Distribueret komponentobjektmodel) og Java RMI (Remote Method Invocation).

Den naturlige udvikling af disse protokoller har ført til introduktionen af ​​meddelelsesorienteret middleware (MOM), som giver mulighed for løsere kobling inden for distribuerede systemer ved at abstrahere oversættelse, sikkerhed og de underliggende kommunikationsprotokoller fra klienter og servere. Middlewareløsninger inkluderer SOAP (Simple Object Access Protocol) og JMS. Proprietær mellemlagstransaktionsbehandling har eksisteret siden de tidlige dage af COBOL (Common Business Oriented Language), men det var ikke meget komplekst på grund af tidlige meddelelsesteknologiers begrænsninger.

Med fremkomsten af ​​standarder som JMS kan udviklere nu forbinde adskillige teknologier. Beslutninger om distribuerede systemdesign er sværere, og deres konsekvenser for dataintegritet og distribution er afgørende for systemets succes eller fiasko.

En gennemgribende og stiltiende antagelse er, at introduktionen af ​​teknologi er et aktiv, mens dens forpligtelser ofte ignoreres. Ikke at tage højde for forpligtelserne resulterer ofte i et system, der enten er unødvendigt kompliceret og / eller overkonstrueret. En grundlæggende forståelse af JMS og dens iboende kvaliteter (systemuafhængige kvaliteter) efterfulgt af en omhyggelig analyse i forhold til specifikke distribuerede systemscenarier kan indikere, hvor godt JMS kan løse systemkrav versus enten at ændre eksisterende problemer eller endda indføre nye.

JMS oversigt

JMS, der blev introduceret af Sun Microsystems i 1999 som en del af Java 2 Platform, Enterprise Edition (J2EE) -specifikationen, er et sæt standarder, der beskriver grundlaget for et meddelelsesbehandlings-middlewarelag. JMS gør det muligt for systemer at kommunikere synkront eller asynkront via både point-to-point- og publish-subscribe-modeller. I dag leverer flere leverandører JMS-implementeringer som BEA Systems, Hewlett-Packard, IBM, Macromedia og Oracle, hvorved JMS kan interagere med flere leverandørteknologier.

Figur 1 viser et simpelt JMS-baseret system med en udgående kø befolket med meddelelser, som klienter skal behandle, og en indgående kø, der indsamler klientbehandlingsresultaterne til indsættelse i en database.

Som nævnt ovenfor tillader MOM (som JMS) løsere kobling inden for distribuerede systemer ved at abstrahere oversættelse, sikkerhed og de underliggende kommunikationsprotokoller fra klienterne og serverne. Et af meddelelsesbehandlingslagets vigtigste aktiver er, at implementeringen af ​​enten klienten eller serveren kan ændres, nogle gange radikalt, uden at påvirke andre systemkomponenter, fordi det introducerer dette abstraktionslag.

To specifikke scenarier

I dette afsnit præsenterer jeg to distribuerede systemer, der er potentielle kandidater til JMS, og forklarer hvert systems mål, og hvorfor systemerne er JMS-kandidater.

Scenarie 1

Den første kandidat er et distribueret kodningssystem (vist i figur 2). Dette system har et sæt N klienter, der henter kodningsjob fra en central databaseserver. Klienterne udfører derefter den faktiske transformation (kodning) fra digital master til kodede filer og afslutter ved at rapportere deres efterbehandlingsstatus (f.eks. Succes / mislykket) tilbage til den centrale databaseserver.

Kodningstyperne (f.eks. Tekst, lyd eller video) eller transformationer (f.eks. .pdf til .xml, .wav til .mp3, .avi til .qt) ligemeget. Det er vigtigt at forstå, at kodning er CPU-intensiv og kræver distribueret behandling på tværs af flere klienter for at skalere.

Med et overblik er dette system en potentiel JMS-kandidat, fordi:

• Behandling skal distribueres, da den er ekstremt processor (CPU) intensiv
• Fra et systemydelsessynspunkt kan det være problematisk at forbinde flere klienter direkte til en enkelt databaseserver

Scenarie 2

Det andet JMS kandidatsystem er et globalt registreringssystem til en internetportal. Global registrering håndterer anmodninger om oprettelse af nye brugere (registrering), login og godkendelse.

Specifikke registreringsoplysninger (f.eks. Navn, adresse, yndlingsfarve) og brugergodkendelsesmetoder (f.eks. Brugers objekter på serversiden, HTTP-cookies) er ikke vigtige. Det er dog vigtigt, at dette system skalerer til at håndtere millioner af brugere, og brugsmønstre er vanskelige, om ikke umulige, at forudsige. (Under et fjernsynet ESPN-verdensmesterskab siger annoncøren: "Log ind og stem i vores online afstemning. Vi præsenterer resultaterne i slutningen af ​​showet." Pludselig logger 500.000 brugere på inden for tre minutter interval. 3 minutter = 180 sekunder; 500.000 brugerlogins / 180 sekunder = 2.778 brugerlogins / sek.)

Dette system er en potentiel JMS-kandidat af følgende grunde:

• Systemet skal distribueres for at skalere transaktionsvolumen
• Transaktioner er atomare (f.eks. Login), så de er statsløse og derfor kandidater til distribution

De to systemer er arkitektonisk ens. Flere klientmaskiner udtrækker data fra en central databaseserver (muligvis replikeret ud til M skrivebeskyttede databaseservere), udfør en vis logik på klienten, og rapporter derefter status tilbage til den centrale databaseserver. Et system leverer kodede filer til et filsystem via UNC / FTP; den anden leverer HTML-indhold til webbrowsere via HTTP. Begge systemer er distribueret.

Dette er så vidt mange ingeniører går med deres analyser, inden de anvender JMS. I resten af ​​denne artikel forklarer jeg, at selvom disse systemer deler mange karakteristika, bliver hensigtsmæssigheden af ​​JMS klarere og mere divergerende, når vi undersøger hvert systems krav, herunder systemydelse, datadistribution og skalerbarhed.

Systemanalyse: At integrere eller ikke integrere

JMS har iboende, systemuafhængige kvaliteter. Nogle af disse kvaliteter (fordele betegnet med +, ulemper betegnet med -), der gælder for begge systemer, inkluderer:

• (+) JMS er et sæt standarder oprettet af flere leverandørimplementeringer; derfor undgår du de frygtede sælger-lock-in problem.
• (+) JMS muliggør abstraktion (via en generisk API) mellem klient og server; du kan ændre et databaseskema eller en platform uden at ændre applikationslaget (implicit her er andre potentielle systemændringer, isoleret fra hinanden ved hjælp af beskedlaget).
• (+)/(-) JMS kan hjælpe en systemskala (et proffs). Ulempen er, at ethvert system, der skalerer med JMS, kan skaleres uden det.
• (-) JMS er kompliceret. Det er et helt nyt lag med et nyt sæt servere. Styring af softwareudrulning, serverovervågning og sikkerhed er blot nogle få af de ikke-private problemer forbundet med en JMS-udrulning. Omkostninger bør også overvejes.
• (-) Leverandører fortolker ikke altid og implementerer derfor standarder Nemlig på samme måde, så der er forskelle mellem forskellige implementeringer.
• (-) Med JMS har du brug for flere systemkontroller og -balancer. Du introducerer ikke kun et nyt lag, du introducerer også asynkron datadistribution og kvittering, som har den ekstra kompleksitet af asynkron underretning.
• (-) Ingen meddelelsesrapportering / opdatering / overvågning af køer uden brugerdefineret software.

JMS har også systemafhængige kvaliteter. Hvorvidt JMS er hensigtsmæssig, afhænger af, hvor godt disse kvaliteter tildeles det problem sæt, du prøver at løse. Nogle af disse kvaliteter og hvordan de relaterer sig til de to interessesystemer følger:

Caching

Caching er et primært hensyn til kapacitetsplanlægning inden for ethvert distribueret system. JMS har mange funktioner, der tillader dets anvendelse som en cacheteknologi (hovedsagelig at den er distribueret, synkron eller asynkron og dataudveksling som objekter i meddelelser). Derfor kan en eksisterende JMS-installation udnyttes som en cacheinfrastruktur, hvis det kræves.

Når man overvejer kodningssystemet, er caching generelt ikke nyttigt for at øge den samlede systemydelse, da de fleste filtransformationer udføres en gang og flytter til en hostingfacilitet eller SAN (lagerområdet), og der er lidt indhold overlapning mellem kunderne. Global registrering er en af ​​de vigtigste kandidater til en brugerinformationscache, da brugere normalt logger ind, gennemser og derefter logger af. Login opretter en brugers cacheindgang, og dette objekt giver efterfølgende brugergodkendelse, mens brugeren er på stedet.

Behandlingsordre

Inden for det globale registreringssystem er der ingen planlægning og / eller ordre til transaktionsbehandling. Pseudo-tilfældige brugere kommer ind i systemet med pseudo-tilfældige intervaller ved login, gennemse indhold (og godkendes derfor, når de får adgang til begrænset indhold og / eller applikationer) og logger derefter ud.

Inden for kodningssystemet bestilles behandling. Indholdspartier i grupper til levering afhængigt af tilgængeligheden af ​​flytbart lager (f.eks. DLT-løsninger eller netværksapparatlagring). Indholdet leveres ikke, før batchen er færdig, så batches skal udføres i rækkefølge (selvom transformationer inden for en batch potentielt kan være uordnet). Implementering af prioritetskøer inden for JMS for at bevare behandlingsordren er mulig, men det er ret kompliceret at opretholde denne rækkefølge af meddelelsesbatcher mellem flere JMS-servere og flere køer. En relationsdatabaseserver med understøttelse af transaktioner er en mere passende teknologi til styring af denne arbejdsgang.

Sikkerhed

Sikkerhed er ikke en del af JMS-specifikationen. Sikkerhedsproblemet ændres ikke nødvendigvis med en JMS-baseret implementering (hvis du har et sikkerhedskrav før JMS, vil du have et lignende sikkerhedskrav efter JMS). Når du ved dette, er det vigtigt at forstå, hvordan JMS kan relateres til eksisterende infrastruktursikkerhed.

Generelt, jo mere teknologi du bruger, jo mere sårbart bliver dit system over for hackere og sikkerhedsovertrædelser. Fordi den globale registreringsapplikationsserver er vendt mod web, bliver sikkerhedsfejl, der er opdaget i dine leverandørers JMS-implementering og offentliggjort i internetnyhedsgrupper, hurtigt sikkerhedsforpligtelser for dit websted. Også fordi JMS er en generisk API, er den mere tilbøjelig til sikkerhedsbrud end et proprietært system, der bruger en upubliceret API.

Mens du kan udnytte din eksisterende firewall og IP-baserede netværkssikkerhed for at beskytte din back-end (læs: ikke webvendt-ordspil beregnet) applikation og databaseservere mod sikkerhedsovertrædelser, er der en betydelig sikkerhedsrisiko skabt ved at udsætte JMS-applikationsservere direkte til Internettet.

Kodningssystemet findes generelt på det samme netværk (også et netværk isoleret fra Internettet). Så der er intet iboende ved dette systems netværkstopografi, der vedrører JMS og udnytter denne topografi til at give sikkerhed (der er langt færre sikkerhedskrav til kodningssystemet, da det ikke er web-vendt).

Skalerbarhed

Da det globale registreringssystem er underlagt indfaldene fra en stor og lunefuldt klikende brugerbase, berettiger systemets skalerbarhedskrav til JMS. JMS hjælper ikke kun med at skalere systemet, det vil køtransaktioner, selvom det ikke vil være meget hjælp, når brugeranmodninger oversvømmer systemet.

Fordi det distribuerede kodningssystem har nøje reguleret datatrafik (da det formodentlig er et selvstændigt system), er systemets skalerbarhedskrav ikke så formidable. For distribueret kodning kan du forbinde din O [100] klienter direkte til din database og reducere deres trafik for at balancere kodningsgennemstrømning med databaseserverydelse.

Ydeevne

Introduktionen af ​​en enkelt JMS-server kan ændre ydelsesproblemer i stedet for at løse dem. Af denne grund skal et JMS-system designes med flere JMS-servere (og derfor flere køer). Figur 4 viser, hvorfor præstationsproblemer ændres i stedet for at blive løst. Det illustrerer de behandlingslag, der kræves for at en generisk dataserver kan svare på anmodninger om klientforbindelse:

Dataudveksling mellem klient og server er en todelt proces, hvad enten det er en klient-til-database eller klient-til-JMS-server:

1. Dataadgang
2. Tråd- og sokkelstyring, pooling og caching

En JMS og en databaseserver ser nøjagtig det samme ud (figur 4). De håndterer stikforbindelser, trådadministration og adgang til serverens data.

Med kun en JMS-server pendler potentielle ydelsesproblemer simpelthen fra databaseserveren til JMS-serveren. Ud over mulig præstationsforringelse forbundet med kontekstskift på din databaseserver, er ydeevneproblemer nu potentielt større på grund af problemer med JVM-ydelse inden for din JMS-server.

En enkelt JMS-server tilføjer betydelig kompleksitet til dit system og kan muligvis også introducere ydeevneproblemer relateret til forbindelsen af ​​flere klienter til en enkelt server. Indvirkningen af ​​flere JMS-servere på dit systemdesign og datastrøm kan betyde forskellen mellem en vellykket eller mislykket systemudrulning.

Sammenfattende ser funktioner versus potentiel JMS-indvirkning sådan ud:

Funktioner versus JMS-indvirkning