Programiranje

Stanje vmesne programske opreme za programe Java, 1. del

Naročnik / strežnik je mrtev. To je zdaj, ko cvetijo nove internetne tehnologije. Toda te nove tehnologije so zgolj naravni razvoj prejšnjih pristopov, ki so bili uvedeni z novejšimi, bolj odprtimi protokoli in zasnovani za zagotavljanje večje razširljivosti, vodljivosti in raznolikosti.

Obseg tega razvoja je osupljiv. Večina največjih prodajalcev odjemalcev / strežnikov je posodobila svoje izdelke in svoje tržne dolarje zdaj usmerja v tristopenjske tehnologije. V večini primerov so novejši izdelki osredotočeni na Javo in internetni protokol. Na primer, pri zadnjem štetju sem ugotovil vsaj 46 vmesnih programov Java. Pred dvema letoma bi težko prišli do polovice te številke.

To je prvi iz dvodelne serije člankov, namenjenih razlagi splošne vmesne programske opreme Java v sedanjih oblikah. V tem prvem članku bom preučil značilnosti trenutnih izdelkov in razložil, zakaj so te funkcije pomembne. V drugem delu bo Anil Hemrajani preučil Enterprise JavaBeans (EJB) in pokazal, kako se sedanja generacija vmesnih programov Java nanaša na ta pomembni standard komponent in ga podpira.

Ozadje

Najprej določimo Java vmesna programska oprema. Izraz zajema aplikacijske strežnike, kot je BEA WebLogic, izdelke za sporočanje, kot sta ActiveWorks Active Software in Push Technologies's SpiritWAVE, ter hibridne izdelke, ki temeljijo na zapuščini DBMS in dodajajo funkcije izvajanja predmetov Java na strežniškem sistemu. Lahko bi se osredotočil na bolj ozek segment, kot so aplikacijski strežniki, vendar bi bilo to nepravično do številnih izdelkov, ki se ne ujemajo natančno s to kategorijo, vendar bi jih bilo treba upoštevati pri večrazrednih aplikacijah. Poleg tega je tudi med aplikacijskimi strežniki precej spektra, vključno s tistimi, ki so predvsem strežniki strežnikov, in tistimi, ki temeljijo na ORB ali OODB. Postavljanje meje med vsemi temi izdelki je vedno težje. Poenotilna značilnost pa je, da vsi poskušajo rešiti problem uvajanja večvrstnih aplikacij z uporabo Java in internetnih tehnologij.

Poslovni primer uporabe Jave v vmesni programski opremi je prepričljiv; med prednostmi, ki jih ponuja vmesna programska oprema Java, so naslednje:

  • Sposobnost interneta za ekonomsko povezovanje pisarn in organizacij

  • Potreba organizacij po sodelovanju z izmenjavo podatkov in poslovnih procesov

  • Želja po konsolidaciji generičnih storitev in upravljanju teh storitev

  • Želja po centraliziranem upravljanju aplikacij, vključno z zagonom, zaustavitvijo, vzdrževanjem, obnovitvijo, uravnoteženjem obremenitve in nadzorom

  • Želja po uporabi odprtih storitev in protokolov

  • Želja po prerazporeditvi poslovne logike po volji in neomejena z infrastrukturo; to zahteva uporabo odprtih API-jev in protokolov, ki so široko podprti v večini infrastrukturnih izdelkov

  • Potreba po podpori sodelujočih aplikacij mešane arhitekture

  • Želja, da se odločitve o omrežni in storitveni infrastrukturi premaknejo iz aplikacijskega prostora, tako da lahko upravitelji sistemov sprejemajo odločitve o infrastrukturi, ne da bi jih ovirale aplikacije, ki so odvisne od lastniških protokolov ali funkcij

  • Želja po zmanjšanju raznolikosti in ravni potrebnih spretnosti programerjev ter zmanjšanje potrebe po naprednem strokovnem znanju za izdelavo orodij znotraj projektov

  • Želja po izkoriščanju objektno usmerjenega strokovnega znanja z razširitvijo na strežniško področje - zato novejši objektno usmerjeni strežniški izdelki in objektno-relacijski mostovi

