Suunnittele yksinkertainen palvelukeskeinen J2EE-sovelluskehys

Nykyään kehittäjät ovat täynnä avoimen lähdekoodin kehyksiä, jotka auttavat J2EE-ohjelmoinnissa: Struts, Spring, Hibernate, Tiles, Avalon, WebWorks, Tapestry tai Oracle ADF, muutamia mainitakseni. Monet kehittäjät huomaavat, että nämä kehykset eivät ole heidän ongelmiensa ihmelääke. Se, että he ovat avointa lähdekoodia, ei tarkoita, että niitä on helppo muuttaa ja parantaa. Kun kehys puuttuu avainalueelta, se koskee vain tiettyä verkkotunnusta tai on vain paisunut ja liian kallis, sinun on ehkä rakennettava oma kehys sen päälle. Strutsin kaltaisen kehyksen rakentaminen on ei-triviaalinen tehtävä. Mutta Strutsia ja muita kehyksiä hyödyntävän kehyksen vähitellen kehittämisen ei tarvitse olla.

Tässä artikkelissa näytän sinulle, kuinka kehittää X18p (Xiangnong 18 Palm, nimetty legendaarisesta voimakkaasta kung fu -taistelijasta), esimerkkikehys, joka käsittelee kahta yleistä ongelmaa, joita useimmat J2EE-kehykset jättävät huomiotta: tiukka kytkentä ja paisunut DAO-koodi (pääsyobjekti). Kuten näette myöhemmin, X18p hyödyntää tukijalkoja, jousia, akselia, horrostilaa ja muita kehyksiä eri tasoilla. Toivottavasti vastaavilla vaiheilla voit kehittää oman kehyksesi helposti ja kasvattaa sitä projektista toiseen.

Lähestymistapani, jota käytän kehyksen kehittämisessä, käyttää IBM: n Rational Unified Process (RUP) -konsepteja. Seuraan näitä vaiheita:

1. Aseta aluksi yksinkertaiset tavoitteet
2. Analysoi olemassa oleva J2EE-sovellusarkkitehtuuri ja tunnista ongelmat
3. Vertaa vaihtoehtoisia kehyksiä ja valitse yksinkertaisin rakentaa
4. Kehitä koodi vähitellen ja refaktori usein
5. Tapaa kehyksen loppukäyttäjän kanssa ja kerää palautetta säännöllisesti
6. Testi, testi, testi

Vaihe 1. Aseta yksinkertaiset tavoitteet

On houkuttelevaa asettaa kunnianhimoiset tavoitteet ja toteuttaa huippuluokan kehys, joka ratkaisee kaikki ongelmat. Jos sinulla on riittävät resurssit, se ei ole huono idea. Yleensä kehyksen kehittäminen etukäteen projektillesi katsotaan yleiskustannukseksi, joka ei tuota konkreettista liiketoiminnallista arvoa. Aloittaminen pienemmäksi auttaa vähentämään odottamattomia riskejä, nauttimaan vähemmän kehitysaikaa, laskemaan oppimiskäyrää ja saamaan hankkeen sidosryhmien osallistumisen. X18p: lle asetin vain kaksi tavoitetta aikaisempien kohtaamieni J2EE-koodin perusteella:

1. Vähennä J2EE: tä Toiminta koodikytkentä
2. Vähennä koodin toistoa J2EE DAO -kerroksessa

Kaiken kaikkiaan haluan tarjota paremman laatukoodin ja vähentää kehittämisen ja ylläpidon kokonaiskustannuksia lisäämällä tuottavuuttani. Sen avulla käymme läpi kaksi vaiheet vaiheista 2-6 saavuttaaksemme nuo tavoitteet.

Vähennä koodikytkentää

Vaihe 2. Analysoi edellinen J2EE-sovellusarkkitehtuuri

Jos J2EE-sovelluskehys on käytössä, meidän on ensin tarkasteltava, kuinka sitä voidaan parantaa. Ilmeisesti alusta alkaen ei ole järkevää. Katsotaanpa X18p-mallia varten tyypillinen J2EE Struts -sovellusesimerkki, joka on esitetty kuvassa 1.

