Programmēšana

Vai jums vajadzētu iet ar JMS?

Sadalīto sistēmu izstrāde strauji pieaug, jo programmatūras izstrādātāji izveido sistēmas, kurām jāseko līdzi arvien pieaugošajām prasībām, ko nosaka e-bizness. Bet nekad agrāk ziņojumu apstrādes slāņa izstrāde un ieviešana izplatītajā sistēmā nav bijusi tik sarežģīta kā šodien. Tas galvenokārt skaidrojams ar dramatisko potenciālās funkcionalitātes pieaugumu, ko iespējoja tādi standarti kā Java Message Service (JMS), kas vienā sistēmā savieno daudzu piegādātāju tehnoloģijas. Turklāt interneta izplatīšanās ir radījusi jaunas, plašas lietotāju bāzes un ir darījusi pieejamus vairākus protokolus saziņai sadalītās sistēmas ietvaros. Šādi protokoli ietver CORBA IIOP (interneta starp-ORB protokols), Microsoft DCOM (izplatītā komponenta objekta modelis) un Java RMI (attālās metodes izsaukšana).

Šo protokolu dabiskā attīstība ir ļāvusi ieviest uz ziņojumu orientētu starpprogrammatūru (MOM), kas ļauj brīvāk sasaistīt izplatītās sistēmās, abstrahējot tulkošanu, drošību un pamatā esošos sakaru protokolus no klientiem un serveriem. Starpprogrammatūras risinājumi ietver SOAP (vienkāršu objektu piekļuves protokolu) un JMS. Īpašumtiesības, vidējā slāņa darījumu apstrāde pastāv jau kopš COBOL (Common Business Oriented Language) pirmsākumiem, taču agrīnu ziņojumapmaiņas tehnoloģiju ierobežojumu dēļ tā nebija ļoti sarežģīta.

Ar tādu standartu kā JMS parādīšanos izstrādātāji tagad var savienot daudzas tehnoloģijas. Sadalītās sistēmas dizaina lēmumi ir grūtāk, un to ietekme uz datu integritāti un izplatīšanu ir izšķiroša, lai sistēma gūtu panākumus vai kļūmes.

Visaptverošs un klusējošs pieņēmums ir tāds, ka tehnoloģiju ieviešana ir aktīvs, bet tās saistības bieži tiek ignorētas. Pienākumu neuzskaitīšana bieži rada nevajadzīgi sarežģītu un / vai pārmērīgi izstrādātu sistēmu. Pamata izpratne par JMS un tai piemītošajām īpašībām (no sistēmas neatkarīgām īpašībām), kam seko rūpīga analīze saistībā ar konkrētiem sadalītās sistēmas scenārijiem, var norādīt, cik labi JMS varētu atrisināt sistēmas prasības, vai nu mainot esošās problēmas, vai pat ieviešot jaunas.

JMS pārskats

JMS, ko Sun Microsystems ieviesa 1999. gadā kā daļu no Java 2 Platform, Enterprise Edition (J2EE) specifikācijas, ir standartu kopums, kas apraksta ziņojumu apstrādes starpprogrammatūras slāņa pamatus. JMS ļauj sistēmām sinhroni vai asinhroni sazināties, izmantojot gan modeļus no punkta uz punktu, gan publicēt-abonēt. Mūsdienās vairāki pārdevēji nodrošina JMS ieviešanu, piemēram, BEA Systems, Hewlett-Packard, IBM, Macromedia un Oracle, tādējādi ļaujot JMS mijiedarboties ar vairākām pārdevēju tehnoloģijām.

1. attēlā parādīta vienkārša uz JMS balstīta sistēma ar izejošo rindu, kas aizpildīta ar klientiem apstrādājamiem ziņojumiem, un ienākošo rindu, kas apkopo klienta apstrādes rezultātus ievietošanai datu bāzē.

Kā minēts iepriekš, MOM (tāpat kā JMS) ļauj brīvāk sasaistīt sadalītās sistēmās, abstrahējot tulkošanu, drošību un pamatā esošos sakaru protokolus no klientiem un serveriem. Viens no ziņojumu apstrādes slāņa galvenajiem aktīviem ir tas, ka, ieviešot šo abstrakcijas slāni, klienta vai servera ieviešana var mainīties, dažkārt radikāli, neietekmējot citas sistēmas sastāvdaļas.

Divi specifiski scenāriji

