Programovanie

Navrhnite jednoduchý aplikačný rámec J2EE zameraný na služby

Dnes sú vývojári zaplavení frameworkmi otvoreného zdroja, ktoré pomáhajú s programovaním J2EE: Struts, Spring, Hibernate, Tiles, Avalon, WebWorks, Tapestry alebo Oracle ADF. Mnoho vývojárov zistí, že tieto rámce nie sú všeliekom na ich problémy. To, že sú open source, ešte neznamená, že sa dajú ľahko meniť a vylepšovať. Ak rámec v kľúčovej oblasti nedosiahne, oslovuje iba konkrétnu doménu alebo je iba nafúknutý a príliš drahý, možno budete musieť na jeho vrchole vytvoriť vlastný rámec. Budovanie rámca ako Struts je nenáročná úloha. Postupné rozvíjanie rámca, ktorý využíva Struts a iné rámce, však už nemusí byť.

V tomto článku vám ukážem, ako sa rozvíjať X18p (Xiangnong 18 Palm, pomenovaný pre legendárneho mocného bojovníka kung-fu), ukážkový rámec, ktorý sa zameriava na dva bežné problémy ignorované väčšinou rámcov J2EE: tesné spojenie a nafúknutý kód DAO (objekt prístupu k údajom). Ako uvidíte neskôr, X18p využíva rámy Struts, Spring, Axis, Hibernate a ďalšie v rôznych vrstvách. Dúfajme, že s podobnými krokmi budete môcť ľahko vytvoriť svoj vlastný rámec a rozšíriť ho z projektu na projekt.

Prístup, ktorý používam pri vývoji tohto rámca, využíva koncepty z IBM Rational Unified Process (RUP). Postupujem podľa týchto krokov:

  1. Stanovte si spočiatku jednoduché ciele
  2. Analyzujte existujúcu aplikačnú architektúru J2EE a identifikujte problémy
  3. Porovnajte alternatívne rámce a vyberte ten, s ktorým je najjednoduchšie zostaviť
  4. Vyvíjajte kód postupne a často ho refaktorujte
  5. Stretávajte sa s koncovými používateľmi rámca a pravidelne zhromažďujte spätnú väzbu
  6. Test, test, test

Krok 1. Stanovte si jednoduché ciele

Je lákavé stanoviť si ambiciózne ciele a zaviesť špičkový rámec, ktorý vyrieši všetky problémy. Ak máte dostatok zdrojov, nie je to zlý nápad. Všeobecne sa vývoj rámca vopred pre váš projekt považuje za réžiu, ktorá neposkytuje hmatateľnú obchodnú hodnotu. Začiatok menšieho rastu vám pomôže znížiť nepredvídané riziká, užiť si menej času na vývoj, znížiť krivku učenia sa a získať záujemcov o projekt. Pre X18p som stanovil iba dva ciele na základe mojich minulých stretnutí s kódom J2EE:

  1. Znížte J2EE Akcia kódová väzba
  2. Znížte opakovanie kódu vo vrstve J2EE DAO

Celkovo chcem poskytnúť kvalitnejší kód a znížiť celkové náklady na vývoj a údržbu zvýšením svojej produktivity. S tým prechádzame dvoma iteráciami krokov 2 až 6, aby sme tieto ciele dosiahli.

Znížte väzbu kódu

Krok 2. Analyzujte predchádzajúcu architektúru aplikácie J2EE

Ak je zavedený aplikačný rámec J2EE, najskôr musíme vidieť, ako sa dá vylepšiť. Je zrejmé, že začať od nuly nemá zmysel. Pre X18p sa pozrime na typický príklad aplikácie J2EE Struts, zobrazený na obrázku 1.

Akcia hovory XXXManagera XXXManager hovory XXXDAOs. V typickom dizajne J2EE, ktorý obsahuje Struts, máme tieto položky:

  • HttpServlet alebo vzpery Akcia vrstva, ktorá zvláda HttpRequest a HttpResponse
  • Vrstva obchodnej logiky
  • Vrstva prístupu k údajom
  • Doménová vrstva, ktorá sa mapuje na entity domény

