Asiakas / palvelin on kuollut. Se on huhu nyt, kun uudemmat Internet-pohjaiset tekniikat kukoistavat. Mutta nämä uudet tekniikat ovat vain aikaisempien lähestymistapojen luonnollinen kehitys, jotka on toteutettu uudemmilla, avoimemmilla protokollilla ja jotka on suunniteltu tarjoamaan suurempi skaalautuvuus, hallittavuus ja monimuotoisuus.
Tämän evoluution laajuus on hämmästyttävä. Suurin osa suurimmista asiakas / palvelintoimittajista on modernisoinut tuotteitaan ja ohjaavat markkinointidollarinsa kolmiportaiseen tekniikkaan. Useimmissa tapauksissa uudemmat tuotteet ovat Java- ja Internet-protokollakeskeisiä. Esimerkiksi tunnistin viimeinkin vähintään 46 Java-väliohjelmistotuotetta. Kaksi vuotta sitten olisi ollut vaikea päästä puoleen tästä luvusta.
Tämä on ensimmäinen kaksiosainen artikkelisarja, joka on omistettu selittämään yleiskäyttöisiä Java-väliohjelmia sen nykyisissä muodoissa. Tässä ensimmäisessä artikkelissa tarkastelen nykyisten tuotteiden ominaisuuksia ja selitän, miksi nämä ominaisuudet ovat tärkeitä. Toisessa osassa Anil Hemrajani tarkastelee Enterprise JavaBeansia (EJB) ja näyttää, kuinka Java-väliohjelmistotuotteiden nykyinen sukupolvi liittyy tähän tärkeään komponenttistandardiin ja tukee sitä.
Tausta
Ensinnäkin, määritellään Java-väliohjelmisto. Termi kattaa sovelluspalvelimet, kuten BEA WebLogic, viestintätuotteet, kuten Active Software's ActiveWorks ja Push Technologies's SpiritWAVE, sekä hybridituotteet, jotka perustuvat DBMS-perintöön ja lisäävät palvelinpohjaisia Java-objektien suoritusominaisuuksia. Olisin voinut keskittyä kapeampaan segmenttiin, kuten sovelluspalvelimiin, mutta se olisi ollut epäoikeudenmukaista moniin tuotteisiin, jotka eivät sovi tähän luokkaan tarkasti, mutta silti se olisi otettava huomioon monitasoisissa sovelluksissa. Jopa sovelluspalvelimien joukossa on melko laaja taajuuksia, mukaan lukien ne, jotka ovat ensisijaisesti servlet-palvelimia, sekä ne, jotka ovat ORB- tai OODB-pohjaisia. Rajan vetäminen kaikkien näiden tuotteiden välille osoittautuu yhä vaikeammaksi. Yhdistävä piirre on kuitenkin se, että ne kaikki yrittävät ratkaista monitasoisen sovelluksen käyttöönotto-ongelman Java- ja Internet-tekniikoiden avulla.
Liiketoimintatapa Java: n käyttämiseksi väliohjelmistoissa on vakuuttava; Java-väliohjelmiston tarjoamia etuja ovat seuraavat:
Internetin kyky yhdistää taloudellisesti toimistot ja organisaatiot
Organisaatioiden on tehtävä yhteistyötä jakamalla tietoja ja liiketoimintaprosesseja
Halu yhdistää yleiset palvelut ja näiden palveluiden hallinta
Halu tarjota keskitettyä sovellusten hallintaa, mukaan lukien käynnistys, sammutus, ylläpito, palautus, kuormituksen tasapainotus ja valvonta
Halu käyttää avoimia palveluita ja protokollia
Halu siirtää liiketoimintalogiikkaa uudelleen haluamallaan tavalla ja ilman infrastruktuurin rajoituksia; tämä edellyttää avoimien sovellusliittymien ja protokollien käyttöä, joita tuetaan laajalti useimmissa infrastruktuurituotteissa
Tarve tukea yhteistyössä toimivia sekarakenteisia sovelluksia
Halu siirtää verkko- ja palveluinfrastruktuuripäätökset pois sovellustilasta, jotta järjestelmän ylläpitäjät voivat tehdä infrastruktuuripäätöksiä ilman, että omat protokollat tai ominaisuudet riippuvat sovellukset estävät niitä
Halu vähentää ohjelmoijahenkilöstön tarvittavien taitojen monimuotoisuutta ja tasoa sekä minimoida edistyneen työkalurakennusosaamisen tarve projekteissa
- Halu hyödyntää olio-osaamista laajentamalla se palvelinmaailmaan - siten uudemmat olio-palvelintuotteet ja objekti-relaatio-sillat
Väliohjelmiston tavoitteena on keskittää ohjelmistoinfrastruktuuri ja sen käyttöönotto. Asiakas / palvelin on peräisin yhdestä osastosta tapahtuvan integraation aikakaudelta. Organisaatiot yrittävät nyt yleensä integroitua osastojen rajojen yli - jopa organisaatiosta toiseen. Internet - joka houkuttelee yrityksiä kykyyn toimia globaalina verkostona, joka antaa osastojen ja yhteistyökumppaneiden yhteyden tehokkaasti ja nopeasti - on luonut tämän integraation kysynnän.
Java tarjoaa lingua franca datan ja sovellusten yhdistäminen helposti organisaation rajojen yli: Hajautetussa globaalissa ympäristössä, jossa et voi hallita kumppaniesi tekemiä teknologiavalintoja, älykkäät yritykset valitsevat avoimet ja alustaneutraalit standardit. Yritykset eivät voi ennakoida, kuka tulee asiakkaiksi, kumppaneiksi tai tytäryhtiöiksi kahden vuoden matkan varrella, joten ei ole aina mahdollista suunnitella yhteistä infrastruktuuria kumppaneidensa kanssa. Tässä epävarmassa tilanteessa paras päätös voi olla käyttää mahdollisimman universaalia ja sopeutuvaa tekniikkaa.
Java-sovelluksen avulla voit vähentää ohjelmointikielien ja -alustojen määrää, jonka henkilökunnan on ymmärrettävä. Miksi? Koska Java on nyt otettu käyttöön niin erilaisissa yhteyksissä kuin Internet-selaimet, tallennetut menettelyt tietokannoissa, liikeobjektit väliohjelmistotuotteissa ja asiakaspuolen sovellukset.
Kolmen vuoden iässä Java-tekniikka on kuitenkin vielä epäkypsä, ja tämä pätee tässä artikkelissa käsiteltyihin tuotteisiin. Toisaalta voimme olla nyt aikakaudella, jolloin tuotteet eivät koskaan saavuta kypsyyttä, koska niiden perustana olevat tekniikat muuttuvat niin nopeasti. Itse asiassa olen löytänyt merkittäviä ongelmia käytännössä jokaisen käyttämäni väliohjelmistotuotteen kanssa, mukaan lukien oletettavasti kypsät tuotteet, jotka ovat olleet markkinoilla muutaman vuoden ajan ja joilla on viime aikoina tullut esiin merkittäviä uusia ominaisuuksia. Asia on, että siihen mennessä, kun myyjä onnistuu korjaamaan ongelmat, uusia ominaisuuksia on lisätty. Uusien ominaisuuksien lisääminen on nyt paljon lyhyempi kuin koskaan ennen, joten tuotteilla ei ole tarpeeksi aikaa vakautua ennen kuin ne sisältävät seuraavan tärkeän ominaisuusjoukon. Tähän meidän on tottuttava, ja valitsemiemme tuotteiden vahvuuksien ja heikkouksien oppiminen on tärkeä osa sovellusten suunnittelua ja prototyyppisykliä.
Väliohjelman tavoitteet
EJB-väliohjelmakomponenttistandardi kehitettiin seuraavilla tavoitteilla:
Tarjota komponenttien yhteentoimivuus. Eri työkaluilla kehitetyt yrityspavut toimivat yhdessä. Eri työkaluilla kehitetyt pavut toimivat myös missä tahansa EJB-ympäristössä.
Tarjota helppokäyttöinen ohjelmointimalli säilyttäen samalla pääsy matalan tason sovellusliittymiin.
Elinkaarikysymysten käsitteleminen, mukaan lukien kehitys, käyttöönotto ja ajonaika.
Tarjota yhteensopivuus olemassa olevien alustojen kanssa, mikä mahdollistaa nykyisten tuotteiden laajentamisen EJB: n tueksi.
Ylläpitää yhteensopivuutta muiden Java-sovellusliittymien kanssa.
Tarjota yhteentoimivuus EJB: n ja muiden kuin Java-sovellusten välillä.
- Yhteensopivuus CORBA: n kanssa.
EJB-standardin painopiste on siis Java-väliohjelmistojen yhteentoimivuusstandardin luomisessa, joka suojaa ohjelmoijia joutumasta käsittelemään monia vaikeita asioita, joita syntyy hajautettujen sovellusten kehittämisessä. Tämä antaa ohjelmistokehittäjille mahdollisuuden keskittyä liiketoimintalogiikkaan sen sijaan, että kirjoittaisivat hienostunutta kotimaista infrastruktuuria ja työkaluja. Tämän seurauksena yritykset voivat käyttää suurimman osan koulutusresursseistaan henkilöstön kouluttamiseen liiketoimintaprosesseissa, mikä on tyypillisesti eniten tuottoa.
Lisään yllä olevaan luetteloon seuraavat lisätavoitteet yritystason Java-väliohjelmistoille. Näitä tuoteominaisuuksia tarvitaan pitkällä aikavälillä, jotta väliohjelmistopohjainen ympäristö voidaan hoitaa ja ylläpitää onnistuneesti:
Sen tulisi ottaa huomioon useiden liiketoimintayksiköiden, yritysten ja asiakkaiden yhteenliittäminen hajautetussa infrastruktuurissa vaarantamatta tietoturvaa tai aiheuttamatta kaaosta.
Sen pitäisi sallia joustavat mutta luotettavat pääsynvalvontamekanismit sen varmistamiseksi, että liikekumppanitietoihin pääsee vain tarkoitetulla tavalla ja vain tarkoitetut osapuolet
Sen pitäisi antaa järjestelmänvalvojille mahdollisuus hallita hajautettua laskentaympäristöä, joka sisältää suuren määrän liiketoimintalogiikan komponentteja yhtenäisellä tavalla, ilman, että heidän tarvitsee ymmärtää tai soveltaa ainutlaatuisia menettelyjä tiettyihin komponentteihin
sen pitäisi antaa järjestelmänvalvojille mahdollisuus tehdä infrastruktuurikomponenttien valintoja vaikuttamatta sovelluksiin, virittää ja skaalata kyseisiä komponentteja, ja niillä on oltava yhtenäiset ja yleiset keinot mitata kaikkien sovellusten suorituskykyä ja resurssitarvetta
Sen pitäisi sallia liiketoimintakomponenttien siirtäminen asiakkaiden ja palvelinten välillä vaikuttamatta kumman tahansa arkkitehtuuriin
Sen tulisi tarjota suojausmekanismi, jonka avulla tietyt käyttäjät voivat lisätä uusia komponentteja tarvitsematta antaa palvelimen järjestelmänvalvojalle pääsyä kaikkiin komponentteihin ja tietolähteisiin (tämä on hieno mahdollisuus lisäarvoa tuottavalle ominaisuudelle, koska se on kriittinen extranet- ja kumppanuussovelluksille) )
Java-väliohjelmistoalustojen komponentit ja ominaisuudet
Nopeimmin kasvava Java-väliohjelmistojen luokka on todennäköisesti sovelluspalvelimet. On kuitenkin välttämätöntä toteuttaa laaja valikoima sovelluspalvelimia (ja muita välituotetuotteita). Java-väliohjelmistojen tuoteluokkien välisiä eroja ei nykyään edustaa viiva, vaan laaja väliohjelmistojen jatkumo. Keskustelen nyt Java-väliohjelmiston ominaisuuksista omien työni vertailujen perusteella, jotka kattavat kaikki tuntemani Java-väliohjelmistotuoteryhmät.
Objekti-, komponentti- ja säiliömallit
Sovelluskomponenttien on noudatettava jotakin ajonaikaisen käyttöönoton mallia, joka määrittää kuinka komponentti kommunikoi ympäristönsä kanssa; (mahdollisesti) miten se asennetaan, käynnistetään, pysäytetään ja soitetaan; ja kuinka se käyttää ympäristölleen tärkeitä palveluja. Suosittuja Java-keskeisiä palvelinkomponenttien ajonaikaisia ja säilömalleja ovat RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages) ja Java-tallennetut menettelyt. Lisäksi komponenttimallit voidaan ilmaista useilla taustalla olevilla kielillä, mukaan lukien Java, IDL, C ++ ja monet muut.
On päällekkäisyyksiä eri komponenttimallien kanssa. Esimerkiksi RMI on triviaalikomponenttimalli, jolla on hyvin perustiedot objektien aktivoinnille ja paikannukselle, ja se on ensisijaisesti etäkutsu standardi, kun taas EJB käyttää RMI: tä ja määrittelee RMI: n ensisijaiseksi objektikutsumalliksi. EJB tukee myös CORBA: ta. Itse asiassa mikään näistä malleista ei ole yksinomainen, ja monet Java-sovelluspalvelimet tukevat suurinta osaa tai kaikkia edellä mainittuja malleja.
Monet Java-väliohjelmistopalvelimet käyttävät useita yritysobjektiesiintymiä (joita CORBA-maailma kutsuu nyt palvelijoiksi) yhdessä Java-virtuaalikoneessa (JVM). Java-kielen tyyppiturvallisuus mahdollistaa yhden JVM-prosessin palvelemaan useiden asiakkaiden pyyntöjä ja pitämään asiakastiedot erillään ohjelmatietorakenteiden ja luokkakuormaajien avulla. Niin kauan kuin palvelijat eivät käytä omia natiivimenetelmiään, yksi palvelija ei voi kaataa muita palvelijoita, jos se kaatuu (ellei se kohdata virhettä itse JVM: ssä) tai käyttää tietoja, jotka ovat yksityisiä muille luokille . Oikein suunniteltu objektipalvelin suojaa yksityisiä objektejaan ja estää virheellisiä objekteja pääsemästä muille esineille.
Java-luokassa staattisiksi julistetut tiedot voidaan kuitenkin jakaa saman JVM: n asiakkaiden kesken, jos asiakkaat käyttävät samaa luokan latainta, joten säännöt on määriteltävä sanelemaan, milloin erillinen JVM (tai vastaava erillinen JVM käyttää muistia - osiointitekniikat) tai erillinen luokan kuormaaja tarvitaan asiakkaalle oman staattisen tietotilan antamiseksi. Tällaiset säännöt on määritetty sovelmille, mutta ei muille suoritusympäristöille. Sunin Java-Web-palvelin käyttää yhtä JVM: ää kaikille servlet-sovelluksille ja erillistä luokan nimiavaruutta palvelinsovelluksille, joilla on erilainen koodipohja. EJB kiertää asiaa kieltämällä ei-lopulliset staattiset tiedot.
Suorituskykyä voidaan lisätä, jos objektit inaktivoidaan tai passivoidaan, kun niitä ei käytetä, mikä vapauttaa resursseja, kuten tietokantayhteyksiä. Tästä syystä monet palvelimet passivoivat ja aktivoivat objektit uudelleen tarpeen mukaan. Vastaavasti jotkut tuotteet pitävät usein luodut objektit poolissa tai välimuistissa alustetussa tilassa ja valmiina välittömään käyttöön. Kohdesäiliön on hallittava passivointia ja uudelleenaktivointia sekä yhdistettyjä resursseja, joihin passivointi vaikuttaa.
EJB-yhteensopivuus (versio)
EJB-mallia tuetaan jo yleisesti. Lähes jokainen väliohjelmistotoimittaja on luvannut tukea sitä ja monet jo tekevätkin. Lisäksi Object Management Group (OMG) on sisällyttänyt kartoituksen EJB: hen osana ehdotettua CORBA-komponenttien määrittely. On vaikea kuvitella, että edes Microsoft, yksinäinen ja vankka holdout, ei lopulta tuota EJB-kontteja DCOM: lle.
Vaikka erilaiset EJB-yhteensopivat väliohjelmistot voivat ottaa käyttöön ja käyttää samoja sovelluskomponentteja (niin kauan kuin kyseiset komponentit käyttävät vain vakiona vaadittuja EJB-ominaisuuksia), EJB-yhteensopivien palvelimien välillä on edelleen paljon vaihtelua. Ensinnäkin EJB-spesifikaatio itsessään on kehittymässä. Tärkeä kysymys Java-väliohjelmistotuotteita arvioitaessa on siis: Tukeeko palvelin EJB: n uusinta versiota vai tukeeko se vain vanhempaa versiota? Toinen keskeinen kysymys on: Onko tuote EJB-keskitetty vai sisältyykö EJB-tuki vain tuotteen lisäarvoa tuottaviin ominaisuuksiin (eikä siten ole käytettävissä, kun EJB-palveluja tai -sovellusliittymiä käytetään)? Ja lopuksi: Mitkä valinnaiset EJB-ominaisuudet ovat mukana (esimerkiksi kokonaisuuspavut ja konttiohjattu pysyvyys)?