Šajā sadaļā es iepazīstinu ar divām izplatītām sistēmām, kas ir potenciālie KMS kandidāti, un izskaidroju katras sistēmas mērķus un to, kāpēc sistēmas ir JMS kandidāti.

1. scenārijs

Pirmais kandidāts ir izplatīta kodēšanas sistēma (parādīta 2. attēlā). Šai sistēmai ir N klienti, kas iegūst kodēšanas darbus no centrālā datu bāzes servera. Pēc tam klienti veic faktisko pārveidošanu (kodēšanu) no digitālā maģistra uz kodētiem failiem un pabeidz, ziņojot par savu pēcapstrādes statusu (piemēram, veiksme / neveiksme) atpakaļ centrālajai datu bāzes serverim.

Kodēšanas veidi (piem., Teksts, audio vai video) vai pārveidojumi (piem., .pdf uz .xml, .wav uz .mp3, .avi uz .qt) nav svarīgi. Ir svarīgi saprast, ka kodēšana ir intensīva procesoriem, un tās mērogošanai ir nepieciešama sadalīta apstrāde vairākiem klientiem.

Īsumā šī sistēma ir potenciāls JMS kandidāts, jo:

  • Apstrāde ir jāsadala, jo tā ir ļoti intensīva procesoram (CPU)
  • No sistēmas veiktspējas viedokļa var būt problemātiski vairākus klientus savienot tieši ar vienu datu bāzes serveri

2. scenārijs

Otrā JMS kandidātu sistēma ir globāla interneta portāla reģistrācijas sistēma. Globālā reģistrācija apstrādā pieprasījumus par jaunu lietotāju izveidošanu (reģistrāciju), pieteikšanos un autentifikāciju.

Konkrēta reģistrācijas informācija (piem., Vārds, adrese, iecienītākā krāsa) un lietotāja autentifikācijas metodes (piemēram, servera puses lietotāja objekti, HTTP sīkfaili) nav svarīgas. Tomēr ir svarīgi, lai šī sistēmas skala darbotos ar miljoniem lietotāju, un lietošanas paradumus ir grūti, ja ne neiespējami, paredzēt. (Televīzijas ESPN pasaules kausa spēles laikā diktors saka: "Piesakieties un balsojiet mūsu tiešsaistes aptaujā. Mēs parādīsim rezultātus šova beigās." Pēkšņi 500 000 lietotāju piesakās trīs minūšu laikā. intervāls. 3 minūtes = 180 sekundes; 500 000 lietotāju pieteikšanās / 180 sekundes = 2778 lietotāju pieteikšanās sekundē.)

Šī sistēma ir potenciāls KMS kandidāts šādu iemeslu dēļ:

  • Sistēma jāizplata, lai mērogotu darījuma apjomu
  • Darījumi ir atomi (piemēram, pieteikšanās), tāpēc tie ir bezvalstnieki un tāpēc ir izplatīšanas kandidāti

Abas sistēmas ir arhitektoniski līdzīgas. Vairākas klientu mašīnas iegūst datus no centrālās datu bāzes servera (iespējams, atkārtotas uz M tikai lasāmi datu bāzes serveri), izpildiet kādu loģiku klientā un pēc tam ziņojiet par statusu centrālajam datu bāzes serverim. Viena sistēma piegādā kodētus failus failu sistēmai, izmantojot UNC / FTP; otra piegādā HTML saturu tīmekļa pārlūkprogrammām, izmantojot HTTP. Abas sistēmas ir izplatītas.

Tas ir tik daudz, cik daudzi inženieri veic analīzi pirms JMS izmantošanas. Pārējā šī raksta daļā es paskaidroju, ka, lai arī šīm sistēmām ir daudz īpašību, JMS piemērotība kļūst skaidrāka un atšķirīgāka, kad mēs pārbaudām katras sistēmas prasības, tostarp sistēmas veiktspēju, datu izplatīšanu un mērogojamību.

Sistēmas analīze: integrēt vai neintegrēt