Čo je zlé na vyššie uvedenej architektúre? Odpoveď: tesné spojenie. Architektúra funguje dobre, ak je v tom logika Akcia je jednoduchý. Čo však v prípade, že potrebujete získať prístup k mnohým komponentom EJB (Enterprise JavaBeans)? Čo ak potrebujete prístup k webovým službám z rôznych zdrojov? Čo ak potrebujete získať prístup k JMX (Java Management Extensions)? Má Struts nástroj, ktorý vám pomôže vyhľadať tieto zdroje od struts-config.xml spis? Odpoveď je nie. Struts má byť rámcom iba pre web. Je možné kódovať Akcias ako rôzni klienti a volajte do koncového zariadenia prostredníctvom vzoru vyhľadávača služieb. Týmto spôsobom sa však v systéme zmiešajú dva rôzne typy kódu Akciaje vykonať () metóda.

Prvý typ kódu sa týka webovej vrstvy HttpRequest/HttpResponse. Napríklad kód načítava údaje formulára HTTP z ActionForm alebo HttpRequest. Máte tiež kód, ktorý nastavuje údaje v požiadavke HTTP alebo relácii HTTP a presmeruje ich na stránku JSP (JavaServer Pages), ktorá sa má zobraziť.

Druhý typ kódu sa však týka obchodnej úrovne. V Akcia, vyvoláte aj backendový kód ako napr EJBObject, téma JMS (Java Message Service), alebo dokonca zdroje údajov JDBC (Java Database Connectivity) a načítať výsledné údaje z zdrojov údajov JDBC. Vzor vyhľadávača služieb môžete použiť v Akcia ktorý vám pomôže vyhľadať. Je to tiež možné pre Akcia odkazovať iba na lokálny POJO (obyčajný starý objekt Java) xxxManager. Napriek tomu backendový objekt resp xxxManagerPodpisy na úrovni metódy sú vystavené Akcia.

To je ako Akcia funguje, nie? Povaha Akcia je servlet, ktorý sa má starať o to, ako prijímať údaje z HTML a nastavovať údaje do HTML s požiadavkou / reláciou HTTP. Je tiež rozhraním s vrstvou obchodnej logiky, aby získala alebo aktualizovala údaje z tejto vrstvy, ale v akej forme alebo protokole, Akcia by sa to mohlo starať menej.

Ako si dokážete predstaviť, keď aplikácia Struts rastie, mohli by ste medzi nimi skončiť tesnými odkazmi Akcias (webová vrstva) a obchodní manažéri (obchodná vrstva) (pozri červené čiary a šípky na obrázku 1).

Na vyriešenie tohto problému môžeme zvážiť otvorené rámce na trhu - nechať ich inšpirovať naše vlastné myslenie skôr, ako urobíme dojem. Jarný rámec sa objaví na mojej radarovej obrazovke.

Krok 3. Porovnajte alternatívne rámce

Jadrom jarného rámca je koncept tzv BeanFactory, čo je dobrá implementácia vyhľadávacej továrne. Líši sa od vzoru vyhľadávača služieb tým, že má funkciu Inversion-of-Control (IoC), ktorá sa predtým volala Závislosť od injekcie. Cieľom je získať objekt zavolaním svojho ApplicationContextje getBean () metóda. Táto metóda vyhľadá v konfiguračnom súbore Spring definície objektov, vytvorí objekt a vráti a java.lang.Objekt objekt. getBean () je dobré na vyhľadávanie objektov. Zdá sa, že iba jeden odkaz na objekt, ApplicationContext, musí byť uvedený v Akcia. To však nie je prípad, ak ho použijeme priamo v Akcia, pretože musíme obsadiť getBean ()návratový typ objektu späť na klienta služieb EJB / JMX / JMS / Web. Akcia stále si musí byť vedomý backendového objektu na úrovni metódy. Tesné spojenie stále existuje.