Cilj vmesne programske opreme je centralizirati programsko infrastrukturo in njeno uvajanje. Odjemalec / strežnik izvira iz obdobja integracije znotraj enega oddelka. Organizacije zdaj pogosto poskušajo vključiti čez meje oddelkov - tudi od ene organizacije do druge. Internet - ki privlači podjetja s svojo sposobnostjo, da služijo kot globalno omrežje, ki oddelkom in partnerjem omogoča učinkovito in hitro medsebojno povezovanje - je povzročil povpraševanje po tej integraciji.

Java ponuja a lingua franca za enostavno medsebojno povezovanje podatkov in aplikacij prek organizacijskih meja: V porazdeljenem globalnem okolju, v katerem nimate nadzora nad izbiro tehnologije, ki jo lahko sprejmejo vaši partnerji, pametna podjetja izberejo odprte in za platformo nevtralne standarde. Podjetja ne morejo predvideti, kdo bodo postali njihovi kupci, partnerji ali hčerinske družbe dve leti po poti, zato ni vedno mogoče načrtovati skupne infrastrukture s partnerji. V tej negotovi situaciji je morda najboljša odločitev za uporabo najbolj univerzalnih in prilagodljivih tehnologij.

Java vam omogoča, da zmanjšate število programskih jezikov in platform, ki jih mora razumeti vaše osebje. Zakaj? Ker je Java zdaj uvedena v tako raznolike kontekste, kot so internetni brskalniki, shranjeni postopki v zbirkah podatkov, poslovni predmeti znotraj vmesnih izdelkov in odjemalske aplikacije.

Vendar pa je pri treh letih tehnologija Java še vedno nekoliko nezrela in to velja za izdelke, obravnavane v tem članku. Po drugi strani pa smo morda zdaj v dobi, ko izdelki nikoli zares ne dozorijo, ker se osnovne tehnologije, na katerih temeljijo, tako hitro spreminjajo. Pravzaprav sem našel velike težave s skoraj vsakim izdelkom vmesne programske opreme, ki sem ga uporabljal, vključno z domnevno zrelimi izdelki, ki so na trgu že nekaj let in so pred kratkim izšli s pomembnimi novostmi. Bistvo je, da ko prodajalcu uspe odpraviti težave, so bile dodane nove funkcije. Cikel dodajanja novih funkcij je zdaj veliko krajši kot kdaj koli prej, zato izdelki nimajo dovolj časa, da postanejo stabilni, preden vključijo naslednji večji nabor funkcij. To se je morda nekaj, na kar se moramo navaditi, in učenje prednosti in slabosti izdelkov, ki jih izberemo, je pomemben del vsakega cikla zasnove aplikacije in prototipa.

Cilji za vmesno programsko opremo

Standard komponente vmesne programske opreme EJB je bil razvit z naslednjimi cilji:

  • Zagotoviti interoperabilnost komponent. Podjetniški fižol, razvit z različnimi orodji, bo deloval skupaj. Tudi fižol, razvit z različnimi orodji, bo deloval v katerem koli okolju EJB.

  • Zagotoviti enostaven programski model, hkrati pa ohraniti dostop do API-jev na nizki ravni.

  • Za reševanje težav v življenjskem ciklu, vključno z razvojem, uvajanjem in izvajanjem.

  • Zagotoviti združljivost z obstoječimi platformami, kar omogoča razširitev obstoječih izdelkov na podporo EJB.

  • Da bi ohranili združljivost z drugimi API-ji Java.

  • Zagotoviti interoperabilnost med EJB in aplikacijami, ki niso Java.

  • Da je združljiv s CORBA.

