Izstrādājiet vienkāršu uz pakalpojumu orientētu J2EE lietojumprogrammu sistēmu

Mūsdienās izstrādātājus pārpludina atvērtā koda sistēmas, kas palīdz J2EE programmēšanā: Struts, Spring, Hibernate, Flīzes, Avalon, WebWorks, Tapestry vai Oracle ADF, lai nosauktu tikai dažus. Daudzi izstrādātāji uzskata, ka šīs sistēmas nav viņu problēmu panaceja. Tas, ka viņi ir atvērtā koda, nenozīmē, ka tos ir viegli mainīt un uzlabot. Kad ietvars nepietiek galvenajā apgabalā, adresē tikai noteiktu domēnu vai ir vienkārši uzpūsts un pārāk dārgs, iespējams, tam virsū būs jāveido savs ietvars. Tādas struktūras izveide kā Struts ir nebūtisks uzdevums. Bet pakāpeniski izstrādāt tādu sistēmu, kas izmanto Struts un citus ietvarus, tā nav jābūt.

Šajā rakstā es parādīšu, kā attīstīties X18p (Xiangnong 18 Palm, kas nosaukts par leģendāru spēcīgu kung fu cīnītāju), parauga ietvars, kas risina divus izplatītākos jautājumus, kurus lielākā daļa J2EE ietvarstruktūru ignorē: saspringts savienojums un uzpūsts DAO (datu piekļuves objekta) kods. Kā redzēsit vēlāk, X18p dažādos slāņos izmanto Struts, Spring, Axis, Hibernate un citus ietvarus. Cerams, ka ar līdzīgām darbībām jūs varat viegli izveidot savu sistēmu un audzēt to no projekta uz projektu.

Pieejā, kuru izmantoju, izstrādājot šo ietvaru, tiek izmantoti IBM Rational Unified Process (RUP) jēdzieni. Es veicu šīs darbības:

1. Sākumā izvirziet vienkāršus mērķus
2. Analizējiet esošo J2EE lietojumprogrammu arhitektūru un identificējiet problēmas
3. Salīdziniet alternatīvos ietvarus un atlasiet to, ar kuru visvienkāršāk ir izveidot
4. Izstrādājiet kodu pakāpeniski un bieži refaktors
5. Satiecieties ar ietvara lietotājiem un regulāri vāciet atsauksmes
6. Pārbaudi, pārbaudi, pārbaudi

1. solis. Nosakiet vienkāršus mērķus

Ir vilinoši izvirzīt ambiciozus mērķus un ieviest progresīvu sistēmu, kas atrisina visas problēmas. Ja jums ir pietiekami resursi, tā nav slikta ideja. Parasti ietvara izstrāde savam projektam tiek uzskatīta par vispārēju cenu, kas nesniedz taustāmu biznesa vērtību. Sākot ar mazāku, jūs varat samazināt neparedzētos riskus, izbaudīt mazāk izstrādes laika, pazemināt mācīšanās līkni un iegūt projekta ieinteresēto personu dalību. Operētājsistēmai X18p es izvirzīju tikai divus mērķus, pamatojoties uz iepriekšējām tikšanās reizēm ar J2EE kodu:

1. Samaziniet J2EE Darbība koda savienošana
2. Samaziniet koda atkārtošanos J2EE DAO slānī

Kopumā es vēlos nodrošināt labākas kvalitātes kodu un samazināt kopējās izstrādes un uzturēšanas izmaksas, palielinot savu produktivitāti. Līdz ar to mēs izietam divas 2. līdz 6. soļa atkārtojumus, lai sasniegtu šos mērķus.

Samaziniet kodu sasaisti

2. darbība. Analizējiet iepriekšējās J2EE lietojumprogrammas arhitektūru

Ja ir izveidota J2EE lietojumprogrammu sistēma, mums vispirms ir jāskatās, kā to var uzlabot. Acīmredzot, sākot no nulles, nav jēgas. Attiecībā uz X18p apskatīsim tipisku J2EE Struts lietojumprogrammas piemēru, kas parādīts 1. attēlā.

Darbība zvani XXXManager, un XXXManager zvani XXXDAOs. Tipiskā J2EE dizainā, kas ietver statņus, mums ir šādi priekšmeti:

