Ezzel csökkenthető a J2EE-projektek költsége és kockázata. Az Alerant a témához szorosan kapcsolódó technológiai bemutatókat is tart, aminek programjáról és időpontjairól az Alerant weboldalain lehet információkat találni.
A szoftverfejlesztési technológia folyamatosan változik, új eszközök jelennek meg, amelyek új módszerek és szoftverarchitektúrák kialakulását teszik lehetővé. Némelyek ezek közül divatossá válnak, és szélesebb körben elterjednek, míg mások nem tesznek szert különösebb szakmai népszerűségre. Az elosztott komponensek interakciójára alapuló architektúrák az elmúlt évtized során teljesen általánosakká váltak és széles körben alkalmazzák azokat elsősorban szerver oldali szoftverek készítésére. Az elosztott komponensek tényleges implementációi és kommunikációs megoldásai azonban különbözőek: RPC, CORBA, DCOM, EJB, XML/HTTP. A HTTP csatornákon keresztül küldött XML dokumentumokra alapuló Web Services elosztott komponenstechnológia csak néhány éve jelent meg, és koncepciójában ugyan semmi újat nem hozott a szoftvertársadalomnak, de implementációs megoldásának egyszerűsége általánosan elfogadottá tette és végre befejeződhetett az elosztott komponenstechnológiák harca, lehetővé téve az egymással kommunikálni képes szolgáltatásorientált szoftverek fejlesztésének kialakulását. A Web Services látványos sikerének három fontos alkotóeleme van:
A kérés és válaszüzenetek jól kezelhető, egyszerű szöveges XML dokumentumokként való megformálása.
A hálózaton legjobban támogatott (tűzfalak, terheléselosztók, proxyk) protokoll, a HTTP alkalmazása az XML formátumú üzenetek küldésére és fogadására.
Az jó terheléselosztást lehetővé tévő egyszerű, eredendően állapotmentes kérés-válasz kommunikációjú komponensek alkalmazása.
Egyetlen korábbi komponenstechnológia sem nyújtotta ezeket a szolgáltatásokat, így teljes körű támogatást egyik sem kapott: a Microsoft nevetségesnek tartotta a CORBA-t és az EJB-t, a szoftverarisztokraták, a "corbások" lenézték a többieket, az újdonsült javás EJB programozók meg nem is tudtak a többiekről azt hívén, ők találták fel az elosztott komponenseket. Miután a nagynevű technológiai szállítók gyámkodásától mentes, szabad szoftvervilágban az XML/HTTP megoldások kezdtek egyre jobban elterjedni, a Microsoft meghirdette új, elosztott komponensarchitektúráját a dotnetet (.NET), ami szintén a Web Services megoldást állította középpontjába. Nemsokára a Java világ is, akik már előzőleg elhódították a CORBA-sok piacát, csatlakoztak az XML/HTTP megoldást alkalmazókhoz. 2001-ben még egyszerű Java szervleteket írtunk, amik XML üzenetekkel válaszoltak az általában szintén XML formában bejövő kérésekre. Példaként említhetjük a világ legnagyobb forgalmú on-line piacterét az eBayt, ami szintén egyszerű XML/HTTP technológiát alkalmazó szolgáltatásokat nyújt az alkalmazásintegrációt használó partnerei számára. A legtöbb on-line fizetési szolgáltató (payment gateway) is XML/HTTP protokollal érhető el. Azon esetekben, amikor a szolgáltatást nyújtó szoftvergyártó valamilyen korábbi komponenstechnológiáról vált át Web Servicesre, egyszerűen egy vékony XML/HTTP-elérést biztosító komponensréteget épít meglévő EJB, CORBA, stb. komponensei elé. A komponenstechnológiát korábban nem alkalmazók vagy a teljesen új szoftverek építői azonban nem vacakolnak ilyen hagyatéki komponenstechnológiák építgetésével, ők minden komponenst eleve Web Serviceként implementálnak.
A Web Services (nagy kezdőbetűkkel és angol többes szám raggal) kifejezés, tehát az XML/HTTP protokollal kommunikáló szerverek implementációs technológiáját jelöli. Egy webszolgáltatás (web service) egy Web Services technológiával készült tényleges szervert vagy annak egy eljárását jelenti. Egy szoftverrendszer vagy egy alrendszer webszolgáltatásokon keresztül teszi elérhetővé funkcióit más (al)rendszerek számára. Mivel egy webszolgáltatás HTTP protokollal kommunikál, a jól ismert http://web.hely.com/szolgaltatas módon címezhető meg. Az üzenetek formátumát XSD (XML Schema Definition) nyelven írjuk le, ami az XML dokumentumok leírására korábban használt DTD (Document Type Definition) nyelvet váltotta fel. Egy adott címen elérhető webszolgáltatást és azok XML üzenetekkel való kommunikációját WSDL (Web Services Description Language) formában írják le. Az üzenetek küldésére a SOAP (Simple Object Access Protocol) protokoll használatos, ami gyakorlatilag a HTTP-nek a Web Services technológiára épülő adaptációja. Számos feladat számára az egymást követő üzeneteknek kapcsolódniuk kell egymáshoz, és így az eredendően állapotmentes HTTP kommunikációra alapozva az egyes kommunikációsorozatok állapotát kezelő megoldásokat vezettek be (párbeszéd azonosító). Az adattitkosítás a Web Services esetén normálisan azt jelenti, hogy az XML üzenetek HTTP/SSL csatornán küldődnek. Vannak azonban olyan esetek, amikor magát az XML üzenetet kívánatos titkosítani, amire a SOAP lehetőséget ad. A webszolgáltatásokat az üzemeltető cégek az UDDI (Universal Description, Discovery, and Integration) interfészen keresztül publikálhatják UDDI-keresést biztosító on-line katalógusokban.
Eredendően az XML/HTTP technológia egyszerű volt, de mint látható, mára már a használhatóság és a kommunikáció hatékonyságnövelése érdekében a Web Services technológia kibővült olyan eszközökkel, amik programozása magas szinten integrált fejlesztőeszközök használatát igényli. A Java alkalmazásszerverek talán legjelentősebb szállítója a BEA cég fő termékét a WebLogic szervert minden eszközzel ellátta, hogy a webszolgáltatás-orientált szoftverrendszerek számára hatékony környezetet biztosítson. A BEA WebLogic webszolgáltatások fejlesztése leghatékonyabban a Workshoppal valósítható meg. A BEA WebLogic Workshop vizuális programozói felületével jelentősen megnöveli a fejlesztői termelékenységet, és a kapcsolódó objektumgyűjteménnyel (Workshop runtime framework) azáltal, hogy a fejlesztőket mentesíti a J2EE komplexitásától. A fejlesztők ismert koncepciók (kontrollok, propertik) alkalmazásával vizuálisan modellezik a különféle komponensek, köztük a webszolgáltatások, kliensekkel és más erőforrásokkal való interakcióit. Ezáltal a programozók az alkalmazás tényleges funkcionalitására, üzleti logikájára tudnak koncentrálni egyszerű, vizuális eszközökkel is támogatott Java kódolás alkalmazásával; nem pedig a J2EE világban egyébként szokásos rendszer-szintű programozással kell birkózniuk.
A Workshop a modell, nézet, vezérlés szerepkörökbe sorolt komponensek kooperációjára (MVC architektúra) alapuló webes alkalmazásfejlesztés minden területét hatékonyan támogatja. A felhasználói felületeket szolgáltató JSP komponensek hatékony készítését a végletekig kifinomult NetUI objektumkönyvtárral és taglibrarykkel támogatja. A JSP oldalak közötti navigációt és a modell komponensekkel való kommunikációt, a vizuális programozást is támogató Page Flow vezérlőkomponensekkel teszi ámulatba ejtően hatékonnyá a Workshop. Jelen írásunkban a modell szerepkörű komponensek programozásának a Workshop által kínált új eszközeit szeretnénk részletesebben ismertetni.
A Workshop lehetővé teszi az összes típusú EJB fejlesztését, beleértve a komplex, konténer menedzselt perzisztenciájú (CMP) entity beanek "mutasd-és-kattints" vizuális eszközökkel való készítését is. Az EJB-kre alapuló architektúrák, azonban egy sor alkalmazás és projektbüdzsé számára túl bonyolultak illetve erőforrás-igényesek. A BEA az EJBk komplexitásából eredő problémák opcionális orvoslására új fejlesztéshatékonyság-növelő eszközöket vezetett be a WebLogic Workshop frameworkben:
- szerver oldali Java Controlokat,
- processz (folyamat) komponenseket.
A Java Controlok egyik fajtájához (Java Control Extension, JCX) tartozó objektumok meglévő (lokális vagy távoli) komponensekkel (EJB, webszolgáltatás, message queue, integrációs adapter, processz komponens) való kommunikációt kezelik, egyszerűen használható húzd-és-dobd programozást is támogató elemekkel.
A Database Java Control objektumok jelentősen leegyszerűsítik az SQL adatbázisok programozását, átláthatóbb alternatívát kínálva, mint az objektumrelációs leképezésre törekvő entity EJB-kre alapuló adatbázis-interfészek. A Database Java Controlok nem fedik el a az SQL-t, az adatbázisok több évtizede használt, jól ismert és kiválóan bevált programnyelvét. A Database Java Controlokban akár adatbáziskezelő-specifikus SQL-t is használhatunk. A Database Java Controlok tehát azon projektek számára hasznosak, ahol nem kívánnak élni a entity beanek nyújtotta objektumrelációs adatbáziskezeléssel együttjáró (performancia) problémákkal, jól ismerik az SQL-t, de ugyanakkor a JDBC programozói felületénél magasabb szintű eszközöket szeretnének használni.
A Custom Java Control (JCS) objektumok segítségével több Database Java Control vagy más EJB, webszolgáltatás, JMS, integrációs adapter, processz objektum eljárásainak hívását foghatjuk össze nagyobb tranzakciós egységekbe. A Workshopra alapuló projektekben a Custom Java Controlokat szánták az üzleti logika megvalósítására. A Custom Java Controlok újrafelhasználása könyvtári metódushívással valósul meg, így nincs kommunikációs többletterhelés. A Database Java Controllokhoz hasonlóan a Custom Java Controlok sem aktív komponensek hanem Page Flow, webszolgáltatás, vagy processz komponensekből, illetve más Custom Java Controlokból mint könyvtári objektumok hívhatók.
A Web Services objektumok közvetlenül használhatják a Database, Custom vagy más típusú Java Control objektumokat. Sok profit-orientált szoftverműhely még ma is idegenkedik a J2EE alkalmazásától annak komplexitása miatt. A WebLogic Workshop olyan Web Services technológiát alkalmazó komponens alapú fejlesztőkörnyezetet biztosít, ami nem készteti a fejlesztőket "réteghegyek" bevezetésére, ahhoz, hogy alkalmazásaikat hatékonyan valósítsák meg. A WebLogic szerver Workshop frameworkjével a fejlesztés olyan hatékonnyá tehető, hogy akár normális programozók is képesek komplex funkcionalitású szoftvert készíteni, mivel idejük nagy részét nem az infrastruktúra bonyolultságának megértésével töltik, hanem a megoldandó feladatokra tudnak figyelni. Ugyanakkor, a Workshoppal költség-hatékonyan készült alkalmazások olyan modern architektúrával készülhetnek, amik a legutóbbi szilíciumvölgyi divatnak is megfelelnek.
Ugyanakkor, a fentiekben elmondottak nem feltétlenül jelentik azt, hogy az EJB-knek ne lenne a jövőben szerepe a WebLogic környezetben. A Workshoppal néhány gombnyomással lehet webszolgáltatás felületet létrehozni meglévő session EJB-k fölé. A Workshop a webszolgáltatások és processz komponensek megvalósításához EJB-ket generál és használ. Hasonlóképpen, a Workshop környezetben nem írunk szervleteket, ugyanakkor, a WebLogic intenzíven használja a szervleteket a Page Flow architektúra és JSP-k tényleges implementációjára. Arról van tehát szó, hogy a Workshop szolgáltatásaira alapuló fejlesztés során (egyre) magasabb szintű elemeket használunk, amik megvalósításához azonban a WebLogic alacsonyabb szintű komponenseket használhat.
A felhasználói felület megvalósítására kiváló Page Flow-k mellett a Workshop nyújtotta magasszintű szolgáltatások csúcsát a processz komonensek alkotják. A processz komponenseket munkafolyamat (workflow) komponenseknek is szokták nevezni, noha egy processz teljesen általánosan használható tetszőleges programlogika reprezentálására. Egy processz komponens egy állapotgépet illetve alapvetően a Command tervezési mintát valósítja meg. Egy processz komponens létrehozásakor túlnyomórészt vizuális elemekkel programozunk olyanokkal, mint elágazás (decision, switch, event choice, parallel), ciklus (while do, do while, for each), eljáráshívás, üzenetküldés (client response, control send, perform) üzenetfogadás (client request, control receive). A vizuálisan összeállított programkód (folyamat) túlnyomó része XML formában tárolódik és a WebLogic szerver processz komponenseket tartalmazó alkalmazás telepítésekor lefordítja ezt a kódot és futásidőben már normál Java sebességgel futtatja. Egy processz példány instanciaváltozóinak értékét és állapotát egy speciális konzol programmal futásidőben meg lehet tekinteni. Egy processz Java Controllok segítségével más komponensek nyújtotta szolgáltatásokat is elérhetünk. Ilyenek a munkafolyamatokban tipikus humán beavatkozást reprezentáló task komponensek. A processzek Custom vagy Database Java Controllokat mint könyvtári objektumokat is hívhatják. Egy vizuálisan leprogramozott processzt webszolgáltatásként is elérhetjük, így a WebLogic-kal implementált webszolgáltatások tesztelésére szolgáló webes felület is rendelkezésre áll. A proceszekben megvalósított programlogikát, folyamatot más processzekből, webszolgáltatásokból Custom Java Controllokból úgynevezett Process Java Controllokkal érhetjük el legegyszerűbben.
A fentieket összefoglalva a következő megállapításokat tehetjük, amiket megfontolásra ajánlunk minden többrétegű (webes) szerver-alkalmazást fejlesztő projekt számára:
1. Alkalmazásszerverként BEA WebLogicot használjunk a hatékony fejlesztési (Workshop) és futásidejű eszközkészlet illetve kiváló támogatottság miatt.
2. Webes felületeket Workshop környezetben készítsünk a NetUI frameworkkel bővített JSP és Page Flow technológiával.
3. Az üzleti logikát Custom Java Controllokba ágyazzuk.
4. Az adatbázis-manipuláló műveleteket Database Controllokkal végezzünk.
5. Önálló elosztott komponenseket a Custom Java Controllokban leprogramozott üzleti logikát és a Database Java Controllok eljárásait felhasznáó webszolgáltatás vagy processz komponensekként tegyük elérhetővé más alrendszerek vagy a külvilág számára.
6. Ha saját EJB-ket szeretnénk gyártani, akkor azokat a Workshop vizuális környezetébe integrált EJBGen EJB kódgenerátorral fejlesszük.
7. Egy alkalmazás valamennyi elemét egy vagy több Workshop Applicationbe célszerű foglalni. Az alkalmazás alkotórészei az Applicationön belül különféle típusú (Java Control, Web User Interface, Web Service, Processz, stb) projektekbe kerülnek.
A BEA WebLogic Workshop framework magasszintű szolgáltatásai a felhasználói felületek programozását jelentősen leegyszerűsítő Page Flow, Java Control, webszolgáltatás és processz technológia olyan fejlesztői hatékonyságnövelő eszköz, hogy ezek alkalmazásával lehet csak igazán kiaknázni egy olyan komplex és drága szoftver szolgáltatásait mint a BEA WebLogic szerver. A Workshop és WebLogic szerver kombináció olyan magastechnológiájú környezetet ad, ami igazán kiemelkedő eszközzé teszi az alkalmazásszerverek között.
Az alábbi angol nyelvű dokumentumok további információkat nyújtanak a BEA WebLogicról, a Workshopról és Web Services technológiáról:
Technology Solutions - Building Web Services
Gamma, Helm, Johnson, Vlissides: Design Patterns, Addison-Wesley, 1995
A többrétegű alkalmazások fejlesztésének új technológiáit és eszközeit jelentette meg a BEA cég a WebLogic Workshop kiadásával. A Workshop nem csupán egy integrált fejlesztési környezet, hanem a WebLogic szerverhez kapcsolódó futásidejű Workshop frameworkkel olyan fejlesztési hatékonyságnövelő eszközkészletet ad a webes és szerveralkalmazások készítőinek, amikkel jelentősen leegyszerűsíthető a J2EE-alkalmazások megvalósítása.