Toiminta puhelut XXXManagerja XXXManager puhelut XXXDAOs. Tyypillisessä J2EE-mallissa, joka sisältää tuet, meillä on seuraavat tuotteet:

• HttpServlet tai tuki Toiminta kerros, joka käsittelee HttpRequest ja HttpResponse
• Liikelogiikan taso
• Tietojen käyttöoikeustaso
• Verkkotunnuskerros, joka kartoitetaan toimialuekokonaisuuksiin

Mitä vikaa yllä olevassa arkkitehtuurissa? Vastaus: tiukka kytkentä. Arkkitehtuuri toimii hienosti, jos logiikka sisään Toiminta on yksinkertainen. Mutta entä jos sinun on käytettävä monia EJB (Enterprise JavaBeans) -komponentteja? Entä jos sinun on käytettävä verkkopalveluja eri lähteistä? Entä jos sinun on käytettävä JMX: ää (Java Management Extensions)? Onko Strutsilla työkalu, jonka avulla voit etsiä näitä resursseja struts-config.xml tiedosto? Vastaus on ei. Strutsin on tarkoitus olla vain Web-tason kehys. On mahdollista koodata Toimintas erilaisina asiakkaina ja soittavat takapäähän Service Locator -kuvion kautta. Näin tekemällä kuitenkin sekoitetaan kaksi erityyppistä koodia sisään Toimintaon suorittaa() menetelmä.

Ensimmäinen koodityyppi liittyy Web-tasoon HttpRequest/HttpResponse. Esimerkiksi koodi hakee HTTP-lomaketiedot ActionForm tai HttpRequest. Sinulla on myös koodi, joka asettaa tiedot HTTP-pyynnössä tai HTTP-istunnossa ja välittää ne näytettävälle JSP (JavaServer Pages) -sivulle.

Toinen koodityyppi liittyy kuitenkin yritystasoon. Sisään Toiminta, käytät myös taustakoodia, kuten EJBObject, JMS (Java Message Service) -aihe tai jopa JDBC (Java Database Connectivity) -tietolähteet ja noutaa tulostiedot JDBC-tietolähteistä. Voit käyttää Service Locator -kuviota Toiminta auttaa sinua tekemään haun. Se on myös mahdollista Toiminta viitata vain paikalliseen POJO: han (tavallinen vanha Java-objekti) xxxManager. Siitä huolimatta taustakohde tai xxxManagermenetelmän tason allekirjoitukset altistuvat Toiminta.

Näin Toiminta toimii, eikö? Luonne Toiminta on servlet, jonka oletetaan välittävän siitä, kuinka ottaa tietoja HTML: stä ja asettaa tiedot HTML: ksi HTTP-pyynnöllä / istunnolla. Se on myös yhteydessä liiketoimintalogiikkatasoon saadakseen tai päivittääkseen tietoja kerroksesta, mutta missä muodossa tai protokollana, Toiminta voisi välittää vähemmän.

Kuten voitte kuvitella, kun Struts-sovellus kasvaa, saatat saada tiukat viitteet niiden välillä Toimintas (Web-taso) ja yritysjohtajat (business-taso) (katso punaiset viivat ja nuolet kuvassa 1).

Tämän ongelman ratkaisemiseksi voimme ottaa huomioon markkinoiden avoimet kehykset - anna niiden innostaa omaa ajatteluamme ennen kuin teemme vaikutuksen. Spring Framework tulee tutkanäytölle.

Vaihe 3. Vertaa vaihtoehtoisia kehyksiä

Spring Frameworkin ydin on nimeltään käsite Pavutehdas, mikä on hyvä hakutehtaan toteutus. Se eroaa palvelunetsintäkuviosta siinä, että siinä on aiemmin kutsuttu Inversion-of-Control (IoC) -ominaisuus Injektion riippuvuus. Ajatuksena on saada esine soittamalla sinulle ApplicationContexton getBean () menetelmä. Tämä menetelmä etsii Spring-määritystiedoston objektimäärityksille, luo objektin ja palauttaa a java.lang.objekti esine. getBean () on hyvä kohteiden hakuun. Vaikuttaa siltä, ​​että vain yksi objektiviite, ApplicationContext, on viitattava Toiminta. Näin ei kuitenkaan ole, jos käytämme sitä suoraan Toiminta, koska meidän täytyy heittää getBean ()palauttaa objektityypin takaisin EJB / JMX / JMS / Web-palveluun. Toiminta on silti oltava tietoinen backend-objektista metoditasolla. Tiukka kytkentä on edelleen olemassa.

