Mnoho podnikových aplikácií Jave vyžaduje, aby sa spracovanie vykonávalo v kontexte oddelenom od kontextu hlavného systému. V mnohých prípadoch tieto procesy typu backend vykonávajú niekoľko úloh, pričom niektoré úlohy závisia od stavu predchádzajúcej úlohy. S požiadavkou vzájomne závislých úloh spracovania sa implementácia pomocou jedinej množiny volaní metód v procedurálnom štýle ukáže ako nedostatočná. Pomocou nástroja Spring môže vývojár ľahko oddeliť proces back-endu do súhrnu aktivít. Nádoba Spring sa spája s týmito aktivitami a vytvára a jednoduchý pracovný tok.
Na účely tohto článku jednoduchý pracovný tok je definovaná ako ľubovoľná sada aktivít vykonávaných vo vopred určenom poradí bez interakcie používateľa. Tento prístup sa však nenavrhuje ako náhrada za existujúce rámce pracovných tokov. Pre scenáre, kde sú potrebné pokročilejšie interakcie, ako je rozvetvenie, pripojenie alebo prechody založené na vstupe používateľa, je lepšie vybavený samostatný otvorený zdrojový alebo komerčný modul pracovného toku. Jeden projekt s otvoreným zdrojovým kódom úspešne integroval do aplikácie Spring zložitejší návrh pracovného toku.
Ak sú úlohy pracovného toku zjednodušujúce, jednoduchý prístup k pracovnému toku má zmysel na rozdiel od plne funkčného samostatného rámca pracovného toku, najmä ak sa už Spring používa, pretože je zaručená rýchla implementácia bez toho, aby došlo k nábehu času. Okrem toho, vzhľadom na povahu ľahkého kontajnera Spring s inverziou kontroly, Spring znižuje režijné prostriedky.
Tento článok stručne predstavuje pracovný tok ako tému programovania. Použitím konceptov pracovných tokov sa Spring používa ako rámec pre riadenie motora pracovných tokov. Potom sa diskutuje o možnostiach nasadenia výroby. Začnime myšlienkou jednoduchého pracovného toku zameraním na návrhové vzory pracovného toku a súvisiace základné informácie.
Jednoduchý pracovný postup
Modelovanie pracovného toku je téma, ktorá sa študuje už v 70. rokoch minulého storočia a mnoho vývojárov sa pokúsilo vytvoriť štandardizovanú špecifikáciu modelovania pracovného toku. Vzory pracovných tokov, biela kniha od W.H.M. van der Aalst a kol. (Júl 2003), sa podarilo klasifikovať skupinu návrhových vzorov, ktoré presne modelujú najbežnejšie scenáre pracovného toku. Medzi najtriviálnejšie vzory pracovných tokov patrí sekvenčný vzor. Podľa kritérií jednoduchého pracovného toku sa vzor pracovného toku Sekvencia skladá zo sady činností vykonávaných postupne.
Diagramy aktivít UML (Unified Modeling Language) sa bežne používajú ako mechanizmus na modelovanie pracovného toku. Obrázok 1 zobrazuje základný postup pracovného postupu sekvencie modelovaný pomocou štandardného diagramu činnosti UML.
Pracovný tok Sekvencia je štandardný vzor pracovného toku prevažujúci v aplikáciách J2EE. Aplikácia J2EE zvyčajne vyžaduje, aby sa postupnosť udalostí vyskytovala vo vlákne na pozadí alebo asynchrónne. Diagram aktivity na obrázku 2 ilustruje jednoduchý pracovný postup upozorňovania cestujúcich, ktorí majú záujem, že sa znížili ceny leteniek do ich obľúbeného cieľa.
Pracovný tok leteckých spoločností na obrázku 1 je zodpovedný za vytváranie a odosielanie dynamických e-mailových upozornení. Každý krok procesu predstavuje aktivitu. Pred uvedením pracovného toku do pohybu musí dôjsť k nejakej externej udalosti. V takom prípade je touto udalosťou pokles rýchlosti pre letovú trasu leteckej spoločnosti.
Poďme sa prejsť obchodnou logikou pracovného toku leteckej spoločnosti. Ak prvá aktivita nenájde žiadnych používateľov, ktorí by sa zaujímali o oznámenia o poklese rýchlosti, celý pracovný tok sa zruší. Ak sa objavia zainteresovaní používatelia, zostávajúce aktivity sú dokončené. Následne transformácia XSL (Extensible Stylesheet Language) vygeneruje obsah správy, po ktorej sa zaznamenajú informácie o audite. Nakoniec sa urobí pokus o odoslanie správy cez server SMTP. Ak sa odoslanie dokončí bez chyby, úspech sa zaznamená a proces sa ukončí. Ak sa ale vyskytne chyba pri komunikácii so serverom SMTP, prevezme ju špeciálna rutina spracovania chýb. Tento kód na spracovanie chýb sa pokúsi správu odoslať znova.
Vzhľadom na príklad leteckej spoločnosti je zrejmá jedna otázka: Ako by ste mohli efektívne rozdeliť postupný proces na jednotlivé činnosti? Tento problém je riešený veľavravne pomocou Spring. Poďme rýchlo diskutovať o jari ako o inverzii kontrolného rámca.
Obrátenie kontroly
Jar nám umožňuje odstrániť zodpovednosť za kontrolu závislostí objektu presunutím tejto zodpovednosti do kontajnera Jar. Tento prenos zodpovednosti sa nazýva Inversion of Control (IoC) alebo Dependency Injection. Pozri Martin Fowler „Inverzia kontrolných kontajnerov a model vstrekovania závislostí“ (martinfowler.com, január 2004), kde nájdete podrobnejšiu diskusiu o IoC a aplikácii závislostí. Riadením závislostí medzi objektmi Spring eliminuje potrebu kód lepidla, kód napísaný výlučne na účely vzájomnej spolupráce tried.
Súčasti pracovného toku ako jarné bôby
Než prídeme príliš ďaleko, je teraz vhodný čas na to, aby sme si prešli hlavné pojmy, ktoré stoja za jarou. The ApplicationContext rozhranie, dediace z BeanFactory rozhranie, ukladá sa ako skutočná riadiaca entita alebo kontajner v rámci jari. The ApplicationContext je zodpovedný za vytvorenie inštancie, konfiguráciu a správu životného cyklu sady bôbov známych ako Jarná fazuľa. The ApplicationContext je nakonfigurovaný používateľom zapojenie Jarné bôby v konfiguračnom súbore založenom na XML. Tento konfiguračný súbor diktuje podstatu, v ktorej fazule Spring Spring navzájom spolupracujú. Tak, na jar hovoriť, Jarné bôby, ktoré interagujú s ostatnými, sú známe ako spolupracovníci. Predvolene existuje jarná fazuľa ako singleton v ApplicationContext, ale atribút singleton je možné nastaviť na hodnotu false, čo ich efektívne zmení tak, aby sa správali k tomu, čo Spring volá prototyp režim.
Späť k nášmu príkladu, v poklese leteniek, je abstrakcia rutiny odosielania SMTP zapojená ako posledná aktivita v príklade procesu pracovného toku (ukážkový kód k dispozícii v prostriedkoch). Ako piata aktivita je táto fazuľa pomenovaná trefne činnosť5. Ak chcete poslať správu, činnosť5 vyžaduje spolupracovníka delegáta a obsluhu chyby:
Implementácia komponentov pracovného toku ako jarných bôbov vedie k dvom požadovaným vedľajším produktom, ľahkému testovaniu jednotiek a veľkej miere opätovného použitia. Efektívne testovanie jednotiek je zrejmé vzhľadom na povahu kontajnerov IoC. Pomocou kontajnera IoC, ako je Spring, možno závislosti spolupracovníkov ľahko zameniť za simulované výmeny počas testovania. V príklade leteckej spoločnosti je Činnosť Jarná fazuľa ako napr činnosť5 je možné ľahko získať zo samostatného testu ApplicationContext. Nahradenie falošného delegáta SMTP činnosť5 umožňuje jednotkovú skúšku činnosť5 oddelene.
Druhý vedľajší produkt, opätovná použiteľnosť, sa realizuje aktivitami pracovného toku, ako je transformácia XSL. Transformáciu XSL, abstraktnú do aktivity pracovného toku, je teraz možné znova použiť v ľubovoľnom pracovnom postupe, ktorý sa zaoberá transformáciami XSL.
Prepojenie pracovného toku
V poskytnutom API (stiahnuteľnom z prostriedkov) ovláda Spring malú skupinu hráčov, ktorí interagujú spôsobom, ktorý predstavuje pracovný tok. Kľúčové rozhrania sú:
Činnosť: Zapuzdruje obchodnú logiku jedného kroku v procese pracovného toku.ProcessContext: Predmety typuProcessContextsa prenášajú medzi činnosťami v pracovnom toku. Objekty implementujúce toto rozhranie sú zodpovedné za udržiavanie stavu pri prechode pracovného toku z jednej aktivity na ďalšiu.ErrorHandler: Poskytuje metódu spätného volania na spracovanie chýb.procesor: Opisuje fazuľu slúžiacu ako vykonávateľ hlavného vlákna pracovného toku.
Nasledujúci výňatok zo vzorového kódu je konfigurácia Spring Bean, ktorá viaže príklad leteckej spoločnosti ako jednoduchý proces pracovného toku.
/ property> org.iocworkflow.test.sequence.ratedrop.RateDropContext The SequenceProcessor trieda je konkrétna podtrieda, ktorá modeluje vzor sekvencie. K procesoru je pripojených päť aktivít, ktoré procesor pracovného toku vykoná v danom poradí.
V porovnaní s väčšinou procedurálnych procesov typu backend vyniká riešenie pracovného toku ako schopné vysoko robustného spracovania chýb. Obslužný program chýb môže byť pre každú činnosť zapojený osobitne. Tento typ obsluhy poskytuje jemnozrnné spracovanie chýb na úrovni individuálnej aktivity. Ak pre činnosť nie je pripojený žiadny obslužný program chýb, problém vyrieši obslužný program chýb definovaný pre celkový procesor pracovného toku. V tomto príklade, ak sa počas procesu pracovného toku vyskytne neošetrená chyba kedykoľvek, rozšíri sa na spracovanie ErrorHandler fazuľa, ktorá je káblovaná pomocou defaultErrorHandler nehnuteľnosť.
Zložitejšie rámce pracovných tokov pretrvávajú medzi prechodmi v dátovom úložisku. V tomto článku nás zaujímajú iba jednoduché prípady pracovných postupov, keď je prechod stavu automatický. Informácie o štáte sú k dispozícii iba v ProcessContext počas behu skutočného pracovného toku. Ak máte iba dve metódy, môžete vidieť ProcessContext rozhranie je na strave:
verejné rozhranie ProcessContext rozširuje Serializable {public boolean stopProcess (); public void setSeedData (Object seedObject); }Betón ProcessContext triedou použitou pre príklad pracovného toku leteckej spoločnosti je RateDropContext trieda. The RateDropContext trieda zapuzdruje údaje potrebné na vykonanie pracovného toku poklesu leteckej spoločnosti.
Doteraz boli všetky inštancie fazule predvolene singletony ApplicationContextsprávanie. Musíme však vytvoriť novú inštanciu súboru RateDropContext triedy pre každé vyvolanie pracovného toku leteckej spoločnosti. Na splnenie tejto požiadavky SequenceProcessor je nakonfigurovaný, pričom sa ako úplný názov triedy použije úplný názov triedy processContextClass nehnuteľnosť. Pre každé vykonávanie pracovného toku je SequenceProcessor načíta novú inštanciu súboru ProcessContext od jari pomocou zadaného názvu triedy. Aby to fungovalo, je potrebné použiť jarnú fazuľu alebo jar prototyp typu org.iocworkflow.test.sequence.simple.SimpleContext musí existovať v ApplicationContext (viď rateDrop.xml pre celý zoznam).
Nasadenie pracovného toku
Teraz, keď vieme, ako zostaviť jednoduchý pracovný tok pomocou jari, zamerajme sa na inštanciu pomocou počiatočných údajov. Aby sme pochopili, ako nasadiť pracovný tok, pozrime sa na metódy vystavené v skutočnosti procesor rozhranie:
verejné rozhranie Procesor {public boolean podporuje (aktivita aktivita); public void doActivities (); public void doActivities (Object seedData); public void setActivities (činnosti v zozname); public void setDefaultErrorHandler (ErrorHandler defaultErrorHandler); }Vo väčšine prípadov si procesy pracovného toku vyžadujú určité počiatočné podnety na zahájenie procesu. Na spustenie procesora existujú dve možnosti: doActivities (Object seedData) metóda alebo jej alternatíva bez argumentov. Nasledujúci zoznam kódov je doAcvtivities () implementácia pre SequenceProcessor súčasťou vzorového kódu:
public void doActivities (Object seedData) {if (logger.isDebugEnabled ()) logger.debug (getBeanName () + "beží procesor .."); // načítanie vložené aktivitami Spring List = getActivities (); // načítanie novej inštancie Workflow ProcessContext ProcessContext context = createContext (); if (seedData! = null) context.setSeedData (seedData); pre (Iterator it = activities.iterator (); it.hasNext ();) {Activity activity = (Activity) it.next (); if (logger.isDebugEnabled ()) logger.debug ("bežiaca aktivita:" + activity.getBeanName () + "pomocou argumentov:" + kontext); skúsiť {context = activity.execute (kontext); } catch (Throwable th) {ErrorHandler errorHandler = activity.getErrorHandler (); if (errorHandler == null) {logger.info ("pre túto akciu nie je obslužný program chýb, spustiť predvolenú chybu" + "obslužný program a prerušiť spracovanie"); getDefaultErrorHandler (). handleError (kontext, th); prestávka; } else {logger.info ("spustiť obslužný program chýb a pokračovať"); errorHandler.handleError (kontext, th); }} 