Standard EJB se zato osredotoča na ustvarjanje standarda interoperabilnosti za vmesno programsko opremo Java, ki ščiti programerje pred reševanjem številnih težav, ki se pojavijo pri razvoju porazdeljenih aplikacij. To omogoča razvijalcem programske opreme, da se osredotočijo na poslovno logiko, namesto da pišejo dodelano domačo infrastrukturo in orodja. Posledično lahko podjetja večino svojih izobraževalnih virov usmerijo v usposabljanje osebja v poslovnih procesih, kar je običajno tisto, kar zagotavlja največje izplačilo.

Zgornjemu seznamu dodam naslednje dodatne cilje za vmesno programsko opremo Java poslovnega razreda. Te funkcije izdelka so dolgoročno potrebne za uspešno delovanje in vzdrževanje okolja, ki temelji na vmesni programski opremi:

  • Prilagoditi mora medsebojno povezovanje več poslovnih enot, podjetij in kupcev v porazdeljeni infrastrukturi, ne da bi to ogrožalo varnost ali uvajalo kaos

  • Omogočati mora prožne, a zanesljive mehanizme nadzora dostopa, ki zagotavljajo dostop do podatkov poslovnih partnerjev samo na predvidene načine in samo s strani predvidenih strank

  • Sistemskim skrbnikom bi moral omogočiti enotno upravljanje porazdeljenega računalniškega okolja, ki vsebuje veliko število komponent poslovne logike, ne da bi morali razumeti ali uporabiti edinstvene postopke za določene komponente

  • sistemskim skrbnikom bi moral omogočiti izbiro komponent infrastrukture, ne da bi to vplivalo na aplikacije, ter prilagoditi in prilagoditi te komponente ter imeti enotna in splošna sredstva za merjenje učinkovitosti in potreb po virih vseh aplikacij

  • Omogočati mora premeščanje poslovnih komponent med odjemalci in strežniki, ne da bi to vplivalo na arhitekturo obeh

  • Zagotavljati mora varnostni mehanizem, ki določenim uporabnikom omogoča dodajanje novih komponent, ne da bi moral skrbniku strežnika omogočiti dostop do vseh komponent in virov podatkov (to je odlična priložnost za dodano vrednost, saj je za ekstranet in partnerske aplikacije ključnega pomena )

Komponente in značilnosti platform za vmesno programsko opremo Java

Najhitreje rastoča kategorija vmesne programske opreme Java je danes verjetno aplikacijski strežnik. Ključno pa je, da se zavedate najrazličnejših strežnikov aplikacij (in drugih vrst vmesnih programov), ki obstajajo. Razlike med kategorijami izdelkov vmesne programske opreme Java danes ne predstavljajo vrstice, temveč obsežen kontinuum vmesne programske opreme. Zdaj bom razpravljal o značilnostih vmesne programske opreme Java na podlagi lastnih primerjav dela, ki zajemajo vse razrede vmesne programske opreme Java, ki jih poznam.

Modeli predmetov, komponent in vsebnikov

Komponente aplikacije se morajo držati nekega uvajalnega modela uvajanja, ki določa, kako komponenta komunicira s svojim okoljem; (mogoče), kako je nameščen, zagnan, zaustavljen in poklican; in kako dostopa do storitev, pomembnih za njegovo okolje. Priljubljeni modeli izvajalnega okolja in vsebnikov, osredotočeni na Javo, vključujejo RMI, EJB, CORBA, DCOM, strežniški programček, JSP (Java Server Pages) in shranjene postopke Java. Poleg tega se lahko modeli komponent izrazijo v različnih osnovnih jezikih, vključno z Java, IDL, C ++ in številnimi drugimi.