JMS ir raksturīgas, no sistēmas neatkarīgas īpašības. Dažas no šīm īpašībām (plusi, kas apzīmēti ar +, mīnusi, kas apzīmēti ar -), kas attiecas uz abām sistēmām, ietver:

  • (+) JMS ir standartu kopums, ko izveidojuši vairāki pārdevēju ieviešanas gadījumi; tāpēc jūs izvairāties no bailes pārdevēja bloķēšana problēmu.
  • (+) JMS ļauj abstrakciju (izmantojot vispārēju API) starp klientu un serveri; jūs varat mainīt datu bāzes shēmu vai platformu, nemainot lietojumprogrammas slāni (šeit netieši ir citas iespējamās sistēmas izmaiņas, kuras viena no otras izolē ziņojumapmaiņas slānis).
  • (+)/(-) JMS var palīdzēt sistēmas mērogam (pro). Nepilnības ir tādas, ka jebkura sistēma, kas mērogojas ar JMS, var mērogot bez tā.
  • (-) JMS ir sarežģīta. Tas ir pilnīgi jauns slānis ar jaunu serveru komplektu. Programmatūras izlaišanas pārvaldība, servera uzraudzība un drošība ir tikai dažas no nebūtiskām problēmām, kas saistītas ar JMS ieviešanu. Jāņem vērā arī izmaksas.
  • (-) Pārdevēji ne vienmēr interpretē un tāpēc ievieš standartus precīzi tāpat, līdz ar to pastāv atšķirības starp dažādām realizācijām.
  • (-) Izmantojot JMS, jums ir nepieciešams vairāk sistēmas pārbaužu un līdzsvara. Jūs ne tikai ieviešat jaunu slāni, bet arī asinhrono datu izplatīšanu un apstiprināšanu, kam ir papildu asinhronā paziņojuma sarežģītība.
  • (-) Bez ziņojumapmaiņas / atjaunināšanas / uzraudzības rindu bez pielāgotas programmatūras.

JMS ir arī no sistēmas atkarīgas īpašības. JMS piemērotība ir atkarīga no tā, cik labi šīs īpašības atbilst problēmu kopai, kuru mēģināt atrisināt. Dažas no šīm īpašībām un to saistība ar abām interesējošajām sistēmām seko:

Kešatmiņa

Kešatmiņa ir galvenais apsvērums jaudas plānošanā jebkurā izplatītajā sistēmā. JMS ir daudzas funkcijas, kas ļauj to izmantot kā kešatmiņas tehnoloģiju (galvenokārt, ka tā ir izplatīta, sinhrona vai asinhrona un datu apmaiņa kā objekts ziņojumos). Tāpēc, ja nepieciešams, esošo JMS instalāciju var izmantot kā kešatmiņas infrastruktūru.

Apsverot kodēšanas sistēmu, kešatmiņa parasti nav noderīga, lai palielinātu sistēmas kopējo veiktspēju, jo lielākā daļa failu pārveidojumu tiek izpildīti vienu reizi un pāriet uz mitināšanas iekārtu vai SAN (krātuves tīkls), un ir maz satura pārklāšanās starp klientiem. Globālā reģistrācija ir galvenā lietotāja informācijas kešatmiņas kandidāte, jo lietotāji parasti piesakās, pārlūko un pēc tam atsakās. Pieteikšanās izveido lietotāja kešatmiņas ierakstu, un šis objekts nodrošina turpmāku lietotāja autentifikāciju, kamēr lietotājs atrodas vietnē.

Notiek pasūtījuma apstrāde

Globālajā reģistrācijas sistēmā nav plānota un / vai pasūtīta darījumu apstrāde. Pseido-nejauši lietotāji, piesakoties, sistēmā ienāk pseido-nejaušos intervālos, pārlūko saturu (un tāpēc tiek autentificēti, piekļūstot ierobežotam saturam un / vai lietojumprogrammām) un pēc tam atsakās.

Kodēšanas sistēmā apstrāde tiek pasūtīta. Saturs tiek piegādāts grupās atkarībā no noņemamās krātuves pieejamības (piem., DLT Solutions vai Network Appliance krātuve). Saturs netiek piegādāts, kamēr partija nav pabeigta, tāpēc paketes ir jāpilda secībā (lai gan transformācijas partijas ietvaros var nebūt pasūtītas). Prioritāro rindu ieviešana JMS sistēmā, lai saglabātu apstrādes kārtību, ir iespējama, taču saglabāt šo ziņojumu partiju secību starp vairākiem JMS serveriem un vairākām rindām kļūst diezgan sarežģīti. Relāciju datu bāzes serveris ar atbalstu darījumiem ir piemērotāka tehnoloģija šīs darbplūsmas pārvaldīšanai.

Drošība

Drošība nav daļa no JMS specifikācijas. Drošības problēma ne vienmēr tiek mainīta, izmantojot JMS balstītu ieviešanu (ja jums ir drošības prasības pirms JMS, jums būs līdzīgas drošības prasības pēc JMS). Zinot to, ir svarīgi saprast, kā JMS varētu būt saistīts ar esošo infrastruktūras drošību.

