Daugelis „Jave“ įmonės programų reikalauja, kad apdorojimas būtų vykdomas atskirai nuo pagrindinės sistemos. Daugeliu atvejų šie vidiniai procesai atlieka kelias užduotis, kai kurios užduotys priklauso nuo ankstesnės užduoties būsenos. Reikalaujant tarpusavyje susijusių apdorojimo užduočių, įgyvendinimas naudojant vieną procedūrinio stiliaus metodų iškvietimų rinkinį dažniausiai pasirodo nepakankamas. Naudodamas „Spring“, kūrėjas gali lengvai atskirti programinės įrangos procesą į visumą veiklų. Pavasario konteineris sujungia tą veiklą ir sudaro a paprastas darbo eiga.
Šio straipsnio tikslais paprastas darbo eiga apibrėžiamas kaip bet koks veiklos rinkinys, atliekamas iš anksto nustatyta tvarka be vartotojo sąveikos. Tačiau šis metodas nėra siūlomas pakeisti esamas darbo eigos sistemas. Tais atvejais, kai reikalinga pažangesnė sąveika, pvz., Šakojimasis, prisijungimas ar perėjimai, pagrįsti vartotojo įvestimi, yra geriau įrengtas atskiras atvirojo kodo arba komercinis darbo eigos variklis. Viename atvirojo kodo projekte sėkmingai integruotas sudėtingesnis darbo eigos dizainas su „Spring“.
Jei nagrinėjamos darbo eigos užduotys yra paprastos, paprastas darbo eigos metodas yra prasmingas, palyginti su visiškai veikiančia atskira darbo eigos sistema, ypač jei jau naudojama „Spring“, nes greitas įgyvendinimas garantuojamas be perėjimo laiko. Be to, atsižvelgiant į „Spring“ lengvo konteinerio „inversija - valdymas“ pobūdį, „Spring“ sumažina išteklių sąnaudas.
Šiame straipsnyje trumpai pristatoma darbo eiga kaip programavimo tema. Naudojant darbo eigos koncepcijas, „Spring“ naudojama kaip darbo eigos variklio pagrindas. Tada aptariami gamybos diegimo variantai. Pradėkime nuo paprastos darbo eigos idėjos, sutelkdami dėmesį į darbo eigos dizaino modelius ir susijusią pagrindinę informaciją.
Paprasta darbo eiga
Modeliavimo darbo eiga yra tema, kuri buvo nagrinėjama dar aštuntajame dešimtmetyje, ir daugelis kūrėjų bandė sukurti standartizuotą darbo eigos modeliavimo specifikaciją. Darbo eigos modeliai, baltas W.H.M. van der Aalst ir kt. (2003 m. Liepos mėn.) Pavyko klasifikuoti dizaino modelių rinkinį, kuris tiksliai modeliuotų dažniausiai pasitaikančius darbo eigos scenarijus. Tarp nereikšmingiausių darbo eigos modelių yra sekos modelis. Atitinkant paprastos darbo eigos kriterijus, sekos darbo eigos modelį sudaro nuosekliai vykdomų veiklų rinkinys.
UML (Unified Modeling Language) veiklos diagramos dažniausiai naudojamos kaip darbo eigos modeliavimo mechanizmas. 1 paveiksle parodytas pagrindinis sekos darbo eigos procesas, sumodeliuotas naudojant standartinę UML veiklos diagramą.
Sekos darbo eiga yra standartinis darbo eigos modelis, paplitęs J2EE programose. J2EE programa paprastai reikalauja, kad įvykių seka vyktų foninėje gijoje arba asinchroniškai. 2 paveikslo veiklos diagrama iliustruoja paprastą darbo eigą pranešant susidomėjusiems keliautojams, kad lėktuvų bilietai į jų mėgstamą vietą sumažėjo.
1 paveiksle nurodytos aviakompanijos darbo eiga yra atsakinga už dinamiškų el. Pašto pranešimų kūrimą ir siuntimą. Kiekvienas proceso etapas reiškia veiklą. Prieš pradedant darbo eigą, turi įvykti tam tikras išorinis įvykis. Šiuo atveju tas įvykis yra aviakompanijos skrydžio maršruto sumažėjimas.
Apžvelkime oro linijų darbo eigos verslo logiką. Jei pirmoji veikla neranda vartotojų, besidominčių pranešimais apie normos sumažėjimą, visa darbo eiga atšaukiama. Jei aptinkama susidomėjusių vartotojų, atliekama kita veikla. Vėliau XSL (Extensible Stylesheet Language) transformacija sukuria pranešimo turinį, po kurio įrašoma audito informacija. Galiausiai bandoma išsiųsti pranešimą per SMTP serverį. Jei pateikimas baigiamas be klaidų, sėkmė registruojama ir procesas baigiamas. Bet jei bendraujant su SMTP serveriu įvyksta klaida, perims speciali klaidų tvarkymo procedūra. Šis klaidų tvarkymo kodas bandys išsiųsti pranešimą iš naujo.
Atsižvelgiant į aviakompanijos pavyzdį, akivaizdus vienas klausimas: kaip galėtumėte efektyviai suskaidyti nuoseklų procesą į atskirą veiklą? Ši problema iškalbingai sprendžiama naudojant „Spring“. Greitai aptarkime pavasarį kaip valdymo sistemos inversiją.
Apversmas valdymas
Pavasaris leidžia mums pašalinti atsakomybę kontroliuoti objekto priklausomybes, perkeliant šią atsakomybę į „Spring“ konteinerį. Šis atsakomybės perdavimas yra žinomas kaip valdymo inversija (IoC) arba priklausomybės injekcija. Žr. Martino Fowlerio „Kontrolinių konteinerių ir priklausomybės injekcijos modelio inversija“ (martinfowler.com, 2004 m. Sausio mėn.) Išsamesnę diskusiją apie IoC ir priklausomybės injekciją. Tvarkydamas priklausomybę tarp objektų, Springas nebereikia klijų kodas, kodas, parašytas tik tam, kad klasės bendradarbiautų.
Darbo eigos komponentai kaip vasarinės pupelės
Kol dar nepasiekėme per toli, dabar yra tinkamas metas apžvelgti pagrindines pavasario idėjas. „ApplicationContext“ sąsaja, paveldima iš Pupelių fabrikas sąsają, save pristato kaip tikrąjį „Spring“ kontroliuojantį subjektą ar konteinerį. „ApplicationContext“ yra atsakingas už pupelių rinkinio, žinomo kaip., paruošimą, konfigūravimą ir gyvavimo ciklo valdymą Vasarinės pupelės. „ApplicationContext“ yra sukonfigūruotas laidų Vasarinės pupelės XML konfigūracijos faile. Šis konfigūracijos failas diktuoja vasarinių pupelių tarpusavio bendradarbiavimo pobūdį. Taigi, pavasarį kalbant, vasarinės pupelės, kurios bendrauja su kitais, yra žinomos kaip bendradarbiai. Pagal numatytuosius nustatymus vasarinės pupelės yra vienintelės „ApplicationContext“, tačiau pavienį atributą galima nustatyti kaip klaidingą, veiksmingai pakeičiant juos taip, kad elgtųsi tai, ką ragina pavasaris prototipas režimas.
Grįžtant prie mūsų pavyzdžio, sumažėjus lėktuvų bilietams, SMTP siuntimo rutinos abstrakcija yra prijungiama kaip paskutinė veikla darbo eigos proceso pavyzdyje (kodo pavyzdys, esantis šaltiniuose). Būdama penktoji veikla, ši pupelė yra tinkamai pavadinta veikla5. Norėdami išsiųsti pranešimą, veikla5 reikalingas įgaliotas bendradarbis ir klaidų tvarkytojas:
Įgyvendinant darbo eigos komponentus kaip vasarines pupeles gaunami du pageidaujami šalutiniai produktai, paprastas vieneto bandymas ir didelis pakartotinio naudojimo laipsnis. Efektyvus vieneto bandymas akivaizdus atsižvelgiant į IoC talpyklų pobūdį. Naudojant IoC konteinerį, pvz., „Spring“, bandymo metu priklausomybes nuo bendradarbių galima lengvai pakeisti pakaitiniais pakeitimais. Oro linijų pavyzdyje Veikla Pavasarinės pupelės, tokios kaip veikla5 galima lengvai gauti iš atskiro testo „ApplicationContext“. Imituojančio SMTP delegato pakeitimas į veikla5 leidžia atlikti bandymą vienetais veikla5 atskirai.
Antrasis šalutinis produktas - pakartotinis naudojimas - realizuojamas vykdant darbo eigą, pvz., XSL transformaciją. XSL transformaciją, suskaidytą į darbo eigos veiklą, dabar gali pakartotinai naudoti bet kuri su XSL transformacijomis susijusi darbo eiga.
Darbo eigos prijungimas
Pateiktoje API (atsisiųsti iš išteklių) „Spring“ valdo nedidelį žaidėjų rinkinį, kad jie galėtų sąveikauti tokiu būdu, kuris sudaro darbo eigą. Pagrindinės sąsajos yra:
Veikla: Apibendrina vieno darbo eigos proceso verslo logiką.„ProcessContext“: Tipo objektai„ProcessContext“yra perduodami tarp veiklos eigos. Objektai, įgyvendinantys šią sąsają, yra atsakingi už būsenos palaikymą, kai darbo eiga pereina iš vienos veiklos į kitą.„ErrorHandler“: Pateikia atgalinio skambinimo metodą klaidoms tvarkyti.Procesorius: Apibūdina pupelę, kuri yra pagrindinės darbo eigos gijos vykdytojas.
Ši pavyzdžio kodo ištrauka yra „Spring pupelių“ konfigūracija, susiejanti aviakompanijos pavyzdį kaip paprastą darbo eigos procesą.
/ nuosavybė> org.iocworkflow.test.sequence.ratedrop.RateDropContext Procesorius klasė yra konkretus poklasis, kuris modeliuoja sekos modelį. Prie procesoriaus prijungtos penkios veiklos, kurias eilės tvarka vykdys darbo eigos procesorius.
Palyginus su daugeliu procedūrinių vidinių procesų, darbo eigos sprendimas iš tiesų išsiskiria tuo, kad gali labai patikimai valdyti klaidas. Klaidų tvarkytuvas gali būti atskirai prijungtas prie kiekvienos veiklos. Šio tipo tvarkytojai teikia smulkų klaidų tvarkymą individualios veiklos lygiu. Jei veiklai nėra prijungtas klaidų tvarkytuvas, problemą spręs klaidų tvarkytuvas, apibrėžtas visam darbo eigos procesoriui. Šiame pavyzdyje, jei bet kurio darbo eigos proceso metu įvyksta neapdorota klaida, ji bus išplinta, kad ją galėtų tvarkyti „ErrorHandler“ pupelė, kuri yra sujungta naudojant defaultErrorHandler nuosavybė.
Sudėtingesnės darbo eigos struktūros išlieka būsenos duomenų saugykloje tarp perėjimų. Šiame straipsnyje mus domina tik paprasti darbo eigos atvejai, kai būsenos perėjimas yra automatinis. Informacija apie valstiją yra prieinama tik ES „ProcessContext“ faktinio darbo eigos vykdymo metu. Turėdami tik du metodus, galite pamatyti „ProcessContext“ sąsaja yra laikomasi dietos:
viešoji sąsaja „ProcessContext“ išplečia „Serializable“ {public boolean stopProcess (); public void setSeedData (Object seedObject); }Betonas „ProcessContext“ aviakompanijos darbo eigos pavyzdžio klasė yra „RateDropContext“ klasė. „RateDropContext“ klasė apibendrina duomenis, reikalingus oro linijų tarifų kritimo darbo eigai vykdyti.
Iki šiol visi pupelių egzemplioriai buvo pavieniai pagal numatytuosius nustatymus „ApplicationContext“elgesys. Bet mes turime sukurti naują „RateDropContext“ klasės už kiekvieną oro linijų darbo eigos iškvietimą. Norėdami įvykdyti šį reikalavimą, Procesorius yra sukonfigūruotas, atsižvelgiant į visiškai kvalifikuotą klasės pavadinimą processContextClass nuosavybė. Kiekvienam darbo eigos vykdymui Procesorius gauna naują „ProcessContext“ nuo pavasario naudojant nurodytą klasės pavadinimą. Kad tai veiktų, niekuo dėtas pavasario pupelis arba prototipas tipo org.iocworkflow.test.sequence.simple.SimpleContext turi egzistuoti „ApplicationContext“ (matyti rateDrop.xml visam sąrašui).
Darbo eiga
Dabar, kai žinome, kaip sudaryti paprastą darbo eigą naudojant „Spring“, sutelkime dėmesį į greitėjimą naudodami pradinius duomenis. Norėdami suprasti, kaip paskirstyti darbo eigą, pažvelkime į faktinius metodus Procesorius sąsaja:
viešoji sąsaja procesorius {public boolean support (veiklos veikla); public void doActivities (); public void doActivities (Object seedData); public void setActivities (Veiklos sąrašas); public void setDefaultErrorHandler (ErrorHandler defaultErrorHandler); }Daugeliu atvejų darbo eigos procesams reikalingi tam tikri pradiniai stimulai. Yra dvi galimybės paleisti procesorių: „doActivities“ („Object seedData“) metodas ar jo be argumentų alternatyva. Šis kodų sąrašas yra „doAcvtivities“ () įgyvendinimas Procesorius pridedamas prie pavyzdžio kodo:
public void doActivities (Object seedData) {if (logger.isDebugEnabled ()) logger.debug (getBeanName () + "procesorius veikia .."); // retrieve injected by Spring List activities = getActivities (); // gauti naują „Workflow ProcessContext ProcessContext“ egzempliorių = createContext (); if (seedData! = null) context.setSeedData (seedData); for (Iterator it = veikla.iterator (); it.hasNext ();) {Veiklos veikla = (Veikla) it.next (); if (logger.isDebugEnabled ()) logger.debug ("vykdoma veikla:" + veikla.getBeanName () + "naudojant argumentus:" + kontekstas); pabandykite {kontekstas = veikla.vykdyti (kontekstas); } gaudyti (mesti th) {ErrorHandler errorHandler = veikla.getErrorHandler (); if (errorHandler == null) {logger.info ("nėra šio veiksmo klaidų tvarkytuvo, paleiskite numatytąją klaidą" + "tvarkyklė ir nutraukite apdorojimą"); getDefaultErrorHandler (). handError (kontekstas, th); pertrauka; } else {logger.info ("paleisti klaidų tvarkytuvą ir tęsti"); errorHandler.handleError (kontekstas, th); }} 