Obstaja prekrivanje z različnimi modeli komponent. Na primer, RMI je trivialni komponentni model z zelo osnovnimi zmogljivostmi za aktiviranje in lokacijo objektov in je predvsem standard oddaljenega klica, medtem ko EJB izkoristi RMI in RMI določi kot svoj primarni model klica predmeta. EJB podpira tudi CORBA. Pravzaprav noben od teh modelov ni ekskluziven in številni strežniki aplikacij Java podpirajo večino ali vse zgornje modele.

Številni strežniki vmesne programske opreme Java izvajajo več primerkov poslovnih predmetov (ki jih svet CORBA zdaj imenuje strežniki) v enem samem navideznem računalniku Java (JVM). Varnost tipa jezika Java omogoča, da en sam postopek JVM servisira zahteve več odjemalcev in uporablja programske podatkovne strukture in nalagalnike razredov, da hranijo odjemalske podatke ločeno. Dokler uslužbenci ne uporabljajo lastnih izvornih metod, en služabnik ne more spraviti drugih uslužbencev, če se zruši (razen če naleti na napako v samem JVM) ali dostopati do podatkov, ki so zasebni za druge razrede. . Pravilno zasnovan strežnik objektov bo zaščitil svoje zasebne predmete in preprečil, da bi napačni predmeti dostopali do drugih predmetov.

Vendar pa lahko podatke, razglašene za statične v razredu Java, delijo odjemalci znotraj istega JVM, če odjemalci uporabljajo isti nalagalnik razredov, zato je treba določiti pravila, ki bodo narekovala, kdaj ločen JVM (ali enakovreden ločen JVM z uporabo pomnilnika- tehnik razdeljevanja) ali ločen nalagalnik razredov, da odjemalcu omogoči lasten statični podatkovni prostor. Takšna pravila so bila določena za programčke, ne pa tudi za druga izvedbena okolja. Sunov spletni strežnik Java uporablja en JVM za vse servlete in ločen prostor imen razreda za servlete z drugačno kodno osnovo. EJB težavo izogne ​​s prepovedjo nedokončnih statičnih podatkov.

Zmogljivost se lahko poveča, če so predmeti inaktivirani ali pasivizirani, ko niso v uporabi, s čimer se sprostijo viri, kot so povezave z bazo podatkov. Iz tega razloga mnogi strežniki pasivizirajo in ponovno aktivirajo predmete, kot je primerno. Podobno nekateri izdelki hranijo pogosto ustvarjene predmete v področju ali predpomnilniku v inicializiranem stanju in so pripravljeni za takojšnjo uporabo. Vsebnik predmetov mora upravljati pasivizacijo in reaktivacijo ter združene vire, na katere pasivizacija vpliva.

Združljivost z EJB (različica)

Model EJB že postaja splošno podprt. Skoraj vsak prodajalec vmesne programske opreme je obljubil, da jo bo podpiral in mnogi že to podpirajo. Poleg tega je skupina za upravljanje predmetov (OMG) vključila preslikavo v EJB kot del predlaganega Specifikacija komponente CORBA. Težko si je predstavljati, da tudi Microsoft, osamljeni in neomajni zastoj, sčasoma ne bo prinesel in ponudil vsebnikov EJB za DCOM.

Medtem ko lahko različna vmesna programska oprema, združljiva z EJB, uvede in deluje z istimi komponentami aplikacije (če te komponente uporabljajo samo standardne zahtevane funkcije EJB), med strežniki, združljivimi z EJB, še vedno obstajajo številne razlike. Prvič, sama specifikacija EJB se razvija. Zato je pri ocenjevanju vmesnih programov Java pomembno vprašanje: Ali strežnik podpira najnovejšo različico EJB ali podpira samo starejšo različico? Drugo ključno vprašanje je: Ali je izdelek osredotočen na EJB ali je podpora EJB vključena samo v funkcije z dodano vrednostjo izdelka (in zato ni na voljo, kadar se uporabljajo storitve ali API-ji EJB)? In na koncu: Katere izbirne funkcije EJB so vključene (na primer fižol entitet in obstojnost, ki jo upravlja vsebnik)?

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