• HttpServlet vai Struts Darbība slānis, kas rīkojas HttpRequest un HttpResponse
• Biznesa loģikas slānis
• Datu piekļuves slānis
• Domēna slānis, kas piesaista domēna entītijas

Kas nepareizi ar iepriekš minēto arhitektūru? Atbilde: cieša sakabe. Arhitektūra darbojas lieliski, ja tajā ir loģika Darbība ir vienkārši. Bet ko tad, ja jums ir nepieciešams piekļūt daudziem EJB (Enterprise JavaBeans) komponentiem? Ko darīt, ja jums ir nepieciešams piekļūt tīmekļa pakalpojumiem no dažādiem avotiem? Ko darīt, ja jums ir nepieciešams piekļūt JMX (Java Management Extensions)? Vai Struts ir rīks, kas palīdz jums meklēt šos resursus no struts-config.xml failu? Atbilde ir nē. Struts ir paredzēts tikai tīmekļa līmeņa ietvars. Ir iespējams kodēt Darbības kā dažādi klienti un izsauc aizmuguri, izmantojot Service Locator modeli. Tomēr, šādi rīkojoties, tiks sajaukti divi dažādi kodu veidi Darbība's izpildīt() metodi.

Pirmais koda veids attiecas uz tīmekļa līmeni HttpRequest/HttpResponse. Piemēram, kods izgūst HTTP veidlapas datus no ActionForm vai HttpRequest. Jums ir arī kods, kas iestata datus HTTP pieprasījumā vai HTTP sesijā un pārsūta tos uz JSP (JavaServer Pages) lapu, lai to parādītu.

Otrais koda tips tomēr attiecas uz uzņēmējdarbības līmeni. In Darbība, jūs arī izsaucat aizmugures kodu, piemēram, EJBObject, JMS (Java Message Service) tēmu vai pat JDBC (Java Database Connectivity) datu avotus un iegūstiet rezultātu datus no JDBC datu avotiem. Pakalpojuma meklētāja modeli jūs varat izmantot Darbība lai palīdzētu jums veikt meklēšanu. Tas ir iespējams arī Darbība atsauce tikai uz vietējo POJO (vienkāršs vecs Java objekts) xxxManager. Neskatoties uz to, aizmugures objekts vai xxxManagertiek pakļauti metodes līmeņa parakstiem Darbība.

Tā Darbība darbojas, vai ne? Raksturs Darbība ir servleta, kurai vajadzētu rūpēties par to, kā iegūt datus no HTML un iestatīt datus HTML formātā ar HTTP pieprasījumu / sesiju. Tas arī saskaras ar biznesa loģikas slāni, lai iegūtu vai atjauninātu datus no šī slāņa, bet kādā formā vai protokolā, Darbība varētu rūpēties mazāk.

Kā jūs varat iedomāties, kad pieaug Struts lietojumprogramma, starp tām var būt ciešas atsauces Darbības (tīmekļa līmenis) un biznesa vadītāji (biznesa līmenis) (skatiet sarkanās līnijas un bultiņas 1. attēlā).

Lai atrisinātu šo problēmu, mēs varam apsvērt atvērto sistēmu tirgū - ļaujiet tām iedvesmot mūsu pašu domāšanu, pirms mēs ietekmējam. Pavasara ietvars parādās manā radara ekrānā.

3. solis. Salīdziniet alternatīvos ietvarus

Pavasara pamatprogrammas kodols ir koncepcija, ko sauc Pupiņu rūpnīca, kas ir laba uzmeklēšanas rūpnīcas ieviešana. Tas atšķiras no pakalpojuma meklētāja modeļa, jo tajā ir iepriekš saukta vadības inversijas (IoC) funkcija Injekcijas atkarība. Ideja ir iegūt objektu, piezvanot savam ApplicationContext's getBean () metodi. Šī metode meklē objekta definīciju pavasara konfigurācijas failu, izveido objektu un atgriež a java.lang.Object objekts. getBean () ir piemērots objektu meklēšanai. Izskatās, ka tikai viena objekta atsauce, ApplicationContext, jābūt atsaucei uz Darbība. Tomēr tas tā nav, ja mēs to izmantojam tieši Darbība, jo mums ir jāizmet getBean ()Atgriež objekta tipu atpakaļ EJB / JMX / JMS / Web pakalpojuma klientam. Darbība joprojām ir jāapzinās aizmugures objekts metodes līmenī. Cieša sakabe joprojām pastāv.

