Programování

Stav middlewaru aplikací Java, část 1

Klient / server je mrtvý. To je bzučení, když nyní prosperují novější internetové technologie. Ale tyto nové technologie jsou pouze přirozeným vývojem dřívějších přístupů, implementovaných pomocí novějších a otevřenějších protokolů a navržených tak, aby poskytovaly větší škálovatelnost, správu a rozmanitost.

Velikost tohoto vývoje je ohromující. Většina hlavních dodavatelů klient / server modernizovala své produkty a nyní nasměrovala své marketingové dolary na třístupňové technologie. Ve většině případů jsou novější produkty zaměřené na prostředí Java a na internetový protokol. Například jsem při posledním sčítání identifikoval alespoň 46 produktů Java middleware. Před dvěma lety by bylo těžké přijít s polovičním počtem.

Toto je první ze dvoudílné série článků věnovaných vysvětlení univerzálního Java Java v jeho současných podobách. V tomto prvním článku prozkoumám funkce současných produktů a vysvětlím, proč jsou tyto funkce důležité. Ve druhé části Anil Hemrajani prozkoumá Enterprise JavaBeans (EJB) a ukáže, jak současná generace Java middlewarových produktů souvisí a podporuje tento důležitý standard komponent.

Pozadí

Nejprve definujme Middleware Java. Termín zahrnuje aplikační servery, jako je BEA WebLogic, produkty pro zasílání zpráv, jako jsou ActiveWorks společnosti Active Software a SpiritWAVE společnosti Push Technologies, a hybridní produkty, které vycházejí ze staršího systému DBMS a přidávají funkce pro provádění objektů Java založené na serveru. Mohl jsem se zaměřit na užší segment, jako jsou aplikační servery, ale to by bylo nespravedlivé vůči mnoha produktům, které přesně nespadají do této kategorie, ale přesto by měly být brány v úvahu pro vícevrstvé aplikace. Dále dokonce i mezi aplikačními servery existuje poměrně široké spektrum, včetně těch, které jsou primárně servletovými servery, a také těch, které jsou založeny na ORB nebo OODB. Ukazování hranice mezi všemi těmito produkty se ukazuje jako stále obtížnější. Sjednocující funkcí však je, že se všichni pokoušejí vyřešit problém nasazení vícevrstvých aplikací pomocí technologií Java a Internetu.

Obchodní případ použití Java v middlewaru je přesvědčivý; Mezi výhody nabízené prostředím Java patří následující:

  • Schopnost internetu ekonomicky propojovat kanceláře a organizace

  • Potřeba spolupráce organizací sdílením dat a obchodních procesů

  • Touha konsolidovat generické služby a správu těchto služeb

  • Touha poskytovat centralizovanou správu aplikací, včetně spouštění, vypínání, údržby, obnovy, vyvažování zátěže a monitorování

  • Touha využívat otevřené služby a protokoly

  • Touha přesunout obchodní logiku dle libosti a bez omezení infrastrukturou; to vyžaduje použití otevřených API a protokolů, které jsou široce podporovány napříč většinou produktů infrastruktury

  • Potřeba podporovat spolupracující aplikace se smíšenou architekturou

  • Touha přesunout rozhodnutí o síťové a servisní infrastruktuře z aplikačního prostoru, aby mohli správci systému přijímat rozhodnutí o infrastruktuře, aniž by jim bránily aplikace závislé na proprietárních protokolech nebo funkcích

  • Touha snížit rozmanitost a úroveň potřebných dovedností pracovníků programátorů a minimalizovat potřebu pokročilých odborných znalostí v oblasti budování nástrojů v rámci projektů

  • Touha využít objektově orientovanou odbornost jejím rozšířením do sféry serveru - tedy novější objektově orientované serverové produkty a mosty mezi objektem a relací

Cílem middlewaru je centralizovat softwarovou infrastrukturu a její nasazení. Klient / server pochází z éry integrace v rámci jednoho oddělení. Organizace se nyní běžně pokoušejí o integraci přes hranice oddělení - dokonce i od jedné organizace k druhé. Internet - který láká podniky na svou schopnost sloužit jako globální síť, která umožňuje efektivní a rychlé propojení oddělení a partnerů - vyvolal poptávku po této integraci.

Java poskytuje lingua franca pro snadné propojení dat a aplikací přes hranice organizace: V distribuovaném globálním prostředí, ve kterém nemáte žádnou kontrolu nad tím, jaké technologické volby mohou vaši partneři dělat, si chytré společnosti vybírají otevřené a platformově neutrální standardy. Společnosti nemohou předvídat, kdo se stane jejich zákazníky, partnery nebo dceřinými společnostmi po dvou letech, takže není vždy možné plánovat společnou infrastrukturu s partnery. V této nejisté situaci může být nejlepším rozhodnutím použít nejuniverzálnější a nejpřizpůsobivější možné technologie.

