Stanje međuopreme Java aplikacije, 1. dio

Klijent / poslužitelj je mrtav. U tome se bruji sada kad novije tehnologije temeljene na Internetu cvjetaju. Ali te su nove tehnologije tek prirodna evolucija ranijih pristupa, implementirane s novijim, otvorenijim protokolima i dizajnirane da pruže veću skalabilnost, upravljivost i raznolikost.

Veličina ove evolucije je zapanjujuća. Većina glavnih dobavljača klijenata / poslužitelja modernizirali su svoje proizvode i sada svoje marketinške dolare usmjeravaju u troslojne tehnologije. U većini slučajeva noviji su proizvodi usmjereni na Javu i usmjereni na internetski protokol. Na primjer, identificirao sam najmanje 46 Java međuproizvoda tijekom posljednjeg brojanja. Prije dvije godine bilo bi teško doći do pola tog broja.

Ovo je prvi iz dvodijelnog niza članaka posvećenih objašnjenju općeg softvera Java middleware u njegovim trenutnim oblicima. U ovom prvom članku proučit ću značajke trenutnih proizvoda i objasniti zašto su te značajke važne. U drugom dijelu, Anil Hemrajani proučit će Enterprise JavaBeans (EJB) i pokazati kako se trenutna generacija Java posredničkih proizvoda odnosi i podržava ovaj važan standard komponenata.

Pozadina

Prije svega, definirajmo Java međuprograme.Pojam obuhvaća aplikacijske poslužitelje kao što je BEA WebLogic, proizvode za razmjenu poruka poput ActiveWorks Active Software-a i SpiritWAVE Push Technologies-a te hibridne proizvode koji se nadovezuju na naslijeđe DBMS-a i dodaju značajke izvršavanja Java objekata zasnovanih na poslužitelju. Mogao sam se usredotočiti na uski segment, poput poslužitelja aplikacija, ali to bi bilo nepravedno prema mnogim proizvodima koji se ne uklapaju točno u ovu kategoriju, ali unatoč tome treba razmotriti za višerazinske aplikacije. Nadalje, čak i među aplikacijskim poslužiteljima postoji popriličan spektar, uključujući one koji su prvenstveno servlet poslužitelji, kao i one koji se temelje na ORB-u ili OODB-u. Povlačenje linije između svih ovih proizvoda postaje sve teže. Međutim, objedinjujuća značajkajest da svi oni pokušavaju riješiti problem primjene multitier aplikacija pomoću Java i Internet tehnologija.

Poslovni slučaj korištenja Jave u međuprogramskom softveru je uvjerljiv; među prednostima koje nudi Java middleware su sljedeće:

  • Sposobnost Interneta da ekonomski poveže urede i organizacije

  • Potreba organizacija za suradnjom dijeljenjem podataka i poslovnih procesa

  • Želja za konsolidacijom generičkih usluga i upravljanje tim uslugama

  • Želja za centraliziranim upravljanjem aplikacijama, uključujući pokretanje, isključivanje, održavanje, oporavak, uravnoteženje opterećenja i nadzor

  • Želja za korištenjem otvorenih usluga i protokola

  • Želja za preusmjeravanjem poslovne logike po volji i neograničena infrastrukturom; to zahtijeva upotrebu otvorenih API-ja i protokola, koji su široko podržani u većini infrastrukturnih proizvoda

  • Potreba za podrškom suradnji s mješovitom arhitekturom

  • Želja za premještanjem odluka o mrežnoj i uslužnoj infrastrukturi iz prostora aplikacija, tako da upravitelji sustava mogu donositi odluke o infrastrukturi, a da ih aplikacije ne ometaju ovisno o zaštićenim protokolima ili značajkama

  • Želja da se smanji raznolikost i razina potrebnih vještina osoblja programera i umanji potreba za naprednom stručnošću u izradi alata unutar projekata

  • Želja za iskorištavanjem objektno orijentirane stručnosti proširujući je na područje poslužitelja - stoga noviji objektno orijentirani poslužiteljski proizvodi i mostovi objekt-na-relacija

Cilj međuopreme je centralizirati softversku infrastrukturu i njezinu primjenu. Klijent / poslužitelj potječe iz razdoblja integracije unutar jednog odjela. Organizacije sada obično pokušavaju integraciju preko granica odjela - čak i od jedne organizacije do druge. Internet - koji mami tvrtke svojom sposobnošću da posluže kao globalna mreža koja omogućuje odjelima i partnerima da se međusobno učinkovito i brzo povezuju - generirao je potražnju za ovom integracijom.

Java nudi lingua francu za jednostavno povezivanje podataka i aplikacija preko organizacijskih granica: U distribuiranom globalnom okruženju, u kojem nemate kontrolu nad tehnološkim izborima koje vaši partneri mogu donijeti, pametne tvrtke odabiru otvorene i platformi neutralne standarde. Tvrtke ne mogu predvidjeti tko će postati njihovi kupci, partneri ili podružnice dvije godine nakon toga, pa nije uvijek moguće planirati zajedničku infrastrukturu s nečijim partnerima. U ovoj neizvjesnoj situaciji najbolja bi odluka mogla biti uporaba što je moguće više univerzalnih i prilagodljivih tehnologija.

