Programmēšana

Izmantojiet Spring, lai izveidotu vienkāršu darbplūsmas motoru

Daudzām Jave uzņēmuma lietojumprogrammām ir nepieciešama apstrāde, kas jāveic atsevišķi no galvenās sistēmas. Daudzos gadījumos šie aizmugures procesi veic vairākus uzdevumus, no kuriem daži ir atkarīgi no iepriekšējā uzdevuma statusa. Ar prasību par savstarpēji atkarīgiem apstrādes uzdevumiem ieviešana, izmantojot vienu procesuāla stila metožu izsaukumu kopumu, parasti izrādās nepietiekama. Izmantojot Spring, izstrādātājs var viegli sadalīt aizmugures procesu darbību kopumā. Pavasara konteiners pievienojas šīm darbībām, veidojot a vienkārša darbplūsma.

Šī raksta vajadzībām vienkārša darbplūsma ir definēts kā jebkurš darbību kopums, kas veikts iepriekš noteiktā secībā bez lietotāja mijiedarbības. Šī pieeja tomēr netiek piedāvāta kā aizstājējs esošajām darbplūsmas sistēmām. Scenārijos, kur nepieciešama progresīvāka mijiedarbība, piemēram, dakšas, pievienošanās vai pārejas, pamatojoties uz lietotāja ievadītu informāciju, ir labāk aprīkots atsevišķs atvērtā koda vai komerciāls darbplūsmas motors. Vienā atvērtā koda projektā ir veiksmīgi integrēts sarežģītāks darbplūsmas dizains ar Spring.

Ja attiecīgie darbplūsmas uzdevumi ir vienkāršoti, vienkāršai darbplūsmas pieejai ir jēga pretstatā pilnībā funkcionējošai atsevišķai darbplūsmas sistēmai, it īpaši, ja pavasaris jau tiek izmantots, jo ātra ieviešana tiek garantēta, neizmantojot uzlaides laiku. Turklāt, ņemot vērā Spring vieglā konteinera Inversion-of-Control raksturu, Spring samazina resursu pieskaitāmās izmaksas.

Šis raksts īsumā iepazīstina ar darbplūsmu kā programmēšanas tēmu. Izmantojot darbplūsmas jēdzienus, Spring tiek izmantots kā pamats darbplūsmas motora vadīšanai. Tad tiek apspriestas ražošanas izvietošanas iespējas. Sāksim ar ideju par vienkāršu darbplūsmu, koncentrējoties uz darbplūsmas noformējuma modeļiem un ar tiem saistīto pamatinformāciju.

Vienkārša darbplūsma

Darbplūsmas modelēšana ir tēma, kas tika pētīta jau pagājušā gadsimta 70. gados, un daudzi izstrādātāji ir mēģinājuši izveidot standartizētu darbplūsmas modelēšanas specifikāciju. Darbplūsmas modeļi, baltā grāmata, ko sagatavoja W.H.M. van der Alsts u.c. (2003. gada jūlijs), ir izdevies klasificēt dizaina modeļu kopumu, kas precīzi modelē visbiežāk sastopamos darbplūsmas scenārijus. Starp visbūtiskākajiem darbplūsmas modeļiem ir secības modelis. Atbilstoši vienkāršas darbplūsmas kritērijiem, secības darbplūsmas modelis sastāv no secīgi izpildītu darbību kopuma.

UML (Unified Modeling Language) darbības diagrammas parasti izmanto kā mehānismu darbplūsmas modelēšanai. 1. attēlā parādīts pamata secības darbplūsmas process, kas modelēts, izmantojot standarta UML darbību diagrammu.

Secības darbplūsma ir standarta darbplūsmas modelis, kas izplatīts J2EE lietojumprogrammās. J2EE lietojumprogrammai parasti ir nepieciešama notikumu secība, kas notiek fona pavedienā vai asinhroni. 2. attēla darbības shēma parāda vienkāršu darbplūsmu, lai informētu ieinteresētos ceļotājus, ka aviobiļetes uz viņu iecienīto galamērķi ir samazinājušās.

Aviokompānijas darbplūsma 1. attēlā ir atbildīga par dinamisku e-pasta paziņojumu izveidošanu un nosūtīšanu. Katrs procesa posms apzīmē darbību. Pirms darbplūsmas sākšanas ir jānotiek kādam ārējam notikumam. Šajā gadījumā šis notikums ir likmes samazinājums aviokompānijas lidojuma maršrutam.

Apskatīsim aviosabiedrību darbplūsmas biznesa loģiku. Ja pirmās darbības laikā netiek atrasti lietotāji, kurus interesē paziņojumi par likmes kritumu, visa darbplūsma tiek atcelta. Ja tiek atklāti ieinteresēti lietotāji, pārējās darbības tiek pabeigtas. Pēc tam XSL (paplašināmās stila lapas valoda) transformācija ģenerē ziņojuma saturu, pēc kura tiek ierakstīta audita informācija. Visbeidzot, tiek mēģināts nosūtīt ziņojumu, izmantojot SMTP serveri. Ja iesniegšana tiek pabeigta bez kļūdām, panākumi tiek reģistrēti un process tiek pārtraukts. Bet, ja, sazinoties ar SMTP serveri, rodas kļūda, pārņems īpaša kļūdu apstrādes kārtība. Šis kļūdu apstrādes kods mēģinās atkārtoti nosūtīt ziņojumu.