Java vám umožňuje snížit počet programovacích jazyků a platforem, kterým musí vaši zaměstnanci rozumět. Proč? Protože Java je nyní nasazena v tak rozmanitých kontextech, jako jsou internetové prohlížeče, uložené procedury v databázích, obchodní objekty v produktech middlewaru a aplikace na straně klienta.

Ve věku tří let je však technologie Java stále ještě trochu nezralá, a to platí o produktech diskutovaných v tomto článku. Na druhou stranu nyní můžeme být v době, kdy produkty nikdy nedosáhnou zralosti, protože základní technologie, na nichž jsou založeny, se tak rychle mění. Ve skutečnosti jsem zjistil významné problémy prakticky s každým produktem middlewaru, který jsem použil, včetně údajně vyspělých produktů, které jsou na trhu již několik let a nedávno přišly s významnými novými funkcemi. Jde o to, že v době, kdy se prodejci podaří vyřešit problémy, byly přidány nové funkce. Cyklus přidávání nových funkcí je nyní mnohem kratší, než kdy byl, takže produkty nemají dostatek času na to, aby se staly stabilními, než zahrnou další hlavní sadu funkcí. To může být něco, na co si musíme zvyknout, a naučit se silné a slabé stránky produktů, které si vybereme, je důležitou součástí každého designu aplikace a prototypového cyklu.

Cíle pro middleware

Standard komponenty EJB middleware byl vyvinut s následujícími cíli:

  • Zajistit interoperabilitu komponent. Enterprise fazole vyvinuté s různými nástroji budou spolupracovat. Také fazole vyvinuté s různými nástroji poběží v jakémkoli prostředí EJB.

  • Poskytnout snadno použitelný programovací model při zachování přístupu k nízkoúrovňovým API.

  • Řešit problémy životního cyklu, včetně vývoje, nasazení a běhového prostředí.

  • Zajistit kompatibilitu se stávajícími platformami, což umožňuje rozšíření stávajících produktů o podporu EJB.

  • Zachovat kompatibilitu s jinými rozhraními Java API.

  • Zajistit interoperabilitu mezi EJB a jinými aplikacemi než Java.

  • Být kompatibilní s CORBA.

Standard EJB se proto zaměřuje na vytvoření standardu interoperability pro Java middleware, který chrání programátory před tím, aby se museli vypořádat s mnoha obtížnými problémy, které vyvstávají při vývoji distribuovaných aplikací. To umožňuje vývojářům softwaru soustředit se na obchodní logiku místo psaní sofistikované domácí infrastruktury a nástrojů. Výsledkem je, že podniky mohou většinu svých vzdělávacích zdrojů věnovat školení zaměstnanců v obchodních procesech, což je obvykle největší přínos.

Do výše uvedeného seznamu přidávám následující další cíle pro podnikový middleware Java. Tyto funkce produktu jsou dlouhodobě potřebné, aby bylo možné úspěšně provozovat a udržovat prostředí založené na middlewaru:

  • Mělo by vyhovět propojení více obchodních jednotek, společností a zákazníků v distribuované infrastruktuře, aniž by došlo k ohrožení zabezpečení nebo zavedení chaosu

  • Mělo by to umožnit flexibilní, ale spolehlivé mechanismy kontroly přístupu, které zajistí, že k datům obchodních partnerů bude přistupováno pouze zamýšleným způsobem a pouze zamýšlenými stranami

  • Mělo by to umožnit správcům systému spravovat distribuované výpočetní prostředí obsahující velké množství komponent obchodní logiky jednotným způsobem, aniž by museli rozumět nebo aplikovat jedinečné postupy na konkrétní komponenty

  • mělo by umožnit správcům systému provádět výběr komponent infrastruktury bez dopadu na aplikace a vyladit a škálovat tyto komponenty a mít jednotný a obecný způsob měření výkonu a potřeb zdrojů všech aplikací

  • Mělo by umožnit přemístění obchodních komponent mezi klienty a servery, aniž by to mělo dopad na jejich architektury

  • Mělo by poskytovat bezpečnostní mechanismus, který umožňuje konkrétním uživatelům přidávat nové komponenty, aniž by museli poskytovat správci serveru přístup ke všem komponentám a zdrojům dat (to je skvělá příležitost pro přidanou hodnotu, protože je to zásadní pro aplikace extranet a partnerství) )

Komponenty a funkce platforem Java middleware