Java vam omogućuje smanjenje broja programskih jezika i platformi koje vaše osoblje mora razumjeti. Zašto? Budući da je Java sada raspoređena u raznolikim kontekstima poput internetskih preglednika, pohranjenih procedura u bazama podataka, poslovnih objekata u međuproduktima i klijentskih aplikacija.

Međutim, u dobi od tri godine Java tehnologija je još uvijek pomalo nezrela, a to vrijedi za proizvode o kojima se govori u ovom članku. S druge strane, možda smo sada u eri kada proizvodi nikad uistinu ne dostižu zrelost, jer se temeljne tehnologije na kojima se temelje mijenjaju tako brzo. U stvari, otkrio sam značajne probleme s gotovo svim Middleware proizvodima koje sam koristio, uključujući navodno zrele proizvode koji su na tržištu već nekoliko godina, a nedavno su izašli sa značajnim novim značajkama. Poanta je u tome što su dobavljači, dok uspije riješiti probleme, dodane nove značajke. Ciklus dodavanja novih značajki sada je puno kraći nego što je ikad bio, pa tako proizvodi nemaju dovoljno vremena da postanu stabilni prije nego što uključe sljedeći glavni skup značajki.To je možda nešto na što se moramo naviknuti, a učenje snaga i slabosti proizvoda koje odaberemo važan je dio bilo kojeg ciklusa dizajna aplikacije i prototipa.

Ciljevi za međuopreme

Standard komponente EJB middleware razvijen je sa sljedećim ciljevima:

  • Osigurati interoperabilnost komponenata. Poduzeće grah razvijeno s različitim alatima će raditi zajedno. Također, grah razvijen različitim alatima prikazivat će se u bilo kojem EJB okruženju.

  • Pružiti jednostavan model programiranja uz zadržavanje pristupa API-ima na niskoj razini.

  • Za rješavanje problema životnog ciklusa, uključujući razvoj, implementaciju i vrijeme izvođenja.

  • Da bi se osigurala kompatibilnost s postojećim platformama, što omogućuje proširenje postojećih proizvoda kako bi se pružila podrška za EJB.

  • Da bi se održala kompatibilnost s drugim Java API-ima.

  • Omogućiti interoperabilnost između EJB i ne-Java aplikacija.

  • Da bi bio kompatibilan s CORBA-om.

Stoga je fokus EJB standarda na stvaranju standarda interoperabilnosti za Java middleware, štiteći programera da se moraju nositi s mnogim teškim problemima koji nastaju pri razvoju distribuiranih aplikacija. To omogućuje programerima da se koncentriraju na poslovnu logiku, umjesto da pišu sofisticiranu domaću infrastrukturu i alate. Kao rezultat toga, poduzeća mogu većinu svojih obrazovnih resursa uložiti u osposobljavanje osoblja u poslovnim procesima, što je obično ono što donosi najveću isplatu.

Na gornji popis dodajem sljedeće dodatne ciljeve za Java-međuprograme poslovne klase. Ove su značajke proizvoda potrebne dugoročno kako bi se uspješno pokrenulo i održavalo okruženje temeljeno na međuproduktu:

  • Trebao bi prilagoditi međusobnu povezanost više poslovnih jedinica, tvrtki i kupaca u distribuiranoj infrastrukturi, bez ugrožavanja sigurnosti ili uvođenja kaosa

  • Trebao bi omogućiti fleksibilne, ali pouzdane mehanizme kontrole pristupa kako bi se osiguralo da se podacima poslovnih partnera pristupa samo na predviđeni način i samo od strane onih kojima su namijenjene.

  • Trebao bi omogućiti administratorima sustava da upravljaju distribuiranim računalnim okruženjem koje sadrži velik broj komponenata poslovne logike na jedinstven način, bez potrebe za razumijevanjem ili primjenom jedinstvenih postupaka na određene komponente

  • trebao bi omogućiti administratorima sustava da vrše odabir komponenata infrastrukture bez utjecaja na aplikacije, te da podešavaju i skaliraju te komponente te da imaju jedinstvena i generička sredstva za mjerenje performansi i potreba za resursima svih aplikacija

  • Trebao bi omogućiti premještanje poslovnih komponenata između klijenata i poslužitelja bez utjecaja na arhitekturu bilo kojeg od njih

  • Trebao bi osigurati sigurnosni mehanizam koji određenim korisnicima omogućuje dodavanje novih komponenti, bez potrebe da administratoru poslužitelja omogući pristup svim komponentama i izvorima podataka (ovo je izvrsna prilika za sposobnost dodane vrijednosti, jer je to presudno za ekstranet i partnerske programe )

Komponente i značajke Java softverskih platformi