Ja mēs vēlamies izvairīties no objekta-metodes līmeņa atsauces, ko vēl mēs varam izmantot? Protams, apkalpošana, nāk prātā. Apkalpošana ir visuresošs, bet neitrāls jēdziens. Jebkurš pakalpojums var būt ne tikai tā sauktie tīmekļa pakalpojumi. Darbība var arī bezpakāpju sesijas pupiņu metodi uzskatīt par pakalpojumu. Tas var uzskatīt JMS tēmas izsaukšanu arī par pakalpojuma patērēšanu. Tas, kā mēs veidojam pakalpojumu patērēšanu, var būt ļoti vispārīgs.

Izmantojot iepriekš minēto analīzi un salīdzinājumu, izstrādājot stratēģiju, pamanot bīstamību un mazinot risku, mēs varam stimulēt savu radošumu un pievienot plānu pakalpojumu brokera slāni, lai parādītu uz pakalpojumu orientētu koncepciju.

4. solis. Attīstīt un refaktors

Lai ieviestu uz pakalpojumu orientētas koncepcijas domāšanu kodā, mums jāņem vērā sekojošais:

• Pakalpojuma starpnieka slānis tiks pievienots starp tīmekļa līmeni un biznesa līmeni.
• Konceptuāli an Darbība zvana tikai biznesa pakalpojuma pieprasījumam, kas pieprasījumu nodod pakalpojumu maršrutētājam. Pakalpojuma maršrutētājs zina, kā piesaistīt biznesa pakalpojumu pieprasījumus dažādiem pakalpojumu sniedzēju kontrolieriem vai adapteriem, meklējot pakalpojuma kartēšanas XML failu, X18p-config.xml.
• Pakalpojumu sniedzēja kontrolierim ir īpašas zināšanas par pamata uzņēmējdarbības pakalpojumu atrašanu un izsaukšanu. Šeit biznesa pakalpojumi var būt jebkas, sākot no POJO, LDAP (viegls direktoriju piekļuves protokols), EJB, JMX, COM un tīmekļa pakalpojumiem līdz COTS (komerciāls bez plaukta) produktu API. X18p-config.xml jāsniedz pietiekami daudz datu, lai pakalpojumu sniedzēja kontrolieris varētu paveikt darbu.
• Izmantojiet pavasari X18p iekšējo objektu meklēšanai un atsaucēm.
• Pakalpojumu sniedzēju kontrolierus veidojiet pakāpeniski. Kā redzēsit, jo vairāk tiek ieviesti pakalpojumu sniedzēju kontrolieri, jo lielāka ir X18p integrācijas jauda.
• Aizsargājiet esošās zināšanas, piemēram, Struts, taču uzmaniet acis jaunām lietām.

Tagad mēs salīdzinām Darbība kods pirms un pēc uz pakalpojumu orientēta X18p ietvara piemērošanas:

Struts darbība bez X18p

 public ActionForward izpildīt (ActionMapping kartēšana, ActionForm forma, HttpServletRequest pieprasījums, HttpServletResponse atbilde) met IOException, ServletException {... UserManager userManager = new UserManager (); Virkne userIDRetured = userManager.addUser ("Džons Smits") ...} 

Struts darbība ar X18p

public ActionForward izpildīt (ActionMapping kartēšana, ActionForm forma, HttpServletRequest pieprasījums, HttpServletResponse atbilde) met IOException, ServletException {... ServiceRequest bsr = this.getApplicationContext (). getBean ("businessServiceRequest"); bsr.setServiceName ("Lietotāju pakalpojumi"); bsr.setOperation ("addUser"); bsr.addRequestInput ("param1", "addUser"); Virkne userIDRetured = (virkne) bsr.service (); ...} 

Pavasaris atbalsta biznesa pakalpojumu pieprasījumu un citu objektu, tostarp POJO vadītāju, ja tādi ir, meklēšanu.

2. attēlā parādīts, kā pavasara konfigurācijas fails, applicationContext.xml, atbalsta vietnes meklēšanu businessServiceRequest un serviceRouter.