Ņemot vērā aviokompānijas piemēru, ir skaidrs viens jautājums: Kā jūs varētu efektīvi sadalīt secīgu procesu atsevišķās darbībās? Šī problēma tiek daiļrunīgi risināta, izmantojot Spring. Ātri apspriedīsim pavasari kā vadības struktūras inversiju.

Invertēšanas vadība

Pavasaris ļauj mums noņemt pienākumu kontrolēt objekta atkarības, pārvietojot šo atbildību uz pavasara konteineru. Šī atbildības nodošana ir pazīstama kā vadības inversija (IoC) vai atkarības injekcija. Padziļinātākas diskusijas par IoC un Atkarības injicēšanu skatiet Martina Faulera grāmatā "Kontroles konteineru inversija un atkarības injekcijas modelis" (martinfowler.com, 2004. gada janvāris). Pārvaldot atkarību starp objektiem, Pavasaris novērš nepieciešamību pēc līmes kods, kods, kas rakstīts tikai nolūkā panākt, lai klases sadarbotos savā starpā.

Darbplūsmas komponenti kā pavasara pupiņas

Pirms mēs esam nonākuši pārāk tālu, tagad ir piemērots laiks, lai iepazītos ar galvenajiem pavasara jēdzieniem. The ApplicationContext interfeiss, mantojot no Pupiņu rūpnīca interfeisu, uzliek sevi par faktisko kontrolējošo vienību vai konteineru Springā. The ApplicationContext ir atbildīgs par pupiņu komplekta, kas pazīstams kā., instantēšanu, konfigurēšanu un dzīves cikla pārvaldību Pavasara pupiņas. The ApplicationContext ir konfigurējis elektroinstalācija Pavasara pupiņas XML bāzes konfigurācijas failā. Šis konfigurācijas fails nosaka veidu, kādā pavasara pupiņas sadarbojas savā starpā. Tādējādi pavasarī runājot, pavasara pupiņas, kas mijiedarbojas ar citiem, ir pazīstamas kā līdzstrādnieki. Pēc noklusējuma pavasara pupiņas ir vienspēlītes ApplicationContext, bet vienreizējo atribūtu var iestatīt uz nepatiesu, efektīvi mainot tos uz uzvedību pavasara aicinājumā prototips režīmā.

Atgriežoties pie mūsu piemēra, samazinoties aviobiļešu cenai, SMTP sūtīšanas rutīnas abstrakcija tiek vadīta kā pēdējā darbība darbplūsmas procesa piemērā (kodā piemērs ir pieejams resursos). Tā kā šī pupiņa ir piektā darbība, tā tiek pareizi nosaukta aktivitāte5. Lai nosūtītu ziņu, aktivitāte5 nepieciešams delegāta līdzstrādnieks un kļūdu apstrādātājs:

Darbplūsmas komponentu ieviešana kā pavasara pupiņas rada divus vēlamus blakusproduktus, vienkāršu vienības testēšanu un lielu atkārtotas izmantošanas pakāpi. Efektīva vienību pārbaude ir acīmredzama, ņemot vērā IoC konteineru raksturu. Izmantojot IoC konteineru, piemēram, Spring, līdzstrādnieka atkarības testēšanas laikā var viegli nomainīt ar izspēles aizstājējiem. Aviokompānijas piemērā Aktivitāte Pavasara pupas, piemēram aktivitāte5 var viegli izgūt no atsevišķa testa ApplicationContext. Smieklīga SMTP delegāta aizstāšana ar aktivitāte5 ļauj veikt vienības pārbaudi aktivitāte5 atsevišķi.

Otro blakusproduktu - atkārtotu izmantošanu - realizē tādas darbplūsmas darbības kā XSL pārveidošana. XSL transformāciju, kas saīsināta darbplūsmas darbībā, tagad var atkārtoti izmantot jebkura darbplūsma, kas nodarbojas ar XSL transformācijām.

Darbplūsmas pieslēgšana

Iesniegtajā API (lejupielādējams no resursiem) Spring kontrolē nelielu spēlētāju kopumu, lai tie mijiedarbotos tādā veidā, kas veido darbplūsmu. Galvenās saskarnes ir:

  • Aktivitāte: Ietver darbplūsmas viena soļa biznesa loģiku.
  • ProcessContext: Tipa objekti ProcessContext tiek nodotas starp darbībām darbplūsmā. Objekti, kas ievieš šo saskarni, ir atbildīgi par stāvokļa saglabāšanu, darbplūsmai pārejot no vienas darbības uz nākamo.
  • ErrorHandler: Nodrošina atzvana metodi kļūdu apstrādei.
  • Procesors: Apraksta pupiņu, kas kalpo kā galvenā darbplūsmas pavediena izpildītāja.