Nejrychleji rostoucí kategorií Java middlewaru v současnosti jsou pravděpodobně aplikační servery. Je však nezbytné si uvědomit, že existuje široká škála aplikačních serverů (a dalších druhů produktů middlewaru). Rozdíly mezi kategoriemi Java middlewarových produktů dnes nepředstavuje čára, ale obrovské kontinuum middlewaru. Nyní budu diskutovat o vlastnostech Java middlewaru na základě mých vlastních pracovních srovnání, která zahrnují všechny třídy Java middleware produktů, o kterých vím.

Modely objektů, komponent a kontejnerů

Komponenty aplikace musí dodržovat nějaký model nasazení za běhu, který určuje, jak komponenta komunikuje se svým prostředím; (případně), jak je nainstalován, spuštěn, zastaven a volán; a jak přistupuje ke službám důležitým pro své prostředí. Mezi oblíbené runtime moduly a moduly serverových komponent zaměřené na prostředí Java patří RMI, EJB, CORBA, DCOM, servlet, JSP (Java Server Pages) a Java uložené procedury. Kromě toho lze modely komponent vyjádřit v různých základních jazycích, včetně prostředí Java, IDL, C ++ a mnoha dalších.

Existuje překrývání s různými modely komponent. Například RMI je triviální komponentní model s velmi základním vybavením pro aktivaci a umístění objektu a je primárně standardem vzdáleného vyvolání, zatímco EJB využívá RMI a specifikuje RMI jako svůj primární model vyvolání objektu. EJB také podporuje CORBA. Ve skutečnosti žádný z těchto modelů není exkluzivní a mnoho aplikačních serverů Java podporuje většinu nebo všechny výše uvedené modely.

Mnoho serverů Java middleware spouští více instancí obchodních objektů (které nyní svět CORBA nazývá sluhy) v rámci jediného virtuálního počítače Java (JVM). Typová bezpečnost jazyka Java umožňuje jednomu procesu JVM obsluhovat požadavky od více klientů a používat datové struktury programu a zavaděče tříd, aby byla data klienta oddělena. Dokud služebníci nepoužívají své vlastní nativní metody, není možné, aby jeden služebník přivedl další zaměstnance, pokud dojde ke zhroucení (pokud nenarazí na chybu v samotném JVM), nebo přistupuje k datům, která jsou soukromá pro jiné třídy . Správně navržený objektový server bude chránit své soukromé objekty a zabrání chybným objektům v přístupu k ostatním objektům.

Data deklarovaná jako statická ve třídě Java však mohou být sdílena mezi klienty v rámci stejného JVM, pokud klienti používají stejný zavaděč tříd, takže je třeba definovat pravidla, která diktují, kdy je samostatný JVM (nebo ekvivalent samostatného JVM využívajícího paměť - aby klient získal svůj vlastní statický datový prostor. Taková pravidla byla specifikována pro applety, ale ne pro jiná prováděcí prostředí. Sunův webový server Java používá jeden JVM pro všechny servlety a samostatný prostor názvů tříd pro servlety s jinou kódovou základnou. EJB tento problém obchází tím, že zakazuje konečná statická data.

Výkon lze zvýšit, pokud jsou objekty deaktivovány nebo pasivovány, když se nepoužívají, čímž se uvolní prostředky, jako jsou připojení k databázi. Z tohoto důvodu mnoho serverů podle potřeby pasivuje a znovu aktivuje objekty. Podobně některé produkty udržují často vytvářené objekty ve fondu nebo mezipaměti v inicializovaném stavu a připravené k okamžitému použití. Kontejner objektu musí spravovat pasivaci a reaktivaci i sdružené prostředky ovlivněné pasivací.

EJB kompatibilita (verze)

Model EJB se již stává všeobecně podporovaným. Téměř každý prodejce middlewaru slíbil, že ji podpoří, a mnoho z nich ji již podporuje. Skupina pro správu objektů (OMG) navíc začlenila mapování do EJB jako součást navrhovaného Specifikace komponent CORBA. Je těžké si představit, že ani Microsoft, osamělý a vytrvalý držák, nakonec nepřinese výnos a neposkytne kontejnery EJB pro DCOM.

Zatímco různé middleware kompatibilní s EJB mohou nasadit a provozovat stejné aplikační komponenty (pokud tyto komponenty používají pouze standardní požadované funkce EJB), mezi servery kompatibilními s EJB stále existuje velká variabilita. Za prvé se vyvíjí samotná specifikace EJB. Důležitou otázkou při hodnocení Java middlewarových produktů tedy je: Podporuje server nejnovější verzi EJB, nebo podporuje pouze dřívější verzi? Další klíčová otázka zní: Je produkt zaměřený na EJB, nebo je podpora EJB zahrnuta pouze do funkcí s přidanou hodnotou produktu (a proto není k dispozici, když se používají služby nebo rozhraní API EJB)? A konečně: Které volitelné funkce EJB jsou zahrnuty (například fazole entit a perzistence spravovaná kontejnerem)?