In ServiceRequest.java, apkalpošana() metode vienkārši izsauc Spring, lai atrastu pakalpojumu maršrutētāju, un nodod sevi maršrutētājam:

 public Object service () {return ((ServiceRouter) this.serviceContext.getBean ("pakalpojumu maršrutētājs")). maršruts (šis); } 

Pakalpojuma maršrutētājs X18p maršrutē lietotāju pakalpojumus biznesa loģikas slānī ar X18p-config.xmlpalīdzība. Galvenais ir tas, ka Darbība kodam nav jāzina, kur un kā tiek ieviesti lietotāju pakalpojumi. Tam jāzina tikai noteikumi par pakalpojuma patērēšanu, piemēram, parametru nospiešana pareizā secībā un pareizā atgriešanas veida liešana.

3. Attēlā parādīts X18p-config.xml kas sniedz pakalpojumu kartēšanas informāciju, kas ServiceRouter meklēs X18p.

Lietotāju pakalpojumiem pakalpojuma veids ir POJO. ServiceRouter izveido POJO pakalpojumu sniedzēja kontrolieri, kas apstrādā pakalpojuma pieprasījumu. Šis POJO's springObjectId ir userServiceManager. POJO pakalpojumu sniedzēja kontrolieris izmanto Spring, lai meklētu šo POJO ar springObjectId. Kopš userServiceManager norāda uz klases tipu X18p.framework.UserPOJOManager, LietotājsPOJOManager klase ir lietojumprogrammas loģiskais kods.

Pārbaudiet ServiceRouter.java:

 public Object route (ServiceRequest serviceRequest) izmet izņēmumu {// / 1. Izlasiet visu kartēšanu no XML faila vai izgūstiet to no rūpnīcas // Config config = xxxx; // 2. Iegūstiet pakalpojuma tipu no config. Virkne businessServiceType = Config.getBusinessServiceType (serviceRequest.getServiceName ()); // 3. Atlasiet atbilstošo maršrutētāju / apstrādātāju / kontrolieri, lai ar to rīkotos. 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 (galapunkts); ws.process (serviceRequest); } else if (businessServiceType.equalsIgnoreCase ("EJB")) {EJBController ejbController = (EJBController) Config.getBean ("EJBController"); ejbController.process (serviceRequest); } else {// TODO System.out.println ("Nezināmi veidi, jums ir atkarīgs, kā ar to rīkoties sistēmā"); } // Tas ir viss, tas ir jūsu ietvars, jūs varat pievienot jebkuru jaunu ServiceProvider savam nākamajam projektam. return null; } 

Iepriekš minēto maršrutēšanu if-else bloku varētu pārveidot par komandu modeli. The Konfigurēt objekts nodrošina Spring un X18p XML konfigurācijas uzmeklēšanu. Kamēr var iegūt derīgus datus, atkarīgs no tā, kā ieviest uzmeklēšanas mehānismu.

Pieņemot, ka POJO vadītājs, TestPOJOBusinessManager, tiek ieviests POJO pakalpojumu sniedzēja kontrolieris (POJOServiceController.java), tad meklē addUser () metode no TestPOJOBusinessManager un izsauc to ar pārdomām (skat. kodu, kas pieejams resursos).

Ieviešot trīs klases (BusinessServiceRequester, ServiceRouter, un ServiceProviderController) plus viens XML konfigurācijas fails, mums ir uz pakalpojumu orientēta sistēma kā koncepcijas pierādījums. Šeit Darbība nav zināšanu par pakalpojuma ieviešanu. Tas rūpējas tikai par ievadi un izvadi.

Dažādu API un programmēšanas modeļu izmantošanas sarežģītība dažādu pakalpojumu sniedzēju integrēšanai ir pasargāta no Struts izstrādātājiem, kuri strādā tīmekļa līmenī. Ja X18p-config.xml ir paredzēts jau sākotnēji kā pakalpojumu līgums, Struts un aizmugures izstrādātāji var strādāt vienlaikus ar līgumu.

4. attēlā parādīts arhitektūras jaunais izskats.

Es apkopoju kopīgos pakalpojumu sniedzēju kontrolierus un ieviešanas stratēģijas 1. tabulā. Jūs varat viegli pievienot vairāk.

1. tabula. Kopējo pakalpojumu sniedzēju kontrolieru ieviešanas stratēģijas