Jos haluamme välttää objekti-menetelmä-tason viittauksen, mitä muuta voimme käyttää? Luonnollisesti, palvelu, tulee mieleen. Palvelu on yleinen mutta neutraali käsite. Kaikki voi olla palvelu, ei välttämättä vain ns. Verkkopalvelut. Toiminta pystyy käsittelemään myös kansalaisuudettoman istuntopapumenetelmän palveluna. Se voi pitää JMS-aiheen kutsumista myös palvelun kulutuksena. Tapa, jolla suunnittelemme palvelun kulutuksen, voi olla hyvin yleinen.

Strategian muotoilun, vaaran havaitsemisen ja riskien lieventämisen avulla yllä olevasta analyysistä ja vertailusta voimme kannustaa luovuuttamme ja lisätä ohuen palveluvälittäjäkerroksen palvelukeskeisen konseptin osoittamiseksi.

Vaihe 4. Kehitä ja refraktoi

Palvelukeskeisen konseptiajattelun toteuttamiseksi koodiksi on otettava huomioon seuraavat seikat:

• Palveluvälittäjäkerros lisätään verkkotason ja yritystason välille.
• Käsitteellisesti Toiminta kutsuu vain yrityspalvelupyynnön, joka välittää pyynnön palvelureitittimelle. Palvelureititin osaa liittää yrityspalvelupyynnöt eri palveluntarjoajan ohjaimille tai sovittimille etsimällä palvelun kartoitus XML-tiedostoa, X18p-config.xml.
• Palveluntarjoajan rekisterinpitäjällä on erityistä tietoa taustalla olevien yrityspalvelujen löytämisestä ja käyttämisestä. Yrityspalvelut voivat tässä olla mitä tahansa POJO: sta, LDAP: stä (kevyt hakemistoprotokolla), EJB: stä, JMX: stä, COM: stä ja verkkopalveluista COTS: n (kaupallinen hyllystä) tuotesovellusliittymiin. X18p-config.xml pitäisi toimittaa riittävästi tietoja palveluntarjoajan ohjaimen saamiseksi tehtävään.
• Hyödynnä jousta X18p: n sisäisen kohteen hakuun ja viitteisiin.
• Rakenna palveluntarjoajan ohjaimia asteittain. Kuten näette, mitä enemmän palveluntarjoajan ohjaimia on otettu käyttöön, sitä enemmän integrointitehoa X18p: llä on.
• Suojaa olemassa olevaa tietoa, kuten Struts, mutta pidä silmät auki uusille asioille.

Nyt verrataan Toiminta koodi ennen palvelukeskeisen X18p-kehyksen soveltamista ja sen jälkeen:

Struts-toiminta ilman X18p: tä

 public ActionForward execute (ActionMapping-kartoitus, ActionForm-lomake, HttpServletRequest-pyyntö, HttpServletResponse-vastaus) heittää IOException, ServletException {... UserManager userManager = new UserManager (); Merkkijono userIDRetured = userManager.addUser ("John Smith") ...} 

Tukee toimintaa X18p: llä

public ActionForward execute (ActionMapping-kartoitus, ActionForm-lomake, HttpServletRequest-pyyntö, HttpServletResponse-vastaus) heittää IOException, ServletException {... ServiceRequest bsr = this.getApplicationContext (). getBean ("businessServiceRequest"); bsr.setServiceName ("Käyttäjäpalvelut"); bsr.setOperation ("addUser"); bsr.addRequestInput ("param1", "addUser"); Merkkijono userIDRetured = (Merkkijono) bsr.service (); ...} 

Spring tukee yrityspalvelupyyntöjen ja muiden kohteiden hakua, mukaan lukien POJO-johtajat, jos sellaisia ​​on.

Kuva 2 näyttää kuinka Spring-määritystiedosto, applicationContext.xml, tukee hakua businessServiceRequest ja serviceRouter.