Ak sa chceme vyhnúť odkazu na úrovni objektovej metódy, čo ešte môžeme použiť? Prirodzene, služby, príde na myseľ. Služba je všadeprítomný, ale neutrálny koncept. Službou môže byť čokoľvek, nielen nevyhnutne takzvané webové služby. Akcia metódu fazule session bean môže považovať aj za službu. Môže tiež považovať volanie témy JMS za náročné na službu. Spôsob, akým navrhujeme konzumáciu služby, môže byť veľmi všeobecný.

Vďaka formulovanej stratégii, zisteniu nebezpečenstva a riziku zníženému z vyššie uvedenej analýzy a porovnania môžeme podnietiť našu kreativitu a pridať tenkú vrstvu sprostredkovateľa služieb, aby sme demonštrovali koncept orientovaný na služby.

Krok 4. Vývoj a refaktorovanie

Pri implementácii konceptuálneho myslenia orientovaného na služby do kódu musíme zvážiť nasledovné:

  • Vrstva sprostredkovateľa služieb sa pridá medzi webovú vrstvu a obchodnú vrstvu.
  • Koncepčne Akcia zavolá iba požiadavku na obchodnú službu, ktorá požiadavku postúpi smerovaču služby. Servisný smerovač vie, ako spojiť požiadavky na podnikové služby s rôznymi radičmi alebo adaptérmi poskytovateľa služieb vyhľadaním súboru XML s mapovaním služby, X18p-config.xml.
  • Kontrolór poskytovateľa služieb má konkrétne vedomosti o vyhľadávaní a vyvolaní základných obchodných služieb. Tu môžu byť obchodné služby čokoľvek, od POJO, LDAP (ľahký prístupový protokol k adresárom), EJB, JMX, COM a webové služby až po API produktov COTS (komerčne dostupné). X18p-config.xml by mal poskytnúť dostatok údajov, aby pomohol kontrolórovi poskytovateľa služieb s vykonaním práce.
  • Využite pružinu na interné vyhľadávanie a referencie objektov X18p.
  • Postupne budujte radiče poskytovateľov služieb. Ako uvidíte, čím viac radičov poskytovateľov služieb bude implementovaných, tým viac má integračný výkon X18p.
  • Chráňte existujúce vedomosti, ako napríklad Struts, ale majte oči otvorené pre nové veci, ktoré prídu.

Teraz porovnáme Akcia kód pred a po použití rámca X18p zameraného na služby:

Struts Action bez X18p

 verejné spustenie ActionForward (mapovanie ActionMapping, formulár ActionForm, požiadavka HttpServletRequest, odpoveď HttpServletResponse) hodí IOException, ServletException {... UserManager userManager = nový UserManager (); Reťazec userIDRetured = userManager.addUser ("John Smith") ...} 

Struts Action s X18p

verejné spustenie ActionForward (mapovanie ActionMapping, formulár ActionForm, požiadavka HttpServletRequest, odpoveď HttpServletResponse) hodí IOException, ServletException {... ServiceRequest bsr = this.getApplicationContext (). getBean ("businessServiceRequest"); bsr.setServiceName ("Služby pre používateľov"); bsr.setOperation ("addUser"); bsr.addRequestInput ("param1", "addUser"); Reťazec userIDRetured = (Reťazec) bsr.service (); ...} 

Jar podporuje vyhľadávanie požiadaviek na obchodné služby a ďalších objektov, vrátane správcov POJO, ak existujú.

Obrázok 2 ukazuje, ako konfiguračný súbor Spring, applicationContext.xml, podporuje vyhľadávanie businessServiceRequest a serviceRouter.

V ServiceRequest.java, služba () metóda jednoducho zavolá Spring, aby našla smerovač služby a odovzdá sa smerovaču:

 public Object service () {return ((ServiceRouter) this.serviceContext.getBean ("service router")). route (this); } 