Šis koda parauga fragments ir pavasara pupiņu konfigurācija, kas saista aviokompānijas piemēru kā vienkāršu darbplūsmas procesu.

             / property> org.iocworkflow.test.sequence.ratedrop.RateDropContext 

The SequenceProcessor klase ir konkrēta apakšklase, kas modelē secības modeli. Procesoram ir pievienotas piecas darbības, kuras darbplūsmas procesors veiks secībā.

Salīdzinot ar lielāko procesuālo aizmugures procesu, darbplūsmas risinājums patiešām izceļas ar to, ka tas spēj ļoti efektīvi apstrādāt kļūdas. Kļūdu apstrādātājs var būt atsevišķi pieslēgts katrai darbībai. Šis apstrādes veids nodrošina precīzu kļūdu apstrādi individuālās darbības līmenī. Ja kādai darbībai nav pievienots kļūdu apstrādātājs, problēmu novērsīs vispārējam darbplūsmas procesoram definētais kļūdu apstrādātājs. Šajā piemērā, ja darbplūsmas procesa laikā rodas neapstrādāta kļūda, tā tiks izplatīta, lai to varētu apstrādāt ErrorHandler pupiņu, kas ir savienota ar vadu defaultErrorHandler īpašums.

Sarežģītākas darbplūsmas ietvari saglabājas datu krātuvē starp pārejām. Šajā rakstā mūs interesē tikai vienkārši darbplūsmas gadījumi, kad stāvokļa pāreja ir automātiska. Informācija par valsti ir pieejama tikai ProcessContext faktiskās darbplūsmas izpildlaika laikā. Jums ir tikai divas metodes, jūs varat redzēt ProcessContext interfeiss ir uzturs:

publiskā saskarne ProcessContext paplašina Serializable {public boolean stopProcess (); public void setSeedData (Object seedObject); }

Betons ProcessContext klase, ko izmanto aviosabiedrības darba plūsmas piemērā, ir RateDropContext klasē. The RateDropContext klase apkopo datus, kas nepieciešami, lai izpildītu aviokompānijas ātruma krituma darbplūsmu.

Līdz šim visi pupiņu gadījumi pēc noklusējuma ir bijuši atsevišķi ApplicationContextuzvedība. Bet mums ir jāizveido jauna RateDropContext klase par katru aviosabiedrības darbplūsmas piesaukšanu. Lai izpildītu šo prasību, SequenceProcessor ir konfigurēts, kā pilnu klases nosaukumu ņemot processContextClass īpašums. Katrai darbplūsmas izpildei SequenceProcessor izgūst jaunu ProcessContext no pavasara, izmantojot norādīto klases nosaukumu. Lai tas darbotos, vienreizējas pavasara pupas vai prototips veida org.iocworkflow.test.sequence.simple.SimpleContext jāpastāv ApplicationContext (skat rateDrop.xml visā sarakstā).

Darbplūsmas sēšana

Tagad, kad mēs zinām, kā apkopot vienkāršu darbplūsmu, izmantojot pavasari, pievērsīsimies instantifikācijai, izmantojot sēklas datus. Lai saprastu, kā sākt darbplūsmu, apskatīsim metodes, kas tiek pakļautas faktiskajam Procesors interfeiss:

publiskā saskarne Procesors {public boolean support (Darbības aktivitāte); public void doActivities (); public void doActivities (Object seedData); public void setActivities (Saraksta darbības); public void setDefaultErrorHandler (ErrorHandler defaultErrorHandler); }

Vairumā gadījumu darbplūsmas procesiem ir nepieciešami daži sākotnējie stimuli. Procesora sākšanai ir divas iespējas: doActivities (Object seedData) metodi vai tās alternatīvu bez argumentiem. Šis kodu saraksts ir doAcvtivities () ieviešana SequenceProcessor iekļauts koda paraugā:

 public void doActivities (Object seedData) {if (logger.isDebugEnabled ()) logger.debug (getBeanName () + "darbojas procesors .."); // izgūt, ko injicēja Spring List aktivitātes = getActivities (); // izgūt jaunu Workflow ProcessContext ProcessContext context instanci = createContext (); if (seedData! = null) context.setSeedData (seedData); par (Iterator it = aktivitātes.iterator (); it.hasNext ();) {Aktivitātes aktivitāte = (Aktivitāte) it.next (); if (logger.isDebugEnabled ()) logger.debug ("darbojas darbība:" + aktivitāte.getBeanName () + ", izmantojot argumentus:" + konteksts); mēģiniet {context = activity.execute (context); } catch (Throwable th) {ErrorHandler errorHandler = aktivitāte.getErrorHandler (); if (errorHandler == null) {logger.info ("šai darbībai nav kļūdu apstrādātāja, palaidiet noklusējuma kļūdu" + "apstrādātājs un pārtrauciet apstrādi"); getDefaultErrorHandler (). handError (konteksts, th); pārtraukums; } else {logger.info ("palaist kļūdu apstrādātāju un turpināt"); errorHandler.handleError (konteksts, th); }} 
$config[zx-auto] not found$config[zx-overlay] not found