Sisään ServiceRequest.java, palvelu () method yksinkertaisesti kutsuu Springin etsimään palvelureitittimen ja välittää itsensä reitittimelle:

 public Object -palvelu () {return ((ServiceRouter) this.serviceContext.getBean ("palvelureititin")). reitti (tämä); } 

X18p: n palvelureititin reitittää käyttäjän palvelut liiketoimintalogiikan tasolle X18p-config.xmlapua. Tärkeintä on, että Toiminta koodin ei tarvitse tietää missä tai miten käyttäjäpalvelut toteutetaan. Sen on oltava tietoinen vain palvelun kulutusta koskevista säännöistä, kuten parametrien työntämisestä oikeaan järjestykseen ja oikean palautustyypin valamiseen.

Kuvassa 3 on esitetty segmentti X18p-config.xml joka tarjoaa palvelun kartoitustiedot, mikä ServiceRouter etsii X18p: ssä.

Käyttäjäpalveluissa palvelun tyyppi on POJO. ServiceRouter luo POJO-palveluntarjoajan ohjaimen palvelupyynnön käsittelemiseksi. Tämä POJO: n springObjectId On userServiceManager. POJO-palveluntarjoajan ohjain käyttää Springiä etsimään tätä POJOa springObjectId. Siitä asti kun userServiceManager osoittaa luokan tyypin X18p.framework.UserPOJOManager, UserPOJOManager luokka on sovelluskohtainen looginen koodi.

Tutki ServiceRouter.java:

 public Object route (ServiceRequest serviceRequest) heittää poikkeuksen {// / 1. Lue kaikki kartoitukset XML-tiedostosta tai noudata niitä tehtaalta // Config config = xxxx; // 2. Hae palvelun tyyppi konfiguraatiosta. Merkkijono businessServiceType = Config.getBusinessServiceType (serviceRequest.getServiceName ()); // 3. Valitse vastaava reititin / käsittelijä / ohjain käsittelemään sitä. 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 (päätepiste); ws.process (serviceRequest); } else if (businessServiceType.equalsIgnoreCase ("EJB")) {EJBController ejbController = (EJBController) Config.getBean ("EJBController"); ejbController.process (serviceRequest); } else {// TODO System.out.println ("Tuntemattomat tyypit, se on sinun tehtäväsi käsitellä sitä kehyksessä"); } // Siinä kaikki, se on sinun kehyksesi, voit lisätä minkä tahansa uuden ServiceProviderin seuraavaan projektiisi. return null; } 

Yllä oleva reititys if-else-lohko voidaan muokata komentomalliksi. Konfig object tarjoaa Spring- ja X18p XML -kokoonpanon haun. Niin kauan kuin kelvollisia tietoja voidaan noutaa, on sinun tehtäväsi hakumekanismi toteuttaa.

Oletetaan POJO-johtaja, TestPOJOBusinessManager, POJO-palveluntarjoajan ohjain (POJOServiceController.java) etsii sitten lisää käyttäjä() menetelmä TestPOJOBusinessManager ja kutsuu sitä pohdiskelemalla (katso Resursseista saatavilla oleva koodi).

Ottamalla käyttöön kolme luokkaa (BusinessServiceRequester, ServiceRouterja ServiceProviderController) plus yksi XML-määritystiedosto, meillä on palvelukeskeinen kehys todisteena konseptista. Tässä Toiminta hänellä ei ole tietoa palvelun toteuttamisesta. Se välittää vain panoksesta ja tuotoksesta.

Erilaisten sovellusliittymien ja ohjelmointimallien käytön monimutkaisuus eri palveluntarjoajien integroimiseksi on suojattu Struts-kehittäjiltä, ​​jotka työskentelevät verkkotasolla. Jos X18p-config.xml on suunniteltu etukäteen palvelusopimukseksi, Struts ja backend-kehittäjät voivat työskennellä samanaikaisesti sopimuksen mukaan.

Kuvassa 4 on esitetty arkkitehtuurin uusi ilme.

Tiivistin yleiset palveluntarjoajan ohjaimet ja toteutusstrategiat taulukossa 1. Voit lisätä helposti lisää.

Taulukko 1. Yhteisten palveluntarjoajien ohjainten toteutusstrategiat