Kategorija najbrže rastućeg Java Java middlewarea danas su vjerojatno poslužitelji aplikacija. Međutim, bitno je shvatiti široku paletu aplikacijskih poslužitelja (i drugih vrsta međuprodukata) koji postoje. Razlike među kategorijama Java posredničkog softvera danas nisu predstavljene linijom već velikim kontinuumom međuopreme. Sada ću raspravljati o značajkama Java posredničkog softvera, na temelju vlastitih usporedbi rada, koje obuhvaćaju svaku klasu Java međuprogramskog proizvoda za koje znam.

Modeli objekata, komponenata i spremnika

Komponente aplikacije moraju se pridržavati nekog runtime modela uvođenja, koji određuje kako komponenta komunicira sa svojim okruženjem; (moguće) kako se instalira, pokreće, zaustavlja i poziva; i kako pristupa uslugama važnim za svoje okruženje. Popularni modeli izvođenja i spremnika s komponentama poslužitelja usmjereni na Javu uključuju RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages) i Java pohranjene procedure. Uz to, komponentni modeli mogu se izraziti na raznim osnovnim jezicima, uključujući Java, IDL, C ++ i mnoge druge.

Postoji preklapanje s različitim modelima komponenata. Na primjer, RMI je trivijalni komponentni model s vrlo osnovnim mogućnostima za aktiviranje i lociranje objekata i prvenstveno je standard udaljenog poziva, dok EJB koristi RMI i određuje RMI kao svoj primarni model pozivanja objekta. EJB također podržava CORBA. U stvari, nijedan od ovih modela nije ekskluzivan, a mnogi Java aplikacijski poslužitelji podržavaju većinu ili sve gore navedene modele.

Mnogi Java posrednički poslužitelji izvode više instanci poslovnih objekata (koje svijet CORBA sada naziva slugama) unutar jednog Java virtualnog stroja (JVM). Sigurnost tipa Java jezika omogućuje da jedan JVM postupak servisira zahtjeve više klijenata i koristi programske strukture podataka i učitavače klasa kako bi klijentske podatke držao odvojeno. Sve dok sluge ne koriste vlastite izvorne metode, nije moguće da jedan sluga sruši druge sluge ako se sruši (osim ako ne naiđe na grešku u samom JVM-u) ili pristupi podacima koji su privatni za druge klase . Ispravno dizajnirani objektni poslužitelj zaštitit će svoje privatne objekte i spriječiti pogrešne objekte da pristupe onome što pripada drugim objektima.

Međutim, podaci deklarirani kao statični u Java klasi mogu se dijeliti između klijenata unutar istog JVM-a ako klijenti koriste isti učitavač klase, pa pravila moraju biti definirana da diktiraju kada zasebni JVM (ili ekvivalent zasebnog JVM-a koji koristi memoriju- tehnike particioniranja) ili je potreban zaseban učitavač klase kako bi klijent dobio vlastiti statički prostor podataka. Takva su pravila navedena za aplete, ali ne i za druga okruženja izvršavanja. Sunov Java Web poslužitelj koristi jedan JVM za sve servlete i zasebni prostor imena klase za servlete s drugačijom bazom koda. EJB zaobilazi problem zabranom nedovršenih statičkih podataka.

Izvedba se može povećati ako su objekti inaktivirani ili pasivizirani kada se ne koriste, oslobađajući resurse kao što su veze s bazom podataka. Iz tog razloga mnogi poslužitelji pasiviziraju i reaktiviraju objekte prema potrebi. Slično tome, neki proizvodi održavaju često kreirane objekte u spremištu ili predmemoriji u inicijaliziranom stanju i spremne za neposrednu upotrebu. Spremnik predmeta mora upravljati pasivizacijom i reaktivacijom, kao i skupnim resursima na koje pasivizacija utječe.

EJB kompatibilnost (verzija)

Model EJB već postaje univerzalno podržan. Gotovo svaki dobavljač srednjeg softvera obećao je da će ga podržati, a mnogi to već i čine. Štoviše, Grupa za upravljanje objektima (OMG) ugradila je mapiranje u EJB kao dio predložene Specifikacije komponente CORBA. Teško je zamisliti da čak ni Microsoft, usamljeni i nepokolebljivi zadržavač, na kraju neće ustupiti i pružiti EJB spremnike za DCOM.

Iako različiti međuprogrami kompatibilni s EJB mogu implementirati i upravljati istim komponentama aplikacije (sve dok te komponente koriste samo standardno potrebne EJB značajke), među poslužiteljima kompatibilnim s EJB-om još uvijek postoji velika razlika. Kao prvo, razvija se sama EJB specifikacija. Stoga je važno pitanje pri ocjenjivanju Javinih međuprogramskih proizvoda: Podržava li poslužitelj najnoviju verziju EJB-a ili podržava samo raniju verziju? Sljedeće je ključno pitanje: Je li proizvod usmjeren na EJB ili je podrška za EJB uključena samo u značajke dodane vrijednosti proizvoda (i stoga nije dostupna kada se koriste EJB usluge ili API)? I na kraju: Koje su opcionalne EJB značajke (na primjer, grah entiteta i postojanost kojom upravlja kontejner)?