Servisný smerovač v X18p smeruje služby používateľa na vrstvu obchodnej logiky pomocou X18p-config.xmlpomoc. Kľúčovým bodom je, že Akcia kód nemusí vedieť, kde a ako sú implementované služby používateľa. Musí si byť vedomý iba pravidiel pre konzumáciu služby, ako je napríklad posúvanie parametrov v správnom poradí a uvádzanie správneho typu návratu.

Obrázok 3 zobrazuje segment X18p-config.xml ktorá poskytuje mapovacie informácie o službe, ktoré ServiceRouter vyhľadá v X18p.

Pre služby používateľom je typ služby POJO. ServiceRouter vytvorí kontrolór poskytovateľa služieb POJO na vybavenie žiadosti o službu. Toto POJO springObjectId je userServiceManager. Ovládač poskytovateľa služieb POJO používa Spring na vyhľadanie tohto POJO pomocou springObjectId. Odkedy userServiceManager ukazuje na typ triedy X18p.framework.UserPOJOManager, UserPOJOManager trieda je logický kód pre konkrétnu aplikáciu.

Preskúmajte ServiceRouter.java:

 trasa verejného objektu (ServiceRequest serviceRequest) vyvolá výnimku {// / 1. Prečítajte si všetky mapovania zo súboru XML alebo ich načítajte z Factory // Config config = xxxx; // 2. Získať typ služby z konfigurácie. Reťazec businessServiceType = Config.getBusinessServiceType (serviceRequest.getServiceName ()); // 3. Vyberte príslušný smerovač / ovládač / ovládač, ktorý s tým bude pracovať. if (businessServiceType.equalsIgnoreCase ("LOCAL-POJO")) {POJOController pojoController = (POJOController) Config.getBean ("POJOController"); pojoController.process (serviceRequest); } else if (businessServiceType.equalsIgnoreCase ("WebServices")) {String endpoint = Config.getWebServiceEndpoint (serviceRequest.getServiceName ()); WebServicesController ws = (WebServicesController) Config.getBean ("WebServicesController"); ws.setEndpointUrl (koncový bod); ws.process (serviceRequest); } else if (businessServiceType.equalsIgnoreCase ("EJB")) {EJBController ejbController = (EJBController) Config.getBean ("EJBController"); ejbController.process (serviceRequest); } else {// TODO System.out.println ("Neznáme typy, je len na vás, ako s tým v rámci naložíme"); } // To je všetko, je to váš rámec, môžete pridať ľubovoľného nového poskytovateľa služieb pre svoj ďalší projekt. návrat null; } 

Vyššie uvedený smerovací blok if-else by mohol byť refaktorovaný do príkazového vzoru. The Konfig objekt poskytuje vyhľadanie konfigurácie XML Spring a X18p. Pokiaľ sa dajú získať platné údaje, je len na vás, ako implementujete vyhľadávací mechanizmus.

Za predpokladu správcu POJO, TestPOJOBusinessManager, je implementovaný radič poskytovateľa služieb POJO (POJOServiceController.java) potom vyhľadá addUser () metóda z TestPOJOBusinessManager a vyvolá ho odrazom (pozri kód dostupný z prostriedkov).

Zavedením troch tried (BusinessServiceRequester, ServiceRoutera ServiceProviderController) plus jeden konfiguračný súbor XML, máme rámec zameraný na služby ako dôkaz koncepcie. Tu Akcia nemá žiadne vedomosti o tom, ako je služba implementovaná. Záleží mu iba na vstupe a výstupe.

Zložitosť používania rôznych rozhraní API a programovacích modelov na integráciu rôznych poskytovateľov služieb je chránená pred vývojármi spoločnosti Struts pracujúcimi na webovej vrstve. Ak X18p-config.xml je navrhnutý vopred ako zmluva o poskytovaní služieb, vývojári spoločnosti Struts a backend môžu súčasne pracovať podľa zmluvy.

Obrázok 4 zobrazuje nový vzhľad architektúry.

Bežné radiče a implementačné stratégie poskytovateľa služieb som zhrnul v tabuľke 1. Môžete ľahko pridať ďalšie.

Tabuľka 1. Implementačné stratégie pre bežných kontrolórov poskytovateľov služieb

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