POLSKIE TOWARZYSTWO INFORMATYCZNE
Dwunaste Jesienne Spotkanie PTI
Mrągowo, 25-29 listopada 1996 r.
Szanowni Państwo
P ierw szy tuzin z głow y. N ow a fo rm u ła naszego je sie n n e g o spotkan ia j e s t efek
tem ja ło w y c h p o ła ja n ek p ra sy kom p u tero w ej i tw órczych idei szan ow n ych człon ków PTI. J a k zo b a czycie P aństw o w trakcie trw an ia k o n feren cji staraliśm y się za ch o w a ć to, co było p o d sta w ą p o w o d zen ia konferencji, redu ku jąc p rzy k re sk u t
k i uboczne. O b ecn o ść p o lsk ich w span iałych w ykładow ców akadem ickich , j a k rów n ież zagran iczn ych i p o lsk ich p ro d u cen tó w środków in fo rm a tyk i w p o łą cze niu z d ysk u sja m i osobistości naszego środow iska p o zw o lą - m am y n adzieję - sp ę
d zić kolejny tydzień w M rągow ie ku p o ży tk o w i i zadow olen iu tak p rezen terów , j a k i słuchaczy.
W spom niałem o prasie. Z n iew yjaśn ion ych p rzyczyn otoczyła ona ostatnio sp e
cjalną troską kon takty P T I z otoczeniem . N ieo b ecn o ść naszego p rzed sta w iciela na je d n y m z liczn ych spotkań środow iskow ych stała się p rzed m io tem obfitych kom entarzy. Z godn ie z naszą w ieloletnią tradycją w olim y d zia ła ć dla dobra To
w arzystw a bez fa n fa r i werbli, a n iżeli u zysk iw a ć p o p u la rn o ść p o p rze z n ieobec
ność. N a obecnym spotkaniu oczekujem y obecn ości w ieloletnich przyjaciół, człon
ków PTI, którzy obecn ie p ełn ią w ysokie fu n k c je w zaprzyjaźn ion ych organ iza
cjach środow iskow ych . M am y nadzieję, że n a w et bez kom en tarzy p ra so w ych to spotkan ie p o su n ie troch ę spraw y naprzód.
W czasie, który m in ą ł od p o p rzed n ieg o spotkan ia odn ow iły się w ładze PTI. S ą
dzę, że o dm łodzen ie składu Z G będzie służyło dalszem u ro zw o jo w i Towarzystwa ku chw ale i p o ży tk o w i p o lsk ie j inform atyki.
D la m nie osobiście to spotkan ie n iesie ze sobą ra d o ść p o żeg n a n ia . O rgan izato
ram i Spotkań są w tym roku: Z G P T I oraz oddziały G órn ośląski i M azow iecki
PTI. O d p rzyszłeg o roku m am za m ia r b yć d ożyw otn im u czestn ikiem i p rzyja c ie
lem konferencji. M oje deklaracje z ubiegłego roku były p ra w d ziw e, tyle, że nigdy
nie w yobrażałem sobie, że M rągow a m oże nie być. N a cześć n ow ego P rezesa i
Sekretarza G eneralnego w ielokrotn e hip łup hura.
PTI
W s p ó ł p r a c a P o l s k i e g o ia r z y s t w ^ T p f o i m la f y c z n e g o
t o d o b n y n # o r g a n i z a c j a m i n a i v w b c i e C&
L v W \
^-■Piotr wJpugl^wicz
/ Wiceprezes PTI \ ^ J
f v ¿ r
PTI 1
działalności n. Kich dziedzinai
micznej Popierali
we/ wszyst)
♦ Podnosząme poziomu i kwalifik$qKózlonków,, kierunkurifhnne osoby
♦ Ułatwiania wymiany informécji w środowisku i
♦ Popularyzacja w jpoleczeńitw iepffgadnień inforniatyku
je j zastosowany \ J )
♦ Reprezentowanie członków Towarzystwa, ich opinii, o ¿ potrzeb, interesów i uprawnień (...)
HM__________________ ____________________________
Czym
♦ Stcwarzyszenien Zwfiązkiem zawodov
§0J?ezentacją/użytkownTJ
♦ Wyrazfóiglem opíffl\prody¿entów śfi informatyki)
♦ Agencjąschrony pr^w ófitforskich
HLL
^ E ^ ł o n k o w i f [I
Ukończyli ątudia wyższe rf&d<ierunku informatp&nym lub związanym z informatykąfg/Wfpaią stopień nayifyy/y w zakęesMpformatyki lubjSfzbstosa^yań
* PosiaddłźfWyksztalcenJe wyższe\yyśródńią%§ioh praca zawodowsArciągu co najmniej 3 ostatnich ląijpczhd wstąpieniem do~Towarzystwa była ściśle zw iała m grxa
informatyka { / y ^ A
♦ Studiują na kierfmkach infoirriay/cznych lub związanych z informatykąj poczynając od trzeciego roku s t u d i ó w \ j J /
M L
Kto nie je s t profesjonalnym
len
i P olskie
T o w arzy stw o Inform atyczne
PTI
Part
n e r z y k r a jo w i, J )w a rz y s z e n ia /
• C S , IF IP
♦ b r ą t m e - s t o w a r z ' j m a n n S o c i e t y ,
♦ h u n q u s z e m a u k o w e Y E s j5 [ j? )
BIL
Polscyj^artru 'olska Izbapnformatyki l i Telekomà^ôçji^
S f ñ ^ t o w a r z f s z e n i e Y v S k i
•ogramowania
Polska Spolęczriość Intern B r’*'**
\Stoû/arzyszèni$l Rozwoju C \ stemów Otwartych J>
E IL
The First S o cie ty In
C o m p u tin g
A sio cia tio n rfo rC o m p u tin g p o w s t a łą w jj^ 7 roku międzynarodową o r g a n iz a c ić ^ ^ u T ł^ n -^ p fit" zajmująógrsię rozszfcjłartteij} kontaktów óraz p r o p a g W a ^ m L ^ n w w a n ie m rozw ojuih^gm iątyki tak w zakresie te o n tó k i z ą ^ t o s i r ^ r r ^
♦ ACM je st organizatorem wieiiTp^estiżowych m ię d z y n ^ j- ^ ^ w ^ h ^ konferencji w zakresi^ inform atyki i w yaa w cą du że j lic z B y = * * ^ w renomowanych czasopism . ( r r ł
♦ Polski Oddzia ACIM został zarejestrpwany W rocławiu.
any w roku 1994
Oprócz krajowvch oddziałów ACM działa poprzez m iędzynarodowe Grupy Zainteresowań.
len_____________________________________
IEEE ^
OMPUTER SOCIETY
5 0 V 5 A E S 0 F S 2 I łY I C 2 * 1 5>4 6 - 1 9 9 6
b ię k s z a o r g a r | t | a ę j a s t o w a r z y s z ę k t r y k ó w lic z ą c ^ p b n a j d gOOOOO
a k ó w
♦ L iW re J ro n fe re ń » ,^ ,^
k s i ą ż k o w e j p e r io d y k i ( n iS Z ® !1 *
♦ Szereg kom itetów specję|j&tycznych
♦ W o s t a t n i c h l a t a c h w ie l e d z ia ła ń n a te n k r a jo w y n a s z e g o r e g io n u , w t y m w iz y t a S h r iv e r a i lic z n e o f e r t y w s p ó ł p r a c y z p o l s k i m i i n f o r m a t y k a m i _________________
IFIP
_ inT Ł R N A T lO N A t. F Z C ÏR A T IO H FO R 3 ¡F O R M A T O N FROC FCC INO
♦ Powstała w i} 960 roku pod au decyzji podjętych na paryskirj roka
ąmi UNESCO w ną Computer Cong
ś k F rodzajów czfonków z c a ł^ o " Swi o rg a n iz a c jffts ó n a d 50 k ra jó w jza p e w n ia ją c wsjx>!p£Bci pozarządow ych stow arzyszeń inform atycznych i age^j-fią fiz ^ c y D ziałalnośćttechniczńa będąca jąd re m aktywności IFIP prawądzona je st przez Kom itetW r echniczne ńTeclfrifpal C o m m itte e s jP \ Przedstawicielam i państw n a sze jW ę ści Europy s ą AkademhąNj&ukj!
w państwachjrióFrnalnie rozwiniętych — lokalne stowarzyszenia ¿ r informatyków!
p y F EPIS je s t C złonkiem Stow arzyszonym IFIP
* * * * Council of European
* c e p i s * P r ^ ^ s i p p a p _
♦ * * ^ Inforniat icŚSocie11
♦ P o w o ł a n a w 1 9 8 8 - ie ł$ { j w P a r y ż u w j z e n t o w a n i a . w S ^ Ó m S g o g ło s u "
o e js k ic h in f o r m a t y k Ą w w b ł? d c v w i j o t y E u r o p e js k ie j
♦ Z r ż e s z a T & e u r o p e js k i c h / ^ r o f e s j o n a s t o w a r z y s z e ń w ty r n P o js j j ^ i W ę g r y
♦ P o ls k a ^ ik t y w n y m u c i r o k u
t n i k ie m o d 1 9 9 1!
PTI
2
PTI
♦ R(
mii - W spl
KBN, pr
♦ W ybrano!
♦ Od 1996 r<
♦ Partnerzy:
Datenverai
C ooperative Research in I n f o r m a j t i i M L T ^ o h n o l o g y
ie 24 lutego
ie przedsięwzięć ż&jyWaTijiJ<&yy^ns(ch przez europejskich
ojektów 'ntynuacj;
ellschaft fur M athem atik und « itung (Niemcy), Fundacja Nauki PolsfciefT Polskie Towarzystw o Inform atyczne
Korzyści za
♦ Znipki dla członki nferencjach i tófączenie opi/iii PartSmentowi
♦ W y m ian ab sług towarzystwam i
♦ Udział w programaci Esprl
płpracy
PTI
SJrategia rozwoju współpracy międz^gt^ocfowej
emanie związ nym partnera
¡^z CEPIS, jakc idzynarodow(r ja program u EuropęjsTjlę
row egV P raw a Jażdy z innym i organizacjam i
spoinie realizowanych z a d a r f ^ T 'e współpracym aukowej
* J 1 PTI
3
Sterowanie Przepływem Pracy w Rozproszonych Systemach Informatycznych
W itold Staniszkis RODAN SYSTEM Sp. z o.o.
Jagielska 50c 02-886 W arszawa W itold.Staniszkis@ rodan.waw.pl
S t r e s z c z e n ie
W spółczesne zastosow ania systemów zarządzania przepływem pracy (ZPP) dalece w ykraczają poza klasyczne system y zarządzania dokum entam i i obrazami. Typowym środow iskiem przetwarzania now oczesnych system ów inform atycznych są heterogeniczne, autonomiczne i rc-zproszone (HAR) systemy oprogram ow ania dostępne w ram ach sieci kom puterow ej. Jednym z m ożliwych rozwiązań stosowanych w ramach takiej architektury oprogram ow ania jest w ykorzystanie system ów zarządzania przepływ em pracy do sterowania procesem użytkowym odw ołującym się do indywidualnych funkcji poszczególnych system ów dostępnych w ramach rozproszonego system u inform atycznego. W referacie om ówiono podstawowe cechy architektury systemów ZPP, charakterystykę obiektow ych system pw informatycznych stanowiących obecnie klasyczne ju ż środowisko system ów HAR, oraz zarys m etodyki projektow ania i realizacji takich systemów inform atycznych.
1. W stę p
G lobalizacja światowej gospodarki doprowadziła do dram atycznego wzrostu konkurencji, szczególnie w zakresie produkcji i usług w rozwiniętych gospodarczo krajach. Silny nacisk producentów z Dalekiego W schodu i Japonii spowodował, że tradycyjny prymat przedsiębiorstw am erykańskich i zachodnioeuropejskich zaczął gw ałtow nie maleć a możliwości dalszego funkcjonowanie na św iatow ych rynkach są uzależnione od radykalnej popraw y w zakresie jakości produkowanych wyrobów i usług oraz poważnego ograniczenia kosztów własnych.
O dpow iedzią na to wyzwanie jest gw ałtow ny rozwój technik zarządzania a szczególnie dziedziny „reinżynierii procesów działalności” (ang. business process reengineering). M ożliwość rozwoju tej dziedziny wynika przede wszystkim z rosnących możliwości współczesnej informatyki w zakresie takich obszarów jak sieci kom puterowe, bazy danych, przetwarzanie rozproszone oraz wspomaganie pracy grupowej.
Szczególnie istotna jest możliwość autom atycznego w spom agania definicji oraz sterow ania procesami pracy, które zazwyczaj integrują funkcje tradycyjnie realizow ane w różnych kom órkach organizacyjnych przedsiębiorstwa. Tradycyjnie sterowanie przepływem pracy było więc związana ze w spom aganiem pracy biurowej a szczególnie z system am i zarządzania dokum entam i i obrazam i. Podstaw ow e wymagania w stosunku do systemów zarządzania przepływem pracy w tej właśnie dziedzinie przedstaw iono w [GEOR95, M ARS94]. Rosnąca liczba zastosow ań system ów ZPP wykazała, że zaawansovvane system y informatyczne wspom agające procesy pracy w ym agają ścisłej integracji funkcji zarządzania dokum entam i i obrazami z klasycznym przetwarzaniem transakcyjnym . Środowisko sieci kom puterowych, zarówno lokalnych ja k i zdalnych, typowe dla zastosowań system ów ZPP, powoduje, że funkcje przetwarzania transakcyjnego m uszą być realizowane w oparciu o architekturę system ów rozproszonych.
Naszym celem jest przedstawienie możliwości realizacji kom pleksowych systemów inform atycznych w spom agających procesy pracy w oparciu o współczesne system y ZPP, a szczególnie integrację tych system ów z now oczesnym i środowiskami rozproszonego przetwarzania obiektow ego. W dalszych częściach referatu przedstaw iono architekturę systemów zarządzania przepływem pracy, charakterystykę współczesnych obiektowych system ów inform atycznych, oraz zarys metodyki projektow ania rozproszonych systemów inform atycznych w ykorzystujących powyższe techniki.
P r z e d s ta w io n o na II K o n fe r e n c ji „ I n fo r m a ty k a na W y ż s z y c h U c z e ln ia c h d la G o s p o d a r k i N a r o d o w e j ” , G d a ń s k , 2 2 -2 4 lis to p a d a , 1996.
2 . S y s t e m y z a r z ą d z a n ia p r z e p ły w e m p r a c y
System zarządzania przepływem pracy sterują w ykonaniem zadań określonych dla w spom aganego procesu pracy, przy czym sterowanie obejmuje takie funkcje koordynacyjne jak przydział zadań, kontrola ich w ykonania oraz retrospektyw na analiza funkcjonowania procesów pracy. Oczywistym warunkiem funkcjonowania system ów ZPP jest istnienie odpowiedniej infrastruktury sprzętowej obejm ującej urządzenia sieciowe, stacje robocze oraz serwer
realizujący funkcje zarządzania procesam i pracy.
Zadania m ogą być przydzielane poszczególnym uczestnikom procesu pracy, zgodnie z jego opisem oraz w oparciu o dynam icznie sprawdzane warunki, poprzez ustaw ienie ich w listach zadań w odpowiedniej stacji roboczej.
Typowym trybem realizacji zadania jest podjęcie go przez użytkow nika danej stacji roboczej, który wykonuje przewidziane czynności korzystając zazwyczaj z funkcji użytkowych oprogram ow ania stacji roboczej, na przykład program ów M icrosoft Office, oraz z funkcji użytkowych system ów informatycznego, takich jak system zarządzania dokum entam i lub system transakcyjny, dostępnych poprzez daną stację roboczą. O dpowiednie elementy oprogram ow ania użytkowego, zazwyczaj dostępne w architekturze klient/serwer, m ogą być autom atycznie aktyw izow ane w mom encie wybrania danego zadania z listy. Zakończenie realizacji zadania potwierdzone autom atyczną kontrolą w arunków zakończenia powoduje utw orzenie następnego zadania lub zadań i ustawienie ich w odpow iednich listach zadań.
N arzęd zia defin icji procesów
N arzęd zia adm ins tratora
Funkcje sterujące przepływem pracy
Inne system SPP
K lien t system u W o ła n e
SPP aplikacje
Rys. 1. A rchitektura Systemu Zarządzania Przepływem Pracy według W orkflow M anagement Coalition.
M ożliwa je st autom atyczna obsługa zadań procesu polegająca na wywołaniu odpowiedniego programu użytkow ego dostępnego w dowolnym węźle sieci kom puterow ej przejm ującego realizację zadania bez konieczności udziału użytkow ników systemu. W przypadku skrajnym wszystkie zadania procesu m ogą być obsługiwane autom atycznie a w takim przypadku opis procesu stanowi skrypt sterujący wykonaniem rozproszonego procesu obliczeniowego. W takim przypadku powinny być dostępne wszystkie mechanizmy ochrony integralności transakcji i danych przewidziane w modelu ACID. Najczęściej mamy do czynienia z sytuacją pośrednią, to jest w ramach opisu procesu istnieją zadania, których obsługa je st całkowicie automatyczna i niewidoczna dla użytkow ników , ja k na przykład ściąganie w ym aganych w procesie danych z pamięci WORM, oraz zadania
podejm ow ane przez użytkow ników systemu spełniających odpow iednią rolę w ram ach w spom aganego procesu pracy.
Rosnąca gwałtownie liczba zastosowań system ów ZPP oraz doświadczenia z innych dziedzin informatyki w skazujące na potrzebę wczesnego tw orzenia specyfikacji standardowych rozwiązań, doprow adziły do powstania m iędzynarodowej organizacji zajmującej się tymi system am i. W orkflow M anagem ent Coalition (W M C) [WORK94]
je st organizacją typu non-profit skupiającą producentów oraz użytkowników system ów ZPP, której celem jest stworzenie architektury systemu ZPP umożliwiającej stosow anie typowych rozwiązań w środowiskach różnych system ów ZPP oraz współpracę takich systemów. A rchitekturę systemu ZPP proponow aną przez Workflow M anagem ent Coalition przedstawiono na rysunku J.
Podstawowym celem specyfikacji architektury W M C jest określenie standardow ych interface’ów dla poszczególnych funkcji użytkowych i adm inistracyjnych systemu ZPP. Sama implementacji systemu, zazwyczaj oparta o system zarządzania bazą danych, może być zrealizow ana w dowolny sposób pod warunkiem zachowania interface’ów określonych w architekturze WMC. N a przykład, system IBM FlowM ark (IBM 96) został zbudowany w oparciu o obiektow y system zarządzania bazą danych ObjectStore zachowując jednocześnie zgodność ze specyfikacją WMC na poziom ie interface’ów.
A rchitektura WMC przyjm uje notację grafów zorientow anych jako formalizm definicji procesów, przy czym dopuszczalne jest zastosowanie dowolnego edytora graficznego dla tworzenia takiego opisu. Interfacem opisu je st język sym boliczny Flow Definition Language (FDL), który powinien być generow any w oparciu o specyfikację graficzną. D opuszczalne jest również definiowanie procesów bezpośrednio w tym języku. W taki sposób została zapew niona uniw ersalność opisu procesów co pozw ala na wymianę informacji pom iędzy systemami ZPP spełniającym i w ym agania specyfikacji WMC. Podstawowe pojęcia opisu procesów pracy pokazana na rysunku 2.
W spółczesne systemy ZPP są realizowane w oparciu- o architekturę klient/serwer, przy czym dzięki ujednoliceniu interface pomiędzy procesem klienta a serw erem , zrealizowanego w form ie publikow anego API, m ożliwe jest tw orzenie procesów klienckich w różnych środowiskach narzędziowych. N a przykład system IBM FlowM ark pozwala na realizację procesów klienckich we w łasnym środowisku (klient FlowM ark), w środowisku Lotus Notes (klient Lotus Notes), oraz w dowolnym środow isku programowym poprzez w ykorzystanie API systemu FlowMark.
N arzędzia adm inistracji procesów pracy sterow anych poprzez system ZPP obejm ują obsługę bieżącego m onitorowania przebiegu procesów, narzędzia retrospektyw nej analizy oraz standardow e m echanizm y ochrony integralności danych. Retrospektywna analiza przebiegu procesów pracy jest m ożliw a dzięki tworzeniu logu obejm ującego w szystkie podstawowe zdarzenia. Zapis logu jest eksportowalny co pozw ala na w ykorzystanie m echanizm ów innych systemów, jak na przykład system u analizy statystycznej i/lub system u zarządzania bazą danych, dla analizy dowolnego okresu przebiegu procesów pracy.
Schemat procesu pracy przedstawiony w postaci graficznej lub bezpośrednio jak o specyfikacja FDL, reprezentuje zasady sterowania pew ną klasą procesów pracy i jest interpretowany przez system ZPP w trakcie sterowania w ykonaniem wszystkich procesów pracy należących do tej klasy. W ybór ścieżki w ramach procesu, reprezentow anego na poziom ie klasy przez zorientow any graf, którego węzłami są czynności realizowane w ramach procesu a krawędzie określają przepływ sterowania pom iędzy czynnościami, jest realizow any w oparciu o warunki określana w ramach opisu poszczególnych czynności. T opologia powiązań pomiędzy czynnościam i opisywanym i w ramach grafu procesu w ym agana przez specyfikację W M C je st pokazana na rysunku 3.
W ramach schematu procesu pracy opisywane są takie elem enty jak czynności procesu pracy reprezentujące zadania w ykonyw ane przez pracow ników biorących udział w procesie, przy czym dopuszczalne jest definiowanie czynności, które są realizowane całkowicie autom atycznie przez program lub inny proces. Pojem niki danych stanow ią m echanizm przekazywania danych, zazw yczaj w formie parametrów lub adresów danych wykorzystyw anych w ramach procesu, pom iędzy czynnościam i procesu, a warunki określone na wartościach atrybutów pojem ników danych determ inują wybór ścieżki w grafie procesu realizującej sterow anie wystąpieniem procesu pracy należącego do danej klasy procesów. Ł ączniki definiowane w ramach schem atu procesu reprezentują krawędzie zorientow anego grafu procesu.
P o d sta w o w e p o ję c ia
( P R O C E S )
\ / \
[C Z Y N N O Ś Ć ]
B L O K !
v y
i Ł Ą C Z N IK )
P O JE M N IK -.,
\ D A N Y C H ■ [ W A R U N E K ]
\ . . /
P R O G R A M j P R A C O W N IK
V A' A
S c h e m a t p ro c esu
P ro ces
t
Rys. 2. Podstawowe pojęcia definicji procesów przepływ u pracy.
Rys. 3. Topologia powiązań pomiędzy czynnościam i procesu pracy.
Cel oraz środowisko działania system ów ZPP powodują, że wszystkie system y inform atyczne w spom agające wykonanie procesów pracy, zarów no te klasyczne jak i zrealizowane w formie całkowicie autom atycznej, stanow ią typowe system y rozproszone. Istotną cechą tych systemów je st rów nież konieczność łączenia elem entarnych funkcji użytkowych dostępnych w ramach różnych systemów inform atycznych, na przykład system zarządzania dokumentami i system finansow o-księgow y, oraz danych przechowywanych w ram ach zbiorów należących do tych systemów. Przykład typow ego środow iska systemu ZPP pokazano na rysunku 4.
Rys. 4. A rchitektura rozproszonego systemu inform atycznego w środowisku systemu ZPP.
W ykonanie zadania opisanego jak o czynność grafu procesu powoduje naw iązanie dialogu pomiędzy w ykonaw cą zadania a funkcjami użytkowymi różnych system ów informatycznych. Takie funkcje użytkowe m ogą albo należeć do funkcji oprogramowania osobistego działającego w ramach stacji roboczej, tak jak na przykład program y MS Office, lub m ogą stanowić odwołania do funkcji systemów informatycznych dostępnych w trybie klient/serw er w ramach sieci komputerowej. W now oczesnych systemach obiektowych warstwę sterowania dialogiem stanowi zazwyczaj program obsługujący graficzny interface użytkownika (GUI) napisany w takim języku oprogram ow ania ja k SmallTalk, Visual Basic, lub z wykorzystaniem klas obsługi interface języku C++. Zmiennym i takiego programu są klasy obiektów, które spełniają funkcje w ym agana w ramach danego systemu inform atycznego.
W ażną cechą takich systemów jest całkowita izolacja program u użytkowego obsługującego dialog od struktur danych wykorzystyw anych dla przechowywania w ystąpień obiektów oraz od reguł odw zorow ań pom iędzy tymi strukturam i a postacią danych wystąpienia obiektu. Bardziej szczegółowe omówienie architektury systemów opartych o paradygm at rozproszonego przetw arzania obiektow ego przedstawiono poniżej.
Realizacja systemów o architekturze HAR nakłada jednak pewne wymagania na m echanizm y systemu ZPP, szczególnie w zakresie sterowania przetwarzaniem transakcyjnym . Inne wymagania takie jak integracja i współpraca heterogenicznych system ów informatycznych, niezależność od rozproszenia, oraz łatwość m odyfikacji i rozwoju sterowania procesami pracy są spełnione dzięki pow iązaniu możliwości systemów ZPP z funkcjami zarządzania rozproszonym systemem obiektowy.
Jak ju ż powiedziano powyżej zachowanie modelu ACID (Atomicity, Consistency, Isolation, D urability) w ramach obsługi procesu pracy jest możliwe jedynie w przypadku gdy wszystkie czynności grafu procesu są obsługiwane w pełni automatycznie. W takim przypadku koniecznej je st spełnienie dwóch dodatkow ych warunków,
a m ianow icie w arunku właściwej obsługi przetw arzania transakcyjnego w ram ach system u obsługującego repozytorium obiektów , oraz możliwości obsługi funkcji odtwarzania i operacji kom pensacyjnych w ramach system u ZPP. Pierw szy warunek je st spełniony jedynie gdy repozytorium obiektów je st obsługiw ane przez relacyjny lub obiektów y system zarządzania bazą danych. W każdym innym przypadku należy tw orzyć specjalny system sterow ania w ykonaniem transakcji wykorzystujący m echanizm y systemu ZPP i dodatkow e oprogramowanie aplikacyjne. Jest to możliwe jedynie w przypadku spełnienia drugiego warunku a m ianowicie możliwości prow adzenia dziennika pracy system u oraz tw orzenia czynności kom pensacyjnych. Jednym z nielicznych systemów ZPP zaw ierających takie możliwości je st IBM FlowM ark (IBM 95).
3 . A r c h ite k t u r a o b ie k t o w y c h s y s te m ó w in f o r m a ty c z n y c h
N ajw yraźniej widocznym kierunkiem ewolucji architektury systemów inform atycznych jest odwrót od hierarchii m odułów oprogram ow ania charakterystycznych dla m onolitycznych system ów informatycznych w których podział funkcjonalny stanowił podstawowe kryterium m odularyzacji oprogram ow ania. Okazało się, iż w miarę wzrostu stopnia złożoności oraz liczby funkcji użytkow ych takich systemów konserw acja oraz rozwój takiego oprogram ow ania stanowiły coraz bardziej znaczący koszt. Dodatkowym poważnym m ankam entem były stosunkowe niewielkie m ożliw ości ponow nego wykorzystania fragm entów oprogram owania użytkow ego, mim o iż podobne algorytm y były stosowane w innych systemach lub wręcz w innych m odułach tego samego systemu inform atycznego.
Rys. 5. Alternatyw ne architektury systemów inform atycznych
N ajpoważniejszym naszym zdaniem m ankam entem architektury m onolitycznych systemów inform atycznych jest jej niewielki związek z modelem pojęciowym opisującym reprezentow aną przez niego rzeczywistość. Problem nieciągłości notacji stosowanej na poziomie analizy funkcjonalnej, gdzie używano zazwyczaj m odeli przepływu danych, a notacji hierarchii funkcji stosowanej w specyfikacji architektury oprogram ow ania użytkowego, stanowi podstawowy brak wszystkich metodyk analizy strukturalnej. W tej sytuacji dokum entacja projektow a tworzona na poziom ie pojęciowym była mało przydatna w pracach nad konserw acją i rozwojem oprogram owania systemów informatycznych. Stanowiło to istotne utrudnienie poniew aż właśnie ten
poziom dokum entacji projektowej je st najbardziej zw iązany z meritum system u inform atycznego i jest intuicyjnie rozum iany zarów no przez użytkow ników systemu ja k i przez pracujących nad nim informatyków. Trudno jest rów nież pokazać w ramach notacji stosowanych w metodykach strukturalnych wzajem ne powiązania pomiędzy statycznym modelem rzeczywistości, reprezentow anym przez pojęciowy model danych, a dynamicznym modelem rzeczywistości, który je st ilustrowany przez hierarchię modeli przepływ u danych.
A rchitektura obiektowych system ów inform atycznych je st jak wiadom o w olna od wszystkich powyższych problem ów a najw ażniejszą jej zaletą je st podział oprogram ow ania użytkow ego na m oduły, klasy obiektów, które bezpośrednio reprezentują elem enty rzeczyw istości objętej zakresem system u inform atycznego. Ogromne zalety takiego podejścia z punktu w idzenia rozwoju i konserwacji oprogram ow ania użytkow ego są oczywiste. Diametralnie różne zasady tw orzenia architektury m onolitycznych i obiektowych system ów inform atycznych są schematycznie pokazane na rysunku 5. C echą najistotniejszą z punktu w idzenia wykorzystania funkcji użytkowych systemów inform atycznych w dialogach w spom agających realizację zadań określonych w ram ach procesu pracy sterowanego przez system ZPP je st możliwość bezpośredniego odw oływ ania się do poszczególnych klas obiektów z poziomu program u obsługującego dialog. W przypadku architektury monolitycznej jedynie dobrze zdefiniowany i opisany interface program ów aplikacyjnych (API) daje podobne możliwości. Jest to rzadka cecha monolitycznych systemów inform atycznych, gdzie program ow e odw oływ anie się do indywidualnych funkcji użytkowych je st trudne lub wręcz niem ożliwe i w ym aga wprow adzenia odpow iednich zmian w oprogram ow aniu takiego systemu.
Pow szechnie akceptowanym podejściem do tworzenia rozproszonych system ów obiektowych jest architektura zaproponow ana przez Object M anagem ent Group (OM G95) nazw ana Common Object Request Broker A rchitecture (CORBA). OMG je st organizacją non-profit skupiające około dwustu firm informatycznych, w tym wszystkich znaczących producentów sprzętu i oprogram owania, której celem jest w ypracowanie standardowej architektury rozproszonych system ów obiektowych. Już w chwili obecnej wszystkie znaczące platformy UNIX są w yposażane w oprogram ow anie ORB zgodne ze specyfikacją OMG. A rchitekturę CORBA oraz możliwy sposób jej integracji z systemami ZPP pokazano na rysunku 6.
J a k o obiekt
O b iek ty aplikacyjne S ZP P
F unk cjo n aln o ść pionow a W s p ó ln e m e c h a n iz m y
F u n k cjo n a ln o ść p o ziom a
Object Request B roker
U słu g i o b ie k to w e SZPP J a k o ko n tek st
Rys. 6. Integracja systemu ZPP z architekturą OMG CORBA.
Object Request Broker stanowi oprogram ow ania pośredniczące (m iddleware) pozwalające na standardow ą rejestrację klas obiektów, taka rejestracji jest realizowana w oparciu o specyfikację w IDL (Interface Definition Language), oraz zapewniającym adresow alność obiektów stanowiących w ystąpienia takich klas, niezależnie od
węzia sieci w którym się aktualnie znajdują. Zastosowanie tego oprogram ow ania pozwala na uzyskanie całkowitej niezależności oprogram ow ania systemów inform atycznych od rozproszenia w ramach sieci. Podstawowym i elem entam i architektury CORBA są Wspólne M echanizm y (Com m on Services), Usługi Obiektowe (Object Services), oraz Obiekty Aplikacyjne (Application Objects).
W spólne M echanizm y stanowiące funkcjonalhość p oziom ą obejm ują usługi technologiczne, takie jak na przykład obsługa interface’u graficznego lub przetw arzania transakcyjnego, dostępne dla tw órców oprogram ow ania obiektów aplikacyjnych. Takie zaklasyfikowanie tych m echanizm ów wynika z ich niezależności od poszczególnych obszarów zastosowań. O dwrotna natomiast sytuacja ma m iejsce w przypadku funkcjonalności poziom ej obejmującej m echanizm y (klasy obiektów) związanych z konkretnym obszarem zastosowań. Przykładem takich klas obiektów m ogą być obiekty obsługujące konwersję w alut lub wyliczanie oprocentow ania lokat kapitałowych.
Usługi obiektowe są dostępne jako kom pletne funkcjonalnie m echanizm y stanow iące kolekcje wzajemnie powiązanych i w spółpracujących klas obiektów spełniających pewne konkretne funkcje o ogólnym zastosowaniu.
Przykładem takich usług m ogą być mechanizm y odw zorow ania w ystąpień obiektów w relacyjnej bazie danych czy obsługa kom unikacji sieciowej według określonego protokołu. Takie kom pletne m echanizm y usługow e są rów nież nazywane kontekstam i (fram eworks).
Obiekty aplikacyjne stanow ią oprogram owanie realizujące funkcje użytkowe systemu inform atycznego. Takie oprogram owanie jest zazwyczaj tworzone na potrzeby konkretnego systemu inform atycznego. M oże ono być również dostępne w formie bibliotek klas obiektów, w tym przypadku istnieje duże podobieństw o pom iędzy takim oprogram owaniem a kontekstem , lub jako pakiet oprogram ow ania opatrzony odpowiednim interface’m, zw anym opakowaniem obiektowym (wrapping) pozwalającym na definicję jego funkcji w IDL.
System ZPP może być zintegrowany ze środowiskiem CORBA albo jako usługa obiektow a, i w takiej sytuacji musi być opatrzony odpowiednim opakówaniem pozw alającym na odw ołania do jeg o funkcji za pośrednictwem ORB, lub jako aplikacja. W tym drugim przypadku odwołania do obiektów w spom agających realizację zadań określonych w czynnościach grafu procesu następują w m om encie uruchom ienia takiego zadania, w przypadku automatycznej obsługi, lub w trakcie wykonania program u obsługującego dialog.
4. Z a ry s m etodyki p ro jek to w an ia zastosow ań system ów Z P P
D ziedzina systemów ZPP znajduje się w etapie wczesnego rozwoju a doświadczenia w zakresie zastosowań tych systemów są tak rozproszone, że trudno jest dokonać uogólnienia zasad analizy i projektow ania w celu stworzenia m etodyki realizacji. Pewne spostrzeżenia w ynikające z analizy 12 aplikacji system ów ZPP w Holandii przedstawiono w [JOOS96].
Naszym doświadczeniem jest praca nad realizacją system u zarządzania dokum entam i i przepływem pracy dla M inisterstwa Pracy i Polityki Socjalnej. Okazało się ju ż w trakcie fazy analizy i projektow ania pojęciowego, że stosowanie klasycznej metodyki, w przypadku RODAN SYSTEM je st to obiektowa m etodyka OM T (Object M anagem ent Technique) [RUMB92], nie daje właściwych rezultatów. W tej sytuacji dokonano istotnej zm iany m etodyki w trakcie realizacji projektu a uzyskane rezultaty w fonnie w drożenia obsługi pierwszej grupy procesów pracy stanow ią pozytyw ną weryfikację naszego podejścia.
Analiza stanu istniejącego i projekt pojęciowy są realizowane z wykorzystaniem technik opisu scenariuszy (use cases) zaproponowanej przez Jacobsona w [JA C 092], przy czym sam a definicja scenariusza je st istotnie różna od podejścia Jacobsona. Każdy scenariusz jest definiowany w oparciu o kilka powiązanych wzajem nie modeli, a m ianowicie m odel procesu, m odel dialogu, oraz cząstkowy m odel danych. Projekt pojęciowy zawiera, poza definicją scenariuszy, rów nież zintegrow any m odel danych. Niezależnie od modeli graficznych realizow anych w środowisku systemu ObjectTeam firmy Cayenne Software zastosowano odpow iednie formularze. M etodyka je st opisana w [RODA96]
M odel procesu jest definiowany jako zorientowany graf, którego w ierzchołkam i są czynności procesu realizującego dany scenariusz a krawędziami zależności następstw a zachodzące pom iędzy tym i czynnościam i. N a poziom ie pojęciowym g raf nie musi być acykliczny. Takie w ym aganie może pojawić się na niższych poziomach definicji grafu procesu w zależności od stosowanego systemu ZPP. Do opisu grafu procesu zastosow ano notację State Tranistion Diagram (STD) zaproponow aną w OMT, przy czym interpretacja symboli graficznych jest istotnie różna.
M odel dialogu, który jest tworzony dla każdej czynności opisanej w grafie procesu, pokazuje przebieg dialogu inicjowanego w trakcie wykonania zadania odpow iadającego definiowanej czynności. Zastosow ano notację
E vent Trace Diagram proponow aną w OMT. N aturalnie w przypadku autom atycznej obsługi zadania model dialogu jest tryw ialny i wskazuje jedynie na program, lub klasę obiektu do której ma nastąpić odwołanie.
C ząstkow y model danych opisywany w notacji Class Association Diagram (CAD) stosowanej w OM T definiuje sem antykę w ycinka rzeczywistości objętego projektowanym scenariuszem . Integracja cząstkow ych modeli danych następuje po zaprojektowaniu wszystkich scenariuszy i jest w ykonyw ana zgodnie z zasadami przyjętym i w [BATI92],
Kolejne fazy realizacji systemu przebiegają zgodnie z m etodyką RODAN N T i polegają na stopniowym uściślaniu pow yższych modeli. N aturalnie na poziom ie realizacji prototypu i konstrukcji systemu stosuje się narzędzia specyfikacji dostępne w wykorzystyw anym oprogramowaniu narzędziowych. Ze w zględu na fakt, że zasady notacji pozostają takie same w ram ach poszczególnych modeli, odw zorow ania pom iędzy różnymi środow iskam i ich opisu są trywialne.
P o d s u m o w a n ie
Zastosow ania systemów ZPP znajdują się w stadium początkowym , chociaż ogromne zainteresowania tą dziedziną, wynikające z rosnącej liczby projektów reinżynierii procesów działalności, je st ewidentne. W tej sytuacji należy oczekiwać ciągłej ewolucji systemów ZPP zarów no w zakresie ich m ożliw ości technicznych jak w zakresie rozw oju metod ich stosowania i eksploatacji.
Nasze prace zm ierzają do ugruntowania podstaw m etodycznych tw orzonych w oparciu o praktyczne dośw iadczenia realizowanych systemów inform atycznych oraz do akumulacji kapitału praktycznych rozwiązań, który m oże być ponownie w ykorzystany w formie w zorców rozwiązań (pattem s) [GAMM94] lub w ręcz gotowego oprogram ow ania obiektowego.
L ite r a t u r a
BAT192 Batini, C., Ceri, S., Navathe, S., Conceptual Database Design: An Entity-Relational Approach, Benjamin Cummings, 1992.
GAM M 94 Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Pattem s, Elements o f Reusable Object- Oriented Software, A ddison-W esley Professional Computing Series, 1994
GEOR95 Georgakopoulos, D., H om ick, M., and Sheth, A., An overview o f w orkflow management: from process modeling to w orkflow autom ation infrastructure, in Distributed and Parallel Databases, 3, 1995, Kluwer Academic Publishers, Boston, USA.
IBM95 Dokumentacja użytkowa IBM FlowM ark, IBM, 1995.
JA C 0 9 2 Jacobson, L, Object-Oriented Software Engineering - A Use Case Driven A pproach, ACM Press, Addison-W esley, 1992.
JO O S94a Joosten, S., Trigger m odelling for workflow analysis, in Proceedings CON ‘94: Workflow Management, Challenges, Paradigm s and Products (O ctober 1994), A.B.G. Chroust (Ed.), Oldenbourg, W ien/M unchen.
JO O S94b Joosten, S., Aussems, G., Duitshof, M., Huffmeijer, R., and M oulder, E., W a-12: an empirical study about practice o f w orkflow managem ent, Tech. Rep., University o f Twente, Dept, o f Com puter Science, 1994.
JOOS96 Joosten, S., Brinkkemper, S., Fundam ental concepts for w orkflow autom ation in practice, Proceedings o f the 5th Int. Conference on Information System Developm ent, Gdańsk, September
1996.
M ARS94 Marshak, R., Software to Support BPR - The value o f Capturing Process Definitions, Workgroup Computing Report, Patricia Seybold Group, Vol. 17, No. 7., July, 1994.
OM G95 Common Objext Request Broker A rchitecture and Specification, Object M anagem ent Group, June, 1995.
RODA96 M etodyka Realizacji System ów Inform atycznych RODAN N T, Rodan System Sp. z o.o., Warszawa, 1996.
RUMB92 Rumbaugh, J., Błaha, M., Premerlani, W., Eddy, F., Lorensen, W., O bject-Oriented M odelling and Design, Prentice-Hall International Inc, 1992.
SILV95 Silver, B., BIS Guide to W orkflow Software: A Visual Comparison o f T oday’s Leading Products, BIS Strategic Decisions, Septem ber 1995.
W ORK94 W orkflow M anagem ent Coalition. Information Pack. Grenoble. France. Juiv 1994
W. Staniszkis, B. Kiepuszewski, M. Nahum Ferber, T. Piórkowska, D. Putem icki, and K. Subieta
RODAN SYSTEM Jagielska 50c 02-886 W arszawa
POLAND
W itold.Staniszkis@ rodan.w aw .pl
I n t e g r a t e d D o c u m e n t / W o r k f l o w M a n a g e m e n t S y s te m A r c h i t e c t u r e
A b s tr a c t
An integrated DW M S architecture com prising IBM FlowM ark, Lotus N otes and Office Objects is presented.
Office Objects com prises a library o f C++ object classes supporting docum ent imaging and hierarchical storage m anagem ent. The object-oriented analysis and design platform based on OMT, extended with the Use Case and D ialogue M odel notations, provides the system design and implementation paradigm. M appings from design m odels into the Lotus N otes docum ent and FlowM ark process models are discussed. A pilot application o f the architecture is outlined.
1. I n tr o d u c tio n
The rapid proliferation o f w orkflow systems, i.e. information system s utilising the workflow m anagem ent technology, has been inhibited by several im portant factors resulting from relative im m aturity o f this area. A thorough discussion o f the current gaps and the required developm ent, both on the research as well as engineering level, has been presented in [GEOR95]. O ur practical experience with w orkflow systems, both from the proprietary software as well as application developers perspective, has shown that the principal challenges lie in the system architecture as well as the application developm ent m ethodology areas. Therefore, we are focusing on these two aspects o f our current developm ent work in the area o f workflow systems.
The Integrated Document/W orkflow M anagem ent System (DW MS) is proposed as a developm ent platform providing a common control layer for docum ent m anagem ent as well as transaction-oriented application functions. A study o f application requirem ents presented in [JOOS94b, JOOS96] has shown that the advanced workflow system s require document m anagem ent, such as document imaging, storage, and retrieval functions, as well as general purpose processing functions, that may require access to various application system s concurrently active within a com puter network. We discuss the architecuire and requirem ents o f such system s in the following section.
Our application development work at the M inistry o f Labour and Social Policy (M OLP) o f Poland, having an objective to automate principal office procedures o f the ministry, has shown in a very early stage that a classic information system development m ethodology is not sufficiently universal to allow for the rigorous system s analysis and conceptual design specification, required both by the future system users as well as by the developers involved in the ensuing system design and implementation phases o f the M OLP project. The m ethodology initially used was, following our com pany standard, the Object M anagem ent Technique (O M T) proposed in [RUM B92]. Although an object-oriented m ethodology is suitable for distributed information system analysis and design, rather important enhancem ents o f the OM T m ethodology were necessary, before a w orkable w orkflow system could be designed and im plem ented. We outline the m ethodology in section 3 o f this paper and further clarify its notation with the use o f a b rief exam ple presented in the appendix.
Finally, we conclude the paper discussing the pros and cons o f the approach adopted for the M OLP system developm ent concentrating both on the architecture as well as the m ethodology aspects o f our w ork.
Future directions o f our research and developm ent w ork in the area o f workflow systems are succinctly outlined.
P r e s e n te d a t th e I n t e r n a tio n a l IB M W o r k flo w C o n fe r e n c e ‘9 6 , D a lla s -F t. W o r th , N o v e m b e r 1 1 -1 3 , 96.
2. T h e D W M S a r c h i t e c t u r e
The advent o f distributed client/server architectures freely deployed on open com puter platform s has considerably increased the com plexity o f information software design and im plem entation process. The advanced com puting environm ents com prise many heterogeneous, autonom ous and distributed systems (HAD), starting from personal com puting environm ent, e.g. M icrosoft Office, deployed on the client workstations, and leading to m ainfram e transaction system s m anaging complex business data. The technical issues associated with HAD environm ents as exhaustively discussed in [GEOR95], The general principles underlying such environm ents in conjunction with the w orkflow m anagem ent system s are illustrated in figure 1.
Di a l og u e
Di s t r i but ed Obj ect Ma n a g e me n t Sys t e m
Î
( Obj e c t M a p p i n g Sys t e m
♦ ♦ ♦
RDBMS OODBM S EDMS
Figure 1. A generalised w orkflow HAD architecture.
A workflow specification, represented by a directed graph, provides a process class description catering for all possible conditions o f process instance executions, which are corresponding to a particular path in the process graph. The im poitant characteristic o f the process graph is that the process activities, represented by graph vertices, m ay be executed autom atically by application functions (com puter program s) or manually by users participating in the business process controlled by the w orkflow system.
In the first case, the w orkflow specification, i.e. the w orkflow directed graph, corresponds to a script, ranging over a num ber o f processing platform s integrated within a com puter network, representing the control flow in a fully autom ated distributed com puting process invoking processing functions either through a classic RPC protocol, or with the use o f a distributed object m anagem ent system, such as OMG CORBA [OMG95] or M icrosoft’s DCOM . In this case, the fully autom ated process resem bles a distributed transaction. Hence the ACID model requirem ents may be met, provided that all underlying object m apping subtransactions are supported by the ACID model com pliant transaction control functions. A lternatively, a custom ised transaction m anagem ent can be used. The object m apping m anagem ent function is required in order to provide a facility to store and update persistent objects. The m ost common repositories used to store persistent objects are relational database m anagem ent systems (RDBM S), object-oriented database managem ent system s (OODBM S), and electronic docum ent m anagem ent systems (EDM S). The workflow transaction m anagem ent solutions would in such cases em ploy techniques like com pensating subtransactions and process event logs. The obvious requirem ent is that the w orkflow m anagem ent systems support the required functionality, e.g. the process activity log [IBM95],
In the second case, the m anual activity creates an entirely different processing environm ent, namely an interactive m an/m achine environm ent, usually supported by a GUI, hosted in the client w orkstation invoking
local and/or rem ote processing functions. In an object-oriented environm ent, one would expect to have an event- driven GUI m anagem ent, usually developed in Visual Basic, Smalltalk or sim ilar languages, featuring object classes as program variables. The object instances, representing business objects or legacy system wrappings [OM G95], m ay be accessible either by an ORB [OMG95] or sim ilar m iddleware (e.g. M ocrosoft’s DCOM).
M ost o f the application logic would norm ally reside in the object class specification. A m onolithic system architecture m ay also be used provided that the required invocation granularity is supported by an API.
In both o f the above cases, distribution independence is supported, and, in the case o f the object- oriented approach im plem enting object persistence with the use o f an object m apping system , also data independence may be attained. Business objects, like com pound docum ents, may be m apped into various data repository types, and the m apping algorithm s are usually com prised in the object class method logic. Standard m appings, like for example the object - relational data m apping, are autom atically supported by object-oriented CASE tools, e.g. C ayenne’s ObjectTeam , that generate the required m apping m ethod logic to store, update, and retrieve the object data structures. The referential integrity constraints are also supported by generation o f the required database procedures and triggers.
The generalised w orkflow system architecture represents technological requirem ents that should be m et by any advanced DW M S architecture. Our design approach has been based on the above requirem ents and the resulting architecture is shown in figure 2.
Figure 2. The DWMS architecture.
The integrated DWMS architecture features the IBM proprietary software systems, such as Lotus Notes and IBM FlowMark. the Office Objects library o f classes developed and marketed by RODAN SYSTEM , and the object-oriented CASE tool ObjectTeaih for OMT developed by Cayenne Software. Our added value lies in seam less integration o f the above proprietary software environm ents, as well as in the application developm ent m ethodology and skills. The dialogue scripts are currently developed in Visual Basic and CA OpenROAD.
The definition environm ent comprises model specification facilities used according to our design m ethodology, namely ObjectTeam to support the analysis and conceptual models, the IBM FlowM ark Development Client to implement the process graph, and the Lotus Notes client to define docum ent classes. The TCL [OUST94] have been developed within the ObjectTeam lower CASE functionality to generate the FDL skeletons o f FlowM ark processes as well as the partial LN docum ent descriptions. Thus, consistency o f the conceptual and logical levels o f the workflow system specification is maintained.
The DW MS execution environm ent com prises client and servers o f three principal building blocks, nam ely IBM FlowM ark, Lotus Notes, and Office Objects. However, the end user sees the system through the Flow M ark Runtim e Client perspective and the process task execution is supported by the dialogue scripts developed in Visual Basic and CA OpenROAD. Lotus N otes and Office Objects functions are invoked via the respective A P I’s or the OLE protocol. The DW MS execution environm ent program module structure is shown in figure 3.
> ££
lilin
<
GG
ZUJ 0
Figure 3. The DW M S execution environment.
The client user interface running in the MS W indow s 3.11 or Windows 95 environm ent comprises the FlowM ark Runtime Client and a collection o f User D ialogue m odules jointly providing the principal platform the user/w orkflow system interaction. The dialogue m odules com m unicate with the Lotus Notes server via the API Broker, that may easily be extended to handle other A P I’s or CORBA object messages. The user dialogues supporting w orkflow process tasks selected from a Flow M ark work list com m unicate with the docum ent database, or possibly with any other information system , presenting documents, parts o f documents, docum ent images, or electronic forms required to fulfil the process task data requirements. The LN docum ent database is also accessible via the Lotus Notes Client providing the standard LN functionality extended.w ith the document imaging functions supported by the Office Objects Im aging Set functions accessible via the OLE protocol. The m iddlew are level comprises also the HSM Retriever m odule that supports selection o f the Lotus Notes docum ent fields stored in devices controlled by the Office Objects H ierarchical Storage M anagem ent functions.
The Office Objects Hierarchical Storage M anager (HSM ) for Lotus Notes has been implemented as the Lotus Notes Server Add-in task and its principal function is to support the bi-directional migration o f LN docum ent field am ong storage devices appropriately defined within the migration paths hierarchy levels, nam ely the magnetic disks, the jukeboxes and m agnetic tapes. The architecture o f the Office Objects HSM is shown in figure 4.
Office Objects HSM is responsible for the m igration o f documents to lower cost storage, ensuring a cost effective and still efficient docum ent storage. D ocum ents are taken from the specified sources and are stored in a set o f mass storage devices o f different kinds: m agnetic, optical, WORM, CD-ROM, DAT, following custom made predicates, called the migration rules. D ocum ents or part o f the them, can be reconstituted on demand, by sim ply retrieving them from the closest available data repository to the source, making HSM completely transparent to the end-user. Migration rules are triggered by time events, such as frequency or specific dates when the rule is to be executed, or external events, such as conditions on the available space in a repository.
The architecture o f HSM consists o f the migration server available as the Add-In task to Lotus N otes used as the engine to m igrate N otes iterns, the retrieve client and server used to restore the migrated items to their original location, the HSM editor used by the system adm inistrator to define the m igration paths and rules, and the Repository server used as the interface to the different storage devices com prised in the storage hierarchy as repositories to m igrated items throughout the network.
The H SM -m anipulates data objects which are generally non-structured binary data. These objects are stored in data repositories and an index is created for further references. A pointer to the object is stored in the original docum ent to be used when retrieving the m igrated parts, if necessary. Data repositories are organized in m igration paths. A migration path is a chain o f repositories o f different kinds through which data objects are m igrated. Each repository in a migration path represents a level, level 0 being the beginning o f the chain, thus, the source o f docum ents.
Figure 4. The Office Objects Hierarchical Storage M anagem ent architecture
The m igration rules have two aspects: the scope o f the rule and the schedule execution schedule o f the rule. The scope o f the rule identifies documents or parts o f docum ents that are to be migrated. The rules are defined as standard ( ANSI compliant ) SQL sentences, com prising arguments, such as names and attributes dependent on how the source documents are organized. The execution scheduling o f the rule indicates when the rule should be evaluated. A rule can be scheduled on specified intervals (seconds, minutes, hours, days) with a resolution o f 10 seconds, on specified days (day o f the w eek, day o f the month) at a specific hour, or on the basis o f an external condition or event, such as for example filling up o f a docum ent repository.
The task o f HSM for Lotus Notes is to m igrate N ote’s fields that are not involved in full-text indexing such as file attachm ents and presentation records o f com posite fields. These are binary data fields, which are usually large. Entire documents are not removed from the N otes databases, making possible to search and find
„m igrated docum ents” ; w henever the document is requested, a dem and for the missing fields is made to m igrate upwards the necessary data items.
The m igration rules text have the following syntax and appropriate semantic:
S E L E C T <item name>, <item name>, ...
F R O M <docum ent class>, <docum ent class>, ...
W HERE <where clause>
where:
