Klientas / serveris mirė. Tai šurmulys dabar, kai klesti naujesnės interneto technologijos. Tačiau šios naujos technologijos yra tik natūrali ankstesnių metodų raida, įgyvendinta naudojant naujesnius, atviresnius protokolus ir sukurta siekiant suteikti didesnį mastelį, valdomumą ir įvairovę.
Šios evoliucijos dydis yra stulbinantis. Dauguma pagrindinių klientų / serverių pardavėjų modernizavo savo produktus ir dabar nukreipia savo rinkodaros dolerius į trijų pakopų technologijas. Daugeliu atvejų naujesni produktai yra orientuoti į „Java“ ir į interneto protokolą. Pavyzdžiui, paskutinį kartą suskaičiavau bent 46 „Java“ tarpinės programinės įrangos produktus. Prieš dvejus metus būtų buvę sunku sugalvoti pusę šio skaičiaus.
Tai pirmasis iš dviejų dalių straipsnių ciklo, skirtas paaiškinti bendrosios paskirties „Java“ tarpinę programinę įrangą dabartinėmis formomis. Šiame pirmame straipsnyje panagrinėsiu dabartinių produktų savybes ir paaiškinsiu, kodėl šios funkcijos yra svarbios. Antroje dalyje Anil Hemrajani išnagrinės „Enterprise JavaBeans“ (EJB) ir parodys, kaip dabartinės „Java“ tarpinės programinės įrangos kartos yra susijusios ir palaiko šį svarbų komponentų standartą.
Fonas
Pirmiausia apibrėžkime „Java“ tarpinė programinė įranga. Šis terminas apima tokių programų serverius kaip „BEA WebLogic“, pranešimų siuntimo produktus, tokius kaip „Active Software“ „ActiveWorks“ ir „Push Technologies“, „SpiritWAVE“, ir hibridinius produktus, kurie remiasi DBVS palikimu ir prideda serveryje esančias „Java“ objektų vykdymo funkcijas. Aš galėjau sutelkti dėmesį į siauresnį segmentą, pvz., Programų serverius, tačiau tai būtų buvę nesąžininga daugelio produktų atžvilgiu, kurie tiksliai neatitinka šios kategorijos, tačiau vis dėlto reikėtų atsižvelgti į daugiapakopes programas. Be to, net tarp programų serverių yra gana didelis spektras, įskaitant tuos, kurie pirmiausia yra servletų serveriai, taip pat tuos, kurie yra ORB arba OODB pagrindu. Nubrėžti liniją tarp visų šių produktų tampa vis sunkiau. Vis dėlto vienijantis bruožas yra tas, kad jie visi bando išspręsti daugiapakopės programos diegimo problemą naudodami „Java“ ir interneto technologijas.
Verslo atvejis naudoti „Java“ tarpinėje programoje yra patrauklus; Tarp „Java“ tarpinės programinės įrangos privalumų yra šie:
Interneto galimybė ekonomiškai susieti biurus ir organizacijas
Organizacijų poreikis bendradarbiauti dalijantis duomenimis ir verslo procesais
Noras konsoliduoti bendrąsias paslaugas ir šių paslaugų valdymą
Noras teikti centralizuotą programų valdymą, įskaitant paleidimą, išjungimą, priežiūrą, atkūrimą, apkrovos balansavimą ir stebėjimą
Noras naudotis atvirosiomis paslaugomis ir protokolais
Noras perskirstyti verslo logiką savo nuožiūra ir nevaržomas infrastruktūros; tam reikia naudoti atviras API ir protokolus, kurie yra plačiai palaikomi daugelyje infrastruktūros produktų
Poreikis palaikyti bendradarbiaujančias mišrios architektūros programas
Noras perkelti tinklo ir paslaugų infrastruktūros sprendimus iš programų erdvės, kad sistemos valdytojai galėtų priimti sprendimus dėl infrastruktūros netrukdydami programoms, kurios priklauso nuo patentuotų protokolų ar funkcijų
Noras sumažinti reikalingų programuotojų personalo įgūdžių įvairovę ir lygį bei iki minimumo sumažinti pažangių įrankių kūrimo žinių poreikį projektuose
- Noras pasitelkti į objektą orientuotas žinias išplėsti ją į serverio sritį - taigi naujesni objektinių serverių produktai ir objektų tarpusavio tiltai
Tarpinės programinės įrangos tikslas yra centralizuoti programinės įrangos infrastruktūrą ir jos diegimą. Klientas / serveris yra kilęs iš integracijos viename skyriuje eros. Dabar organizacijos dažnai bando integruotis per žinybų ribas - net iš vienos organizacijos į kitą. Internetas, kuris vilioja verslą, kad jis galėtų veikti kaip pasaulinis tinklas, leidžiantis departamentams ir partneriams efektyviai ir greitai sujungti, sukėlė šios integracijos poreikį.
„Java“ suteikia a Prancūzų kalba lengvai susieti duomenis ir taikymą per organizacijos ribas: Išskirstytoje pasaulinėje aplinkoje, kurioje jūs negalite kontroliuoti, kokius technologinius sprendimus gali pasirinkti jūsų partneriai, išmaniosios įmonės renkasi atvirus ir neutralius platformai standartus. Įmonės negali numatyti, kas dvejus metus taps jų klientais, partneriais ar dukterinėmis įmonėmis, todėl ne visada įmanoma suplanuoti bendrą infrastruktūrą su savo partneriais. Esant tokiai neapibrėžtai situacijai, geriausias sprendimas gali būti universaliausių ir pritaikomų technologijų naudojimas.
„Java“ leidžia sumažinti programavimo kalbų ir platformų, kurias turi suprasti jūsų darbuotojai, skaičių. Kodėl? Kadangi „Java“ dabar diegiama įvairiuose kontekstuose kaip interneto naršyklės, saugomos procedūros duomenų bazėse, verslo objektai tarpinės programinės įrangos produktuose ir kliento programos.
Tačiau būdama trejų metų „Java“ technologija vis dar yra šiek tiek nesubrendusi, ir tai pasakytina apie šiame straipsnyje aptartus produktus. Kita vertus, dabar galime būti laikmetyje, kai produktai niekada nesulaukia brandos, nes pagrindinės technologijos, kuriomis jie yra paremtos, keičiasi taip greitai. Tiesą sakant, radau reikšmingų problemų praktiškai su kiekvienu naudojamu tarpinės programinės įrangos produktu, įskaitant tariamai subrendusius gaminius, kurie buvo rinkoje keletą metų ir neseniai pasirodė su naujomis reikšmingomis funkcijomis. Esmė ta, kad kol pardavėjui pavyks išspręsti problemas, buvo pridėta naujų funkcijų. Naujų funkcijų pridėjimo ciklas dabar yra daug trumpesnis nei kada nors anksčiau, todėl produktai neturi pakankamai laiko tapti stabilūs, kol neįtraukia kito pagrindinio funkcijų rinkinio. Tai gali būti dalykas, prie kurio turime priprasti, ir išmokti pasirinktų produktų stipriąsias ir silpnąsias puses yra svarbi bet kurio programos kūrimo ir prototipų ciklo dalis.
Tarpinės programos tikslai
EJB tarpinės programinės įrangos komponentų standartas buvo sukurtas siekiant šių tikslų:
Užtikrinti komponentų sąveiką. Verslinės pupelės, sukurtos naudojant įvairius įrankius, veiks kartu. Be to, pupelės, sukurtos naudojant įvairius įrankius, bus naudojamos bet kurioje EJB aplinkoje.
Pateikti lengvai naudojamą programavimo modelį išlaikant prieigą prie žemo lygio API.
Spręsti gyvenimo ciklo problemas, įskaitant kūrimą, diegimą ir vykdymo laiką.
Užtikrinti suderinamumą su esamomis platformomis, o tai leidžia išplėsti esamus produktus ir teikti paramą EJB.
Norėdami palaikyti suderinamumą su kitomis „Java“ API.
Užtikrinti EJB ir ne „Java“ programų sąveikumą.
- Kad būtų suderinama su CORBA.
Todėl EJB standartas yra skirtas kurti „Java“ tarpinės programinės įrangos suderinamumo standartą, apsaugantį programuotojus nuo to, kad jiems teks spręsti daugelį sudėtingų problemų, kylančių kuriant paskirstytas programas. Tai leidžia programinės įrangos kūrėjams susitelkti ties verslo logika, užuot rašius rafinuotą namų infrastruktūrą ir įrankius. Todėl įmonės gali didžiąją dalį savo švietimo išteklių skirti darbuotojų mokymui verslo procesuose, o tai dažniausiai duoda didžiausią naudą.
Prie aukščiau pateikto sąrašo pridedu šiuos papildomus tikslus, skirtus įmonės klasės „Java“ tarpinei programinei įrangai. Šios produkto savybės reikalingos ilguoju laikotarpiu, norint sėkmingai valdyti ir palaikyti tarpinės programinės įrangos aplinką:
Tai turėtų sutelkti kelių verslo padalinių, įmonių ir klientų sujungimą į paskirstytą infrastruktūrą, nepakenkiant saugumui ir nekeliant chaoso.
Tai turėtų leisti lanksčius, bet patikimus prieigos kontrolės mechanizmus užtikrinti, kad verslo partnerių duomenys būtų prieinami tik numatytais būdais ir tik numatytoms šalims
Tai turėtų leisti sistemos administratoriams vienodai valdyti paskirstytą skaičiavimo aplinką, kurioje yra daug verslo logikos komponentų, neprivalant suprasti ar taikyti tam tikrų komponentų unikalių procedūrų.
tai turėtų leisti sistemos administratoriams pasirinkti infrastruktūros komponentus, nedarant poveikio programoms, suderinti ir keisti tuos komponentus ir turėti vienodas ir bendras priemones visų programų našumui ir išteklių poreikiams matuoti.
Tai turėtų leisti verslo komponentus perkelti tarp klientų ir serverių, nepaveikiant nė vieno iš jų architektūros
Tai turėtų suteikti saugumo mechanizmą, leidžiantį konkretiems vartotojams pridėti naujų komponentų, nesuteikiant serverio administratoriui prieigos prie visų komponentų ir duomenų šaltinių (tai yra puiki galimybė sukurti pridėtinę vertę, nes tai yra labai svarbu ekstraneto ir partnerystės programoms )
„Java“ tarpinės programinės įrangos platformų komponentai ir funkcijos
Greičiausiai šiandien auganti „Java“ tarpinės programinės įrangos kategorija tikriausiai yra programų serveriai. Tačiau būtina suvokti įvairius egzistuojančius programų serverius (ir kitus tarpinės programinės įrangos produktus). „Java“ tarpinės programinės įrangos produktų kategorijas šiandien skiria ne linija, o didžiulis tarpinės programinės įrangos tęstinumas. Dabar aptarsiu „Java“ tarpinės programinės įrangos ypatybes, remdamasis savo darbų palyginimais, apimančiais visas „Java“ tarpinės programinės įrangos klases, apie kurias žinau.
Objektų, komponentų ir konteinerių modeliai
Programos komponentai turi atitikti tam tikrą vykdymo laiko diegimo modelį, kuriame nurodoma, kaip komponentas bendrauja su savo aplinka; (galbūt) kaip jis įdiegiamas, paleidžiamas, sustabdomas ir iškviečiamas; ir kaip ji naudojasi savo aplinkai svarbiomis paslaugomis. Populiarūs „Java“ centriniai serverio komponentų vykdymo ir konteinerių modeliai apima RMI, EJB, CORBA, DCOM, servlet, JSP („Java Server Pages“) ir „Java“ saugomas procedūras. Be to, komponentų modelius galima išreikšti įvairiomis pagrindinėmis kalbomis, įskaitant „Java“, IDL, C ++ ir daugelį kitų.
Yra sutapimas su įvairiais komponentų modeliais. Pvz., RMI yra nereikšmingas komponentų modelis, turintis labai paprastas objekto aktyvavimo ir vietos nustatymo galimybes, ir pirmiausia yra nuotolinio iškvietimo standartas, o EJB naudoja RMI ir nurodo RMI kaip pagrindinį objekto iškvietimo modelį. EJB taip pat palaiko CORBA. Tiesą sakant, nė vienas iš šių modelių nėra išskirtinis, ir daugelis „Java“ programų serverių palaiko daugumą arba visus anksčiau nurodytus modelius.
Daugelis „Java“ tarpinės programinės įrangos serverių paleidžia kelis verslo objektų egzempliorius (kuriuos CORBA pasaulis dabar vadina tarnautojais) vienoje „Java“ virtualioje mašinoje (JVM). „Java“ kalbos tipo saugumas leidžia vienu JVM procesu aptarnauti kelių klientų užklausas ir naudoti programos duomenų struktūras bei klasių krautuvus, kad kliento duomenys būtų atskirti. Tol, kol tarnautojai netaiko savo gimtosios metodikos, vienam tarnautojui neįmanoma nuversti kitų tarnautojų, jei tai užstringa (nebent jis aptinka klaidą pačiame JVM) arba prieigai prie duomenų, kurie yra privatūs kitoms klasėms . Tinkamai suprojektuotas objektų serveris apsaugos savo privačius objektus ir neleis klaidingiems objektams pasiekti to, kas priklauso kitiems objektams.
Tačiau statiniais „Java“ klasėje paskelbtais duomenimis gali būti dalijamasi to paties JVM klientams, jei klientai naudoja tą patį klasės krautuvą, todėl reikia apibrėžti taisykles, nurodančias, kada atskiras JVM (arba lygiavertis atskiram JVM, naudojant atmintį) padalijimo metodai) arba atskiras klasės krautuvas reikalingas tam, kad klientas gautų savo statinių duomenų erdvę. Tokios taisyklės buvo nurodytos programėlėms, bet ne kitoms vykdymo aplinkoms. „Sun“ „Java“ žiniatinklio serveris naudoja vieną JVM visoms servletams ir atskirą klasės pavadinimo vietą servletams su kita kodo baze. EJB apeina šią problemą uždraudusi ne galutinius statinius duomenis.
Našumas gali būti padidintas, jei objektai yra inaktyvuojami arba pasyvinami, kai jie nenaudojami, atlaisvindami išteklius, pvz., Duomenų bazių ryšius. Dėl šios priežasties daugelis serverių pasyvina ir vėl suaktyvina objektus. Panašiai kai kurie produktai dažnai sukurtus objektus telkinyje ar talpykloje laiko inicializuota būsena ir paruošti naudoti nedelsiant. Objekto konteineris turi valdyti pasyvavimą ir pakartotinį suaktyvinimą, taip pat sujungtus išteklius, kuriuos paveikė pasyvinimas.
EJB suderinamumas (versija)
EJB modelis jau tampa visuotinai palaikomas. Beveik kiekvienas tarpinės programinės įrangos pardavėjas pažadėjo tai palaikyti, ir daugelis tai jau daro. Be to, Objektų valdymo grupė (OMG) įtraukė EJB žemėlapį kaip siūlomos dalies dalį CORBA komponentų specifikacija. Sunku įsivaizduoti, kad net „Microsoft“, vienišas ir tvirtas laikiklis, galų gale neduos ir nepateiks EJB talpyklų DCOM.
Nors skirtinga su EJB suderinama tarpinė programinė įranga gali diegti ir valdyti tuos pačius programų komponentus (jei tik tie komponentai naudoja tik standartines reikalaujamas EJB funkcijas), vis tiek yra daug skirtumų tarp EJB suderinamų serverių. Viena vertus, keičiasi pati EJB specifikacija. Todėl vertinant „Java“ tarpinės programinės įrangos produktus yra svarbus klausimas: ar serveris palaiko naujausią EJB versiją, ar palaiko tik ankstesnę versiją? Kitas pagrindinis klausimas yra: ar produktas orientuotas į EJB, ar EJB palaikymas yra įtrauktas tik į produkto pridėtinės vertės funkcijas (ir todėl negalimas, kai naudojamos EJB paslaugos ar API)? Ir galiausiai: kurios neprivalomos EJB funkcijos yra įtrauktos (pavyzdžiui, subjekto pupelės ir konteinerių valdomas patvarumas)?