Kopumā, jo vairāk tehnoloģiju izmantojat, jo jūsu sistēma kļūst neaizsargātāka pret hakeriem un drošības pārkāpumiem. Tā kā globālais reģistrācijas lietojumprogrammu serveris ir vērsts uz tīmekli, drošības trūkumi, kas atklāti jūsu piegādātāju JMS ieviešanā un publicēti interneta ziņu grupās, ātri kļūst par jūsu vietnes drošības saistībām. Tā kā JMS ir vispārīgs API, tas ir vairāk pakļauts drošības pārkāpumiem nekā patentēta sistēma, kas izmanto nepublicētu API.

Lai gan jūs varat izmantot esošo ugunsmūri un uz IP balstītu tīkla drošību, lai aizsargātu savas aizmugures (lasīt: nevis ar tīmekli vērstu - paredzēts punam) lietojumprogrammas un datu bāzes serverus no drošības pārkāpumiem, JMS lietojumprogrammu serveru pakļaušana rada ievērojamu drošības risku. tieši internetā.

Kodēšanas sistēma parasti pastāv tajā pašā tīklā (arī tīklā, kas izolēts no interneta). Tātad šīs sistēmas tīkla topogrāfijai nekas nav raksturīgs, kas attiecas uz JMS un šīs topogrāfijas izmantošanu drošības nodrošināšanai (kodēšanas sistēmai ir daudz mazāk drošības prasību, jo tā nav vērsta uz tīmekli).

Mērogojamība

Tā kā globālā reģistrācijas sistēma ir pakļauta lielas un kaprīzi noklikšķinošas lietotāju bāzes iegribām, sistēmas mērogojamības prasības garantē JMS. JMS ne tikai palīdzēs mērogot sistēmu, bet arī rindos uz darījumiem, lai gan tas nebūs daudz noderīgs, ja lietotāju pieprasījumi pārpludinās sistēmu.

Tā kā izplatītā kodēšanas sistēma ir rūpīgi regulējusi datu plūsmu (jo tā, iespējams, ir atsevišķa sistēma), sistēmas mērogojamības prasības nav tik briesmīgas. Lai izplatītu kodējumu, varat savienot savu O [100] klientus tieši uz jūsu datu bāzi un ierobežo to trafiku, lai līdzsvarotu kodēšanas caurlaidi ar datu bāzes servera veiktspēju.

Izrāde

Viena JMS servera ieviešana drīzāk var mainīt veiktspējas problēmas, nevis tās atrisināt. Šī iemesla dēļ JMS sistēma ir jāveido ar vairākiem JMS serveriem (un līdz ar to ar vairākām rindām). 4. attēlā parādīts, kāpēc veiktspējas problēmas tiek mainītas, nevis atrisinātas. Tas parāda apstrādes slāņus, kas nepieciešami vispārējam datu serverim, lai atbildētu uz klienta savienojuma pieprasījumiem:

Datu apmaiņa starp klientu un serveri ir divdaļīgs process neatkarīgi no tā, vai tas ir klients-datu bāze vai klients-JMS serveris:

  1. Piekļuve datiem
  2. Vītņu un kontaktligzdu pārvaldība, apvienošana un kešatmiņa

JMS un datu bāzes serveris izskatās tieši tāpat (4. attēls). Viņi apstrādā kontaktligzdu savienojumus, pavedienu pārvaldību un piekļuvi servera datiem.

Izmantojot tikai vienu JMS serveri, iespējamās veiktspējas problēmas vienkārši pārvietojas no datu bāzes servera uz JMS serveri. Papildus iespējamai veiktspējas pasliktināšanās, kas saistīta ar konteksta maiņu jūsu datu bāzes serverī, veiktspējas problēmas tagad ir potenciāli lielākas JVM veiktspējas problēmu dēļ jūsu JMS serverī.

Viens JMS serveris jūsu sistēmai piešķir ievērojamu sarežģītību un var radīt arī veiktspējas problēmas, kas saistītas ar vairāku klientu savienojumu ar vienu serveri. Vairāku JMS serveru ietekme uz jūsu sistēmas dizainu un datu plūsmu var nozīmēt atšķirību starp veiksmīgu vai neveiksmīgu sistēmas izlaišanu.

Kopumā funkcijas salīdzinājumā ar iespējamo JMS ietekmi izskatās šādi:

Funkcijas pret JMS ietekmi

$config[zx-auto] not found$config[zx-overlay] not found