Erl T. - SOA. Koncepcje, technologie i projektowanie

O pinie o książkach Thomasa Erla „Architektura zorientowana na usługi to tem at gorący, lecz często opacznie pojmowany. Thomas fachowo opisuje koncepcje, specyfikacje i standardy związane ze zorientowaniem na usługi i usłu­ gami sieciowymi. Dla przedsiębiorstw adaptujących swe środowisko do standardów SOA to szcze­ gółowy przewodnik po analizie zorientowanej na usługi, planowaniu i projektowaniu. Tę książkę trzeba przeczytać!” — Alex Lynch, głów ny k o n su ltan t, M icrosoft E n terprise Services

„Jednym z podstawowych celów zastosowania SOA w projektowaniu jest dostarczenie wartości biznesowych do budowanych rozwiązań. Krytyczne jest zrozumienie znaczenia właściwego po­ dejścia do analizy, projektowania i program owania rozwiązań zorientowanych na usługi. Thomas wykonał naprawdę dobrą robotę, uwalniając SOA od mitów i nadając jej w tej książce praktyczne znaczenie”. — Rick W eaver, starszy k o n su lta n t IBM, licencjonow any k o n su lta n t pro g ram isty czn y

„Pragmatyczny przewodnik po zasadach SOA, strategiach i zalecanych praktykach; zamiast zbędnej wrzawy ramowe podejście do adaptacji SOA na gruncie złożonych środowisk korporacyjnych”. — S am eer Tyagi, S enior S taff E ngineer, Sun M icrosystem s

„Aktualny i jakże cenny wkład w tę burzliwie rozwijającą się dziedzinę wiedzy. Wyjaśniając zasady i niuanse tego skomplikowanego świata, autor dostarcza wnikliwe studium kluczowych aspektów SOA, od analizy i planow ania do opisu standardów WS-* i BPEL. Rekomenduję tę książkę za­ równo kolegom po fachu, jak i klientom zmierzającym w stronę SOA”. — Ravi P alep u, S enior F ield A rchitect, R ogue W ave Softw are

„Wreszcie książka oparta na realnych doświadczeniach implementacyjnych w środowisku pro­ dukcyjnym. Czytając wiele książek na temat SOA, można po prostu ugrzęznąć w gąszczu technicz­ nych szczegółów albo ogłuchnąć w zgiełku reklamy tego czy innego dostawcy. Ta książka traktuje o napraw dę ciężkiej pracy — skom plikowanych procesach planowania, projektowania i im ple­ mentow ania architektur zorientowanych na usługi w sposób zapewniający osiągnięcie celów wy­ tyczonych przez organizację. Książkę tę można śmiało polecić wszystkim programistom, architek­ tom i menedżerom projektów, którzy implementują — albo myślą, że implementują — architekturę zorientowaną na usługi”. — Priscilla W alm sley, d y re k to r ds. m a rk e tin g u D atypic

„Książka SOA. Koncepcje, technologie i projektowanie Thom asa Erla jest wprowadzeniem do tem atyki architektur zorientow anych na usługi, wprowadzeniem najlepszym, jakiego m ożna by sobie życzyć. W jednym tomie omawiany jest cały temat, od teorii poprzez przykłady zastosowań do szczegółów technicznych. Przykłady są znakomite i wyjątkowo czytelnie sformułowane”. — R onald B ourret, a u to r XM L a n d D atabases

„Doczekaliśmy się książki o SOA traktującej o problemach realnego świata i przykładach ich roz­ wiązywania. Erl zabiera nas na wycieczkę po świecie SOA: od projektów architektonicznych do standardów przemysłowych — książka naprawdę napisana jest bardzo dobrze i śmiało m ożna ją polecić do codziennego użytku. Rozpoczynając swą własną przygodę w krainie orientacji na usługi, nie zapomnij zabrać tej książki do plecaka”. — C lark Sell, w iceprezes CSell In c o rp o ra ted

„Organizacje borykające się z przeszkodami na drodze ewolucji istniejących rozwiązań poza proste usługi sieciowe otrzymują teraz poradnik napisany przez eksperta. Prowadząc w kierunku przed­ siębiorstwa prawdziwie zorientowanego na usługi, Thomas Erl demitologizuje jednocześnie zło­ żoność standardów WS-I i wyjaśnia ich detale za pomocą praktycznych opisów i analiz przypadków. Głębia i czytelność ujęcia tem atu czyni tę książkę znakomitym uzupełnieniem Field Guide”. — d r Kelvin P. Davis, arch itek t opro g ram o w an ia

„Książka jest znakom itym przewodnikiem dla architektów, program istów i m enedżerów pracują­ cych już nad usługami sieciowymi i rozwiązaniami zorientowanymi na usługi bądź rozważających taką ewentualność w bliskiej perspektywie. Książka podzielona jest na cztery części. W pierwszej opisywane są fundam entalne technologie związane z XML, usługami sieciowymi i architekturami zorientowanymi na usługi, z należytym uwzględnieniem ukształtowanych — i kształtujących się — standardów . Książka napisana jest bardzo dobrze, z dogłębnym ujęciem tem atu. Polecam ją gorąco każdemu zainteresowanemu architekturą usług na poziomie enterprise”. — A dam H ocek, prezes i d y re k to r tech n iczn y B roadstrokes, Inc.

Więcej opinii znaleźć można na stronie www.serviceoriented.ws/reviews.asp.

Spis treści

Przedm ow a ............................................................................................................................................................... 17 Rozdział 1. W prow adzenie ...................................................................................................................................19 1.1. Dlaczego ta książka jest w ażn a?.........................................................................................................20 1.1.1. Fałszywa S O A ............................................................................................................................................................ 20 1.1.2. Ideał S O A .................................................................................................................................................................... 21 1.1.3. R ealna S O A .................................................................................................................................................................21

1.2. Cele tej książki ..................................................................................................................................... 22 1.2.1. Podstaw y SOA, o rientacji n a usługi i u słu g sie cio w y c h ............................................................................... 22 1.2.2. Jak budow ać SOA n a bazie u słu g sieciowych? .................................................................................................23

1.3. Dla kogo przeznaczona jest ta książka? ............................................................................................23 1.4. Czego w tej książce nie ma? ............................................................................................................... 23 1.5. Organizacja tej książki ........................................................................................................................ 24 1.5.1. Część I. SO A i fu n d a m e n ty u słu g sieciow ych ................................................................................................. 24 1.5.2. Część II. SOA i rozszerzenia W S-* .....................................................................................................................26 1.5.3. Część III. SO A i zorien to w an ie n a usługi .........................................................................................................28 1.5.4. Część IV. B udow anie SO A (planow anie i a n a liz a ) ........................................................................................ 29 1.5.5. Część V. B udow anie SO A (technologie i p ro je k t)...........................................................................................30 1.5.6. K onw encje stylistyczne — uw agi ........................................................................................................................ 33

1.6. Informacja d odatkow a........................................................................................................................ 33 1.6.1. F ram ew o rk X W IF (XM L & W eb Services In teg ra tio n F ram ew ork) .........................................................33 1.6.2. w w w .serviceoriented.w s .........................................................................................................................................33 1.6.3. K o n tak t z a u to r e m ....................................................................................................................................................33

Rozdział 2. Analizy p rz y p a d k ó w ........................................................................................................................ 35 2.1. Jak prezentowane są analizy przypadków? ......................................................................................36 2.1.1. S ty lis ty k a ..................................................................................................................................................................... 36 2.1.2. Z w iązek z t r e ś c i ą ....................................................................................................................................................... 36 2.1.3. Przykładow y k o d ...................................................................................................................................................... 36

2.2. Przypadek nr 1: RailCo Ltd................................................................................................................. 37 2.2.1. H isto ria ........................................................................................................................................................................37 2.2.2. In fra stru k tu ra te c h n ic z n a .......................................................................................................................................37 2.2.3. R ozw iązania a u to m a ty z a c y jn e ..............................................................................................................................37 2.2.4. Cele biznesow e i p rz e s z k o d y ................................................................................................................................. 37

6

SPIS TREŚCI

2.3.

P r z y p a d e k n r 2: T r a n s it L in e S y s te m s I n c ....................................................................................................... 39 2.3.1. H isto ria ........................................................................................................................................................................39 2.3.2. In fra stru k tu ra te c h n ic z n a .......................................................................................................................................39 2.3.3. R ozw iązania a u to m a ty z a c y jn e ..............................................................................................................................40 2.3.4. Cele biznesow e i p rz e s z k o d y ................................................................................................................................. 40

Część I. Fundamenty SOA i usług sieciowych ............................................................ 43 Rozdział 3. W prow adzenie do S O A ................................................................................................................... 45 3.1. F u n d a m e n t y S O A ............................................................................................................................................................ 46 3.1.1. O rientacja n a usługi — analogia ......................................................................................................................... 46 3.1.2. Jak u sługi e nkapsulują logikę? ..............................................................................................................................47 3.1.3. Jak pow iązane są u s łu g i? .........................................................................................................................................48 3.1.4. Jak k o m u n ik u ją się u s łu g i? .................................................................................................................................... 48 3.1.5. Jak p ro jek tu je się usługi? ........................................................................................................................................49 3.1.6. Jak zbudow ane są usługi? .......................................................................................................................................50 3.1.7. P ie rw o tn a SO A ......................................................................................................................................................... 50 3.2. O g ó ln ie o w s p ó łc z e s n e j S O A .....................................................................................................................................52 3.2.1. W spółczesna SO A jest najw ażniejszą sp o śró d p latfo rm z orientow anych n a u s ł u g i .......................... 53 3.2.2. W spółczesna SO A przyczynia się do podw yższenia jakości u s łu g ............................................................53 3.2.3. W spółczesna SO A jest zasadniczo a u to n o m ic z n a ......................................................................................... 54 3.2.4. W spółczesna SO A bazuje n a otw artych s ta n d a r d a c h ...................................................................................54 3.2.5. W spółczesna SOA w spiera zróżnicow anie dostaw ców ............................................................................... 55 3.2.6. W spółczesna SOA p ro p a g u je w ykryw alność .................................................................................................. 56 3.2.7. W spółczesna SOA w spiera n a tu ra ln e w spółdziałanie ..................................................................................56 3.2.8. W spółczesna SOA pro p ag u je federacyjność ................................................................................................... 57 3.2.9. W spółczesna SO A pro p ag u je k o m p o n o w aln o ść arch itek to n iczn ą ......................................................... 57 3.2.10. W spółczesna SO A sprzyja w rodzonej w ie lo u ż y w a ln o ści............................................................................ 58 3.2.11. W spółczesna SO A eksponuje rozszerzalność ................................................................................................. 59 3.2.12. W spółczesna SO A w spiera p a rad y g m at zorientow anego usługow o m odelow ania b iz n e s u

60

3.2.13. W spółczesna SO A im p lem en tu je w arstw y a b s tra k c ji...................................................................................60 3.2.14. W spółczesna SO A p ro m u je luźne p o w iązania k o m p o n e n tó w in fra stru k tu ry IT ...............................61 3.2.15. W spółczesna SO A p ro p a g u je zw inność o r g a n iz a c y jn ą ............................................................................... 61 3.2.16. W spółczesna SO A jest b u d u lc e m ........................................................................................................................ 63 3.2.17. W spółczesna SO A oznacza e w o lu c ję ..................................................................................................................63 3.2.18. W spółczesna SO A jest m odelem w ciąż dojrzew ającym .............................................................................. 64 3.2.19. W spółczesna SO A jest dążeniem do i d e a ł u ..................................................................................................... 64 3.2.20. Z definiow anie S O A ..................................................................................................................................................64 3.2.21. Podział c h a ra k te ry sty k i........................................................................................................................................... 65 3.3. N a jc z ę s ts z e n i e p o r o z u m i e n ia d o ty c z ą c e S O A ....................................................................................................66 3.3.1. „A plikacja korzystająca z u słu g sieciow ych jest aplikacją z o rie n to w an ą n a u słu g i” ...........................66 3.3.2. „SOA to now e h asło m arketingow e dla starych u słu g sieciow ych” ......................................................... 67 3.3.3. „SOA to now a etykietka dla p rzetw arzania rozproszonego opartego n a usługach sieciow ych” .......67 3.3.4. „SOA upraszcza p rzetw arzan ie ro z p ro szo n e ” ................................................................................................. 67

SPIS TREŚCI

7

3.3.5. „A plikacja z u słu g am i sieciow ym i, w ykorzystująca rozszerzenia W S-*, jest aplikacją zo rien to w an ą n a u sługi” ........................................................................................................... 68 3.3.6. „Jeśli znasz u sługi sieciowe, bez p ro b le m u zbudujesz SO A ” ......................................................................68 3.3.7. „G dy przejdziesz n a SOA, w szystko zacznie w spółdziałać” ........................................................................68

3.4. Najważniejsze wymierne pożytki z S O A ..........................................................................................69 3.4.1. U sp raw n io n a integracja (i n a tu ra ln e w spółdziałanie) ..................................................................................69 3.4.2. W b u d o w an a w ieloużyw alność .............................................................................................................................70 3.4.3. Eleganckie a rch ite k tu ry i r o z w ią z a n ia ............................................................................................................... 70 3.4.4. S pożytkow anie daw nych in w e sty c ji....................................................................................................................70 3.4.5. Jednolite rep rezen to w an ie danych w standardzie X M L .............................................................................. 71 3.4.6. S k oncentrow ane inw estow anie w in frastru k tu rę k o m u n ik a c y jn ą ............................................................71 3.4.7. W y b ó r najlepszego w a rian tu ................................................................................................................................72 3.4.8. Z w inność o rg a n iz a c y jn a .........................................................................................................................................72

3.5. Najważniejsze pułapki w adaptacji S O A ..........................................................................................73 3.5.1. B udow anie a rch ite k tu ry zorientow anej n a usługi n a w zó r a rch ite k tu ry tradycyjnej ........................ 73 3.5.2. B rak standaryzacji ....................................................................................................................................................74 3.5.3. B rak p la n u tra n s fo rm a c ji........................................................................................................................................74 3.5.4. Początki bez X M L ..................................................................................................................................................... 75 3.5.5. Ignorow anie w ym agań w ydajnościow ych S O A ..............................................................................................75 3.5.6. N iedocenianie bezpieczeństw a u słu g sieciow ych .......................................................................................... 76 3.5.7. N iedotrzym yw anie k ro k u n ow oczesnym p latfo rm o m i sta n d ard o m ..................................................... 77

Rozdział 4. Ewolucja S O A .....................................................................................................................................79 4.1. Oś czasu SOA (od XML, przez usługi sieciowe, do SOA) ............................................................ 80 4.1.1. XM L — k ró tk a h is t o r ia ........................................................................................................................................... 80 4.1.2. U sługi sieciowe — k ró tk a h isto ria ...................................................................................................................... 81 4.1.3. SO A — k ró tk a h isto ria ........................................................................................................................................... 82 4.1.4. SO A a now e oblicze X M L i u słu g sieciow ych ................................................................................................. 83

4.2. N ieustanna ewolucja SOA (organizacje standaryzacyjne i kontrybutorzy)............................... 85 4.2.1. S tandardy, specyfikacje i ro z sz e rz e n ia ............................................................................................................... 85 4.2.2. O rganizacje standaryzacyjne zw iązane z S O A ................................................................................................ 85 4.2.3. C zołow i dostaw cy SO A ..........................................................................................................................................88

4.3. Korzenie SOA (SOA a tradycyjne arch itek tu ry ).............................................................................91 4.3.1. Co znaczy „ a rc h ite k tu ra ”? ......................................................................................................................................91 4.3.2. SO A a a rch ite k tu ra k lie n t-s e rw e r........................................................................................................................ 93 4.3.3. SO A a ro z p ro szo n a a rch ite k tu ra in te rn e to w a ................................................................................................. 98 4.3.4. SO A a h ybrydow a a rch ite k tu ra u słu g sieciow ych ....................................................................................... 106 4.3.5. O rientacja n a usługi oraz o rientacja n a obiekty (część I) .......................................................................... 108

Rozdział 5. Usługi sieciowe a pierw otna S O A .............................................................................................111 5.1. Framework usług sieciow ych........................................................................................................... 112 5.2. Usługi (jako usługi sieciowe) ........................................................................................................... 114 5.2.1. Role u słu g ................................................................................................................................................................. 115 5.2.2. M odele u s ł u g ............................................................................................................................................................125

8

SPIS TREŚCI

5.3. Opisy usług (w języku WSDL) ........................................................................................................ 128 5.3.1. P u n k ty końcow e u słu g i opisy u s łu g .................................................................................................................131 5.3.2. O pis a b s tra k c y jn y ...................................................................................................................................................131 5.3.3. O pis sk o n k re ty zo w a n y .......................................................................................................................................... 132 5.3.4. M etad an e i k o n trak ty u s ł u g ................................................................................................................................ 133 5.3.5. O pisy s e m a n ty c z n e .................................................................................................................................................134 5.3.6. O głaszanie i odnajdyw anie opisów u słu g .......................................................................................................135

5.4. Komunikowanie według S O A P....................................................................................................... 138 5.4.1. K om u n ik aty S O A P .................................................................................................................................................139 5.4.2. W ęzły SO AP .............................................................................................................................................................143 5.4.3. Ścieżki k o m u n ik a tó w ............................................................................................................................................ 146

Część II. SOA i rozszerzenia W S -*................................................................................ 149 Rozdział 6. Usługi sieciowe i współczesna SOA (Część I. Zarządzanie aktywnościam i ik o m p o zycje)......................................................... 153 6.1. Wzorce wymiany kom unikatów ................................................................................................... 155 6.1.1. P rym ityw ne w zorce M E P .....................................................................................................................................156 6.1.2. W zorce M EP i SO AP ............................................................................................................................................ 161 6.1.3. W zorce M EP i W S D L ........................................................................................................................................... 161 6.1.4. W zorce M EP a SO A .............................................................................................................................................. 163

6.2. Aktywności usług .............................................................................................................................. 163 6.2.1. P roste i złożone aktyw ności usług .................................................................................................................... 164 6.2.2. A ktyw ności usług a S O A ......................................................................................................................................165

6.3. K oordynacja........................................................................................................................................167 6.3.1. K om pozycja k o o rd y n a to ra .................................................................................................................................. 168 6.3.2. T ypy k o o rdynacyjne i p ro to k o ły k o o rd y n a c y jn e ..........................................................................................169 6.3.3. K ontekst k oo rd y n acji i uczestnicy k o o rd y n a c ji............................................................................................169 6.3.4. A ktyw acja i rejestracja .......................................................................................................................................... 170 6.3.5. Z akończenie koo rd y n acji .................................................................................................................................... 171 6.3.6. K oordynacja a S O A ................................................................................................................................................172

6.4. Transakcje n iepodzielne................................................................................................................... 173 6.4.1. T ransakcje A C I D ....................................................................................................................................................175 6.4.2. P ro to k o ły tran sak cji n ie p o d z ie ln y c h ................................................................................................................175 6.4.3. K o o rd y n a to r tran sak cji n ie p o d z ie ln e j............................................................................................................. 175 6.4.4. Proces tran sak cji niepodzielnej ......................................................................................................................... 176 6.4.5. T ransakcje n iepodzielne a S O A ......................................................................................................................... 178

6.5. Aktywności biznesow e...................................................................................................................... 179 6.5.1. P ro to k o ły aktyw ności b iz n e so w y c h ..................................................................................................................181 6.5.2. K o o rd y n a to r aktyw ności biznesow ych ........................................................................................................... 181 6.5.3. S tany aktyw ności b iz n e so w e j..............................................................................................................................181 6.5.4. A ktyw ności biznesow e a tran sak cje n ie p o d z ie ln e ....................................................................................... 182 6.5.5. A ktyw ności biznesow e a SO A ............................................................................................................................182

SPIS TREŚCI

9

6.6. O r k ie s tr a c je ...................................................................................................................................................................... 185 6.6.1. P ro to k o ły biznesow e i definicje p ro c e s ó w ......................................................................................................187 6.6.2. U sługi procesow e i u sługi p a rtn e rs k ie ............................................................................................................. 187 6.6.3. A ktyw ności p odstaw ow e i aktyw ności stru k tu raln e ...................................................................................188 6.6.4. Sekwencje, przepływ y i z łą c z a .............................................................................................................................188 6.6.5. O rkiestracje i aktyw ności .................................................................................................................................... 189 6.6.6. O rkiestracje i k oordynacje .................................................................................................................................. 189 6.6.7. O rkiestracje a S O A .................................................................................................................................................189 6.7. C h o r e o g r a f ie ....................................................................................................................................................................191 6.7.1. W s p ó łp r a c a ...............................................................................................................................................................192 6.7.2. Role i uczestnicy ..................................................................................................................................................... 193 6.7.3. Relacje i k a n a ły ........................................................................................................................................................ 193 6.7.4. Interakcje i jed n o stk i p r a c y ................................................................................................................................. 193 6.7.5. W ieloużyw alność, k o m p o n o w aln o ść i m o d u la r n o ś ć ..................................................................................193 6.7.6. O rkiestracje a choreografie ................................................................................................................................. 194 6.7.7. C horeografie a SOA .............................................................................................................................................. 195

Rozdział 7. Usługi sieciowe i współczesna SOA (Część II. Zaaw ansow ane kom unikow anie, m etadane i bezp ieczeń stw o )

197

7.1. A d r e s o w a n i e .....................................................................................................................................................................199 7.1.1. R eferencje p u n k tó w końcow ych .......................................................................................................................201 7.1.2. N agłów ki in form acyjne k o m u n ik a tó w ...........................................................................................................202 7.1.3. A dresow anie a niezależność o d p ro to k o łu tran sp o rto w eg o .................................................................... 203 7.1.4. A dresow anie a SO A .............................................................................................................................................. 204 7.2. N ie z a w o d n e k o m u n ik o w a n ie ............................................................................................................................... 2 0 6 7.2.1. RM Source, RM D estination, źródło aplikacyjne i p rzeznaczenie a p lik a c y jn e .................................. 207 7.2.2. S e k w e n cje..................................................................................................................................................................208 7.2.3. P o tw ie rd z e n ia .......................................................................................................................................................... 208 7.2.4. Z apew nienia d o s ta rc z e n ia ................................................................................................................................... 210 7.2.5. N iezaw odne k o m u n ik o w an ie a a d re s o w a n ie ................................................................................................212 7.2.6. N iezaw odne k o m u n ik o w an ie a S O A ............................................................................................................... 212 7.3. K o r e la c je .......................................................................................................................................................................... 2 1 4 7.3.1. Korelacje jako a b s tr a k c ja ..................................................................................................................................... 215 7.3.2. K orelacje w e w zorcach M EP i a k ty w n o śc ia ch ...............................................................................................216 7.3.3. Korelacje w k o o r d y n a c ji...................................................................................................................................... 216 7.3.4. K orelacje w orkiestracji ........................................................................................................................................216 7.3.5. K orelacje w a d re s o w a n iu ..................................................................................................................................... 216 7.3.6. K orelacje w niezaw odnym k o m u n ik o w a n iu .................................................................................................217 7.3.7. K orelacje a S O A ......................................................................................................................................................217 7.4. Z a ło ż e n ia p o l i t y k i ..........................................................................................................................................................218 7.4.1. F ram ew ork W S -P o lic y ..........................................................................................................................................219 7.4.2. A sercje polityki i w a rian ty p o lity k i.................................................................................................................. 220 7.4.3. T ypy asercji p o lityki i słow niki polityki ..........................................................................................................220 7.4.4. P o d m io ty polityki i zakresy p o lity k i................................................................................................................ 220 7.4.5. W y rażen ia p olityki i załączniki p o lity k i..........................................................................................................221

10

SPIS TREŚCI

7.4.6. Z ałożenia p olityki w k o o rd y n a c ji......................................................................................................................221 7.4.7. Z ałożenia p olityki w orkiestracji i c h o re o g ra fia c h ....................................................................................... 221 7.4.8. Z ałożenia p olityki w n iezaw odnym k o m u n ik o w a n iu ................................................................................ 221 7.4.9. Z ałożenia p olityki a S O A ..................................................................................................................................... 221 7.5. W y m i a n a m e t a d a n y c h ................................................................................................................................................223 7.5.1. Specyfikacja W S -M e tad a ta E x ch a n g e ............................................................................................................... 224 7.5.2. K om u n ik aty ż ądania i odpow iedzi G et M etad ata .......................................................................................224 7.5.3. K om u n ik aty ż ądania i odpow iedzi G e t ...........................................................................................................225 7.5.4. Selektyw ne p o b ieran ie m e ta d a n y c h ................................................................................................................. 226 7.5.5. W y m ia n a m etad an y ch a odnajdyw anie opisów u s ł u g ............................................................................... 226 7.5.6. W y m ia n a m etad an y ch a k o n tro la w ersji ....................................................................................................... 227 7.5.7. W y m ia n a m etad an y ch a SO A ........................................................................................................................... 227 7.6. B e z p i e c z e ń s tw o .............................................................................................................................................................. 229 7.6.1. Identyfikacja, uw ierzytelnianie i a u to ry z a c ja ................................................................................................231 7.6.2. Je d n o k ro tn e lo g o w a n ie .........................................................................................................................................232 7.6.3. P oufność i in te g ra ln o ś ć .........................................................................................................................................233 7.6.4. Bezpieczeństw o n a p oziom ie tra n s p o rtu i n a p o zio m ie k o m u n ik a tó w ................................................ 234 7.6.5. Szyfrow anie i p o d p isy cyfrow e .......................................................................................................................... 234 7.6.6. B ezpieczeństw o a S O A ..........................................................................................................................................236 7.7. P o w ia d a m ia n ie i z d a r z e n io w a n ie ........................................................................................................................ 238 7.7.1. M odel „ p u blikuj-subskrybuj” jako a b s tra k c ja ...............................................................................................238 7.7.2. Jedna koncepcja, dwie sp ecy fik acje.................................................................................................................. 239 7.7.3. F ram ew ork W S -N otification ............................................................................................................................. 239 7.7.4. Specyfikacja W S -E venting ..................................................................................................................................242 7.7.5. W S -N otification a W S -E v e n tin g .......................................................................................................................243 7.7.6. P ow iadam ianie i zdarzeniow anie a SO A ....................................................................................................... 244

Część III. SOA i zorientowanie na usługi .................................................................. 247 Rozdział 8. Zasady orientacji na u s łu g i......................................................................................................... 249 8.1. O r ie n ta c ja n a u s łu g i z p e r s p e k ty w y p r z e d s ię b io r s tw a .............................................................................. 2 5 0 8.2. A n a t o m i a a r c h i te k t u r y z o r ie n to w a n e j n a u s łu g i ........................................................................................ 253 8.2.1. Logiczne k o m p o n e n ty fram e w o rk u u słu g sie c io w y c h ............................................................................... 253 8.2.2. K o m p o n e n ty logiki a u to m a ty z a c ji....................................................................................................................254 8.2.3. K o m p o n e n ty S O A ................................................................................................................................................. 256 8.2.4. Jak pow iązane są k o m p o n e n ty SOA? .............................................................................................................. 257 8.3. P o d s ta w o w e z a s a d y z o r ie n to w a n i a n a u s łu g i ............................................................................................... 258 8.3.1. U sługi są w ie lo u ż y w a ln e ...................................................................................................................................... 260 8.3.2. U sługi w spółdzielą fo rm aln e k o n t r a k t y ..........................................................................................................262 8.3.3. U sługi są luźno p o w ią z a n e ..................................................................................................................................264 8.3.4. U sługi ukryw ają w ew n ętrzn ą l o g ik ę ................................................................................................................ 265 8.3.5. U sługi są k o m p o n o w aln e .................................................................................................................................... 268 8.3.6. U sługi są a u to n o m iczn e ...................................................................................................................................... 270 8.3.7. U sługi są bezstanow e ............................................................................................................................................273 8.3.8. U sługi są w ykryw alne ...........................................................................................................................................274

SPIS TREŚCI

11

8.4. Jak powiązane są zasady zorientowania na usługi? ..................................................................... 276 8.4.1. W ieloużyw alność u s ł u g i ...................................................................................................................................... 276 8.4.2. K ontraktow ość u s ł u g i ...........................................................................................................................................278 8.4.3. L uźne pow iązanie usługi ..................................................................................................................................... 279 8.4.4. A bstrakcyjność u s ł u g i ...........................................................................................................................................280 8.4.5. K om ponow aln ość u s ł u g i ..................................................................................................................................... 280 8.4.6. A u to n o m ia u s ł u g i ...................................................................................................................................................281 8.4.7. Bezstanow ość u s łu g i.............................................................................................................................................. 282 8.4.8. W ykryw alność u s ł u g i ............................................................................................................................................283

8.5. Orientacja na usługi oraz orientacja na obiekty (część I I ) .......................................................... 284 8.6. Natywne wsparcie dla zasad zorientowania na usługi ze strony usług sieciow ych.................286 Rozdział 9. W arstw y usług ................................................................................................................................ 289 9.1. Zorientowanie na usługi a współczesna SOA .............................................................................. 290 9.1.1. C harakterystyka w spółczesnej SOA a jej genealogia i zasoby w s p o m a g a ją c e .................................... 291 9.1.2. N iew spierane cechy SOA .................................................................................................................................... 293

9.2. Usługowe warstwy abstrakcji .......................................................................................................... 294 9.2.1. P ro b lem y rozw iązyw ane p rzez aranżow anie u słu g w w a rstw y ................................................................294

9.3. W arstwa usług aplikacyjnych ........................................................................................................ 297 9.4. W arstwa usług biznesowych .......................................................................................................... 300 9.5. W arstwa orkiestracji usług .............................................................................................................. 302 9.6. Agnostycyzm usług .......................................................................................................................... 303 9.7. Scenariusze konfiguracji warstwy usług ....................................................................................... 305 9.7.1. Scenariusz n r 1: wyłącznie usługi hybrydow e ................................................................................................. 305 9.7.2. Scenariusz n r 2: usługi hybrydow e i usługi użytkow e ................................................................................... 306 9.7.3. Scenariusz n r 3: biznesow e usługi zadaniow e i aplikacyjne usługi u ż y tk o w e ..........................................306 9.7.4. Scenariusz n r 4: oba typy usług biznesow ych i aplikacyjne usługi użytkow e ......................................... 307 9.7.5. Scenariusz n r 5: usługa procesow a i oba typy usług a plikacyjnych ............................................................ 307 9.7.6. Scenariusz n r 6: usługa procesow a, biznesow e usługi zadaniow e i aplikacyjne u sługi użytkow e ..... 308 9.7.7. Scenariusz n r 7: usługa procesow a, oba typy usług biznesow ych i aplikacyjne usługi u ż y tk o w e ...... 308 9.7.8. Scenariusz n r 8: usługa procesow a, biznesowe usługi podm iotow e i aplikacyjne usługi użytkow e ... 308

Część IV. Budowanie SOA (planowanie i an aliza)...................................................311 Rozdział 10. Strategie realizacji S O A ............................................................................................................. 313 10.1. Fazy cyklu życiowego SOA ......................................................................................................... 314 10.1.1. P odstaw ow e fazy realizacji SO A ...................................................................................................................314 10.1.2. A naliza z o rie n to w an a usługow o ...................................................................................................................315 10.1.3. P rojektow anie z o rientow ane usługow o ..................................................................................................... 315 10.1.4. T w orzenie usług ................................................................................................................................................ 315 10.1.5. T estow anie u słu g ............................................................................................................................................... 315 10.1.6. W d raż an ie usług ................................................................................................................................................ 316 10.1.7. A dm in istro w an ie usługam i ............................................................................................................................317 10.1.8. Strategie w drożeniow e SOA .......................................................................................................................... 317

12

SPIS TREŚCI

10.2. Strategia zstęp u jąca......................................................................................................................... 318 10.2.1. Proces .................................................................................................................................................................... 318 10.2.2. Z a i p r z e c iw ......................................................................................................................................................... 320

10.3. Strategia wstępująca ....................................................................................................................... 321 10.3.1. P r o c e s .................................................................................................................................................................... 321 10.3.2. Z a i p rzeciw ......................................................................................................................................................... 323

10.4. Strategia zwinna .............................................................................................................................. 324 10.4.1. Proces .................................................................................................................................................................... 324 10.4.2. Z a i p r z e c iw ......................................................................................................................................................... 326

Rozdział 11. Analiza zorientow ana na usługi (Część I. W p ro w a d z e n ie )............................................329 11.1. W prowadzenie do analizy zorientowanej na usługi ................................................................. 330 11.1.1. Cele analizy zorientow anej n a usługi ..........................................................................................................330 11.1.2. A naliza z o rie n to w an a n a u sługi a m o d el u słu g przedsiębiorstw a .....................................................331 11.1.3. Proces analizy zorientow anej n a usługi ..................................................................................................... 332

11.2. Korzyści z SOA ukierunkowanej b iznesow o.............................................................................. 335 11.2.1. U sługi biznesow e w bu d o w u ją zw inność w m odele b iz n e s o w e .......................................................... 336 11.2.2. U sługi biznesow e p rzygotow ują p roces do o rk ie s tra c ji.........................................................................336 11.2.3. U sługi biznesow e um ożliw iają w ieloużyw alność ....................................................................................336 11.2.4. Tylko za pom ocą usług biznesowych m ożna realizować przedsiębiorstwo zorientowane na usługi ...337

11.3. W yodrębnianie usług biznesow ych..............................................................................................339 11.3.1. Ź ró d ła dla w yo d ręb n ian ia usłu g b iz n e so w y c h ......................................................................................... 339 11.3.2. T ypy w y odrębnianych usług b iz n e so w y c h ................................................................................................344 11.3.3. U sługi biznesow e i o rk ie s tra c je .....................................................................................................................347

Rozdział 12. Analiza zorientow ana na usługi (Część II. M odelow anie u s łu g )................................ 349 12.1. Modelowanie usług krok po k ro k u ...............................................................................................350 12.1.1. „U sługi” a „ k an d y d a tu ry n a usługi” ............................................................................................................350 12.1.2. Proces .................................................................................................................................................................... 351

12.2. Wytyczne i wskazówki dotyczące modelowania u s łu g ............................................................. 366 12.2.1. Rozw ażanie p otencjalnej w ieloużyw alności m iędzyprocesow ej enkapsulow anej logiki (k a n d y d atu ry n a biznesow e usługi zadaniow e) ....................................................................................366 12.2.2. Rozw ażanie p otencjalnej w ieloużyw alności w ew nątrzprocesow ej enkapsulow anej logiki (k a n d y d atu ry n a biznesow e usługi zadaniow e) ....................................................................................367 12.2.3. W ykryw anie w ew nętrznych uzależnień o d p ro cesu (k a n d y d atu ry n a biznesow e usługi zadaniow e) ....................................................................................367 12.2.4. M odelow anie w ieloużyw alności m iędzyaplikacyjnej (k a n d y d atu ry n a u sługi a p lik a c y jn e )

368

12.2.5. P rognozow anie dalszych w ym agań d e k o m p o z y cy jn y c h ...................................................................... 368 12.2.6. Identyfikow anie logicznych jed n o ste k pracy w określonych granicach ..........................................369 12.2.7. Z apobieganie p e łz an iu g r a n ic ........................................................................................................................ 369 12.2.8. E m ulow anie usłu g procesow ych p rz y b ra k u orkiestracji (k a n d y d atu ry n a biznesow e usługi zadaniow e) ....................................................................................370 12.2.9. R ów now ażenie celów m o d e lo w a n ia ............................................................................................................370 12.2.10. K lasyfikow anie logiki m odelow anych u s ł u g .............................................................................................371 12.2.11. A lokow anie w ystarczających zasobów n a p o trze b y m o d e lo w a n ia ....................................................371 12.2.12. T w orzenie i p ublikow anie sta n d ard ó w m odelow ania usłu g b iz n e so w y c h ..................................... 372

SPIS TREŚCI

13

12.3. K la sy fik a c ja lo g ik i m o d e lu u s ł u g ........................................................................................................................ 373 12.3.1. M odel SO E .......................................................................................................................................................... 373 12.3.2. M odel biznesow y p rz e d się b io rs tw a ............................................................................................................. 374 12.3.3. „Bloki k o n stru k c y jn e ” a „m odele usłu g ” ................................................................................................... 374 12.3.4. P odstaw ow e bloki k o n stru k c y jn e m o delow ania .....................................................................................375 12.4. P o r ó w n a n ie p o d e jś ć d o m o d e lo w a n ia ( p rz y k ła d ) .................................................................................... 37 7

Część V. Budowanie SOA (technologie i projekt).................................................... 391 Rozdział 13. Projektowanie zorientow ane na usługi (Część I. W prow adzenie) .............................393 13.1. W p r o w a d z e n ie d o p r o j e k t o w a n ia z o r ie n to w a n e g o n a u s ł u g i ............................................................. 39 4 13.1.1. Cele p ro jek to w an ia zorientow anego n a u s ł u g i ........................................................................................ 394 13.1.2. „S tandardy p ro jek to w e” a „ stan d a rd y przem ysłow e” ............................................................................ 394 13.1.3. Proces p ro jek to w an ia zorientow anego n a u s ł u g i ....................................................................................395 13.1.4. P rzygotow ania ....................................................................................................................................................396 13.2. P o d s ta w y X M L S c h e m a z w ią z a n e z W S D L .................................................................................................. 39 7 13.2.1. E lem ent s c h e m a ................................................................................................................................................. 399 13.2.2. E lem ent e le m e n t ................................................................................................................................................ 399 13.2.3. E lem enty com plexT ype i s im p le T y p e .........................................................................................................399 13.2.4. E lem enty im p o rt i include ............................................................................................................................. 400 13.2.5. In n e w ażne e le m e n ty ....................................................................................................................................... 400 13.3. P o d s ta w y ję z y k a W S D L ...........................................................................................................................................401 13.3.1. E lem ent d e f in itio n s ...........................................................................................................................................402 13.3.2. E lem ent t y p e s ......................................................................................................................................................402 13.3.3. E lem enty m essage i p a r t ..................................................................................................................................403 13.3.4. E lem enty p o rtT y p e, interface i o p e r a tio n .................................................................................................. 404 13.3.5. E lem enty in p u t i o u tp u t (jako p o to m n e ele m en tu operatio n ) ........................................................... 405 13.3.6. E lem ent b i n d i n g ................................................................................................................................................ 405 13.3.7. E lem enty in p u t i o u tp u t (jako p o to m n e ele m en tu b in d in g ) ...............................................................406 13.3.8. E lem enty service, p o rt i e n d p o i n t ................................................................................................................ 407 13.3.9. E lem ent i m p o r t ...................................................................................................................................................407 13.3.10.

E lem ent d o c u m e n ta tio n .............................................................................................................................. 408

13.4. P o d s ta w y ję z y k a S O A P ............................................................................................................................................4 0 8 13.4.1. E lem ent E n v e lo p e .............................................................................................................................................. 409 13.4.2. E lem ent H e a d e r ................................................................................................................................................. 409 13.4.3. E lem ent B o d y ......................................................................................................................................................410 13.4.4. E lem ent F a u l t ......................................................................................................................................................411 13.5. N a r z ę d z ia d o p r o je k to w a n ia i n te r f e js ó w u s ł u g .......................................................................................... 4 1 2 13.5.1. A u tom atyczne generow anie .......................................................................................................................... 412 13.5.2. N arzędzia p r o je k to w e ...................................................................................................................................... 412 13.5.3. Ręczne k o d o w a n ie .............................................................................................................................................413

14

SPIS TREŚCI

Rozdział 14. Projektowanie zorientowane na usługi (Część II. Wytyczne komponowania SOA) ...415 14.1. Komponowanie SOA — krok po k ro k u ...................................................................................... 416 14.1.1. W y b ó r stru k tu ry w arstw u s łu g ......................................................................................................................417 14.1.2. U m iejscow ienie rd z en n y c h s ta n d a r d ó w .................................................................................................... 417 14.1.3. W y b ó r rozszerzeń S O A ................................................................................................................................... 418

14.2. Uwarunkowania wyboru warstw u s łu g ...................................................................................... 418 14.3. Uwarunkowania umiejscowienia rdzennych standardów SOA ...............................................420 14.3.1. S tan d ard y przem ysłow e a S O A .....................................................................................................................420 14.3.2. XM L a SOA ......................................................................................................................................................... 421 14.3.3. W S-I Basic Profile .............................................................................................................................................422 14.3.4. W SD L a SO A ......................................................................................................................................................423 14.3.5. XM L Schem a a SO A .........................................................................................................................................424 14.3.6. SO AP a SO A ....................................................................................................................................................... 425 14.3.7. Przestrzenie nazw a SO A ................................................................................................................................426 14.3.8. U D D I a S O A ....................................................................................................................................................... 426

14.4. Uwarunkowania wyboru rozszerzeń S O A .................................................................................. 428 14.4.1. Selekcja charakterystyki S O A P ......................................................................................................................428 14.4.2. Selekcja specyfikacji W S-* ............................................................................................................................. 429 14.4.3. W S-BPEL a SOA ............................................................................................................................................... 429

Rozdział 15. Projektowanie zorientow ane na usługi (Część III. Projektowanie u s łu g ) 433 15.1. O projektowaniu usług ogólnie ................................................................................................... 435 15.1.1. S tan d ard y p ro jek to w an ia ................................................................................................................................435 15.1.2. O pisy p rocesów ...................................................................................................................................................436 15.1.3. P rzygotow ania ....................................................................................................................................................436

15.2. Projektowanie biznesowych usług podm iotowych — krok po k r o k u ....................................438 15.2.1. Proces .................................................................................................................................................................... 438

15.3. Projektowanie usług aplikacyjnych — krok po k r o k u .............................................................. 456 15.3.1. Proces .................................................................................................................................................................... 457

15.4. Projektowanie biznesowych usług zadaniowych — krok po k ro k u ........................................469 15.4.1. Proces .................................................................................................................................................................... 470

15.5. Wytyczne dla projektowania u słu g ...............................................................................................483 15.5.1. Identyfikow anie ograniczeń te c h n ic z n y c h ................................................................................................483 15.5.2. Stosow anie sta n d ard ó w nazew niczych ...................................................................................................... 484 15.5.3. D o b ó r odpow iedniej z iarnistości in te r f e js u ..............................................................................................485 15.5.4. P rojektow anie operacji u słu g jako n a tu ra ln ie rozszerzalnych ........................................................... 487 15.5.5. Identyfikow anie znanych i poten cjaln y ch u sług-w nioskodaw ców ...................................................488 15.5.6. M odularyzow anie d o k u m en tó w W S D L .................................................................................................... 488 15.5.7. S taran n e używ anie p rz estrz en i n a z w ...........................................................................................................489 15.5.8. W ykorzystyw anie literalnych k o m u n ik a tó w w stylu d o k u m e n to w y m ............................................490 15.5.9. K onsekw entne zachow yw anie zgodności z zaleceniam i W S - I ........................................................... 491 15.5.10.

D o k u m en to w an ie usług za p o m o cą m etad an y ch ...............................................................................491

SPIS TREŚCI

15

Rozdział 16. Projektowanie zorientow ane na usługi (Część IV. Projektowanie procesu biznesow ego)................................................................ 493 16.1. P o d s ta w y ję z y k a W S - B P E L ................................................................................................................................... 4 9 4 16.1.1. K rótka h isto ria BPEL4WS i W S-BPEL ...................................................................................................... 495 16.1.2. P rzygotow ania ....................................................................................................................................................495 16.1.3. E lem ent p r o c e s s ................................................................................................................................................. 496 16.1.4. E lem enty p a rtn e rL in k s i p a r tn e r L in k ..........................................................................................................496 16.1.5. E lem ent p a rtn e rL in k T y p e ...............................................................................................................................497 16.1.6. E lem ent v ariables .............................................................................................................................................. 498 16.1.7. F unkcje getV ariab leP ro p erty i g e tV a ria b le D a ta ......................................................................................499 16.1.8. E lem ent s e q u e n c e .............................................................................................................................................. 499 16.1.9. E lem ent invoke ...................................................................................................................................................500 16.1.10. E lem ent receive .................................................................................................................................................. 500 16.1.11. E lem ent r e p l y ......................................................................................................................................................501 16.1.12. E lem enty sw itch, case i otherw ise ................................................................................................................ 502 16.1.13. E lem enty assign, copy, from i to ...................................................................................................................502 16.1.14. E lem enty faultH andlers, catch i catchA ll .................................................................................................. 503 16.1.15. P ozostałe elem enty W S-BPEL .......................................................................................................................503 16.2. O s p e c y fik a c ji W S - C o o r d i n a t i o n o g ó l n i e .....................................................................................................505 16.2.1. E lem ent C o o rd in a tio n C o n te x t...................................................................................................................... 505 16.2.2. E lem enty Id en tifier i E x p ir e s ......................................................................................................................... 506 16.2.3. E lem ent C o o rd in a tio n T y p e ........................................................................................................................... 507 16.2.4. E lem ent R eg istra tio n S erv ice .......................................................................................................................... 507 16.2.5. W y b ó r ty p u koordynacyjnego W S-B usinessA ctivity ............................................................................ 507 16.2.6. W y b ó r ty p u koordynacyjnego W S -A to m icT ran sactio n .......................................................................507 16.3. P r o je k to w a n ie p r o c e s u b iz n e s o w e g o z o r ie n to w a n e g o n a u s łu g i — k r o k p o k r o k u ................508 16.3.1. Proces .................................................................................................................................................................... 508

Rozdział 17. Podstaw ow e rozszerzenia W S-* .............................................................................................531 17.1. P o d s ta w y ję z y k a W S - A d d r e s s i n g ....................................................................................................................... 532 17.1.1. E lem ent E n d p o in tR e fe re n c e .......................................................................................................................... 533 17.1.2. E lem enty nagłów ka reprezen tu jące inform ację o k o m u n ik a tac h (M I) ........................................... 534 17.1.3. W ie lo k ro tn e w ykorzystyw anie W S -A d d re ss in g ...................................................................................... 537 17.2. P o d s ta w y ję z y k a W S -R e lia b le M e s s a g in g ....................................................................................................... 538 17.2.1. E lem enty Sequence, M essageN um ber i L a stM essa g e ............................................................................ 539 17.2.2. E lem enty S equenceA cknow ledgem ent i A c k n o w led g e m en tR a n g e ...................................................540 17.2.3. E lem ent N a c k ......................................................................................................................................................541 17.2.4. E lem ent A c k R e q u e ste d .................................................................................................................................... 542 17.2.5. P ozostałe elem enty W S -R eliab leM essag in g..............................................................................................543 17.3. P o d s ta w y ję z y k a W S - P o l i c y .................................................................................................................................. 544 17.3.1. E lem ent Policy i p odstaw ow e asercje p olityki ......................................................................................... 545 17.3.2. E lem ent E xactlyO ne ..........................................................................................................................................545 17.3.3. E lem ent All .......................................................................................................................................................... 546 17.3.4. A try b u t U s a g e .....................................................................................................................................................547 17.3.5. A try b u t P re fe re n c e ............................................................................................................................................ 547 17.3.6. E lem ent P o licy R eferen ce................................................................................................................................. 547 17.3.7. A try b u t P o lic y U R Is...........................................................................................................................................548

16

SPIS TREŚCI

17.3.8. E lem ent P olicyA ttachm ent .............................................................................................................................548 17.3.9. In n e typy asercji polityki ................................................................................................................................. 549

17.4. Podstawy języka W S-MetadataExchange ....................................................................................550 17.4.1. E lem ent G e tM e ta d a ta ...................................................................................................................................... 551 17.4.2. E lem ent D ialect ................................................................................................................................................. 552 17.4.3. E lem ent Identifier ............................................................................................................................................. 552 17.4.4. E lem enty M etadata, M etadataS ection i M etadataR eference ...............................................................552 17.4.5. K om u n ik at G e t ...................................................................................................................................................554

17.5. Podstawy języka W S-Security........................................................................................................ 555 17.5.1. E lem ent S e c u rity ................................................................................................................................................ 556 17.5.2. E lem enty U sernam eT oken, U sern am e i P assw ord (W S -S e cu rity )....................................................556 17.5.3. E lem ent B inaryS ecurityT oken (W S-Security) ......................................................................................... 556 17.5.4. E lem ent SecurityT okenR eference (W S-Security) ...................................................................................556 17.5.5. K om ponow anie zaw artości ele m en tu Security (W S-Security) .......................................................... 557 17.5.6. E lem ent E n cry p ted D ata (X M L -E ncryption) ............................................................................................558 17.5.7. E lem enty C ipherD ata, C ipherV alue i C ipherR eference (X M L -E n c ry p tio n )................................. 558 17.5.8. E lem enty X M L -S ignature ...............................................................................................................................559

Rozdział 18. Platform y S O A ...............................................................................................................................563 18.1. Platformy S O A ................................................................................................................................. 564 18.1.1. P odstaw ow e bloki k o n stru k c y jn e p latfo rm y SOA ..................................................................................564 18.1.2. G łów ne w arstw y p latfo rm y SO A ..................................................................................................................565 18.1.3. W arstw y SOA a te c h n o lo g ie .......................................................................................................................... 566 18.1.4. F u n d a m en ta ln a a rch ite k tu ra technologiczna u s ł u g ............................................................................... 567 18.1.5. P latform y dostaw ców ...................................................................................................................................... 576

18.2. SOA na platformie J2E E ................................................................................................................. 577 18.2.1. O gólnie o p la tf o rm ie .........................................................................................................................................577 18.2.2. W sparcie dla p ierw otnej SO A ....................................................................................................................... 587 18.2.3. W sparcie dla zasad zorien to w an ia n a u s łu g i.............................................................................................588 18.2.4. W sparcie dla w spółczesnej SO A ...................................................................................................................589

18.3. SOA na platformie .N E T ................................................................................................................ 593 18.3.1. O gólnie o p la tf o rm ie .........................................................................................................................................594 18.3.2. W sparcie dla p ierw otnej SO A ....................................................................................................................... 602 18.3.3. W sparcie dla zasad zorien to w an ia n a u s łu g i.............................................................................................602 18.3.4. W sparcie dla w spółczesnej SO A ...................................................................................................................603

18.4. Względy integracyjne ..................................................................................................................... 606 D odatek A. Analizy przypadków — k o n k lu z ja ............................................................................................609 A.1. RailCo Ltd........................................................................................................................................... 610 A.2. Transit Line Systems Inc. (TLS) .....................................................................................................612 A.3. Myjnia samochodów W3C O a s is...................................................................................................615 Dodatek B. M odele usług — lista referencyjna .........................................................................................617 O a u to rz e ..................................................................................................................................................................621 O fotografiach ........................................................................................................................................................623 S k o ro w id z.................................................................................................................................................................625

Przedmowa

Książka ta jest owocem niemal rocznej pracy — pisania, badań, a przy tym wszystkim dotrzymy­ wania kroku w znajomości dziedziny, która z dnia na dzień staje się bardziej popularna i odgrywa coraz większą rolę w nowoczesnym przemyśle informatycznym. Choć w większości rozdziałów traktuję tematykę architektury zorientowanej na usługi z perspektywy niezależności od konkret­ nej implementacji i konkretnego dostawcy, jednak adekwatne zobrazowanie tej perspektywy wy­ magało poświęcenia dość długiego czasu na ocenę wsparcia, jakie zapewniają SOA produkty naj­ bardziej znanych dostawców. W trakcie swych badań dyskutowałem na ten tem at z ponad setką doświadczonych specjalistów IT, zarówno w formie wywiadów, a także jako ju ro r dokonujący ewaluacji platform udostępnianych przez producentów. Jednym z najbardziej interesujących aspektów wspomnianych badań było definiowanie zorien­ towania na usługi w kontekście usług sieciowych. Studiując poszczególne elementy tego, co w istocie konstytuuje paradygmat zorientowania na usługi, uświadomiłem sobie, iż wiele tych elementów wywodzi swe korzenie z przeszłych wynalazków — a jednocześnie paradygmat ów, łączący trady­ cję z nowatorskimi pomysłami, stanowi istotnie nowy, unikatowy model architektoniczny. Niezależnie od swego nowatorskiego charakteru, SOA opiera się na fundam entach wywodzą­ cych się z tradycyjnej szkoły myślenia. Zorientowanie na usługi, rozumiane jako podział skompli­ kowanych bytów na niezależne jednostki logiczne, to koncepcja nienowa; doświadczamy jej wszyscy, mniej lub bardziej świadomie, w codziennym życiu — co ja osobiście zacząłem sobie uświada­ miać bardziej niż kiedykolwiek, pisząc kolejne rozdziały tej książki. Produkty, usługi, ludzie, or­ ganizacje — każdy z nas jest konsum entem pewnych, dobrze zdefiniowanych usług, wielu z nas oferuje takie usługi innym . Jednak w kontekście architektury technologicznej zorientowanie na usługi oznacza skoncentrowanie się na specyficznej części wspomnianego świata — automatyzacji biznesu. Ostra rywalizacja rynkowa, jako nieodłączny element biznesowych klimatów, stawia przed przed­ siębiorcami bezwzględny wymóg zarówno ograniczania (a wręcz eliminowania) niepotrzebnych wysiłków, jak i maksymalnej efektywności w osiąganiu strategicznych celów. Nieefektywne firmy, nieustannie m arnotraw iące swe zasoby, zwyczajnie nie liczą się w tej grze. Metody, którym i przedsiębiorstwa realizują automatyzację swego biznesu, stanowią krytyczny czynnik decydujący o poziomie efektywności ich działania, a w konsekwencji — o stopniu powodzenia, z jakim reali­ zują swe przedsięwzięcia.

18

PRZEDMOWA

I ta właśnie nowoczesna walka o byt czyni SOA tak wartościowym. Kształtowanie logiki au­ tomatyzacji zgodnie z zasadami orientacji na usługi umożliwia uzyskanie większych pożytków z poniesionych (i ponoszonych) inwestycji, pełną realizację inteligencji biznesowej oraz zapew­ nienie tej automatyzacji należytego stopnia elastyczności. W połączeniu z platformą usług siecio­ wych SOA stwarza ogrom ny potencjał, otwierający przed firm ą znaczące i rzeczywiste korzyści, i podnoszący na wyższy poziom zarówno firmową technologię, jak i sam wizerunek firmy. Książkę napisałem po to, by pom óc zainteresowanym czytelnikom w zrozumieniu i praktycz­ nym osiągnięciu wspomnianego potencjału.

Podziękow ania Pisałem tę książkę, natchniony błogosławieństwem recenzentów i wydawców, producentów , no i speców od m arketingu. Wielkie dzięki dla Was wszystkich za niestrudzony wysiłek i pomoc. Głęboka wdzięczność dla mojej rodziny za cierpliwość i nieustające wsparcie.

Rozdział 1

Wprowadzenie 1.1. Dlaczego ta książka jest ważna? 1.2. Cele tej książki 1.3. Dla kogo przeznaczona jest ta książka? 1.4. Czego w tej książce nie ma? 1.5. Organizacja tej książki 1.6. Informacja dodatkowa

20

R O ZDZIA Ł 1. ■ W P R O W A D Z E N IE

1 .1 . D la c ze g o ta książka je s t w a ż n a ? Jednym z m oich ulubionych cytatów jest sentencja, którą przypadkowo podsłuchałem, przygoto­ wując się do wystąpienia na pewnej konferencji. Dwóch specjalistów IT wymieniało uwagi na te­ m at swych środowisk projektowych i jeden spytał współrozmówcę, czy jego aplikacje tworzone są na bazie architektury zorientowanej na usługi. Odpowiedź brzmiała „Mój architekt jest przeko­ nany, iż jest to orientacja na usługi, moi programiści upierają się przy architekturze zorientowa­ nej obiektowo, zaś analitycy chcieliby ukierunkowania na potrzeby biznesowe. Co m ożna powie­ dzieć na pewno — to coś nowego, co rozpoczęło się, gdy zaczęliśmy budować usługi sieciowe”. To szczere stwierdzenie jest swoistym znakiem naszych czasów. Architektura zorientowana na usługi (SOA) stała się centralnym punktem zainteresowań w przemyśle IT, jednakże zaintere­ sowanie to nie idzie zwykle w parze z należytym zrozumieniem tem atu — „należytym” w sensie możliwości spożytkowania potencjalnie możliwych korzyści. Książka ta, w zamierzeniu autora, ma za zadanie wypełnić choć częściowo tę lukę, pomagając czytelnikom w osiągnięciu dwóch pod­ stawowych celów, czyli w: • zrozumieniu, co naprawdę oznacza „zorientowanie na usługi”, czym jest architektura SOA i w jakiej pozostaje relacji do tradycyjnie rozum ianych usług sieciowych, • zyskaniu umiejętności budow ania konkretnych rozwiązań, dzięki połączeniu usług sieciowych z nowatorstwem architektury SOA. Rozpocznijmy od omówienia najczęstszych przeszkód na drodze do adaptacji SOA.

1.1.1. Fałszywa SOA Trudno byłoby mi wymienić inny term in wywołujący tyle nieporozumień, co określenie „zo­ rientowany na usługi”. Nieporozumienie to prowadzi (i poniekąd — usprawiedliwia) producentów, specjalistów IT i publicystów do tworzenia (i kultywowania) własnych wyobrażeń dotyczących tego, jak należy wspomnianą orientację na usługi interpretować. I w konsekwencji trudno o spójne ujęcie tego wszystkiego, czemu w literaturze przedmiotu przypina się etykietkę „orientacji na usługi”. „A rchitektura zorientow ana na usługi”, reprezentow ana przez akronim SOA (od Service Oriented Architecture), tradycyjnie stała się paradygmatem architektury rozproszonej rozpatry­ wanej w oderwaniu od konkretnej implementacji. Koncepcja to niewątpliwie słuszna, aczkolwiek fragmentaryczna, bo obejmuje jedynie wąski podzbiór tego, czym naprawdę jest SOA w swej obec­ nej i najczęściej spotykanej formie. W połączeniu z platform ą usług sieciowych oraz wieloma przyjętymi powszechnie zasadami, SOA wyewoluowała z czasem jako platform a architektoniczna wyraźnie różniąca się od swych poprzedniczek: platforma wprowadzająca nowe koncepcje, wspierane przez nowoczesne technolo­ gie i poszerzające możliwości tradycyjnie rozumianych środowisk rozproszonych — do tego stop­ nia, że środowisko zorientowane na usługi oznacza ponowne zdefiniowanie infrastruktury IT. Nic więc dziwnego, że SOA zyskała sobie należne zainteresowanie i prom ow ana zaczęła być jako platforma zdolna zrewolucjonizować informatykę przedsiębiorstw i zaszczepić na jej gruncie nowe nadzieje na federacyjność, zwinność i harm onijną współpracę międzyplatformową. Ścisły związek technologii SOA z usługami sieciowymi w naturalny sposób wykreował ten­ dencję do postrzegania tejże technologii jako zbudowanej wyłącznie na bazie tych usług. Tenden­ cja ta jest równie powszechna, co niebezpieczna: firmy adaptujące SOA na swym gruncie stają się

1 .1 . DLACZEGO T A KSIĄŻKA JEST W A ŻN A ?

21

zakładnikami złudnego przekonania, iż sukces całego przedsięwzięcia osiągalny jest głównie za sprawą intensywnego inwestowania w platformę usług sieciowych. Wszystko to staje się zrozumiałe po uświadomieniu sobie, że trudno przedsiębiorstwu wła­ ściwie ocenić udział w jego infrastrukturze „orientacji na usługi”, jeżeli przedsiębiorstwo to nie ma jasnego wyobrażenia o rzeczywistym znaczeniu tegoż pojęcia. Potrzebujemy zatem pewnego punktu odniesienia — modelowego, idealnego przedsiębiorstwa.

1.1.2. Ideał SOA Wszyscy dążymy do jakichś ideałów. Każdy ideał reprezentuje pewien stan wspaniałości i m oty­ wuje do osiągnięć wykraczających poza pewną granicę — granicę, której bez w izerunku ideału przekroczyć nie sposób. Jednym z takich ideałów jest wizja świata, w którym zasoby, wyraźnie i rozsądnie rozpartycjonowane, pozostają ze sobą w idealnej spójności. W odniesieniu do architektury IT przekłada się to na uniwersalny model, podporządkowujący tej koncepcji logikę automatyzacji, a nawet logikę biznesową. Model stosujący się w równej mierze do zadań, do rozwiązań, do przedsiębiorstwa, do całej społeczności — i być może sięgający jeszcze dalej... Techniczne i filozoficzne rozbieżności w rozum ieniu tej (bądź co bądź dość ogólnikowej) idei zostały z biegiem czasu zniwelowane przez nałożenie na w spom niany model swoistych warstw abstrakcji, dających w efekcie globalnie akceptowany standard reprezentowania logiki i informacji. Ów poziom standaryzacji otworzył organizacjom drogę do trudnych do przecenienia korzyści: tra­ dycyjnym wyzwaniom związanym z nieustannie ewoluującym środowiskiem IT można było wresz­ cie stawić czoło w zunifikowany sposób, za pomocą aplikacji działających w obszarze w spom nia­ nych warstw abstrakcji. Idea „orientacji na usługi” stała się jednocześnie m otorem napędowym działań wynoszących SOA do rangi kolejnej fazy w ewolucji środków automatyzowania biznesu. Tak jak kom putery m ainfram e stały się trzonem aplikacji „klient-serw er”, a te z kolei stopniow o przeobraziły się w środowiska przetwarzania rozproszonego opartego na technologiach webowych, tak za sprawą współczesnej architektury SOA opartej na usługach sieciowych stopień rozproszenia wspom nia­ nych środowisk sięgnął skali globalnej. SOA zyskała sobie wsparcie ze strony wszystkich znaczących wytwórców i dostawców, w tym wielu czynnie zaangażow anych w tw orzenie i rozw ijanie otw artych standardów . W rezultacie każda obecnie znacząca platforma tworzenia oprogramowania oferuje środki do kreowania roz­ wiązań zorientowanych na usługi. Realizacja SOA zdaje się bujnie rozkwitać. No więc, skoro jest tak wspaniale, dlaczego jest aż tak źle? Dlaczego fałszywa SOA zdaje się dziś być raczej regułą niż wyjątkiem?

1.1.3. Realna SOA Fałszywa SOA to nie tylko odstępstwo od „prawdziwej ścieżki orientacji na usługi”, lecz przede wszystkim utrzymywanie i rozwijanie antywzorców, czyli okopywanie na ustalonych pozycjach tych tradycyjnych mechanizmów przetwarzania rozproszonego, dla których właśnie SOA powinna być alternatywą. Rozczarowanie pojawia się, gdy rozbieżności między efektami a oczekiwaniami zestawi się z poniesionymi kosztami, wielkością zainwestowanego wysiłku i ogólnie wszelkimi nie­ dogodnościami wynikającymi z reanimowania przestarzałych rozwiązań.

22

R O ZDZIA Ł 1. ■ W P R O W A D Z E N IE

Można tego uniknąć, gdy właściwie zrozumie się sens „zorientowania na usługi”, a konkretnie — jego odzwierciedlenie w technicznej architekturze SOA; musi temu — oczywiście — towarzyszyć realizacja, krok po kroku, procesów składających się na SOA w jej nowoczesnej formie. Wymaga to pewnej zm iany m entalności, głównie w zakresie postrzegania logiki biznesowej w nowym, „usługowym” kontekście: kontekst ten m usi zostać odzwierciedlony w nowym sposobie budow a­ nia konkretnych rozwiązań. Wszystko to stawia określone wymagania pod adresem architektury technicznej, zdolnej do efektywnego hostowania wspomnianych rozwiązań. Taka transformacja, o charakterze zstępującym (od ogólnych założeń do szczegółowych roz­ wiązań), powinna prowadzić nie tyle w kierunku jakiegoś abstrakcyjnego ideału, co do konkretnego, realnego celu, uwarunkowanego specyfiką firmy, oczywiście, zgodnie z koncepcją zorientowania na usługi, modelem architektonicznym dostarczanym przez współczesną SOA i przy wykorzysta­ niu możliwości oferowanych przez nowoczesną technologię. Realna SOA wymaga rzeczywistych zmian, realnych przewidywań i prawdziwego zaangażo­ wania; przede wszystkim jednak wymaga przewodnictwa — do czego właśnie przyczynkiem ma — z założenia — być ta książka.

1 .2 . C e le te j książki Zatrzymajmy się przez chwilę nad dwoma podstawowymi celami, które przed chwilą sformułowaliśmy.

1.2.1. Podstawy SOA, orientacji na usługi i usług sieciowych Mimo iż treść tej książki nie skupia się wyłącznie na architekturze SOA, architektura ta jest cen­ tralną częścią platformy zorientowanej na usługi, wnoszącą do tejże platformy nowe koncepcje, nowe technologie i jednocześnie stawiającą nowe wyzwania. Czytelnicy znajdą tu obszerne om ó­ wienie kluczowych elementów tej platformy, w kontekście zróżnicowanych aspektów tworzenia rozwiązań zorientowanych na usługi. • Zdefiniowane i opisane zostaną, krok po kroku, pierwotne i współczesne odmiany SOA, w ujęciu kilkunastu charakterystycznych cech właściwych obecnym technologiom usług sieciowych i technikom ich projektowania. • Przedstawiona zostanie fundam entalna teoria usług sieciowych; omówione zostanie także zjawisko integrowania języka XML z usługami sieciowymi, które — dynamicznie wspierane przez organizacje standaryzacyjne i dostawców oprogramowania — wywarło istotny wpływ na ewolucję SOA. • Omówione zostaną szczegółowo zasady „orientowania na usługi”, wyjaśnione także zostanie (na licznych przykładach) ich odzwierciedlenie w projektowaniu usług sieciowych. • Opisane zostanie z detalami kilkanaście specyfikacji grupy WS-*. W ybrane fragmenty książki poświęcone są wyjaśnieniu koncepcji owych specyfikacji w języku potocznym, a ich szczegóły techniczne objaśnione są na licznych przykładach. • Przedmiotem szczegółowej dyskusji staną się zaawansowane koncepcje i problemy projektowe SOA, głównie w odniesieniu do tworzenia specjalizowanych warstw usługowych. Ujęcie takie pozwoli lepiej zrozumieć sens wyodrębniania abstrakcyjnych dom en biznesu i technologii, jako podstawy do sformułowania celów projektowych w konkretnym zastosowaniu.

1 .4 . CZEGO W TEJ KSIĄŻCE NIE M A?

23

1.2.2. Jak budować SOA na bazie usług sieciowych? Znacząca część tej książki pom yślana została jako instruktaż wspom agający realizację zadań, takich jak: • analiza zorientowana na usługi, • modelowanie kandydatur usługowych na podstawie istniejącej dokumentacji biznesowej, • projektowanie dekompozycji SOA, • projektowanie usług aplikacji z perspektywy abstrakcji technologicznej, • projektowanie usług biznesowych z perspektywy abstrakcji logiki biznesowej, • projektowanie zorientowanych usługowo procesów biznesowych, • ocena zakresu wsparcia dla SOA ze strony platform J2EE i .NET.

1 .3 . D la k o g o p rze zn a c zo n a je s t ta książka? SOA to tem at niewątpliwie rozległy, obejmujący platformę architektoniczną nowej generacji, łą­ czącą szereg nowoczesnych technologii (zarówno własnościowych, jak i niezależnych od kon­ kretnych dostawców). Z tego względu książka ta zainteresuje z pewnością wielu specjalistów IT, skłonnych pogłębić swą wiedzę w zakresie: • budowania rozwiązań kategorii SOA, • zasad zorientowania na usługi, • projektowania różnych typów usług na potrzeby SOA, • modelowania biznesowego ukierunkowanego na usługi, • korzyści dostarczanych przez kluczowe specyfikacje WS-*, • orkiestracji usług sieciowych przy użyciu WS-BPEL, • wsparcia dla SOA na platform ach J2EE i .NET, • modelowania usług skoncentrowanych na biznesie, • tworzenia standardów projektowych dla rozwiązań opartych na SOA, • technologii usług sieciowych postrzeganych w kontekście SOA.

1 .4 . C ze g o w te j książce n ie m a? Mimo iż w tej książce znajdują się odniesienia do integracji i współdziałania ukierunkowanych usługowo, nie zostały one w yodrębnione w postaci osobnego tem atu; jem u dedykowana jest oddzielna książka — Service-Oriented Architecture: A Field Guide to Integrating XM L and Web Services — szczegółowo traktująca o architekturach, strategiach i zalecanych praktykach wspo­ mnianej integracji. Podobnie, choć książka z pewnością będzie pom ocna dla program istów pragnących zgłębić tajniki budow ania usług dla SOA i wsparcia różnych platform technologicznych dla modelu SOA, nie znajdą w niej czytelnicy opisów program owania usług sieciowych jako takich w konkretnym języku. Zamieszczone przykłady „krok po k roku” koncentrują się na budow aniu i orkiestracji

24

R O ZDZIA Ł 1. ■ W P R O W A D Z E N IE

punktów końcowych usług, a nie na logice komponentów konstytuujących owe usługi, zaś tutoriale i przykładowy kod opierają się na otwartych językach usług sieciowych: WSDL, SOAP, XML Schema, WS-BPEL, WS-Coordination, WS-Policy, WS-Metadata-Exchange, WS-Security, WS-Addressing oraz WS-ReliableMessaging.

UWAGA Przy lekturze tej książki w ielce pom ocna okaże się znajom ość języka X M L . W ykaz zalecan ej w zw iązku z tym literatury znajdą czytelnicy pod adresem http://www.servicetechbooks.com/ , natom iast na stronie http://www.servicetechspecs.com/xmizna\du\ą się liczne odsyłacze do publikacji w prow adzających w tem at.

1 .5 . O rg a n iz a c ja te j książki Siedemnaście następnych rozdziałów to istna lawina informacji i nie było sprawą banalną jej zor­ ganizowanie w taki sposób, by zachowując jej logiczną strukturę, stworzyć jednocześnie książkę łatwą w odbiorze. Ostatecznie treść książki podzielona została na pięć następujących części: • Część I. Fundam enty SOA i usług sieciowych, • Część II. SOA i rozszerzenia WS-*, • Część III. SOA i zorientowanie na usługi, • Część IV. Budowanie SOA (planowanie i analiza), • Część V. Budowanie SOA (technologie i projekt). Zasadniczo części I, II i III poświęcone są teorii oraz podstawowym i zaawansowanym kon­ cepcjom SOA, i z założenia pełnić mają funkcję przygotowawczą dla lektury części IV i V, które zawierają materiał instruktażowy wyjaśniający budowanie SOA krok po kroku. W części V omówiono także technologie grupy WS-* oraz elementy wsparcia dla SOA ze strony platform J2EE i .NET. W ątkiem wspólnym dla wszystkich części jest spójne wykorzystywanie analiz przypadku — ponad sto dwadzieścia takich analiz urozmaica treść książki oraz dobitnie zaświadcza o tym, że omawiane koncepcje mają swe niezaprzeczalne odzwierciedlenie w rzeczywistym świecie. Analizy te pojawiają się po raz pierwszy w rozdziale 2., dostarczając podstawowych informacji o dwóch m o­ delowych (fikcyjnych) organizacjach, stanowiących podm iot wszystkich analiz. Przyjrzyjmy się teraz nieco dokładniej tematyce następnych rozdziałów.

1.5.1. Część I. Fundamenty SOA i usług sieciowych W tej części wyjaśniane są podstawowe koncepcje SOA i omawiana jest droga ewolucji SOA ze starszych platform. Na zakończenie opisany został framework usług sieciowych. Wprowadzenie do SOA (rozdział 3.) W rozpoczynającym część I rozdziale 3. sprecyzujemy definicję SOA w obecnym rozum ieniu — czyli wyjaśnimy, czym SOA jest w istocie, a czym nie jest. Posłuży nam do tego najpierw analiza tych cech, które składają się na tradycyjną, „pierw otną” SOA, po czym uzupełnim y tę analizę sformułowaniem zasad „zorientowania na usługi” oraz przyjrzymy się czynnikom, za sprawą których

1 .5 . O R G A N IZA C JA TEJ KSIĄŻKI

25

pierwotna SOA wyewoluowała do obecnej postaci platformy klasy enterprise. Zidentyfikujemy przy tym i wyjaśnimy sens 20 kluczowych cech charakterystycznych tejże nowoczesnej platformy. Gdy już współczesna SOA objawi się nam jako dobrze zdefiniowany twór, o wyraźnej cha­ rakterystyce, zajmiemy się serią powszechnie panujących m itów i nieporozum ień — czyli spró­ bujemy ogólnie wyjaśnić, czym SOA nie jest i nigdy nie była. Do kwestii tej będziemy powracać wielokrotnie w następnych rozdziałach. Poznawszy bliżej tożsamość SOA, zajmiemy się tematyką potencjalnych korzyści, jakich do­ starczyć m oże zaadaptow anie SOA w infrastrukturze IT. Oczywiście, tem atyka ta jest jednym z głównych wątków we wszystkich rozdziałach tej książki, warto jednak zawczasu nazwać owe ko­ rzyści po imieniu, dzięki czemu już na początku uzyskamy klarowną wizję tego, co możemy osią­ gnąć, dokonując transformacji tradycyjnej platform y w stronę SOA. Zakończymy rozdział 3. spojrzeniem na pułapki występujące najczęściej na drodze do SOA. Zrozumienie „złych praktyk” jest istotne nie tylko dla unikania wielu poważnych problemów, ale pozwala też na lepsze zrozumienie (i docenienie) argumentacji kryjącej się za analizami i proce­ sami projektowymi prezentowanymi w następnych rozdziałach. Ewolucja SOA (rozdział 4.) W rozdziale 4. kontynuow ać będziem y tematykę genezy i rozwoju SOA — przyglądając się osi czasu, omówimy: • starsze platformy architektoniczne, z których SOA wyewoluowała do obecnej postaci, dziedzicząc „po drodze” rozmaite cechy charakterystyczne — te pożądane i te cokolwiek osobliwe; • bieżące czynniki, które ukształtowały SOA w obecnej postaci — głównie standard XML i technologie usług sieciowych; • działania organizacji standaryzacyjnych oraz dostawców sprzętu i oprogramowania, dodatkowo poszerzające możliwości platformy SOA. Rozpoczniemy od krótkiego rysu historycznego standardu XML i usług sieciowych, po czym pokażemy, jak te — obecnie rozpowszechnione — technologie wpłynęły na kształt współczesnej SOA i w dalszej konsekwencji stały się głównymi czynnikami warunkującymi jej sukces. Zwrócimy także uwagę na relację odwrotną, czyli wpływ na sposób użytkowania wspomnianych technologii — a konkretnie zmianę tego sposobu w stosunku do tradycyjnych wzorców. Sukces SOA nie narodził się w próżni, warto więc zastanowić się, co i kto jest jego siłą spraw­ czą. Pierwszorzędną rolę w tym dziele odgrywają niewątpliwie organizacje standaryzacyjne oraz dostawcy sprzętu i oprogram owania — przyjrzymy się więc dokładniej trzem najbardziej znanym twórcom standardów: • W orld W ide Web Consortium (W3C), • Web Services Interoperability Organization (WS-I), • Organization for the Advancement of Structured Inform ation Standards (OASIS). Nie zapom nim y — oczywiście — o ich dynam icznym powiązaniu z producentam i sprzętu i oprogramowania. Elementem owej dynamiki jest swoiste sprzężenie zwrotne, czyli wpływ tychże producentów na kształt definiowanych standardów usług sieciowych i nierzadko znaczący wkład w proces ich definiowania.

26

R O ZDZIA Ł 1. ■ W P R O W A D Z E N IE

W dalszej kolejności zajmiemy się definicjami „architektury aplikacji” i „architektury przed­ siębiorstwa” oraz pokażem y ich związek z architektonicznym aspektem SOA. Związek ten ma swą historię, bo korzenie „orientowania na usługi” tkwią głęboko w trzech następujących trady­ cyjnych platformach, których kontrast ze współczesną SOA postaram y się uwidocznić: • architekturze klient-serwer, • rozproszonej architekturze internetowej, • architekturach rozproszonych, wykorzystujących usługi sieciowe w sposób peryferyjny. Omawiając powyższe modele, opiszemy ich najważniejsze aspekty: logikę aplikacji, przetwa­ rzanie aplikacyjne, bezpieczeństwo i administrowanie. Zakończymy rozdział 4. wstępnym porównaniem „zorientowania na usługi” i „zorientowania obiektowego”. Usługi sieciowe a pierwotna SOA (rozdział 5.) W rozdziale 3. zdefiniowaliśmy formalnie charakterystykę pierwotnej SOA, w rozdziale 5. poka­ żemy natom iast, jak jej cechy szczególne odzwierciedlone zostały w technologiach tworzących pierwszą generację usług sieciowych. Rozpoczniemy od przeglądu fundam entalnych m echani­ zmów, tworzących framework komunikacyjny usług sieciowych, czyli: • podstawowej struktury kom unikatów wymienianych przez usługi sieciowe, • usług-dostarczycieli i usług-wnioskodawców, • opisów usług, kontraktów między usługami i metadanych, • czynnych i biernych pośredników, • ścieżek kom unikatów i kompozycji usług, • powszechnych modeli usług. Potem zajm iem y się specyfiką pierwotnej SOA; pokażemy, jak opisy usługi realizują luźne powiązanie, które w sposób kontraktowy łączy usługi składowe w architekturę SOA. W yjaśnimy podstawowe koncepcje kryjące się za abstrakcyjnymi i konkretnym i definicjami WSDL, a także wstępnie opiszemy UDDI i rejestry usług. Omówimy SOAP jako podstawowe narzędzie realizujące potrzeby SOA w zakresie komuni­ kowania — wyjaśnimy standardową strukturę komunikatów SOAP oraz rolę odgrywaną przez węzły przetwarzania SOAP. Rozdział 5. jest jednocześnie pierwszym, w którym pojawia się tekst opatrzony etykietką „Po p ro stu ...”. Skomplikowana tematyka tej książki, mimo iż ilustrowana licznymi przykładami, za­ pewne stanie się bardziej przystępna, jeśli przybliży się ją za pomocą prostych analogii o charakterze zdecydowanie pozatechnicznym — nawet jeśli niekiedy konieczne w związku z tym będzie zna­ czące uproszczenie.

1.5.2. Część II. SOA i rozszerzenia WS-* Kolejna część książki poświęcona jest zaawansowanym zagadnieniom związanym z mnogością rozszerzeń SOA.

1 .5 . O R G A N IZA C JA TEJ KSIĄŻKI

27

Usługi sieciowe i współczesna SOA — Część I. Zarządzanie aktywnościami i kompozycje (rozdział 6.) Lektura nabiera tem pa — wchodzimy w świat specyfikacji WS-*: w rozdziałach 6. i 7. pokażemy, jak specyfikacje te w istotny sposób wzbogacają możliwości SOA. Omówimy następujące elementy współczesnej SOA: • wzorce wymiany komunikatów, • aktywności, • koordynację, • transakcje niepodzielne, • aktywności biznesowe, • orkiestrację, • choreografię. Kolejność elementów na powyższej liście nie jest przypadkowa, każdy tworzy warstwę funk­ cjonalną, na bazie której budow any jest następny element. Koncepcje odnoszące się do pięciu ostatnich elementów są przedm iotem następujących specyfikacji WS-*: • WS-Coordination, • WS-AtomicTransaction, • WS-BusinessActivity, • WS-BPEL (dawniej BPEL4WS), • WS-CDL (dawniej WS-Choreography). Ponieważ w tej książce koncepcje celowo oddzielone zostały od szczegółów technologicznych, opis szczegółów składniowych języka używanego w specyfikacjach WS-* odkładamy do części V., „Budowanie SOA (technologie i projekt)”. Zwracamy natomiast uwagę na wzajemne związki między poszczególnymi specyfikacjami WS-* oraz między koncepcjami, które się za tymi specyfi­ kacjami kryją; wyjaśniamy także, jak każda z tych specyfikacji manifestuje swą obecność w postaci takiej czy innej cechy współczesnej SOA. Podobnie jak w rozdziale 5., także i tu wiele złożonych zagadnień wyjaśnianych jest w kon­ wencji pozatechnicznych analogii „Po p r o s t u . ”. Usługi sieciowe i współczesna SOA — Część II. Zawansowane komunikowanie, metadane i bezpieczeństwo (rozdział 7.) Rozdział ten prowadzi nieco głębiej w krainę rozszerzeń SOA i koncepcji stanowiących ich podłoże. Omówimy następujące tematy: • adresowanie, • niezawodne komunikowanie, • korelację, • polityki, • wymianę metadanych,

28

R O ZDZIA Ł 1. ■ W P R O W A D Z E N IE

• bezpieczeństwo, • powiadamianie i zdarzeniowanie. Wykorzystamy w tym celu następujące specyfikacje: • WS-Addressing, • WS-ReliableMessaging, • framework WS-Policy (w tym WS-PolicyAttachments i WS-PolicyAssertions), • WS-MetadataExchange, • WS-Security (w tym XML-Encryption i XML-Signature), • framework WS-Notification (w tym WS-BaseNotification, WS-Topics i WS-BrokeredNotification), • WS-Eventing. Podobnie jak w rozdziale 6., omawiane będą jedynie same koncepcje; języki związane z pię­ cioma pierwszymi specyfikacjami na powyższej liście omówione zostaną w rozdziale 17. I podobnie jak w rozdziale 6., zależności między poszczególnymi specyfikacjami i ich wpływ na charaktery­ stykę współczesnej SOA wyjaśnione zostaną także na przykładzie nieformalnych opisów kategorii „Po p r o s t u . ”.

1.5.3. Część III. SOA i zorientowanie na usługi Ta część książki poświęcona jest „zorientowaniu na usługi” jako paradygmatowi projektowemu. W yjaśnimy sens istotnych koncepcji, stanowiących podstawę różnych podejść do projektowania usług i ich architektury — podejść opisywanych w następnych rozdziałach. Zasady orientacji na usługi (rozdział 8.) W rozdziale 8. skoncentrujem y się na fundam entalnych zasadach „zorientowania na usługi” — zasadach zarówno formujących podstawę SOA, jak i kształtujących oraz standaryzujących po­ szczególne usługi składające się na SOA. W prowadzamy tu model „logiki enterprise”, czyli „logiki przedsiębiorstwa” dzielącej się na dwie dom eny — logikę biznesową i logikę aplikacyjną; model ten stanowić będzie punkt odniesienia dla treści następnych rozdziałów. Pokazujemy, jak poprzez owe dom eny SOA realizuje promocję zorientowania na usługi. Następnie zajmiemy się logiką SOA i jej podstawowymi elementami. Omówimy kluczowe kom ponenty frameworku usług sieciowych i pokażemy ich umiejscowienie w ram ach SOA; po­ każemy też wzajemne powiązania między kom ponentam i SOA. Kolejną część rozdziału poświęcimy wyczerpującemu omówieniu ośmiu podstawowych zasad zorientowania na usługi; każdą z tych zasad zilustrujemy przykładami w postaci analiz przypadku. Uwidocznimy powiązania między tymi zasadami, czyli pokażemy, jak są od siebie uzależnione oraz jak niektóre dostarczają wsparcia dla innych. Dla czytelników znających tematykę orientacji obiektowej (OO) z pewnością interesujące okaże się porów nanie podstawowych zasad tej orientacji z zasadami orientacji na usługi — po­ równanie ujawniające istotny wpływ, jaki OO wywarło na kształtowanie SOA.

1 .5 . O R G A N IZA C JA TEJ KSIĄŻKI

29

Rozdział zakończymy interesującym porów naniem — porównaniem zasad zorientowania na usługi z zestawem cech, jakimi charakteryzowały się platformy usług sieciowych pierwszej gene­ racji. Porównanie to pozwoli odróżnić te ze wspomnianych zasad, które realizowane są niejako automatycznie przez korzystanie z tradycyjnych usług sieciowych, od tych, których realizacja wy­ maga dodatkowego wysiłku. Rozróżnienie to jest istotne o tyle, że wyznacza listę problemów, które należy krok po kroku rozwiązywać w ram ach procesów projektowych. Warstwy usług (rozdział 9.) W tym rozdziale kontynuować będziemy omawianie charakterystyki współczesnej SOA. W ska­ żemy na te czynniki, które w głównej m ierze odpowiedzialne są za tę charakterystykę, po czym powrócimy do wspomnianego wcześniej podziału tej charakterystyki — czyli wyodrębnimy te jej elementy, których realizacja wymaga jawnego wysiłku ze strony projektantów; najważniejsze z tych elementów to zorientowane usługowo modelowanie biznesowe i zwinność organizacyjna. Następnie przejdziemy do definiowania podejścia projektowego uwzględniającego wspomniane cechy — podejścia, w ram ach którego serie specjalizowanych warstw usługowych realizują abs­ trakcję kluczowych elementów logiki generycznej i specyficznej dla aplikacji. Tak właśnie reali­ zuje się SOA w skali przedsiębiorstwa. Na tym etapie definiowane są trzy następujące warstwy usługowe: • warstwa usług aplikacji, • warstwa usług biznesowych, • warstwa usług orkiestracji. W arstwy te tworzą podwalinę pod serię standaryzowanych usług, om awianych szczegółowo w następnych rozdziałach. Dalej w rozdziale zajm iem y się kilkom a zagadnieniam i zw iązanym i z tw orzeniem usług w sposób oderwany od konkretnego rozwiązania, w którym usługi te będą wykorzystywane (solu­ tion-agnostic services). Rozdział zakończymy przeglądem ośmiu różnych scenariuszy konfiguracji warstw usługowych — jako ilustracją zakresu różnorodności możliwych projektów SOA.

1.5.4. Część IV. Budowanie SOA (planowanie i analiza) Treść wszystkich poprzednich rozdziałów poświęcona była koncepcjom i teorii, teraz nadszedł czas na pokazanie, jak teorię tę należy wykorzystywać w praktyce rzeczywistego świata. Rozdziały tej części za­ wierają opis realizacji urzeczywistniania projektów współczesnej SOA oraz szczegółowy instruktaż na temat definiowania logiki biznesu i logiki aplikacji oraz modelowania ich w postaci kandydatur na usługi. Strategie realizacji SOA (rozdział 10.) SOA przedstawiana jest tu z perspektywy urzeczywistniania projektu poprzez nazwanie i opisanie typowych faz składających się na cykl życiowy tego urzeczywistniania. Fazy te konsolidowane są następnie według trzech strategii: • zstępującej (top-down), • wstępującej (bottom-up), • zwinnej (agile).

30

R O ZDZIA Ł 1. ■ W P R O W A D Z E N IE

Omówiono zalety i wady każdej z nich, ze szczególnym uwzględnieniem charakterystyki stra­ tegii zwinnej, łączącej w pewnym sensie zalety i wymagania dwóch pozostałych strategii. Analiza zorientowana na usługi — Część I. Wprowadzenie (rozdział 11.) Omówiliśmy już fundam entalne i zaawansowane koncepcje związane z SOA oraz orientacją na usługi, a także wiele elementów wsparcia dla frameworku usług sieciowych. W tym rozdziale ro ­ bimy pierwszy krok w kierunku wykorzystania tej wiedzy, w ram ach fazy analizy zorientowanej na usługi. Definiujemy ogólne cele analizy zorientowanej na usługi, po czym prezentujemy listę kroków składających się na realizację tej fazy. O statnim z rzeczonych kroków jest proces modelowania usług, którem u poświęcamy rozdział 12. W dalszej części rozdziału omawiamy to, co składa się na tzw. SOA skoncentrowaną biznesowo (business-centric SOA). Wyjaśniamy kluczowe korzyści wynikające z zainwestowania w warstwy usług biznesowych i prezentujemy różne sposoby wyprowadzania usług biznesowych z istniejących modeli biznesowych. Generalnie poszczególne punkty tego rozdziału mają charakter przygotowawczy do studio­ wania krok po kroku procesu modelowania usług, opisywanego w następnym rozdziale. Analiza zorientowana na usługi — Część II. Modelowanie usług (rozdział 12.) Prześledzimy teraz składający się z dwunastu kroków proces, w ramach którego zastosujemy orientację na usługi do istniejącego biznesowego przepływu pracy i wyprowadzimy kandydatury na usługi biznesowe i usługi aplikacyjne. Stworzone w ten sposób kandydatury stanowić będą podstawowe dane wejściowe do osta­ tecznego projektu SOA, który stanowić będzie zwieńczenie procesów projektowych opisywanych w następnych rozdziałach. Nasz proces modelowania usług zakończymy szczegółowymi analiza­ mi przypadków dem onstrującymi przebieg poszczególnych kroków procesu. Następnie przedstawimy kilkanaście wskazówek dotyczących modelowania usług — porad, rekomendowanych standardów analizy i dodatkowych zaleceń. W kolejnej części rozdziału przedstawimy opcjonalną klasyfikację systemów, którą wykorzy­ stać m ożna do dalszego rozszerzenia procesu analizy. Klasyfikacja ta wyodrębnia i nazywa jed­ nostki logiczne, które mogą poprawić klarowność dokumentacji i dopomóc w zidentyfikowaniu potencjalnych okazji do wieloużywalności. Rozdział zakończymy inną szczegółową analizą przypadku, w którym druga z naszych m ode­ lowych fikcyjnych firm staje się podm iotem procesu modelowania, tym razem z zastosowaniem wzmiankowanego systemu klasyfikacji. Rezultatem tej analizy są trzy różne kombinacje kandy­ datur na usługi, ilustrujące wyniki kontrastujących podejść.

1.5.5. Część V. Budowanie SOA (technologie i projekt). Ta najbardziej obszerna część książki poświęcona jest procesom projektowania (krok po kroku) specjalizowanych usług SOA i tworzeniu zorientowanych na usługi procesów biznesowych. Licz­ ne tutoriale technologiczne pomagają w zrozum ieniu prezentowanych przykładów kodu. Całość zamyka przegląd platform technologicznych implementujących SOA, ze szczególnym uwzględ­ nieniem frameworku .NET i platformy J2EE.

1 .5 . O R G A N IZA C JA TEJ KSIĄŻKI

31

Projektowanie zorientowane na usługi — Część I. Wprowadzenie (rozdział 13.) W tym rozdziale ponownie ruszamy do przodu, począwszy od miejsca, w którym zakończyliśmy fazę analizy. Jesteśmy przygotowani do przekształcenia naszych kandydatur na projekt zoriento­ wany usługowo. Pierwszym krokiem na nowej drodze będzie ćwiczenie kompozycyjne SOA, które pomoże w ziden­ tyfikowaniu granic architektonicznych naszego planowanego rozwiązania (ten krok jest szczegółowo analizowany w rozdziale 14.). Pozostałe kroki będą reprezentować następujące procesy projektowe: • projektowanie usług skoncentrowane na encjach, • projektowanie usług aplikacji, • projektowanie usług skoncentrowane na zadaniach, • projektowanie procesu biznesowego zorientowanego na usługi. Każdy z tych procesów opisywany jest z detalam i w rozdziałach 15. i 16. Celem wszystkich tych ćwiczeń jest utworzenie w języku WSDL definicji implementacyjnych kandydatur na usługi (wyodrębnionych w procesie analizy). Czytelnicy otrzymują krótki przewodnik dotyczący: • języka WSDL, • elementów WSDL Schema związanych z WSDL, • elementów struktury kom unikatów SOAP. Ograniczmy się jednak tylko do elementów występujących w kodzie przykładów. Rozdział kończy się dyskusją na tem at podejść do modelowania interfejsów, porównane są tu narzędzia dedykowane tem u modelowaniu z ręcznym kodowaniem. Projektowanie zorientowane na usługi — Część II. Wytyczne komponowania SOA) (rozdział 14.) W rozdziale 14. zajmujemy się procedurą kom ponowania architektury zorientowanej na usługi na podstawie znanych wymagań funkcjonalnych i ograniczeń technicznych. Jako część tej proce­ dury prezentujem y wskazówki dotyczące wyboru warstw usług oraz umiejscowienia zidentyfiko­ wanych standardów i rozszerzeń SOA. W szczególności omawiamy problemy projektowe związane z wykorzystywaniem XML, WSDL, XML Schema, SOAP, UDDI i WS-I Basic Profile na potrzeby SOA. Rozdział kończymy wska­ zówkami na tem at wyboru specyfikacji WS-*, zwracając uwagę na specyfikację WS-BPEL. Projektowanie zorientowane na usługi — Część III. Projektowanie usług (rozdział 15.) Rozdział 15. — najdłuższy ze wszystkich rozdziałów tej książki — zawiera szczegółowe opisy trzech procesów projektowania usług, odpowiadających dwóm spośród trzech warstw usług, które definiowaliśmy w rozdziale 9. — opisane są procesy: • projektowania usług ukierunkowanych na podm ioty (zwane także encjami — entities), • projektowania usług aplikacyjnych, • projektowania usług ukierunkowanych na zadania. Każdy opis uzupełniony jest obszernymi analizami przypadków, demonstrującymi zastoso­ wanie poszczególnych kroków procesu w „prawdziwych” scenariuszach. Ten — niezwykle ważny — rozdział zamykamy kilkoma wskazówkami dotyczącymi poprzednio opisywanych procesów.

32

R O ZDZIA Ł 1. ■ W P R O W A D Z E N IE

Projektowanie zorientowane na usługi — Część IV. Projektowanie procesu biznesowego (rozdział 16.) W tym rozdziale przedstaw iam y szczegółowy scenariusz budow ania procesu biznesowego zo­ rientowanego na usługi. W ram ach analiz przypadków tworzona jest definicja procesu WS-BPEL, w którym dokonuje się orkiestracja usług wymodelowanych i zaprojektowanych w treści poprzed­ nich rozdziałów. Zanim jednak przejdziemy do projektowania samego procesu biznesowego, przedstawiamy krótki tutorial opisujący kluczowe elementy języka WS-BPEL wykorzystywane we wspomnianych powyżej przykładowych analizach przypadków. Opisujemy również pokrótce strukturę nagłówków SOAP związanych ze specyfikacją W S-Coordination. Podstawowe rozszerzenia WS-* (rozdział 17.) Efekt naszych dotychczasowych doświadczeń to zbiór usług ustanawiających maksymalnie trzy poziomy abstrakcji, stosownie do procesu biznesowego odpowiedzialnego za orkiestrację tychże usług. W tym rozdziale zajmiemy się technicznymi aspektami rozszerzania SOA za pomocą spe­ cyfikacji WS-* opisywanych w rozdziale 7. O m awiamy kluczowe elementy i konstrukcje nastę­ pujących specyfikacji: • WS-Addressing, • WS-ReliableMessaging, • WS-Policy, • WS-MetadataExchange, • WS-Security. Każdy z tych opisów uzupełniony jest przykładami analiz przypadków, ilustrującymi koncep­ cje wprowadzone w rozdziale 7. Platformy SOA (rozdział 18.) O statni rozdział poświęcamy bliższemu przyjrzeniu się charakterystyce platform im plem entu­ jących SOA. Wyjaśniamy znaczenie poszczególnych składników środowiska programistycznego przeznaczonego do tw orzenia rozwiązań zorientow anych na usługi oraz środowiska urucho­ mieniowego, którego zadaniem jest hostowanie działających rozwiązań. Zaglądamy też „pod pod­ szewkę” im plem entacji typowej usługi sieciowej, by przyjrzeć się szczegółom logiki tej im ple­ mentacji. W dalszej części rozdziału, w dwóch punktach o identycznej strukturze, analizujemy wsparcie dla SOA dostarczane przez dwie najpopularniejsze platform y — .NET i J2EE. Każdy z punktów rozpoczynamy wprowadzeniem o charakterze wysokopoziomowym, po czym przechodzimy do omówienia wspomnianego wsparcia w aspekcie następujących tematów omawianych w poprzed­ nich rozdziałach: • charakterystyki pierwotnej SOA, • zasad zorientowania na usługi, • charakterystyki współczesnej SOA.

1.6. INFORMACJA DODATKOWA

33

Analizy przypadków — konkluzja (Dodatek A) Dodatek A to swego rodzaju epilog do serii analiz przypadku, ukazujących historię rozwoju dwóch fikcyjnych firm; serii zapoczątkowanej w rozdziale 2. Podsum ow ujem y przebieg transform acji w obu firm ach i analizujemy finalne rozwiązanie, głównie w kategoriach spełnienia założonych na wstępie celów. Modele usług — lista referencyjna (Dodatek B) Dodatek B to lista referencyjna wszystkich modeli usług opisywanych w tej książce.

1.5.6. Konwencje stylistyczne — uwagi • Podsumowania — każdy istotny fragment książki zwieńczony jest podsumowaniem, które w formie wypunktowanej listy streszcza najważniejsze zagadnienia i konkluzje. Dla czytelnika podsumowania takie mogą stanowić krótki sprawdzian zrozumienia treści książki. • Rysunki — książka zawiera ponad trzysta diagramów, umownie nazywanych „rysunkami”. Objaśnienie symboli używanych na tych diagramach znajdą czytelnicy pod adresem http://servicetechbooks.com/ctd/symbol_legend. • Przykładowy kod — niektóre z prezentowanych przykładów zawierają wiersze, niemieszczące się na szerokości stronicy, więc z oczywistych względów wiersze te należało w druku „zawinąć”. Dotyczy to przede wszystkim długich adresów URL odnoszących się do przestrzeni nazw. Gdy wkleimy taki „długi wiersz” do edytora, będzie on prawdopodobnie „pokawałkowany” znakami łamania linii — nieistotnymi dla czytelności, ale ewidentnie „psującymi” kod XML. Nie m ożna więc zapom inać o usunięciu owych zbędnych znaków łamania przed uruchom ieniem wklejonego kodu.

1 .6 . In fo rm a c ja d o d a tk o w a 1.6.1. Framework XWIF (XML & Web Services Integration Framework) Niektóre fragm enty treści tej książki wywodzą się z badań przeprow adzanych przez autora dla SOA Systems Inc. (dawniej XMLTC Consulting Inc.) w ram ach projektu XML & Web Services Integration Framework (XWIF). Czytelników zainteresowanych szczegółami tego projektu zapra­ szamy na stronę www.xwif.com.

1.6.2. www.serviceoriented.ws Aktualizacje treści tej książki, przykładow y kod i wiele innych zasobów związanych z książką znajdą czytelnicy pod adresem http://servicetechbooks.com/ctd Czekamy także na opinie i sugestie czytelników, które z pewnością przyczynią się do ulepszeń następnych wydań książki.

1.6.3. Kontakt z autorem Autor książki zaprasza na swą prywatną stronę www.thomaserl.com/technology.

34

ROZDZIAŁ 1. a WPROWADZENIE

Rozdział 2

Analizy przypadków 2.1. Jak prezentowane są analizy przypadków? 2.2. Przypadek nr 1: RailCo Ltd. 2.3. Przypadek nr 2: Transit Line Systems Inc

36

RO ZDZIA Ł 2. ■ A N A L IZ Y PR ZYPAD KÓ W

Ze względu na specyficzną naturę nowoczesnych architektur zorientowanych usługowo, analizy przypadków pomyślane zostały jako efektywny sposób wyjaśniania wielu skomplikowanych kon­ cepcji omawianych w tej książce. Analizy te, choć całkowicie fikcyjne, znakomicie ilustrują wiele rzeczywistych problem ów i wyzwań, z jakimi mierzyć się muszą codziennie informatycy w przed­ siębiorstwach. W tym rozdziale czytelnicy wprowadzeni zostaną w realia dwóch różnych organizacji. Pierw­ sza z nich, RailCo Ltd., to średniej wielkości przedsiębiorstwo, posiadające niewielki zespół IT. Druga firma — Transit Line Systems Inc. (TLS) — jest już zdecydowanie większa i posiada kilka działów IT, odpowiedzialnych za zarządzanie infrastrukturą informatyczną. Chociaż każda z wy­ mienionych firm jest przedm iotem osobnej analizy przypadku, to między firmami tymi istnieją powiązania biznesowe.

2.1. Jak prezentow ane są analizy przypadków? W następnych rozdziałach znajdą czytelnicy około sto dwadzieścia przykładów opartych na ana­ lizie wym ienionych firm, stanowiących niezm ienny punkt odniesienia do rzeczywistego świata. Metamorfoza obu firm w stronę SOA, odzwierciedlana w ram ach kolejnych analiz, m a swój finał opisany w dodatku A.

2.1.1. Stylistyka W celu lepszego uwidocznienia analiz przypadków wyróżniono je przez umieszczenie na szarym tle, jak w poniższym przykładzie:

...Początkowo podejście to nie budziło żadnych zastrzeżeń, ponieważ każda z aplikacji do­ starczała oczekiwanych możliwości i spełniała pokładane w niej nadzieje dotyczące rozwią­ zywania określonych problem ów biznesowych. Ponieważ jednak nie przewidziano żadnej strategii zapewniającej wykorzystywanie XML i usług sieciowych w kierunku wsparcia dla SOA, brak było środków zapobiegających pojawieniu się rozbieżności w p ro je k to w a n iu .

2.1.2. Związek z treścią Mimo iż zamieszczone analizy przypadków służą wyjaśnianiu opisywanych abstrakcyjnie koncepcji, technologii i procesów, to jednak ów abstrakcyjny opis nie jest od nich w żaden sposób zależny. Czytelnicy zainteresowani jedynie ogólnym zrozumienie danego tem atu mogą więc — bez szkody dla tego zrozum ienia — pomijać analizy przypadków towarzyszące omawianiu tegoż tematu.

2.1.3. Przykładowy kod Rozdziały składające się na część V zawierają liczne przykłady kodu źródłowego w językach XML i WSDL, ilustrujące wykorzystanie konkretnych technik i technologii, opisywanych w treści wspo­ mnianych rozdziałów. Książka została zaprojektowana w ten sposób, że wszystkie prezentowane elem enty użytego kodu są szczegółowo opisane — pewnym odstępstwem od tej reguły są trzy przykłady w rozdziale 17., prezentujące pewien aspekt wykorzystania elementu-kontenera.

2 .2 . PRZYPADEK NR 1: RAILCO LTD.

37

2.2. Przypadek nr 1: RailCo Ltd. RailCo Ltd. to znany dostawca części dla kolejnictwa, głównie hamulców pneumatycznych i zwią­ zanego z nim i wyposażenia. Firma działa na całym świecie, lecz 90% transakcji odbywa się na te­ renie Ameryki Północnej. Mimo iż głównym obszarem działalności firmy jest sprzedaż, firma za­ trudnia także niewielką grupę specjalistów wykonujących lokalnie naprawy i instalacje.

2.2.1. Historia Firm a powstała w latach dziewięćdziesiątych ubiegłego wieku i zatrudniała wówczas dw unastu pracowników; z biegiem czasu zatrudnienie wzrosło do dwudziestu osób. Początkowo, działając jako pośrednik między producentam i różnorodnego sprzętu dla kolejnictwa a hurtownikami, wy­ specjalizowała się w obszarze hamulców pneumatycznych; konsekwencją tej specjalizacji było po­ większenie relacji biznesowych, wskutek czego RailCo sama stała się hurtowym sprzedawcą sprzętu hamulcowego, pozyskiwanego bezpośrednio od producentów.

2.2.2. Infrastruktura techniczna Infrastrukturą IT firmy zajmuje się pięcioro pełnoetatowych pracowników, podlegających jednemu menedżerowi. Są oni odpowiedzialni przede wszystkim za utrzymanie operatywności stacji klienc­ kich oraz serwerów zaplecza, poprzez ich aktualizacje oraz naprawianie luk i błędów. Opracowy­ wanie nowych rozwiązań zlecane jest na zasadzie outsourcingu lokalnej firmie konsultingowej.

2.2.3. Rozwiązania automatyzacyjne W skład środowiska automatyzacji biznesu firmy RailCo wchodzą następujące aplikacje. • System finansowo-księgowy, zbudowany w dwuwarstwowej architekturze klient-serwer, obsługujący wszystkie transakcje księgowe i inwentarzowe. Dokum enty dla wspomnianych transakcji — głównie zamówienia od klientów, zamówienia dla producentów i faktury — wprowadzane są do systemu ręcznie przez dwóch pracowników administracyjnych. Otrzymanie i zatwierdzenie tych dokum entów rozpoczyna zwykle powiązane procesy kontroli stanu w magazynie i realizacji zamówienia. • System komunikacji z menedżerami (contact management), zarządzający przechowywanymi profilami klientów i partnerów biznesowych. System ten jest stosunkowo prostą aplikacją, przechowującą dane w pojedynczej bazie; wprowadzanie danych i raportowanie odbywa się za pośrednictwem interfejsu użytkownika opartego na przeglądarce W W W . Klientami systemu są menedżerowie i ich zastępcy oraz personel finansowo-księgowy.

2.2.4. Cele biznesowe i przeszkody Zysk firmy w ciągu ostatniego roku wykazywał wyraźną tendencję spadkową. Poszukiwanie przy­ czyn tego stanu rzeczy doprowadziło do konkluzji, iż głównym winowajcą jest nieakceptowalny poziom kosztu procesów biznesowych, w wyniku czego klienci zwracają się do konkurencyjnej firmy, oferującej te same produkty w sposób znacznie wygodniejszy i po wyraźnie niższej cenie.

38

RO ZDZIA Ł 2. ■ A N A L IZ Y PR ZYPAD KÓ W

Ta konkurencyjna firma zmodyfikowała niedawno swój system finansowo księgowy, co po­ zwoliło na przeprowadzanie w trybie online rozmaitych transakcji, także w ram ach relacji z roz­ wiązaniami B2B większych klientów. Nie tylko przyczyniło się to do zwiększenia konkurencyjności, lecz także pozwoliło na obniżenie kosztów działalności dzięki redukcji personelu administracyjnego. W stronę owej konkurencji zwrócił się również dotychczasowy główny klient RailCo — firma Transit Line Systems, co zdecydowanie nie było dobrą nowiną. Tak oto przestarzała, nieefektywna technologia automatyzacji biznesu okazała się podstawową przyczyną kłopotów. W celu ich zażegnania należało więc natychmiast podjąć działania zmierzające do unowocześnienia infrastruktury technicznej, tak by była zdolna sprostać wyzwaniom i potrzebom nowoczesnych trendów biznesowych. Przede wszystkim, aby na pow rót stać się atrakcyjnym partnerem dla Transit Line Systems, RailCo m usi zapewnić sobie możliwość dokonywania transakcji online z tą firmą. Zrobiony został nawet pierwszy krok na tej drodze — opracowanie dwóch usług sieciowych zapewniających RailCo łączność z istniejącymi systemami B2B swego partnera. Ich schemat przedstawiamy na rysunku 2.1, a szczegóły wyjaśniać będziemy stopniowo w następnych rozdziałach. Do projektu tego powrócimy także w części V. \

Usługa Wystawienie faktury

Usługa Realizacja zamówienia

\

\ RailCo

Rysunek 2.1. Początkowy zestaw usług sieciowych firmy RailCo, zaprojektowany głównie na potrzeby łączności z systemami B2B firmy TLS

RailCo zdała więc sobie sprawę z własnych ograniczeń i faktu, że sposobem na ich zniwelowanie jest unowocześnienie struktury IT w kierunku budowy SOA. Dodatkowym czynnikiem motywu­ jącym tę decyzję — i jednocześnie kształt projektu tej metamorfozy — jest konieczność pozyska­ nia nowych klientów w celu odrobienia strat wynikających ze spadku sprzedaży na rzecz TLS. Zauważmy przy okazji, że usługa wystawiania faktur, mimo iż technicznie w postaci odrębnego kodu WSDL, często występuje w roli usługi-wnioskodawcy, wysyłając dokum enty do odpowied­ niej usługi sieciowej TLS. Nie można jednak traktować jej po prostu jako programu klienckiego tej ostatniej: pełni ona przede wszystkim rolę dostarczyciela i jako taka przedstawiana będzie w n a­ stępnych rozdziałach w kontekście opisu ewolucji RailCo w stronę SOA. W rozdziale 5. wyjaśnimy dokładniej, jak dana usługa może spełniać jednocześnie rolę wnioskodawcy i dostarczyciela.

2 .3 . PRZYPADEK NR 2: TR A N S IT LINE SYSTEMS INC

39

2.3. Przypadek nr 2: Transit Line Systems Inc Transit Line Systems Inc. (TLS) to znaczący gracz w sektorze transportu prywatnego. Firma po­ siada biura w czterech miastach i zatrudnia prawie dwa tysiące pracowników. Mimo iż to transport stanowi główną linię działalności firmy, działalność uzupełniona jest kilkoma usługami drugo­ rzędnymi, a mianowicie: • outsourcingiem konserwacji i napraw sprzętu do sektora transportu publicznego, • wytwarzaniem części i podzespołów dla innych gałęzi przemysłu, • turystyką, realizowaną w drodze współpracy z liniami lotniczymi i hotelami.

2.3.1. Historia Przez wiele lat firma TLS funkcjonowała jako średniej wielkości korporacja skupiona wokół jednej prywatnej kolei, jednakże w rezultacie wygranej długotrwałej walki z rywalem identycznej branży (walki zakończonej bankructwem tegoż rywala) rozpoczął się okres ekspansji firmy. Po poszerzeniu swej dom eny o dwie następne koleje w innych miastach, w ciągu ok. dziesięciu lat firma przejęła kilka innych korporacji, między innymi: • G&R Tracks Ltd., prywatną kompanię kolejową: ten niegdysiejszy konkurent TLS dostarczył teraz swemu właścicielowi niezbędnych zasobów do wybudowania nowej kolei w sąsiednim mieście; G&R zatrudniała ponad stu osiemdziesięciu pracowników, TLS zatrzymała z tego jedynie dziesięciu specjalistów technicznych, • Sampson Steel Corp., dużego producenta rozmaitego asortymentu metalurgicznego na potrzeby przemysłów lotniczego i samochodowego. Firma ta znalazła się na krawędzi bankructw a z pow odu spadku koniunktury wywołanego ekspansją TLS. W rezultacie obie firmy połączyły się w holding, w którym TLS został większościowym udziałowcem, natomiast Sampson zachował samodzielność w zakresie sterowania działalnością operacyjną. Sampson nie zaprzestał świadczenia usług dla dotychczasowych klientów, jednakże głównym obszarem jego działalności stała się produkcja części na potrzeby kolei zarządzanych przez TLS. I choć było to jedynie wyposażenie podstawowe, to koszt jego pozyskiwania przez TLS był teraz kilkakrotnie niższy w porów naniu z cenami u innych dostawców.

2.3.2. Infrastruktura techniczna Centrala firmy TLS posiada rozbudowany dział IT: spośród dwustu specjalistów obsługujących automatyzację biznesu ok. 50% to pracownicy kontraktowi, zatrudnieni w związku z konkretnymi projektami. Ogólnie rzecz biorąc, infrastruktura IT firmy m a charakter mieszany. Z jednej strony, nowsze rozwiązania typu eBiznes hostowane są w środowisku klastera serwerów, zdolnych do nadążania z obsługą intensywnego strum ienia transakcji, wyposażonych w m echanizmy szybkiego przywra­ cania poprawnego stanu po awarii i zabezpieczonych niezawodnymi kopiami zapasowymi; drugą stronę stanowią starsze, „spadkowe” systemy, w większości działające w oddzielnych środow i­ skach, w izolacji od innych systemów. Podstawę sprzętową stanowią nowoczesne komputery m ain­ frame, a seria serwerów opartych na systemie W indows obsługuje starsze, specjalizowane systemy typu klient-serwer i związane z tymi systemami bazy danych.

40

RO ZDZIA Ł 2. ■ A N A L IZ Y PR ZYPAD KÓ W

2.3.3. Rozwiązania automatyzacyjne Ze „spadkowych” systemów informatycznych w firmie TLS dwa następujące będą często przy­ woływane w analizach przypadków. • Rozproszony system finansowo-księgowy, obsługujący ok. czterystu użytkowników. System ten stał się następcą oryginalnego pakietu księgowego firmy TLS, gdy ten nie był już w stanie sprostać wymaganiom dynamicznie rozwijającej się firmy. Nowy system księgowy jest rozwiązaniem specyficznym dla TLS, choć jego funkcjonalność opiera się na standardow ych m echanizm ach, typowych dla księgowości. System ten posiada wyrafinowany interfejs webowy na potrzeby dostępu zdalnego i dostępu z intranetu, udostępnia jednak również narzędzia desktopowe przeznaczone dla potrzeb analizy i raportow ania. Dostawca systemu, patrząc perspektywicznie, wyposażył ów system w zestaw wtyczek pełniących rolę adapterów usług sieciowych dla różnych m odułów. • System kontroli czasu pracy pracowników świadczących usługi outsourcingowe na zewnątrz firmy. Informacje zbierane przez ten system są następnie wprowadzane ręcznie do systemu finansowo-księgowego, za pośrednictwem odpowiedniego modułu.

2.3.4. Cele biznesowe i przeszkody Intensywne przem iany, jakie dokonały się w firmie TLS w ostatnim dziesięcioleciu, oznaczały między innymi kilkakrotną zmianę tożsamości i struktury firmy, głównie ze względu na przejęcia innych firm i wynikające stąd procesy integracyjne. Postawiło to niełatwe zadanie przed specjali­ stam i z działu IT, którzy musieli zmagać się z ulotnym , wciąż ewoluującym m odelem bizneso­ wym i w konsekwencji ciągłym uzupełnianiem infrastruktury nowymi rozwiązaniami i technolo­ giami. W rezultacie infrastruktura ta nafaszerowana została licznymi doraźnymi aplikacjami oraz produktami firm trzecich — produktami, które w zamierzeniu autorów nie zostały zaprojektowane do współdziałania z innymi. Koszty automatyzacji biznesu poczęły więc drastycznie rosnąć, podobnie jak wysiłki zmierza­ jące do zapanowania nad mnogością systemów i zmuszenia ich do współpracy. To oznaczało nie tylko nierozsądnie wysokie koszty utrzym ania, ale przede wszystkim brak elastyczności i nad­ m ierną złożoność, a w konsekwencji niemożność należycie szybkiego reagowania na częste zmia­ ny procesów biznesowych. Kierownictwo IT, zmęczone koniecznością nieustannego inwestowania w niefunkcjonalne środowisko, postanowiło zaadoptować SOA, zarówno jako standardową architekturę dla nowych aplikacji, jak i w charakterze fundamentalnego środka dla połączenia istniejących systemów spad­ kowych. Podstawową motywacją tej nieco desperackiej decyzji była pilna konieczność zestandaryzowania istniejących rozwiązań w skali całej firmy i zwiększenie zwinności organizacyjnej. W chwili, gdy rozpoczyna się nasza historia, TLS dysponuje już pierwszą wersją rozwiązania zorientow anego usługowo, w idoczną na rysunku 2.2. Z tą właśnie konfiguracją (czyli de facto systemem B2B) łączy się RailCo (i wielu innych kontrahentów) w celu realizowania transakcji online. Omawianie usług składowych tej konfiguracji rozpoczynamy od rozdziału 5. i kontynu­ ujemy w następnych rozdziałach poświęconych technologii usług sieciowych. W części V opiszemy jednak „przesiadkę” TLS na nowy projekt SOA — jego usługi składowe oraz niezbędne transfor­ macje, jakie w związku z nim i poczynić musi firma na swojej platformie technologicznej.

2 .3 . PRZYPADEK NR 2: TR A N S IT LINE SYSTEMS INC

41

Usługa Płatność na konto

Usługa Profile dostawców

Usługa Zlecenie zakupu

Usługa Rejestr księgi głównej

Usługa Równoważenie obciążenia

Usługa Polityka wewnętrzna

Usługa Powiadamianie

TLS

Rysunek 2.2. Usługi sieciowe składające się na system B2B firmy TLS

42

ROZDZIAŁ 2. ■ ANALIZY PRZYPADKÓW

Część I

Fundamenty SOA i usług sieciowych Rozdział 3. W prowadzenie do SOA Rozdział 4. Ewolucja SOA Rozdział 5. Usługi sieciowe a pierwotna SOA

„Wcale nie potrzebujesz usług sieciowych, by zbudować SOA” — to zdanie spotyka się nader często w różnych sytuacjach związanych z wyjaśnianiem architektury zorientowanej na usługi. I równie często niedługo potem następuje ciąg dalszy w rodzaju „...ale budowanie SOA przy użyciu usług sieciowych to diabelsko dobry pomysł!”. Treść tej książki w pełni potwierdza podstawową zasadę, że SOA oraz zorientowanie na usługi to paradygmaty możliwe do zaimplementowania przy użyciu wielu różnych technologii, lecz jed­ nocześnie abstrakcyjne, bo niepozostające w związku z żadną konkretną platformą technolo­ giczną. Więc być może pewnego dnia pojawi się platforma zdolna do zdetronizowania w tej roli usług sieciowych i poprowadzenia świata IT jeszcze bliżej pełnego zorientowania na usługi, jednak zanim to nastąpi właśnie usługi sieciowe (i wszystkie pożytki, które ze sobą niosą) m uszą nam w tej roli wystarczyć — a trzeba przyznać, że wystarczają znakomicie. I dlatego większość tej książki poświęcona jest budowaniu SOA drogą realizacji zasad zorien­ towania na usługi na gruncie technologii usług sieciowych. I vice versa — opisujemy w tej książce koncepcje i technologie usług sieciowych przede wszystkim z perspektywy ich przydatności do tego właśnie celu.

Wprowadzenie do SOA 3.1. Fundam enty SOA 3.2. Ogólnie o współczesnej SOA 3.3. Najczęstsze nieporozum ienia dotyczące SOA 3.4. Najważniejsze wymierne pożytki z SOA 3.5. Najważniejsze pułapki w adaptacji SOA

46

ROZDZIAŁ 3 . ■ W P R O W A D Z E N IE DO SOA

Zanim zajmiemy się szczegółami rozwiązań zorientowanych na usługi i praktycznym tworzeniem tych rozwiązań, zdefiniujmy wpierw kilka podstawowych koncepcji i przedstawmy podstawowe problemy związane z nimi.

3.1. Fundamenty SOA Termin „orientacja na usługi” funkcjonuje już od dłuższego czasu i to w różnych kontekstach, i dla różnych celów. Niezmiennym elementem każdego z tych znaczeń jest jednak aspekt dekompozycyjny — czyli osobne traktowanie poszczególnych podproblemów rozwiązywanego problemu. Oznacza to, że logika rozwiązywania skomplikowanego problemu może być jaśniej skonstruowana, mniej złożona i lepiej kontrolowana, gdy problem ten rozpatrywany będzie jako kolekcja prost­ szych, powiązanych części; każda z tych części odpowiadać powinna dobrze określonemu aspek­ towi oryginalnego problemu. Ta generyczna reguła dekompozycji przenika wszem i wobec każde praktyczne podejście do rozwiązywania dowolnych problemów, także rozwiązań automatyzacji Im nesu i przeznaczonych do tego technologii — SOA nie jest w tym względzie wyjątkiem. Tymftcmak, co dla SOA cha­ rakterystyczne, jest sposób, w jaki wykonywana jest separacja ppdtooble$ów .

3.1.1. Orientacja na usługi — analogia

K

Wyobraźmy sobie typowe, tętniące życiem duże miasuL Typo mieszkańcy nieustannie korzystają — mniej lub bardziej świadomie — z bogatego zesifftamsług. Ten globalnie postrzegany „sektor usługowy” można potraktować jak pojedynczy /bł^uts zarabiający na udostępnianiu określonych dóbr ogółowi swych konsumentów; zde bardziej realne będzie jednak potraktowanie odrębnie każdego z usługodawców, dbając^g^-d jak najlepszą kondycję własnego przedsięwzięcia. Kompromisem godzącym oba te podejM a/jest postrzeganie naszej metropolii jako swoistej ar­ chitektury wiążącej konsumentów Łusłu^odawcami działającymi w rozproszeniu. „Architektura” to określenia'Wywołujące nieodmiennie skojarzenia technologiczne. Faktycz­ nie, „architektura zorientow4{2|^sługowo” to model, w ramach którego logika automatyzacji po­ dzielona („dekomponow^nk”) jest na odrębne jednostki logiczne. Owe jednostki, z założenia rozseparowane, podporządkowane są jednak swemu pierwowzorowi, jakim jest oryginalny problem. Wspominaliśmy już o tym, że dekompozycja złożonego problemu na podproblemy jest regułą generalną i jej przejaw na gruncie „orientacji na usługi” ma charakter wyjątkowy. W jakim sensie wyjątkowy? Lwia część tej książki poświęcona jest sformułowaniu odpowiedzi na to właśnie pytanie, więc na początek przyjrzyjmy się w zarysie najważniejszym cechom owej wyjątkowości. Jeśli w środowisku rozproszonego biznesu narzucimy na uczestników tego biznesu krępujące zależności, możemy w znaczącym stopniu ograniczyć możliwości wykorzystania potencjału każ­ dego uczestnika. A zatem, mimo iż jak najbardziej pożądana jest możliwość wzajemnego komuni­ kowania się usługodawców ze sobą i wzajemnego wymieniana między sobą rozmaitych dóbr, to nie mogą one odbywać się za cenę zbyt silnego uzależnienia od siebie uczestników biznesu. Konieczne jest pozostawienie każdemu swobody rozwoju i wzrostu, (względnie) niezależnie od innych. Mimo postulowanej niezależności poszczególnych „biznesów”, każdy z nich musi jednak sto­ sować się do pewnych uzgodnionych konwencji — na przykład sprzedawania i kupowania dóbr oraz usług za tę samą walutę, przestrzegania wymaganych standardów technicznych i społecz­ nych, czy nawet wymogu, by pracownicy kontaktowali się z klientami w ich ojczystym języku.

3 .1 . F U N D A M E N T Y S O A

47

Stwarza to — oczywiście — pewne ograniczenia, jednakże pomyślane głównie dla wygody kon­ sumentów i niestwarzające znaczących barier na drodze samorozwoju każdego z usługodawców. Zgodnie z powyższą analogią, architektura zorientowana na usługi (SOA) eksponuje istnienie każdej z usług niezależnie od pozostałych, lecz nie w zupełnej izolacji od nich. Poszczególne jed­ nostki logiczne wciąż muszą pozostawać w zgodności z pewnymi regułami, wprowadzającymi określony stopień zgodności i standaryzacji, bez jednakże krępowania niezależnego rozwoju. Na gruncie SOA wspomniane jednostki logiczne nazywane są usługam i (services).

3.1.2. Jak usługi enkapsulują logikę? Poszczególne usługi, aby zachować własną niezależność, muszą enkapsulować swą logikę w od­ rębnym kontekście. Kontekst ten może być specyficzny dla danego zadania biznesowego, pod­ miotu gospodarczego czy też innej, swoistej reguły grupowania. Zróżnicowany może być także zakres logiki realizowanej przez usługę, zależnie od specyfiki problemu, którego rozwiązaniu usługa ta jest dedykowana. Co więcej, pćttóęważ dana usługa może być „dostarczycielem logiki” dla innych usług, można połączyć kilka usW%w kolekcję, postrzeganą jako pojedynczą, złożoną usługę. bi; I tak na przykład konkretne rozwiązanie z dziedziny autom! biznesu dedykowane jest zazwyczaj konkretnemu problemowi biznesowemu; logikajcgiptolfesu przekłada się na określoną sekwencję kroków realizowanych przez wspomniane rozwlaMpie — sekwencję wynikającą z reguł biznesu i właściwości środowiska wykonawczego. Jak pokazano na rysunku 3.1, budując rozwiązaHfclldadające się z usług, powierzamy każdej usłudze zadanie wynikające z konkretnego kroksiretópu) lub ciągu kroków składających się na podproces; pojedyncza usługa może być teke%ete€lykowana kompletnemu procesowi. W dwóch ostatnich przypadkach logika reprezentowan^-przez złożoną usługę może obejmować logikę „im­ portowaną” z innych usług.

Rysunek 3.1. Usługi mogą reprezentować zróżnicowany zakres logiki

48

ROZDZIAŁ 3 . ■ W P R O W A D Z E N IE DO SOA

Aby można było wykorzystywać logikę enkapsulowaną przez usługę, usługa ta musi partycy­ pować w realizacji aktywności biznesowych. Żeby było to możliwe, konieczne jest ustanowienie wyraźnych relacji z jej użytkownikami.

3.1.3. Jak powiązane są usługi? W ramach SOA usługi mogą być wykorzystywane przez inne usługi lub programy. Muszą być w tym celu świadome nawzajem swego istnienia; świadomość ta zapewniana jest poprzez opisy usług (service descriptions).

Opis usługi B

>

Rysunek 3 .: Usługa A może komunikować się z usługą B, gdyż posiada niezbędną do tego informację \iy3oS|m9pisu usługi

B

Opis usługi, w najprostszej postaci, zawiera n a z '# ę A i|s ł u g i oraz specyfikację danych oczekiwa­ nych i zwracanych przez tę usługę. Powiązania m ig rfW w s łu g a m i, realizowane za pośrednictwem opisów, nazywane są luźnym i powiązaniam i (b tscpeduplings). W przykładzie pokazanym na ry­ sunku 3.2 usługa A jest świadoma is tn ie n ia ^ § ł« jw B /p o n ie w a ż znajduje się w posiadaniu jej opisu. Świadomość istnienia usługi to d o p ię f% p o c z ą te k . Aby usługi mogły współdziałać i generalnie przejawiać jakąś użyteczność, muszą w y k n d i i a ć między sobą informacje. Konieczny jest do tego framework k o m u n ik a c y jn y , p o z w a la ją c y !la zachowanie luźnego powiązania; takim frameworkiem jest messaging (,,k o m u n ik o w a n i;? ^

3.1.4. Jak komunikują się usługi? Gdy usługa wysyła komunikat, traci kontrolę nad tym, co dzieje się z tym komunikatem. Z tego właśnie względu komunikaty nazywane są „niezależnymi jednostkami komunikacji”; oznacza to, że komunikaty, podobnie jak usługi, są bytami autonomicznymi. Każdy komunikat musi więc być wyposażony w zasób inteligencji wystarczający do realizacji powierzonej mu roli w logice przetwarzania (patrz rysunek 3.3).

Rysunek 3.3. Komunikat istniejący jako niezależna jednostka komunikacji

3 .1 . F U N D A M E N T Y S O A

49

U sługi wyposażone w swe opisy i zdolne wymieniać informacje za pom ocą kom unikatów tworzą podstawową architekturę. Na pierwszy rzut oka wydaje się ona podobna do starszych ar­ chitektur przetwarzania rozproszonego, opartych na wymianie komunikatów oraz odseparowa­ niu interfejsu od logiki przetwarzania. Czynnikiem, który wyróżnia ją w tym kontekście, jest spo­ sób powiązania jej trzech podstawowych kom ponentów — usług, opisów i komunikatów: właśnie to powiązanie jest charakterystyczne dla orientacji na usługi (service-orientation).

3.1.5. Jak projektuje się usługi? Podobnie jak „orientacja obiektowa”, tak i „orientacja na usługi” wykształciła się jako dobrze zdefiniowane podejście projektowe, oparte na powszechnie przyjętych zasadach ustanawiających zarówno miejsce, jak i projekt kom ponentów architektonicznych (patrz rysunek 3.4).

Rysunek 3.4. Zasady^efitaiji dy gtfèpt na usługi odzwierciedlają problemy projek owe

W spom niane reguły zorientowania na usługi opisane zostaną wyczerpująco w następnych rozdziałach tej książki; w tym miejscu, niejako tytułem wstępu, wymienimy ich najważniejsze aspekty: • luźne powiązanie — usługi utrzymują między sobą powiązania na zasadzie wzajemnej świadomości swego istnienia, co sprowadza do minimum zależności między nimi; • kontraktowaść — usługi stosują się do uzgodnień w kwestii komunikacji, zdefiniowanych w opisie (opisach) i odnośnych dokumentach; • autonomia — każda usługa sprawuje pełną i wyłączną kontrolę nad logiką, którą enkapsuluje; • abstrakcyjność — usługa skrywa przed światem zewnętrznym wszystkie elementy swej logiki, które nie stanowią części kontraktu;

50

RO ZDZIA Ł 3 . ■ W P R O W A D Z E N IE DO SOA

• wieloużywalność — podział logiki biznesowej między poszczególne usługi dokonywany jest z intencją jak największej uniwersalności tych usług w znaczeniu ich wielokrotnego wykorzystywania; • komponowalność — działanie usług może być koordynowane w stopniu umożliwiającym łączenie ich w kolekcje, będące de facto usługami złożonymi; • bezstanowość — usługi sprowadzają do m inimum informację specyficzną dla swego funkcjonowania; • wykrywalność — usługi projektowane są jako wystarczająco intuicyjne, by za pomocą dostępnych mechanizmów ich wykrywania można je było odnajdywać i oceniać ich przydatność do określonego celu. Znając kom ponenty składające się na naszą podstawową architekturę oraz reguły ich projek­ towania, do kształtowania i standaryzowania brakuje już tylko jednego — platformy implementa­ cyjnej, która pozwoliłaby te zamierzenia urzeczywistnić, czyli nadać im materialny kształt rozwią­ zania zorientowanego na usługi. Taką platformę oferuje technologia usług sieciowych.

3.1.6. Jak zbudowane są usługi?

v<5

Jak już wspominaliśmy, pojęcie „zorientowania na u s łu g i i i ^ i i a i t e abstrakcyjne modele SOA istniały już przed pojawieniem się usług sieciowych. Żadi|M pdnak z dostępnych technologii nie okazała się tak przydatna i tak udana w manifestowaniu SOA jak właśnie usługi sieciowe. Wszyscy znaczący dostawcy narzędzi do tw or^srm oprogram ow ania wspierają obecnie two­ rzenie rozwiązań zorientowanych na usługi i olfsT&ga ta jest najczęściej rozumiana jako środki do tworzenia usług sieciowych. Doceniając pełni fakt, że osiągnięcie celów SOA nieko­ niecznie musi prowadzić poprzez u słu g r^ e ro w e , w tej książce skupiamy się na takiej właśnie drodze ich osiągania. .

■ 3.1.7. Pierwotna SOA W kilku ostatnich punktafthlśroi^iśmy poszczególne elementy tego, co nazywane jest pierwotną SOA (primitive SOA). Jak surabie można wnioskować, jest to pewna „linia odniesienia”, czyli zasób technologii oczekiwanych od współczesnych dostawców platform programistycznych. W szystkie postaci SOA, jakie opisywać będziemy dalej w tej książce, bazują na tym pier­ wotnym m odelu i stanow ią jego rozszerzenie. N iektóre z opisywanych rozszerzeń tej grupy stanowią w ynik zastosowania zaawansowanych technik projektowych, inne natom iast opierają się na dostępności predefiniowanych usług sieciowych i wsparciu dla nich ze strony dostawców rozwiązań. ANALIZA PRZYPADKU System finansowo-księgowy firmy RailCo jest dwuwarstwową aplikacją typu klient-serwer, przy czym zdecydowana większość logiki biznesowej zlokalizowana jest w programach zain­ stalowanych i uruchamianych na stacjach klienckich. Szczegóły tej aplikacji opiszemy w na­ stępnym rozdziale, tu ograniczymy się do dwóch jej najważniejszych zadań, którymi są:

3 .1 . F U N D A M E N T Y SOA

• wprowadzenie zamówienia klienta, • utworzenie zamówienia klienckiego. W ykonanie każdego z tych zadań obejmuje serię kroków realizujących proces biznesowy. Proces ten był modelowany za pomocą logiki standardowego przepływu pracy, a następnie zaimplementowany w postaci pakietu. Mimo iż na poziomie kodu źródłowego poszczególne aspekty procesu zostały odzwierciedlone w postaci odrębnych m odułów (podprogramów), całość została ostatecznie skompilowana do postaci pojedynczego m odułu wykonywalnego, automatyzującego w spom niany proces według ustalonej a priori aranżacji. Na gruncie modelu zorientowanego usługowo jest zgoła inaczej: logika kryjąca się za określonym procesem pow inna zostać zrealizowana w postaci zespołu usług (w szczególności — pojedynczej usługi), automatyzacja zaś całego procesu powinna zostać wykonana jako kom ­ pozycja tychże usług. Każda z usług powinna reprezentować podproces czy nawet pojedynczy jego etap i pow inna być wykonywana niezależnie od pozostałych. Przykładowo proces utwo­ rzenia zamówienia klienckiego może składać się z następujących podprocesów: • pobranie danych zamówienia, • sprawdzenie dostępności towaru, • utworzenie dokum entu zamówienia, • zapisanie dokum entu zamówienia w bazie. Jak wiemy, proces jako całość może być traktowany (i modelowany) jako usługa. Niekie­ dy kilka procesów m ożna połączyć tak, że reprezentować będą pojedynczą usługę. Przykła­ dowo procesy utworzenia dokum entu zamówienia i wygenerowania faktury dla klienta mogą zostać połączone w pojedynczy proces p rzetw arzania zam ów ienia. W reszcie, m ożem y zaprojektow ać w spom niane procesy jako na tyle elastyczne, że zdolne wykorzystywać procesy lub zasoby dostępne gdziekolwiek w przedsiębiorstw ie. Przykładowo m ożem y do procesu przetw arzania zam ów ienia dodać podproces autom atycznie wyszukujący adres e-mailowy klienta; ten podproces może także istnieć jako część większego procesu rap o r­ tow ania dla klientów. Aby zaimplementować ten model, potrzebujemy architektury technicznej zdolnej do: • podziału logiki automatyzacji biznesu na jednostki właściwie reprezentujące poszczególne usługi, • zapewnienia względnej niezależności wspom nianych jednostek logicznych, dzięki czemu spełniać będą one postulat zdolności do wielokrotnego wykorzystywania, w różnych kompozycjach, • umożliwienia wspomnianym jednostkom logicznym komunikowania się w sposób zachowujący ich niezależność. Fundam entalna charakterystyka enkapsulacji logiki w ram ach usług, luźnego powiązania i komunikowania, zrealizowana zgodnie z zasadami zorientowania na usługi i zaimplemen­ towana na bazie usług sieciowych, jest właśnie spełnieniem powyższych wymagań w ramach implementacji pierwotnej SOA.

51

52

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

PODSUMOW ANIE •

SOA i zorientow anie na usługi to oderw ane od im plem entacji paradygm aty projektow e, przeznaczone do realizacji na dow olnej, przydatnej do tego platformie.

•

M odel „pierw otnej SOA" reprezentuje zestaw odm ian SOA bazujących w yłącznie na usługach sieciowych i powszechnie przyjętych zasad zorientow ania na usługi.

•

Ilekroć dalej w tej książce użyjemy term inu SOA, będzie on odnosił się do modelu pierwotnej SOA.

3 .2 . O g ó ln ie o w s p ó łc z e s n e j SO A Pierwotny model SOA to dopiero początek. Ostatnie trendy przemysłowe i konkretne produkty nadały SOA nowe oblicze. Podstawowe zasady modelu pierwotnego zostały zachowane, jednak wiele z nich poszerzono głównie ze względu na spodziewane korzyści i — oczywiście — techniczne możliwości urzeczywistnienia abstrakcji. Znaczący dostawcy oprogram ow ania wciąż wykazują niespożytą inwencję w form ułow aniu nowych specyfikacji usług sieciowych i tworzeniu coraz większego wsparcia dla tychże usług oraz standardu XML na współczesnych platform ach technologicznych. I właśnie to ukształtowało no­ wą, rozszerzoną odmianę architektury zorientowanej na usługi — odmianę tę nazywać będziemy współczesną SOA (contemporary SOA). Współczesna SOA wyrosła więc na gruncie jej podstawowego modelu, jako efekt spożytkowania nowych możliwości technologicznych i trendów przemysłowych — na drodze do ideału, o k tó ­ rym pisaliśm y w rozdziale 1. I choć zmieniają się (i będą się zmieniać) technologie im plem en­ tacyjne, pod względem koncepcyjnym współczesną SOA m ożna uznać za ustabilizow aną — w tym sensie, że: • jest najważniejsza spośród platform zorientowanych na usługi, • przyczynia się do podwyższenia jakości usług, • jest zasadniczo autonomiczna, • bazuje na otwartych standardach, • wspiera zróżnicowanie dostawców, • wspiera naturalne współdziałanie, • propaguje wykrywalność, • propaguje federacyjność, • propaguje komponowalność architektoniczną, • sprzyja wrodzonej wieloużywalności, • eksponuje rozszerzalność, • wspiera paradygmat zorientowanego usługowo modelowania biznesu, • implementuje warstwy abstrakcji, • prom uje luźne powiązania kom ponentów infrastruktury IT, • propaguje zwinność organizacyjną, • jest budulcem,

3 .2 . O G Ó LN IE O W SPÓŁCZESNEJ SOA

53

• oznacza ewolucję, • jest modelem wciąż dojrzewającym, • jest dążeniem do ideału. Zwróćmy uwagę na fakt, iż na powyższej liście brakuje tradycyjnych wartości w rodzaju „bez­ pieczna”, „transakcyjna”, „niezawodna” itp. Ten „brak” jest jednak tylko pozorny, przymioty te są elementem „podwyższenia jakości usług”, wymienionego na drugiej pozycji. W rozdziałach 6. i 7. opiszemy szczegółowo, jak ewoluujące specyfikacje usług sieciowych ujmują typowe wymagania jakości usług (QoS — Quality o f Service), a teraz w kolejnych punktach wyjaśnimy dokładniej zna­ czenie każdej z wymienionych cech, wieńcząc opis sformułowaniem definicji współczesnej SOA.

3.2.1. Współczesna SOA jest najważniejszą spośród platform zorientowanych na usługi Zanim rozważać będziem y rzeczywiste znaczenie „współczesnej SOA”, zobaczmy najpierw, jak w kręgach przemysłu IT traktowany jest sam akronim „SOA”. Otóż w powszechnym odczuciu zdaje się on wykraczać poza obszar wyznaczany przez ostatnią jego literę — architekturę; gdy mowa o „produkcie SOA”, „projektowaniu SOA” czy „technologii SOA” można odnieść wrażenie, iż słuchamy symfonii z nowego świata — świata całkiem nowej platformy aplikacyjnej. To wyraźne odstępstwo od tradycji: dotychczas ilekroć danem u określeniu towarzyszył przed­ rostek (przyrostek) „architektura” w rozm aitych odmianach, było oczywiste, iż m amy do czynie­ nia ze stricte architektonicznym aspektem tegoż określenia. Tak było na przykład z określeniami „klient-serwer” czy „n-warstwowy” — zależnie od kontekstu mogły one odnosić się do narzędzi, infrastruktury administracyjnej czy (właśnie) architektury aplikacji. I na tę wieloaspektową modłę m ożna by równie dobrze potraktować akronim SOA, gdyby nie fakt, że organicznie tkwi już w nim konkretny — architektoniczny — aspekt. A mimo to, gdy tylko mowa o platformie opartej na usługach sieciowych i zaprojektowanej z uwzględnieniem zasad orientacji na usługi, natychmiast zaczyna wokół pobrzmiewać wielogłosowa fuga na temat „S-O-A”. Jest więc jak jest, warto jednak zastanowić się, jak być powinno — by było prawdziwie, czyli bez niepotrzebnych nieporozumień. Chyba najlepiej będzie, by (poprzedzający cokolwiek) przed­ rostek SOA oznaczał, że „to coś” stworzone zostało przy (bezpośrednim lub pośrednim) wsparciu ze strony architektury bazującej na zasadach zorientowania na usługi. Ta konwencja tyczy się tak­ że niniejszej książki: m imo iż w tytule widnieje słowo „Architektura”, jej treść wykracza jednak poza ram y czysto architektoniczne, z intencją możliwie szerokiego opisania współczesnych plat­ form zorientowanych na usługi. Ponieważ umiejscowiliśmy „współczesną SOA” jako koncepcję wyrosłą na gruncie pierwot­ nego m odelu SOA i stanowiącą jego rozszerzenie, możemy pokusić się o zaczątek naszej definicji: Współczesna SOA reprezentuje architekturę propagującą zorientowanie na usługi z wykorzystywaniem usług sieciowych.

3.2.2. Współczesna SOA przyczynia się do podwyższenia jakości usług N aturalnym wymaganiem stawianym SOA staje się zapewnienie realizacji jej elementów funkcjo­ nalnych na (co najmniej) takim poziomie bezpieczeństwa i niezawodności, jakiego gwarancję dają obecne, uznane instancje architektur rozproszonych. W ymaganie to skonkretyzować można w kategoriach typowych dla „jakości usług” (QoS — Quality o f Service), czyli między innymi:

54

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

• zdolności do realizowania zadań w sposób bezpieczny, a zatem z zapewnieniem zarówno ochrony treści komunikatów, jak i kontroli dostępu do poszczególnych zasobów; • niezawodnej komunikacji między zadaniami, a zatem gwarancji, że każdy wysłany kom unikat albo zostanie poprawnie dostarczony, albo też przypadek jego niedostarczenia skwitowany będzie stosownym powiadomieniem; • wystarczającej wydajności gwarantującej, że narzut ze strony protokołu SOAP i przetwarzania treści XML nie spowoduje pogorszenia efektywności realizowanych zadań; • transakcyjności chroniącej integralność określonych zadań biznesowych oraz gwarantującej wykonanie „awaryjnego” kodu w przypadku niepowodzenia w wykonywaniu zadania. Od współczesnej SOA oczekuje się więc wypełnienia luki w zakresie QoS, charakterystycznej dla pierwotnego m odelu SOA. Wiele koncepcji i specyfikacji omawianych w części II obejmuje elementy, które dają się odnieść bezpośrednio do wymienionych powyżej wymagań. Z braku bar­ dziej zwięzłego przym iotnika implementacje SOA czyniące zadość tym wymaganiom określać będziemy jako „zdolne do zapewnienia jakości usług” lub krócej „korzystne jakościowo” (w an­ glojęzycznej literaturze przedm iotu zaletę tę określa się jako QoS-capable).

3.2.3. Współczesna SOA jest zasadniczo autonomiczna Na mocy jednej z prezentowanych reguł zorientowania na usługi poszczególne usługi powinny być od siebie niezależne i samowystarczalne tak dalece, jak tylko to możliwe — tylko wówczas każda z usług będzie mogła sprawować wyłączną kontrolę nad enkapsulowaną przez siebie logiką. Postulat niezależności sięga jeszcze dalej: autonom ii i samowystarczalności wymaga się również od kom unikatów w ym ienianych między usługami, dzięki czemu każdy kom unikat wyposażyć m ożna w zasób inteligencji niezbędny do kontroli tego, jak kom unikat ów zostanie przetworzony przez usługę-adresata. SOA wykorzystuje i rozszerza tę zasadę, propagując koncepcję autonom ii na całość rozwiązań automatyzacji w przedsiębiorstwie. Przykładowo aplikacje zbudowane z autonom icznych usług same mogą być traktowane jak złożone, samowystarczalne usługi, realizujące swą samowystar­ czalność w zintegrowanym środowisku zorientowanym na usługi. Nieco później wyjaśnimy, jak poprzez kreowanie warstw abstrakcji usług uzyskać m ożna wy­ łączną kontrolę nad określonymi dom enami tematycznymi — i w rezultacie osiągnąć poziom autonom ii przekraczający granice poszczególnych rozwiązań.

3.2.4. Współczesna SOA bazuje na otwartych standardach Bodaj jednak najbardziej znaczącym atrybutem usług sieciowych jest fakt, że wymiana danych między usługami zorganizowana jest na bazie otwartych standardów. K om unikat wysłany przez jedną usługę do innej obsługiwany jest na bazie protokołów globalnie zestandaryzowanych i po­ wszechnie zaakceptowanych. Zestandaryzowany jest także każdy z komunikatów zarówno pod względem formatu, jak i spo­ sobu reprezentowania ładunku użytecznego. Użycie SOAP, WSDL, XML i XML Schema pozwala na zachowanie samodzielności kom unikatów i uzgodnienie wspólnych zasad komunikacji, dzięki czemu komunikujące się usługi nie muszą wiedzieć o sobie nic ponad to, co wynika z ich opisów.

3 .2 . O G Ó LN IE O W SPÓŁCZESNEJ SOA

55

W ykorzystywanie otwartego, standardow ego m odelu komunikacyjnego eliminuje konieczność współdzielenia systemu typów1 przez logikę usług i generalnie wspiera paradygmat luźnego po­ wiązania. Współczesna SOA w pełni spożytkowuje ten framework komunikacyjny, niezależny od kon­ kretnych dostawców (patrz rysunek 3.5). SOA redukuje rolę specyficznych, własnościowych tech­ nologii jedynie do implementacji i hostowania logiki aplikacyjnej enkapsulowanej przez usługę. Powoduje to, że komunikacja między usługami zawsze jest dostępną opcją.

Rysunek 3.5. Standardowe, otwarte technologie wykorzystywane są zarówno na gruncie poszczególnych rozwiązań, jak i w relacji pomiędzy nimi

3.2.5. Współczesna SOA wspiera zróżnicowanie dostawców Opisywany w poprzednim punkcie otwarty framework komunikacyjny nie tylko stwarza pomost do kom unikowania się heterogenicznych środowisk, w ram ach przedsiębiorstwa i między przed­ siębiorstwami, lecz także ułatwia wybór środowiska najlepiej dostosowanego do potrzeb konkretnej aplikacji. Przykładowo, niezależnie od tego, w jakim konkretnym środowisku programistycznym two­ rzona jest dana aplikacja, jeżeli tylko środowisko to zapewnia wsparcie dla standardowych usług sieciowych, wspomnianą aplikację m ożna wyposażyć w warstwę standardowego interfejsu, otwie­ rającego drogę do w spółdziałania z innym i aplikacjami tego rodzaju (patrz rysunek 3.6). Przy okazji nadaje to nowe oblicze architekturze integracyjnej, która teraz, za pośrednictwem odpo­ wiednich „usługowych” adapterów, enkapsulować może także starszą („spadkową”) logikę oraz spożytkowywać zalety rozmaitego oprogramowania typu middleware2.

1 Pod pojęciem „systemu typów” autor rozumie tu zapewne pewne zdefiniowane a priori zasady operow ania ty­ pam i danych, powszechne chociażby w językach trzeciej generacji (Fortranie, Algolu czy wczesnych wersjach Pascala): jeśli w eźm iem y pod uwagę na przykład przekazywanie param etrów do procedur i funkcji (podprogra­ mów), zauważymy, że w wygenerowanym przez kom pilator kodzie binarnym nie m a żadnej inform acji o typie przekazywanej wartości, jest tylko przyjęte założenie o jej typie, odzwierciedlone przez kom pilator w treści prze­ kładu. W opisywanym przypadku luźnego powiązania między usługam i jest diam etralnie inaczej — w kom uni­ kacie wym ienianym między usługam i znajduje się kom pletna inform acja na tem at przekazywanej wartości (czyli również inform acja o jej typie) i nie m a odniesienia do jakiegokolwiek predefiniowanego „zewnętrznego” sys­ tem u typów (gdyby odniesienie takie istniało, powiązanie między usługam i nie byłoby już tak luźne, bo skrępo­ wane koniecznością ich stosowania się do dom yślnych „zewnętrznych” konwencji — przyp. tłum. 2 O kreślenie m iddlew are (sk ró t o d ang. [ in ] m iddle software , dosł. oprogram ow anie p ośredn ie ) używ ane jest w dwóch znaczeniach: jako oprogram ow anie o charakterze pośrednim między wysokopoziom owym i m echani­ zm am i aplikacyjnymi a niskopoziom owym i funkcjam i systemu operacyjnego lub jako oprogram ow anie pośred­ niczące między dwom a (lub więcej) obiektami, zapewniające ich współdziałanie. W tej książce występować będzie ono głównie w tym drugim znaczeniu — przyp. tłum .

56

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

Rysunek 3.6. Różnica technologiczna między platformami zorientowanymi na usługi nie stanowi przeszkody w e współdziałaniu tych platform

Przedsiębiorstwa m ają więc możliwość korzystania w dalszym ciągu z istniejących rozwiązań, narzędzi programistycznych i zaplecza serwerowego — oczywiście, ma to sens wówczas, gdy przy­ czynia się do spożytkowania zalet tkwiących w firmowych zasobach. Równocześnie warto jednak przyglądać się ofertom nowych dostawców. Taka elastyczność jest konsekwencją przyjęcia otwar­ tych technologii, nieodłącznie związanych z frameworkiem usług sieciowych; dzięki standaryzacji i zasadom wprowadzanym przez SOA m ożna tę elastyczność osiągnąć łatwiej niż poprzednio.

3.2.6. Współczesna SOA propaguje wykrywalność Mimo iż standard UDDI pojawił się już w pierwszej generacji usług sieciowych, niewiele ówczesnych środowisk wykorzystywało rejestrowanie usług jako swój integralny element. Może dlatego, że tylko nieliczne z budowanych usług uwzględniały możliwość rejestrowania; bardziej prawdopodobną przyczyną był jednak fakt, że sama koncepcja rejestrowania usług tradycyjnie nie istniała w ówcze­ snych architekturach rozproszonych — usługi sieciowe były raczej wykorzystywane na potrzeby roz­ wiązań typu punkt-punkt i koncepcja wykrywania usługi nie wydawała się specjalnie interesująca. SOA diametralnie zmienia ten stan rzeczy, propagując ogłaszanie i wykrywanie usług, w skali całego przedsiębiorstwa i poza jego granicami. Każda niebanalna implementacja SOA wykorzystuje prawdopodobnie jakąś formę rejestru czy katalogu jako narzędzia do zarządzania opisami usług (patrz rysunek 3.7).

Rysunek 3.7. Rejestr jako mechanizm umożliwiający wykrywanie usług

3.2.7. Współczesna SOA wspiera naturalne współdziałanie N a bazie opisywanego wcześniej wymogu używania otwartych standardów, uniezależniania śro­ dowiska od konkretnych dostawców i zapewnienia wzajemnej wykrywalności usług rodzi się nowa koncepcja — naturalne współdziałanie. Niezależnie od tego, czy konkretna aplikacja charaktery­ zuje się własnymi wymogami pod względem integracji z innymi mechanizmami, zasady projek­ towania usług przemawiają za ich wyposażeniem w cechy naturalnie propagujące współdziałanie.

3 .2 . O G Ó LN IE O W SPÓŁCZESNEJ SOA

57

W aplikacji SOA tworzonej „od zera” usługi posiadające zdolność naturalnego współdziałania stają się potencjalnymi węzłami integracji (patrz rysunek 3.8). Przy właściwej standaryzacji pro­ wadzi to do architektury integracyjnej opartej na usługach, w ram ach której gotowe rozwiązania same z siebie uzyskują wrodzoną zdolność współdziałania z innym i rozwiązaniami. Przekłada się to w prostej linii na zmniejszenie kosztów i wysiłku w przyszłych zabiegach integracyjnych wyni­ kających z wymogów nowych aplikacji.

Rysunek 3.8. Usługi posiadające wrodzoną zdolność współdziałania stwarzają nieocenione możliwości w zakresie integracji

3.2.8. Współczesna SOA propaguje federacyjność Budowanie SOA wewnątrz przedsiębiorstwa nie musi oznaczać rezygnacji ze starszych, z powo­ dzeniem wykorzystywanych rozwiązań. Jedną z najbardziej atrakcyjnych cech SOA jest możliwość jednoczenia środowisk, które dotąd funkcjonowały odrębnie. Mimo iż taką federację umożliwiały już usługi sieciowe, SOA podwyższa rangę tej możliwości poprzez mechanizm enkapsulacji logiki starszych, tradycyjnych aplikacji i eksponowanie tejże logiki za pośrednictwem powszechnie uży­ wanego, otwartego i standardowego frameworku komunikacyjnego (tworzenie takich frameworków możliwe jest dzięki bogatej ofercie rozmaitych adapterów). Oczywiście, prowadzi to do powstawania rozmaitych rozwiązań hybrydowych. Najważniejsze jest jednak to, że kanały komunikacji ustanowione w drodze takiej integracji zorientowanej na usługi są w pełni standardowe i ujednolicone (patrz rysunek 3.9).

Rysunek 3.9. Usługi umożliwiają standardowe federację tradycyjnych, różniących się od siebie systemów

3.2.9. Współczesna SOA propaguje komponowalność architektoniczną Komponowalność to głęboko zakorzeniona cecha SOA, która realizować się może na różnych po­ ziomach. Przykładowo dzięki możliwości tw orzenia i rozwijania usług kom ponow alnych SOA wspomaga automatyzację elastycznych, adaptowalnych procesów biznesowych. Jak wielokrotnie

58

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

podkreślaliśmy, poszczególne usługi egzystują jako niezależne jednostki logiczne; proces bizne­ sowy może więc zostać rozbity na szereg usług, z których każda reprezentować będzie pewien lo­ giczny aspekt tego procesu. W sposób bardziej spektakularny przejawia się komponowalność na gruncie frameworku usług sieciowych drugiej generacji, który to framework wyewoluował z biegiem czasu do obecnej posta­ ci licznych specyfikacji grupy WS-*. M odularna natura tych specyfikacji pozwala na tworzenie rozwiązań SOA poprzez selektywny dobór tylko tych komponentów, które faktycznie są w danym przypadku potrzebne. Tym, co dostarcza owej elastyczności, jest fakt, że wspomniane specyfikacje usług sieciowych drugiej generacji zaprojektowane zostały z myślą o wykorzystaniu zalet modelu komunikacyjnego SOAP. Poszczególne specyfikacje składają się z m odularnych rozszerzeń oferujących specyficzne mechanizmy. Ponieważ oferta wsparcia dla wspomnianych rozszerzeń ze strony dostawców sys­ tematycznie się zwiększa, coraz większa staje się elastyczność w doborze niezbędnych kom ponen­ tów (patrz rysunek 3.10). Innym i słowy, platform y obsługujące WS-* umożliwiają tworzenie ele­ ganckich i zoptymalizowanych architektur, aplikacji, usług, a nawet komunikatów.

Rysunek 3.1 0 . Różne rozwiązania mogą być budowane jako odmienne kompozycje rozszerzeń i mogą ze sobą współdziałać, o ile zawierają wspólne komponenty niezbędne do tego współdziałania

Zgodnie z naszą definicją współczesnej SOA, odzwierciedlimy opisaną cechę poprzez opisanie całej architektury jako „kom ponow anej”. Oznacza to zarówno usługi kom ponowalne, jak i roz­ szerzenia składające się na rozszerzenia konkretnych implementacji SOA.

3.2.10. Współczesna SOA sprzyja wrodzonej wieloużywalności SOA ustanawia środowisko propagujące na wielu poziomach wielokrotne wykorzystywanie usług. Po pierwsze, usługi tworzone zgodnie z zasadami zorientowania na usługi są z natury wieloużywalne, nawet jeżeli nie jest to absolutnie konieczne, z punktu widzenia ich zastosowań. Po drugie, kolekcje usług stanowiące de facto usługi złożone, same mogą być elementami składowymi więk­ szych (super)kolekcji. Po trzecie, ta sam a usługa wchodzić może w skład części wspólnej dwóch różnych kompozycji (tak jak na rysunku 3.11).

3 .2 . O G Ó LN IE O W SPÓŁCZESNEJ SOA

59

Ta sama usługa wykorzystywana w różnych rozwiązaniach

Rysunek 3.1 1 . Przyrodzona wieloużywalność usług stwarza nieocenione możliwości w zakresie ich wielokrotnego wykorzystywania

Eksponowana przez SOA niezależność tworzonych usług od procesów biznesowych i rozwiązań automatyzacji, na potrzeby których usługi te mają być wykorzystywane, prowadzi do powstawania środowisk, w których wieloużywalność dostarczanych usług jest korzystnym efektem ubocznym. Budowanie rozwiązań zorientowanych na usługi jest więc naturalną prom ocją wbudowanej wieloużywalności.

3.2.11. Współczesna SOA eksponuje rozszerzalność Organizując wyrażanie funkcjonalności usług poprzez ich opisy, SOA skłania do postrzegania ich w sposób wykraczający poza tradycyjny schemat komunikacji punkt-punkt. Przy właściwym po­ dziale logiki problem u między usługi i umiejętnym zaprojektowaniu ich interfejsów, na odpo­ wiednim stopniu granulacji, zakres funkcjonalności oferowanej przez daną usługę można często rozszerzyć bez łam ania istniejących interfejsów (patrz rysunek 3.12).

Rysunek 3.1 2 . Rozszerzalne usługi umożliwiają wzbogacanie oferowanej funkcjonalności przy minimalnym w pływ ie na inne komponenty

Na gruncie SOA rozszerzalność obejmuje nie tylko pojedyncze usługi, ale wręcz przenika całą architekturę. Istniejące rozwiązania mogą być wzbogacane funkcjonalnie przez dodawanie nowych usług lub przez łączenie z innym i aplikacjami zorientowanymi na usługi (co ostatecznie skutkuje tym samym — dodawaniem usług). Ponieważ luźne powiązanie między usługami minimalizuje ich wzajemne zależności, ich wzbogacanie nie powoduje znaczącego zakłócenia istniejącego układu. Czas zatem powrócić do naszej początkowej definicji „współczesnej SOA” i rozszerzyć ją o kilka istotnych przymiotników:

60

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

Współczesna SOA reprezentuje otwartą, rozszerzalną, federacyjną i komponowalną architekturę propagującą zorientowanie na usługi, niezależną od konkretnych dostawców, złożoną z usług autonomicznych, współdziałających, wykrywalnych i potencjalnie wieloużywalnych, zdolną do polepszania jakości tych usług, zaimplementowanych w technologii usług sieciowych.

3.2.12. Współczesna SOA wspiera paradygmat zorientowanego usługowo modelowania biznesu Opisując m odel pierwotnej SOA, wyjaśniliśmy pokrótce, jak procesy biznesowe mogą być repre­ zentowane i wyrażane przez usługi. Partycjonowanie logiki biznesowej pomiędzy usługi, z których następnie komponować można kompletne rozwiązania, m a niebagatelne konsekwencje pod wzglę­ dem sposobu modelowania procesów biznesowych (patrz rysunek 3.13). Oczywiście, analitycy wykorzystują tę okazję — im plem entując SOA, niejako z autom atu wprowadzają wspomniane partycjonowanie do projektowania procesów biznesowych. Logika biznesowa

/ \

.

P Usługi enkapsulujące logikę biznesową

Rysunek 3.1 3 . Kolekcja (warstwa) usług enkapsulująca logikę procesu biznesowego

Innymi słowy, wszelkie modele biznesowe — zarządzania procesami (BPM — Business Process Management), podm iotów gospodarczych czy innych form inteligencji biznesowej — mogą być precyzyjnie reprezentowane w formie kompozycji skoordynowanych usług. Niestety, ten para­ dygmat projektow ania nie jest obecnie ani powszechnie przyjęty, ani też należycie zrozumiany; wyjaśnieniu jego istoty poświęcona jest więc znacząca część tej książki.

3.2.13. Współczesna SOA implementuje warstwy abstrakcji W śród zasad zorientowanego na usługi projektowania aplikacji jedna z nich m a wyraźnie ewolu­ cyjny charakter — mowa o zasadzie abstrakcyjności. Typowa instancja SOA realizuje warstwy abstrakcji, czyniąc usługi jedynymi punktam i dostępu do rozmaitych zasobów oraz logiki prze­ twarzania. Abstrakcjonizm ten może być ukierunkowany na logikę biznesową i logikę aplikacji. Przykła­ dowo, tworząc warstwę „punktów końcowych” reprezentujących kompletne rozwiązania i konkret­ ne platformy technologiczne, powodujemy całkowite ukrycie ich szczegółów (patrz rysunek 3.14). W idoczne pozostają tylko elementy funkcjonalne oferowane za pośrednictwem interfejsów usług.

3 .2 . O G Ó LN IE O W SPÓŁCZESNEJ SOA

61

Rysunek 3.1 4 . Szczegóły technologiczne realizujące logikę aplikacji mogą zostać ukryte przez dedykowaną warstwę usług

Abstrakcjonizm , w ram ach którego proces biznesowy i logika aplikacji nawzajem skrywają przed sobą swe szczegóły, jest jedną z podstawowych cech paradygmatu projektowania zoriento­ wanego na usługi, omawianego w poprzednim punkcie. Abstrakcjonizm jest także jednym z fun­ damentów luźnego powiązania między usługami.

3.2.14. Współczesna SOA promuje luźne powiązania komponentów infrastruktury IT Wyjaśnialiśmy już, że główną korzyścią wynikającą z luźnego powiązania między usługami jest za­ chowanie niezależności pomiędzy logiką każdej z nich: każdą usługę można tworzyć i rozwijać nieza­ leżnie od pozostałych, jedynym czynnikiem wiążącym usługi jest wzajemna świadomość ich istnienia. Jeśli zastosujemy tę zasadę w skali całego przedsiębiorstwa zarówno do modelowania biznesowego, jak i projektu technicznego, korzyści z luźnego powiązania stają się jeszcze bardziej spektakularne. Jeżeli zaimplementujemy zestandaryzowaną warstwę abstrakcji usług, efekt luźnego powiąza­ nia wystąpić może również między dwiema dom enam i przedsiębiorstwa — dom eną procesów biznesowych i dom eną technologii aplikacyjnych (patrz rysunek 3.15). Obie dom eny skrywają nawzajem swe szczegóły i współegzystują wyłącznie na zasadzie świadomości istnienia partnera. Dzięki tem u mogą rozwijać się względnie niezależnie od siebie — a to umożliwia wystarczająco szybkie reagowanie na nowe potrzeby biznesu i na pojawiające się wciąż nowe technologie. For­ malnie zdolność tę nazywa się zwinnością organizacyjną (organizational agility).

3.2.15. Współczesna SOA propaguje zwinność organizacyjną W ewnętrzna reorganizacja, fuzja, zm iana profilu biznesowego, wymiana użytkowanych techno­ logii — zdolność do szybkiego, „zwinnego” reagowania na te i inne (nieprzewidywalne) żywioły świata korporacji może być dla tych korporacji sprawą na miarę „być albo nie być”. Zm iany w logice biznesowej przedsiębiorstwa m ają pewien wpływ na technologię aplikacji, które tę logikę autom atyzują. I vice versa: zm iana infrastruktury technologicznej m a pewien wpływ na logikę biznesową, której automatyzacji infrastruktura ta służy. Kluczowe znaczenie ma tutaj wym iar słowa „pew ien” — im większe w spom niane uzależnienie, tym większy problem z wprowadzaniem zmian i tym większy koszt tego procesu. Wykorzystując reprezentowanie logiki biznesowej w formie usług, budując warstwę abstrakcji usług i realizując luźne powiązanie między dom eną biznesu a dom eną aplikacyjną, SOA sprowa­ dza opisaną zależność do m inim um , bo wydatnie zwiększa zwinność organizacyjną firmy (patrz rysunek 3.16).

62

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

Rysunek 3.1 5 . Dzięki implementacji warstwy usług, separującej logikę biznesową od logiki aplikacji, paradygmat luźnego powiązania zrealizowany zostaje na poziomie całego przedsiębiorstwa

Rysunek 3.1 6 . Relacja luźnego powiązania między biznesem a technologią aplikacyjną pozwala każdej z tych domen efektywniej dostosowywać się do zmian w obrębie drugiej domeny

3 .2 . O G Ó LN IE O W SPÓŁCZESNEJ SOA

63

Istotną rolę w „zwinnym” przeprowadzaniu zm ian odgrywają także dwie inne cechy SOA — otwarty framework komunikacji między architekturam i integrującymi oraz wbudowana w usługi składowe zdolność do współdziałania z innym i usługami, otwierająca możliwość współdziałania zróżnicowanych platform. Ponadto luźne powiązanie między usługami stanowiącymi „końce” kanału komunikacyjnego powoduje, że jedna z komunikujących się domen pozostaje nieświadoma zmian, jakie dokonują się wewnętrznie w ram ach drugiej. Ogólnie rzecz biorąc, zwinność organizacyjna firmy to bodaj największa z korzyści, jakie daje współczesna SOA.

3.2.16. Współczesna SOA jest budulcem Migracja firmy w stronę SOA jest procesem długotrwałym i architektura aplikacji zorientowa­ nych na usługi jest praw dopodobnie tylko jedną z kilku (wielu) platform architektonicznych w tej firmie. Jedną z kilku, ale ekspansywną: firm a, sukcesywnie transform ując swą infrastrukturę w kierunku SOA, zm ierza ku ideałowi, jakim jest przedsiębiorstwo zorientowane na usługi (SOE — Service Oriented Enterprise), w którym wszystkie procesy biznesowe realizowane są na bazie usług zarówno pod względem koncepcyjnym, jak i pod względem fizycznej implementacji. Z perspektywy SOE granice funkcjonalne SOA wyznaczają już fragment tego przyszłego ideału — fragment stanowiący bądź to wydzielony sektor biznesu, bądź też usługę enkapsulującą część lub całość logiki automatyzacji. W konsekwencji zm ian na poziomie modelu biznesowego obszar SOA może albo zostać poszerzony, albo też stać się częścią architektury integracyjnej warunkującej współdziałanie wielu aplikacji. Konkretna aplikacja zorientowana na usługi — jako całość —może więc być reprezentowana przez pojedynczą usługę i modelowana jako taka. Jak wcześniej wyjaśnialiśmy, rozmiar logiki enkapsulowanej przez usługę jest praktycznie nieograniczony: nieograniczony jest więc także po­ ziom zagnieżdżania usług — SOA może składać się z usług, które są kolekcjami usług będących kolekcjami usług, itd. W tym ujęciu dane rozwiązanie oparte na SOA może być traktowane jako pojedyncza usługa stanowiąca część SOE. Opisana właściwość wymaga rozszerzenia naszej definicji współczesnej SOA — dołączmy do niej następujące stwierdzenie: SOA zdolna jest do stworzenia abstrakcji logiki biznesowej i architektury technologicznej, przez co między tymi dwiema domenami powstaje relacja luźnego powiązania. Dzięki temu zm iany w obrębie jednej z tych domen wywołują niewielki wpływ na konieczne zm iany w drugiej. Sprzyja to płynnem u wdrażaniu zorientowania na usługi na ewolucyjnej drodze do przedsiębiorstwa zorientowanego na usługi (SOE).

3.2.17. Współczesna SOA oznacza ewolucję Architektura definiowana przez SOA kultywuje, co prawda, tradycje swych poprzedników, lecz jest od nich zasadniczo różna: od klasycznej architektury klient-serwer i obliczeń rozproszonych różni się przede wszystkim zasadami projektowymi oraz ukierunkowaniem na usługi sieciowe. Można zaryzykować stwierdzenie, że SOA, zachowując zalety platform-poprzedników, buduje na ich fundamencie nową platformę, opartą na nowatorskich wzorcach projektowych i im plem en­ towaną przy użyciu nowoczesnych technologii.

64

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

W śród w spom nianych zalet wymienić należy przede wszystkim wieloużywalność oraz party­ cjonowanie logiki aplikacji na dobrze zdefiniowane komponenty. Znalazły one swe wyraźne od­ zwierciedlenie wśród zasad zarówno pierwotnego, jak i współczesnego modelu SOA.

3.2.18. Współczesna SOA jest modelem wciąż dojrzewającym Choć opisane dotychczas właściwości m ają znaczenie fundam entalne dla współczesnej SOA, trzeba przyznać, iż w rzeczywistości stanowią raczej subiektywną konstatację stanu, w jakim SOA znajduje się obecnie. Jeśli nawet SOA m a już ustabilizowaną reputację jako bezsprzecznie przy­ szłościowa platform a dla aplikacji kom puterow ych, jej gotowość do objęcia tej zaszczytnej roli jest jeszcze problematyczna. Mimo iż usługi sieciowe z powodzeniem wykorzystywane są do im ­ plementowania funkcjonalności aplikacji, to wiele z m echanizmów niezbędnych do „poważnych” obliczeń w przedsiębiorstwach wciąż nie jest w pełni dostępnych. M ultum specyfikacji opracowanych przez organizacje standaryzacyjne, w ścisłej współpracy z dostawcami oprogramowania, formalnie reguluje kwestie wielu potrzebnych rozszerzeń; now o­ czesne narzędzia program istyczne i serwery aplikacji prezentują się obiecująco pod względem wsparcia technicznego dla nowych koncepcji. Gdy już platformy SOA i towarzyszące im narzędzia osiągną adekwatny poziom dojrzałości, wykorzystanie usług sieciowych w tworzeniu rozwiązań SOA stanie się powszechne i osiągnięcie ideału SOE stanie się perspektywą bardziej realną. Przym ierzając się zatem do sform ułow ania definicji odzwierciedlającej prawdziw y obraz „współczesnej SOA”, nie sposób nie odnieść się do stanu rozwoju niezbędnych technologii. Zwa­ żywszy jednak na tempo, w jakim ogólnie rozumiany przemysł IT przejmuje platformy SOA i do­ konuje ich doskonalenia, można mieć nadzieję, że już niedługo formułowanie tego typu zastrzeżeń stanie się niepotrzebne.

3.2.19. Współczesna SOA jest dążeniem do ideału Pełne zaadaptowanie SOA w skali całego przedsiębiorstwa to ideał, który wiele firm chciałoby osiągnąć jak najszybciej. Realia są jednak takie, iż transformacja taka wymaga nie lada wysiłku, dyscypliny i — zależnie od rozm iaru firmy — odpowiednio długiego czasu. Każde środowisko techniczne doznaje rozmaitych zmian w trakcie tego typu migracji, a różne części SOA w od­ miennym tempie przechodzą przez kolejne fazy rozwoju. Najpewniej prowadzi to do powstawa­ nia niezliczonych architektur hybrydowych, czyli stanowiących mieszankę aplikacji tradycyjnych i aplikacji zorientowanych na usługi. To wszystko zbiega się w czasie z rozwojem środków tech­ nologicznych, jakie powstają w celu wspomagania realizacji całej transformacji; od ewoluującej firmy wymaga to sukcesywnej modernizacji infrastruktury, stosownie do zmian wynikających z dojrze­ wania specyfikacji, standardów i produktów związanych z SOA. N a szczęście, znakom ita większość opisanych wcześniej cech SOA jest osiągalna już dziś. W tej książce zamieściliśmy serię tutoriali oraz opisów krok po kroku wyjaśniających, jak cechy te manifestują się w praktycznych zastosowaniach.

3.2.20. Zdefiniowanie SOA Zakończyliśmy prezentację najważniejszych cech współczesnej SOA, pora więc sformułować ostateczną jej definicję. Przypomnijmy:

3 .2 . O G Ó LN IE O W SPÓŁCZESNEJ SOA

65

SOA reprezentuje otwartą, rozszerzalną, federacyjną i komponowalną architekturę propagującą zorientowanie na usługi, niezależną od konkretnych dostawców, złożoną z usług autonomicznych, współdziałających ze sobą, wykrywalnych i potencjalnie wieloużywalnych, zdolną do polepszania jakości tych usług, zaimplementowanych w technologii usług sieciowych. SOA zdolna jest do stworzenia abstrakcji logiki biznesowej i architektury technologicznej, przez co między tymi dwiema domenami powstaje relacja luźnego powiązania. Dzięki temu zm iany w obrębie jednej z tych domen wywołują niewielki wpływ na konieczne zm iany w drugiej. Sprzyja to płynnem u wdrażaniu zorientowania na usługi, na ewolucyjnej drodze do przedsiębiorstwa zorientowanego na usługi (SOE). I uzupełnijmy: SOA stanowi wynik ewolucji starszych platform, zachowując korzystne cechy tradycyjnych architektur i łącząc je z nowatorskimi zasadami orientacji na usługi, wyznaczającymi drogę do stworzenia przedsiębiorstwa w pełni zorientowanego na usługi. SOA jest dążeniem do ideału przedsiębiorstwa zorientowanego na usługi (SOE), a osiągnięcie tego ideału wymaga zaplanowanego procesu transformacji oraz wsparcia ze strony wciąż doskonalonych technologii. Powyższa definicja współczesnej SOA, choć trafna, jest jednak wysoce szczegółowa. Dla celów praktycznych warto sformułować poniższą, bardziej ogólną wersję, stosującą się zarówno do pier­ wotnej, jak i współczesnej SOA: SOA jest form ą architektury technologicznej, osnutą wokół zasad zorientowania na usługi. Realizowana w technologii usług sieciowych stwarza potencjał dla propagowania i praktycznej realizacji wspomnianych zasad w odniesieniu zarówno do procesów biznesowych, jak i domeny automatyzacji tych procesów.

3.2.21. Podział charakterystyki Opisane charakterystyki współczesnej SOA podzielimy teraz na dwie grupy: do pierwszej zali­ czymy cechy „konkretne”, czyli realizowalne jako rzeczywiste rozszerzenia SOA, w drugiej grupie umieścimy natom iast te, które są de facto komentarzam i lub wynikami obserwacji. Jedne i drugie okazały się użyteczne w sformułowaniu formalnej definicji, jednakże odtąd interesować nas będą przede wszystkim konkrety. Usuniemy zatem z oryginalnej listy nieco górnolotne stwierdzenia, iż: • jest najważniejszą spośród platform zorientowanych na usługi, • jest budulcem, • stanowi ewolucję, • jest modelem wciąż dojrzewającym, • jest dążeniem do ideału. Ze skonkretyzowanej w ten sposób listy cech wyczytać możemy, że współczesna SOA: • bazuje na otwartych standardach, • jest komponowalna architektonicznie, • jest zdolna sprostać powszechnym wymaganiom jakości usług.

66

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

A ponadto wspiera, propaguje lub zapewnia: • zróżnicowanie dostawców, • wrodzone współdziałanie, • wykrywalność, • federacyjność, • naturalną wieloużywalność, • rozszerzalność, • zorientowane na usługi modelowanie procesów biznesowych, • warstwy abstrakcji, • luźne powiązanie w skali globalnej, • zwinność organizacyjną. Tym właśnie konkretom — gdy są właściwie rozumiane i realizowane — zawdzięczamy rze­ czywiste, mierzalne korzyści.

UWAGA M im o iż zakwalifikowaliśmy w ym ienione cechy jako jedynie „konkretną" część definicji, dalej w książce właśnie ten zestaw będziemy utożsamiać z tym , co nazywamy „charakterystyką współczesnej SOA".

PODSUMOW ANIE •

Sform ułowaliśm y definicję współczesnej SOA w kategoriach zestawu cech charakterystycznych, bazujących na zasadach i cechach pierw otnej SOA i rozszerzających je.

•

Praktyczna realizacja charakterystyki współczesnej SOA jest treścią następnych rozdziałów tej książki.

3 .3 . N a jc zę s ts ze n ie p o ro z u m ie n ia d o ty c z ą c e SO A W spom inaliśm y już o tym i w tej książce powtarzać będziem y wielokrotnie, że transform acja (ta prawdziwa) w kierunku SOA to przede wszystkim zm iana sposobu myślenia. A jeśli tak, to również okazja do wielu mitów, nieporozum ień, przesądów — te wybrane, które tu krótko opi­ szemy (i postaram y się zobiektywizować), to jedynie wierzchołek góry lodowej.

3.3.1. „Aplikacja korzystająca z usług sieciowych jest aplikacją zorientowaną na usługi" Ten m it m a swe źródło w nie do końca precyzyjnej definicji SOA. Bo przecież SOA jako abstrak­ cyjny model to coś innego niż SOA bazująca na usługach sieciowych i zorientowaniu na usługi. Zależnie od tego, jaki model abstrakcyjny przyjmie się za punkt odniesienia, każdą niemal postać architektury rozproszonej m ożna zaklasyfikować jako „zorientowaną na usługi”. Jeżeli jednak transformacja w stronę SOA m a stać się źródłem tych wszystkich korzyści, które opisywaliśmy w poprzednich punktach, musi opierać się na standaryzacji i umiejscowieniu usług sieciowych zgodnie z zasadami orientacji na usługi.

3 .3 . NAJCZĘSTSZE N IE P O R O Z U M IE N IA DOTYCZĄCE SOA

67

Naprawdę więc to, czy tytułowe zdanie jest tylko mitem, czy może zawiera jednak ziarno prawdy, zależy przede wszystkim od oczekiwań: możemy traktować tradycyjną architekturę rozproszoną jako „zorientowaną na usługi”, jeżeli nie spodziewamy się po niej korzyści, które dać może pier­ w otna i współczesna SOA.

3.3.2. „SOA to nowe hasło marketingowe dla starych usług sieciowych" Term in „SOA”, jako bezsprzecznie chwytliwy, używany jest często (i nadużywany) do celów m ar­ ketingowych — zawsze wtedy, ilekroć pojawia się kontekst usług sieciowych. Fakt, że współczesna SOA im plem entowana jest właśnie przy użyciu usług sieciowych, jest powodem pewnego scepty­ cyzmu dotyczącego rangi samego akronim u SOA: dla wielu hasło „wsparcie dla SOA” to tylko nowa etykietka tego, co naprawdę jest „wsparciem dla usług sieciowych”. SOA nie jest jednak wynalazkiem medialnej reklamy czy speców od marketingu. Jest to peł­ nopraw ny technicznie term in, o niekwestionowanej reputacji, odnoszący się do specyficznej ar­ chitektury, opartej na dobrze określonych, fundam entalnych założeniach; to także wykorzysty­ wanie ściśle określonych technologii do realizacji tychże założeń. Technologią z wyboru w tej grupie są właśnie usługi sieciowe, stąd całe nieporozumienie.

3.3.3. „SOA to nowa etykietka dla przetwarzania rozproszonego opartego na usługach sieciowych" Powszechna wiara w ten m it to nic innego jak syndrom „fałszywej SOA” opisywany w rozdziale 1. I trudno się dziwić: wiele wrzawy wokół SOA przyćmiło jej rzeczywiste znaczenie, a wielu do­ stawców opatruje etykietką „wsparcie dla SOA” zwyczajną mieszankę tradycyjnych obliczeń roz­ proszonych z usługami sieciowymi. I już łatwo o nieporozumienie, a sama reputacja term inu „SOA” zostaje poważnie nadszarpnięta. SOA jest jednak tworem samym w sobie. Owszem, jej zasady pozostają w wyraźnej relacji do niegdysiejszych platform obliczeń rozproszonych, lecz jednocześnie definiują wyraźny kontrast w po­ równaniu z tymi platformami. Szczegółami tego porównania zajmiemy się w następnym rozdziale.

3.3.4. „SOA upraszcza przetwarzanie rozproszone" Same zasady tworzące fundam ent SOA są z natury nieskomplikowane. Często jednak to, o czym łatwo się mówi, znacznie trudniej zrealizować w praktyce: wcielenie wspomnianych zasad w życie może być napraw dę trudnym zadaniem. Owszem, spodziewane korzyści to gra w arta świeczki; wygrana w tej grze uwarunkowana jest jednak przeprowadzeniem dogłębnej analizy i dochowa­ niem wierności zasadom projektowania zorientowanego na usługi. Typowa im plem entacja SOA wymaga n a ogół bardziej szczegółowych badań i poszukiwań, w porów naniu ze starszymi paradygm atam i platform obliczeniowych. W dużej części to konse­ kwencja bogactwa technologii usług sieciowych, stanowiących podstawę implementacyjną współ­ czesnej SOA. Tak, oczywiście, w końcowym rozrachunku SOA spowoduje uproszczenie przetwarzania roz­ proszonego; stanie się to wówczas, gdy standaryzacja zorientow ana na usługi na dobre zagości w środowisku IT, czyli gdy zaistnieje wystarczający zestaw komponowalnych usług, a zasady zo­ rientowania na usługi zostaną w pełni zintegrowane ze wspomnianym środowiskiem.

68

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

3.3.5. „Aplikacja z usługami sieciowymi, wykorzystująca rozszerzenia WS-*, jest aplikacją zorientowaną na usługi" Podczas gdy druga generacja specyfikacji usług sieciowych predestynuje SOA do roli pierwszego skrzypka w orkiestrze infrastruktury IT, to odwrotna relacja niekoniecznie jest prawdziwa — proste uczynienie tych specyfikacji częścią architektury nie sprawi, że ta architektura stanie się zorientowa­ na na usługi. Niezależnie od bogactwa samych usług sieciowych, tym, co czyni te usługi częścią ar­ chitektury zorientowanej na usługi, jest sposób zaprojektowania tejże architektury samej z siebie. Z drugiej strony, można jednak żywić nadzieję, że większość rozwiązań poważnie podchodzących do wykorzystania rozszerzeń WS-* to rozwiązania faktycznie zorientowane na usługi. Przesłanką tej nadziei jest prawdopodobieństwo, iż tempo upowszechniania SOA jest z grubsza zbieżne z coraz więk­ szym wsparciem dla rozszerzeń WS-* w środowiskach programistycznych i produktach middleware.

3.3.6. „Jeśli znasz usługi sieciowe, bez problemu zbudujesz SOA" Znajomość tematyki usług sieciowych pod kątem koncepcyjnym i technicznym jest niewątpliwie nieodzow na dla projektantów , jednakże — jak wspom inaliśm y na początku tego rozdziału — fundam entalne zasady zorientowania na usługi pozostają bez związku z konkretną technologią. Zorientowanie na usługi koncentruje się raczej na odpowiednim postrzeganiu i partycjonowaniu logiki biznesowej i logiki aplikacji, a w stosunku do usług sieciowych — na wymaganiu, by były projektowane i wykorzystywane zgodnie z fundamentalnymi zasadami. Usługi sieciowe mogą być z łatwością włączane do istniejących tradycyjnych architektur roz­ proszonych, w których bądź to zajmą centralne miejsce i obarczone zostaną odpowiedzialnością za krytyczną część przetwarzania, bądź też staną się punktam i dostępu do peryferyjnych aplikacji. SOA wykorzystuje usługi sieciowe w znacząco inny sposób. Nacisk położony na enkapsulację logiki biznesowej i tworzenie warstwy abstrakcji usług wymaga zwykle doświadczenia zarówno w zakresie technologii, jak i analityki biznesowej. Można więc śmiało przyjąć, że realizacja współcze­ snej SOA wymaga umiejętności wykraczających daleko poza li tylko technologię usług sieciowych.

3.3.7. „Gdy przejdziesz na SOA, wszystko zacznie współdziałać" Do upowszechnienia tego m itu walnie przyczynił się szum medialny i agresywna reklama. Wielu m niema, że z racji samego zbudowania rozwiązań zorientowanych na usługi infrastruktura tech­ niczna magicznym sposobem sama przekształci się w ujednoliconą, sfederowaną architekturę. Owszem, może się tak stać, lecz tylko za sprawą inwestycji, analiz, no i przede wszystkim wy­ sokiego stopnia standaryzacji. Wykorzystanie frameworku komunikacyjnego usług sieciowych i ar­ chitektury zorientowanej na usługi (i różnych architektur integracyjnych zorientowanych na usługi) pozwala na abstrahowanie i skrywanie szczegółów konkretnego rozwiązania, jego platformy i zasto­ sowanej technologii. Tak właśnie tworzy się przewidywalne m edium komunikacyjne dla wszystkich aplikacji wyeks­ ponowanych za pośrednictwem usług sieciowych. Niestety, nie oznacza to automatycznie standary­ zacji informacji wymienianej za pomocą tego medium. Gdy więc SOA stanie się bardziej powszech­ na, będzie m ożna spotkać jej znakomite implementacje oraz implementacje zdecydowanie mniej udane. W arunkiem prawdziwie udanego współdziałania, federacyjności, wieloużywalności i innych jeszcze korzyści jest poddanie każdej z usług składowych wspólnym standardom projektowym.

3 .4 . NA JW AŻNIEJSZE W Y M IE R N E POŻYTKI Z SOA

69

PODSUMOW ANIE •

Większość nieporozumień dotyczących znaczenia SOA wynika z polityki m arketingow ej i nieobiektywnej reklamy medialnej.

•

Często usługi sieciowe działające w rozproszonej architekturze internetow ej m ylone są z praw dziw ą, współczesną SOA.

•

Najbardziej zdradliw ym m item jest postrzeganie rozwiązań zorientowanych na usługi jako prostych z natury, łatwych w tw orzeniu i autom atycznie zapewniających w spółdziałanie.

3 .4 . N a jw a ż n ie js z e w y m ie rn e p o ż y tk i z SO A Dotychczas zajmowaliśmy się kom ponentam i tworzącymi SOA i tematykę tę będziemy szczegó­ łowo rozwijać dalej w tej książce, zajmując się wewnętrznymi szczegółami funkcjonowania roz­ wiązań zorientowanych na usługi. Nie m ożna jednak nie zadać sobie oczywistego pytania — po co to wszystko? Z jakich to powodów gremia informatyków zadają sobie trud tak znaczącej m e­ tam orfozy zarówno filozofii, jak i technologii, by zaadaptować SOA na gruncie dotychczasowej infrastruktury, jako docelowy następnik tejże? Skupimy się w tym miejscu na uchwytnych, wymiernych zyskach ze wspomnianej inwestycji, związanych głównie z: • usprawnieniami, jakie SOA zdolna jest wprowadzać do konstruowania rozwiązań automatyzujących biznes, • korzyściami, jakie dla globalnie postrzeganego przedsiębiorstwa niesie proliferacja orientacji na usługi.

UWAGA Korzyści, jakie odnosić może firma dzięki SOA, mogą być wielorakie i rozmaite, zależnie od wytyczonych celów oraz sposobu, w jaki w drażane są kom ponenty SOA, w raz z całą arm ią produktów powiązanych. Przedsta­ wiana w tym miejscu lista ma charakter raczej ogólny i jako taka daleka jest — oczywiście — od kompletności, stanow i jedynie pewien w yznacznik potencjału, jaki kryją w sobie platformy architektoniczne SOA.

3.4.1. Usprawniona integracja (i naturalne współdziałanie) SOA umożliwia tworzenie rozwiązań składających się z usług naturalnie współdziałających ze sobą. Wykorzystywanie rozwiązań bazujących na współdziałających usługach jest częścią integrowania zorientowanego na usługi (SOI — Service-Oriented Integration), prowadzącego do stworzenia architektury integracyjnej zorientowanej na usługi. Dzięki niezależności frameworku komunikacyjnego od konkretnych dostawców — niezależności wynikającej z zasad SOA implementowanej przez usługi sieciowe — możliwe jest implementowanie wysoce zestandaryzowanych opisów usług i struktur komunikatów. W rezultacie otrzymujemy natu­ ralne współdziałanie platform, a wtedy projektanci mogą skupić się raczej na modelowaniu procesów biznesowych niż konstruowaniu specyficznych pomostów komunikacyjnych między aplikacjami. Zatem koszt i wysiłek integracji międzyaplikacyjnej stają się znacząco mniejsze, gdy integracja ta zgodna jest z zasadami SOA.

70

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

3.4.2. Wbudowana wieloużywalność Orientacja na usługi propaguje projektowanie usług w sposób zapewniający ich wieloużywalność. Projektowanie w ten sposób otwiera prostą drogę do lepszego wykorzystywania istniejących im ­ plementacji logiki automatyzacyjnej. Tworzenie rozwiązań składających się z usług, które, oprócz wymagań na szczeblu aplikacji, m ogą być również wykorzystywane przez potencjalnych przyszłych wnioskodawców, zwiększa efektywność projektowania i implementowania, bo raz zainwestowany wysiłek może być wyko­ rzystywany wielokrotnie. Zatem, mimo umiarkowanie większego wysiłku koniecznego do zapewnienia wieloużywalności, zyskujemy znacząco większy stopień spożytkowania owoców tego wysiłku.

3.4.3. Eleganckie architektury i rozwiązania Jedną z fundam entalnych koncepcji SOA jest komponowalność. W brew pozorom, koncepcja ta wykracza daleko poza proste agregowanie usług w ram ach kolekcji. Cała platforma WS-* zbudo­ wana jest całkowicie na bazie komponowalności. Jak pisaliśmy już w punkcie 3.2.9, ten aspekt architektury zorientowanej na usługi może pro­ wadzić do powstawania wysoce zoptymalizowanych środowisk automatyzacyjnych, zawierających wyłącznie kom ponenty faktycznie niezbędne. Zatem osiągnięcie opisanej optymalizacji wymaga zgodności ze standardam i projektowymi, rządzącymi dozwolonymi rozszerzeniami w każdym środowisku aplikacyjnym. Ograniczenie wy­ korzystywanych rozszerzeń do niezbędnego zestawu przyczynia się do zredukowania zarówno wysiłku projektantów, jak i zakresu ich niezbędnych kwalifikacji (bo te ograniczają się do wiedzy związanej z konkretną aplikacją, usługą lub rozszerzeniem), przyczynia się również do poprawy ogólnej wydajności.

UWAGA W spom niana powyżej poprawa wydajności odnosi się wyłącznie do eliminacji realizowania zbędnych roz­ szerzeń (nieobecnych w zoptym alizow anej im plem entacji), bo w ym iana danych oparta na komunikatach SOA charakteryzuje się w iększym obciążeniem przetw arzania w porównaniu ze zdalnym w yw oływ aniem procedur (RPC — Remote Procedure Ca/J) stosowanym w tradycyjnych architekturach rozproszonych. (O zagadnieniu wydajności na platformach SOA piszemy w punkcie 3.5.5 ).

3.4.4. Spożytkowanie dawnych inwestycji Upowszechnienie się technologii usług sieciowych w przemyśle informatycznym stało się motorem napędowym na rynku różnorodnych adapterów, umożliwiających dostosowywanie wielu star­ szych aplikacji do uczestnictwa w architekturach integracyjnych zorientowanych na usługi. Tra­ dycyjne środowiska, działające dotychczas w izolacji od siebie, mogą stawać się dzięki tem u kom ­ ponentam i wspólnej architektury, zapewniającej w jednolity sposób współdziałanie i uwalniającej od konieczności opracowywania kosztownych i często niepewnych kanałów integracyjnych typu punkt-punkt. I nawet m im o faktu, że wspomniane adaptery nie rozwiązują wielu istotnych pro­ blem ów — jak chociażby problem sprostania przez tradycyjną aplikację znacznie większemu

3 .4 . NA JW AŻNIEJSZE W Y M IE R N E POŻYTKI Z SOA

71

strum ieniow i danych w porów naniu z tym, dla którego została oryginalnie zaprojektowana — to i tak czerpanie wciąż korzyści ze starszych rozwiązań w nowych warunkach orientacji na usługi jest samo z siebie perspektywą na wskroś atrakcyjną. Zatem koszt i wysiłek integracji starszych rozwiązań z nowymi stają się znacznie mniejsze, a konieczność rezygnacji ze starszych aplikacji — znacznie mniej praw dopodobna.

3.4.5. Jednolite reprezentowanie danych w standardzie XML Język XML to jeden z fundam entów SOA, więc transformacja w stronę SOA stanowi doskonałą okazję do wykorzystania wszelkich zalet reprezentacji danych w tym standardzie. Zestandaryzowany form at reprezentacji danych — gdy zostanie opracowany i pomyślnie wdrożony — oznacza na ogół zmniejszenie złożoności całego środowiska aplikacyjnego. Oto szczegóły. • Dokum enty w formie języka XML (i towarzyszące im schematy) upakowane w kom unikatach SOAP, wymienianych między aplikacjami lub ich komponentami, powodują ujednolicenie form atu wymienianych danych, co umożliwia budowanie przewidywalnych, a w konsekwencji łatwo rozszerzalnych i adaptowalnych sieci komunikacyjnych. • Samoopisująca natura języka XML ułatwia interpretowanie zakodowanych w tym języku danych przez architektów, analityków i deweloperów. Dzięki tem u dane przenoszone przez kom unikaty stają się prostsze koncepcyjnie, bardziej zrozumiałe i łatwiejsze w śledzeniu. • Standaryzacja formy wymienianych danych stwarza grunt dla wewnętrznego współdziałania. Przykładowo wykorzystywanie wspólnych słowników powoduje redukcję konieczności niwelowania różnic w interpretowaniu korporacyjnych modeli danych przez różne aplikacje. Adaptacja starszych platform do standardu XML wykonywana była z reguły wybiórczo, sto­ sownie do bieżących potrzeb. Jej korzyści dla organizacji były więc mocno ograniczone w stosunku do tych, jakie potencjalnie przynieść mogłoby systematyczne przejście na XML. Ze względu na fun­ damentalne znaczenie XML dla współczesnej SOA, taka systematyczna adaptacja jest nie opcją, lecz koniecznością — i jednocześnie okazją do standaryzacji w znacznie szerszym zakresie. Zatem proliferacja standardowej reprezentacji danych w języku XML przyczynia się do re­ dukcji kosztów i wysiłków związanych z tworzeniem aplikacji.

UWAGA Korzyści w spom niane w dwóch ostatnich akapitach (integrowanie starszych aplikacji i reprezentowanie danych w języku XM L) opisyw ane są obszerniej w książce Service-O riented A rchitecture: A F ie ld Guide to in te g ra tin g

XM L a n d Web Services.

3.4.6. Skoncentrowane inwestowanie w infrastrukturę komunikacyjną Ponieważ usługi sieciowe ustanawiają wspólny fram ew ork komunikacyjny, komunikacje wewnątrzaplikacyjna i międzyaplikacyjna stają się centralnym elementem standardowej infrastruk­ tury IT. Ujednolicenie tej komunikacji oznacza, że przeznaczone na nią inwestycje można skon­ centrować na pojedynczej technologii.

72

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

Zatem ograniczenie się do pojedynczej technologii realizującej komunikację w ramach sfederowanej części infrastruktury IT przedsiębiorstwa oznacza redukcję kosztów skalowania tej komunikacji.

3.4.7. Wybór najlepszego wariantu Częstą przyczyną ataków, jakich obiektem staje się dział IT firmy, są ograniczenia określonej plat­ formy technologicznej w zakresie możliwości realizacji wymagań dotyczących automatyzacji biz­ nesu w tejże firmie. Ograniczenia te mogą wynikać z niedopuszczalnie wysokich kosztów przed­ sięwzięcia, lecz równie dobrze m ogą być pochodną w rodzonych ograniczeń samej technologii. W efekcie dział IT zmuszony zostaje do moderowania swych planów w zakresie poszerzania lub wymiany istniejących rozwiązań, a często nawet do rezygnacji z tych planów. Oczywiście, SOA nie stanowi panaceum na problemy tego rodzaju, ale może je wydatnie ła­ godzić za sprawą jednej ze swych fundam entalnych cech — niezależności od konkretnej techno­ logii. Jedynym żądaniem pod adresem określonego „kawałka” automatyzacji jest wyeksponowanie adekwatnego interfejsu usługi; poszukując technologii do realizacji tejże usługi, jesteśmy unieza­ leżnieni od konkretnej platformy czy oprogram owania middleware i m am y swobodę wyboru tej, która najlepiej odpowiada określonym potrzebom i możliwościom. Zatem niezależność technologiczna zwiększa możliwości w zakresie automatyzacji biznesu oraz generalnie oznacza lepszą jakość tworzonych rozwiązań.

3.4.8. Zwinność organizacyjna „Zwinność” to cecha, którą odnosić m ożna niem al do wszystkiego: zwykły algorytm, kom ponent oprogramowania, rozwiązanie, platforma, proces — miarą zwinności każdego z tych elementów jest sposób jego skonstruow ania, umiejscowienia i użyteczności. To, jak całość tych elementów wpisuje się w ogół finansowych i kulturowych uwarunkowań firmy i jak dzięki tym elementom usprawniona zostaje realizacja procesów biznesowych, stanowi miarę zwinności firmy jako całości. Znakomita większość rozwiązań zorientowanych na usługi konstruowana jest ze świadomością faktu, iż to, co zostało dzisiaj zbudowane, z biegiem czasu będzie musiało być ewolucyjnie dosto­ sowywane do nieuchronnych zmian w biznesie. Jednym z pożytków, jakie daje dobrze zaprojek­ tow ana SOA, jest właśnie złagodzenie związanych z tym uciążliwości. Jeśli zdolność reagowania na zmiany staje się norm ą w projektowaniu rozwiązania rozproszonego, zalety, takie jak wieloużywalność i współdziałanie, stają się czymś naturalnym. Przewidywalność, jaką niosą ze sobą te cechy, zapewnia należyty poziom zwinności organizacyjnej. Wszystko to m ożna jednak osiągnąć tylko pod warunkiem właściwego projektowania i standaryzacji. W mało elastycznych środowiskach IT zmiany są prawdziwą plagą: mogą być destrukcyjne, kosztowne i generalnie niebezpieczne. Zdolność antycypowania zmian przez tworzone rozwiązania automatyzacyjne (wraz ze wspomagającą infrastrukturą) jest więc zaletą trudną do przecenienia. Zestandaryzowane środowisko składające się z luźno powiązanych, komponowalnych, współdzia­ łających i potencjalnie wieloużywalnych usług niezaprzeczalnie zdolność taką posiada. Co więcej, poprzez tworzenie specjalizowanych warstw usług, abstrahujących logikę biznesową i technologię implementacyjną, SOA ustanawia luźne powiązanie między tymi dwiema domenami. Każda z nich może więc rozwijać się względnie niezależnie i elastycznie reagować na zmiany wy­ muszane przez drugą domenę. A to w znaczącym stopniu przyczynia się do zwinności organiza­ cyjnej, niezależnie od tego, jak intensywnych zmian wymagać będą nowe uwarunkowania.

3 .5 . NA JW AŻNIEJSZE PUŁAPKI W ADA PTA C JI SOA

73

Zatem SOA przyczynia się do redukcji kosztu i wysiłku związanego z adaptacją infrastruktury IT do zmian zachodzących w procesach biznesowych lub technologiach implementacyjnych. PODSUMOW ANIE •

Inw estow anie w SOA może przynosić w ym ierne zyski w yrażające się w konkretnych kategoriach.

•

W iele długofalowych korzyści obiecywanych przez SOA uwidacznia się dopiero w ów czas, gdy zasady orientow ania na usługi zostaną w drożone w skali całego przedsiębiorstwa.

•

Na szczęście, SOA um ożliwia także osiągnięcie w ielu korzyści o charakterze doraźnym.

3 .5 . N a jw a ż n ie js z e p u ła p k i w a d a p ta c ji SO A Skoro omówiliśmy potencjalne korzyści płynące ze współczesnej SOA, czyli to, co „ewentualnie może być”, pomyślmy teraz kategoriami „jak jest napraw dę”, czyli przyjrzyjmy się realiom. Generalnie każdy projekt, architektura, aplikacja itd. może być produktem różnej jakości i SOA nie jest w tym względzie wyjątkiem. Zważywszy na niebanalny rozm iar działań (również ich wymiar czasowy) koniecznych do pełnego zaadaptowania SOA w przedsiębiorstwie, a przede wszystkim na fakt, że transform acja taka wymaga zmiany sposobu myślenia na tem at automaty­ zacji biznesu, można żywić obawy, iż transformacja ta nie zawsze przebiegać będzie we właściwym kierunku. I rzeczywiście; poniżej przedstawiany krótkie omówienie kilku wybranych, najczęściej popełnianych błędów tego rodzaju.

3.5.1. Budowanie architektury zorientowanej na usługi na wzór architektury tradycyjnej Prawdopodobnie błędem num er jeden w dążeniu do celów spodziewanych po SOA jest budow a­ nie lub rozbudowywanie tradycyjnej architektury rozproszonej w przekonaniu, że oto buduje się współczesną SOA. To złudne przekonanie jest najczęściej wynikiem przyjęcia któregoś z błędnych założeń, o których dopiero co pisaliśmy. Niby nic wielkiego, wszyscy popełniam y błędy; niebezpieczeństwo kryjące się za tym błędem jest jednak na tyle poważne, że firma może zabrnąć dość daleko w ślepą uliczkę (ze wszystkimi, nie tylko finansowymi, tego konsekwencjami), zanim zorientuje się, że podąża w ewidentnie złym kie­ runku i trzeba zawracać. Oto kilka typowych praktyk, które mogą zwiastować opisane nieszczęście. • Konstruowanie opisów usług w stylu typowym dla RPC, z konsekwencją w postaci zbyt intensywnej wymiany „drobnoziarnistych” komunikatów. • Unikanie wykorzystywania cech oferowanych przez specyfikacje WS-*. • Niewłaściwe partycjonowanie elementów funkcjonalnych pomiędzy usługi. • Tworzenie usług niekom ponowalnych (lub komponowalnych połowicznie). • Uporczywe trzymanie się wzorców komunikacji synchronicznej. • Tworzenie usług hybrydowych lub niestandardowych. Kluczem do unikania opisanych sytuacji jest zrozumienie fundamentalnych różnic między SOA a wcześniejszymi architekturami (tematyce tej poświęcona jest część rozdziału 4.).

74

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

3.5.2. Brak standaryzacji W większych firmach, w których realizuje się równolegle kilka projektów, zdefiniowanie odpo­ wiednich standardów jest zadaniem pierwszorzędnym. Integracja (w przyszłości) aplikacji utwo­ rzonych w ram ach dwóch różnych projektów, rządzących się odm iennym i standardam i, będzie prawdopodobnie bardzo trudna, kosztowna, a jej rezultat wątpliwy. Lekcję tę przerabiało już wiele działów IT, stających przed zadaniem integrowania „spadkowych” aplikacji. SOA umożliwia federowanie zróżnicowanych środowisk — to jedna z jej fundamentalnych zasad — lecz nie dokona się ono „z autom atu”, za sprawą zakupienia jedynie najnowszych aktu­ alizacji narzędzi deweloperskich czy oprogram owania serwerowego. SOA, podobnie zresztą jak wiele innych architektur, ujawnia swój potencjał dopiero w połączeniu z opracowaniem i w dro­ żeniem odpowiedniej standaryzacji (pisaliśmy już o tym w punkcie 3.3.7). Realizowanie projektu rozwiązania zorientowanego na usługi w oderwaniu od innych pro­ jektów i aplikacji może doprowadzić do sytuacji, w której próba integrowania tegoż rozwiązania z innym i, działającym i w tej samej firm ie, przysporzy wiele dotkliw ych problem ów , z których najbardziej dotkliwe to: • niekompatybilność w reprezentacji danych — ten sam typ informacji reprezentowany będzie według różnych schematów; • nieregularna struktura i zróżnicowanie semantyki opisów usług; • niespójność implementacyjna, czyli wykorzystywanie (do realizacji tego samego zadania) różnych rozszerzeń lub rozszerzeń im plem entowanych w odm ienny sposób. SOA w n aturalny sposób propaguje oddzielenie interfejsu od im plem entacji, czyli ukrycie szczegółów funkcjonowania zaplecza. Nie zmienia to konieczności standaryzacji projektu i inte­ rakcji usług kolektywnie realizujących logikę tego zaplecza. Różne standardy projektowe, takie jak podejście „najpierw WSDL” omawiane w częściach IV i V tej książki, stworzone zostały z myślą o osiągnięciu wielu kluczowych korzyści oferowanych potencjalnie przez SOA.

3.5.3. Brak planu transformacji Szanse na udaną migrację w stronę SOA stają się znacząco mniejsze, gdy migracja ta nie jest reali­ zowana według jasnego, zrozum iałego planu. Ponieważ sposób umiejscowienia usług w infra­ strukturze IT może oznaczać kompletną redefinicję tejże struktury, reperkusje źle przeprowadzonej migracji mogą być dla firmy katastrofalne. W spom niany plan umożliwia skoordynowanie poszczególnych faz migracji, przeprowadzanej równolegle na trzech poziomach — technologicznym, architektonicznym i organizacyjnym. Szczegółowa treść takiego planu jest specyficzna dla konkretnej firmy, choć — ogólnie rzecz biorąc — pow inna zawsze zawierać pewne kluczowe elementy, między innymi: • analizę przewidywanego wpływu przeprowadzanej transformacji na istniejące zasoby, procesy, wewnętrzne standardy i technologie; • definicję architektury transformacyjnej, w ram ach której środowiska przewidziane do transform acji ewoluują poprzez serię zaplanowanych, hybrydowych etapów;

3 .5 . NA JW AŻNIEJSZE PUŁAPKI W ADA PTA C JI SOA

75

• spekulatywną analizę możliwości wykorzystania przyszłego rozwoju usług sieciowych i technologii wspierających te usługi; • wykaz szczegółowych zmian w scentralizowanej logice (związanych na przykład z nowym modelem bezpieczeństwa). Opracowanie (i przestrzeganie) planu transformacji pozwala uniknąć wielu nieprzyjemnych niespodzianek, jakie m ogą przytrafić się w konsekwencji doraźnych zabiegów, wykonywanych w ram ach transformacji ad hoc. Jak wspominaliśmy, szczegółowa postać planu transformacji jest specyficzna dla konkretnej firmy — dla jej oczekiwań, ograniczeń i celów.

3.5.4. Początki bez XML W świecie współczesnej SOA wszystko zaczyna się od usług sieciowych — to zdanie, powtarzane niby m antra, jest jednak tylko połowicznie prawdziwe. W świecie współczesnego SOA wszystko faktycznie bierze swój początek od standardu XML. Na bazie tego standardu zdefiniowano wiele standardów pochodnych, składających się na architekturę de facto reprezentowania danych. W ła­ śnie te standardy napędzały tworzenie wielu specyfikacji usług sieciowych — specyfikacji stano­ wiących m otor napędowy współczesnej SOA. Obecnie tak wiele uwagi poświęca się transferowi danych między usługami, że praktycznie zaniedbywana jest kwestia strukturalizacji i walidacji tych danych przez komunikujące się usługi. Może to odbijać się negatywnie na jakości (wydajności) przetwarzania danych: przykładowo te same dane m ogą być wielokrotnie poddaw ane walidacji według tych samych kryteriów bądź też te same dane mogą być niepotrzebnie przetwarzane dwukrotnie — przed wysłaniem przez jedną usługę i po odebraniu ich przez drugą. I to wszystko niejako przypadkowo, bez wyraźnych inten­ cji projektantów i programistów. Standaryzacja sposobu, w jaki kluczowe technologie XML wykorzystywane są do reprezento­ wania, walidacji i przetw arzania danych korporacyjnych przesyłanych w środow isku aplikacji (zarówno wewnątrz usług, jak i między nim i), jest w arunkiem niezbędnym do skonstruow ania solidnej, zoptymalizowanej i interoperacyjnej SOA.

3.5.5. Ignorowanie wymagań wydajnościowych SOA W niewielkiej skali łatwo tworzyć rozwiązania zorientowane usługowo, prawidłowo funkcjonujące i dobrze reagujące na kom unikaty z otoczenia. Gdy rozrasta się środowisko i dodawana jest nowa funkcjonalność, w konsekwencji rośnie natężenie wymiany komunikatów. W nieprzygotowanych na to aplikacjach obserwuje się wówczas drastyczne spowolnienie przetwarzania danych. Ponieważ współczesna SOA opiera się na tworzeniu abstrakcji przetwarzania danych, pojawia się problem dodatkowego obciążenia narzucanego przez te warstwy. Uzależnienie współczesnej SOA od usług sieciowych pogłębia jej zależność od reprezentacji danych w języku XML, co w naturalny sposób zwiększa wymagania dotyczące przetwarzania tej reprezentacji. Przykładowo mechanizmy bezpieczeństwa usług sieciowych — między innym i szyfrowanie i podpisy cyfrowe — skutkują pojawieniem się nowych warstw przetwarzania, po stronie zarówno nadawców, jak i odbiorców komunikatów.

76

RO ZD ZIAŁ 3 . ■ W P R O W A D Z E N IE D O SOA

Dla pomyślnego budow ania rozwiązań opartych na usługach konieczne jest więc zawczasu zarówno zrozum ienie i oszacowanie opisanych wymagań, jak i rozpoznanie ograniczeń własnej struktury w tym zakresie. W praktyce oznacza to: • przetestowanie zdolności wspomnianej infrastruktury do przetwarzania komunikatów, jeszcze przed zainwestowaniem w usługi sieciowe; • przetestowanie, w warunkach ekstremalnego obciążenia, różnorodnych procesorów (dedykowanych standardom XML, XSLT, SOAP itp.), których zastosowanie bierze się pod uwagę; • przeprowadzenie rozpoznania w obszarze alternatywnych procesorów, akceleratorów i innych technologii wspomagających; w tej grupie wymienić można między innymi specyfikacje XOP (XML-binary Optimized Packaging) i SOAP MTOM (Message Transmission Optimization Mechanism), obie autorstwa W 3C (szczegółowe informacje na ich temat znaleźć można w witrynie www.w3c.org). Wydajność jest też jednym z kryteriów preferowania „gruboziarnistych” interfejsów usług oraz asynchronicznej komunikacji między usługami. W raz z innymi jeszcze zabiegami projekto­ wymi cechy te pozwalają na unikanie potencjalnych „wąskich gardeł” przetwarzania.

3.5.6. Niedocenianie bezpieczeństwa usług sieciowych Zakres rozwoju technologii usług sieciowych w danym środowisku jest zwykle powiązany ze swo­ bodą deweloperów i architektów w ram ach danego frameworku technologicznego. W rozrastają­ cej się architekturze wygodnie jest nadal wykorzystywać uproszczony m echanizm wymiany ko­ munikatów, którego zabezpieczenie opiera się na szyfrowaniu dostarczanym przez protokół SSL (Secure Sockets Layer). Mimo iż SSL świetnie się spisuje w roli zabezpieczenia bezpośredniego, nie jest technologią „z wyboru” dla SOA: w miarę jak usługi obejmować będą coraz większy zakres przetwarzania, pojawi się zapotrzebowanie na mechanizmy zabezpieczające na poziomie komunikatów. Framework WS-Security oferuje powszechnie akceptowalny model zabezpieczeń, realizowany przez rodzinę specyfikacji przenikających aplikacje usługowe i architektury korporacyjne na wielu poziomach. Jednym z ważniejszych zagadnień projektow ych związanych z wykorzystywaniem m odelu WS-Security jest zapewnienie centralizacji zabezpieczeń. Zgodnie z takim podejściem, duża por­ cja logiki i zasad bezpieczeństwa wydzielona zostaje w postaci odrębnej, centralnej warstwy abs­ trakcji, na bazie której zapewnione zostaje bezpieczeństwo dla aplikacji usługowych. Jeśli naw et wykorzystywana obecnie platform a nie zapew nia wystarczającego w sparcia dla WS-Security, a istniejące zabezpieczenia oparte na SSL spełniają bieżące wymagania w zakresie bezpieczeństwa, warto pomyśleć perspektywicznie, zwracając baczną uwagę na zmiany, jakie nie­ uchronnie prędzej czy później okażą się konieczne. Rozwijanie infrastruktury bez wykorzystywa­ nia WS-Security nieuchronnie prowadzi do sytuacji, w której niezbędne stanie się ponowne pro­ jektow anie i im plem entow anie niektórych rozwiązań. A rgum ent ten staje się ważniejszy, gdy decydujemy się na zaimplementowanie scentralizowanego modelu bezpieczeństwa, który stanie się rozszerzeniem infrastruktury IT.

3 .5 . NA JW AŻNIEJSZE PUŁAPKI W ADA PTA C JI SOA

77

3.5.7. Niedotrzymywanie kroku nowoczesnym platformom i standardom Profesjonaliści IT, pracujący w ram ach jednej platform y program istycznej, nie m ają na ogół w zwyczaju interesować się bieżącymi trendam i objawiającymi się w świecie innej platform y — i tak na przykład twórcy aplikacji dla platformy .NET nie są generalnie zbyt podekscytowani tym, co aktualnie dzieje się w kręgach Javy (i vice versa). Niezależność SOA od konkretnych technologii otwiera przed działami IT szeroki rynek pro­ duktów oraz możliwość wyboru platform y do tw orzenia i hostow ania logiki aplikacji. I chociaż względy produktywności przemawiają za kontynuacją wykorzystywania tego, co zna się najlepiej (bo poznało się i praktykowało przez lata), to jednak opcja sięgnięcia po nowsze narzędzia istnieć będzie zawsze, między innym i również dlatego, że otwarty framework komunikacyjny (jako jeden z fundam entów SOA) gwarantować będzie możliwość komunikacji między aplikacjami zbudo­ wanymi za pom ocą różnych technologii — i w konsekwencji współdziałanie tychże aplikacji. Jednym z istotnych czynników, które należy brać pod uwagę przy wyborze konkretnego do­ stawcy, jest relacja tego dostawcy z trwającym procesem opracowywania specyfikacji rozszerzeń WS-*, zwłaszcza w sytuacji, gdy określone rozszerzenie m a zostać użyte do implementacji klu­ czowych elementów logiki aplikacji. Interesująca będzie z pewnością pozycja dostawcy wśród do­ stawców konkurencyjnych, dostarczających implementacje tych samych rozszerzeń. Równie inte­ resujący może być ogólny związek konkretnego dostaw cy ze światem specyfikacji WS-*, na przykład w kwestii tego: • które specyfikacje znajdują wsparcie w jego produktach, • jakie jest jego zaangażowanie w sam proces opracowywania specyfikacji, • z którymi innym i organizacjami współpracuje podczas doskonalenia określonego standardu, • jak przedstawia się planowane wsparcie, ze strony produktów lub platform, dla specyfikacji i standardów, które opublikowane zostaną w najbliższej przyszłości. W rozdziale 4. podajemy ogólny opis procesu opracowywania standardów oraz charaktery­ stykę pierwszych organizacji standaryzacyjnych związanych z SOA. PODSUMOW ANIE •

W iele błędów popełnianych przy transformacji w stronę SOA w ynika z niezrozumienia jej istoty oraz nieświadomości w ym agań warunkujących pomyślne jej w drożenie.

•

Zrozumiały plan transformacji jest najlepszą bronią przeciwko przeszkodom, które napotykać mogą firmy na swej drodze migracji w kierunku SOA.

•

Dotrzym yw anie kroku tw orzonym produktom komercyjnym oraz opracow yw anym standardom stanowi istotny czynnik zapewniający zgodność tworzonych obecnie rozwiązań z przyszłym rozwojem infrastruktury.

78

ROZDZIAŁ 3. ■ WPROWADZENIE DO SOA

Rozdział 4

Ewolucja SOA 4.1. Oś czasu SOA (od XML, przez usługi sieciowe, do SOA) 4.2. N ieustanna ewolucja SOA (organizacje standaryzacyjne i kontrybutorzy) 4.3. Korzenie SOA (SOA a tradycyjne architektury)

80

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Jedną z charakterystycznych, wspominanych w poprzednim rozdziale, cech SOA jest jej ewolu­ cyjna natura. By w pełni docenić jej zalety, trzeba przyjrzeć się dokładniej ewolucji SOA, a kon­ kretnie zastanowić się, jaki wpływ na tę ewolucję mają — i generalnie w jakim kierunku prowadzą SOA — coraz to nowe osiągnięcia przemysłu informatycznego. W tym rozdziale omawiamy relacje zachodzące między trzema dom enam i — XML, usługami sieciowymi i SOA — oraz wyjaśniamy, jak producenci i organizacje standaryzacyjne przyczynili się do powstania tej przedziwnej, bo jednocześnie rywalizacyjnej i kolaboratywnej, areny, na której spe­ cyfikacje usług sieciowych ukazują coraz to nowe oblicza. Na zakończenie przedstawiamy krótki rys historyczny rozwoju architektur aplikacji na przestrzeni dwóch ostatnich dziesięcioleci.

UWAGA Chronologiczna aranżacja tego rozdziału może w yd aw ać się zrazu dziw na: rozpoczynamy od prezentacji ak­ tualnego stanu ewolucji SOA, a dopiero potem zagłębiam y się w historię wydarzeń prowadzących do tego stanu. To jednak zabieg celowy: nie chcemy zaprzątać uw agi tych czytelników, którzy w spom nianą historią nie są zainteresow ani, zresztą można ten fragm ent pom inąć bez szkody dla pozostałej treści rozdziału.

Analizy przypadków: W tym rozdziale m am y okazję zilustrować dokonywane porównania architektur przykładami pochodzącymi z naszych fikcyjnych firm — RailCo i TLS. Porów ­ nanie każdej z cech charakterystycznych SOA i architektury rozproszonej zakończone jest stosowną analizą przypadku.

4 .1 . Oś czasu S O A (o d X M L , p rze z u słu g i s ie c io w e , d o SOA) Rozpoczniemy od spojrzenia na oś czasu, na której wyróżniono wydarzenia kluczowe dla prze­ mysłu inform atycznego i sprawcze dla obecnego kształtu platform y SOA. Następnie pokażemy, jak emancypacja SOA jako współczesnej platform y architektonicznej przyczyniła się do zmiany roli XML i usług sieciowych w nowoczesnym świecie informatycznym.

4.1.1. XML — krótka historia Podobnie jak język HTML, tak język XML (Extensible M arkup Language) opracowany został przez konsorcjum W3C jako następca SGML (Standard Generalized M arkup Language), języka znaczników popularnego od lat 60. ubiegłego wieku. Język (właściwie: metajęzyk) zyskał tę po­ pularność dzięki możliwości przydania inteligencji „surowym” plikom danych. XML datuje swój żywot (i coraz większą popularność), począwszy od końca lat 90. ubiegłego wieku, kiedy to ekspansja Internetu przyczyniła się do powstania i rozwoju e-biznesu, realizowa­ nego głównie w oparciu o języki skryptowe przetwarzane w serwerach zaplecza. Dzięki językowi XML deweloperzy zyskali możliwość nadawania znaczenia i kontekstu dowolnej porcji informacji transmitowanej przy użyciu protokołów internetowych. Oprócz naturalnej roli narzędzia do standardowego reprezentowania danych, język XML stał się też bazą dla sformułowania specyfikacji dwóch powiązanych języków: XSD (XML Schema De­ finition Language) oraz XSLT (XSL Transformation Language). Cała ta trójka — XML, XSD i XSLT — stanowi obecnie trzon nowoczesnego zestawu technologii XML.

4 .1 . OŚ CZASU SO A (O D X M L , PRZEZ USŁUGI SIEC IO W E, D O SOA)

81

Architektura reprezentacji danych w standardzie XML jest jedną z fundamentalnych warstw SOA. XML wyznacza form at i strukturę kom unikatów wymienianych między usługami. Schematy XSD zapewniają poprawność i integralność danych przenoszonych przez te komunikaty, natomiast zadaniem XSLT jest umożliwienie komunikacji między dwiema różnymi reprezentacjami danych za pomocą mapowania schematów. Jednym słowem — niepodobna zrobić krok w stronę SOA bez angażowania standardu XML.

4.1.2. Usługi sieciowe — krótka historia W roku 2000 konsorcjum W3C otrzymało zapotrzebowanie na specyfikację SOAP (Simple Object Access Protocol). Zadaniem tej specyfikacji miało być początkowo ujednolicenie (a w wielu przy­ padkach —zastąpienie) własnościowej komunikacji RPC. Zgodnie z nową koncepcją, dane powinny być najpierw przekształcane („serializowane”) ze swej rodzimej postaci na form at XML, w tym formacie transmitowane, a po dotarciu do celu przekształcane („deserializowane”) na wymagany form at docelowy. Producenci oprogram owania (i przedsiębiorstwa użytkujące systemy informatyczne) szybko zdali sobie sprawę z faktu, że zapewnienie niezależnego od dostawców internetowego frameworku komunikacyjnego stwarza niesam owitą szansę dla rozwoju e-biznesu. Na kanwie tego pomysłu zrodziła się koncepcja klarownej, opartej na sieci W W W technologii przetwarzania rozproszonego: jednolity framework komunikacyjny stanowić miał pomost nad przepaścią dzielącą dwa drastycznie różne systemy w różnych przedsiębiorstwach (a niekiedy w tym samym przedsiębiorstwie). Kon­ cepcję tę opatrzono nazwą usług sieciowych (Web services). Najważniejszym elementem usługi sieciowej jest jej publiczny interfejs. Stanowi on centralny punkt informacji, przyporządkowujący usłudze tożsamość i umożliwiający jej wywoływanie. Nic więc dziwnego, że jedną z pierwszych inicjatyw w kierunku wsparcia dla usług sieciowych był język WSDL (Web Service Description Language — język opisywania usług sieciowych). Pierwsza spe­ cyfikacja tego języka ujrzała światło dzienne w roku 2001 i od tego czasu jest sukcesywnie rozwijana. Do urzeczywistnienia wizji interoperacyjności (współdziałania) usługi sieciowe potrzebują zestandaryzowanego frameworku komunikacyjnego, zgodnego z Internetem i wykorzystującego for­ m at danych kompatybilny z XML. Mimo iż rozważano wiele możliwości w tym względzie, między innym i protokół XML-RPC, przemysłowym faworytem okazał się SOAP i to on stał się dom inu­ jącym standardem komunikacji dla usług sieciowych. Uwzględniając tę nową rolę protokołu SOAP, konsorcjum W 3C opracowało nowszą wersję jego specyfikacji, zgodną zarówno z kom unikatam i w stylu RPC, jak i kom unikatam i w stylu do­ kumentowym — te ostatnie używane są na gruncie SOA znacznie częściej. Sam zaś term in SOAP przestał być postrzegany jako akronim „Simple Object Access Protocol” — począwszy od wersji 1.2 specyfikacji, jest już samodzielnym terminem. Do rodziny standardów usług sieciowych pierwszej generacji należy ponadto specyfikacja UDDI. Zapoczątkowana przez UDDI.org, została powierzona organizacji OASIS, która kontynu­ uje jej rozwój we współpracy z UDDI.org. Specyfikacja ta przewiduje tworzenie zestandaryzowanych rejestrów opisów usług, obejmujących swym zasięgiem całe przedsiębiorstwo, a nawet prze­ kraczających jego granice. Usługi sieciowe m ogą być potencjalnie rejestrowane w centralnej lokalizacji, za pośrednictwem której wykrywane są przez usługi-wnioskodawców. W przeciwień­ stwie jednak do WSDL i SOAP, UDDI nie zyskało sobie powszechnej akceptacji w kręgach prze­ mysłowych i aktualnie pozostaje opcjonalnym rozszerzeniem SOA.

82

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Dla zaspokojenia specyficznych potrzeb biznesowych opracowano wiele stosownych usług sieciowych, wykształcił się ponadto rynek sprzedaży i dzierżawy takich usług. Istniejące platformy komunikacyjne, między innym i produkty MOM (Messaging-Oriented Middleware), zaprzęgnięte zostały do pracy na potrzeby usług sieciowych, poprzez zgodność z protokołem SOAP i innymi protokołam i komunikatów. Niektóre organizacje dokonały także bezpośredniego wcielenia usług sieciowych do swych systemów B2B w celu ułatwienia wymiany danych z kontrahentami — często jako alternatywę dla elektronicznej wymiany danych EDI (Electronic Data Interchange).

4.1.3. SOA — krótka historia Nie minęło wiele czasu i organizacje uświadomiły sobie, że zamiast po prostu przystosowywać istniejące aplikacje rozproszone do nowych potrzeb, lepiej będzie wykorzystać usługi sieciowe ja­ ko fundam ent dla nowej platform y architektonicznej — platformy zdolnej wykorzystać zalety technologii usług sieciowych do zrealizowania koncepcji usług w przedsiębiorstwie. Tak oto SOA rozpoczęła swój żywot jako technologia przyszłości. Na tym etapie swej ewolucji SOA klasyfikowana bywała na różne sposoby, najczęściej na pod­ stawie technologii wykorzystywanej do im plem entowania usług sieciowych. Wczesny model, in­ spirowany głównie pierwotnymi standardami usług sieciowych, definiował SOA jako architekturę obejmującą trzy podstawowe kom ponenty, takie jak usługa-wnioskodawca, usługa-dostarczyciel i rejestr usług (patrz rysunek 4.1).

Rysunek 4.1. Wczesne ucieleśnienie SOA

Usługi sieciowe pierwszej generacji realizowały ten model następująco: • usługa opisywana była w języku WSDL, • SOAP determ inował format kom unikatów wymienianych między usługą-dostarczycielem a jej wnioskodawcą, • UDDI definiował standardowy form at rejestru usług.

4 .1 . OŚ CZASU SO A (O D X M L , PRZEZ USŁUGI SIEC IO W E, D O SOA)

83

Z perspektywy fizycznej architektury ta pierwsza odm iana SOA bazującej na usługach wykra­ cza poza granice m odelu pierwotnej SOA, który opisywaliśmy w rozdziale 3. Jak pamiętamy, pierwotna SOA nie wymaga obecności ani używania rejestru usług; wykrywalność usług jest na­ tomiast jedną z cech współczesnej SOA i jako taka propagowana jest w ram ach zasad zoriento­ wania na usługi. Model pierwotnej SOA właściwie sięgnął już swych szczytów — jej obsługę zapewniają plat­ form y program istyczne i wykonawcze wszystkich liczących się dostawców. Ci sami dostawcy mają wielkie plany dotyczące SOA i nie są to bynajm niej plany na papierze: wiele omawianych w rozdziale 3. cech charakterystycznych współczesnej SOA to rezultat ofensywnych inicjatyw zmierzających do rozszerzania pierwotnego modelu. Rozszerzenia te, znane jako „druga genera­ cja usług sieciowych” lub po prostu „specyfikacje WS-*”, dedykowane są określonym aspektom funkcjonalnym usług sieciowych, a ich wspólnym celem jest podniesienie platformy usług siecio­ wych do rangi platformy klasy enterprise. Krajobraz specyfikacji WS-* dopełnia zastosowanie koncepcji zorientowania na usługi w świecie analiz biznesowych. Zgodnie z tą koncepcją, logika biznesowa może zostać przejrzyście enkapsulowana i odseparowana od zastosowanej technologii automatyzacyjnej. Praktyczną realizacją tej wizji jest powstanie języków definicji procesów biznesowych, na czele z WS-BPEL. Nie tylko umoż­ liwiają one dekompozycję tradycyjnych modeli zarządzania procesami biznesowymi (BPM — Business Process Management) na usługi składowe, lecz stanowią także wypełnienie luki między analizą a im ­ plementacją, bo logika biznesowa w pełni wyrażona zostaje jako konkretny, wykonywalny kod. Te i inne interakcje z przemysłem informatycznym spowodowały poszerzenie wizerunku SOA. Niewykluczone więc, że dzięki nieustannem u wzbogacaniu tego wizerunku o nowe cechy rychło doczekamy chwili, w której to, co dziś nazywamy „współczesną SOA” postrzegane będzie jako „tra­ dycyjna SOA” stanowiąca punkt wyjścia dla nowoczesnego modelu. SOA jest więc bytem prawdziwie ewolucyjnym. Jej obecne znaczenie jest wynikiem wielu wzajemnie powiązanych inicjatyw organizacji standaryzacyjnych i producentów oprogramowania. W dzisiejszym, zm iennym środowisku, stanowiącym istną mieszankę rywalizacji i współpracy, każde z rozszerzeń będących efektem wspomnianych inicjatyw jest strategicznie umiejscowioną częścią tego, co dzisiaj nazywamy platformą współczesnego SOA. W punkcie 4.2 zajmiemy się do­ kładniej procesem opracowywania standardów dla SOA.

4.1.4. SOA a nowe oblicze XML i usług sieciowych Jak każda architektura, tak i SOA cechuje się swoistymi regułami i ograniczeniami. Co prawda, zaistnienie współczesnej SOA stało się możliwe dzięki standardow i XML i usługom sieciowym, lecz w miarę rozwoju SOA relacje te się odwróciły — platformy te musiały doznać pewnych prze­ obrażeń po to, by można je było właściwie umiejscowić i spożytkować w ramach architektury zo­ rientowanej na usługi. Tradycyjne aplikacje rozproszone wykorzystujące XML i (lub) usługi sieciowe — i myślenie ich kategoriam i — wymagają więc pewnych istotnych przewartościowań. Oto kilka przykładów potencjalnych problemów, jakie w tym względzie stwarzać mogą istniejące implementacje tychże aplikacji.

84

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

UWAGA W iele z wymienionych poniżej zagadnień om awianych jest bardziej szczegółowo w rozdziale 14.

• Zgodnie z wymaganiami SOA, reprezentacja danych musi iść w parze ze standardam i modelowania usług. To raczej ogólnikowe stwierdzenie stwarza wiele implikacji jako fundam ent zapewnienia naturalnego współdziałania. • Komunikacja między usługami w ram ach SOA opiera się na kom unikatach SOAP. To właśnie protokół SOAP zapewnia im transport, wewnętrzne przetwarzanie, trasowanie i dostarczanie do miejsca przeznaczenia. Modelowanie dokum entów XML i związanych z nim i schematów XSD musi się więc odbywać z uwzględnieniem jego wymogów. • SOA wprowadza standaryzację wykorzystywania kom unikatów w stylu dokumentowym (document-style mesaging) zamiast tradycyjnych kom unikatów w stylu RPC. Wymaga to zmiany w sposobie projektowania opisów usług: interfejsy muszą mieć teraz charakter gruboziarnisty (czyli muszą być wyrażane w bardziej ogólnych kategoriach) i w konsekwencji generalnie zwiększa się granulacja poszczególnych operacji. • Preferując kom unikaty w stylu dokumentowym, SOA stwarza wymóg wyposażenia modelu komunikacji w odpowiedni poziom inteligencji, umożliwiający usługom zachowanie bezstanowości oraz autonom ii i minimalizujący częstotliwość wymieniania komunikatów między usługami. W odróżnieniu od komunikatów w stylu RPC, z natury drobnoziarnistych i przenoszących drobne porcje „ukierunkowanych” danych, dokum enty XML w ramach SOA reprezentują raczej wiązki danych dotyczących zwykle więcej niż jednego kontekstu. • Zanim powszechne stanie się wykorzystywanie mechanizmów komunikacyjnych oferowanych przez rozszerzenia WS-*, konieczne będzie wyposażenie wielu aplikacji w specjalne nagłówki SOAP, stanowiące doraźne przystosowanie tychże aplikacji do skomplikowanego schem atu komunikacji — doraźne, bo przeważnie nieuwzględniające zarządzania kontekstem i korelacjami. Tego rodzaju zabiegi faktycznie składają się na pewien model transform acji w stronę implementacji standardów przemysłowych — transformacji, której przeprowadzenie będzie łatwiejsze, gdy zostanie zawczasu starannie zaplanowana. PODSUMOW ANIE •

Podstaw ow e technologie X M L stały się nieodłączną częścią rozproszonej architektury internetow ej.

•

Architektura usług sieciowych pierwszej generacji wykształciła się jako konglom erat trzech standardów: WSDL, SOAP i UDDI. Podczas gdy UDDI w ciąż jest w w ielu środowiskach mechanizm em opcjonalnym , WSDL i SOAP stały się kluczowymi technologiam i zbudow anym i na w arstw ie X M L i definiują fundam entalny fram ew ork komunikacyjny dla SOA.

•

SOA w pełni otworzyła drogę wytyczoną przez inicjatywy X M L i usług sieciowych. Udany mariaż tych sprawdzonych koncepcji z rozwijającym i się technologiam i został w pełni zaakceptow any przez globalną społeczność IT.

•

M im o iż współczesna SOA ukształtowana została przez X M L i usługi sieciowe, realia SOA spow odow ały konieczność zmiany w traktowaniu tych technologii w stosunku do tradycyjnych architektur rozproszonych.

4 .2 . N IE U S T A N N A EW O LU C JA SO A (O R G ANIZACJE STA N DARYZACYJNE I KONTRYBUTORZY)

85

4 .2 . N ie u s ta n n a e w o lu c ja SOA (o rg an izacje sta n d a ry za cy jn e i ko n try b u to rzy ) XML definiowany jest w specyfikacji jako język zapisu treści, lecz poza tym użyty został jako język zapisu wszystkich niemal specyfikacji dotyczących standardu XML i usług sieciowych. Niezależ­ nie więc od tego, jak dalece rozwinie się kraina specyfikacji, nie można zapominać o ich wspólnych korzeniach. I niezależnie od tego, czy przyjdzie nam bezpośrednio pracować ze wspomnianymi specyfika­ cjami, ich istnienie i ewolucja będą znaczące dla każdego budowanego rozwiązania zorientowa­ nego na usługi. Do pełnego zrozum ienia świata SOA konieczna jest zatem wiedza o tym, jak i dla­ czego opracowywane są specyfikacje i standardy.

4.2.1. Standardy, specyfikacje i rozszerzenia Wymienione w tytule określenia często używane są zamiennie, bez zbytniego troszczenia się o ade­ kwatność ich znaczenia, często jednak troska taka jest niezbędna (o czym wiedzą przede wszyst­ kim wszyscy zaangażowani w tworzenie wymienionych kategorii). Tak więc specyfikacja to do­ kum ent zawierający propozycje standardu. Standard ten zachowuje status propozycji do czasu, aż wspomniana specyfikacja zostanie przekazana uznanej organizacji standaryzacyjnej, zaakceptowana przez nią i opublikow ana — wówczas proponow any standard staje się oficjalnym standardem przemysłowym. Często bywa tak, że standard proponow any przez producenta (zwłaszcza producenta współ­ pracującego z organizacją standaryzacyjną), mimo swego nieoficjalnego charakteru, zostaje przez tegoż producenta zaim plem entow any na wytwarzanych przez niego platform ach, czyli staje się standardem de facto. Powracając do tytułowych kategorii, aby uniknąć nieporozum ień, w książce tej używać ich będziem y w następującym znaczeniu. • Standardem nazywać będziemy zaakceptowany standard przemysłowy. Wszystkie specyfikacje usług sieciowych pierwszej generacji uważane są za standardy w tymże znaczeniu, podobnie jak wiele specyfikacji XML. • Za specyfikację uważać będziemy opis proponowanego lub zaakceptowanego standardu. Standardy XML, standardy usług sieciowych pierwszej generacji oraz rozszerzenia WS-* — wszystkie one opisane są w ram ach specyfikacji. • Przez rozszerzenie rozumieć będziemy specyfikację WS-* lub m echanizm opisywany w takiej specyfikacji.

4.2.2. Organizacje standaryzacyjne związane z SOA Jak wiadom o, standardy są tym, co decyduje o rozwoju SOA. Poprzednie platform y architekto­ niczne realizowane były w granicach i według zasad określonych przez producentów — obowią­ zywanie standardu, specyficznego dla producenta, kończyło się na granicach jego platformy. Wraz z koncepcją frameworku niezależnego od producenta pojawia się niepodlegające dyskusji wyma­ ganie, by standard definiujący ten framework także pozostawał niezależny od konkretnych pro­ ducentów.

86

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Jak powstają standardy? Kwestia ta nie jest do końca oczywista. Organizacje zajmujące się standardam i internetow ym i istnieją już od dłuższego czasu i są powszechnie znane, lecz już ich agendy i oddziały nie zawsze są wyraźnie rozróżnialne, a często nawet się nakładają — dana agenda jest agendą dwóch lub więcej organizacji. Żeby było ciekawiej — największy wkład do „neutralnych” standardów wnoszą właśnie konkretni producenci: Microsoft, IBM, Oracle (daw­ niej Sun Microsystems) i wiele innych firm odgrywa coraz większą rolę nie tylko w formalizowaniu specyfikacji usług sieciowych, lecz także nadają bieg implementowaniu tych specyfikacji jako standardów przemysłowych. O tym, jaki wkład wnoszą producenci do opracowywania standar­ dów i jaki na te standardy wywierają wpływ, piszemy w następnym punkcie; przedtem jednak warto zapoznać się z trzem a najbardziej znaczącymi organizacjami standaryzacyjnymi, kolektyw­ nie odpowiedzialnymi za kształt ewolucji XML i architektur usług sieciowych. World W ide Web Consortium (W3C) Założone przez Tima Bernersa-Lee w 1994 roku, konsorcjum W 3C przyjęło na siebie główną od­ powiedzialność za rozwój sieci W W W jako globalnego, semantycznego m edium współdzielenia informacji. Dokonania W 3C zaczynają się od języka HTML, jednego z najpopularniejszych języ­ ków technicznych, jakie kiedykolwiek wypracowano w kręgach przemysłu IT. Gdy Internet zaczął zdobywać coraz większą popularność jako narzędzie komunikacyjne e-biznesu, odpowiedzią W3C było stworzenie kluczowych standardów opartych na XML, między innymi XML Schema i XSLT. Cztery grupy robocze wniosły znaczący wkład do projektów W 3C Web Services Activity, któ­ rych rezultatem było opracowanie najważniejszych standardów bazowych dla usług sieciowych. Pierwsze i najważniejsze z nich to SOAP i WSDL, sztandarowe specyfikacje związane z usługami sieciowymi. Nieco późniejsza specyfikacja — WS-CDL (W eb Services Choreography Description Language) — dedykowana jest standardowym wzorcom wymiany informacji między usługami. W art uwagi jest też sam dokum ent Web Services Architecture: mimo iż doświadcza on nieustan­ nych zmian, nadal pozostaje punktem odniesienia i jest jednym z nielicznych dokum entów trak­ tujących architekturę usług sieciowych w sposób abstrahujący od konkretnej platformy. W 3C znane jest ze swego formalnego i rygorystycznego podejścia do opracowywania stan­ dardów. Zanim dany standard opublikowany zostanie na oficjalnej witrynie, jego specyfikacja poddaw ana jest wieloetapowym procesom przeglądu i rewizji, i dotyczy to każdej nowej wersji czy aktualizacji. Ten rygoryzm m a swoją cenę w postaci zwłoki czasowej: cała procedura opraco­ wania nowego standardu może trwać dwa - trzy lata. Organization for the Advancement o f Structured Information Standards (OASIS) Założona w 1993 roku jako SGML Open, pięć lat później zmieniła nazwę na OASIS, by zaakcen­ tować przesunięcie swego zainteresowania na standardy powiązane z XML. Licząca tysiące człon­ ków wywodzących się z ponad 600 organizacji, OASIS jest uznaną międzynarodową organizacją standaryzacyjną. OASIS uważana jest za autora znaczącej specyfikacji WS-BPEL, znana jest także z opracowa­ nia ebXML (specyfikacji mającej za zadanie dostarczenie standardowych środków wymiany danych w ram ach B2B) i przyczynku do specyfikacji UDDI — jednego z kluczowych standardów związa­ nych z platformam i usług sieciowych pierwszej generacji.

4 .2 . N IE U S T A N N A EW O LU C JA SO A (O R G ANIZACJE STA N DARYZACYJNE I KONTRYBUTORZY)

87

OASIS m a znaczący udział w rozwoju rozszerzeń zabezpieczających XML i usługi sieciowe: zarówno SAML (Security Assertion Markup Language) i XACML (eXtensible Access Control Markup Language) dostarczają mechanizmy zabezpieczeń bazujące na jednokrotnym logowaniu i autory­ zacji. Najważniejszy jednak projekt związany z zabezpieczeniami zrealizowany został przez ko­ m itet techniczny WSS (W eb Services Security), którem u powierzono przyszły rozwój frameworku WS-Security. Podczas gdy W 3C koncentruje się na tw orzeniu kluczowych, neutralnych technologicznie standardów, to główną dom eną zainteresowania grupy OASIS jest wspomaganie owych kluczo­ wych standardów za pom ocą dodatkow ych specyfikacji, dedykowanych różnym przem ysłom wertykalnym. Także proces opracowywania standardów jest w przypadku grupy OASIS znacząco krótszy. Web Services Interoperability Organization (WS-I) Głównym celem WS-I nie jest tworzenie nowych standardów, lecz zapewnienie, że realizowany jest ultymatywny cel — otwarta interoperacyjność. Założone w 2002 roku, konsorcjum to rozwinęło się znacząco, zyskując poparcie prawie 200 organizacji, w tym czołowych dostawców SOA. WS-I znana jest przede wszystkim jako autor Basic Profile — dokum entu o statusie rekom en­ dacji, stanowiącego swego rodzaju poradnik dotyczący używania dostępnych standardów do bu­ dowania jak najlepszej architektury interoperacyjnej. Umiejscawiając formalnie w tym kontekście konkretne wersje WSDL, SOAP, UDDI, XML i XML Schema, dokum ent ten stał się niezwykle istotny dla społeczności IT jako punkt odniesienia: producenci dbający o pełną interoperacyjność swoich platform dążą przede wszystkim do zachowania zgodności tych platform z dokum entem Basic Profile. Późniejszy dokum ent autorstwa WS-I — Basic Security Profile — utrzymany w tej samej kon­ wencji, co Basic Profile, definiuje kolekcję technologii dedykowanych bezpieczeństwu XML i usług sieciowych. WS-I ogłosiło swój plan kontynuowania serii dokum entów Profile dla każdego istot­ nego aspektu interoperacyjności usług sieciowych, między innymi niezawodnej wymiany kom u­ nikatów, zarządzania usługami i orkiestracją. Dokum enty serii Profile, oprócz werbalnego definiowania architektury interoperacyjnej, uzu­ pełniane są o przykładowe implementacje i wskazówki zalecanych praktyk dotyczących jak naj­ lepszego wykorzystywania dostępnych standardów w celu osiągnięcia jak najwyższej jakości współ­ działania. Ponadto WS-I dostarcza narzędzia pozwalające na upewnienie się, że konkretne rozwiązania czynią zadość wymaganiom opisywanym w dokum entach Profile. Wielu producentów dostarcza także własne odm iany tych narzędzi, wśród nich weryfikatory zgodności z Basic Profile. WS-I stara się zachować bezstronność w kwestii udziału swych członków w swoich pracach: m im o iż wśród członków tych są zarówno znaczący dostawcy SOA, jak i pomniejsi gracze, nikt nie jest faworyzowany, nie ma znaczenia wielkość firmy ani jej udział w rynku. Chociaż konsorcjum W3C odrzuciło niedawno zaproszenie do członkowstwa w WS-I, członkowie grup roboczych WS-I kontynuują swój udział w inicjatywach W3C i OASIS, uczestnicząc bezpośrednio w grupach robo­ czych tych organizacji w celu kontynuowania współpracy związanej z interoperacyjnością. Porównanie W tabeli 4.1 przedstawiamy skrócone porównanie wybranych cech i aspektów funkcjonowania trzech omawianych organizacji.

88

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Tabela 4.1. Porównanie organizacji standaryzacyjnych

R ok założenia

W 3C

OASIS

W S -I

1994

1993 jako SGM L O pen,

2002

1998 jako OASIS Liczba członków

400

600

200

(w przybliżeniu) O gólne cele

W sp iera n ie ew olucji sieci W W W

P ropagow anie h a n d lu

Z apew nienie

(zw iązane z SOA)

p o p rz ez dostarczanie

i w sp ó łp racy biznesow ej

interoperacyjności

fu n d a m e n ta ln y ch stan d ard ó w

za p o m o cą stan d ard ó w

n a gruncie

uspraw niających w spółdzielenie

specjalizow anych usług

stan d ard ó w

inform acji i biznes online

sieciowych

u słu g sieciowych

B asic P ro file , Basic S ecurity P ro file

W ażniejsze

XM L, XM L Schem a, X Q uery,

U D D I, ebXM L, SAML,

publikacje

XM L E ncryption, XM L Signature,

XA CM L, W S-BPEL,

(zw iązane z SOA)

X P ath, XSLT, W SDL, SOAP,

W S-S ecurity

W S -C D L, W S-A ddressing, Web Services A rc h ite c tu re

4.2.3. Czołowi dostawcy SOA Chociaż organizacje standaryzacyjne działają zgodnie z własną kulturą i filozofią opracowywania standardów, jednak nie działają w próżni, lecz silnie uzależnione są od rynku (od którego zresztą otrzymują wsparcie i wkład merytoryczny). Mimo iż formalnie istnieją jako niezależne podmioty, zrzeszają przecież większość głównych dostawców oprogramowania — którzy z kolei mają swój znaczący udział w bieżącym opracowywaniu standardów. W tej grupie faktycznie znajdujemy największych świata IT: Microsoft, IBM, BEA Systems, Oracle, Tibco, Hewlett-Packard, Canon, Commerce One, Fujitsu, Software AG, Nortel, Verisign i W ebM ethods — że ograniczymy się tylko do wybranych. Dynamika interakcji między produ­ centami, ich rozmaite alianse i sam udział w organizacjach standaryzacyjnych — to wszystko jest na tyle ciekawe, że wymaga pobieżnego chociaż omówienia. Dlaczego opracowuje się standardy wspierające SOA? Nie sposób wskazać pojedynczej osoby ani pojedynczej organizacji, która sprawowałaby wyłączną kontrolę nad SOA. Stanowiąc wynik ewolucji, od panoptikum własnościowych platform do ar­ chitektury opartej na otwartych standardach i „neutralnych” protokołach, SOA pozostanie ważną platformą tak długo, jak długo zapewniać będą jej wsparcie najwięksi wytwórcy oprogramowania. Jest bowiem zrozumiałe, że użyteczność SOA wynika z jej globalnego zaakceptowania; SOA pozostanie użyteczna tak długo, jak długo cieszyć się będzie akceptacją, taką jak obecnie. No bo jakiż sens miałoby budowanie aplikacji z założenia interoperacyjnych, jeśli tylko część tworzonych rozwiązań wykorzystywałaby technologie realizujące standardową komunikację międzyaplikacyjną? Ta zależność działa również w drugą stronę: skoro SOA jest dziś najważniejszą pozycją na li­ ście priorytetów wszystkich znaczących organizacji programistycznych, to rezygnacja ze zgodno­ ści z SOA stanowi dla wytwórcy oprogram ow ania świadome postawienie się poza granicam i wciąż rozwijającego się rynku.

4 .2 . N IE U S T A N N A EW O LU C JA SO A (O R G ANIZACJE STA N DARYZACYJNE I KONTRYBUTORZY)

89

Opisane sprzężenie zwrotne sprawia, że SOA jest filozofią na dziś i taką pozostanie w dającej się przewidzieć przyszłości. Wpływ dostawców Mimo iż nikt nie sprawuje wyłącznej kontroli nad SOA, każdy dostawca technologii m a swoje własne zdanie o tym, jak kształtowane powinny być technologie implementacyjne dla SOA. W y­ nikające stąd różnice powodują, że procesy opracowywania standardów często przeistaczają ewolu­ cję SOA w walkę między agendami. Każdy dostawca m a własną wizję dotyczącą tego, jak planować rozwój własnych produktów. I tak na przykład IBM powierzył platformie WebSphere ścieżkę technologiczną wzrastającego wsparcia dla SOA, a Microsoft nie tylko konsekwentnie zwiększa wsparcie dla SOA na platformie .NET, lecz sukcesywnie wbudowuje technologię usług sieciowych w kolejne wersje systemu Windows. Mimo iż w założeniu standard usług sieciowych powinien pozostać niezależny od dostawców, jednak każdy dostawca mający wpływ na kształtowanie tego standardu może odczuwać motywację do preferowania w tym kontekście filozofii bliskiej jego własnym technologiom. Choć m ożna się w tym dopatrywać znam ion podstępu czy manipulacji, niewątpliwie z jednym należy się zgodzić: ponieważ zadaniem każdego standardu jest de facto ukierunkowanie osobnych technologii na wspólny cel, standard ten znakomicie spełni to zadanie, jeśli stanowić będzie wynik kom prom isu dostawców reprezentujących znaczącą część rynku. Prawdziwym wyzwaniem jest jednak przeko­ nanie wszystkich dostawców do osiągnięcia wspomnianego kompromisu. Alianse dostawców Dawne bitwy między znaczącymi dostawcami prowadzą do daleko posuniętej nieufności — nie­ ufności stanowiącej wyraźną przeszkodę we współpracy nad specyfikacjami mającymi propago­ wać interoperacyjność. W połączeniu z poczuciem wspólnego interesu — poczuciem, które może okazać się silniejsze od nieufności i podejrzeń — prowadzi to do powstawania różnych, przeważnie nieformalnych, aliansów między firmami. Każdy taki alians pozwala wytwórcom połączyć siły w dążeniu do określonego celu. Zwykle trwanie takiego aliansu ogranicza się do cyklu życiowego konkretnej specyfikacji, choć znane są przykłady współpracy bardziej trwałej lub powtarzalnej — czego spektakularnym przykładem jest wspólny wysiłek IBM, Microsoftu i BEA, którego owocem jest seria specyfikacji WS-*. Jednym z najbardziej znanych przykładów standardu, który swą genezę zawdzięcza takiemu spektakularnemu aliansowi, jest specyfikacja WS-ReliableMessaging. Początkowo zapotrzebowanie na niezawodny mechanizm komunikacyjny zrodziło się z inicjatywy komitetu technicznego OASIS, który zaprosił do w spółpracy między innym i Sun Microsystems i Oracle; gotowa specyfikacja zatytułowana została WS-Reliability. I raptem tydzień później M icrosoft i IBM (we współpracy z kilkoma jeszcze innych firmami) ogłosiły własną specyfikację o nazwie WS-ReliableMessaging, bardzo podobną w treści i dedykowaną tym sam ym ogólnym wymaganiom. I choć została ona opublikowana później od poprzedniczki i stworzona bez udziału organizacji standaryzacyjnej (czy nawet konsultacji z takową), stała się dla tej poprzedniczki rów norzędnym konkurentem . I wszystko dlatego, że M icrosoft i IBM reprezentow ały znacznie większy segm ent rynku IT niż Sun plus Oracle. O pisany incydent nie tylko ilustruje ulotny stan przem ysłu usług sieciowych, lecz jest także świadectwem słabnącego autorytetu organizacji standaryzacyjnych.

90

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Wybór organizacji standaryzacyjnej Ogólnie jednak korzystnie jest dla producenta, gdy „jego” specyfikacja sformalizowana zostanie przez organizację standaryzacyjną. Staje się wtedy oczywiste, że celem tej specyfikacji jest wspieranie otwartego standardu, sama zaś specyfikacja jest przedm iotem jawnego, upublicznionego procesu. Czasami jednak wybór konkretnej organizacji standaryzacyjnej nie jest sprawą obojętną z tej prostej przyczyny, że procesam i opracowywania standardów rządzi drastycznie inna dynamika niż ta, której podlegają procesy rynkowe. Producenci mają swoje cele m arketingowe i działają pod presją terminowego dostarczania produktów zgodnych z oczekiwaniami klientów oraz prze­ ścigania oferty konkurencji (lub przynajmniej dorównywania tej ofercie). Zważywszy na dość długi cykl powstawania standardu w ram ach konsorcjum W3C, trudno się dziwić, że przedsiębiorcy chętniej powierzają swe standardy grupie OASIS. Chociaż opracowywanie kilku podobnych specyfikacji może wydawać się działaniem redundantnym , zawsze jedna z nich zdaje się ostatecznie dystansować pozostałe. Także niezależnie od tego, iż przeciwstawne motywacje mogą nie sprzyjać rozwojowi kolekcji standardów neutralnych technologicznie, dotychczasowe postępy w tej dziedzinie zdają się nie potwierdzać tej obawy. O czym nie wolno zapominać? W punkcie „Najważniejsze pułapki w adaptacji SOA” w rozdziale 3. zwróciliśmy uwagę na zna­ czenie dotrzymywania kroku nowo pojawiającym się produktom i standardom . Ten punkt zamy­ kamy zatem poniższą krótką listą powodów, dla których warto trzymać rękę na pulsie świata no­ wych standardów. • Planując migrację na SOA, warto wziąć pod uwagę proces dojrzewania kluczowych specyfikacji. Specyfikacje te udostępniają mnóstwo funkcjonalności przydatnych w nowej architekturze. • Obserwowanie procesów formowania standardów umożliwia dokonanie rozeznania, które specyfikacje podlegają rozwojowi, a które zatrzymały się w pewnym stadium. To może stanowić pewną wskazówkę dotyczącą tego, w którym kierunku podążać m a ewolucja rozwiązań zorientowanych na usługi. • Otrzymując informację o opracowywanych standardach, ich autorach i kontrybutorach, m ożna zyskać rozeznanie dotyczące trendów technologicznych związanych z SOA. • Ponieważ SOA pozwala na budowanie różnych aplikacji przy użyciu odm iennych platform programistycznych, konieczne jest zachowanie perspektywy abstrahującej od konkretnych dostawców. Pozwoli to na lepsze porównanie cech i stopnia wsparcia dla SOA na różnych platformach. PODSUMOW ANIE •

W kład konsorcjum W 3C w rozwój sieci W W W jest trudny do przecenienia. Z perspektywy SOA rola W 3C jest pierwszorzędna jako ciała standaryzacyjnego odpow iedzialnego za kluczowe i generyczne elem enty funkcjonalności.

•

OASIS powstała na kanw ie organizacji standaryzacyjnej SGML, a jej zainteresow ania skupiały się niemal w yłącznie na specyfikacjach związanych z e-biznesem. Celem działalności OASIS było w spom aganie tworzenia standardów ukierunkowanych na konkretne gałęzie przemysłu oraz wspomagających wym ianę handlow ą między firm am i za pośrednictwem e-biznesu.

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

•

W S-I jako grupa zajmująca się problem am i współdziałania zróżnicowanych platform nie produkuje nowych standardów, lecz dostarcza dokum enty profilujące oraz narzędzia do testow ania zgodności rozwiązań z istniejącymi standardami. Zgodność ta jest w arunkiem niezbędnym w łaściw ego stopnia interoperacyjności.

•

Chociaż organizacje standaryzacyjne egzystują jako odrębne podm ioty, działają przy wsparciu i udziale reprezentantów przemysłu. W kład tych reprezentantów w opracow yw anie standardów m otyw ow any jest zarów no ich w łasnym interesem, jak i troską o w spólne dobro.

•

Niezm ierne w ażne jest dotrzym yw anie kroku opracow yw anym standardom , poniew aż dzięki temu

91

migracja w stronę SOA może zostać starannie zaplanow ana i lepiej przeprow adzona.

4 .3 . K o rze n ie SO A (S O A a tra d y c y jn e a rc h ite k tu ry ) Powracamy na oś czasu, by przyjrzeć się podstawowym różnicom między dawnymi platformami architektonicznymi a SOA. To porównanie jest o tyle interesujące, że poza wspomnianymi różni­ cami istnieją również cechy wspólne, które SOA przejęła od swych poprzedników.

UWAGA O m aw iam y tu kilka tradycyjnych architektur, o m ó w ien ie architektury SOA odkładam y je d n ak do ostatnich rozdziałów tej książki. M ożna w ięc bez uszczerbku dla zrozum ienia dalszej treści opuścić prezento w ane tu porów nanie — niezainteresowanych nim czytelników zapraszamy od razu do rozdziału 5.

4.3.1. Co znaczy „architektura"? Z każdym skonstruowanym kiedykolwiek kom puterowym rozwiązaniem automatyzacji związane jest nieodłącznie pojęcie jego architektury technologicznej. Fakt ten nie od zawsze był oczywisty: u zarania informatyki tworzone aplikacje były tak banalne w swej strukturze, iż mało kto skłonny był do wyodrębniania i definiowania ich architektury. Gdy pojawiły się aplikacje wielowarstwowe, stopień ich złożoności oraz różnorodność sposo­ bów ich budowania stwarzały wręcz konieczność sięgnięcia po pewne usystematyzowane podej­ ścia dające szansę uniknięcia potencjalnego chaosu. Projektanci i programiści odczuwali koniecz­ ność wyodrębnienia pewnych schematów strukturalnych aplikacji, stanowiących swego rodzaju szablony dla rozwiązań w najbliższej przyszłości. Szablony te były abstrakcyjne w swej naturze, lecz z naturalnych względów odzwierciedlały reguły, granice, uwarunkowania, wytyczne projek­ towe i kontekst technologiczny tworzonych na ich podstawie aplikacji. Tak właśnie narodziła się koncepcja architektury aplikacji. Architektura aplikacji Architektura aplikacji jest dla zespołu tworzącego aplikację tym, czym projekt budynku dla bu­ downiczych. Szczegółowa postać architektury aplikacji jest specyfiką konkretnego środowiska, ze­ społu projektantów, tradycji, kultury i tym podobnych: w niektórych przypadkach m a postać je­ dynie wysokopoziomowych wytycznych, w innych obfituje w różne detale — podstawowe modele danych, diagram y przepływu inform acji, koncepcję zabezpieczenia aplikacji czy relację z infra­ strukturą technologiczną.

92

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Nie jest niczym niezwykłym funkcjonowanie kilku różnych architektur aplikacji w jednej firmie: definicja konkretnej architektury pozostaje zazwyczaj w ścisłym związku z platformą program i­ styczną użytą do tworzenia aplikacji, tak więc na przykład architektura stanowiąca szablon dla aplikacji opartych na platformie .NET zazwyczaj różni się wyraźnie od architektury aplikacji two­ rzonych na bazie platform y J2EE. Cechą wspólną wszystkich architektur aplikacji jest fakt, że każda z nich odzwierciedla zarówno doraźne aspekty tworzenia aplikacji, jak i długofalowe cele strategiczne przyświecające tworzeniu i użytkowaniu tejże aplikacji. Jeśli więc w przedsiębiorstwie egzystuje kilka różnych architektur aplikacyjnych, te wspólne elementy umożliwiają zintegrowane spojrzenie na nie wszystkie, w ra­ mach nadrzędnej architektury zwanej powszechnie architekturą enterprise (enterprise to angielski odpowiednik „przedsiębiorstwa”). Architektura enterprise W dużych środowiskach IT zdolność zapanowania nad infrastrukturą IT i umiejętnego nią ste­ rowania jest czynnikiem krytycznym dla funkcjonowania firmy. Jeśli w firm ie tej współegzystuje kilka różnych architektur aplikacyjnych, być może w pewnym stopniu zintegrowanych, zarządza­ nie każdą z platform z osobna może być skomplikowane i uciążliwe. Pojawia się zapotrzebowanie na specyfikację wyższego rzędu, traktującą wysokopoziomowo całość heterogenicznej architektury, wraz z definicją implementującej tę architekturę infrastruktury. Przywołując poprzednią analogię: taka wysokopoziomowa architektura enterprise jest dla firmy tym, czym dla miast jest plan urbanistyczny. Taki plan ma się tak do schematu konstrukcyjnego budynku, jak właśnie architektura enterprise do każdej z architektur aplikacyjnych. Zazwyczaj zmiany w zakresie architektury enterprise bezpośrednio wpływają na postać po­ szczególnych architektur aplikacji; tłumaczy to, dlaczego najczęściej wszystkie architektury aplika­ cyjne w przedsiębiorstwie oraz jego architektura enterprise podlegają kontroli tej samej grupy osób. Ponadto częścią architektury enterprise są zwykle długoterminowe plany ewolucyjne środowiska IT i jego technologii, na przykład scenariusze przyszłego eliminowania przestarzałych technologii. Wreszcie, częścią architektury enterprise mogą być definicje polityki i technologii związanych z (rozumianym globalnie) bezpieczeństwem firmy, choć jednak zwykle są one wyodrębniane w po­ staci osobnej architektury — architektury bezpieczeństwa. Architektura zorientowana na usługi Architektura zorientowana na usługi, mówiąc po prostu, rozciąga się na obie dom eny — archi­ tekturę enterprise i architekturę aplikacji. Korzyści oferowane przez SOA widoczne są wyraźnie tylko wtedy, gdy zastosuje się SOA do środowiska obejmującego wiele rozwiązań, bo tylko wtedy inwestycje w tworzenie wieloużywalnych i interoperacyjnych usług, komunikujących się w sposób niezależny od konkretnego dostawcy, stają się w pełni opłacalne. Bo tylko wówczas m ożna naj­ więcej zyskać dzięki charakterystycznym cechom SOA. Zauważmy przy tym, że term in „SOA” niekoniecznie kojarzyć się musi z granicami konkret­ nej architektury: może odnosić się zarówno do architektury aplikacji, jak i podejścia używanego do standaryzacji architektury technicznej w przedsiębiorstwie. Ze względu na kompozycyjną na­ turę SOA (co oznacza, że każda architektura na poziomie aplikacji może stanowić kompozycję różnych rozszerzeń i technologii) jest całkiem możliwe, że w danej firmie rzeczownik „SOA” wy­ stępuje w liczbie m nogiej...

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

93

I jeszcze jedno: jak wyjaśnialiśmy w poprzednim rozdziale, platforma usług sieciowych jest tylko jedną z możliwych platform implementacyjnych dla SOA. I chociaż w tej książce ograniczamy się tylko do niej, nie m ożna zapominać, że w tej roli równie dobrze mogą spisywać się tradycyjne platformy przetwarzania rozproszonego. Jednakże — przypomnijmy — dalej w tej książce określenie „SOA” odnosić się będzie do implementacji współczesnej SOA, na bazie usług sieciowych, zgodnie z zasadami opisanymi w rozdziale 3.

4.3.2. SOA a architektura klient-serwer „Klient-serwer” — to określenie zadomowiło się już w informatyce i praktycznie oznacza dowolne środowisko, w którym jedna porcja aplikacji żąda informacji od innej części i (lub) informację tę samorzutnie otrzymuje1. I prawdę mówiąc, takiego elementu interakcji można dopatrzyć się w każ­ dej niemal architekturze aplikacji (nie wyłączając SOA). Jednakże obecnie w kręgach przemysłu informatycznego określenie „architektura klient-serwer” generalnie odnosi się do konkretnej ge­ neracji wczesnych środowisk, w których klient i serwer były realnymi, wyraźnie wyodrębnionymi, fizycznymi bytami o określonej implementacji i charakterystyce. Architektura klient-serwer — krótka historia Oryginalne monolityczne systemy mainframe, dzięki którym niegdysiejsze przedsiębiorstwa m o­ gły uważać się za „skomputeryzowane”, powszechnie uważane są za pierwsze wcielenie architek­ tury klient-serwer. Te środowiska, w których opasły kom puter (lub kilka komputerów) m ainfra­ me zaplecza świadczył swe usługi na rzecz prymitywnych („cienkich” — thin) klientów-terminali, formalnie określane są m ianem jednowarstwowej (single-tier) architektury klient-serwer (patrz rysunek 4.2). Systemy mainframe natywnie wykorzystywały komunikację zarówno synchroniczną, jak i asyn­ chroniczną. Komunikacja synchroniczna umożliwiała serwerowi natychmiastową reakcję na naci­ skanie klawiszy terminalu; gdy spełnione zostały określone warunki, serwer podejmował stosow­ ną akcję. Mimo iż systemy o tej strukturze znakomicie spełniały swe zadanie, ich blask począł przygasać pod koniec lat 80. ubiegłego wieku, kiedy to ujrzały światło dzienne systemy klient-serwer o archi­ tekturze dwuwarstwowej (two-tier). To nowe podejście wprowadzało koncepcję delegowania logiki aplikacji i reguł przetwarzania do poszczególnych stacji roboczych, które tym samym stawały się inteligentnymi („grubymi” — fat) klientami. Pojawienie się w tym czasie nowoczesnych, graficznych stacji roboczych i w ślad za tym graficznych interfejsów użytkownika (GUI — Graphical User Interfaces) oznaczało duży krok na­ przód i praktycznie zdominowało świat IT pierwszej połowy lat 90. ubiegłego wieku. Typowa konfiguracja takiego systemu obejmuje pewną liczbę „grubych” klientów, z których każdy posiada własne połączenie z bazą danych rezydującą na centralnym serwerze. Strona kliencka obarczona została całością przetwarzania związanego z prezentacją oraz główną częścią przetwa­ rzania związanego z dostępem do danych (patrz rysunek 4.3). Same dane zlokalizowane były na jednym serwerze lub kilku serwerach w postaci relacyjnych baz danych (RDBMs). 1 Jeśli konsum ent informacji („klient”) otrzym uje tę informację ze swej własnej inicjatywy (poprzez żądanie), m ów im y o transakcji „ciągnionej” (pull); gdy inform acja napływ a do konsum enta z inicjatywy jej p roducenta („serwera”), sytuację określam y m ianem transakcji „wypychanej” (push) — przyp. tłum.

94

RO ZDZIAŁ 4 . ■ EW OLUC JA SOA

Rysunek 4.2. Typowa jednowarstwowa architektura klient-serwer

Rysunek 4.3. Typowa dwuwarstwowa architektura klient-serwer

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

95

Przeanalizujmy więc poszczególne cechy dwuwarstwowej architektury klient-serwer i porów ­ najmy je z ich odpowiednikami na gruncie SOA. Logika aplikacyjna W dwuwarstwowym środowisku klient-serwer większość logiki aplikacji umiejscowiona jest po stronie klienckiej. Efektem tego jest monolityczny m oduł wykonywalny, odpowiedzialny zarówno za wrażenia użytkownika, jak i zasoby zaplecza. Pewnym wyjątkiem od tej reguły jest podział lo­ giki biznesowej: powszechną praktyką stała się realizacja tej logiki w obrębie serwera, za pomocą zestawu procedur składowanych (stored procedures) i wyzwalaczy (triggers). Dzięki tem u logika biznesowa została w pewnym sensie oddzielona od klienta, uprościł się też sposób program owa­ nia dostępu do danych2. Nie zmienia to jednak faktu, że to klient rozdaje karty w tej grze. W arstwa prezentacji rozwiązania zorientowanego na usługi może wyglądać rozmaicie: każdy kawałek oprogram ow ania zdolny wysyłać i odbierać kom unikaty SOAP zgodnie z kontraktem danej usługi może być traktow any jako wnioskodawca tej usługi. I choć zwykle oczekuje się, iż ów wnioskodawca też będzie usługą, projekt warstwy prezentacji jest kwestią całkowicie otwartą i zależną od specyfiki konkretnego rozwiązania. W środowisku serwera istnieją różne opcje umiejscowienia i rozpartycjonowania logiki apli­ kacji, a szczególnie nie jest wykluczone użycie procedur składowanych i wyzwalaczy. Zasady projektowania zorientowanego na usługi nakazują jednak podział logiki przetwarzania na auto­ nomiczne jednostki, z myślą o bezstanowości i interoperacyjności usług, a w przyszłości także ich komponowalności i wieloużywalności. Ponadto, zgodnie z zasadami SOA, konstrukcje wspomnianych jednostek powinny pozosta­ wać bez związku z konkretnym rozwiązaniem. Pomaga to w osiągnięciu ostatecznego celu, jakim jest wieloużywalność i luźne powiązanie przekraczające granice aplikacji. Przetwarzanie aplikacyjne Ponieważ większość aplikacji klient-serwer lokuje logikę aplikacji po stronie klienta, kliencka stacja robocza obarczona zostaje potężną porcją przetwarzania — przyjmuje się zwykle 80%, pozostałe 20% przypada na serwer bazy danych. Mimo iż to tylko 20%, właśnie baza danych często okazuje się wąskim gardłem przetwarzania. W dwuwarstwowej architekturze klient-serwer każdy klient utrzymuje osobne połączenie z bazą danych. Połączenie to m a zwykle charakter perm anentny — nawiązywane jest podczas logowania 1 trwa do zakończenia pracy aplikacji. Przy dużej liczbie takich połączeń serwer bazy danych za­ czyna się po prostu dusić, co po stronie klientów manifestuje się dużymi — często niedopuszczalnie dużymi — opóźnieniami. Co więcej, ponieważ klient odpowiedzialny jest za znakomitą większość przetwarzania, często potrzebuje w związku z tym znaczących zasobów. Aplikacje klienckie utrzymują pełnię informacji o swym stanie, konsumując w związku z tym duże porcje pamięci operacyjnej. Wynikające stąd obciążenie dla stacji roboczej może być tak wielkie, że równoległa praca na tej stacji innych apli­ kacji jest praktycznie wykluczona. 2 Dzięki procedurom składowanym, enkapsulującym poszczególne aspekty logiki biznesowej, klient mógł teraz nie tylko żądać od serwera udostępniania i modyfikowania poszczególnych rekordów bazy danych, lecz prowadzić z serwerem konwersację na wyższym poziomie inteligencji i żądać realizowania kompletnych transakcji. Wyzwalacze pełniły natom iast rolę strażników niedopuszczających do naruszenia integralności danych — przyp. tłum .

96

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Dla odmiany, na gruncie SOA przetwarzanie jest wysoce rozproszone. Każda usługa ma wy­ raźnie zakreślone granice funkcjonalne i wynikające stąd zapotrzebowanie na zasoby. Modelowa­ nie technicznej architektury zorientowanej na usługi daje dużą swobodę wyboru umiejscawiania i wdrażania usług. Rozwiązania klasy enterprise obejm ują wiele serwerów, z których każdy hostuje określony zestaw usług i wspom agającego oprogram ow ania m iddlew are. N a gruncie SOA nie m a mowy 0 stałym podziale przetwarzania: usługi m ogą być rozproszone stosownie do wielu czynników, z których kluczowym są wymogi i możliwości wydajnościowe. Komunikacja między usługą a jej wnioskodawcą może być synchroniczna albo asynchroniczna, co daje kolejne możliwości w zakresie optymalizacji przetwarzania (zwłaszcza gdy wykorzystywa­ ne są wzorce komunikacji asynchronicznej). Ponadto, plasując sporą porcję inteligencji w kom u­ nikatach (co elastycznie umożliwiają opcje zarządzania kontekstem), uwalniamy same usługi od utrzymywania informacji o stanie i tym samym redukujem y ich zapotrzebowanie na zasoby. Technologia Pojawienie się aplikacji klient-serwer stworzyło grunt dla języków 4. generacji, takich jak Visual Basic czy PowerBuilder. Oparte na nich środowiska programistyczne znakomicie wykorzystują m e­ chanizmy W indows, dostarczając możliwości budow ania bogatych graficznie, estetycznych i wy­ soce interaktywnych interfejsów użytkownika. Języki 3. generacji — takie jak C++ — wykorzy­ stywane są nadal, głównie tam, gdzie krytyczne okazują się względy wydajności. Po stronie zaplecza spotykamy natomiast niezawodne i elastyczne systemy relacyjnych baz danych, autorstwa znanych dostawców — takich jak Oracle, Informix, IBM, Sybase i Microsoft — zdolne efektywnie obsłu­ giwać wiele równoległych połączeń i udostępniające wygodne narzędzia do optymalizacji i adm i­ nistrowania. Zestaw technologii wykorzystywanych na potrzeby SOA nie zm ienił się zbytnio, choć — oczywiście — rozwinęły się same technologie: nowe wersje tych samych języków wciąż używane są do tworzenia usług sieciowych, a relacyjne bazy danych nie mają realnej alternatywy. Techno­ logiczny krajobraz SOA jest jednak zdecydowanie bardziej zróżnicowany w porównaniu z po­ przednikam i: oprócz standardowego zestawu dla usług sieciowych (z HTML, CSS i H TTP na czele), SOA narzuca nieodw ołalnie reprezentację danych w standardzie XML i kom unikaty w standardzie SOAP. I ta lista nie jest zamknięta, z definicji SOA otwarta jest na nowe standardy 1 technologie, szczególnie związane z usługami sieciowymi. Bezpieczeństwo Poza przechowywaniem danych, zarządzaniem danymi i implementowaniem logiki biznesowej za pomocą procedur składowanych i wyzwalaczy, kolejnym elementem architektury klient-serwer, który zwykle pozycjonowany jest na centralnym serwerze, są zabezpieczenia. Obecne systemy rela­ cyjnych baz danych zawierają mechanizmy zabezpieczające, w postaci (wbudowanego w model danych) zarządzania dostępem do danych w oparciu o konta, hasła i uprawnienia użytkowników oraz ich grup. Bezpieczeństwem aplikacji m ożna sterować także z poziom u strony klienckiej, szczególnie w sytuacji, gdy dany element zabezpieczenia dotyczy specyficznych reguł biznesowych związa­ nych z realizacją logiki aplikacji (na przykład z ograniczeniem dostępu do niektórych elementów interfejsu „zwykłym” użytkownikom). Niektóre elementy zabezpieczeń m ogą pochodzić wprost z systemu operacyjnego — takim elementem jest na przykład logowanie użytkownika Windows.

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

97

Tak się składa, że projektanci, zachwycając się wspaniałościami SOA, jednocześnie z zazdro­ ścią spoglądają wstecz na bezpieczeństwo systemów klient-serwer — tam było to proste: dostęp do danych korporacyjnych prowadził przez pojedynczy punkt uwierzytelniania przy nawiązywa­ niu pojedynczego połączenia klienta z serwerem. W rozproszonym świecie SOA jest to niewykonalne, zabezpieczenia stają się sprawą niezwykle skomplikowaną — tym bardziej, im więcej od nich za­ leży. Realizowane są przy użyciu różnych technologii, z których większość wykorzystuje framework WS-Security (o którym piszemy obszernie w rozdziałach 7. i 17.). Administrowanie Jednym z powodów, dla którego aplikacje klient-serwer odeszły praktycznie do lamusa historii IT, były coraz większe koszty i kłopoty z konserwacją aplikacji rozproszonych po licznych (idących niekiedy w setki, a nawet tysiące) stacjach klienckich. Ponieważ na każdej stacji klienckiej znaj­ dowała się kopia m odułów aplikacji, każda aktualizacja tych m odułów oznaczała czasochłonną wycieczkę administratora po stanowiskach klientów. A administrator też człowiek i może się mylić. Dodatkową trudność sprawiał fakt, że poszczególne stacje klienckie mogą pochodzić od róż­ nych producentów, mieć zróżnicowaną konfigurację i może być nawet tak, że każda stacja kliencka będzie dla adm inistratora osobną bajką. I wtedy adm inistrator dopiero mógł się pomylić. Zresztą, utrzymanie systemu klient-serwer to także utrzymanie serwera. To zapewnienie, by sprawował się efektywnie — a to, wobec rosnącej liczby klientów, złożoności aplikacji i rozmiarów danych było coraz trudniejsze. Rozwiązania zorientowane na usługi nie są całkowicie wolne od opisanych problemów. Ponie­ waż usługa może być w danej chwili wywoływana przez wielu wnioskodawców, może pojawić się znany problem z wydajnością. Oczywiście, serwery aplikacji i serwery bazodanowe praw dopo­ dobnie posiadają możliwość skalowania, ale w tym momencie pojawiają się nowe wyzwania ad­ ministracyjne. Przykładowo, gdy SOA wyewoluuje do stanu, w którym usługi staną się wieloużywalne i każda z nich będzie m ogła uczestniczyć w wielu kompozycjach, zarządzanie zasobami serwera i interfejsami usług wymagać będzie silnych narzędzi administracyjnych, w tym wykorzystywania prywatnych rejestrów usług. ANALIZA PRZYPADKU

System finansowo-księgowy firmy RailCo to klasyczna dwuwarstwowa aplikacja klient-serwer. Jej strona kliencka to pojedynczy plik wykonywalny, zaprojektowany do uruchamiania na star­ szych stacjach roboczych Windows. Aplikacja udostępnia interfejs umożliwiający wyszukiwanie, edytowanie i dodawanie rekordów reprezentujących zdarzenia istotne dla księgowości; aplikacja posiada także zamknięty zestaw różnych funkcji raportowania, szczegółowego i sumarycznego. Ponieważ nie zdarzało się, by aplikacja ta była używana równocześnie przez więcej niż dwóch-trzech użytkowników, nie zaobserwowano nigdy problemów z jej wydajnością. Nawet przestarzały system bazy danych, wykorzystywany od kilkunastu lat, okazał się niezawodny i wymagał niewielkich zabiegów konserwacyjnych. Jednak ten spokojny krajobraz ostatnio mącą pewne kłopoty. • Po kolejnych aktualizacjach systemu Windows niektóre ekrany aplikacji wyświetlane są nieprawidłowo, pojawiają się także zagadkowe komunikaty o błędach. Prawdopodobną tego przyczyną są inne programy zainstalowane na stacjach roboczych.

98

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

• Aktualizacja systemu W indows nie szła w parze z aktualizacjami sprzętowymi stacji roboczych — aktualizacjami wymaganymi przez nowe wersje oprogramowania. W rezultacie, gdy na stacji roboczej uruchom i się system finansowo-księgowy, pochłania on praktycznie wszystkie zasoby kom putera i użytkownik m a nikłą możliwość zrobienia na tym komputerze czegokolwiek innego. Nietrudno zgadnąć, że odbija się to ujemnie na produktywności pracowników. • Zgodnie z nową polityką zarządzania rekordami i wskutek zmian w procedurze bilansowania zmienił się ogólnie cały proces bilansowy. Ponieważ system finansowo-księgowy nie został zaprojektowany w sposób umożliwiający przystosowanie do tej zmiany, pracownicy stanęli przed koniecznością samodzielnego uzupełniania zautomatyzowanego procesu bilansowego i ręcznie wypełniają dodatkowe formularze. Generalnie opisywany system nadal poprawnie spełnia swe zadanie, jednakże dodatkowe czynności wykonywane przez pracowników są nużące, mechaniczne i mało efektywne, a przy tym podatne na błędy. Takie są koszty wątpliwej stabilności przestarzałej stacji roboczej i nieadaptowalności systemu do bieżących potrzeb. SOA jest w stanie rozwiązywać problem y tego rodzaju w następujący sposób. • W rozwiązaniu zorientowanym na usługi nie występuje uzależnienie działania aplikacji od specyfiki stacji klienckiej, ponieważ całość przetwarzania powierzona zostaje stronie serwerowej (tak jak w tradycyjnej rozproszonej architekturze internetowej). • SOA ustanawia adaptowalny i rozszerzalny model architektoniczny, pozwalający na rozbudowę istniejących rozwiązań przy m inim alnym wysiłku. Usługi mogą enkapsulować dotychczasową logikę aplikacji i udostępniać ją za pomocą standardowych interfejsów API, stanowiących m echanizm integrujący te usługi z większą całością. W spom niana adaptowalność i rozszerzalność są organicznie wbudowane w środowisko aplikacji od samych jej początków.

4.3.3. SOA a rozproszona architektura internetowa To porównanie może wydawać się nielogiczne, jako że SOA może być uważana za jedną z form internetowej architektury rozproszonej i vice versa — dawne typy architektur rozproszonych mogą być projektow ane na m odłę SOA. To praw da, ponadto istnieją dziś środowiska rozproszone w wysokim stopniu czyniące zadość zasadom zorientowania na usługi; tym niemniej takie właśnie odm iany SOA należą obecnie do rzadkości i, mówiąc o „rozproszonej architekturze internetow ej” w ramach niniejszej analizy porównawczej, m am y na myśli tę architekturę w takiej formie, w jakiej tradycyjnie była ona powszechnie projektowana. Rozproszona architektura internetowa — krótka historia Jako odpowiedź na kłopoty związane z utrzymaniem dwuwarstwowej architektury klient-serwer pojawiła się i szybko zyskała popularność koncepcja budowania aplikacji o strukturze kom po­ nentowej. Nowa, wielowarstwowa architektura klient-serwer przełamywała m onolit pliku wyko­ nywalnego w klienckiej stacji roboczej na rzecz zespołu kom ponentów zaprojektowanych mniej lub bardziej zgodnie z zasadam i program ow ania zorientowanego obiektowo (OOP — Object Oriented Programming).

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

99

Rozproszenie logiki aplikacji między kom ponenty (część z nich rezydowała na serwerze, część po stronie klienta) oznaczało uwolnienie od kłopotów wynikających ze skomasowania większości logiki na centralnym serwerze. Obecnie kom ponenty serwerowe, teraz umiejscowione na dedy­ kowanych serwerach aplikacji, przejm ują na siebie problem y łączności z bazą (bazami) danych, organizując zarządzanie pulami połączeń i uwalniając tym samym serwery bazodanowe od zm a­ sowanych strum ieni połączeń — w ram ach jednego połączenia m ożna teraz obsługiwać jednocze­ śnie wielu klientów (patrz rysunek 4.4).

Rysunek 4.4. Typowa wielowarstwowa architektura klient-serwer

Opisane korzyści m ają — oczywiście — swoją cenę: kłopoty nękające dotychczas wdrożeniowców przesunęły się teraz na twórców aplikacji. Konstruowanie kom ponentów zdolnych ob­ sługiwać równocześnie wiele nadchodzących żądań to sztuka dalece trudniejsza i bardziej najeżo­ na problem am i niż proste tworzenie monolitycznych m odułów wykonywalnych, przeznaczonych dla pojedynczych użytkowników. Dotychczasowe bezpośrednie połączenia stacji klienckich z serwerem bazy danych zastąpione zostały przez zdalne wywoływanie procedur (RPC — Remote Procedure Calls). Technologie re­ alizujące RPC, takie jak CORBA czy DCOM , realizowały odtąd kom unikację m iędzy kom po­ nentam i strony klienckiej a kom ponentam i zlokalizowanymi na serwerach. I pojawiły się znane problem y znane z architektury dwuwarstwowej, dotyczące zarządzania zasobami i perm anent­ nymi połączeniami, a ponadto zaistnienie dodatkowej warstwy (serwerów aplikacji i m onitorów transakcji) skomplikowało cały proces utrzymywania systemu.

100

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Gdy w połowie lat 90. ubiegłego wieku sieć W W W objawiła się jako potencjalne m edium ko­ munikacyjne, do obszaru środowisk wielowarstwowych wkroczyły technologie internetowe. Naj­ bardziej spektakularne tego przejawy zaobserwować m ożna było po stronie klienckiej: dedyko­ wane kom ponenty klienckie wyparte zostały przez uniwersalne przeglądarki W W W . Teraz już 100% przetwarzania odbywało się po stronie serwerów, za to projektowanie interfejsów użytkownika uprościło się znacząco, choć jednocześnie wtłoczone zostało w ramy ograniczeń wynikających z natu­ ralnych cech przeglądarek W W W i języka HTML (patrz rysunek 4.5). Po epokach klienta „cienkiego” i klienta „grubego” nastała era klienta prymitywnego („głupiego” lub „niemego” — dumb).

Rysunek 4.5. Typowa rozproszona architektura internetowa

Rozproszona architektura internetowa wprowadza nową warstwę fizyczną, czyli serwer WWW, a w konsekwencji własnościowe protokoły RPC, wykorzystywane uprzednio do komunikacji między klientami a serwerem, zastąpione zostają przez protokół HTTP. Rola RPC zredukowana zostaje do komunikacji zdalnego serwera W W W z serwerami aplikacji. W okresie od schyłku lat 90. ubiegłego wieku do pierwszych lat wieku obecnego rozproszone architektury internetow e były platform ą de facto dla budow anych rozwiązań korporacyjnych. Upowszechnienie kwalifikacji programistycznych w zakresie tworzenia aplikacji kom ponento­ wych oraz coraz bardziej wyrafinowane oprogramowanie middleware spowodowały, że stosun­ kowo duża złożoność takich aplikacji (w porów naniu z niedawnymi jeszcze monolitami) prze­ stała być znaczącym problemem. Jak więc ma się do SOA ta popularna i znajom a architektura? Na to pytanie odpowiemy szczegółowo w kolejnych punktach.

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

101

UW AGA M im o iż w ielow arstw ow a architektura jest realnym modelem , rządzącym się dobrze określonymi regułami, nie przedstaw im y jej porów nania z SOA, poniew aż porów nanie takie w yeksponow ałoby jedynie te jej cechy, które w idoczne są już w jej porównaniu z rozproszoną architekturą internetow ą.

Logika aplikacyjna Jeżeli nie brać pod uwagę tych rzadkich i nietypowych aplikacji, które wbudowują własne niety­ powe rozszerzenia w przeglądarki W W W , śmiało m ożna stwierdzić, że rozproszone aplikacje in­ ternetowe lokują całość swej logiki przetwarzania po stronie serwerowej. Nawet skrypty klienckie, przeznaczone do urucham iania w reakcji na określone zdarzenia zachodzące w obrębie stron W W W , pobierane są z serwera w odpowiedzi na inicjalne żądanie HTTP. Przyjrzyjmy się zatem dokładniej temu: • jak powinno się rozdzielić logikę aplikacji, • gdzie powinny rezydować jednostki logiki przetwarzania, • jak jednostki logiki przetwarzania pow inny współdziałać ze sobą. Z fizycznego punktu widzenia, architektura zorientowana na usługi jest bardzo podobna do rozproszonej architektury internetowej: logika dostarczyciela rezyduje po stronie serwerowej, po­ dzielona na rozłączne jednostki. Różnica między tymi dwiema architekturami sprowadza się do zasad regulujących trzy wymienione powyżej kwestie. Tradycyjna aplikacja rozproszona składa się z kom ponentów rezydujących na jednym serwe­ rze lub kilku serwerach aplikacji. Projektowanie tych kom ponentów może odbywać się na róż­ nym stopniu granulacji funkcjonalności, zależnie od powierzonych im zadań i stopnia oczekiwa­ nej wieloużywalności. K om ponenty rezydujące na tym samym serwerze kom unikują się zarówno poprzez specyficzne API, jak i swe publiczne interfejsy; komunikacja przekraczająca granice ser­ werów realizowana jest za pośrednictwem protokołów RPC, każdy zdalny kom ponent reprezen­ towany jest przez swą namiastkę (proxy stub) (patrz rysunek 4.6).

Rysunek 4.6. W komunikacji przekraczającej granicę serwera każdy zdalny komponent reprezentowany jest przez swą namiastkę

102

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Oczekiwana interakcja między kom ponentam i brana jest pod uwagę już w fazie ich projekto­ wania — odwołania danego kom ponentu do innych kom ponentów zostają „zaszyte na sztywno” w kodzie aplikacji. Między komponentami powstaje więc ścisłe powiązanie (tight coupling), dzięki czemu w trakcie działania aplikacji nie traci się czasu na lokalizację kom ponentu docelowego, ale też z powodu czego utworzona sieć kom ponentów, gdy zaimplementowana, bardzo trudno pod­ daje się zmianom. Współczesna SOA również wykorzystuje kom ponenty i jest od nich zależna, jednakże zasady modelowania nakazują tworzenie usług enkapsulujących te komponenty. Zgodnie z zasadami zo­ rientowania na usługi, podział kom ponentów między usługi powinien być dokonany w taki spo­ sób, by każda usługa reprezentowała pewien aspekt funkcjonalny aplikacji. Elementami enkapsulowanymi w usłudze mogą zresztą być nie tylko kom ponenty obiektowe; funkcjonalność usługi może mieć także inne źródła, na przykład „opakowane” w odpowiednie adaptery „luźne” fragmenty kodu, pakiety oprogram owania czy nawet kompletne bazy danych. Celem opakowywania funkcjonalności w ram y usługi jest wyeksponowanie tej funkcjonalno­ ści poprzez otwarty, standardowy interfejs, niezależny od technologii używanych do zaimple­ mentowania wewnętrznej logiki. Taki standardowy interfejs jest narzędziem otwartej komunikacji, leżącej u podstaw SOA. Ponadto wykorzystywanie usług sieciowych stwarza środowisko luźno po­ wiązanych encji, co jest wyraźnym kontrastem do ścisłego powiązania kom ponentów w ramach tradycyjnych aplikacji rozproszonych. Luźno powiązane usługi, gdy są właściwie zaprojektowane, realizują model kompozycyjny, umożliwiający poszczególnym usługom uczestnictwo w agrego­ wanych zestawach. To z kolei stwarza okazję do wieloużywalności i rozszerzalności usług. Inną znaczącą różnicą SOA w stosunku do tradycyjnych aplikacji rozproszonych jest sposób wymieniania inform acji między usługami. Podczas gdy tradycyjne kom ponenty posługują się wywołaniami metod połączonymi z przekazywaniem parametrów, usługi sieciowe wymieniają informację za pomocą komunikatów SOAP. I chociaż SOAP może obsługiwać komunikaty o struktu­ rze typowej dla RPC, większość zorientowanych usługowo usług sieciowych projektuje się na bazie kom unikatów w stylu dokumentowym (tę istotną różnicę wyjaśniamy dokładniej w następnych rozdziałach). Ponadto same kom unikaty projektowane są tak, by były samowystarczalne. Nagłówki SOAP umożliwiają kojarzenie treścią kom unikatów różnorodnych metainformacji, instrukcji przetwa­ rzania czy reguł polityki. W porów naniu z wymianą danych w tradycyjnym, czysto kom ponen­ towym świecie, framework komunikacyjny SOA jest bardziej wyrafinowany, komunikaty mają znacznie większą objętość i wymieniane są w ram ach mniejszej liczby transmisji. Wreszcie — mimo iż w tradycyjnych aplikacjach wieloużywalność kom ponentów jest doce­ nianą i zalecaną cechą, dla SOA jest ona jednym z fundam entów , obok interoperacyjności usług i ich projektowania w oderwaniu od konkretnych rozwiązań. Przetwarzanie aplikacyjne Niezależnie od platformy, to kom ponenty reprezentują lwią część logiki aplikacji i to one ponoszą główny ciężar wykonywanego przez tę aplikację przetwarzania. Technologie używane do kom u­ nikowania się przez usługi SOA różnią się zasadniczo od tradycyjnych technologii komunikacyjnych aplikacji rozproszonych, także pod względem rozm iaru przetwarzanej informacji.

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

103

W dawnych aplikacjach rozproszonych komunikacja między kom ponentam i realizowana była za pomocą własnościowych protokołów w rodzaju DCOM oraz różnych implementacji archi­ tektury CORBA. M imo iż owe technologie również stawiały przed projektantam i niebagatelne wyzwania, uznawane były za względnie stabilne i efektywne, przynajmniej w zakresie funkcjonowa­ nia na już ustanowionym połączeniu. Komunikujące się komponenty mogły mieć charakter stano­ wy lub bezstanowy i komunikowały się przeważnie synchronicznie (komunikacja asynchroniczna, choć udostępniana przez niektóre platformy, nie była jednak powszechnie wykorzystywana). SOA, dla odmiany, posługuje się komunikatami SOAP, przenoszącymi dane użyteczne w for­ macie XML. Przetwarzanie takich kom unikatów wymaga najpierw konwersji („serializacji”) da­ nych z natywnego formatu do formatu XML, później przesłania komunikatu i przywrócenia danym („deserializacji”) pierwotnego formatu; dodatkowo transmitowany dokument XML podlega dwu­ krotnej walidacji — przed wysłaniem i po dotarciu do miejsca przeznaczenia. Komputery mają więc co robić i choć to pracochłonne przetwarzanie wspomagane jest przez różnego rodzaju parsery — także sprzętowe — nadal w większości aplikacji kom unikacja RPC jest wyraźnie szybsza niż w SOAP. Ponieważ w sieci serwerów SOA komunikacja RPC z reguły m a zostać wyparta przez mecha­ nizmy komunikacyjne oparte na zasadach orientacji na usługi, narzut związany z przetwarzaniem kom unikatów SOAP stanowi dla projektantów nie lada wyzwanie. Konwencje modelowania do­ kumentów i komunikatów oraz strategiczne umiejscowienie logiki walidacyjnej to główne czynniki decydujące o kształcie warstwy transportowej w architekturze zorientowanej na usługi. Framework komunikacyjny SOA sprzyja tworzeniu autonomicznych usług, wykorzystujących rozmaite wzorce wymiany komunikatów. Mimo pełnego wsparcia tego frameworku dla kom uni­ kacji synchronicznej, zaleca się raczej transmisję asynchroniczną, bo ta z reguły zadowala się mniej intensywną wymianą kom unikatów i jako taka stwarza większe możliwości w zakresie optymali­ zacji przetwarzania. Uzyskanie bezstanowego charakteru usług umożliwiają różne opcje zarządzania kontekstem , między innym i specyfikacje W S-Coordination i WS-BPEL oraz inne specyficzne, tworzone ad hoc narzędzia. Technologia Technologie kryjące się za rozproszoną architekturą internetową przeszły kilka stadiów przeobra­ żeń w ciągu kilku ostatnich lat. Początkowo elementami takiej architektury były kom ponenty, skrypty serwerowe i „surowe” narzędzia, z językiem HTML i protokołem HTTP na czele. Uspraw­ nienie program owania middleware pozwoliło na zwiększenie efektywności obliczeniowej i zaim­ plementowanie niepodzielnych transakcji. Dzięki upowszechnieniu XML m ożna było tworzyć wykoncypowane reprezentacje danych, formowanych w obszerne dokum enty transmitowane za pośrednictwem protokołów internetowych. Pojawienie się usług sieciowych pozwoliło aplikacjom rozproszonym wyjść poza ram y własnościowych platform. W rezultacie wiele obecnych aplikacji rozproszonych wykorzystuje zarówno XML, jak i usługi sieciowe, więc kryjące się za nimi technologie niewiele różnią się od wykorzystywanych przez SOA. Z tą jednak różnicą, że o ile w przypadku tradycyjnych aplikacji rozproszonych XML i usługi sie­ ciowe były atrakcyjnymi opcjami, dla współczesnej SOA są one technologiami fundamentalnymi.

104

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

Bezpieczeństwo Gdy logika aplikacji porozrzucana jest na wiele fizycznych obszarów, zaimplementowanie choćby tylko fundam entalnych środków bezpieczeństwa — uwierzytelniania i autoryzacji — staje się dość trudne. W w arunkach dwuwarstwowej architektury klient-serw er dedykowane połączenie klienta z serwerem bardzo prosto załatwiało kwestię identyfikacji użytkowników i bezpieczeństwa trans­ portu danych korporacyjnych. Gdy jednak pojawiły się serwery aplikacji, a ich połączenia z ser­ werem (serwerami) baz danych straciły swą ekskluzywną relację „jeden do jednego” z użytkowni­ kami, zaś „wrażliwe” dane zmuszone były odbywać swą wędrówkę przez wiele fizycznych warstw, trzeba było podejście do bezpieczeństw a gruntow nie zrewidować. Aby zapew nić bezpieczny transport informacji i rozpoznawanie poświadczeń (credentials) użytkowników, przy jednocze­ snym zachowaniu oryginalnego kontekstu zabezpieczeń, tradycyjne architektury bezpieczeństwa stosują podejścia w rodzaju delegowania i uosabiania (impersonation). Ponadto dla ochrony treści i integralności informacji poza granicami serwera w czasie transportu za pomocą otwartego przecież protokołu HTTP szyfruje się tę informację. SOA całkowicie zrywa z tym modelem, traktując problematykę zabezpieczeń w sposób nieja­ ko hurtowy. W oparciu o rozszerzenia i koncepcje frameworku WS-Security model zabezpieczeń wykorzystywany w ram ach SOA plasuje logikę bezpieczeństwa na poziomie komunikatów. Komu­ nikaty SOAP udostępniają bloki nagłówków realizujące tę logikę: z każdym przesyłanym kom u­ nikatem wędruje nieodłącznie informacja związana z jego zabezpieczeniem. Takie rozwiązanie jest konieczne do zachowania autonom ii poszczególnych usług i luźnego ich powiązania, jak również do tego, by usługi pozostały bezstanowe. Administrowanie Utrzymywanie aplikacji bazującej na kom ponentach wiąże się z koniecznością kontrolowania po­ szczególnych instancji kom ponentów , śledzenia problem ów związanych z komunikacją (lokalną i zdalną), m onitorow ania zapotrzebowania na zasoby serwera i — oczywiście — administrowania bazą (bazami) danych. W rozproszonej architekturze internetowej listę tę uzupełnia obsługa ser­ wera W W W i generalnie nadzorowanie funkcjonowania związanej z nim warstwy fizycznej. Dla klientów — zarówno tych wewnątrz firmy, jak i zewnętrznych — oficjalnym punktem pierwszego kontaktu jest serwer W W W , z którym łączą się za pom ocą protokołu HTTP. Serwer ten musi więc być zaprojektowany z możliwością skalowania — to wymaganie realizowane jest przez kon­ struowanie farm serwerowych, wyposażonych w funkcje zarządzania pulami zasobów. W architekturze SOA na poziomie enterprise dochodzą do tego wysiłki związane z kontrolo­ waniem działania frameworku komunikacyjnego. Problemy w jego działaniu, zwłaszcza przy ko­ munikacji asynchronicznej, łatwiej mogą pozostać niezauważone niż w przypadku RPC; wynika to przede wszystkim ze znacznie większej liczby potencjalnych kombinacji nakładania się kom u­ nikatów w czasie. W komunikacji RPC wysłanie komunikatu do komponentu docelowego jest zwy­ kle powiązane z oczekiwaniem na odpowiedź tegoż dotyczącą przetworzenia otrzymanego kom u­ nikatu: brak odpowiedzi w założonym czasie lub odpowiedź sygnalizująca błąd traktowane są jako sytuacje awaryjne i powodują wywołanie procedury obsługi wyjątku. W komunikacyjnym frameworku SOA obsługa wyjątków jest znacznie bardziej skomplikowana i mniej niezawodna: jakkolwiek rozszerzenia WS-* zaprojektowane zostały w sposób uwzględniający występowanie sytuacji wyjąt­ kowych, jednakże zachowanie stabilności działania systemu wciąż wymaga udziału administratora.

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

105

Od adm inistratora oczekuje się jeszcze wykonywania innych zadań, między innym i zarządza­ nia zasobami systemu (podobnie do zarządzania komponentami). Jednak, aby osiągnąć wyższy poziom wieloużywalności i komponowalności usług w przedsiębiorstwie wykorzystującym duże zestawy usług sieciowych, użyteczną częścią infrastruktury administracyjnej powinno być repo­ zytorium stanowiące prywatny rejestr usług. UDDI to jedna z technologii używanych do standa­ ryzacji takich repozytoriów, umożliwiająca odnajdywanie opisów usług — w sposób ręczny lub programowy. ANALIZA PRZYPADKU

System księgowy firmy TLS to duża aplikacja bazująca na komponentach. Logika aplikacji podzielona jest między ponad 50 komponentów, z których wybrane zainstalowano (ze wzglę­ dów wydajnościowych lub dla większego bezpieczeństwa) na osobnych serwerach aplikacji. Ogólnie, realizacja typowego zadania księgowego obejmuje cztery - pięć następujących warstw fizycznych, składających się z: • serwera W W W hostującego skrypty, przekazującego klienckie żądania HTTP do kom ponentów na serwerach aplikacji oraz przesyłającego klientom informację zwrotną na podstawie odpowiedzi otrzymanych od wspomnianych komponentów; • serwera aplikacji hostującego kom ponenty kontrolera generującego kontekst transakcji i zarządzającego kom ponentam i bardziej specjalizowanymi; • opcjonalnie — drugiego serwera aplikacji hostującego kilka komponentów biznesowych, wymuszających reguły biznesowe i spełniających różne funkcje specyficzne dla konkretnego kontekstu biznesowego, serwer ten może hostować także kom ponenty enkapsulujące logikę dostępu do danych, używane do komunikacji z różnymi repozytoriami aplikacyjnymi; • serwera bazy danych, hostującego kompletne środowisko relacyjnej bazy danych (RDBMS). System ten przez kilka ostatnich lat był wiele razy zmieniany i rozszerzany — oto niektóre jego zmiany i rozszerzenia: • Początkowo wiele kom ponentów było owocem doraźnych zabiegów, mających na celu modyfikację lub wzbogacanie istniejącej funkcjonalności. Dodanie każdego nowego kom ponentu było kosztownym przedsięwzięciem — przede wszystkim należało się upewnić, że nowe elementy nie powodują zachwiania dotychczasowej stabilności, a to wymagało olbrzymich inwestycji w testowanie i uciążliwe wdrażanie. • Zarządzanie informacją o stanie kom ponentów nigdy nie było zestandaryzowane: niektóre cache’owały te informacje w pamięci, inne w bazach danych zlokalizowanych na serwerach aplikacji. Okazało się to poważnym problemem przy pierwszej próbie przejścia na form at XML jako standardowy dla wszystkich danych: format informacji o stanie, charakterystyczny dla relacyjnej bazy danych był nie do pogodzenia z wymaganą strukturą dokum entów XML.

106

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

W następnych rozdziałach wyjaśnimy, w jaki sposób zasady SOA ułatwiają niwelowanie opisanych problemów. Tu podajemy je w skrócie. • Luźne powiązania między jednostkami logiki przetwarzania i zamknięcie określonej porcji tej logiki w granicach konkretnej usługi sprawia, że każda z usług może ewoluować niezależnie od pozostałych i bez wpływu na nie (lub przy minimalnym wpływie). Szczególnie zmiany zamykające się w granicach usługi pozostają niezauważalne dla jej wnioskodawców tak długo, jak długo zachowany zostaje oryginalny kontrakt (interfejs) tej usługi. • Reprezentacja danych w formacie XML jest na gruncie SOA wymaganiem fundam entalnym , a bezstanowość usług realizowana jest poprzez przeniesienie informacji o stanie na poziom komunikatów. Maksymalizuje to wieloużywalność, dostępność i skalowalność logiki usług i jednocześnie dostarcza zestandaryzowane podejście do zarządzania informacją o stanie przetwarzania.

4.3.4. SOA a hybrydowa architektura usług sieciowych W poprzednim punkcie opisywaliśmy rozproszoną architekturę internetową, na grunt której przeniknęły technologie usług sieciowych. Tej nowoczesnej odmianie architektury rozproszonej warto poświęcić trochę więcej uwagi z tego względu, iż często jest (i pewnie jeszcze długo będzie) najczęstszym obiektem nieporozum ień związanych z SOA. Po pierwsze, wykorzystywanie usług sieciowych w ramach tradycyjnych architektur jest zjawiskiem całkiem naturalnym. Wsparcie popularnych środowisk programistycznych dla tworzenia usług sie­ ciowych powoduje, że ułatwione jest przystosowywanie aplikacji zaprojektowanych tradycyjnie do tej nowej technologii, zaś dla aplikacji zbudowanych w środowiskach pozbawionych takiego wspar­ cia często dostępne są odpowiednie adaptery przystosowujące tradycyjne projekty do nowych realiów.

UWAGA Koncentrujemy się w tym miejscu na rozproszonej architekturze internetow ej, nic jednak nie stoi na prze­ szkodzie, by w zbogacić o usługi sieciowe także dw uw arstw o w ą architekturę klient-serwer.

Usługi sieciowe jako otoczki komponentów Podstawową rolą usług sieciowych w opisanym kontekście jest utworzenie warstwy integracyjnej, obudowującej zestawy kom ponentów w ram y usług i umożliwiającej synchroniczne kom uniko­ wanie się tych usług ze światem zewnętrznym poprzez zgodny z SOAP kanał integracyjny (patrz rysunek 4.7). W arto w tym miejscu nadm ienić, że początkowa wersja specyfikacji SOAP defi­ niowała tę kom unikację jako odm ianę tradycyjnego stylu kom unikacji RPC, zrealizowaną teraz w oparciu o standardow e kom unikaty3, i pierwsza generacja serwerów SOAP zaprojektowana została stosownie do tej definicji. 3 Tak się dziwnie składa, że dwie różne koncepcje, wyrażające się angielskimi słowami message i communication, przekładają się w języku polskim na dwa podobne słowa (odpowiednio) „kom unikat” i „kom unikacja”. W sfor­ m ułow aniu „kom unikacja w oparciu o kom unikaty” nie m am y więc do czynienia z synonim am i ani pleonazmem: kom unikaty nie są jedynym środkiem komunikowania się, wszak istnieją jeszcze wyzwalacze (triggers),

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

Aplikacja rozproszona A

107

Aplikacja rozproszona 8

Rysunek 4.7. Usługi sieciowe jako otoczki dla komponentów

W spom niane kanały integracyjne wykorzystywane były przede wszystkim w architekturach integracyjnych, ułatwiając komunikację aplikacji z innymi aplikacjami lub partneram i zewnętrz­ nymi — a także z innym i rozwiązaniami, w dużym stopniu zorientowanymi na usługi, oraz nie­ zależnymi narzędziami blisko związanymi z usługami sieciowymi. Bez względu jednak na to, jak intensywnie tradycyjna architektura rozproszona sięga po usługi sieciowe i wynikające z nich profity, nie może być automatycznie uważana jako „realna SOA” — jest ona jedynie architekturą rozproszoną wzbogaconą o usługi. SOA idzie znacznie dalej. Zamiast jedynie odzwierciedlania (często po prostu: dublowania) interfejsów enkapsulowanych kom ponentów w ram ach interfejsów usług-otoczek oraz ustana­ wiania komunikacji typu punkt-punkt między usługami-otoczkami, SOA dostarcza solidne wspar­ cie dla różnorodnych modeli kom unikatów (zarówno synchronicznych, jak i asynchronicznych), ponadto same usługi projektow ane są w sposób bardziej rygorystyczny, zgodnie z zasadam i, o których pisaliśmy w rozdziale 3. Te i inne cechy SOA pomagają w osiągnięciu systematycznie luźnego powiązania między usługami, dzięki czemu usługi te nie są już ograniczone do kom uni­ kacji punkt-punkt, lecz mogą być przystosowane do równoczesnej obsługi wielu wnioskodawców. Usługi sieciowe w ramach SOA Niezależnie od tego, jak rozległa, i jak dalece zaawansowana jest im plem entacja SOA, istnieją uchwytne jej cechy charakterystyczne, wyraźnie odróżniające ją od innych architektur wykorzy­ stujących usługi sieciowe. Tem u obszernem u zagadnieniu pośw ięcona jest większa część tej

aktywne przepytywanie (polling), asynchroniczne przerwania (interrupts), że ograniczę się do najczęściej spo­ tykanych. Kom unikacja przy użyciu kom unikatów określana jest w języku angielskim przez pojedyncze słowo messaging, nieprzekładające się lakonicznie na język polski, a używane dość często z racji tego, że taka właśnie kom unikacja jest jednym z fundam entów SOA. Proszę więc czytelników, by pamiętali o tym, napotykając dalej w tej książce podobne sform ułowania — przyp. tłum.

108

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

książki; tu ograniczymy się do stwierdzenia, że SOA budowana jest na bazie usług sieciowych — zaprojektowanych w celu wspólnego automatyzowania (albo uczestnictwa w zautomatyzowaniu) jednego lub kilku procesów biznesowych — i że usługi te zorganizowane są w specjalizowane warstwy abstrakcji reprezentujące poszczególne elementy logiki automatyzacji. Ponadto standaryzacja SOA w skali całego przedsiębiorstwa przyczynia się do osiągnięcia interoperacyjności, sięgającej także własnościowych platform aplikacyjnych. Dzięki tem u różne śro­ dowiska działające uprzednio w izolacji od siebie stają się składnikami kompozycji zmierzającej w kierunku nowych i ewoluujących procesów automatyzacji biznesu. ANALIZA PRZYPADKU

Firma TLS wykorzystuje pewną liczbę specjalizowanych aplikacji e-biznesu, wykonanych na zasadzie outsourcingu przez kilka firm konsultingowych. Przy każdym z tak realizowanych projektów firm a TLS uzyskiwała zapewnienie, że aplikacja wykonana zostanie przy użyciu najnowszych technologii — szczególnie standardu XML i usług sieciowych, tak więc te spe­ cjalizowane aplikacje określane były m ianem „zorientowanych na usługi”. Pewnego dnia informatycy z firmy TLS stwierdzili, że dobrze byłoby zintegrować ze sobą dwie spośród wspom nianych aplikacji. Analiza obu aplikacji wykazała alarmujący poziom ich niespójności pod względem reprezentowania danych korporacyjnych i zarządzania nimi oraz pod względem form atu kom unikatów przenoszących te dane. Aby osiągnąć poziom interoperacyjności umożliwiający współdziałanie rzeczonych aplikacji, konieczne było urucho­ mienie złożonego i kosztownego projektu integracyjnego. Uczestnicy tego projektu nie kryli zdziwienia, że komunikacja między dwoma systemami bazującymi na tych samych technolo­ giach może stanowić tak monumentalny problem. I coraz wyraźniej zdawali sobie sprawę z faktu, że niezależnie od zastosowanych technologii każda aplikacja organizowała zarządzanie danymi na swój specyficzny sposób, optymalny w stosunku do własnych potrzeb — konsekwentne używanie standardu XML nie przeszkadzało temu, że każda z aplikacji stosowała formatowanie danych specyficzne do swego kontekstu. Usługi sieciowe, choć skwapliwie wykorzystywane, nie stanowiły jednak głównego trzonu architektury żadnej z aplikacji. Owszem, czyniły one zadość pewnym specyficznym wymaganiom, ich projektanci nie zapewnili im jednak jednej z kluczowych cech — interoperacyjności. Nie zapewnili, bo nie mieli takiego obowiązku, przecież każda z aplikacji z osobna speł­ niała bez zarzutu wszystkie funkcje, jakich zażyczył sobie zamawiający (firma TLS). Przy pro­ jektowaniu w ogóle nie zastosowano reguł SOA zapewniających implementacje XML i usług sieciowych w sposób zestandaryzowany, eliminujący a priori niekompatybilność będącą jedną z przyczyn poważnych problemów.

4.3.5. Orientacja na usługi oraz orientacja na obiekty (część I) Zwróćm y uwagę na spójnik w tytule: „Orientacja na usługi oraz orientacja na obiekty”, a nie „Orientacja na usługi kontra orientacja na obiekty”. To rozróżnienie m a akcentować fakt, że te dwie szkoły niekoniecznie muszą być postrzegane jako przeciwstawne.

4 .3 . KORZENIE SO A (S O A A TRADYCYJNE A RCHITEKTURY)

109

I rzeczywiście, programowanie zorientowane obiektowo jest powszechnie używane do budo­ wania logiki aplikacji enkapsulowanej wewnątrz usług sieciowych. W arto jednak zwrócić uwagę na kilka istotnych różnic między zorientowaniem na obiekty a zorientowaniem na usługi; paradok­ salnie, zrozumienie tych różnic może okazać się pom ocne w dziele pogodzenia obu tych technik. Zestawiamy poniżej krótką listę wspomnianych różnic. Ponieważ zorientowanie na usługi jest pewną koncepcją projektowania usług, zaś istotą orientacji obiektowej jest tworzenie obiektów, by uniknąć nieporozumień, będziemy encje obu tych dom en — usługi i obiekty — określać mianem „jednostek logiki przetwarzania”. • Zorientowanie na usługi propaguje luźne powiązanie między jednostkami logiki (usługami). Mimo iż orientacja obiektowa także propaguje tworzenie wieloużywalnych, luźno powiązanych jednostek logiki (klas i obiektów), zależności między klasami (wynikające z dziedziczenia i polimorfizmu) wiążą te jednostki w sposób bardziej ścisły. • Zorientowanie na usługi zaleca używanie „gruboziarnistych” interfejsów (opisów usług), wskutek czego każda jednostka komunikacyjna (komunikat) zawiera jak najwięcej informacji potrzebnych do wykonania określonego zadania. Dla odmiany, orientacja obiektowa posługuje się raczej „drobnoziarnistym i” interfejsami programisty (API) i jednostki kom unikacji (którym i są wywołania lokalne i wywołania RPC) m ogą dotyczyć zadań o zróżnicow anej złożoności. • Zorientow anie na usługi nie narzuca żadnych wymogów (ani zaleceń) dotyczących obszaru i zakresu jednostki logiki (usługi), natom iast orientacja obiektowa charakteryzuje się tendencją do tw orzenia mniejszych i bardziej skoncentrow anych jednostek logiki (klas i obiektów). • Usługi, tworzone zgodnie z zasadami orientacji na usługi, są jednostkami logiki nieświadom ym i swego rzeczywistego zastosowania — kontaktują się z otoczeniem jedynie za pośrednictw em kom unikatów . Jedną z idei orientacji obiektowej jest natom iast wiązanie jednostek logiki przetw arzania (metod) z danym i podlegającymi przetw arzaniu (atrybutam i) — tak właśnie formowane są klasy. • Zasady SOA wymagają zachowania bezstanowości projektowanych jednostek logicznych (usług) w takim stopniu, jak tylko to możliwe. Jednostki logiczne orientacji obiektowej (obiekty) przechowują zwykle sporą inform ację o stanie w swych atrybutach; należy jednak zauważyć, że ostatnio projekty aplikacji kom ponentow ych zdają się odchodzić od tej tendencji. • Na gruncie SOA luźne powiązanie jednostek logicznych (usług) stwarza całkowitą swobodę w łączeniu ich w kompozycje. O rientacja obiektowa także umożliwia kom ponow anie jednostek logicznych (obiektów), lecz jego charakter wyznaczony jest zwykle przez relację dziedziczenia między klasami. Nie omawialiśmy tu konkretnych zasad orientacji obiektowej — enkapsulacji, dziedziczenia i agregacji. Ponieważ nie opisaliśmy jeszcze w pełni zasad orientacji na usługi, nie możemy na tym poziomie porównać paradygmatów obu domen. W rozdziale 8. wyjaśnimy najpierw szczegółowo znaczenie poszczególnych zasad orientacji na usługi, po czym porów nam y je z paradygm atam i orientacji obiektowej.

110

RO ZD ZIAŁ 4 . ■ EW OLUCJA SOA

PODSUMOW ANIE •

SOA stanowi w yraz radykalnego zerwania z architekturą klient-serwer. Co prawda, współczesna SOA wciąż korzysta z niektórych technologii oryginalnie stosowanych do budow ania aplikacji typu klient-serwer, jednakże SOA, jako technologia bardziej w yrafinow ana, wyraźnie kontrastuje z prostotą dw uw arstw ow ej architektury klient-serwer.

•

Rozproszona architektura internetow a ma w iele elem entów wspólnych z SOA, głów nie pod w zględem technologicznym. SOA jednak rządzi się bardziej rygorystycznymi zasadami projektow ania, przetwarzania i bezpieczeństwa, zaś w ym iana informacji oparta na komunikatach sprawia, że proces adm inistrow ania serwerami i stacjami roboczymi jest bardziej złożony.

•

Tradycyjne architektury także korzystały z usług sieciowych, zgodnie ze swymi własnymi paradygm atami, co stanow i przyczynek do mylenia tychże architektur z SOA; tym czasem w spom nianym paradygm atom daleko do zasad SOA, między innymi w ykorzystyw ane usługi sieciowe komunikują się przew ażnie w starym stylu zdalnego w yw oływ ania procedur (RPC).

Rozdział 5

Usługi sieciowe a pierwotna SOA 5.1. Framework usług sieciowych 5.2. Usługi (jako usługi sieciowe) 5.3. Opisy usług (w języku WSDL) 5.4. Komunikowanie według SOAP

112

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

W spółczesna SOA związana jest nierozerw alnie z usługami sieciowymi — to właśnie koncepcje i technologie związane z usługami sieciowymi wywarły znaczący wpływ na kształt zasad zorien­ towania na usługi, wymienionych w rozdziale 3. Jest więc naturalne, że próbę zrozumienia SOA należy rozpocząć od bliższego przyjrzenia się frameworkowi ukształtowanem u przez pierwszą generację usług sieciowych oraz rozszerzeniom składającym się na drugą ich generację. W spom niane koncepcje, wyartykułowane w specyfikacjach usług sieciowych podzielimy na dwie kategorie: • koncepcje podstawowe, odnoszące się do pierwotnej SOA i rdzennych standardów usług sieciowych (omawiamy je w tym rozdziale), • koncepcje zaawansowane, rozszerzające podstawowy framework o wiele użytecznych cech, związanych z charakterystyką współczesnej SOA (im poświęcamy rozdziały 6. i 7.). Rozpoczniemy od przeglądowego wprowadzenia w koncepcje pierwszej generacji usług sie­ ciowych, przedstawiając ich związek z charakterystyką pierwotnej SOA.

UWAGA Fram ew ork, którego obraz tu przedstaw iam y, opiera się na kilku otw artych specyfikacjach, m iędzy innymi WSDL, SOAP i UDDI. Czytelnicy, którzy znają te specyfikacje i ogólne koncepcje usług sieciowych, mogą od razu przejść do rozdziału 6.

DYGRESJE „PO PROSTU" Dla czytelników mniej zaaw ansow anych przygotow aliśm y fragm enty w yróżnione jako „po prostu", w y ja ­ śniające fundam entalne koncepcje techniczne drogą analogii o charakterze zdecydow anie pozatechnicznym. Dla nowicjuszy w świecie usług sieciowych mogą one okazać się pomocne w rozwianiu ew entualnych w ą t­ pliwości.

Analizy przypadków: W tym rozdziale również odwiedzamy nasze znajome firmy RailCo i TLS, szczególną uwagę zwracać będziemy na te elementy ich infrastruktury, które stanowią od­ zwierciedlenie abstrakcyjnych koncepcji omawianych w tym rozdziale.

5 .1 . F ra m e w o rk usług s ie c io w y c h Fram ework technologiczny jest niewątpliwie tworem skomplikowanym: obejmuje jedną lub wiele architektur, technologii, koncepcji, modeli, a nawet subframeworków. Ewidentnym tego przykła­ dem jest fram ew ork definiowany przez specyfikacje usług sieciowych. A konkretnie, fram ew ork ten m ożna scharakteryzować za pomocą: • abstrakcji definiowanych (niezależnie od producentów ) przez organizacje standaryzacyjne i im plem entow anych przez (zależne od producentów) platformy technologiczne, • podstawowych cegiełek, między innymi usług sieciowych, ich opisów oraz komunikatów,

5.1. FRAMEWORK USŁUG SIECIOWYCH

113

• uzgodnień komunikacyjnych, opierających się na opisach usług sieciowych wyrażonych w języku WSDL, • subframeworku komunikacyjnego zbudowanego z koncepcji i technologii SOAP, • rejestracji opisów usług i architektury odnajdywania usług, często realizowanej za pomocą UDDI, • dobrze zdefiniowanej architektury wspierającej wzorce kom unikatów i kompozycje (omawianej w rozdziale 6.), • rozszerzeń drugiej generacji usług sieciowych (znanych powszechnie jako specyfikacje WS-*), wciąż poszerzających zestaw ich użytecznych cech; omawiamy je w rozdziałach 6. i 7. Uzupełnieniem tej listy może być dokum ent Basic Profile autorstwa WS-I (wspominaliśmy o nim w rozdziale 4. i będziemy do niego powracać w następnych rozdziałach). Jego treścią są zale­ cane praktyki dotyczące wykorzystywania poszczególnych cech WSDL, SOAP i UDDI, a w kon­ sekwencji stanowi on podstawę standaryzacji elem entów składających się na fram ework usług sieciowych. Fram ework technologiczny usług sieciowych, w całej swej okazałości, jest koncepcyjnie po­ wiązany z zasadami orientacji na usługi, wymienionymi w rozdziale 3. Dla lepszego uwidocznie­ nia tej synergii nadaliśmy trzem następnym podrozdziałom tytuły pozostające w ścisłym związku z tytułam i odpowiednich punktów rozdziału 3. poświęconych pierwotnej SOA. Przedstawiamy to powiązanie na rysunku 5.1.

Rysunek 5.1. Strukturalna odpowiedniość fragm entów rozdziałów 3. i 5. P O D S U M O W A N IE Technologie usług sieciowych pierwszej i drugiej generacji w raz z projektow aniem niezależnym od zastosowań i architekturam i abstrahującymi od konkretnych im plem entacji składają się na abstrakcyjny fram ew ork usług sieciowych. Charakterystyczne cechy tego fram ew orku pozostają w ścisłej relacji do charakterystyki pierwotnej SOA.

114

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

5 .2 . U s łu g i (ja k o u s łu g i s ie c io w e ) W rozdziale 3. wprowadziliśmy koncepcję usług oraz wyjaśniliśmy, że usługa może enkapsulować pewną część logiki. Urzeczywistnienie tej koncepcji wymaga użycia technologii, z jednej strony, zachowującej zasady zorientowania na usługi, z drugiej natomiast, zdolnej do implementowania funkcjonalności świata biznesu. Usługi sieciowe umożliwiają spełnienie tych warunków, lecz muszą być w tym celu odpowiednio zaprojektowane. Framework usług sieciowych jest wysoce elastyczny i wysoce adaptowalny — usługi sieciowe mogą być projektowane bądź to z intencją dublowania zachowania i funkcjonalności ty­ powych dla konkretnego (własnościowego) systemu rozproszonego, bądź też w sposób zgodny w pełni z zasadami zorientowania na usługi.

UWAGA W tej książce zam iennie używać będziemy określeń „usługi" i „usługi sieciowe".

Rozpocznijmy od przyjrzenia się najbardziej podstawowym koncepcjom projektowania usług sieciowych. Zasadniczo, z każdą usługą sieciową może być skojarzona: • klasyfikacja tymczasowa wynikającą z roli, jaką przyjmuje usługa w kontekście bieżącego przetwarzania komunikatu, • klasyfikacja perm anentna oparta na logice aplikacji reprezentowanej przez usługę oraz na funkcji, jaką pełni usługa w środowisku danego rozwiązania. W yjaśnimy obie te klasyfikacje projektowe w dwóch punktach poświęconych: • rolom usług (klasyfikacja tymczasowa), • m odelom usług (klasyfikacja perm anentna).

PO PROSTU Bob i Jim to dwaj starzy przyjaciele, z którymi czasem i ja się spotykam. Podczas ostatniego naszego spotkania w spom inaliśm y Chucka, z którym też często spędzaliśmy przyjemne chwile, lecz o którym nie m am y od wielu lat żadnych wieści. Uznaliśmy, że miło byłoby znów się razem spotkać. Bob słyszał o agencji Reconnect, spe­ cjalizującej się w odnajdyw aniu ludzi. Aby skorzystać z usług agencji Reconnect, musielibyśmy: 1.

znaleźć sposób skontaktow ania się z tą agencją (odnaleźć agencję),

2.

skom pletow ać informacje na tem at Chucka, jakich zażąda agencja w celu rozpoczęcia poszukiwań (sform ułować żądanie),

3.

przekazać te informacje agencji (wysłać żądanie).

(Każdy z tych kroków zostanie szczegółowo om ów iony w kolejnych dygresjach „Po p ro s tu ..."). Agencja Reconnect oferuje klientom swe usługi, może być w ięc postrzegana w roli dostarczyciela usługi. M y, jako żądający w yświadczenia usługi, możemy być uważani jako w ypełniający rolę usługi-wnioskodawcy.

5 .2 . USŁUGI (JAKO USŁUGI S IEC IO W E)

115

5.2.1. Role usług Usługa sieciowa zdolna jest do przyjmowania różnych ról, zależnie od kontekstu, w którym jest używana — przykładowo może pełnić rolę inicjatora, przekaźnika lub odbiorcy komunikatu. Nie można więc jednoznacznie potraktować usługi jako klienta albo serwera, lecz należy raczej pa­ trzeć na nią jak na jednostkę przetwarzania zdolną do zmieniania swych ról, stosownie do bieżącej odpowiedzialności w danym scenariuszu przetwarzania. I dla usługi sieciowej jest czymś zgoła norm alnym wielokrotna zmiana ról w ram ach danego zadania biznesowego. Dotyczy to zwłaszcza usług sieciowych tworzących SOA — każda z nich może pełnić (być może równocześnie) odmienne role w różnych zadaniach biznesowych. Opiszmy więc dokładniej fundam entalne role usługi. Usługa-dostarczyciel Usługa spełnia rolę dostarczyciela („providera”), gdy spełnione są następujące warunki: • usługa ta wywoływana jest przez zewnętrzne źródło, którym może być na przykład usługa-wnioskodawca (patrz rysunek 5.2); • usługa ta dostarcza swój opublikowany opis, czyli informacje na temat swych cech i zachowania (opisami usług zajmiemy się dalej w tym rozdziale).

Rysunek 5.2. Usługa sieciowa będąca adresatem komunikatu-żądania uważana jest za usługę-dostarczyciela

Analogią roli dostarczyciela usługi może być rola serwera w klasycznej architekturze klient-serwer. Zależnie od rodzaju wymiany kom unikatów związanej z wywoływaniem usługi-dostarczyciela, usługa ta może wysłać do wnioskodawcy zwrotny komunikat-odpowiedź (rodzaj wymiany ko­ m unikatów między usługam i nosi nazwę „wzorca wymiany kom unikatów ” — wzorcami takimi zajmiemy się w następnym rozdziale). Często terminy „usługa-dostarczyciel” i „dostarczyciel usługi” używane są zamiennie, bo w wielu sytuacjach nieistotne jest rozróżnienie między samą usługą a świadczącym ją podmiotem (obiektem). W sytuacji, gdy takie rozróżnienie jest konieczne, pojawiają się następujące, bardziej precyzyjne określenia:

116

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

• podmiot-dostawca usługi (serviceprovider entity) to organizacja, człowiek, system lub inna encja fizycznie świadcząca usługę, • agent dostawcy usługi (serviceprovider agent) to sama dostarczana usługa, funkcjonująca w im ieniu swego podmiotu-dostawcy.

UWAGA Nie należy jednak mylić agenta dostaw cy usługi z agentem usługi (service a g e n t — ten ostatni jest nie­ w ielkim program em , wykonującym rutynowe działania w spom agające realizację usług sieciowych. Agentam i usług zajm iem y się w rozdziale 18.

Usługa-wnioskodawca Dowolna jednostka logiki przetwarzania, zdolna wysyłać komunikaty-żądania zrozumiałe dla do­ starczyciela usługi, klasyfikowana jest jako usługa-wnioskodawca (service requestor). Każda usługa sieciowa zawsze jest usługą-dostarczycielem, niektóre usługi mogą pełnić także rolę wnioskodawcy.

UWAGA W tej książce przyjmujem y, że każda (praw ie) opisywana usługa-w nioskodaw ca jest usługą sieciową i jako taką przedstaw iam y ją w opisie i na rysunkach. W rozdziale 18. zajm iem y się im plem entow aniem usług sie­ ciowych oraz wyjaśnim y, ja k poszczególne elem enty platform y im plem entacyjnej w pisują się w dostarczy­ ciela i w nioskodaw cę usługi.

Usługa pełni rolę wnioskodawcy, gdy spełnione są następujące warunki: • usługa ta wywołuje usługę-dostarczyciela poprzez wysłanie do niej kom unikatu (patrz rysunek 5.3), • usługa ta wyszukuje potencjalnych dostarczycieli i wybiera najlepszego z nich (na podstawie subiektywnych kryteriów oceny), wykorzystując dostępne opisy usług (opisy usług i ich rejestry omawiamy w punkcie „Opisy usług (w języku WSDL)”, w tym rozdziale). Usługa-wnioskodawca jest naturalnym partnerem usługi-dostarczyciela — tak jak w archi­ tekturze klient-serwer klient jest naturalnym partnerem serwera. Przy okazji — należy pamiętać, że usługa nie pełni roli wnioskodawcy w sytuacji, gdy jako dostarczyciel odsyła do wnioskodawcy zwrotny kom unikat-odpow iedź. Ogólnie usługa-wnioskodawca może być utożsam iana z p ro ­ gramem inicjującym konwersację z usługą-dostarczycielem. Analogicznie jak w przypadku usługi-dostarczyciela, tak i pojęcie wnioskodawcy jest dwuznaczne, bo może oznaczać zarówno usługę-wnioskodawcę, jak i podmiot świadczący tę usługę. I podobnie jak poprzednio, gdy istotne jest rozróżnienie tych znaczeń, precyzujemy: • podmiot-wnioskodawca usługi (service requestor entity) to organizacja, człowiek, system lub inna encja fizycznie żądająca usługi, • agent wnioskodawcy usługi (service requestor agent) to usługa żądająca innej usługi w im ieniu swego podmiotu-właściciela.

5 .2 . USŁUGI (JAKO USŁUGI S IEC IO W E)

117

Rysunek 5.3. Nadawca komunikatu-żądania traktowany jest jako usługa-wnioskodawca

UW AGA Często używ anym synonim em usługi-w nioskodaw cy jest usługa-konsum ent (service consum er.

A N A LIZA PRZYPADKU

Firma RailCo jest jednym ze stałych dostawców dla firmy TLS. RailCo była od dawna naj­ ważniejszym producentem zaopatrującym TLS w części do systemów hamulcowych; zamó­ wienia realizowane były telefonicznie lub za pomocą faksu. Ostatnio jednak na rynku zaist­ niał nowy producent wspomnianych części, oferujący swe produkty po konkurencyjnych cenach oraz — to ważne — zdolny do współpracy z firmą TLS za pośrednictwem jej systemu B2B. RailCo utraciła swą dominującą (wręcz monopolistyczną) pozycję w dostawach dla TLS — praktycznie TLS zwracała się teraz do RailCo tylko w sytuacji, gdy nowy dostawca nie mógł dostarczyć żądanych części. Aby choć częściowo odzyskać utracone wpływy i stać się równorzędnym partnerem online firmy TLS, firma RailCo m usi przystosować się do reguł i specyfikacji definiowanych przez TLS. Po pierwsze, TLS wymaga od każdego z dostawców zbudowania odpowiedniego inter­ fejsu, umożliwiającego TLS współpracę z systemem kontroli inwentarza tegoż dostawcy (bo w ten sposób TLS składać będzie zamówienia). Po drugie, każdy dostawca musi zapewnić sobie możliwość współpracy z systemem księgowym TLS, poprzez zewnętrzny interfejs tegoż sys­ tem u (w ten sposób TLS otrzymywać będzie potwierdzenia zleceń i faktury). Powyższe wymagania zmusiły RailCo do poszerzenia swego systemu księgowego o m oż­ liwość współdziałania z systemem B2B firmy TLS, opartym na usługach sieciowych. Typowy scenariusz wymiany danych w nowych warunkach wygląda mniej więcej tak:

118

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

• usługa Zlecenie zakupu w firmie TLS wysyła (elektroniczne) zamówienie, które zarejestrowane zostaje przez usługę Realizacja zamówienia w firmie RailCo, • w związku z otrzymanym zamówieniem usługa Wystawienie faktury w firmie RailCo wysyła (elektroniczną) fakturę do usługi Płatność na konto w firmie TLS. Opisaną wymianę dwóch kom unikatów zilustrowano na rysunku 5.4.

R a ilC o

TLS

Rysunek 5.4. Zmieniające się role usług w związku z wymianą powiązanych ze sobą komunikatów

W pierwszym scenariuszu TLS pełni rolę podm iotu usługi-wnioskodawcy. Usługa Zlece­ nie zakupu jest usługą-wnioskodawcą (agentem wnioskodawcy) i inicjuje interakcję, wysyłając komunikat-żądanie. Odbiorca tego kom unikatu — usługa Realizacja zamówienia — pełni rolę usługi-dostarczyciela (agenta dostarczyciela). RailCo, jako właściciel tej usługi, pełni rolę podm iotu dostarczyciela. W drugim scenariuszu role podmiotów zamieniają się. RailCo jest podmiotem-wnioskodawcą, ponieważ jego usługa Wystawienie faktury funkcjonuje w roli usługi-wnioskodawcy. TLS jest podm iotem -dostarczycielem , ponieważ jego usługa Płatność na konto, odbierając ko­ m unikat wysłany przez usługę-wnioskodawcę i odpowiadając na niego, pełni rolę usługi-dostarczyciela.

PO PROSTU

Ponieważ chcemy wysłać list (tradycyjną pocztą) do agencji Reconnect, w celu zainicjowania poszukiwań Chucka, potrzebujem y pośrednika: m im o iż wspomniany list zaadresowany jest do agencji Reconnect, zostaje przekazany urzędowi pocztowemu, który — wiadomymi sobie drogami — doręczy list adresatowi. W tym scenariuszu urząd pocztowy pełni rolę pośrednika (intermediary) oferującego usługę trasowania (routing).

5 .2 . USŁUGI (JAKO USŁUGI S IEC IO W E)

119

Usługi pośredniczące Framework komunikacyjny ustanawiany przez usługi sieciowe jest z natury odm ienny od trady­ cyjnych kanałów komunikacyjnych typu punkt-punkt. Te tradycyjne kanały, mimo iż mało ela­ styczne i skalowalne tylko w niewielkim stopniu, są jednak stosunkowo proste w projektowaniu. Framework komunikacyjny usług sieciowych bazuje na ścieżkach komunikatów, z których każda może być (obrazowo) uważana jako połączenie typu punkt-* — kom unikat wysłany przez usługędostarczyciela trasowany jest i przetwarzany przez serię agentów-pośredników, zanim dotrze do miejsca swego przeznaczenia (o ścieżkach kom unikatów piszemy nieco dokładniej w końcowej części tego rozdziału). Usługi sieciowe zajmujące się przetwarzaniem kom unikatu po jego wysłaniu przez nadawcę, a przed dotarciem do adresata, nazywane są pośrednikami (intermediaries) lub usługam i p o­ średniczącymi (intermediary services). Każda usługa pośrednicząca, jako przyjmująca, a następ­ nie wysyłająca kom unikat, występuje najpierw w roli dostarczyciela, a następnie wnioskodawcy (patrz rysunek 5.5).

Rysunek 5.5. W trakcie przetwarzania komunikatu usługa pośrednicząca pełni na zmianę role dostarczyciela i wnioskodawcy

Zależnie od traktow ania otrzymanego kom unikatu, usługi pośredniczące dzielą się na dwa rodzaje. Pośrednik bierny (passive intermediary) odpowiedzialny jest jedynie za przekazanie ko­ m unikatu do następnej lokalizacji na trasie (patrz rysunek 5.6). Lokalizacja ta może zostać wy­ znaczona bądź to na podstawie nagłówka SOAP, bądź też za pom ocą specjalnego procesu, na przykład procedury próbującej równoważyć obciążenie sieci; tak czy inaczej, kom unikat nie jest modyfikowany, a jedynie przekazywany.

120

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

\

\

\

r-

n

Realizuje logikę trasowania, decydującą o przebiegu ścieżki komunikatu

Usługawnioskodawca

-W-

Bierna usługa pośrednicząca

\

\

Usługadostarczyciel

-M-

\

Rysunek 5.6. Bierna usługa pośrednicząca przekazuje komunikat bez modyfikowania jego treści

ANALIZA PRZYPADKU

Usługa RailCo Wystawienie faktury po otrzym aniu zamówienia od TLS wysyła kom uni­ kat zawierający elektroniczną fakturę. Pierwszą z usług TLS, która odbiera ten kom unikat, jest bierna usługa pośrednicząca Równoważenie obciążenia, kontrolująca bieżące obcią­ żenie dostępnych serwerów i przekazująca otrzym any kom unikat do serwera najmniej ob­ ciążonego. W spom niana usługa równoważąca obciążenie w momencie odbierania kom unikatu wy­ słanego przez usługę-wnioskodawcę Wystawienie faktury pełni rolę dostarczyciela. Po wybra­ niu serwera docelowego zmienia ona swą rolę na wnioskodawcę, przekazującego dokumentfakturę do docelowej usługi-dostarczyciela Płatność na konto. UWAGA Usługa Równoważenie obciążenia (i pokrewna usługa Polityka w ew nętrzna ) to przykłady pośredników osiągalnych przez usługi sieciowe w sposób ja w n y — za pomocą języka WSDL bądź jako agenty usług. Agenty usług to usługi pośredniczące zaprojektow ane w celu przechw ytyw ania i przetw arzania komuni­ katów na drodze do miejsca przeznaczenia — ich dokładne om ówienie przedstawiam y w rozdziale 18. Firma TLS wykorzystuje elastyczne usługi tego typu w celu spełnienia w ym o g ó w specyficznych dla jej środowiska.

5 .2 . USŁUGI (JAKO USŁUGI S IEC IO W E)

121

Pośrednicy czynni (active intermediaries), podobnie jak ich bierne odpowiedniki, przekazują otrzymywane kom unikaty do następnej usługi na ich trasie, jednakże przed wysłaniem kom uni­ katu przetwarzają go i zmieniają jego treść (patrz rysunek 5.7). Zazwyczaj przetwarzanie to od­ bywa się w oparciu o informację zawartą w poszczególnych blokach nagłówków SOAP i polega na modyfikowaniu tej informacji, a niekiedy dodawaniu lub usuwaniu całych bloków nagłówka (blokami nagłówków SOAP zajmiemy się dalej w tym rozdziale).

Rysunek 5.7. Czynna usługa pośrednicząca

A N A LIZA PRZYPADKU

W środowisku TLS funkcjonuje wiele czynnych usług pośredniczących. Przykładowo usługa Polityka wewnętrzna kontroluje otrzymany kom unikat pod kątem stosowalności do niego restrykcji wynikających z założeń wewnętrznej polityki — gdy okazuje się, że analizowany kom unikat faktycznie podlega którejkolwiek ze wspomnianych restrykcji, usługa pośredni­ cząca dodaje do jego nagłówka nowy blok zawierający stosowne reguły dla następnych usługdostarczycieli napotykanych na trasie. Podobnie jak biernie pośrednicy, tak i czynni pośrednicy ciągle zmieniają swe role w dziele dostarczania komunikatu do docelowej usługi-dostarczyciela.

Nadawca początkowy i odbiorca końcowy Nadawca początkowy (Initial sender) to po prostu usługa-wnioskodawca inicjująca transm isję kom unikatu, stanowiąca pierwszy punkt na trasie (ścieżce) kom unikatu. Analogicznie końcowa usługa-dostarczyciel na trasie kom unikatu — będąca ultymatywnym adresatem tegoż kom uni­ katu — to odbiorca końcowy (ultim ate receiver). Przedstaw iam y tę sytuację na rysunku 5.8. W arto zauważyć, że z perspektywy określonego kom unikatu usługa pośrednicząca nigdy nie jest ani nadawcą początkowym, ani odbiorcą końcowym.

122

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

Rysunek 5.8. Usługi sieciowe działające jako nadawca początkowy i odbiorca końcowy

A N A LIZA PRZYPADKU

Rozwijając poprzedni przykład ilustrujący działanie biernego pośrednika, przyjrzyjmy się ogó­ łowi usług uwikłanych w wymianę komunikatów. W ymiana ta inicjowana jest przez usługę RailCo Wystawienie faktury (działającą w roli wnioskodawcy). W ysłany przez nią kom uni­ kat trafia do usługi-pośrednika Równoważenie obciążenia działającej w roli dostarczyciela; przekazując otrzymany kom unikat, usługa ta zmienia swą rolę na wnioskodawcę. Komunikat trafia do usługi-dostarczyciela Płatność na konto (patrz rysunek 5.9).

Rysunek 5.9. Usługa Równoważenie obciążenia działająca jako pośrednik między początkowym nadawcą z RailCo a końcowym odbiorcą z TLS

5 .2 . USŁUGI (JAKO USŁUGI S IEC IO W E)

123

Tak więc trzy fizyczne usługi obsadzane są w czterech logicznych rolach w celu zrealizo­ wania dwóch transmisji między wnioskodawcą a dostarczycielem. Dokładnie jedna usługa — Wystawienie faktury — jest w tym scenariuszu inicjatorem (początkowym nadawcą) i do­ kładnie jedna — Płatność na konto — jako końcowy odbiorca kończy ten scenariusz.

Kompozycje usług Kompozycją usług nazywamy kolekcję usług sieciowych wraz ze wszystkimi złożonymi zależno­ ściami, jakie między tymi usługam i występują. Usługa sieciowa w celu wykonania określonego zadania może zwerbować do pom ocy jedną lub więcej dodatkowych usług i schemat ten należy rozumieć wielopoziomowo — każda ze zwerbowanych usług dodatkowych może zrealizować taki werbunek na swoje potrzeby i tak dalej. W tym kontekście każda z usług partycypujących w kom­ pozycji przyjmuje na siebie rolę składnika kompozycji (composition member) (patrz rysunek 5.10).

Rysunek 5.10. Czteroskładnikowa kompozycja usług

Zazwyczaj zdolność usługi sieciowej do efektywnego uczestniczenia w kompozycjach powinna być rozważana już podczas projektowania. Zasady zorientowania na usługi kładą szczególny nacisk na komponowalność usług, co skłania do projektowania usług sieciowych w sposób umożliwiający uczestnictwo w przyszłych kompozycjach, bez uprzedniej wiedzy na temat ich zastosowań. Koncepcja komponowalności jest szczególnie istotna w środowisku zorientowanym na usługi (wyjaśniamy dokładniej tę koncepcję w rozdziale 8.). Koncepcję tę wspierają rozszerzenia WS-*, między innymi WS-BPEL i WS-CDL wprowadzające powiązane koncepcje orkiestracji i choreografii (co wyjaśniamy w rozdziale 6.).

UW AGA Kompozycje usług są także określane m ianem podzespołów usługowych (service assem blies.

124

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

A N A LIZA PRZYPADKU

Gdy usługa TLS Płatność na konto otrzymuje fakturę elektroniczną, wywołuje serię dodat­ kowych usług w celu pełnego przetworzenia treści faktury. 1. Najpierw usługa Profile dostawców waliduje dane nagłówka i wiąże dokum ent faktury z kontem dostawcy. 2. Następnie usługa Płatność na konto wyodrębnia kwotę podatku i koszty dostawy, po czym obciąża odpowiednie konto. 3. Na zakończenie usługa Płatność na konto przekazuje kwotę płatności do usługi Rejestr księgi głównej, w celu zaktualizowania rejestru księgi głównej. M amy zatem do czynienia z kompozycją trzech usług, z usługą Płatność na konto na czele (patrz rysunek 5.11).

Rysunek 5.11. Usługa Płatność na konto werbuje do pomocy dw ie dodatkowe usługi w ramach kompozycji

UW AGA Nie om aw iam y w tym miejscu w ażnej cechy opisywanej kompozycji — transakcyjnoścr. przedstawiony sce­ nariusz musi zostać w ykonany albo w całości, albo wcale. Gdy mianowicie w ykonyw anie którejkolwiek z usług załamie się, należy anulować wszystko, co do tej pory wykonane zostało w ramach wspom nianego scenariusza (koncepcje zw iązane z transakcjami usług w yjaśniam y w rozdziale 6.).

5 .2 . USŁUGI (JAKO USŁUGI S IEC IO W E)

125

5.2.2. Modele usług Om awiane dotychczas role usług miały tę cechę wspólną, że nie pozostawały w żadnym związku z funkcjonalnością oferowaną przez daną usługę; reprezentowały raczej pewne uniwersalne (generyczne) stany usługi, przez które przechodzi ona w trakcie realizowania swych elementów funk­ cjonalnych. Przebywanie usługi w takim konkretnym stanie m a zwykle charakter przejściowy, dlatego klasyfikację usług ze względu na pełnione role nazwaliśmy klasyfikacją tymczasową. Funkcjonowanie usług sieciowych w realnym świecie skłania jednak do stworzenia alterna­ tywnej klasyfikacji, opierającej się na naturze logiki aplikacyjnej, jaką usługi te reprezentują, jak również na ich udziale w realizowaniu globalnej logiki biznesowej konkretnego rozwiązania. Umiejscowienie usługi w kategoriach tej klasyfikacji nosi nazwę modelu usługi; często konkretna usługa przejawia cechy charakterystyczne dla kilku modeli. Cechy te pozostają niezmienne przez cały czas funkcjonowania usługi, dlatego modele usług uważane są za klasyfikację permanentną (w odróżnieniu od wspomnianej na wstępie klasyfikacji tymczasowej opartej na rolach usług). W kolejnych punktach przedstawimy teraz krótką charakterystykę najczęściej spotykanych modeli usług, kolejne modele omawiane będą w następnych rozdziałach. Zestawienie wszystkich opisywanych w tej książce modeli usług znajdą czytelnicy w dodatku B. Usługa biznesowa Usługa biznesowa stanowi w kontekście SOA podstawowy blok-cegiełkę. Usługa taka enkapsuluje dobrze zdefiniowany zbiór elementów logiki biznesowej, mieszczącej się w ściśle określonych granicach funkcjonalnych. Jest idealnie autonom iczna i jakkolwiek może — oczywiście — działać w odosobnieniu, jednak usługi biznesowe spotyka się bardzo często jako składniki kompozycji. Na gruncie SOA usługi biznesowe wykorzystywane są najczęściej: • jako cegiełki tworzące reprezentację logiki biznesowej, • do reprezentowania korporacyjnych banków informacji i innych zasobów informacyjnych, • do reprezentowania logiki procesów biznesowych, • jako składniki kompozycji. Wybiegając nieco w przód — gdy SOA budow ana jest na kanwie warstw abstrakcji, model usług biznesowych może być uważany za odpow iednik warstwy usług biznesowych (omawianej w rozdziale 9.). Usługa użytkowa Usługa realizująca generyczną funkcjonalność, niereprezentująca w sposób wyraźny logiki bizne­ sowej, klasyfikowana jest jako usługa użytkowa. Usługi użytkowe wykorzystywane są w ram ach SOA jako: • usługi wspierające wykorzystywanie wieloużywalności, • uniwersalne usługi pośredniczące, nieuzależnione od konkretnego rozwiązania, • usługi wspomagające osiągnięcie interoperacyjności, • usługi o dużym stopniu autonomiczności.

126

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

Ponownie nawiązujemy do warstw abstrakcji usług opisywanych w rozdziale 9.: usługa użyt­ kowa skojarzona jest zwykle z warstwą usług aplikacyjnych, dlatego często określana jest mianem aplikacyjnej usługi użytkowej. ANALIZA PRZYPADKU

W prezentowanych dotąd w tym rozdziale analizach przypadku wyodrębniliśmy osiem usług sieciowych. Sześć z nich to usługi biznesowe, dwie pozostałe to usługi użytkowe: • Płatność na konto to usługa biznesowa, • Polityka wewnętrzna to usługa użytkowa, • Wystawienie faktury to usługa biznesowa, • Rejestr księgi głównej to usługa biznesowa, • Równoważenie obciążenia to usługa użytkowa • Realizacja zamówienia to usługa biznesowa, • Zlecenie zakupu to usługa biznesowa, • Profile dostawców to usługa biznesowa. Usługi Równoważenie obciążenia i Polityka wewnętrzna zaklasyfikowane zostały jako użytkowe, ponieważ reprezentują uniwersalną funkcjonalność, przydatną dla różnych typów aplikacji. Pozostałe z wymienionych usług są specyficzne dla konkretnego zadania lub roz­ wiązania.

Usługa-kontroler Kompozycje usług to zbiory usług niezależnych, jednak współuczestniczących w wykonaniu okre­ ślonego zadania. Zebranie i skoordynowanie tych usług to zwykle zadanie skomplikowane samo w sobie — zadanie, które może stanowić główną funkcję dedykowanej usługi lub drugoplanową (poboczną) funkcję usługi realizującej zasadniczo logikę biznesową. Taki model koordynacji usług składowych w ram ach kompozycji nosi nazwę usługi-kontrolera. Usługa-kontroler wykorzystywana jest przez SOA w celu: • wspierania i implementowania zasady komponowalności, • spożytkowywania wieloużywalności. Usługa posiada atrybut kontrolera, gdy choć jedna z jej operacji reprezentuje logikę koordy­ nowania operacji wykonywanych przez inne usługi uczestniczące w tej samej kompozycji. Zauważmy, że model usługi-kontrolera to koncepcja ogólnie wielopoziomowa: dana usługa, będąca kontrolerem, może być jednocześnie usługą składową większej kompozycji, podporządko­ waną kontrolerowi wyższego rzędu. W sytuacji przedstawionej na rysunku 5.12 nadrzędny kon­ troler odpowiedzialny jest za koordynowanie operacji trzech podporządkowanych usług, z których jedna jest kontrolerem niższego rzędu (subkontrolerem) koordynującym trzy inne usługi.

5 .2 . USŁUGI (JAKO USŁUGI S IEC IO W E)

127

Rysunek 5.12. Kompozycja składająca się z kontrolera nadrzędnego, subkontrolera, czterech usług biznesowych i jednej usługi użytkowej

Jak wyjaśnimy to w rozdziale 9., m odel usługi-kontrolera używany jest przez SOA do budo­ wania specjalizowanych warstw abstrakcji.

A N A LIZA PRZYPADKU

W jednym z poprzednich przykładów pokazaliśmy, jak usługa Płatność na konto inicjuje i ko­ ordynuje funkcjonowanie kompozycji obejmującej jeszcze dwie inne usługi (patrz rysunek 5.13). Nadaje to usłudze Płatność na konto status usługi-kontrolera. I nie przeszkadza tem u fakt, że usługę tę można zakwalifikować również jako usługę biznesową — jak wcześniej wyjaśniali­ śmy, konkretna usługa czynić może zadość charakterystykom kilku modeli.

128

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

Rysunek 5.13. Usługa Płatność na konto funkcjonująca jako usługa biznesowa i jednocześnie jako usługa-kontroler, podporządkowująca sobie dwie inne usługi

P O D S U M O W A N IE •

Usługi sieciowe mogą być klasyfikowane według kryteriów zarówno tymczasowych, jak i permanentnych.

•

Klasyfikacja tym czasowa usług odnosi się do ról, jakie przejściowo przyjmują na siebie funkcjonujące usługi; przykładowo każda usługa pośrednicząca odgrywa kolejno role dostarczyciela i w nioskodawcy.

•

Klasyfikacja perm anentna w yodrębnia m odele usług, odnoszące się do logiki enkapsulow anej przez usługi oraz ich umiejscowienia w ogólnej konstrukcji rozw iązania. Konkretna usługa może być klasyfikowana w kategoriach więcej niż jednego modelu.

5 .3 . O p is y u sług (w ję zy k u W S D L) Gdy w rozdziale 3. wymieniliśmy luźne powiązanie usług jako jedną z zasad pierwotnej SOA, wyjaśniliśmy fundam entalne znaczenie opisów usług dla realizacji tej zasady. To właśnie opisy każdej z usług umożliwiają powiązanie tychże usług (zaimplementowanych jako usługi sieciowe) w spójny schemat komunikacji, stanowiący istotę wspomnianego luźnego powiązania. Z tego względu z każdą usługą, przewidzianą do funkcjonowania w roli końcowego odbiorcy, muszą być powiązane dokum enty opisujące tę usługę. Jednym z takich dokum entów jest opis rze­ czonej usługi w języku WSDL (patrz rysunek 5.14).

5 .3 . O PISY USŁUG (W JĘZYKU W SD L)

129

Rysunek 5.14. Definicje WSDL umożliwiające luźne powiązanie usług

UWAGA W tym rozdziale om aw iam y jedynie koncepcję języka WSDL, samym językiem i przykładami jego użycia zaj­ miemy się w rozdziale 13.

PO PROSTU Aby agencja Reconnect mogła rozpocząć poszukiwania Chucka, potrzebuje kilku informacji oraz w ym aga do­ pełnienia pewnych formalności. Zdobyliśmy broszurę agencji, do broszury dołączony był form ularz. Czytając w spom nianą broszurę, dow iedzieliśm y się, że: 1.

w załączonym form ularzu należy zaw rzeć kom plet inform acji niezbędnych do wszczęcia poszukiw ań,

2.

poszukiw ania zostaną rozpoczęte przez agencję natychm iast po otrzym aniu przez nią w spom nianego form ularza,

3.

po zakończeniu poszukiwań zostaniem y poinform ow ani listow nie o ich rezultacie.

Oprócz w ypełnienia formularza w żądanej aranżacji, musieliśmy ponadto w ydać oświadczenie, że po­ szukiwania Chucka będą prow adzone w naszym imieniu; musieliśmy także zaakceptow ać zastrzeżenie, że mimo dołożenia należytej staranności do w ykonania zadania, agencja nie gw arantuje pozytywnego rezultatu poszukiwań. Broszura w raz z załączonym do niej form ularzem są dla agencji Reconnect mniej więcej tym , czym dla usługi sieciowej jest jej opis WSDL. W obu przypadkach m am y do czynienia ze szczegółami wykorzystania usługi: informacją niezbędną do w ykonania żądania, dodatkow ym i uw arunkow aniam i niezbędnymi do tej realizacji oraz sposobem poinform ow ania o ostatecznym statusie tej realizacji.

130

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

A N A LIZA PRZYPADKU

Firma RailCo w celu zaprojektowania swoich usług sieciowych B2B w pełnej zgodności z usłu­ gami TLS uzyskała od TLS opis WSDL usługi Płatność na konto. Programiści RailCo wyko­ rzystali ten opis do zbudowania usługi Wystawienie faktury tak, by była zdolna do przetwa­ rzania komunikatów SOAP, zgodnie z wymaganiami dotyczącymi interfejsów, definiowanymi w opisach usług TLS. Ponadto RailCo dostarczyła do TLS kopię opisu WSDL swej usługi Realizacja zamówienia. TLS zarejestrowała ten opis i dodała go do listy punktów końcowych dostawców, do których usługa Zlecenie zakupu wysyłać może elektroniczne zamówienia. Oba te scenariusze przed­ stawiono na rysunku 5.15.

Rysunek 5.15. Każda usługa-wnioskodawca dysponuje opisem WSDL usługi-dostarczyciela, do której wysyła swe komunikaty, dzięki czemu komunikaty te mogą być poprawnie interpretowane przez adresata

Zauważmy, że ponieważ to TLS definiuje zasady wymiany kom unikatów ze swymi kon­ trahentami, RailCo dostosowała się do tych zasad, projektując swoje usługi. Usługa Wystawie­ nie faktury została zbudowana jako wnioskodawca wysyłający kom unikaty zgodne z opisem WSDL usługi Płatność na konto. Usługę Realizacja zamówienia zaprojektowano natomiast jako dostarczyciela, zgodnie ze specyfikacją podaną przez TLS; daje to firmie TLS gwarancję, że kom unikaty wysyłane przez usługę Zlecenie zakupu (działającą jako wnioskodawca) będą zrozumiałe dla zarejestrowanych dostarczycieli.

5 .3 . O PISY USŁUG (W JĘZYKU W SD L)

131

5.3.1. Punkty końcowe usług i opisy usług Opis WSDL usługi sieciowej to w istocie opis punktu, w którym z usługą tą, jako dostarczycielem, kontaktują się wnioskodawcy. Punkt ten, nazywany oficjalnie punktem końcowym usługi (service endpoint) lub krótko punktem końcowym (endpoint), zawiera form alną definicję interfejsu usługi-dostarczyciela oraz inform ację o lokalizacji tej usługi. Dzięki tem u każdy potencjalny wnioskodawca może tę usługę odnaleźć oraz nadać wysyłanym kom unikatom strukturę wym a­ ganą przez jej interfejs. Zobaczmy więc, jak ogólnie zorganizowany jest sam dokum ent opisu usługi. Informację skła­ dającą się na definicję WSDL usługi (zwaną krótko definicją WSDL) m ożna podzielić na dwie kategorie: • opis abstrakcyjny, • opis skonkretyzowany. Na rysunku 5.16 przedstawiono schematycznie ten podział, wraz z wyszczególnieniem logicznej hierarchii każdej z kategorii. W yjaśnimy pokrótce rolę poszczególnych elementów tej hierarchii.

J Definicja WSDL

Rysunek 5.16. Dokument WSDL, podzielony na dw ie kategorie — abstrakcyjną i skonkretyzowaną — wspólnie opisujące punkt końcowy usługi

5.3.2. Opis abstrakcyjny Opis abstrakcyjny odzwierciedla strukturę interfejsu usługi sieciowej w całkowitym oderwaniu od technologii implementującej tę usługę i umożliwiającej transmisję komunikatów. Taka separa­ cja pomaga w zachowaniu integralności opisu usługi w przypadku zmiany platformy technolo­ gicznej. Abstrakcyjna część dokum entu WSDL podzielona jest hierarchicznie na typy portów, operacje i komunikaty.

132

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

Typ portu, operacja i komunikat Macierzysta sekcja Typ portu (portType) jest narzędziem wysokopoziomowej organizacji inter­ fejsu usługi — komunikaty, które usługa zdolna jest przetwarzać, pogrupowane są funkcjonalnie w operacje. Każda operacja reprezentuje pewną konkretną akcję wykonywaną przez usługę; w tym sensie operację m ożna przyrównać do publicznej m etody kom ponentu (obiektu) w tradycyjnej aplikacji rozproszonej. Analogią wejściowych i wyjściowych param etrów wspomnianej metody są (odpo­ wiednio) odbierane i wysyłane przez usługę kom unikaty, a dokładniej — operacja jest de facto zbiorem takich komunikatów. Ułożenie wspomnianych kom unikatów w odpowiednią sekwencję jest kwestią wzorca wy­ miany komunikatów skojarzonego z operacją. W zorcami takimi będziemy się zajmować w na­ stępnym rozdziale.

UWAGA Od wersji 2 .0 specyfikacji WSDL term in Typ portu (portTypèi ustąpił miejsca term inow i interfejs (,interface ).

5.3.3. Opis skonkretyzowany Aby usługa sieciowa mogła urzeczywistnić jakąkolwiek porcję swej logiki, jej abstrakcyjna definicja interfejsu musi zostać skojarzona z jakąś rzeczywistą technologią implementacyjną. A ponieważ funkcjonowanie usługi sieciowej nierozerwalnie wiąże się z odbieraniem i wysyłaniem kom uni­ katów, ten abstrakcyjny interfejs nieuchronnie m usi zostać skojarzony z fizycznym protokołem transportowym . Oba te skojarzenia są częścią skonkretyzowanej porcji opisu WSDL, której ele­ mentam i są: wiązanie (binding), port i usługa (service). Wiązanie, port i usługa Przedm iotem wiązania są wymagania usługi dotyczące nawiązywania przez nią połączeń z do­ starczycielami oraz nawiązywania połączenia z nią z inicjatywy wnioskodawców. Innymi słowy, wiązanie reprezentuje jedną z możliwych technologii transportowych, które usługa może wyko­ rzystywać na potrzeby komunikacji z innym i usługami. Najczęściej spotykana w tej roli jest tech­ nologia SOAP, co jednak nie wyklucza innych możliwości. Konkretne wiązanie może dotyczyć całego interfejsu lub tylko wybranej operacji. Z wiązaniem skojarzony jest port, reprezentujący fizyczną lokalizację, którą usługa stara się osiągnąć za pośrednictwem określonego protokołu. Projektanci WSDL uznali, że celowe jest od­ dzielenie informacji o lokalizacji od innych aspektów opisu skonkretyzowanego. Termin usługa (service) w kontekście WSDL odnosi się do grupy powiązanych punktów końcowych.

UWAGA W wersji 2.0 specyfikacji WSDL termin „port" przemianowany został na „punkt końcowy" (endpoint) — i poja­ w iła się niejednoznaczność. „punkt końcowy" jako elem ent języka WSDL, oznaczający fizyczną lokalizację, jest pojęciem węższym niż „punkt końcowy" rozumiany ogólnie jako miejsce kontaktu usługi z otoczeniem.

5 .3 . O PISY USŁUG (W JĘZYKU W SD L)

133

ANALIZA PRZYPADKU

Usługa Płatność na konto została utworzona w celu przyjmowania faktur od wielu dostawców. Abstrakcyjna porcja jej opisu WSDL to definicja pojedynczego interfejsu, z jedną operacją WystawFakturę. Operacja ta to grupa dwóch kom unikatów — odbieranego („wejściowego”) i wysyłanego („wyjściowego”). K om unikat wejściowy wysłany przez usługę-wnioskodawcę (na przykład usługę Wystawienie faktury z firmy RailCo) z założenia niesie dokum ent-fakturę od do­ stawcy. Kom unikat wyjściowy to po prostu potwierdzenie pomyślnego odebrania kom uni­ katu wejściowego i pozytywnego zweryfikowania jego treści. Skonkretyzowana porcja opisu WSDL usługi Płatność na konto to powiązanie operacji WystawFakturę z protokołem SOAP oraz wskazanie adresu-lokalizacji usługi.

5.3.4. Metadane i kontrakty usług W iemy już zatem, że definicja WSDL — podzielona na porcję abstrakcyjną i skonkretyzowaną — artykułuje informację techniczną dotyczącą kontaktow ania się usługi ze światem zewnętrznym oraz typów danych wymienianych w kom unikatach wysyłanych i odbieranych przez tę usługę. To jednak zwykle nie wystarcza. Definicje WSDL często uzupełniane są o schematy XSD formalizujące strukturę odbieranych i wysyłanych komunikatów. Innym równie często spotykanym suplementem definicji WSDL jest dokum ent ustalający politykę wykorzystywania usługi — reguły, preferencje i inne detale nieuwzględnione w (lub nieuregulowane przez) WSDL i XSD (zagadnie­ niem wspomnianej polityki zajmujemy się w rozdziale 7.). Reasumując, stwierdzamy, że poszczególne aspekty usługi sieciowej opisywane są przez zestaw (maksymalnie) trzech dokumentów, którymi są: • definicja WSDL, • schemat XSD, • założenia polityki. Każdy z wymienionych dokum entów pełni rolę pomocniczą w stosunku do „zasadniczych” danych przetwarzanych przez usługę, dlatego klasyfikowany jest jako metadane (metadata). Komplet dokum entów opisujących daną usługę składa się na kontrakt tej usługi, czyli zbiór warunków, które muszą zostać spełnione lub zaakceptowane przez potencjalnego wnioskodawcę, aby był zdol­ ny do prawidłowego i efektywnego komunikowania się z przedmiotową usługą. Kontrakt usługi może zawierać dodatkowe dokumenty, niewchodzące w skład opisu tej usługi i określające dodatkowe aspekty (przeważnie o charakterze prawnym ) wykorzystywania usługi, uzgodnione między właścicielem usługi a jej potencjalnymi konsum entam i (uzgodnienia te okre­ śla się często jako „uzgodnienia na poziomie usługi” — Service Level Agreement, w skrócie SLA). Przykład typowego kontraktu usługi sieciowej przedstawiono na rysunku 5.17.

134

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

Kontrakt usługi

Rysunek 5.17. Kontrakt usługi, zawierający kolekcję opisów usługi i opcjonalnie dodatkowe dokumenty

5.3.5. Opisy semantyczne Obecnie większość m etadanych usług koncentruje się na informacjach technicznych związanych z reprezentowaniem danych i wymogami przetwarzania. Informacje te mają jednak ograniczoną wartość z perspektywy wyjaśniania szczegółów behawiorystyki usług — zaiste, największym wy­ zwaniem przy sporządzaniu opisu usługi sieciowej jest jak najlepsze odzwierciedlenie specyficz­ nych cech jej semantyki, między innymi: • zachowania się tej usługi w określonych warunkach, • reagowania przez tę usługę na określone zdarzenia, • charakteru zadań, do których usługa ta jest szczególnie przydatna. Większość informacji tego typu uzyskiwana jest drogą nieformalnej oceny, wynikającej bądź to z werbalnej dyskusji konsum enta usługi z jej właścicielem, bądź też z lektury dodatkowej do­ kumentacji publikowanej wraz z usługą. Prawdziwą jednakże sztuką jest dostarczenie tej infor­ macji w postaci strukturalnej, tak by usługi-wnioskodawcy mogły automatycznie oceniać dostępne usługi-dostarczycieli i wybierać spośród nich. Informacja o semantyce usługi nabiera szczególnego znaczenia w sytuacji, gdy jest to usługa zewnętrzna dla wnioskodawcy i ten zdany jest tylko na to, co właściciel rzeczonej usługi zdecy­ dował się opublikować; naw et jednak w granicach jednej firm y inform acja ta staje się coraz istotniejsza, w miarę jak zwiększa się liczba i zakres funkcjonalny działających w tej firmie usług sieciowych. I chociaż możliwe jest wyrażenie tej informacji w postaci sformalizowanej, na przykład w formie preferencji i asercji stanowiących część dokumentu polityki, to jednak prace w tym kierunku (pro­ wadzone głównie przez W3C) są obecnie mało zaawansowane i na razie pozostaje wnioskodaw­ com polegać w tej mierze jedynie na nieformalnej treści zawartej w trzech składnikach opisu — definicjach WSDL, schematach XSD i założeniach polityki.

5 .3 . O PISY USŁUG (W JĘZYKU W SD L)

135

5.3.6. Ogłaszanie i odnajdywanie opisów usług Jedynym wymaganiem usługi dotyczącym skomunikowania się z inną usługą jest dysponowanie opisem tej ostatniej. W miarę jak zwiększa się liczba usług eksploatowanych w przedsiębiorstwie i usług zew nętrznych wykorzystywanych przez to przedsiębiorstwo, coraz bardziej odczuwalna staje się potrzeba zastosowania m echanizm u zapewniającego rejestrowanie i odnajdywanie opi­ sów usług — na przykład centralnego katalogu lub rejestru takich opisów. Takie repozytorium umożliwia ludziom (a nawet usługom-wnioskodawcom): • lokalizowanie najnowszych wersji opisów znanych usług, • odnajdywanie nowych usług sieciowych spełniających określone kryteria. Rozum ieli taką potrzebę projektanci pierwszej generacji usług sieciowych, czego owocem okazał się standard UDDI. I chociaż wciąż nie jest on powszechnie im plem entowany, stanowi model rejestracji usług, którem u warto poświęcić nieco uwagi. Prywatne i publiczne rejestry usług Na rysunku 5.18 przedstawiono schemat (względnie zaakceptowanego) specyfikowanego przez UDDI standardu strukturalizacji rejestru usług. Rejestr taki może być przeszukiwany ręcznie lub przetwarzany programowo za pośrednictwem standardowego API.

Usługa Rozwiązanie

Rysunek 5.18. Lokalizacje opisów usług scentralizowane w formie rejestru

W zależności od zakresu i dostępności rejestrowanej informacji, rejestry usług dzielą się na publiczne i prywatne. Rejestr publiczny to w zasadzie rejestr usług z podziałem na ich właścicieli. Dowolna organizacja po zarejestrowaniu swej tożsamości może rejestrować oferowane przez siebie usługi sieciowe; nie m a przy tym znaczenia, czy w momencie rejestracji oferuje ona już jakieś usługi, czy też nie. Rejestry prywatne implementowane są wewnątrz organizacji i pełnią rolę centralnych repozytoriów, zawierających opisy wszystkich usług, które dana organizacja opracowuje, kupuje lub dzierżawi. Poniżej przedstawiamy opis najważniejszych części rekordu rejestru w standardzie UDDI.

136

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

Encje biznesowe i usługi biznesowe Każdy rekord rejestru publicznego to w istocie obraz profilu encji biznesowej (business entity), zawierający podstawowe informacje na temat firmy (lub podmiotu-dostarczyciela usługi). W rekor­ dzie tym znajduje się jeden lub więcej obszarów usług biznesowych (business services), z których każdy zawiera opis usług oferowanych przez wspomniany podmiot. Obszary te mogą, lecz nie muszą, być powiązane z wykorzystywaniem usług sieciowych. Szablony wiązań i sekcje tModel Jak pamiętamy, w definicji WSDL opis interfejsu odseparowany jest od inform acji im plem en­ tacyjnych, w wyniku czego informacja na tem at interfejsu pozostaje bez związku z protokołem transportowym , z którym powiązany zostaje ten interfejs w czasie funkcjonowania usługi. Analo­ giczną koncepcję przyjęto w standardzie UDDI: informacje na temat powiązań usług z fizycznym środowiskiem znajdują się w osobnych obszarach rekordu UDDI, zwanych szablonami wiązań (binding templates). Każda pozycja reprezentująca usługę biznesową odwołuje się do jednego lub kilku szablonów wiązań. Informacja zawarta w szablonie wiązania może, lecz nie musi, odnosić się do konkretnej usługi: przykładowo może być wskazaniem adresu URL strony W W W. Jeśli jednak odnosi się do usługi sieciowej, odniesienie to m a postać tzw. sekcji tModel, będącej w istocie wskazaniem opisu wspomnianej usługi. Opisane zależności przedstawiono na rysunku 5.19.

Rekord rejestru UDDI

Rysunek 5.19. Podstawowa struktura rekordu encji biznesowej w rejestrze UDDI

UW AGA Nie om aw iam y w tej książce składni języka UDDI, zainteresowanych czytelników odsyłamy do tutoriala pod adresem w w w .w s-stand ards.com /uddi.

5 .3 . O PISY USŁUG (W JĘZYKU W SD L)

137

A N A LIZA PRZYPADKU

W firmie TLS prowadzi się równolegle wiele projektów programistycznych i integracyjnych, i niemal w każdym z tych projektów tworzone są nowe usługi — niektóre zgodnie z now o­ czesnymi zasadami zorientowania na usługi, inne na bazie adapterów „opakowujących” ele­ m enty tradycyjnych rozwiązań rozproszonych. Ubocznym efektem tej kreatywności jest wciąż powiększająca się pula usług, które wymknęły się spod kontroli: na spotkaniu podsum owują­ cym kończący się rok, podczas analizy podjętych w tym roku inicjatyw program istycznych skonstatowano, że wiele zespołów nieświadomie dubluje wysiłek partnerów i w efekcie po­ wstaje kilka usług o bardzo zbliżonej funkcjonalności. By powstrzymać tę niekorzystną ten­ dencję, utworzono w firmie prywatny rejestr usług, przedstawiony poglądowo na rysunku 5.20. Zespoły odpowiedzialne za jakiekolwiek aktywne usługi zobowiązane zostały do rejestrowania opisów tych usług, a sam proces rejestracji stał się obowiązkowym etapem jej cyklu życiowego.

Rysunek 5.20. Prywatny rejestr usług firmy TLS zawierający odnośniki do aktualnych definicji WSDL

P O D S U M O W A N IE •

Definicja WSDL podzielona jest na d w ie części — abstrakcyjną i skonkretyzowaną. Przedmiotem części abstrakcyjnej jest opis interfejsu usługi, zaś przedmiotem części skonkretyzowanej — informacja o lokalizacji usługi i protokole transportow ym używ anym przez komunikaty odbierane i w ysyłane przez usługę.

•

D wa inne, oprócz definicji WSDL, kluczowe elem enty opisu usługi to schematy XSD i dokum ent założeń polityki.

•

Opisy usług mogą być odnajdywane w sposób ręczny lub programowy, za pomocą prywatnych i publicznych rejestrów usług.

138

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

5 .4 . K o m u n ik o w a n ie w e d łu g SOAP Ponieważ całość komunikacji między usługami opiera się na kom unikatach, wybrany do tej ko­ munikacji framework musi być zestandaryzowany, by wszystkie usługi używały tego samego proto­ kołu komunikacyjnego, a wymieniane między nim i kom unikaty miały ustalony format. Ponadto na gruncie SOA projektowanie aplikacji jest tak dalece ukierunkowane na wymianę kom unika­ tów, że właśnie we w nętrzu kom unikatów lokowana jest coraz większa porcja logiki biznesowej i aplikacyjnej. W efekcie odebranie kom unikatu przez usługę staje się akcją o charakterze funda­ m entalnym , akcją zapoczątkowującą realizację elem entu logiki przetwarzania, a to stawia przed w spom nianym frameworkiem wymagania maksymalnej elastyczności i wysokiego stopnia rozsze­ rzalności. Specyfikacja SOAP wychodzi naprzeciw tym wymaganiom, bo opracowana została jako stan­ dardowy protokół komunikacyjny usług sieciowych i w tej roli została powszechnie zaakcepto­ wana. W porów naniu z pierwszą wersją została zmodyfikowana i poszerzona o nowe możliwości, a bardziej wyrafinowane struktury komunikatów znakomicie wpasowują się w potrzeby nowo­ czesnych aplikacji rozproszonych, szczególnie tych, które ewoluują w kierunku SOA. Om ówim y tu wysokopoziomowe koncepcje kryjące się za frameworkiem SOAP. Rozpocz­ niemy od zasad rządzących strukturą kom unikatów, po czym przedstawimy koncepcję węzłów SOAP i ich podział na typy. Rozdział zakończymy krótkim objaśnieniem ścieżek kom unikatów w powiązaniu z omówionymi poprzednio koncepcjami.

UWAGA Prezentow any w tym rozdziale opis protokołu SOAP nie jest tutorialem języka SOAP, zaw iera jedynie w y ­ brane koncepcje i term iny zw iązane z bieżącą treścią. W prow adzenie do języka SOAP odkładam y do punktu P odstaw y języka SOAP, w rozdziale 13.

PO PROSTU W ypełniliśm y już form ularz inform acyjny w ym a g an y przez agencję Reconnect i musimy go do tej agencji dostarczyć. Nie znam y jej adresu, a jedynie nazw ę, możem y jednak odszukać adres w książce telefonicznej. A potem napisać go na kopercie, w łożyć do koperty form ularz, zakleić kopertę, nakleić znaczek i wrzucić całość do najbliższej skrzynki pocztowej. Książka telefoniczna stanowi tu analogię rejestru usług, zaś adres agencji jest odpow iednikiem punktu końcow ego (portu) WSDL. Koperta reprezentuje natom iast standardo w e m edium transportu inform acji — podobnie jak SOAP, narzuca predefiniow any, standardow y form at na transportow ane komunikaty. W rzucając list do skrzynki pocztowej, pow ierzam y poczcie zadanie jego doręczenia do adresata; na tej samej zasadzie wnioskodawca usługi powierza protokołowi SOAP zadanie doręczenia wysłanego komunikatu do końcowego odbiorcy. Droga, którą odbędzie nasz list — od skrzynki pocztowej począwszy, na agencji Reconnect skończywszy — stanow i bliską analogię trasy komunikatu SOAP, w ędrującego od w nioskodawcy do dostarczyciela.

5 .4 . K O M U N IK O W A N IE W E D ŁU G SOAP

139

5.4.1. Komunikaty SOAP Mimo iż oryginalna nazwa kryjąca się za akronimem SOAP brzmi „Simple Object Access ProtocoF — prosty protokół dostępu do obiektów — w istocie nie jest to definicja protokołu, lecz standar­ dowego formatu komunikatów. Co prawda, oryginalnie specyfikowany format komunikatu SOAP jest banalnie prosty, lecz wynikające ze specyfikacji SOAP możliwości jego rozszerzania i konfi­ gurowania czynią cały system SOAP istnym m otorem napędowym współczesnej SOA i w pew­ nym sensie protoplastą wielu jej fundam entalnych cech. Zobaczmy więc nieco bliżej, jak kształ­ tuje się struktura kom unikatów SOAP.

UW AGA Nieadekwatność rozwinięcia Sim ple Object Access Protocoizostała oficjalnie uznana w wersji 1.2 specyfikacji SOAP — odtąd akronim ten funkcjonuje samodzielnie, bez kojarzenia z jakim kolw iek rozwinięciem.

Koperta, nagłówek i ciało komunikatu Każdy kom unikat SOAP opakowany jest w kontener nazywany kopertą (envelope). Metafora dość trafna, bo kontener ten odpowiedzialny jest za przechowywanie wszystkich części kom uni­ katu (patrz rysunek 5.21).

Rysunek 5.21. Podstawowa struktura komunikatu SOAP

Każdy komunikat może zawierać nagłówek (header) — obszar dedykowany przechowywaniu metaiformacji. W większości rozwiązań zorientowanych na usługi jest on żywotną częścią architektury, więc choć teoretycznie nie musi występować w komunikacie, jednak bardzo rzadko jest pomijany. Jego istotność wynika między innymi z faktu, że rozszerzenia standardowego formatu SOAP implemento­ wane są właśnie na bazie bloków nagłówka (za chwilę powrócimy do tej kwestii). Zasadnicza treść komunikatu znajduje się w jego ciele (body), które zwykle stanowią dane sformatowane zgodnie ze standardem XML; ciało komunikatu często bywa określane mianem ładunku użytecznego (payload).

140

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

Bloki nagłówka Podstawową przesłanką zastosowania SOAP jako frameworku komunikacyjnego SOA jest nafaszerowanie przesyłanych kom unikatów sporą dawką inteligencji i uczynienie ich możliwie sam o­ wystarczalnymi. Dzięki tem u poszczególne kom unikaty stają się w wysokim stopniu niezależne od siebie, dzięki czemu framework komunikacyjny zyskuje dużą niezawodność i duże możliwości rozszerzania — cechy nie do przecenienia w sytuacji, kiedy komunikaty wymieniane między usłu­ gami sieciowymi stanowią jedyny sposób ich (luźnego) powiązania. Niezależność kom unikatów osiągana jest głównie dzięki implementowaniu odpowiedniej metainformacji, kodowanej w blokach nagłówka koperty. Metainformacja wykorzystywana jest przez każdą usługę, jaką kom unikat napotyka na swej drodze i przez którą jest przetwarzany i (lub) trasowany zgodnie z zakodowanymi w nim regułami, instrukcjami i właściwościami. Nie sposób byłoby jej umieścić w ram ach kom unikatu, gdyby nie wspomniane bloki nagłówka. Opisany stan rzeczy uwalnia poszczególne usługi (i — oczywiście — ich projektantów) od utrzy­ mywania i przetwarzania logiki specyficznej dla komunikatów. A to znakomicie przyczynia się do realizacji fundam entalnych założeń współczesnej SOA — wieloużywalności, interoperacyjności i komponowalności. Projektowanie usług sieciowych znacznie się upraszcza, ponieważ różno­ rodna inform acja specyficzna dla konkretnych zastosowań m a jednolitą formę — skrywana jest w blokach nagłówków komunikatów; dzięki temu może być przetwarzana w ujednolicony sposób, niezależnie od swego specyficznego charakteru. Możliwości wynikające z wykorzystywania bloków nagłówka uczyniły framework usług sie­ ciowych rozszerzalną i komponowalną platformą obliczeniową klasy enterprise. Wszystkie niemal rozszerzenia WS-* implementowane są właśnie z użyciem bloków nagłówka (konkretne tego przy­ kłady przedstawimy w rozdziale 17.). Charakter informacji, którą znaleźć można w blokach nagłówków komunikatów SOAP, bywa wiel­ ce zróżnicowany — wśród najczęściej spotykanych przypadków wymienić należy przede wszystkim: • instrukcje przetwarzania, przeznaczone do wykonywania przez usługi pośredniczące lub odbiorców końcowych, • informację związaną z trasowaniem kom unikatu lub zaawansowaniem przetwarzania, • dane i param etry związane z zabezpieczeniem komunikatu, • wymagania niezawodności dotyczące dostarczenia kom unikatu do adresata, • informację związaną z kontekstem przetwarzania i zarządzaniem transakcjami, • dane korelacyjne (zazwyczaj identyfikatory wiążące komunikaty-odpowiedzi z odnośnymi kom unikatam i-żądaniami. Powyższa lista nie jest kom pletna ani nawet reprezentatywna, bo jej różnorodność ograniczo­ na jest jedynie inwencją projektantów usług. Co więcej, SOAP umożliwia rozpoznawanie i prze­ twarzanie bloków nagłówka oznaczonych jako opcjonalne, dzięki czemu kom unikaty mogą być wyposażone w informację charakterystyczną dla nowszych wersji usług.

UWAGA W spom niane instrukcje przetw arzania, które napotkać można w blokach nagłów ków SOAP, różnią się od in­ strukcji przetw arzania obsługiwanych natyw nie przez język XML.

5 .4 . K O M U N IK O W A N IE W E D ŁU G SOAP

141

ANALIZA PRZYPADKU

Faktury, jakie kontrahenci przesyłają firmie TLS, transmitowane są w opakowaniu kom uni­ katów, od których wymaga się obecności pewnych standardow ych bloków w nagłówku — inaczej kom unikaty te nie mogłyby być prawidłowo odbierane i przetwarzane przez usługę Płatność na konto. Oto co między innymi znajduje się wśród tych wymaganych bloków.: • Identyfikator korelacyjny, zgodny ze standardowym formatem, poszerzony o znacznik reprezentujący m om ent (datę i czas) wysłania komunikatu. Unikatowość tego znacznika (i w rezultacie całego identyfikatora) umożliwia powiązanie kom unikatu-żądania z ewentualną odpowiedzią. • Specyficzne dla firmy informacje, wykorzystywane do celów uwierzytelniania. Każdy dostawca ma swoje konto w systemie B2B firmy TLS i każdy transmitowany komunikat skojarzony musi być z kontem swego nadawcy. Usługa Płatność na konto odrzuca kom unikaty nieposiadające w nagłówku powyższych informacji, ponieważ są one nieodzowne do właściwego przetworzenia treści każdego z ko­ munikatów.

Style komunikatów Specyfikacja SOAP zaprojektowana została oryginalnie jako zastępnik własnościowych protoko­ łów RPC. Dane wymieniane między kom ponentam i miały najpierw być przekształcane („serializowane”) ze swej oryginalnej postaci do form atu XML, w tym formacie przesyłane, a po odebra­ niu przez adresata konwertowane („deserializowane”) na powrót do natywnego formatu. Istotą oryginalnej specyfikacji SOAP była zatem strukturalizacja danych RPC w postaci standardowych komunikatów. Komunikaty te, określane mianem komunikatów w stylu RPC, kontrastują wyraźnie z duchem SOA, czyli preferowaniem kom unikatów niezależnych i bardziej „inteligentnych” — komunika­ tów w stylu dokum entowym , czyli przenoszących w swym ciele kom pletne dokum enty i stąd wymienianych między usługami ze znacznie mniejszym natężeniem, w oparciu o bardziej „gru­ boziarniste” interfejsy.

UWAGA Nie należy mylić ko m unikatów SOAP w stylu dokum entow ym z tzw . dokum entam i X M L bazującym i na dokum encie ( docum ent-centric X M L , różniącymi się swą charakterystyką od dokum entów X M L bazują­ cych na danych (d a ta -ce n tricX M L , zawierających dane aplikacji1.

1 Cecham i charakterystycznym i dokumentów X M L bazujących na danych są: regularna struktura, rów nom ierna granulacja, jednorodna zawartość i nieistotność kolejności elementów. Dokum enty X M L bazujące na dokum en­ cie m ają naturę zgoła przeciw staw ną — nieregularną strukturę, nierów nom ierną granulację i niejednorodną zawartość, a kolejność elem entów m a istotne znaczenie — przyp. tłum.

142

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

A N A LIZA PRZYPADKU

Tradycyjnie wysłanie faktury przez RailCo do odbiorcy wiązało się z szeregiem interakcji z tym odbiorcą, m iędzy innym i z: • wygenerowaniem dokum entu-faktury i wysłaniem go przez pocztę, • wygenerowaniem wyciągu z konta (czyli zestawienia należności nieuregulowanych jeszcze przez odbiorcę) i wysłaniem go przez pocztę, • wygenerowaniem i wysłaniem przez pocztę informacji na temat polityki cenowej RailCo i zasad stosowania rabatu ilościowego, wraz ze wskazaniem, jak blisko stosowalności wspomnianego rabatu znajduje się dany odbiorca w świetle dokonanych dotychczas w RailCo zakupów. Gdy tradycyjną interakcję RailCo z TLS zastąpiła usługa Wystawienie faktury, wszystkie trzy wymienione powyżej dokum enty spakowane zostały w formę pojedynczego kom unikatu wysyłanego przez tę usługę (patrz rysunek 5.22).

Rysunek 5.22. Komasacja trzech dokumentów w formie jednego komunikatu, wykonywana przez usługę Wystawienie faktury

Załączniki W celu ułatwienia przesyłania danych trudno poddających się formatowaniu XML — plików binar­ nych, obrazów, dźwięków i podobnych — specyfikacja SOAP udostępnia technologie załączników (attachments), dające możliwość wbudowywania w kom unikaty SOAP danych w ich oryginalnym formacie.

5 .4 . K O M U N IK O W A N IE W E D ŁU G SOAP

143

ANALIZA PRZYPADKU

Zasady prow adzenia księgowości w firmie TLS nakazują, by każde zamówienie o wartości przekraczającej 100 000 USD potwierdzone było podpisem m enedżera wyższego szczebla. Ponadto takie zamówienie nie może być przetwarzane w standardowym formacie elektro­ nicznym, bo wspomnianym podpisem musi być opatrzona każda część dokumentu. Użytkowany aktualnie przez TLS system finansowo-księgowy oferuje możliwość skanowa­ nia dokumentów księgowych; zeskanowane obrazy przechowywane są na osobnym serwerze, a do każdego rekordu księgowego mogą być załączane URL-e identyfikujące lokalizację po­ wiązanych z tym rekordem skanów. Specjalnie opracowane rozszerzenie wspomnianego syste­ m u po wykryciu, że całkowita wartość zamówienia przekracza 100 000 USD, uruchamia najpierw scenariusz prowadzący do wydrukowania, przekazania do podpisu i zeskanowania dokumentu (przez operatora), po czym wywołuje alternatywną operację usługi Zlecenie zakupu i przeka­ zuje jej kopię skanu. Usługa generuje następnie komunikat, w którym kopia ta umieszczana jest jako załącznik.

Usterki Komunikaty SOAP oferują również możliwość wyposażania komunikatów w logikę obsługi ewen­ tualnych awarii i usterek, jakie mogą wystąpić przy przesyłaniu i przetwarzaniu tych komunikatów — związany z tym kod umieszczany jest w opcjonalnej sekcji fa u lt stanowiącej część ciała kom u­ nikatu. Zazwyczaj obsługa błędnej sytuacji polega na przekazaniu nadawcy kom unikatu zw rot­ nego informującego o fakcie wystąpienia usterki i dostarczającego dokładniejsze informacje o jej szczegółach.

ANALIZA PRZYPADKU

W spom niany w poprzedniej analizie przypadku kom unikat z załącznikiem zawiera także ob­ szar fa u lt z informacją o ewentualnych błędach związanych z tymże załącznikiem: w sytuacji, gdy odbiorca kom unikatu nie jest w stanie poprawnie przetworzyć załącznika lub poprawnie przekazać samego kom unikatu do następnej usługi, do TLS zwracany jest kom unikat zawie­ rający standardowy kod błędu wraz ze standardowym opisem.

5.4.2. Węzły SOAP Chociaż usługi sieciowe istnieją jako samodzielne i samowystarczalne jednostki logiki przetwa­ rzania, ich funkcjonowanie zapewnione jest przez fizyczną infrastrukturę komunikacyjną, odpo­ wiedzialną za wymianę kom unikatów SOAP między usługami i za zarządzanie tymi kom unika­ tami. Każda znana platform a posiada własną implementację serwera kom unikacyjnego SOAP, a różni dostawcy odm iennie oznaczają swe w arianty tego fragm entu oprogramowania. Na po­ ziomie abstrakcji program y wysyłające i odbierające kom unikaty SOAP na rzecz usług nazywane są węzłami SOAP (SOAP nodes). Relację między usługą, węzłem i komunikatem SOAP przedsta­ wiono schematycznie na rysunku 5.23.

144

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

N Usługa

Komunikat SOAP

\ Rysunek 5.23. W ęzeł SOAP jako narzędzie transmisji komunikatu SOAP przez usługę

Każdy węzeł SOAP, niezależnie od sposobu implementacji, musi być kompatybilny ze stan­ dardami przetwarzania ustalonymi w tej wersji specyfikacji SOAP, do zgodności z którą wspo­ m niana implementacja pretenduje. Zgodność ta jest niezbędna do zachowania ogólnej niezależ­ ności fram ew orku kom unikacyjnego SOA od konkretnej technologii — daje gwarancję, że kom unikat SOAP wysłany przez węzeł SOAP z inicjatywy jednej usługi będzie miał szansę po­ prawnego odebrania i przetw orzenia przez inny węzeł SOAP, działający na rzecz innej usługi (pod warunkiem jednak, iż oba węzły obsługują tę samą wersję standardu SOAP). Typy węzłów Podobnie jak usługi, tak i działające na rzecz usług węzły SOAP można zaklasyfikować w kategorii różnych typów, odzwierciedlających formę przetwarzania, w jaką zaangażowany jest dany węzeł w konkretnym scenariuszu obsługi komunikatu. Przedstawiona poniżej lista typów węzłów SOAP (zgodna ze standardowym modelem prze­ twarzania SOAP — SOAP Processing Model) bardzo jest podobna do analogicznej listy ról usług sieciowych, prezentowanej na początku tego rozdziału. W kontekście SOA term in „rola” m a jed­ nak inne znaczenie, a typy węzłów SOAP nazywane są koncepcjami (concepts). No więc — SOAP wyróżnia następujące koncepcje węzłów: • nadawca SOAP (SOAP sender) — to węzeł transmitujący komunikat, • odbiorca SOAP (SOAP receiver) — to węzeł odbierający komunikat, • pośrednik SOAP (SOAP intermediary) — to węzeł odbierający komunikat, być może przetwarzający go, a następnie transmitujący, • początkowy nadawca SOAP (initial SOAP sender) — węzeł transm itujący dany kom unikat jako pierwszy, • końcowy odbiorca SOAP (ultimate SOAP receiver) — węzeł odbierający dany kom unikat jako ostatni. Znaczenie poszczególnych koncepcji węzłów zilustrowano na rysunku 5.25.

5 .4 . K O M U N IK O W A N IE W E D ŁU G SOAP

145

A N A LIZA PRZYPADKU

Gdy usługa Wystawienie faktury w firmie RailCo wysyła kom unikat SOAP zawierający dokum ent-fakturę, odpowiedni serwer SOAP (będący początkowym nadawcą SOAP) dokonuje fizycznego przesłania tego kom unikatu za pośrednictwem protokołu HTTP. Aby usługa Płatność na konto w firmie TLS mogła otrzymać wspomniany komunikat, musi on najpierw zostać odebrany przez serwer SOAP (lub inny proces-obserwator) czyniący to za pośrednictwem protokołu HTTP (i będący końcowym odbiorcą SOAP). Uwidoczniono te zależności na rysunku 5.24.

RailCo

TLS

Rysunek 5.24. Umiejscowienie w ęzłów SOAP w schemacie transmisji komunikatu między RailCo a TLS

Pośrednicy SOAP Podobnie jak usługi m ogą pośredniczyć w transm isji kom unikatu między usługą-wnioskodawcą a usługą-dostarczycielem, tak węzły pośredniczące SOAP odpowiedzialne są za przetwarzanie komunikatu na jego drodze od węzła-nadawcy SOAP do węzła-odbiorcy SOAP (patrz rysunek 5.25). Podobnie do podziału usług pośredniczących na bierne i czynne, węzły pośredniczące SOAP dzielą się na forwardujące i aktywne. Pośrednik forwardujący odpowiedzialny jest jedynie za prze­ kazanie kom unikatu do następnego węzła. Często wiąże się to z przetwarzaniem lub modyfiko­ waniem bloków nagłówka zawierających logikę forwardowania, a być może również z usuwaniem bloków, które nie pow inny być dalej forwardowane. Pośrednik aktywny poddaje przekazywany kom unikat przetwarzaniu wykraczającemu wy­ raźnie poza logikę forwardowania: ingerencja w nagłówek komunikatu może być posunięta znacz­ nie dalej — węzeł może modyfikować istniejące bloki, usuwać je lub dodawać nowe, jak również wykonywać określone akcje dotyczące zarówno nagłówka, jak i ciała komunikatu.

146

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

Rysunek 5.25. Różne typy w ęzłów SOAP zaangażowanych w przetwarzanie komunikatu

5.4.3. Ścieżki komunikatów M ianem ścieżki kom unikatu określa się trasę, jaką pokonuje ten kom unikat od wysłania aż do dotarcia do miejsca przeznaczenia. W spom niana trasa musi więc zawierać co najmniej początko­ wego nadawcę i końcowego odbiorcę, a opcjonalnie może obejmować również pośredników (patrz rysunek 5.26). Mapowanie i modelowanie ścieżek komunikatów to jedno z coraz trudniejszych wyzwań związanych z SOA, jako że liczba i rozmiar pośredników wykazują tendencję wzrostową w miarę ekspansji rozwiązania zorientowanego na usługi. Założenia projektowe dotyczące trasy, jaką przebyć m a kom unikat, koncentrują się zwykle wokół niełatwych kwestii związanych z wy­ dajnością, bezpieczeństwem, zarządzaniem kontekstem i niezawodnością transmisji. Zwróćmy uwagę na ważny fakt, że ścieżka kom unikatu nie zawsze wyznaczona jest a priori: usługi pośredniczące mogą, opierając się na informacji zawartej w blokach nagłówka, dynamicz­ nie budow ać tę trasę (jak na rysunku 5.27) na podstawie logiki trasow ania, zaawansowanego przetwarzania czy bieżących warunków środowiskowych. Aby odróżnić ścieżkę kom unikatu ro ­ zum ianą (abstrakcyjnie) jako sekwencję usług od ścieżki kom unikatu rozumianej jako sekwencja węzłów SOAP, w tym drugim znaczeniu kwalifikujemy ją jako ścieżkę komunikatu SOAP (SOAP message path). I podczas gdy ścieżka kom unikatu w ujęciu abstrakcyjnym jest tworem czysto lo­ gicznym, z perspektywy SOAP jest ona wyznaczana przez rzeczywisty protokół transportowy jako sekwencja węzłów, rozpoczynająca się od początkowego nadawcy i kończąca na końcowym od­ biorcy; każdy węzeł skojarzony jest z fizyczną instalacją oprogramowania SOAP i posiada własny adres fizyczny.

5 .4 . K O M U N IK O W A N IE W E D ŁU G SOAP

Rysunek 5.26. Ścieżka komunikatu obejmująca trzy usługi sieciowe

Rysunek 5.27. Ścieżka komunikatu budowana dynamicznie w trakcie jego przesyłania

147

148

RO ZDZIAŁ 5. ■ USŁUGI S IEC IO W E A P IE R W O T N A SOA

ANALIZA PRZYPADKU

Różnicę między obydwoma znaczeniami ścieżki kom unikatu bardzo łatwo wyjaśnić m ożna w kontekście opisanego wcześniej scenariusza wystawiania faktury przez firmę RailCo dla firm y TLS. W ujęciu logicznym (abstrakcyjnym) ścieżka komunikatu jest zdeterminowana już w m o­ mencie rozpoczynania scenariusza. Usługa W ystawienie faktury w firmie RailCo pełni rolę początkowego nadawcy. W ysłany przez nią kom unikat trafia do następnego punktu — po­ średniczącej usługi Równoważenie obciążenia w firmie TLS. Usługa Równoważenie obcią­ żenia przyjmuje rolę wnioskodawcy i przekazuje kom unikat do usługi Płatność na konto, będącej jednocześnie końcowym odbiorcą. Mamy więc ścieżkę wyznaczoną przez trzy usta­ lone usługi. O dpow iadająca tem u logicznem u m odelow i fizyczna ścieżka SOAP nie jest ustalona a priori, ponieważ usługa Równoważenie obciążenia dynamicznie wyznacza serwer SOAP, którem u powierzony zostanie przedmiotowy kom unikat — w momencie, gdy kom unikat ten trafia do usługi Równoważenie obciążenia (pełniącej w tym momencie rolę dostarczyciela), węzeł SOAP, który stanie się końcowym odbiorcą SOAP, nie jest jeszcze znany.

PODSUMOW ANIE •

Fram ew ork komunikacyjny SOAP jest fizyczną realizacją abstrakcyjnego fram ew orku usług sieciowych jako zespołu w ęzłó w SOAP będących w istocie instancjami oprogram ow ania serwera SOAP.

•

Fram ew ork komunikacyjny SOAP jest urzeczywistnieniem idei „niezależnych jednostek komunikacji" w postaci kom unikatów w stylu dokum entow ym , o dużej objętości informacyjnej i rozszerzalnym formacie.

•

Fram ew ork komunikacyjny SOAP definiuje standardow ą strukturę kom unikatu, zaw ierającą rozszerzalną sekcję nagłów kow ą, w ykorzystyw aną przez w iele rozszerzeń W S-* do im plem entow ania m echanizm ów klasy enterprise.

Część II

SOA i rozszerzenia WS-* Rozdział 6. Usługi sieciowe i współczesna SOA (Część I. Zarządzanie aktywnościami i kompozycje) Rozdział 7. Usługi sieciowe i współczesna SOA (Część II. Zaawansowane komunikowanie, m etadane i bezpieczeństwo)

Materiał części I jest wystarczającym świadectwem tego, że SOA, choć prosta koncepcyjnie, w prak­ tycznej realizacji może szybko stać się bardzo skomplikowana. Po przypomnieniu przedstawionej charakterystyki współczesnej SOA najwyższy więc czas zakasać rękawy i rozpocząć zgłębianie taj­ ników tej skomplikowanej realizacji. Dobrym punktem wyjścia do tej eksploracji będzie analiza fram ew orku usług sieciowych, a konkretnie jego osadzenia w realiach specyfikacji drugiej generacji usług sieciowych, czyli w re­ aliach rodziny specyfikacji WS-*. Specyfikacje te to bodaj najbardziej interesująca (i w pewnym sensie — niepokojąca) część krajobrazu współczesnej SOA, podlegająca w dodatku nieustannej ewolucji. Jak wyjaśnialiśmy w rozdziale 4., poszczególne specyfikacje różnie torują sobie drogę do panteonu technik informatycznych. I, jak to w ewolucji, niektóre zyskują sobie trwałą akceptację, inne natom iast po pewnym czasie idą w zapomnienie. W następnych dwóch rozdziałach zajmiemy się szczegółowo koncepcjami wprowadzanymi przez reprezentatywną kolekcję specyfikacji WS-*. Większość z nich zajęła już swą ustabilizowaną pozycję w krajobrazie SOA; przyjrzyjmy się jednak również kilku nowym, które niedawno poja­ wiły się na horyzoncie. Wiele z cech i rozszerzeń opisywanych w specyfikacjach WS-* to reminiscencje mechanizmów stosow anych w tradycyjnych aplikacjach klasy enterprise; wiele innych m a jednak swe źródło w fundam entalnych zasadach zorientowania na usługi, bazuje na tych zasadach i w wielu przy­ padkach rozszerza je. Specyfikacje WS-*, poszerzając granice tego, co uważane jest za „zgodne z za­ sadami zorientowania na usługi”, poszerzają jednocześnie pole do popisu dla producentów, którzy taką zgodność swych produktów deklarują; tym samym stają się one głównym m otorem napędo­ wym rozwoju technologii składających się na implementacyjny krajobraz SOA. Poszczególne punkty poświęcone koncepcjom definiowanym przez specyfikacje WS-* wień­ czone są analizami przypadków, ilustrującymi związek tych koncepcji z wybranymi cechami współ­ czesnej SOA, wymienionymi w rozdziale 3., a którymi są: • luźne powiązanie, • komponowalność, • interoperacyjność, • wieloużywalność, • rozszerzalność, • możliwość swobodnego wyboru dostawców technologii, • wykrywalność, • polepszanie jakości usług. Związkiem specyfikacji WS-* z innym i cechami współczesnej SOA — i generalnie ogólnym wpływem WS-* na kształt ewolucji SOA — zajmiemy się w rozdziale 9. Ponieważ treść tej książki skupiona jest na koncepcyjnej stronie SOA, nie zajmujemy się tymczasowo szczegółami składni specyfikacji WS-* i definiowanych tam języków (tymi ostatnim i zajmować się będziemy w n a­ stępnych rozdziałach).

Co to je s t „ W S -*" ? Każdemu użytkownikowi systemów operacyjnych gwiazdka intuicyjnie kojarzy się z metasymbolem oznaczającym „cokolwiek” — vide szablonowe nazwy grup plików — zgodnie zatem z tą konwencją szablon „WS-*” jednoznacznie kojarzy się z grupą identyfikatorów (tytułów) rozpo­ czynających się przedrostkiem „WS-”. Faktycznie, znakomita większość specyfikacji usług siecio­ wych drugiej generacji tak właśnie jest zatytułowana (o czym m ożna się przekonać, oglądając przykładowe tytuły na stronie autora, pod adresem http://www.servicetechspecs.com/ws). Spe­ cyfikacje WS-* to milowy krok na drodze rozwojowej SOA: wyznaczają one kształt drugiej gene­ racji usług sieciowych, poszerzając fundam enty pierwszej generacji zbudowane na trium wiracie WSDL+SOAP+UDDI.

Usługi sieciowe i współczesna SOA (Część I. Zarządzanie aktywnościami i kompozycje) 6.1. Wzorce wymiany kom unikatów 6.2. Aktywności usług 6.3. Koordynacja 6.4. Transakcje niepodzielne 6.5. Aktywności biznesowe 6.6. Orkiestracje 6.7. Choreografie

154

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZARZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Model komunikacji międzyusługowej jest raczej prosty koncepcyjnie, czego nie da się już powie­ dzieć o jego im plementowaniu w dużej skali, zgodnie z zasadami zorientowania na usługi i przy spożytkowaniu potencjalnych korzyści z tych zasad wynikających. Działając zgodnie ze wspomnianymi zasadami, tworzymy rozwiązanie automatyzujące zada­ nia biznesowe w postaci kompozycji usług, które nie tylko kom unikują się na zasadzie luźnego powiązania, ale muszą komunikować się w sposób skoordynowany. W arunkiem niezbędnym zre­ alizowania takiej koordynacji jest zapewnienie globalnej kontroli nad frameworkiem kom unika­ cyjnym, w ram ach którego wymieniane są kom unikaty między usługami. Niezbędne do tego środki tkwią zarówno w specyfikacjach WS-*, jak i w konwersatywnej naturze samej SOA. W tym rozdziale wyjaśniamy kluczowe koncepcje składające się na model aktywności usług bazu­ jący na wymianie komunikatów, omawiamy także te koncepcje zaczerpnięte z WS-*, na bazie których implementowane są mechanizmy zarządzania wspomnianą aktywnością w ramach kompozycji usłu­ gowych. Jedne i drugie (wraz ze specyfikacjami, z których zostały zaczerpnięte) składają się na archi­ tekturę zorientowaną usługowo — komponowalną, rozszerzalną, skoordynowaną i zdolną do realizo­ wania procesów w sposób transakcyjny. Na rysunku 6.1 przedstawiono ogólny plan treści tego rozdziału w ujęciu strukturalnym, uwidoczniającym charakter zależności między poszczególnymi koncepcjami. Znaczenie tych koncepcji wyjaśniać będziemy na przykładach wybranych specyfikacji WS-* na różnych etapach ich przemysłowej akceptacji. Wykorzystamy w tym celu następujące specyfikacje: • WS-Coordination (wraz z typami koordynacyjnymi WS-AtomicTransaction i WS-BusinessActivity), • WS-BPEL (znaną także jako BPEL4WS), • WS-CDL (znaną także jako WS-Choreography). Jako że skupiać się będziemy wyłącznie na koncepcjach, nie przedstawimy w tym rozdziale żadnych konkretnych przykładów kodu. Przykłady takie, w językach WS-BPEL i WS-Coordination, znajdą czytelnicy w rozdziale 16. w ramach wprowadzającego tutoriala. UWAGA Pod koniec tego rozdziału przedstaw im y obraz koncepcyjny choreografii. Nie będziem y w ogóle om aw iać w tej książce języka WSCDL: jego specyfikacja źródłow a w ciąż jest niedojrzała, w ięc poziom koncepcyjny jest jedynym ad ekw atn ym ujęciem.

PO PROSTU

Omawiane w tym rozdziale nowe koncepcje zaczerpnięte z WS-* z pewnością zainteresują tych czytelników, którzy swe dotychczasowe doświadczenia wywodzą z technologii usług sie­ ciowych pierwszej generacji. Dla urozmaicenia lektury kontynuować będziemy, rozpoczętą w poprzednim rozdziale, naszą towarzyską historyjkę, wzbogacając ją w nowe wątki.

Analizy przypadków: W tym rozdziale jeszcze bardziej szczegółowo analizować będziemy procesy Wystawianie faktury i Zlecenie zakupu, identyfikując te ich aspekty, które odzwier­ ciedlają omawiane nowe koncepcje.

6 .1 . W ZO R C E W Y M IA N Y K O M U N IK A T Ó W

Wzorce MEP

155

Choreografia

Rysunek 6.1. Strukturalny obraz treści tego rozdziału

6 .1 . W z o rc e w y m ia n y k o m u n ik a tó w Każde zadanie, którego realizacja automatyzowana jest za pomocą usług sieciowych, jest specy­ ficzne zarówno pod względem logiki aplikacyjnej, jak i ról odgrywanych przez poszczególne usługi. Niezależnie jednak od tej specyfiki i od stopnia komplikacji wspomnianego zadania, zawsze reali­ zacja tegoż wiąże się z wymianą wielu kom unikatów między usługami. W ym iana ta m usi być skoordynowana — poszczególne kom unikaty muszą układać się w określone sekwencje, podpo­ rządkowane globalnemu zadaniu. Na rysunku 6.2 widoczny jest elementarny przykład takiego uporządkowania.

156

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Rysunek 6.2. Nie każda wymiana komunikatów między usługami wpisuje się w schemat „żądanie-odpowiedź"

Pewne scenariusze wymiany kom unikatów między usługami są na tyle powszechne, iż zakla­ syfikowane zostały jako wzorce wymiany komunikatów — w języku angielskim message exchange patterns, stąd powszechnie używany akronim MEP na ich oznaczenie, także w polskim wydaniu tej książki. Najbardziej znany i chyba najpowszechniej stosowany MEP to „żądanie-odpowiedź”: usługa-wnioskodawca wysyła kom unikat-żądanie do usługi-dostarczyciela, ta natom iast po po­ prawnym odebraniu rzeczonego kom unikatu wysyła do jego nadawcy komunikat-odpowiedź. Zdefiniowano wiele wzorców MEP, każdy stosownie do określonych potrzeb w zakresie kon­ kretnego scenariusza wymiany komunikatów. Zajmiemy się najbardziej reprezentatywnymi z nich jako bodaj najbardziej przydatnymi dla projektantów rozwiązań zorientowanych na usługi.

PO PROSTU Agencja Reconnect przysłała nam dobre wiadomości: odnalazła Chucka. M y czym prędzej umówiliśmy się z nim na spotkanie, by powspominać stare, dobre czasy. W czasie tego spotkania zaobserw ow ałem ciekaw e zjaw isko. Gdy Chuck pytał o coś Boba, ten zw ykle ochoczo odpow iadał; gdy jednak Chuck opow iadał Bobowi jakąś historyjkę, Bob kw itow ał tę opowieść zu­ pełnym milczeniem — no chyba że coś go w tej historyjce szczególnie zainteresow ało (zaczynałem w ów czas rozumieć, dlaczego Chuck nie był ostatnio zainteresowany utrzymywaniem jakichkolwiek kontaktów z Bobem). Opisana „pogaw ędka" Boba z Chuckiem to bliska analogia kilku w zorców MEP. Każdy MEP jest bytem incydentalnym, bo obejm uje jedną w ym ianę kom unikatów (zdań) między partneram i. Następstwo kolejnych MEP tw orzy (rozciągniętą w czasie) konwersację.

6.1.1. Prymitywne wzorce MEP Zanim jeszcze pojawiła się współczesna SOA, frameworki komunikacyjne tradycyjnych aplikacji budowane były w oparciu o rozm aite produkty kategorii middleware. Już wtedy kom unikacja między kom ponentam i odbywała się zgodnie ze wzorcami, które określane są mianem prymi­ tywnych MEP (primitive MEPs) lub pierwotnych MEP. Żądanie-odpowiedź To chyba najpopularniejszy MEP w środowiskach aplikacji rozproszonych, stanowiący bazę ko­ munikacji synchronicznej (równie dobrze jednak wzorzec ten może być stosowany w komunikacji asynchronicznej). Jak wynika z rysunku 6.3, wzorzec ten obejmuje prostą wymianę dwóch komuni­ katów, z których pierwszy (żądanie) wysyłany jest przez komponent źródłowy (usługę-wnioskodawcę) i odbierany przez komponent docelowy (usługę-dostarczyciela), natomiast drugi (odpowiedź) wy­ syłany jest w kierunku przeciwnym przez usługę-dostarczyciela po odebraniu pierwszego.

6 .1 . W ZO R C E W Y M IA N Y K O M U N IK A T Ó W

157

Rysunek 6.3. Wzorzec MEP „żądanie-odpowiedź"

Zauważmy, że wzorzec ten może wymagać pewnych m echanizm ów korelacyjnych, umożli­ wiających kojarzenie komunikatów-odpowiedzi z odnośnymi komunikatami-żądaniami. Koncepcję korelacji omawiamy w rozdziale 7.

A N A LIZA PRZYPADKU

W punkcie „Kompozycje usług”, w rozdziale 5., opisywaliśmy sytuację, w której usługa TLS Płatność na konto po otrzym aniu faktury elektronicznej od dostawcy zwraca się do usługi Profile dostawców z żądaniem zweryfikowania poprawności informacji zawartej w nagłówku faktury. Mamy tu do czynienia z klasycznym wzorcem „żądanie-odpowiedź” — usługa Płatność na konto wysyła swe żądanie do usługi Profile dostawców i oczekuje od niej odpowiedzi potwierdzającej, że informacje nagłówkowe identyfikujące dostawcę są poprawne i aktualne (patrz rysunek 6.4). Negatywny wynik tej weryfikacji powoduje, że proces Wystawianie faktury kończy awaryjnie swą pracę, a usługa Płatność na konto wysyła do nadawcy komunikatufaktury informację (komunikat) o odrzuceniu żądania.

Rysunek 6.4. Przykładowa wymiana komunikatów zgodnie ze wzorcem „żądanie-odpowiedź" między usługami Płatność na konto i Profile dostawców

158

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Odpal i zapomnij Ten asynchroniczny MEP odpowiada jednokierunkowej transmisji kom unikatu z pojedynczego źródła do jednego lub wielu miejsc przeznaczenia (patrz rysunek 6.5). Zależnie od liczby odbiorców docelowych, wyróżniamy trzy odmiany tego wzorca: • ukierunkowaną (single-destination) — jest tylko jeden odbiorca komunikatu, • rozgałęzioną (multicast) — istnieje predefiniowana grupa odbiorców komunikatu, • rozgłoszeniową (broadcast) — kom unikat wysyłany jest do szerszego kręgu odbiorców. Wzorzec wymiany komunikatów

i Usługa| wnioskodawca | mm i

h i

>'< i

Komunikat .odpal i zapomnij"

/

Usługa* dostarczyciel

Rysunek 6.5. Wzorzec „odpal i zapomnij"

Cechą charakterystyczną tego wzorca jest fakt, że nadawca komunikatu nie spodziewa się odpowiedzi. A N A LIZA PRZYPADKU

Usługa TLS Płatność na konto zaprojektowana została w ten sposób, że w przypadku nega­ tywnej weryfikacji nagłówka faktury wystawca tej faktury otrzymuje e-mailowe powiadomienie o tym fakcie. W tym celu usługa Płatność na konto wysyła kom unikat do usługi Powiada­ mianie — to usługa użytkowa, która zapisuje szczegóły komunikatu w tzw. dzienniku powia­ damiania. Właśnie w oparciu o rekordy tego dziennika generowane są wiadomości e-mailowe (wyjaśnimy to dokładniej w następnym przykładzie). Między wspomnianymi usługami prze­ syłany jest tylko jeden kom unikat, którego nadawca (usługa Płatność na konto) nie oczekuje żadnej odpowiedzi. Mamy więc do czynienia z typowym przykładem wzorca „odpal i zapomnij” w odmianie ukierunkowanej (patrz rysunek 6.6).

Rysunek 6.6. Jednostronne wysłanie komunikatu przez usługę Płatność na konto

6 .1 . W ZO R C E W Y M IA N Y K O M U N IK A T Ó W

159

Złożone wzorce MEP Zaprezentowane prymitywne wzorce MEP nie tylko ułatwiają realizację prostych zadań, lecz rów­ nież stanowić mogą części składowe wzorców bardziej skomplikowanych (complex MEPs). Kla­ sycznym przykładem takiego złożonego MEP jest model publikuj-subskrybuj (publish-and-subscribe); generalnie podejściami tego typu zajmować się będziemy w rozdziale 7., tu poprzestaniemy na pro­ stym przykładzie. W zorzec „publikuj-subskrybuj” definiuje nowe role dla usług zaangażowanych w wymianę komunikatów, czyli wydawcę (publisher) i subskrybenta (subscriber). W każdej z tych ról usługa może kom unikat zarówno wysyłać, jak i odbierać. Ten zdecydowanie asynchroniczny MEP czyni zadość wymaganiu, by kom unikaty wydawcy dostępne były dla grupy subskrybentów zaintereso­ wanych ich odbiorem. Scenariusz realizujący ten wzorzec wygląda zwykle mniej więcej tak. 1. Subskrybent wysyła do wydawcy kom unikat-powiadomienie, iż jest zainteresowany otrzy­ mywaniem od tegoż wydawcy kom unikatów o określonej tematyce czy kategorii. 2. Gdy tylko wydawca wejdzie w posiadanie informacji interesującej zarejestrowanych sub­ skrybentów, przekazuje (w formie komunikatów) tę informację subskrybentom. Rzut oka na rysunek 6.7 pozwala zrozumieć, dlaczego ten MEP należy do wzorców złożonych i jak kom ponują się weń składowe wzorce prymitywne. • Krok 1. wzorca „publikuj-subskrybuj” może zostać zaimplementowany jako wzorzec „żądanie-odpowiedź”. Komunikat-żądanie wysyłany jest przez subskrybenta, który w ten sposób wyraża zamiar ustanowienia subskrypcji; wydawca potwierdza ustanowienie subskrypcji, wysyłając komunikat-odpowiedź. • W kroku 2. wzorca „publikuj-subskrybuj” obserwujemy serię kom unikatów wysyłanych przez wydawcę do poszczególnych subskrybentów; rozpoznajemy tu rozgałęzioną odmianę wzorca „odpal i zapom nij”.

Rysunek 6.7. Złożony MEP „publikuj-subskrybuj" jako kompozycja dwóch prymitywnych MEP

160

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Wśród specyfikacji WS-* wykorzystujących MEP „publikuj-subskrybuj” wymienić należy przede wszystkim: • WS-BaseNotification, • WS-BrokeredNotification, • WS-Topics, • WS-Eventing. Koncepcje definiowane w treści tych specyfikacji omawiamy w punkcie „Powiadomienia i zdarzeniowanie”, w następnym rozdziale. A N A LIZA PRZYPADKU

Użytkowa usługa Powiadamianie w firmie TLS okresowo generuje i rozsyła komunikaty o róż­ norodnym znaczeniu. Szczególnie wtedy, gdy wykryty zostanie problem dający się skojarzyć z konkretnym kontem kontrahenta (na przykład niepoprawna okaże się informacja o kon­ trahencie zawarta w nagłówku faktury — o czym pisaliśmy w dwóch poprzednich analizach przypadków), usługa Powiadamianie odnotowuje ten fakt w repozytorium powiadomień de­ dykowanym tem u kontu. Na zakończenie dnia roboczego repozytorium każdego z kont jest skanowane na obecność odrzuconych faktur. Następnie usługa Powiadamianie sporządza przekrojowy raport zarejestrowanych zdarzeń w podziale na predefiniowane kategorie i rozsyła ten raport (pod postacią komunikatu w trybie rozgłoszeniowym) do zainteresowanych subskrybentów, którymi w większości są specjalizowane usługi księgowe (patrz rysunek 6.8). Te z kolei stosownie przetwarzają otrzymywane raporty, niektóre wysyłają też wiadomości e-mail do wybranych pracowników księgowości.

Rysunek 6.8. Usługa Powiadamianie wysyła komunikaty powiadamiające subskrybentów o zaistniałych problemach

6 .1 . W ZO R C E W Y M IA N Y K O M U N IK A T Ó W

161

Kilka innych aplikacji zintegrowanych z systemem księgowym TLS umożliwia subskry­ bentom (którymi są zarówno ludzie, jak i usługi) ustanawianie i anulowanie subskrypcji zwią­ zanych z poszczególnymi kategoriami informacji.

6.1.2. Wzorce MEP i SOAP Standard SOAP sam z siebie stanowi mechanizm organizujący przesyłanie pojedynczych kom u­ nikatów, jednak jego rozszerzalna natura pozwala na implementowanie niezliczonych cech cha­ rakterystycznych i specyficznego zachowania (między innymi związanego ze wzorcami MEP) za pomocą bloków nagłówkowych. Język SOAP umożliwia również (przy użyciu opcjonalnego pa­ ram etru) identyfikowanie konkretnych MEP skojarzonych z poszczególnymi komunikatami.

6.1.3. Wzorce MEP i WSDL Częścią definicji operacji w opisach usługi są definicje komunikatów, których wymiana stanowi realizację zadania przypisanego do danej operacji. Wzorce MEP odgrywają ważną rolę w opisach WSDL, ponieważ zapewniają koordynację komunikatów związanych z poszczególnymi operacjami. Kojarzenie wzorców MEP z operacjami WSDL niejako wbudowuje w interfejsy usług konwersacyjne zachowanie, tak pożądane z perspektywy SOA. Operacje WSDL przewidują rozmaite konfiguracje komunikatów przychodzących (incoming), wychodzących (outgoing) i awaryjnych fault). Konfiguracje te są odpowiednikami wzorców MEP, więc w specyfikacji WSDL określane są krótko jako wzorce (patterns). Należy w tym miejscu podkreślić, że dla definicji WSDL wzorce predefiniowane w specyfikacji stanowią jedynie pewne „m inim um konwersacyjne” i m ogą być rozbudowywane — a zatem nie stanowią dla definicji WSDL czynnika ograniczającego. W wersji 1.1 specyfikacji WSDL definiowane są cztery wzorce wymiany komunikatów, w przy­ bliżeniu odpowiadające wzorcom MEP opisywanym w poprzednich punktach tego rozdziału. Wzorce te mogą być zaprzęgnięte do definiowania operacji z perspektywy usługi-dostarczyciela lub punktu końcowego. W terminologii wspomnianej wersji specyfikacji przedstawiają się one następująco. • Operacja „żądanie-odpowiedź” (Request-response operation) — po odebraniu kom unikatu usługa musi wysłać komunikat-odpowiedź lub komunikat-awaryjny. • Operacja z zamówioną odpowiedzią (Solicit-response operation) — po wysłaniu kom unikatu do wnioskodawcy usługa oczekuje standardowego komunikatu-odpowiedzi lub kom unikatu awaryjnego. • Operacja jednokierunkowa (One-way operation) — usługa oczekuje pojedynczego kom unikatu i nie jest zobligowana do odpowiedzi. • Operacja powiadomienia (Notification operation) — usługa wysyła kom unikat i nie jest przygotowana na jakąkolwiek odpowiedź. Spośród wymienionych wzorców (zilustrowanych na rysunku 6.9) w dokumentacji WS-I Basic Profile zalecane jest używanie tylko operacji „żądanie-odpowiedź” i operacji jednokierunkowej.

162

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Rysunek 6.9. Cztery podstawowe wzorce wymiany komunikatów opisywane w specyfikacji WSDL 1.1

Jak więc widać, WSDL od początku dostarczał wsparcie dla podstaw ow ych MEP. Nowsze wersje specyfikacji WSDL poszerzają to wsparcie o dodatkowe wzorce. W wersji 2.0 spotykamy osiem następujących wzorców (zwróćmy uwagę na zmianę term inologii)1. • in-out, porównywalny z MEP „żądanie-odpowiedź” i odpowiadający operacji „żądanie-odpowiedź” w wersji 1.1. • out-in, stanowiący odwrócenie poprzedniego wzorca: usługa-dostarczyciel inicjuje wymianę wysłaniem kom unikatu-żądania; to odpowiednik operacji z zamówioną odpowiedzią w wersji 1.1. • in-only, bliski odpowiednik wzorca MEP „odpal i zapom nij” i operacji jednokierunkowej w wersji 1.1. • out-only, stanowiący odwrócenie wzorca in-only: jest odpowiednikiem operacji-powiadomienia w wersji 1.1 i wykorzystywany głównie na potrzeby powiadamiania o zdarzeniach. • robust in-only, odm iana wzorca in-only, dostarczająca opcję wysłania kom unikatu awaryjnego w sytuacji wystąpienia błędu transmisji lub błędu przetwarzania. • robust out-only, odm iana wzorca out-only: kom unikat wychodzący inicjuje transmisję, a odbiorca tego kom unikatu może wysłać zwrotny kom unikat awaryjny. • in-optional-out, podobny do wzorca in-out, z jedną ważną różnicą: dostarczenie zwrotnego kom unikatu-odpow iedzi jest opcjonalne i jako takie nie może być wymagane przez usługę-wnioskodawcę inicjującą komunikację. Usługa powinna być jednak przygotowana na nadejście wspomnianej odpowiedzi. W zorzec ten przewiduje ponadto generowanie kom unikatu awaryjnego. • out-optional-in, odwrotność wzorca in-optional-out — kom unikat przychodzący jest opcjonalny. Podobnie jak w przypadku wzorca in-optional-out, przewidziane jest wygenerowanie kom unikatu awaryjnego.

1 Nie spotkałem polskich odpowiedników; byłoby nieuzasadnionym sileniem się na oryginalność ich wymyślanie w sytuacji, gdy nazewnictwo anglojęzyczne jest wystarczająco czytelne. Pozostawiam zatem wersję oryginalną — przyp. tłum.

6 .2 . A K TY W N O Ś C I USŁUG

163

Co prawda, wymienione wzorce zyskają naprawdę na znaczeniu dopiero wówczas, gdy roz­ powszechni się wykorzystywanie specyfikacji WSDL 2.0., tak czy inaczej warto jednak mieć roze­ znanie, w którym kierunku zmierza jeden z kluczowych standardów.

UW AGA Obecna wersja 2.0 specyfikacji WSDL początkowo oznaczona była numerem 1.2, opracowująca ją grupa robocza uznała jednak, że zakres dokonanych w specyfikacji zmian uzasadnia inkrementację głównego numeru wersji i tak z wersji 1.2 zrobiła się momentalnie wersja 2.0. Mimo to, gdzieniegdzie można jeszcze spotkać odwołania do wersji 1.2. Niezależnie od oznaczenia — 1.2 czy 2.0 — ta nowa wersja nie jest jeszcze powszechnie wykorzystywana, a jej szczegóły zaprezentowano tutaj głów nie dla zilustrowania rozszerzalności zastosowań wzorców MEP.

6.1.4. Wzorce MEP a SOA W zorce MEP są w swej naturze abstrakcyjne i wysoce generyczne, bo w istocie reprezentują inte­ rakcję dwóch usług. Związek wzorców MEP z SOA uwidacznia się poprzez ich odniesienie do abstrakcyjnego frameworku usług sieciowych — są one fundam entalną częścią dowolnego śro­ dowiska bazującego na usługach sieciowych, a szczególnie środowiska SOA. P O D S U M O W A N IE •

W zorzec MEP to abstrakcyjny wzorzec interakcji między dw iem a usługami, definiujący w ym ianę kom unikatów między nimi.

•

Wzorce MEP w yw o d zą się z tradycyjnych aplikacji rozproszonych, w których komunikacja między kom ponentam i organizowana była przez dedykow ane oprogram ow anie m iddlew are. Od tego czasu ukształtowało się kilka powszechnie używanych w zorców .

•

Proste (prym ityw ne) w zorce MEP mogą być kom ponow ane do postaci w zorców złożonych.

•

Specyfikacje WSDL i SOAP definiują w łasne odm iany podstawowych MEP.

6 .2 . A k ty w n o ś c i usług Oczywistą funkcją każdego rozwiązania automatyzacji jest wykonanie określonego zadania bizne­ sowego. Zadania biznesowe sterowane są logiką przetwarzania, której realizacja służy spełnieniu określonych wymagań biznesowych. W rozwiązaniach zorientowanych na usługi każde zadanie wykonywane jest na bazie pewnej liczby współdziałających ze sobą usług. Interakcja w ram ach grupy usług podporządkowanych wykonaniu pewnego zadania określana jest mianem aktywności usług (service activity). Przykład takiej aktywności widzimy na rysunku 6.10.

Rysunek 6.10. Aktywność usług jako współdziałanie usług w realizacji wspólnego zadania

164

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

UWAGA Choć term in „aktywność" (a c tiv ity nie jest form alnie zdefiniow any, używa go kilka specyfikacji cytowanych w tej książce w znaczeniu logicznej jednostki pracy w ykonyw anej przez kolekcję usług.

PO PROSTU Dow olne zadanie w ykonyw ane jest w postaci ciągu kroków (w szczególności — pojedynczego kroku). Przy­ kładowo zadanie włączenia telew izora to sekwencja dwóch banalnych kroków: 1.

znajdź pilota,

2.

naciśnij przycisk zasilania.

Zadanie umycia samochodu jest jednak skom plikow ane odrobinę bardziej: 1.

znajdź w iadro.

2.

znajdź gąbkę,

3.

znajdź końcówkę w ęża,

4.

napełnij w iadro ciepłą w odą,

5.

dolej płynu czyszczącego do w ody,

6.

zamocz gąbkę,

7. w ytrzyj gąbką karoserię, ... i ta k dalej. Kroki powyższego scenariusza można pogrupować w elem entarne zadania: 1.

skompletuj niezbędne wyposażenie,

2.

przygotuj roztw ór czyszczący,

3.

umyj karoserię.

Każde z tych trzech prostych zadań składa się z mniejszej liczby kroków niż oryginalne monolityczne zadanie w pierwszej wersji. Żadne z tych trzech prostych zadań nie ma samodzielnej racji bytu, choćby z tego względu, że rozpoczęcie każdego z nich (oczywiście, z w yjątkiem pierwszego) uw arunkow ane jest zakończeniem po­ przedniego; dopiero potraktowanie ich jak jednostek bardziej skomplikowanego zadania nadaje im sens. Podobnie większość zadań biznesowych, autom atyzow anych za pomocą aplikacji zorientowanych na usługi, reprezentuje złożoną aktyw ność angażującą w iele usług, z których każda odpow iedzialna jest za w y ­ konanie pewnej części zadania.

6.2.1. Proste i złożone aktywności usług Aktywność usług może m ieć różny wymiar. Aktywność prosta może reprezentować synchro­ niczną wymianę kom unikatów między dwiema usługami, zgodnie ze standardowym MEP „żąda­ nie-odpowiedź” (patrz rysunek 6.11). Aktywności takie są niemal zawsze krótkotrwałe — czas ich trwania ogranicza się do czasu wykonania MEP. Dla odmiany, złożone aktywności obejmować mogą wiele usług (i wiele wzorców MEP) współ­ pracujących w realizacji wielu etapów przetwarzania, w dłuższym okresie czasu (patrz rysunek 6.12). Bardziej wyrafinowane typy aktywności strukturalizowane są zazwyczaj według koncepcji stero­ wanych rozszerzeniami i zorientowanych kompozycyjnie, między innymi choreografii i orkiestracji, niemniej jednak także zadanie realizowane jako ciąg specyficznych usług, niepowiązanych w kompozycję, może być zaklasyfikowane jako aktywność złożona.

6 .2 . A K TY W N O Ś C I USŁUG

165

Rysunek 6.11. Prymitywna aktywność składająca się z pojedynczego MEP

Rysunek 6.12. Aktywność złożona, angażująca cztery usługi

6.2.2. Aktywności usług a SOA Na gruncie SOA aktywności reprezentują każdą interakcję między usługami wymaganą do reali­ zowania złożonych zadań biznesowych. Zakresem aktywności usług jest przede wszystkim ko­ munikacja między nim i — wewnętrzna logika każdej z usług generalnie nie jest postrzegana jako część aktywności, niezależnie od tego, czy usługa ta zawiera pojedynczy kom ponent, czy też sta­ nowi otoczkę-adapter kom pletnego tradycyjnego systemu. Aktywności złożone są naturalnym zjawiskiem w wielkoskalowych rozwiązaniach zorientowanych na usługi, mogą one angażować wiele usług uczestniczących.

UW AGA Często spotykany angielski term in Web services a c tiv ity może w ystępow ać w dwóch różnych znaczeniach: może określać bądź to aktyw n o ść usług, bądź też zw iązane z usługami sieciowymi działania prowadzone przez liczne grupy robocze W 3C.

166

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

A N A LIZA PRZYPADKU

Ścieżka, jaką przebywa kom unikat niosący fakturę wystawioną przez RailCo jest znakomitym przykładem aktywności złożonej. Przypom nijm y sobie proces Wystawianie faktury, opisywany w rozdziale 5. 1. Nadawca początkowy, którym jest usługa Wystawienie faktury, wysyła kom unikat zawierający dokum ent faktury. 2. Kom unikat ten zostaje odebrany przez bierną usługę pośredniczącą TLS Równoważenie obciążenia, która wyznacza dalszą trasę kom unikatu, stosownie do bieżących warunków środowiskowych. Niezależnie od kształtu tej trasy, kom unikat dociera do usługi Płatność na konto. 3. Usługa Płatność na konto działająca jako kontroler kompozycji inicjuje przetworzenie kom unikatu otrzymanego przez tę kompozycję. Pierwszą czynnością w ram ach tej inicjacji jest wywołanie usługi Profile dostawców w celu zweryfikowania poprawności nagłówka faktury i powiązania jej z konkretnym kontem dostawcy. 4. Po pozytywnym wyniku weryfikacji, o której mowa w punkcie 3., usługa Płatność na konto dzieli kwotę faktury na kwotę zasadniczą, koszty dostawy i podatek VAT, po czym przekazuje te wartości usłudze Rejestr księgi głównej, która aktualizuje stany różnych kont, w tym księgi głównej. 5. O statnim etapem aktywności jest wysłanie przez usługę Płatność na konto komunikatu-odpowiedzi do usługi RailCo Wystawienie faktury. Mamy zatem do czynienia z aktywnością złożoną, obejmującą pięć usług (patrz rysunek 6.13).

Rysunek 6.13. Przykładowa aktywność złożona rozciągająca się na obszar usług RailCo i TLS

6 .3 . KOO R D YN A C JA

167

P O D S U M O W A N IE •

Aktywność to abstrakcyjna koncepcja w ykorzystyw ana do reprezentow ania zadania lub jednostki pracy, w ykonyw anej przez zespół usług.

•

Czas trw ania prostych aktywności może być ograniczony do pojedynczych w zorców MEP.

•

Aktywności złożone są naturalnym i zjawiskam i na gruncie SOA i spotykane są w e wszystkich niebanalnych aplikacjach zorientowanych na usługi.

6 .3 . K o o rd y n a c ja Każda aktywność wprowadza pewien stopień kontekstowości do środowiska wykonawczego apli­ kacji — pod tym pojęciem rozum iem y informację związaną z czymkolwiek, co zdarza się w czasie wykonywania aplikacji i jest znaczące dla jej istnienia. Im bardziej skom plikow ana jest aktywność, tym zwykle większa jest ilość związanej z nią inform acji kontekstowej. W spom niana „komplikacja” może wyrażać się w postaci rozm aitych czynników, między innym i takich jak: • liczba i złożoność usług uczestniczących w aktywności, • czas trwania aktywności, • częstotliwość, z jaką zmienia się natura aktywności, • zdolność istnienia aktywności jednocześnie w wielu instancjach. Konieczny jest więc framework realizujący zarządzanie informacją kontekstową w skompli­ kowanych aktywnościach, jej przechowywanie i (lub) aktualizowanie oraz rozprowadzanie wśród usług zaangażowanych w aktywność. Fram ework taki ustanowiony jest za pomocą koordynacji (patrz rysunek 6.14).

Usługa A /

J

|v \

.Zapraszam ciędo

Rysunek 6.14. Koordynacja dostarcza usługi nakładające kontrolowaną strukturę na aktywności

168

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

UWAGA W tym punkcie przedstaw iam y koncepcje zaczerpnięte ze specyfikacji W S-Coordination. W rozdziale 16., w punkcie „W S-Coordination — przegląd", znajdą czytelnicy przykłady n a g łó w kó w SOAP związanych z tą specyfikacją.

PO PROSTU Chuck, Bob i Jim przegrali ze mną zakład i tym razem to oni um yją mój samochód. Gdy już oswoili się z tą perspektyw ą, przydzieliłem im zadania: Chuck — skompletuje wyposażenie, Bob — przygotuje roztw ór do mycia, Jim — umyje karoserię. Jak pam iętam y, każde z tych odpow iedzialnych zadań składa się z szeregu kroków — przykładow o Chuck pow inien: 1.

znaleźć w iadro,

2.

znaleźć gąbkę,

3.

zlokalizować końcówkę w ęża.

N iew ątpliw ie zakończenie kroku 1. jest konieczne, by swe zadanie mógł rozpocząć Bob (musi przecież dyspo­ nować wiadrem), ponadto Jim nie może rozpocząć swego zadania, zanim nie ukończą swych zadań Chuck i Bob. Zauważm y jednak, że Bob nie musi czekać z rozpoczęciem swego zadania do czasu, aż zadanie swe wykona cał­ kowicie Chuck — Bob może zacząć przygotowywanie roztworu do mycia, gdy tylko Chuck dostarczy wiadro, czyli zrealizuje tylko 1. krok swego zadania. I w czasie, gdy Chuck będzie szukał gąbki, Bob może już mieszać płyn czysz­ czący z wodą. Skorzysta na tym Jim, bo ze względu na tę równoczesność Chuck i Bob wcześniej zakończą swe zadania. Aby ta akcja mogła się udać, Chuck musi poinformować Boba, że odnalazł w iadro i Bob może już nalewać w odę. Ponieważ tak się złożyło, że Bob gdzieś się chw ilow o zawieruszył, a Chuck nie ma ochoty ani czasu go szukać, Chuck powierza mi misję przekazania Bobowi tej optymistycznej wiadomości i zabiera się za szukanie gąbki. A ja, gdy tylko ujrzę Boba, przekażę mu w iadro. W opisanym scenariuszu status dostępności rzeczonego w iadra może być uw ażany za informację kon­ tekstow ą, której zarządzanie jest moim obowiązkiem . Ja pełnię rolę menedżera kontekstu, uwalniając Chucka od komunikowania informacji kontekstowej bezpośrednio Bobowi ^znalazłem w iadro, gdzie jesteś?"), co po­ zwala mu kontynuow ać w łasne zadanie. M oje działanie uwalnia rów nież Boba od bezpośredniego kom uni­ kowania się z Chuckiem w spraw ie w spom nianej informacji kontekstowej ^znalazłeś już wiadro?"). Dostępność przedm iotow ego w iadra nie jest jedynym elem entem informacji kontekstowej; na informację tę składa się także moja w iedza na tem at tego, jakie poszczególnym kolegom przypadają zadania w dziele usuwania z karoserii mojego auta komprom itującego napisu „BRUDAS".

6.3.1. Kompozycja koordynatora Specyfikacja W S - C o o r d in a tio n ustanawia framework wprowadzający generyczną usługę bazującą na m o d e l u u s ł u g i - k o o r d y n a t o r a ( c o o r d in a to r s e rv ic e m o d e l) zilustrowanym na rysunku 6.15. W spom niana usługa jest kontrolerem kompozycji zawierającej jeszcze trzy inne usługi, z których każda realizuje specyficzną część zarządzania danym i kontekstow ym i. W skład w spom nianej kompozycji wchodzą cztery następujące usługi:

6 .3 . KOO R D YN A C JA

169

• usługa aktywacyjna (activation service), odpowiedzialna za tworzenie nowego kontekstu i kojarzenie go z konkretną aktywnością; • usługa rejestracyjna (registration service), umożliwiająca uczestniczącym usługom wykorzystywanie informacji kontekstowej otrzymywanej od usługi aktywacyjnej i rejestrowanie tej informacji w dostępnych protokołach kontekstowych; • usługi specyficzne dla protokołów (protocol-specific services), reprezentujące protokoły obsługiwane przez typ koordynacyjny koordynatora (wyjaśnimy dokładniej tę kwestię w następnych punktach); • koordynator (coordinator), nazywany także usługą koordynacyjną (coordination service), pełniący rolę kontrolera całej kompozycji.

6.3.2. Typy koordynacyjne i protokoły koordynacyjne Każdy koordynator funkcjonuje w oparciu o pewien typ koordynacyjny, określający naturę i we­ wnętrzną logikę aktywności, której zarządzaniu podlega informacja kontekstowa. Typy koordyna­ cyjne definiowane są w odrębnych specyfikacjach. Framework WS-Coordination jest rozszerzalny i może być wykorzystywany przez wiele różnych typów koordynacyjnych i doraźne odmiany tychże, zdecydowanie najczęściej jednak używane są dwa: WS-AtomicTransaction oraz WS-BusinessActivity — ich szczegółami zajmiemy się w odnośnych punktach tego rozdziału. Typy koordynacyjne dostarczają zbiór protokołów koordynacyjnych, określających specy­ ficzne reguły i zasady zachowania dla usług uczestniczących. Każdy taki protokół może być uwa­ żany za kreatora zasad dla aktywności oraz zarejestrowanych w niej usług.

6.3.3. Kontekst koordynacji i uczestnicy koordynacji K ontekst utw orzony przez usługę aktywacyjną nazywany jest kontekstem koordynacyjnym (coordination context). Zawiera on kolekcję informacji reprezentującej odnośną aktywność i róż­ norodne dane dodatkowe. Przykładami tych danych mogą być:

170

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZARZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

• unikatowy identyfikator reprezentujący aktywność, • okres ważności kontekstu, • informacja o typie koordynacyjnym. Usługa zamierzająca partycypować w aktywności zarządzanej przez WS-Coordination musi zażądać kontekstu koordynacyjnego od usługi aktywacyjnej. Następnie może wykorzystać ten kontekst do zareje­ strowania w ramach jednego lub wielu protokołów koordynacyjnych. Usługa, która w ten sposób otrzy­ ma kontekst i dopełni rejestracji, staje się usługą-uczestnikiem (participant) koordynowanej aktywności.

6.3.4. Aktywacja i rejestracja Kompozycja usługi koordynacyjnej zostaje uformowana, gdy usługa aplikacji kontaktuje się z usługą aktywacyjną (patrz rysunek 6.16). Za pomocą komunikatu CreateCoordinationContext wspomniana usługa aplikacji żąda od usługi aktywacyjnej wygenerowania zbioru nowych danych kontekstowych. Po otrzymaniu tych danych za pośrednictwem komunikatu ReturnContext usługa aplikacyjna może teraz „zapraszać” inne usługi do partycypowania w koordynacji. Każde takie zaproszenie zawiera in­ formację kontekstową, którą usługa aplikacji otrzymała oryginalnie od usługi aktywacyjnej.

Rysunek 6.16. Proces rejestracyjny wg specyfikacji WS-Coordination

6 .3 . KOO R D YN A C JA

171

Dowolna usługa sieciowa, będąca w posiadaniu wspomnianej informacji kontekstowej, może wystosować żądanie rejestracji do usługi rejestracyjnej; pozwala jej to na dołączenie do koordyna­ cji bazującej na konkretnym protokole (protokoły koordynacyjne omawiać będziemy dalej w tym rozdziale, w punktach „Transakcje niepodzielne” i „Aktywności biznesowe”). Po pomyślnym za­ rejestrowaniu usługa staje się oficjalnym uczestnikiem aktywności koordynowanej przez proto­ kół. Usługa rejestracyjna przekazuje jej lokalizację usługi koordynacyjnej, a usługa koordynacyjna poinform owana zostaje o adresie nowego uczestnika.

6.3.5. Zakończenie koordynacji Usługa aplikacji może zażądać zakończenia (completion) koordynacji, wysyłając w tym celu od­ powiednie żądanie (completion request) do usługi koordynacyjnej; ta z kolei wysyła własne żąda­ nie zakończenia do wszystkich usług uczestniczących w koordynacji. Każda z usług-uczestniczek odsyła w odpowiedzi kom unikat-potwierdzenie zakończenia (completion acknowledgement). Scenariusz ten zilustrowano na rysunku 6.17.

Usługa koordynacyjna

Rysunek 6.17. Proces zakończenia koordynacji wg specyfikacji WS-Coordination

172

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

6.3.6. Koordynacja a SOA Framework zarządzania informacją kontekstową koordynacji, w postaci definiowanej przez spe­ cyfikację WS-Coordination i powiązane z nią typy koordynacyjne, wprowadza do SOA warstwę kontroli kompozycji (patrz rysunek 6.18). Standaryzuje on zarządzanie informacją kontekstową i jej wymianę w ram ach różnorodnych protokołów biznesowych. Architektura zorientowana na usługi

Aktywności biznesowe

Transakcje niepodzielne

/— (j
Definiują protokoły dla

Definiują protokoły dla ...

Luźne powiązanie

Interoperacyjność

i s gp *

Wieloużywalność Rozszerzalność

Standaryzuje kontrolę

Zarządza kontekstem dla

Zróżnicowanie dostawców Wykrywalność

Aktywności złożone

Usługi sieciowe

Jakość usług

Rysunek 6.18. Związek koordynacji z innymi elementami SOA

Koordynacja uwalnia ponadto usługi od konieczności utrzymywania informacji o stanie. Jak pam iętam y, bezstanowość usług jest jedną z kluczowych cech — i zalet — SOA; koordynacja urzeczywistnia tę cechę, przyjmując odpowiedzialność za zarządzanie informacją kontekstową.

A N A LIZA PRZYPADKU

W poprzedniej analizie przypadku opisaliśmy poszczególne etapy procesu tworzące aktyw­ ność złożoną. W momencie, gdy przetwarzanie tej aktywności osiąga granicę środowiska TLS, TLS urucham ia system zarządzania kontekstem w celu skoordynowania przepływu kom uni­ katów między usługami wewnątrz tego środowiska. Jak pokazano na rysunku 6.19, koordynacją objęte są następujące kroki wspomnianego procesu. 3. Usługa Płatność na konto działająca jako kontroler kompozycji inicjuje przetworzenie otrzymanego kom unikatu przez tę kompozycję. Pierwszą czynnością w ram ach tej inicjacji jest wywołanie usługi Profile dostawców w celu zweryfikowania poprawności nagłówka faktury i powiązania jej z konkretnym kontem dostawcy. 4. Po pozytywnym wyniku weryfikacji, o której mowa w punkcie 3., usługa Płatność na konto dzieli kwotę faktury na kwotę zasadniczą, koszty dostawy i podatek VAT, po czym przekazuje te wartości usłudze Rejestr księgi głównej, która aktualizuje stany różnych kont, w tym księgi głównej.

6 .4 . TRANSAKCJE N IEPO D ZIE LN E

173

Rysunek 6.19. Usługi TLS: Płatność na konto, Profile dostawców i Rejestr księgi głównej zostają objęte koordynacją

Koordynacja ta wykorzystuje typ koordynacyjny transakcji niepodzielnej, co wyjaśnimy szczegółowo w dwóch następnych analizach przypadków.

P O D S U M O W A N IE •

Aktywności złożone zależne są zw ykle od danych kontekstowych, którymi muszą odpowiednio zarządzać i które muszą odpow iednio koordynować.

•

Specyfikacja W S-Coordination definiuje abstrakcyjny fram ew ork zarządzania kontekstem, wykorzystujący standardow ą kompozycję usług z usługą-koordynatorem jako kontrolerem.

•

Konkretne, specjalizowane im plem entacje tego fram ew orku realizow ane są za pomocą typó w koordynacyjnych, z których najczęściej używ ane są W S-Atom icTransactioni WS-BusinessActivity.

•

Poprzez w prow adzenie do SOA w arstw y zarządzania aktywnościam i koordynacja staje się realizacją postulatu bezstanowości usług i wsparciem dla kontrolow anej kompozycji aktywności złożonych.

6 .4 . T ra n s a k c je n ie p o d z ie ln e Transakcje wykorzystywane są w obliczeniach automatycznych w zasadzie „od zawsze”. Podczas przetwarzania pewnych „wrażliwych” danych konieczne jest potraktowanie serii zmian, jakie doko­ nywane są na tych danych, na zasadzie „wszystko albo nic”, na zasadzie niepodzielnej akcji: scenariusz zmian musi zostać wykonany albo w całości, albo wcale — przerwanie tego scenariusza na etapie po­ średnim wymaga anulowania wszystkich jego dotychczasowych konsekwencji, czyli przywrócenia oryginalnej postaci przetwarzanych danych. N a gruncie usług sieciowych ta znana idea realizowana jest w odniesieniu do całych kompozycji usługowych, w postaci mechanizmu zwanego transakcją nie­ podzielną (atomic transaction). Prosty przykład takiej transakcji zilustrowano na rysunku 6.20.

174

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Rysunek 6.20. Transakcja niepodzielna oznacza potraktowanie pewnej części aktywności na zasadzie „wszystko albo nic"

UWAGA Koncepcje om aw iane w tym punkcie zaczerpnięte zostały ze specyfikacji WS-AtomicTransaction, definiującej protokoły do w ykorzystania przez mechanizm y opisyw ane w specyfikacji W S-Coordination. W rozdziale 16., w punkcie „WS-Coordination — przegląd", przedstawiamy prosty przykład odwołania do WS-AtomicTransaction w bloku nagłów kow ym komunikatu SOAP.

PO PROSTU Podczas gdy koledzy myli mój samochód, sąsiad zapytał mnie, czy za drobnym w ynagrodzeniem nie byliby­ śmy skłonni umyć jego samochodu. Nie mając żadnych planów na popołudnie, zgodziliśmy się. W czasie następnego tygodnia szeptana reklama spopularyzowała w okolicy nasze zdolności i kilku innych są­ siadów poprosiło o podobną przysługę. I po pewnym czasie myliśmy cztery - pięć samochodów w każdy weekend. Nie ma jednak róży bez kolców i przekonaliśmy się o tym dotkliwie. Pewnego dnia stanął przed nami samochód o karoserii metallicna wysoki połysk, a my, nieświadomi zagrożenia, użyliśmy naszego standardowego preparatu. Gdy karoseria już wyschła, ujrzeliśmy na niej szpecące przebarwienia; lakiernik z pobliskiego warsztatu wyjaśnił nam, że tanie środki czyszczące mają katastrofalny w p ływ na niektóre rodzaje wykończeń, między innymi lakiery m etalizowane. Zapłata za ponowne polakierowanie limuzyny była dla nas lekcją wielce pouczającą... Człow iek uczy się na błędach, w ięc bogatsi o now ą w iedzę, przepracowaliśm y naszą recepturę. Zgodnie z zaleceniami producentów i w skazów kam i znajom ego fachow ca, mieszaliśmy ze sobą kilka preparatów , aż do osiągnięcia w ym aganego koloru roztworu. Nie zawsze się udawało, czasami rezultat w zbudzał wątpliwości — w ylew aliśm y w ów czas całą mieszankę i rozpoczynaliśmy sporządzanie now ej. W kategoriach przedsta­ w ionego wcześniej scenariusza oznaczało to być może w ielokrotne w ykonyw anie następującej sekwencji: 4. napełnij w iadro ciepłą w odą, 5. dolej płynu czyszczącego do w ody. W oryginalnym scenariuszu sekwencja ta w ykonyw ana była po prostu jako jego część, tym razem jest nieco inaczej: gdy zaw artość w iadra okaże się nieakceptowana (w ramach punktu 5.), w ylew am y ją, spro­ w adzając („resetując") w iadro do stanu sprzed rozpoczęcia punktu 4. Gdy jednak sporządzona mieszanka nie budzi zastrzeżeń, uznajemy punkt 5. za pomyślnie w ykonany (i przechodzimy do następnych punktów). Tym oto sposobem sekwencja punktów 4. i 5. zostaje do obiektu w iadra albo zastosowana w całości, albo niezastosowana w ogóle.

6 .4 . TRANSAKCJE N IEPO D ZIE LN E

175

6.4.1. Transakcje ACID Protokoły definiowane w specyfikacji WS-AtomicTransaction umożliwiają objęcie kompozycji usług koordynacją transakcyjną porównywalną do transakcji typu ACID stosowanych w większości aplikacji rozproszonych. Akronim ACID składa się z pierwszych liter angielskich nazw czterech następujących cech, którymi charakteryzuje się tradycyjna transakcja: • niepodzielności (atomicity) — wszystkie czynności objęte transakcją muszą zostać wykonane w komplecie, albo niewykonane w ogóle; efekt częściowego ich wykonania musi zostać anulowany (rollback), czyli przetwarzane dane muszą zostać przywrócone do stanu sprzed rozpoczęcia transakcji, • spójności (consistency) — wykonanie transakcji nie może naruszać warunków integralności danych narzuconych na ich konkretny model; naruszenie tej zasady wymaga anulowania całej transakcji, czyli przywrócenia danych do stanu sprzed jej rozpoczęcia, • izolacji (isolation) — jeżeli równocześnie wykonywanych jest kilka transakcji, nie mogą one ze sobą interferować; każdej transakcji należy zapewnić realizację w oddzielnym środowisku, • trwałości (durability) — po pomyślnym wykonaniu transakcji jej rezultat nie może zostać zniwelowany przez ewentualnie zaistniałe awarie.

6.4.2. Protokoły transakcji niepodzielnych WS-AtomicTransaction to typ koordynacyjny, czyli rozszerzenie opracowane na potrzeby opisy­ wanego wcześniej frameworku zarządzania kontekstem. Usługa zamierzająca uczestniczyć w trans­ akcji musi wpierw pobrać kontekst koordynacyjny od usługi aktywacyjnej, po czym zarejestrować się w ram ach dostępnych protokołów transakcji niepodzielnych. We wspomnianej grupie protokołów do najważniejszych zaliczają się następujące: • Completion — używany zwykle do inicjowania stanu transakcji: zatwierdzona (committed) albo anulowana (aborted), • Durable 2PC — w jego ramach rejestrują się usługi reprezentujące perm anentne repozytoria danych, • Volatile 2PC — używany jest przez usługi zarządzające tymczasowymi („ulotnymi” — volatile) danymi. Najczęściej protokoły te wykorzystywane są do realizacji zatwierdzania dwufazowego (two phase commit, w skrócie 2PC) w ramach transakcji niepodzielnej obejmującej wiele usług-uczestniczek.

6.4.3. Koordynator transakcji niepodzielnej Gdy używane są protokoły W S-AtomicTransaction, usługa-koordynator, będąca kontrolerem kompozycji, określana jest m ianem koordynatora transakcji niepodzielnej (atomic transaction coordinator). Ta szczególna implementacja koordynatora WS-Coordination reprezentuje specy­ ficzny model usług: wspomniany koordynator odgrywa kluczową rolę w zarządzaniu uczestnikami procesu objętego transakcją i ostatecznie decyduje o wyniku tej transakcji (patrz rysunek 6.21).

176

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

6.4.4. Proces transakcji niepodzielnej J a k w c z e ś n ie j w s p o m in a liś m y , k o o r d y n a t o r tr a n s a k c ji n ie p o d z ie ln e j o d p o w ie d z ia ln y je s t z a o s ta ­ t e c z n y w y n ik tr a n s a k c ji; d e c y z ję w te j m ie r z e p o d e jm u je o n n a p o d s ta w ie in f o r m a c j i o t r z y m a n e j w r a m a c h s p r z ę ż e n ia z w r o tn e g o z k a ż d y m z u c z e s t n ik ó w te j tr a n s a k c ji. T o s p rz ę ż e n ie z w r o t n e d o k o n u je się w d w ó c h fa z a c h . W

fa z ie

przygotowawczej (p re p a re )

p r z e d s ta w io n e j n a r y s u n k u 6 .2 2 k a ż d a z u s łu g u c z e s tn ic z ą c y c h p o w ia d a m ia n a je s t p r z e z k o o r d y ­ n a to r a o z a m ia r z e s fin a liz o w a n ia tr a n s a k c ji; m a o n a w ó w c z a s s p o s o b n o ś ć p r z y g o to w a n ia się d o teg o a k tu o r a z m a o b o w ią z e k z a g ło s o w a n ia w te j k w e s tii — z a z a t w ie r d z e n ie m tr a n s a k c ji (c o m m it) a lb o z a je j a n u lo w a n ie m ( a b o r t) , j a k n a r y s u n k u 6 .2 3 .

Rysunek 6.22. Koordynator konsultujący z uczestnikami transakcji zamiar jej zatwierdzenia

6 .4 . TRANSAKCJE N IEPO D ZIE LN E

177

Rysunek 6.23. Uczestnicy transakcji głosujący w kwestii jej zatwierdzenia albo przerwania P o z e b r a n iu g ło s ó w o d u c z e s t n ik ó w k o o r d y n a t o r p r z e c h o d z i d o f a z y

finalizowania tr a n s a k c ji.

Jeśli w s z y s c y je j u c z e s tn ic y z a g ło s o w a li z a je j z a t w ie r d z e n ie m ( c o m m it) , k o o r d y n a t o r d o k o n u je ta k ie g o z a tw ie r d z e n ia ; je ś li n a to m ia s t c h o ć je d e n u c z e s tn ik z a g ło s o w a ł z a a n u lo w a n ie m tr a n s a k c ji

( a b o rt) lu b w o g ó le n ie o d p o w ie d z ia ł, tr a n s a k c ja z o s ta je p r z e z k o o r d y n a t o r w y c o fa n a ( r o llb a c k ) , ta k ja k n a ry s u n k u 6 .2 4 . Z a u w a ż m y , że u r z e c z y w is tn ie n ie te g o w y c o fa n ia je s t z a d a n ie m u s łu g u c z e s tn i­ c z ą c y c h , k t ó r e k o o r d y n a t o r p o w ia d a m ia o k o n ie c z n o ś c i a n u lo w a n ia w s z y s tk ic h z m ia n , ja k ie o d p o c z ą tk u t r a n s a k c ji z o s ta ły d o k o n a n e n a je j d a n y c h k o n te k s to w y c h .

Rysunek 6.24. Koordynator decyduje o anulowaniu (wycofaniu) transakcji i powiadamia jej uczestników o konieczności wycofania wszystkich zmian, jakie od początku tej transakcji zostały wprowadzone

178

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

6.4.5. Transakcje niepodzielne a SOA Większość funkcjonalności o charakterze transakcyjnym implementowanej w rozwiązaniach zo­ rientowanych na usługi zamyka się w grupie kom ponentów realizujących aktywność w imieniu jednej usługi. W miarę jednak rozrastania się repertuaru usług i ich kompozycji prędzej czy póź­ niej pojawia się konieczność zapewnienia transakcyjności na poziomie interakcji przekraczającej granice poszczególnych usług. Możliwość zagwarantowania właściwego rezultatu każdej aktyw­ ności jest kluczowym aspektem przetwarzania danych w każdym przedsiębiorstwie, więc niepo­ dzielność transakcji staje się istotnym czynnikiem zapewnienia jakości usług. Mechanizmy transakcji niepodzielnych nie tylko prowadzą do powstawania solidnych środowisk dla aktywności SOA, lecz także propagują interoperacyjność w zintegrowanych środowiskach. Aktywność transakcyjna może rozciągać się na wiele rozwiązań, im plementowanych przy użyciu różnych platform , i m im o tej heterogeniczności wciąż gwarantowany jest rezultat na zasadzie „wszystko albo nic”. Przy założeniu, że typ koordynacyjny WS-AtomicTransaction obsługiwany jest przez działające aplikacje, opcja ta poszerza obszar zastosowań protokołu zatwierdzania dwufazowego poza granice tradycyjnych aplikacji (wspierając tym samym interoperacyjność). Na rysunku 6.25 — stanowią­ cym wycinek diagramu z rysunku 6.1 — uwidocznione zostało odzwierciedlenie transakcyjności w wymienionych aspektach SOA.

Rysunek 6.25. Związek transakcyjności z innymi elementami SOA

A N A LIZA PRZYPADKU

Powracając do poprzedniej analizy przypadku — gdy zajrzymy „pod podszewkę” opisywa­ nego scenariusza, skonstatujemy, że jego kroki 3. i 4. składają się na transakcję niepodzielną. Oznacza to, że gdy choć jedna z usług nie wykona prawidłowo swego zadania w zakresie ak­ tualizacji danych, wszelkie ewentualne aktualizacje dokonane wcześniej (w ram ach kroku 3. transakcji, oczywiście) pow inny zostać anulowane (patrz rysunek 6.26).

6 .5 . A K TY W N O Ś C I B IZN ESO W E

179

Rysunek 6.26. Wszelkie zmiany dokonywane przez zespół usług Płatność na konto, Profile dostawców i Rejestr księgi głównej wykonywane są w ramach transakcji niepodzielnej

D la z a g w a r a n to w a n ia te g o e fe k tu r o z w ią z a n ie T L S b a z u je n a s p e c y fik a c ji W S -C o o rd in a tio n i im p le m e n t a c ji t y p u k o o r d y n a c y jn e g o W S - A to m ic T r a n s a c tio n . W y k o r z y s t u je o n o k o o r d y ­ n a to r k o n te k s t u w r a z z p r o t o k o łe m t r a n s a k c y jn y m C o m p le te w c e lu w y p o s a ż e n ia a k ty w n o ś c i z ło ż o n e j w m e c h a n iz m y tr a n s a k c ji t y p u A C I D .

P O D S U M O W A N IE • •

WS-Atom/'cTransact/'on to typ koordynacyjny dostarczający trzy protokoły koordynacyjne realizujące dw ufazow e zatw ierdzanie transakcji rozciągającej się na w iele usług uczestniczących. Koordynator transakcji niepodzielnej podejm uje ostateczną decyzję w kwestii zatw ierdzenia albo anulow ania transakcji, bazując na wynikach głosowania usług uczestniczących.

•

Typ koordynacyjny W S-AtomicTransaction umożliwia współczesnej SOA w ykorzystyw anie m echanizm ów transakcji typu ACID w odniesieniu do całych kompozycji usług.

6 .5 . A k ty w n o ś c i b iz n e s o w e A k t y w n o ś c i b iz n e s o w e (b u s in e s s a c tiv itie s ) r z ą d z ą w y k o n y w a n ie m d łu g o t r w a ły c h a k ty w n o ś c i u s łu g . M u s i u p ły n ą ć w ie le g o d z in , d n i, c z y n a w e t t y g o d n i, b y a k ty w n o ś ć b iz n e s o w a z r e a liz o w a ła p o w ie r z o n e je j z a d a n ie ; w t y m c z a s ie a k t y w n o ś ć t a m o ż e w y k o n y w a ć m n ó s t w o z a d a ń a n g a ż u ją ­ c y c h w ie le u s łu g u c z e s tn ic z ą c y c h . W o d r ó ż n ie n iu o d r e g u la r n y c h a k ty w n o ś c i z ło ż o n y c h , u s łu g i u c z e s tn ic z ą c e w a k ty w n o ś c ia c h b iz n e s o w y c h p o d le g a ją s p e c y fic z n y m r e g u ło m d e f in io w a n y m p r z e z o d p o w ie d n ie p r o t o k o ły . I n n ą w a ż n ą ce ch ą c h a ra k te ry s ty c z n ą a k ty w n o ś c i b iz n e s o w y c h , o d r ó ż n ia ją c ą je o d o m a w ia n y c h d o ty c h c za s

180

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

a k ty w n o ś c i, je s t p o d e jś c ie d o k w e s t ii tr a n s a k c y jn o ś c i o b s łu g i s y tu a c ji w y ją tk o w y c h . Z w a ż y w s z y n a d łu g o o k r e s o w ą n a tu r ę a k ty w n o ś c i b iz n e s o w y c h , t r u d n o w o g ó le r o z w a ż a ć r e a lis ty c z n ie p e r s p e k ­ ty w ę z a s to s o w a n ia n a ic h g r u n c ie tr a n s a k c ji n ie p o d z ie ln y c h t y p u A C I D ; a lt e r n a t y w ą je s t w t y m p r z y p a d k u p ro c e s

kompensacji (c o m p e n s a tio n ), k t ó r y , n ie ja k o n a z a s a d z ie „ p la n u B ” , u r u c h a ­

m i a n y z o s ta je w z w ią z k u z z a is tn ia łą s y tu a c ją w y ją t k o w ą ( p a t r z r y s u n e k 6 .2 7 ).

Rysunek 6.27. Aktywność biznesowa kontroluje integralność aktywności usług za pomocą „planu B" jako procesu kompensacyjnego

UWAGA Koncepcje om aw iane w tym punkcie zaczerpnięte zostały ze specyfikacji W S-BusinessActivity k tó ra (p o ­ d o b n ie ja k WS-AtomicTransactiori) definiuje protokoły do wykorzystania przez mechanizmy opisywane w spe­ cyfikacji WS-Coordination. W rozdziale 16., w punkcie „WS-Coordination — przegląd", przedstawiamy prosty przykład odw ołania do W S-BusinessActivityw bloku nagłów kow ym komunikatu SOAP.

PO PROSTU Zdarzało się, że w skutek niesprzyjającej pogody musieliśmy odw oływ ać w iele umówionych wcześniej spo­ tkań związanych z myciem samochodów. Było to dość kłopotliw e, w ym agało w szak uprzedniego pow iada­ miania klientów , no i też musieliśmy pow iadam iać siebie nawzajem . W końcu postanowiliśm y, że trzeba coś z tym zrobić. Chuck m iał w swym domu ogrom ny garaż i w spaniałom yślnie zgodził się udostępniać go jako pomiesz­ czenie do mycia au t w czasie deszczu. Zgodziliśmy się, aby jako pomysłodawca sam oceniał w arunki pogo­ dow e i decydow ał, czy będziem y w ykonyw ać nasze ulubione zajęcie w jego garażu, czy na posesji klienta. A jeżeli w jego garażu, to pow inien nas (i klienta) pow iadom ić zawczasu o tym fakcie. Tym samym nasz proces mycia sam ochodów ponow nie się skom plikował: jego częścią stał się podproces uruchamiany jedynie w sytuacji, gdy określone w arunki uniem ożliw iają realizację oryginalnego planu. Jest to w ięc proces kompensacyjny, powszechny elem ent typowych aktywności biznesowych. Zauw ażm y przy tym , że proces ten w żadnym stopniu nie w p ływ a na transakcję przygotow yw ania roz­ tw oru preparatów do mycia. Jest to w yraz związku między aktywnościam i biznesowymi a transakcjami nie­ podzielnym i w rzeczywistym świecie: każda aktyw ność biznesowa obejm uje jedną lub w ięcej transakcji nie­ podzielnych.

6 .5 . A K TY W N O Ś C I B IZN ESO W E

181

6.5.1. Protokoły aktywności biznesowych P o d o b n ie j a k W S - A to m ic T r a n s a c tio n , W S -B u s in e s s A c tiv ity to ty p k o o r d y n a c y jn y z a p r o je k t o w a n y n a p o t r z e b y f r a m e w o r k u z a r z ą d z a n ia k o n te k s te m W S - C o o rd in a tio n . O f e r u je o n d w a p o d o b n e p r o t o k o ły , z k t ó r y c h k a ż d y n a r z u c a u s łu g o m u c z e s tn ic z ą c y m o k re ś lo n e z a s a d y z a c h o w a n ia w r a ­ m a c h a k ty w n o ś c i b iz n e s o w e j, a m ia n o w ic ie : •

p r o t o k ó ł B u s in e s s A g r e e m e n tW ith P a r tic ip a n tC o m p le tio n u m o ż liw ia u s łu g o m u c z e s tn ic z ą c y m s y g n a liz o w a n ie w y k o n a n ia p o w ie r z o n y c h i m z a d a ń ;

•

p r o t o k ó ł B u s in e s s A g r e e m e n tW ith C o o r d in a to r C o m p le tio n z o b o w ią z u je u s łu g i u c z e s tn ic z ą c e d o p o w ia d a m ia n ia k o o r d y n a t o r a o w y k o n a n iu p o w ie r z o n y c h z a d a ń o r a z z a k o ń c z e n iu u c z e s tn ic tw a w a k ty w n o ś c i.

U s łu g i u c z e s tn ic z ą c e w a k ty w n o ś c i b iz n e s o w e j r e je s tr u ją się w r a m a c h o k re ś lo n e g o p r o t o k o łu z a p o ś r e d n ic tw e m s ta n d a r d o w e g o k o n t r o le r a - k o o r d y n a t o r a W S - C o o r d in a tio n , co w y ja ś n ia liś m y j u ż w p u n k c ie „ K o o r d y n a c ja ” .

6.5.2. Koordynator aktywności biznesowych G d y u ż y w a n e są w y m ie n io n e w p o p r z e d n im p u n k c ie p r o to k o ły , u s łu g a -k o n tr o le r W S - C o o rd in a tio n p r z y jm u je r o lę s p e c y fic z n ą d la t y p u k o o r d y n a c y jn e g o — w t y m p r z y p a d k u s ta je się k o o r d y n a t o ­ r e m a k t y w n o ś c i b iz n e s o w e j (b u s in e s s a c tiv ity c o o r d in a to r ) , co z ilu s tr o w a n o n a r y s u n k u 6 .2 8 . Jak j u ż w c z e ś n ie j w y ja ś n ia liś m y , k o o r d y n a t o r t e n s p r a w u je k o n t r o lę n a d o g ó ln ą a k ty w n o ś c ią n a r ó ż ­ n y c h s to p n ia c h , b a z u ją c n a p r o t o k o ła c h k o o r d y n a c y jn y c h w y k o r z y s t y w a n y c h p r z e z p o d p o r z ą d ­ k o w a n e m u u s łu g i.

Rysunek 6.28. Model usługi-koordynatora aktywności biznesowej

6.5.3. Stany aktywności biznesowej W c z a s ie t r w a n ia a k ty w n o ś c i b iz n e s o w e j je j k o o r d y n a t o r o r a z u s łu g i w n ie j u c z e s tn ic z ą c e p r z e ­ c h o d z ą p r z e z s z e re g s ta n ó w . Z m i a n a s ta n u n a s tę p u je w m o m e n c ie p r z e k a z a n ia s p e c ja ln e g o k o m u n ik a t u - p o w ia d o m ie n ia m i ę d z y u s łu g a m i.

182

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

I t a k n a p r z y k ła d u s łu g a u c z e s tn ic z ą c a m o ż e w y s ła ć

powiadomienie zakończenia (c o m p le te d

n o tific a tio n ) , s y g n a liz u ją c w t e n s p o s ó b , że w y k o n a ła p o m y ś ln ie c a ło ś ć p o w ie r z o n e g o je j z a d a n ia ;

czynna ( a c tiv e ) n a zakończona (c o m p le te d ). K o o r d y n a t o r zamknięcie (clo s e ), o z n a jm ia ją c w t e n s p o s ó b u s łu d z e u c z e s t­

p o w o d u je to z m ia n ę s ta n u u s łu g i z m o ż e o d p o w ie d z ie ć k o m u n ik a t e m

n ic z ą c e j p o m y ś ln e z a k o ń c z e n ie c a łe j a k ty w n o ś c i b iz n e s o w e j. N i e z a w s z e w s z y s tk o d z ia ła ta k , j a k z a p la n o w a n o ; g d y z d a r z y się coś w y ją tk o w e g o w o g ó ln y m p r z e b ie g u a k ty w n o ś c i b iz n e s o w e j, is tn ie je k ilk a o p c ji p o r a d z e n ia s o b ie z tą s y tu a c ją . U s łu g i u c z e s tn i­ czące m o g ą w c h o d z ić w

stan kompensacji (c o m p e n s a tio n ), w k t ó r y m u s iłu ją w y k o n a ć p e w ie n r o ­

d z a j o b s łu g i w y ją tk u ; g e n e r a ln ie p o le g a to n a z a in ic jo w a n iu p e w n e g o p r o c e s u k o m p e n s a c y jn e g o , z ło ż o n e g o z s e rii d o d a tk o w y c h k r o k ó w . K o m p e n s a c ja r ó ż n i się o d tr a n s a k c ji n ie p o d z ie ln e j t y m , że o d k o m p e n s a c ji n ie o c z e k u je się a n u lo w a n ia ( ro llb a c k ) d o k o n a n y c h ju ż z m ia n , le c z r a c z e j t r a k t u je się j ą ja k o s w o is tą r e k o m p e n s a tę ic h d o k o n a n ia . I n n ą o p c ją je s t w p r o w a d z e n ie u s łu g i w

stan anulowana (c a n c e lle d ) n a s k u te k w y s ła n ia d o n ie j

o d p o w ie d n ie g o p o w ia d o m ie n ia ( c a n c e lla tio n n o tific a tio n s ) . U s łu g a p o o t r z y m a n iu ta k ie g o k o ­ m u n ik a t u p o w in n a z a p r z e s ta ć w y k o n y w a n ia p o w ie r z o n e g o je j z a d a n ia . I n n y m s z c z e g ó łe m o d r ó ż n ia ją c y m a k ty w n o ś ć b iz n e s o w ą o d t r a n s a k c ji n ie p o d z ie ln e j je s t fa k t, ż e u c z e s tn ic t w o u s łu g i w a k ty w n o ś c i b iz n e s o w e j n ie m u s i r o z c ią g a ć się n a c a ły cza s t r w a n ia te j a k ty w n o ś c i. P o n ie w a ż g e n e r a ln ie n ie s p o s ó b z a p e w n ić śc isłej k o n t r o li n a d z m ia n a m i d o k o n y w a ­ n y m i p r z e z u s łu g i u c z e s tn ic z ą c e w a k ty w n o ś c i b iz n e s o w e j, u s łu g i te m o g ą o p u s z c z a ć tę a k ty w n o ś ć p o z r e a liz o w a n iu s w e g o w k ła d u w n ią . U s łu g a w y c o fu ją c a s w e u c z e s tn ic tw o w a k ty w n o ś c i b iz n e ­ s o w e j s y g n a liz u je t e n f a k t, w y s y ła ją c d o k o o r d y n a t o r a k o m u n ik a t

powiadomienie o wyjściu ( e x it

n o tific a tio n ) ; p r z e c h o d z i t y m s a m y m d o s ta n u wyłączona ( e x it ). W y m ie n io n e s ta n y (o r a z k i lk a in n y c h ) w r a z z f u n k c ja m i ( t a b e la m i) p r z e jś c ia m i ę d z y n i m i z d e fin io w a n e są w s p e c y fik a c ji W S -B u s in e s s A c tiv ity . O p is te n s ta n o w i b e z w z g lę d n y p u n k t o d n ie ­ s ie n ia d la lo g ik i p r o je k t o w a n y c h p r o t o k o łó w a k ty w n o ś c i b iz n e s o w e j.

6.5.4. Aktywności biznesowe a transakcje niepodzielne W t y m m ie js c u n a le ż y z w r ó c ić u w a g ę n a w a ż n y f a k t, ż e a k ty w n o ś c i b iz n e s o w e w c a le n ie w y k lu ­ c z a ją m o ż liw o ś c i u ż y w a n ia tr a n s a k c ji n ie p o d z ie ln y c h ; w r ę c z p r z e c iw n ie , w czas ie t r w a n ia d łu g o ­ te r m in o w e j a k ty w n o ś c i b iz n e s o w e j p r a w d o p o d o b n e r e a liz o w a n e są lic z n e ta k ie tr a n s a k c je . P r z y ­ k ła d o w ą m ig a w k ę ilu s tr u ją c ą t a k i s ta n r z e c z y w id z im y n a r y s u n k u 6 .2 9 .

6.5.5. Aktywności biznesowe a SOA A k t y w n o ś c i b iz n e s o w e w p e łn i w p is u ją się w k o m p o z y c y jn ą n a tu r ę S O A ( p a t r z r y s u n e k 6 .3 0 ) , z a ­ p e w n ia ją c ś le d z e n ie o r a z r e g u lo w a n ie a k ty w n o ś c i z ło ż o n y c h i je d n o c z e ś n ie s tw a r z a ją c w a r u n k i d o ic h d łu g o t r w a łe g o f u n k c jo n o w a n ia . A u t o n o m ia i b e z s ta n o w o ś ć u s łu g są w p e łn i r e s p e k to w a n e , b o u c z e s t n ic t w o d a n e j u s łu g i w a k ty w n o ś c i b iz n e s o w e j m o ż e b y ć o g r a n ic z o n e d o n ie z b ę d n e g o m i ­ n i m u m — p o w y k o n a n iu p o w ie r z o n e g o z a d a n ia u s łu g a m o ż e a k ty w n o ś ć b iz n e s o w ą o p u ś c ić . T a k a e la s ty c z n o ś ć z n a k o m ic ie u ła t w ia p r o je k t o w a n ie a u to m a ty z a c ji p r o c e s ó w b iz n e s o w y c h i je d n o c z e ­ ś n ie s p ra w ia , że z a p r o je k to w a n e a p lik a c je są d o b r z e a d a p to w a ln e d o n o w y c h w a r u n k ó w . P o n a d to , d z ię k i u ż y w a n iu p r o c e s ó w k o m p e n s a c y jn y c h , a k ty w n o ś c i b iz n e s o w e p r z y c z y n ia ją się d o o g ó ln e g o p o le p s z e n ia ja k o ś c i u s łu g , d o s ta r c z a ją c w b u d o w a n y c h ś r o d k ó w d o o b s łu g i s y tu a c ji w y ją t k o w y c h .

6 .5 . A K TY W N O Ś C I B IZN ESO W E

Rysunek 6.29. Transakcje niepodzielne realizowane w czasie trwania aktywności biznesowej

Rysunek 6.30. Związek aktywności biznesowych z innymi elementami SOA

183

184

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Podobnie jak w przypadku WS-AtomicTransaction, obsługa rozszerzenia WS-BusinessActivity przez wiele rozwiązań realizuje postulat interoperacyjności i przyczynia się znacząco do uprasz­ czania architektur integracyjnych. Aktywności biznesowe idą jednak w tym względzie kilka kro­ ków dalej, umożliwiając wyjście aktywności usług poza granice pojedynczego podm iotu (co stwa­ rza wygodne warunki do zintegrowanej współpracy wielu partnerów biznesowych). Oczywiście, nic nie stoi na przeszkodzie realizacji tego samego celu za pomocą jedynie transakcji niepodziel­ nych, jednakże aktywności biznesowe nadają się znacznie lepiej do tego typu komunikacji.

A N A LIZA PRZYPADKU

Proces TLS Zlecenie zakupu (zilustrowany na rysunku 6.31) obejmuje usługę Zlecenie za­ kupu działającą jako nadawca początkowy, wysyłającą kom unikat SOAP zawierający szcze­ góły zamówienia do usługi Realizacja zamówienia w TLS (krok 2.). Proces ten komplikuje się w przypadku, gdy wartość zlecenia przekracza 100 000 dolarów, bo takie zlecenie musi zostać zaakceptowane przez kierownictwo TLS (krok 1.).

Rysunek 6.31. Proces TLS Zlecenie zakupu jako część aktywności biznesowej rozciągającej się na dwie organizacje (dwie usługi uczestniczące)

RailCo, jak każdy inny dostawca, ma 48 godzin od czasu otrzymania zamówienia na spraw­ dzenie dostępności żądanego asortym entu i odesłanie odpowiedniego kom unikatu — po­ twierdzającego możliwość zrealizowania zamówienia bądź informującego, że zamówienie może zostać zrealizowane jedynie częściowo albo wcale (krok 3.). Jeśli nawet proces Zlecenie zakupu może zostać zaklasyfikowany jako aktywność złożona, jednak ta analiza przypadku różni się od poprzedniej dwoma istotnymi szczegółami: • obejmuje długotrwałą aktywność (trwającą do 48 godzin), • zawiera etap wykonywany przez człowieka (zaakceptowanie albo anulowanie zlecenia zakupu).

6 .6 . ORKIESTRACJE

185

A b y p o r a d z ić s o b ie z t a k im p r z y p a d k ie m a k ty w n o ś c i z ło ż o n e j, T L S u ż y ła te g o s a m e g o fr a m e w o r k u z a r z ą d z a n ia k o n t e k s t e m , o k t ó r y m p is a liś m y w p o p r z e d n ie j a n a liz ie p r z y p a d k u ( W S - C o o rd in a tio n ) , t y m r a z e m je d n a k w y k o r z y s ta n o ty p k o o r d y n a c y jn y W S -B u s in e s s A c tiv ity .

P O D S U M O W A N IE •

Aktywności biznesowe to złożone, długotrw ałe aktywności, zm ieniające się w czasie zarów no pod w zględem zakresu, ja k i liczby usług uczestniczących.

•

Typ koordynacyjny WS-BusinessActiv'rtyjako budulec frameworku zarządzania kontekstem (WS-Coordination)

•

Usługi uczestniczące w aktywności biznesowej oraz koordynator tej aktywności przechodzą przez szereg stanów w czasie trw ania tej aktywności. Przejścia między tym i stanam i dokonują się w skutek w ym iany kom unikatów -pow iadom ień.

•

D ługotrw ałe aktywności biznesowe są zjawiskam i powszechnymi na gruncie współczesnej SOA, co pozycjonuje specyfikację W S -B usinessA ctM yjako jedną z najważniejszych z perspektywy zarządzania logiką tego typu aktywności złożonych.

dostarcza dwa protokoły, w ramach których mogą rejestrować się usługi uczestniczące.

6 .6 . O rk ie s tra c je O r g a n iz a c jo m , k t ó r e n a p o t r z e b y a u to m a t y z a c ji s w y c h b iz n e s ó w u ż y w a ły ( lu b u ż y w a ją ) o p r o ­ g r a m o w a n ia m id d le w a r e z k a te g o r ii In t e g r a c ji A p lik a c ji K o r p o r a c y jn y c h (E n te rp ris e A p p lic a t io n

In te g r a tio n , w s k r ó c ie E A I ) , s c a la ją c e g o d z ia ła n ie r o z m a it y c h „ s p a d k o w y c h ” s y s te m ó w , z p e w n o ­ ś c ią n ie o b c a je s t k o n c e p c ja o r k i e s t r a c ji ( o rc h e s tr a tio n ) , z g o d n ie z k t ó r ą c e n t r a ln ie s te r o w a n a l o ­ g ik a p r z e p ły w u p r a c y o r g a n iz u je w s p ó łd z ia ła n ie d w ó c h lu b w ie lu r ó ż n y c h a p lik a c ji. P o w s z e c h n ie s p o ty k a n ą im p le m e n t a c ją o r k ie s tr a c ji je s t m o d e l n o s z ą c y a n g ie ls k ą n a z w ę h u b -a n d -s p o k e (d o s ł. „o ś i s z p r y c h y ”) p o le g a ją c y n a w s p ó łp r a c y w ie lu z e w n ę t r z n y c h u c z e s tn ik ó w z c e n t r a ln y m s iln i­ k ie m o r k ie s t r a ln y m (o rc h e s tr a tio n e n g in e ). Id e ę tę p r z e d s ta w io n o o b r a z o w o n a r y s u n k u 6 .3 2 .

Rysunek 6.32. Orkiestracja sprawuje kontrolę nad każdym niemal aspektem aktywności złożonej K o n c e p c ja o r k ie s tr a c ji s p o w o d o w a ła p o w s ta n ie n a r z ę d z ia u ła tw ia ją c e g o s c a la n ie s k o m p lik o ­ w a n y c h p r o c e s ó w b iz n e s o w y c h . D z ię k i o r k ie s tr a c ji r ó ż n e p r o c e s y z y s k u ją s p o s o b n o ś ć d o w s p ó ł­ d z ia ła n ia b e z j a k ie jk o l w i e k in g e r e n c ji w ic h o r y g in a ln e p r o je k t y ; o r k ie s t r a c ja z a s y p u je p r z e p a ś ć

186

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

istniejącą dotąd między tymi procesam i wskutek ich różnic projektowych i technologicznych. Ponadto wykorzystanie orkiestracji może znacząco zredukować złożoność środowiska integrują­ cego wiele różnych rozwiązań: logika przepływu pracy zostaje wyodrębniona w postaci abstrak­ cyjnej i jako taka poddaje się kontroli łatwiej niż gdyby rozproszono ją i wbudowano w poszcze­ gólne kom ponenty rozwiązań. W środowiskach zorientowanych na usługi orkiestracja dodatkowo zyskuje na znaczeniu: dzięki wykorzystywaniu rozszerzeń, pozwalających wyrażać logikę procesów biznesowych w kategoriach usług, orkiestracja pozwala na ujęcie tej logiki w standardowej formie, opartej właśnie na usługach. Z perspektywy tworzenia rozwiązań zorientowanych na usługi dostarcza to atrakcyjne środki do wyrażania i kontrolowania logiki reprezentującej automatyzowane procesy biznesowe. Tworząc potencjalne punkty końcowe dla integracji procesów, orkiestracja stanowi kolejny krok w kierunku lepszego spożytkowania wewnętrznej interoperacyjności; kolejnym aspektem pozycjonującym orkiestrację na gruncie SOA jest fakt, iż orkiestracje same mają postać usług. Orkiestracja nadaje procesom standardową reprezentację w skali przedsiębiorstwa i poza jego granicami, zatem wspiera federacyjność i generalnie propaguje zorientowanie na usługi. Podstawową specyfikacją przemysłową definiującą standardy orkiestracji w dziedzinie usług sieciowych jest WS-BPEL (Business Process Execution Language — język [programowania] realizacji procesów biznesowych) i w tej książce jej koncepcje i terminologię będziemy stosować jako pod­ stawę różnych dyskusji na tem at modelowania procesów biznesowych.

UWAGA WS-BPELto najnowsza nazwa w spom nianej specyfikacji; w przeszłości specyfikacja ta znana była pod nazw ą BPEL4WS\ub (po prostu) BPEL Okoliczności towarzyszące metamorfozie nazwy oraz najważniejsze części języka WS-BPEL om aw iam y w rozdziale 16.

PO PROSTU Nabraliśm y już w p raw y w myciu aut, umyliśmy ich sporo, w ięc postanowiliśm y — Chuck, Bob, Jim i ja — założyć w łasną firmę. Sform alizowaliśm y przecież nasz proces mycia i jesteśmy przygotow ani na przywraca­ nie czystości samochodom o różnych w ym aganiach. Traktując teraz naszą działalność profesjonalnie, w prow adziliśm y do niej kolejne rozszerzenia: •

w okresie szczególnego popytu zatrudniać będziemy na umowę-zlecenie dwóch pracowników do pomocy;

•

nie posiadając kapitału założycielskiego, czyli możliwości rozbudow y bazy operacyjnej, weszliśmy w porozum ienie z pobliską stacją paliw: w zamian za doraźne użyczanie części powierzchni zgodziliśmy się pom agać im w obsłudze klientów w godzinach szczytu.

Nasz początkowo bardzo prosty proces mycia aut stał się w ięc znacząco skom plikowany. Nie jest on już ta k stabilny ja k poprzednio, bo może podlegać raptow nym zm ianom w zależności od w arunków i zdarzeń zewnętrznych: • •

gdy zatrudnim y dodatkowych pracow ników, zmieni się sposób przyporządkowyw ania zadań poszczególnym członkom zespołu; gdy personel stacji paliw będzie potrzebow ał dodatkow ej pomocy, zobow iązani będziemy oddelegow ać jednego lub więcej członków zespołu.

6 .6 . ORKIESTRACJE

187

Są to wszystko czynniki raczej ła tw o p rzew idyw alne, bo zdarzające się okresow o. Nasza działalność podlega także ograniczeniom innego rodzaju: •

gdy nasze obroty spadną poniżej ustalonej granicy, nie będziemy mogli zatrudniać dodatkowych pomocników;

•

gdy zacznie padać deszcz, będziemy musieli zawiesić pracę (co dodatkowo przyczyni się do spadku obrotów).

I choć nie są one wielce praw dopodobne, to przecież musimy brać je pod uw agę. Wszystkie te (i kilka innych pomniejszych) uw arunkow ania zamieściliśmy w planie zaw ierającym procesy zasadnicze i procesy alternatyw ne zw iązane z różnymi czynnikami, mniej lub bardziej przew idyw alnym i. Plan ten jest w istocie przepływem pracy, łączącym pojedyncze kroki w procesy i podprocesy, przedzielone punktam i decyzyjnymi. W ramach tego planu spotyka się nasz zasadniczy proces z procesem funkcjonowania stacji paliw oraz rozszerzonym procesem uwzględniającym zatrudnienie pracowników pomocniczych. Jest więc orkiestracją zarządzającą w ym aganiam i dotyczącymi poszczególnych procesów oraz pow iązanym i zasobami, uczestnikami, zdarzeniam i, regułami biznesowym i i aktywnościami.

6.6.1. Protokoły biznesowe i definicje procesów L o g ik a p r z e p ły w u p r a c y s k ła d a ją c a się n a o r k ie s tr a c ję m o ż e o b e jm o w a ć w ie le r e g u ł b iz n e s o w y c h , w a r u n k ó w i z d a r z e ń . T e e le m e n t y o r k ie s t r a c ji, r a z e m w z ię t e , u s ta n a w ia ją

protokół biznesowy

(b u s in e s s p ro to c o l) d e fin iu ją c y s p o s ó b w s p ó łd z ia ła n ia u c z e s tn ik ó w w c e lu w y k o n a n ia o k re ś lo n e g o z a d a n ia b iz n e s o w e g o . S z c z e g ó ły w s p o m n ia n e j lo g ik i, e n k a p s u lo w a n e i w y r a ż o n e p r z e z o rk ie s tra c ję z a w a r te są w

definicji procesu (p ro ce ss d e fin itio n ) .

6.6.2. Usługi procesowe i usługi partnerskie W d e fin ic ji p ro c e s u z o s ta ją z id e n ty fik o w a n e i o p is a n e u s łu g i u c ze s tn ic zą c e w t y m p ro c esie. N a jp ie r w

usługą procesową (process s e rv ic e ), tw o r z ą c a usługami partnerskimi ( p a rtn e r s ervice), z w a n y m i ta k ż e łączami partnerskimi ( p a rtn e r lin k s ),

s a m p ro c e s p o t r a k to w a n y z o s ta je ja k o u s łu g a , z w a n a w ra z z

m o d e l u s łu g o w y te g o p ro c e s u , t a k ja k p r z e d s ta w io n o to n a r y s u n k u 6 .3 3 .

Rysunek 6.33. Usługa procesowa, koordynująca i eksponująca funkcjonalność trzech usług partnerskich

188

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZARZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Z a le ż n ie o d lo g ik i p r z e p ły w u p r a c y , u s łu g a p r o c e s o w a m o ż e b y ć b ą d ź to w y w o ły w a n a p r z e z z e w n ę t r z n ą u s łu g ę p a r t n e r s k ą , b ą d ź t e ż s a m a m o ż e w y w o ły w a ć t a k ą u s łu g ę — o b a te p r z y p a d k i z ilu s t r o w a n o n a r y s u n k u 6 .3 4 .

Rysunek 6.34. Usługa procesowa, wywołana przez usługę partnerską, wywołuje inną usługę partnerską

6.6.3. Aktywności podstawowe i aktywności strukturalne S p e c y fik a c ja W S -B P E L d z ie li lo g ik ę p r z e p ły w u p r a c y n a p r e d e fin io w a n e a k ty w n o ś c i p ro s te . Aktyw­ ności podstawowe (B a s ic a c tiv itie s ) — o d b ie r z (re ce ive ), w y w o ła j (in v o k e ), o d p o w ie d z (re p ly ), s y g n a li­ z u j w y ją t e k ( th r o w ) i p o c z e k a j ( w a it ) — r e p r e z e n tu ją fu n d a m e n t a ln e a k c je , k tó r e m o g ą b y ć o r g a ­ n iz o w a n e w je d n o s tk i w y ż s z e g o r z ę d u —

aktywności strukturalne ( s tru c tu re d a c tiv itie s ): s e k w e n c je

(seque nce), in s tr u k c je w y b o r u (s w itc h ), p ę tle ( w h ile ), p r z e p ły w y ( flo w ) i o c z e k iw a n ia n a z d a r z e n ie (p ic k ). Z a s to s o w a n ie w y m ie n io n y c h a k ty w n o ś c i d o w y r a ż a n ia lo g ik i p r o c e s ó w b iz n e s o w y c h o m a ­ w ia m y w r o z d z ia le 16.

6.6.4. Sekwencje, przepływy i złącza A k t y w n o ś c i p o d s ta w o w e i a k ty w n o ś c i s t r u k t u r a ln e m o g ą b y ć o r g a n iz o w a n e w s t r u k t u r y w y ż s z e ­ g o r z ę d u w y z n a c z a ją c e k o le jn o ś ć ic h w y k o n y w a n ia .

Sekwencja (se q u e n ce ) p o r z ą d k u je g r u p ę p o ­

w ią z a n y c h a k ty w n o ś c i w c ią g , w k t ó r y m są o n e w y k o n y w a n e p o k o le i. Jest to s z c z e g ó ln ie u ż y te c z n e w s y tu a c ji, g d y p e w n a p o r c ja lo g ik i a p lik a c ji z a le ż n a je s t o d w y n ik ó w in n e j.

Przepływ ( flo w ) to r ó w n ie ż g r u p a a k ty w n o ś c i, ty le ż e w y k o n y w a n y c h r ó w n o le g le ; w p r z e c i­ w ie ń s tw ie d o s e k w e n c ji, ż a d n a a k ty w n o ś ć n ie m u s i o c z e k iw a ć n a z a k o ń c z e n ie in n e j w r a m a c h te g o s a m e g o p r z e p ły w u . W y k o n a n ie p r z e p ły w u u w a ż a się z a z a k o ń c z o n e , g d y z a k o ń c z ą się w s z y s tk ie e n k a p s u lo w a n e p r z e z e ń a k ty w n o ś c i. S ta n o w i to n a t u r a ln y ś r o d e k s y n c h r o n iz a c ji m i ę d z y d w ie m a p o r c ja m i lo g ik i r e z y d u ją c y m i w o d d z ie ln y c h p r z e p ły w a c h .

Złącza ( lin k s ) w y k o r z y s ty w a n e są d o w y r a ż a n ia f o r m a ln y c h z a le ż n o ś c i m ię d z y a k ty w n o ś c ia m i w c h o d z ą c y m i w s k ła d p r z e p ły w u . Z a n i m z a k o ń c z y się a k ty w n o ś ć p o d p o r z ą d k o w a n a o k r e ś lo n y m z łą c z o m w y jś c io w y m ( o u tg o in g lin k s ) , m u s z ą z o s ta ć s p e łn io n e w s z y s tk ie w y m a g a n ia w y r a ż o n e p o p r z e z te z łą c z a ; a n a lo g ic z n ie , a k ty w n o ś ć n ie m o ż e się r o z p o c z ą ć , d o p ó k i n ie z o s ta n ą s p e łn io n e w y m a g a n ia w y r a ż o n e p r z e z z łą c z a w e jś c io w e ( in c o m in g lin k s ) , k t ó r y m a k ty w n o ś ć ta je s t p o d p o ­ r z ą d k o w a n a . R e g u ły w y r a ż a n e p r z e z z łą c z a n a z y w a n e są p o w s z e c h n ie

zacyjnymi ( s y n c h r o n iz a tio n d e p e n d e n c ie s ).

zależnościami synchroni­

6 .6 . ORKIESTRACJE

189

6.6.5. Orkiestracje i aktywno ś ci Jak wyjaśnialiśmy wcześniej, „aktywność” to term in niesprecyzowany, który może odnosić się do dowolnej logicznej jednostki pracy wykonywanej przez rozw iązanie zorientow ane na usługi. Obszar pojedynczej orkiestracji może być zatem sklasyfikowany jako aktywność złożona, praw­ dopodobnie długotrwała.

6.6.6. Orkiestracje i koordynacje Orkiestracja, w postaci definiowanej przez WS-BPEL, może w pełni wykorzystywać dobrodziej­ stwa frameworku zarządzania kontekstem WS-Coordination przy użyciu typu koordynacyjnego WS-BusinessActivity. Specyfikacja WS-BPEL definiuje protokoły koordynacyjne zaprojektowane na potrzeby złożonych, długotrwałych aktywności.

6.6.7. Orkiestracje a SOA Logika procesu biznesowego jest centralną częścią rozwiązania automatyzacyjnego. Orkiestracja dostarcza model automatyzacji, w ram ach którego logika procesów zostaje scentralizowana, lecz zachowuje swe podstawowe zalety — komponowalność i rozszerzalność (patrz rysunek 6.35). Po­ przez zastosowanie orkiestracji środowiska zorientowane na usługi stają się naturalnie rozsze­ rzalne i adaptowalne. Orkiestracje same z siebie ustanawiają zwykle punkty integracji z innym i aplikacjami, przez co stają się kluczowym czynnikiem ułatwiającym, a niekiedy wręcz um ożli­ wiającym, tę integrację.

Wykrywalność Jakość usług

Rysunek 6.35. Związek orkiestracji z innymi elementami SOA

Opisane zalety przekładają się bezpośrednio na zwiększenie zwinności organizacyjnej, ponieważ: • logika przepływu pracy enkapsulowana w ram ach orkiestracji może być modyfikowana i rozszerzana w sposób scentralizowany, • centralne umiejscowienie orkiestracji znacząco ułatwia scalanie procesów biznesowych przez abstrahowanie czynnika spajającego poszczególne rozwiązania automatyzacyjne, • poprzez ustanawianie architektur integracyjnych w potencjalnie ogromnej skali, orkiestracja wspiera, na poziomie fundamentalnym, ewolucję rozmaicie sfederowanego przedsiębiorstwa.

190

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Orkiestracja jest więc kluczowym czynnikiem wspomagającym federację w przedsiębiorstwie posiadającym wiele aplikacji działających na zróżnicowanych platformach obliczeniowych. Postęp w dziedzinie oprogramowania middleware sprawia, że orkiestracje jako takie same z siebie mogą dziś już w pełni integrować się z środowiskami zorientowanymi na usługi. Koncepcja orkiestracji zorientowanej na usługi stanowi wsparcie dla wszystkich innych kon­ cepcji, które dotąd omówiliśmy w tym rozdziale. W wielu środowiskach orkiestracje stają się po prostu sercem SOA.

A N A LIZA PRZYPADKU

W poprzedniej analizie przypadku zaprezentowaliśmy zastosowanie protokołu WS-BusinessActivity, dzięki któremu do długotrwałej aktywności wprowadzone zostało zarządzanie kontekstem i obsługa sytuacji wyjątkowych. Mimo iż opisywana aktywność może być postrzegana jako proces biznesowy, w firmie TLS w dalszym ciągu brakowało standardowych środków do wyrażenia logiki przepływu pracy. Brak ten zniwelowano, stosując orkiestrację w wydaniu WS-BPEL, tak jak na rysunku 6.36.

Rysunek 6.36. Rozszerzony proces Wysyłanie zamówienia zarządzany przez orkiestrację umożliwiającą interakcję z wieloma partnerami handlowymi

6 .7 . CHO REO G RAFIE

191

O r k ie s tr a c ja ta n ie t y lk o p o r z ą d k u je d o ty c h c z a s o w ą lo g ik ę p ro c e s u , le c z r ó w n ie ż p o s z e rz a ją o s c e n a riu s z e d o d a t k o w y c h in t e r a k c ji z u s łu g a m i w ie lu d o s ta w c ó w . P r z y k ła d o w o , g d y w y ­ b r a n y d o s ta w c a n ie je s t w s ta n ie z r e a liz o w a ć d a n e g o z a m ó w ie n ia , je s t o n o k ie r o w a n e d o n a ­ s tę p n e g o d o s ta w c y n a liś cie ; te n s c e n a riu s z k o n t y n u o w a n y je s t d o c h w ili n a p o tk a n ia d o s ta w c y z d o ln e g o k o m p le t n ie z r e a liz o w a ć z a m ó w ie n ie ( w z a ło ż o n y c h g r a n ic a c h c e n o w y c h ) lu b n ie z n a le z ie n ia ta k o w e g o n a liś c ie . W t y m d r u g im p r z y p a d k u d o k o n y w a n y je s t w y b ó r n a jle p s z e g o d o s ta w c y s p o ś ró d p r z e a n a liz o w a n y c h — n a jle p s z e g o w ś w ie tle s k o m p lik o w a n e j f o r m u ł y w a r t o ­ ś c io w a n ia , u w z g lę d n ia ją c e j m i ę d z y i n n y m i c e n ę , s to p ie ń k o m p le tn o ś c i r e a liz a c ji z a m ó w ie n ia i w a r u n k i r e k la m a c ji. Z a s to s o w a n a o r k ie s tr a c ja o r g a n iz u je z a te m z a r z ą d z a n ie w s z y s tk im i a s p e k ta m i p ro c e s u , w łą c z a ją c in t e r a k c ję z u s łu g a m i w ie lu d o s ta w c ó w o r a z a k t y w n o ś c i b iz n e s o w e u r u c h a m ia n e w z w ią z k u z p r z e t w a r z a n ie m z le c e n ia z a k u p u .

PODSUMOW ANIE •

Orkiestracja to sedno logiki procesu biznesowego realizowanego zazwyczaj w skali jednej organizacji.

•

Orkiestracja ustanawia protokół biznesowy i form alnie tw orzy ramy definicji procesu biznesowego.

•

Logika przepływu pracy w ew nątrz orkiestracji podzielona jest na aktywności podstaw ow e i strukturalne, zorganizow ane w struktury wyższego rzędu, między innymi sekwencje i przepływy.

•

Orkiestracja nazywana bywa „sercem SOA", poniew aż dostarcza środki do centralizacji znaczącej części logiki w ew nątrzaplikacyjnej i m iędzyaplikacyjnej, w ramach standardowego modelu usług.

6 .7 . C h o re o g ra fie W d o s k o n a ły m ś w ie c ie w s z y s tk ie p r z e d s ię b io rs tw a p o z o s ta ją ze s o b ą w ś c is ły m k o n ta k c ie w k w e s tii u z g o d n ie ń d o ty c z ą c y c h s tr u k tu r a liz a c ji ic h w e w n ę t r z n y c h p r o c e s ó w b iz n e s o w y c h . G d y p r z y c h o d z i d o n a w ią z y w a n ia w s p ó łp r a c y o n lin e , w s z y s tk o je s t ju ż g o to w e i o ja k ic h k o l w ie k p r o b le m a c h n ie m oże być m ow y. I c h o ć s z a n s e u r z e c z y w is tn ie n ia te j r ó ż o w e j w iz j i w r e a ln y m ś w ie c ie są d o k ła d n ie z e r o w e , je d ­ n a k w s p ó łc z e s n e p r z e d s ię b io rs tw a s k a z a n e są n a w s p ó łp r a c ę , m u s z ą i c h c ą w s p ó łp r a c o w a ć . I m u s z ą s ta w ić c z o ło w y z w a n io m w y n ik a ją c y m z d r a s ty c z n e g o n ie r a z z r ó ż n ic o w a n ia a r c h it e k t u r y i te c h ­ n o lo g ii. P o tr z e b u ją d o te g o e fe k ty w n y c h ś r o d k ó w . P r a w d a ta sta je się s z c z e g ó ln ie o d c z u w a ln a w sy­ tu a c ji, g d y w ie le r ó ż n y c h u s łu g , d z ia ła ją c y c h w r ó ż n y c h p r z e d s ię b io r s tw a c h , w s p ó łp r a c o w a ć m u s i w c e lu w y k o n a n ia w s p ó ln e g o z a d a n ia . W ś r ó d w ie lu s p e c y fik a c ji d e d y k o w a n y c h e f e k t y w n e m u o r g a n iz o w a n iu w y m i a n y in f o r m a c ji m i ę d z y w ie l o m a p r z e d s ię b io r s t w a m i (a ta k ż e — w ie l o m a a p lik a c ja m i w r a m a c h p o je d y n c z e g o p r z e d s ię b io r s tw a ) n a jb a r d z ie j c h y b a z n a n a je s t s p e c y fik a c ja W S - C D L (W e b S ervices C h o re o g ra p h y

D e s c r ip tio n L a n g u a g e — ję z y k o p is u c h o r e o g r a fii u s łu g s ie c io w y c h ) e k s p o n u ją c a w s p o s ó b s z c z e ­ g ó ln y a s p e k t

publicznej współpracy ( p u b lic c o lla b o r a tio n ) , s c h e m a ty c z n ie p r z e d s ta w io n y n a r y ­

s u n k u 6 .3 7 . T ę w ła ś n ie s p e c y fik a c ję w y k o r z y s t y w a ć b ę d z ie m y w k s ią ż c e d o w y ja ś n ia n ia k o n c e p c ji c h o r e o g r a fii, z n ie j te ż z a c z e r p n ę liś m y u ż y w a n ą w k s ią ż c e t e r m in o lo g ię z te j d z ie d z in y .

192

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Aplikacja

Organizacja A

„Oto reguły współpracy"

Organizacja B

Aplikacja B

Rysunek 6.37. Choreografia jako mechanizm umożliwiający współpracę między jej uczestnikami

PO PROSTU Upłynęło kilka miesięcy i nasze skromne przedsięwzięcie można uznać za udane. Pracując w naszym elastycz­ nym i ad ap to w aln ym systemie, jesteśm y w stanie efektyw nie świadczyć usługi mycia pojazdów i osiągać godziw e zyski. Jako bądź co bądź liczący się w branży, postanowiliśm y skontaktow ać się z nieodległą myjnią samochodów. M im o iż położona jest zaledw ie kilometr dalej, nie uw ażam y jej za konkurencję, ze względu na specyfikę lokalnych uw arunkow ań komunikacyjnych. M y ulokowaliśmy nasze usługi w pobliżu stacji paliw przy zjeździe z autostrady, oni po drugiej stronie tejże autostrady. Naszymi klientami są kierowcy udający się na północ, ich klientela to podróżni podążający na południe. W rezultacie inaczej rozkładają się nam godziny szczytu: my mamy pełne ręce pracy o poranku, oni przeżyw ają praw dziw e oblężenie późnym popołudniem . Skoro nie ma m ow y o konkurencji, to korzystnie byłoby nawiązać w spółpracę, użyczając sobie naw zajem części zasobów, w celu sprostania nawałowi pracy w godzinach szczytu. Dla nas taka perspektywa jest ze wszech miar korzystna: dotychczas klienci, przyjeżdżający na stację paliw , w idząc kolejkę aut do naszej myjni, z w y ­ czajnie rezygnowali. Doraźna pomoc jest w ięc potrzebna ja k najbardziej. Naw iązaliśm y partnerską w spółpracę, co znow u w ym agało modyfikacji naszego procesu biznesowego. M im o obiecującej perspektywy większych zysków, nie było to zadanie łatw e, bo przystosowując się do nowych w arunków , chcieliśmy jednocześnie chronić nasz oryginalny system pracy, sprawdzony już w praktyce. Po nara­ dzie z partnerami udało nam się w ypracować elastyczny proces współdziałania. Tak oto urzeczywistniła się koncepcja choreografii — współpracy dwóch organizacji w środowisku, nad którym żaden z partnerów nie spraw uje wyłącznej kontroli.

6.7.1. Współpraca Najważniejszą cechą charakterystyczną choreografii jest jej przeznaczenie — zaprojektowano ją na potrzeby publicznej wymiany kom unikatów , umożliwiającej nawiązywanie specyficznie zor­ ganizowanej współpracy między usługami reprezentującymi różne podmioty, przy czym logika tej współpracy niekoniecznie musi być kontrolowana przez konkretny, pojedynczy podmiot. Tym samym choreografia niesie ze sobą potencjał do ustanawiania uniwersalnych wzorców interoperacyjności dla zadań biznesowych rozciągających się na wiele organizacji.

6 .7 . CHO REO G RAFIE

193

UWAGA Chociaż choreografię wymyślono i zaprojektowano przede wszystkim na potrzeby interakcji B2B, to nadaje się ona rów nie dobrze do organizowania współdziałania aplikacji działających w tym samym przedsiębiorstwie. Praktyka dow odzi jednak, iż w tej roli częściej w ykorzystyw ana jest orkiestracja.

6.7.2. Role i uczestnicy U s łu g a s ie c io w a u c z e s tn ic z ą c a w c h o r e o g r a fii p r z y jm u je n a s ie b ie je d n ą z p r e d e f in io w a n y c h r ó l. R o la ta o d z w ie r c ie d la c h a r a k te r f u n k c jo n a ln y u s łu g i o r a z je j u m ie js c o w ie n ie w k o n te k ś c ie k o n ­ k r e tn e g o z a d a n ia b iz n e s o w e g o . R o le u s łu g m o g ą b y ć w ią z a n e z d e fin ic ja m i W S D L , zaś d e fin ic je m o g ą b y ć o d p o w ie d n io k o ja r z o n e i g r u p o w a n e , p r z e z co s a m e u s łu g i o k re ś la n e są m ia n e m u c z e s tn i­

k ó w ( p a r tic ip a n ts ) lu b u s łu g u c z e s tn ic z ą c y c h ( p a r t ic ip a n t s e rvice s).

6.7.3. Relacje i kanały K a ż d a a k c ja o d w z o r o w a n a w r a m a c h c h o r e o g r a fii r e a liz o w a n a je s t w p o s ta c i w y m i a n y s e r ii k o ­ m u n ik a t ó w m ię d z y d w ie m a u s łu g a m i. K a ż d a p o te n c ja ln a w y m ia n a k o m u n ik a t ó w m i ę d z y d w ie ­ m a r o la m i w c h o r e o g r a fii d e fin io w a n a je s t in d y w id u a ln ie ja k o r e la c ja (r e la tio n s h ip ) , c z y li k a ż d a r e la c ja p o w ią z a n a je s t z d o k ła d n ie d w ie m a r o la m i. S k o ro z n a m y ju ż n a tu r ę k o n w e r s a c ji, p o t r z e b u je m y ś r o d k ó w d o je j u r z e c z y w is t n ie n ia . Ś r o d ­ k a m i t a k i m i są k a n a ł y (c h a n n e ls ) d e fin iu ją c e c h a r a k t e r y s ty k ę w y m i a n y k o m u n ik a t ó w m i ę d z y d w ie m a k o n k r e t n y m i r o la m i. A b y d o d a tk o w o u ła t w ić r e a liz o w a n ie k o n w e r s a c ji a n g a ż u ją c y c h w ie lu u c z e s tn ik ó w , p r z e w i­ d z ia n o m o ż liw o ś ć p rz e s y ła n ia w k o m u n ik a ta c h in fo r m a c ji o k a n a le . W te n sp o só b je d n a u s łu g a m o ż e p r z e k a z a ć in n e j d a n e n ie z b ę d n e d o s k o m u n ik o w a n ia się z je s z c z e in n ą u s łu g ą ( in n y m i u s łu g a m i). Jest to w a ż n a c e c h a s p e c y fik a c ji W S - C D L , w s p o m a g a ją c a m e c h a n iz m d y n a m ic z n e g o w y k r y w a n ia u s łu g i p o w ię k s z a ją c a w te n s p o s ó b lic z b ę p o te n c ja ln y c h u s łu g u c z e s tn ic z ą c y c h w r e a liz a c ji r o z ­ b u d o w a n y c h z a d a ń b iz n e s o w y c h .

6.7.4. Interakcje i jednostki pracy L o g ik a b iz n e s o w a s k r y w a ją c a się z a w y m ia n ą k o m u n ik a t ó w e n k a p s u lo w a n a je s t w r a m a c h i n t e ­ r a k c ji ( in te r a c tio n ). In t e r a k c je są c e g ie łk a m i, z k tó r y c h b u d o w a n a je s t c h o r e o g r a fia , b o z a k o ń c z e n ie k o le jn e j in t e r a k c ji o z n a c z a p o s tę p w r a m a c h c h o r e o g r a fii. P o ję c ie m p o k r e w n y m in t e r a k c ji są j e d ­ n o s t k i p r a c y ( w o r k u n its ) . N a r z u c a ją o n e n a in te r a k c ję r e g u ły i o g r a n ic z e n ia k o n ie c z n e d o te g o , b y in t e r a k c ja t a m o g ła się z a k o ń c z y ć p o w o d z e n ie m .

6.7.5. Wieloużywalność, komponowalność i modularność K a ż d a c h o r e o g r a fia m o ż e z o s ta ć z a p r o je k t o w a n ia ja k o w ie lo u ż y w a ln a , c z y li m o ż liw a d o z a s to s o ­ w a n ia w r ó ż n y c h z a d a n ia c h b iz n e s o w y c h , s k ła d a ją c y c h się z ty c h s a m y c h f u n d a m e n t a ln y c h a k c ji. P o n a d to , d z ię k i m e c h a n iz m o w i im p o r t o w a n ia , c h o r e o g r a fia m o ż e s k ła d a ć się z n ie z a le ż n y c h m o ­ d u łó w . Z k o le i k a ż d y m o d u ł r e p r e z e n to w a ć m o ż e d o b r z e o k re ś lo n e p o d z a d a n ie i m o ż e b y ć u ż y w a n y r ó w n o c z e ś n ie p r z e z w ie le m a c ie rz y s ty c h c h o re o g ra fii. Z a le ż n o ś ć tę z ilu s tr o w a n o n a ry s u n k u 6 .3 8 .

194

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

Choreografia A

Choreografia B

Rysunek 6.38. Choreografia złożona z dwóch prostszych choreografii

I nawet jeśli choreografia z rezultacie obejmuje zbiór „zwykłych” usług podporządkowanych wykona­ niu określonego zadania, nic nie stoi na przeszkodzie, by uczestnikami choreografii były inne choreografie.

6.7.6. Orkiestracje a choreografie Zarówno orkiestracja, jak i choreografia reprezentują złożone wzorce wymiany komunikatów, jednak istnieje między nimi istotna różnica. Otóż orkiestracja wyraża biznesowy przepływ pracy specyficzny dla konkretnej organizacji; oznacza to, że organizacja ta całkowicie kontroluje logikę kryjącą się za orkiestracją, nawet jeśli logika ta zawiera interakcje z innymi partnerami biznesowymi. Dla odmiany, choreografia niekoniecznie musi być kontrolowana przez jeden podmiot, funkcjonuje jako wzorzec wymiany komu­ nikatów dla celów współpracy między usługami działającymi w różnych podmiotach (patrz rysunek 6.39).

Rysunek 6.39. Choreografia organizująca współpracę między dwiema różnymi orkiestracjami

6 .7 . CHO REO G RAFIE

195

Niekiedy orkiestracja uważana bywa za specyficzne zastosowanie choreografii — nie bez pod­ staw: otóż funkcjonalność definiowana przez specyfikacje WS-CDL i WS-BPEL częściowo się po­ krywa, co niechybnie jest konsekwencją faktu, iż każda z tych specyfikacji opracowywana była — w izolacji — przez inną organizację (odpowiednio: W 3C i OASIS). Orkiestracja bazuje na modelu, w którym logika kompozycji wykonywana jest i kontrolowana w sposób scentralizowany; sęk w tym, że orkiestracja może obejmować uczestnictwo usług po­ chodzących z innych podmiotów niż jej macierzysty — i to właśnie jest wspomniana część wspólna obu wymienionych specyfikacji. W efekcie orkiestracja może efektywnie kontrolować aktywności międzyorganizacyjne, podobnie jak choreografia. Z tą jednak różnicą, że orkiestracja — w prze­ ciwieństwie do choreografii — jest generalnie zarządzana przez pojedynczą organizację.

6.7.7. Choreografie a SOA Fundam entalną dla SOA koncepcję eksponowania logiki biznesowej poprzez autonomiczne usłu­ gi można realizować w różnym zakresie implementacyjnym. Dwie usługi w ram ach tej samej or­ ganizacji mogą współdziałać za pom ocą wzorców MEP w celu realizacji prostych zadań; analo­ gicznie dwie usługi należące do różnych organizacji, każda eksponująca kompletne rozwiązanie biznesowe, mogą współdziałać za pośrednictwem choreografii w celu realizacji zadań bardziej skom­ plikowanych. W obu przypadkach m am y do czynienia z dwiema usługami, oba przypadki zgodne są z fundam entalnym i zasadami SOA. Choreografia może zatem być pom ocna w realizacji SOA na obszarze przekraczającym grani­ ce pojedynczej organizacji (patrz rysunek 6.40). Oprócz przyrodzonego wsparcia dla komponowalności, wieloużywalności i rozszerzalności, przyczynia się ona jeszcze do zwiększenia zwinności organizacyjnej i wykrywalności usług. Dzięki niej organizacje mogą dołączać do współpracy online, która może poszerzać lub nawet modyfikować oryginalne procesy biznesowe. Ponadto za pomocą przekazywania informacji o kanałach w wymienianych kom unikatach organizacje mogą przeka­ zywać innym organizacjom informacje o swych partnerach, co dodatkowo powiększa możliwości tej współpracy.

Rysunek 6.40. Związek choreografii z innymi elementami SOA

196

ROZDZIAŁ 6. ■ USŁUGI SIECIOW E I W SPÓŁCZESNA SOA (CZĘŚĆ I. ZA RZĄDZANIE A K TY W N O Ś C IA M I I KOMPOZYCJE)

ANALIZA PRZYPADKU

Firma TLS zakupiła fabrykę Sampson Steel produkującą rozmaite części i podzespoły stalowe dla przemysłu samochodowego i lotniczego. TLS wykorzystuje moce przerobowe przejętego zakładu do produkcji części na własne potrzeby oraz dla dotychczasowych klientów Sampson Steel. W ubiegłym roku na rynku pojawił się znaczący klient, potrzebujący dla swych produk­ tów nietypowych części ze stali. W celu uzgadniania skomplikowanych szczegółów projek­ towych każdego elementu klient ten musi współpracować ze specjalistami pracującymi po­ przednio w Sampson Steel, obecnie w TLS. Specyfikacja projektowa każdej części obejmuje rozmaite jej parametry, między innymi: • złożoność projektową, • koszt materiału, • liczbę potrzebnych egzemplarzy, • dostępność maszyn niezbędnych do obróbki, • wymaganą trwałość, • wymagania eksploatacyjne dotyczące środowiska. W rezultacie, zanim rzeczona specyfikacja osiągnie ostateczną postać, wiele jej szkiców krąży między klientem a specjalistami z TLS. Przetwarzanie tych szkiców jest wysoce zauto­ matyzowane na każdym etapie ich przeglądu pod kątem ochrony prywatności, praw autor­ skich i składu chemicznego, wykonywane są także skomplikowane obliczenia matematyczne. Aby proces stał się bardziej klarowny, TLS i klient uzgodnili objęcie choreografią swych własnych systemów z tej dziedziny. Usługi uczestniczące w tej choreografii między innymi: • transm itują i trasują kom unikaty zawierające dokum enty specyfikacji projektowych, • automatycznie walidują dane specyfikacji, • przetwarzają założenia polityki prywatności i bezpieczeństwa, • wykonują obliczenia określone przez skomplikowane form uły matematyczne. W ten sposób w spom niana choreografia autom atyzuje w dużym stopniu pracochłonną i czasochłonną współpracę firmy TLS z klientem w zakresie negocjowania i finalizowania projektów nietypowych produktów.

PODSUMOW ANIE

• Choreografia jest złożoną aktywnością obejm ującą kompozycję usług i w zorców MEP. • Choreografie składają się z w ielu usług uczestniczących, przyjmujących rozm aite role i pozostających w rozmaitych relacjach.

• Choreografie są w ieloużyw alne, kom ponow alne i mogą być m odularyzow ane. • Koncepcja choreografii rozszerza w izję SOA na standaryzow aną współpracę między organizacjami.

Rozdział 7

Usługi sieciowe i współczesna SOA (Część II. Zaawansowane komunikowanie, metadane i bezpieczeństwo) 7.1. Adresowanie 7.2. Niezawodne komunikowanie 7.3. Korelacje 7.4. Założenia polityki 7.5. W ymiana metadanych 7.6. Bezpieczeństwo 7.7. Powiadamianie i zdarzeniowanie

198

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

W rozdziale 6. omawialiśmy szereg koncepcji związanych z kompozycjami usług i zarządzaniem ich aktywnościami, głównie w aspekcie ich związku z kompozycyjną naturą SOA. W tym roz­ dziale zajmiemy się rozszerzeniami WS-* poświęconymi wybranym cechom frameworku kom u­ nikacyjnego SOAP, czyli tworzeniem i wymianą m etadanych oraz bezpieczeństwem aplikacji re­ alizowanym na poziomie komunikatów. Podobnie jak w rozdziale 6., na pierwszym rysunku (7.1) przedstawimy strukturalny układ omawianych zagadnień i powiązań między nimi.

R y s u n e k 7 .1 . S tru k tu ra ln y o b ra z treści te g o ro zdziału

7 .1 . A D R E S O W A N IE

199

W miarę jak odkrywać będziemy tajniki kolejnych specyfikacji WS-*, coraz wyraźniej wyła­ niać będzie się spodziewana skądinąd prawda, że fram ework kom unikacyjny jest krwiobiegiem architektury współczesnej SOA. Realizuje on nie tylko transm isję danych, ale wręcz w arunkuje urzeczywistnienie kompozycyjnej natury SOA. Elastyczność kom unikatów SOAP, dzięki konfi­ gurowalnym nagłówkom, pozwala na implementowanie wszystkich niemal koncepcji opisywa­ nych w tym i poprzednim rozdziale. Terminologię używaną w tym rozdziale zaczerpnęliśmy z następujących specyfikacji w aktu­ alnej edycji: •

W S -A d d re s s in g ,

• W S -R e lia b le M e s s a g in g , • frameworku W S -P o lic y (wraz z W S -P o lic y A tta c h m e n ts i W S -P o lic y A s s e rtio n s ), • W S -M e ta d a ta E x c h a n g e , • W S -S e c u rity (wraz z X M L - E n c r y p tio n , X M L - S ig n a tu r e i S A M L ) , • frameworku W S - N o tific a tio n (wraz z W S - B a s e N o tific a tio n , W S -T o p ic s i W S - B ro k e re d N o tific a tio n ) , • W S -E v e n tin g . Podobnie jak w rozdziale 6., tak i w tym rozdziale ograniczamy się wyłącznie do koncepcyjnej strony cytowanych specyfikacji WS-*. Opisy składni języków pięciu pierwszych specyfikacji z po­ wyższej listy, wraz z przykładami ich użycia, prezentujemy w rozdziale 17.

UWAGA Nie przedstaw iam y w tej książce przykładów użycia języków definiowanych przez fram ew ork W S-Notification oraz specyfikację W S-Eventing. Są to dwa różne języki opisujące dw a bardzo podobne światy, które w kon­ tekście tem atyki tej książki bardziej ad ekw atn ie prezentują się na poziom ie koncepcyjnym.

PO PROSTU Historyjka rozpoczęta w rozdziale 5. ma swój ciąg dalszy i nieodm iennie stwarza okazję do sugestyw nego w yjaśniania om aw ianych zjaw isk za pom ocą pozatechnicznych analogii.

Analizy przypadków: Powracamy w tym rozdziale do kilku analiz przypadków prezento­ wanych w rozdziale poprzednim , by ponownie przyjrzeć się niektórym interakcjom między usługami w kontekście ich związku z nowo omawianymi koncepcjami.

7 .1 . A d re s o w a n ie Adresowanie jest dla kom unikatów SOAP tym, czym list przewozowy dla przesyłki kurierskiej. Niezależnie od tego, jaką drogą przesyłka ta wędruje do miejsca przeznaczenia, razem z nią wę­ druje wspom niany list przewozowy, z którego wyczytać m ożna co najmniej to:

200

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

• kto przesyłkę nadał, • na jaki adres przesyłka m a zostać doręczona, • kto pod w spom nianym adresem jest uprawniony do odebrania przesyłki, • dokąd trafić m a przesyłka, gdy nie m ożna jej doręczyć zgodnie z planem. Specyfikacja WS-Addressing implementuje te cechy adresowe (patrz rysunek 7.2) za pomocą dwóch typów nagłówków SOAP (które niebawem opiszemy). Rozszerzenia te, choć względnie proste z natury, stanowią integralny element mechanizmów komunikacyjnych SOA. Wiele innych specyfikacji WS-* niejawnie wykorzystuje specyfikację WS-Addressing. „Potrafię dokładnie wskazać, kto mnie wysłał i w jaki sposób powinieneś odpowiedzieć na moje przybycie"

M „A ja wiem dokładnie, dokąd wysłać tę informację"

Rysunek 7.2. Adresowanie sprawia, że komunikaty stają się autonomicznymi jednostkami komunikowania

UWAGA Ogólny przegląd języka WS-Addressing przedstaw iam y w punkcie „Podstawy języka W S-Addressing", w roz­ dziale 17.

PO PROSTU Nasza myjnia au t znakom icie się rozw ija, a w raz z nią zaczyna kw itnąć biurokracja. Raz w tygodniu Chuck przegląda korespondencję i w ykonuje niezbędną papierow ą robotę z nią zw iązaną. W tym tygodniu przyszły dw a listy: jeden z naszej firm y ubezpieczeniow ej, drugi z urzędu skarbowego. Pierwszy z listów zaw ierał odnow ienie naszej polisy ubezpieczeniowej i kw otę opłaty na następny rok. Na kopercie w pozycji „nadawca" w idniała nazwa firmy i adres jej centrali. Pod listem podpisał się przedstawi­ ciel odpowiedzialny za naszą polisę, zwracając uw agę na niektóre istotne zmiany w warunkach ubezpieczenia i prosząc, by bezpośrednio do niego przesłać czek na żądaną sumę. Chuck umieścił w ięc ów czek w kopercie, a na kopercie pod adresem centrali firm y dopisał „Przekazać bezpośrednio do ..." (tu w pisał imię i nazwisko naszego przedstawiciela). List z urzędu skarbowego zaw ierał dw ie koperty zw rotne oraz rozliczenie podatku. Zgodnie z załączoną instrukcją, jeśli chcemy wpłacić całość naszego zobow iązania, powinniśmy wysłać czek na odpowiednią sumę w pierwszej kopercie (zaadresow anej do Działu Należności), jeżeli natomiast możem y uregulow ać tylko część zobow iązania, pow inniśm y w tym celu użyć drugiej koperty (zaadresow anej do działu w indykacji). Oba scenariusze stanow ią analogię — nieco daleką — fundam entalnych koncepcji referencji punktu końcowego i n agłów ków informacyjnych, które w yjaśnim y w kolejnych punktach.

7 .1 . A D R E S O W A N IE

7 .1 .1 .

201

R e fe re n c je p u n k t ó w k o ń c o w y c h

J a k w y ja ś n ia liś m y w r o z d z ia le 3 ., je d n y m z e le m e n t ó w z a p e w n ia ją c y c h lu ź n e p o w ią z a n ie m ię d z y u s łu g a m i są o p is y ty c h u s łu g ; i n n y m i s ło w y , w s z y s tk im , c z e g o p o tr z e b u je u s łu g a -w n io s k o d a w c a d o s k o n t a k to w a n ia się z u s łu g ą -d o s ta r c z y c ie le m , je s t d e fin ic ja W S D L te j o s ta tn ie j. J e d n y m z e le ­ m e n t ó w te j d e fin ic ji je s t a d re s u s łu g i, p o d k t ó r y m m o g ą się z n ią k o n t a k t o w a ć z a in te r e s o w a n e u s łu g i-w n io s k o d a w c y . S y tu a c ja k o m p lik u je się je d n a k , g d y p o d t y m a d re s e m f u n k c jo n u je w ie le

in s ta n c ji d a n e j u s łu g i i u s łu g a - w n io s k o d a w c a m u s i s k o n t a k t o w a ć się z k o n k r e t n ą in s t a n c ją — s a m a d re s w ó w c z a s n ie w y s ta r c z y . T r a d y c y jn ie p r o b le m t e n r o z w ią z y w a n o w te n s p o s ó b , że p o łą c z e n ie m i ę d z y k o n k r e t n y m i i n ­ s t a n c ja m i u s łu g t r a k t o w a n o ja k o sesję, a u n ik a t o w y id e n t y f ik a t o r ( I D ) te j se s ji d o łą c z a n o ja k o p r z y r o s t e k d o a d re s u u s łu g i, w w y n ik u c z e g o o t r z y m y w a n o u n ik a t o w y U R L . T a k ie r o z w ią z a n ie , ja k k o lw ie k p r z e jr z y s te i ła tw e w im p le m e n t a c ji, m ia ło te n z a s a d n ic z y m a n k a m e n t , ż e z a p r o je k t o ­ w a n a w te n s p o s ó b a p lik a c ja p o z b a w io n a b y ła p r a k t y c z n ie c e c h b e z p ie c z e ń s tw a . P o z a t y m r e a liz a ­ c ja te g o p o m y s łu m i a ła w ie le r ó ż n y c h o d m ia n i ja k o ta k a d a le k a b y ła o d s ta n d a r y z a c ji. N a g ru n c ie u s łu g s ie c io w y c h a d re s o w a n ie in s ta n c ji u s łu g re a liz o w a n e je s t p r z e z re fe re n c je punk­ tów końcowych (e n d p o in t references). E le m e n te m k a ż d e j ta k ie j re fe re n c ji je s t w s k a ź n ik u n ik a to w o id e n ty fik u ją c y d a n ą in s ta n c ję u s łu g i ( i z w y k le to w a rz y s z ą c e te j in s ta n c ji m e ta d a n e ), d la b e z p ie c z e ń s tw a g e n e r o w a n y d y n a m ic z n ie , b y ć m o ż e z u w z g lę d n ie n ie m o k re ś lo n y c h w ła ś c iw o ś c i. W s y tu a c ji p o k a z a n e j n a r y s u n k u 7 .3 in s ta n c ja 1 u s łu g i A w y s y ła k o m u n ik a t d o (je d n o in s ta n c y jn e j) u s łu g i B.

Rysunek 7.3. Komunikat SOAP zawierający referencję instancji, która go wysłała R e fe r e n c ja p u n k t u k o ń c o w e g o z a w ie r a z w y k le n a s tę p u ją c e części:

• adres — lo k a liz a to r U R L u s łu g i; • właściwości referencji — z b ió r w a r to ś c i o k re ś la ją c y c h p o s z c z e g ó ln e w ła ś c iw o ś c i in s ta n c ji u s łu g i s ie c io w e j ( w n a s z e j o s ta tn ie j h is to r y jc e „ P o p r o s t u . . . ” n a z w is k o k o n k r e tn e g o p r z e d s ta w ic ie la w c e n t r a li f i r m y u b e z p ie c z e n io w e j b y ło a n a lo g ią w ła ś c iw o ś c i I D , c z y li id e n t y f ik a t o r a in s ta n c ji);

202

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

• parametry referencji — zbiór param etrów określających szczegóły interakcji z instancją usługi; • nazwę usługi i typ portu — informacja specyficzna dla interfejsu usługi, wskazująca odbiorcy komunikatu szczegóły lokalizacji opisu usługi, niezbędne dla wysłania odpowiedzi. • założenia polityki — zgodne ze specyfikacją WS-Policy reguły i norm y zachowania, charakterystyczne dla bieżącej interakcji (zajmiemy się nim i dalej w tym rozdziale). Powyższa lista może być rozszerzana o dodatkowe elementy, praw dopodobnie związane ze szczegółami definicji WSDL. W szystkie jej elementy, oprócz adresu, są opcjonalne. 7 .1 .2 .

N a g łó w k i in fo r m a c y jn e k o m u n ik a t ó w

W poprzednim rozdziale opisywaliśmy prymitywne wzorce wymiany komunikatów (MEP), z któ­ rych komponować m ożna aktywności złożone. Wzorce te mają przewidywalną charakterystykę, co z jednej strony, ułatwia projektowanie usług sieciowych, z drugiej jednak, poważnie ogranicza scenariusze interakcji, w jakich tak zaprojektowane usługi mogą uczestniczyć. W zaawansowanych rozwiązaniach zorientowanych na usługi pożądana elastyczność usług zmusza do przełamywania ustalonych wzorców — przykładowo specyfika konkretnego rozwiązania może stwarzać wymaganie, by sposób wymiany kom unikatów przez daną usługę w interakcji z innym i usługami określany był dynamicznie, stosownie do bieżących warunków. W specyfikacji WS-Addressing definiowane są nagłówki SOAP, umożliwiające wbudowywanie w kom unikaty inform acji określających charakter ich wymiany; nagłówki te określane są wspólnym m ianem nagłówków inform acji o komunikatach lub krótko nagłówków M I, od angielskiego Message Inform ation. Przykład użycia takiego nagłówka widzimy na rysunku 7.4. \

\

/

\

\

/ U s łu g a C

• Nadała mnie usługa A • Zmierzam do usługi B •Odpowiedź do usługi C •Jeśli wystąpi problem, powiadom usługę D

U s łu g a D

\

\

\

\

R y s u n e k 7 .4 . K o m u n ik a t SOAP z n a g łó w k ie m za w ie ra ją c y m in fo rm a c ję na te m a t sw ej szcze g ó ło w e j dyspozycji

7 .1 . A D R E S O W A N IE

203

W s p e c y fik a c ji W S -A d d re s s in g p r z e w id z ia n e są n a s tę p u ją c e n a g łó w k i M I :

• przeznaczenie ( d e s tin a tio n ) — o k re ś la a d re s d o c e lo w y k o m u n ik a t u , • źródłowy punkt końcowy (s o u rc e e n d p o in t) — r e fe r e n c ja p u n k t u k o ń c o w e g o o d n o s z ą c a się d o u s łu g i, k t ó r a w y g e n e r o w a ła k o m u n ik a t ,

• punkt końcowy dla odpowiedzi ( re p ly e n d p o in t) — te n is t o t n y n a g łó w e k u m o ż liw ia k o m u n ik a t o w i w y m u s z e n ie s k ie r o w a n ia p o t w ie r d z e n ia ( o d p o w ie d z i) d o o k re ś lo n e j u s łu g i,

• punkt końcowy dla powiadomienia o błędzie ( f a u lt e n d p o in t) — to k o le jn y n a g łó w e k z w ię k s z a ją c y e la s ty c z n o ś ć k o m u n ik o w a n ia , d a ją c y k o m u n ik a t o w i m o ż liw o ś ć o k re ś le n ia u s łu g i, d o k tó r e j s k ie r o w a n e z o s ta n ie p o w ia d o m ie n ie o e w e n t u a ln y c h p r o b le m a c h z je g o d o s ta r c z e n ie m ,

• identyfikator komunikatu (m essage id ) — w a r to ś ć je d n o z n a c z n ie id e n t y f ik u ją c a k o m u n ik a t , w y k o r z y s t y w a n a p r z y e w e n tu a ln e j r e t r a n s m is ji k o m u n ik a t u o r a z d o s k o ja r z e n ia k o m u n ik a t u - o d p o w ie d z i z o d n o ś n y m k o m u n ik a t e m - ż ą d a n ie m ; t e n n a g łó w e k je s t w y m a g a n y w p r z y p a d k u o b e c n o ś c i n a g łó w k a p u n k t k o ń c o w y d la o d p o w ie d z i, •

relacja ( r e la tio n s h ip ) — u ż y w a n y n a jc z ę ś c ie j w s c e n a r iu s z a c h t y p u „ ż ą d a n ie - o d p o w ie d ź ” , z a w ie r a id e n t y f ik a t o r p o w ią z a n e g o k o m u n ik a t u - ż ą d a n ia (n a g łó w e k t e n je s t o b o w ią z k o w y w k o m u n ik a c ie - o d p o w ie d z i) ,

• akcja ( a c tio n ) — w a r to ś ć A U R I w s k a z u ją c a o g ó ln e p r z e z n a c z e n ie k o m u n ik a t u , o d p o w ie d n ik s ta n d a r d o w e j w a r to ś c i H T T P a c tio n p r o t o k o łu S O A P . ( W a r t o w t y m m ie js c u z w r ó c ić u w a g ę n a c ie k a w y fa k t, ż e s p e c y fik a c ja W S -A d d re s s in g d o p u s z ­ c z a r ó w n ie ż a n o n im o w e U R I , u m o ż liw ia ją c e z a m ie r z o n e u m ie s z c z a n ie w n a g łó w k a c h M I n ie p o ­ p r a w n y c h a d re s ó w ). M o ż liw o ś ć r o z s z e r z a n ia k o m u n ik a t ó w S O A P o w y m ie n io n e n a g łó w k i d o d a t k o w o w z m a c n ia p o z y c ję ty c h k o m u n ik a t ó w ja k o n ie z a le ż n y c h je d n o s te k k o m u n ik a c ji. P o d p o s ta c ią n a g łó w k ó w M I k o m u n ik a t y S O A P m o g ą te r a z p r z e n o s ić s z c z e g ó ło w e in f o r m a c je n a t e m a t w y m a g a n e g o t r a k t o ­ w a n ia ic h p r z e z o d b ie r a ją c e je u s łu g i ( o r a z w y m a g a n e g o z a c h o w a n ia p o o d e b r a n iu ) . W e fe k c ie o t r z y m u j e m y s ta n d a r d o w e w s p a r c ie d la n ie p r z e w id y w a ln y c h i e la s ty c z n y c h s c e n a r iu s z y w y m i a ­ n y k o m u n i k a t ó w — s c e n a r iu s z y t w o r z o n y c h d y n a m i c z n ie n a p o d s t a w ie b ie ż ą c y c h w a r u n k ó w w ykonaw czych.

7 .1 .3 .

A d r e s o w a n ie a n ie z a le ż n o ś ć o d p r o t o k o łu t r a n s p o r t o w e g o

W tr a d y c y jn y c h a p lik a c ja c h r o z p r o s z o n y c h s z c z e g ó ły p r o c e s u d o s ta r c z a n ia je d n o s t k i k o m u n ik a ­ c ji z p u n k t u A d o p u n k t u B p o w ie r z a n e b y ły k o n k r e t n y m p r o t o k o ło m d z ia ła ją c y m w w a r s tw ie t r a n s p o r t o w e j. C h o ć t a k i p o z io m a b s t r a h o w a n ia t e c h n o lo g ic z n e g o je s t w y g o d n y d la p r o g r a m i­ s tó w , je d n o c z e ś n ie o g r a n ic z a p o d w z g lę d e m m o ż liw o ś c i k o m u n ik o w a n ia się d w ie je d n o s t k i lo g ik i p r z e tw a r z a n ia . S ta n d a r d o w e n a g łó w k i S O A P d e fin io w a n e p r z e z s p e c y fik a c ję W S -A d d re s s in g n iw e lu ją w ię k ­ s z o ś ć te g o r o d z a ju z a le ż n o ś c i o d p r o t o k o łó w , ja k o ż e d a ją k o m u n ik a t o w i p e łn ię k o n t r o l i n a d s w y m p r z e z n a c z e n ie m . T o k o le jn y c z y n n ik p o z w a la ją c y k o m u n ik a t o m n a f u n k c jo n o w a n ie ja k o s a m o d z ie ln e je d n o s tk i k o m u n ik a c ji.

204

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

7.1.4. Adresowanie a SOA A d r e s o w a n ie r e a liz u je s ta n d a r y z a c ję S O A n a n is k im , tr a n s p o r t o w y m p o z io m ie , co s ta n o w i p r o ­ m o c ję o t w a r t y c h s t a n d a r d ó w u s ta n a w ia ją c y c h n ie z a le ż n o ś ć o d k o n k r e t n y c h t e c h n o lo g ii t r a n s ­ p o r t o w y c h ( p a t r z r y s u n e k 7 .5 ). U ż y c ie r e fe r e n c ji p u n k t ó w k o ń c o w y c h i n a g łó w k ó w M I z w ię k s z a s to p ie ń in te lig e n c ji w b u d o w y w a n e j w k o m u n ik a t y S O A P i s p r a w ia , że są b a r d z ie j a u to n o m ic z n e .

Rysunek 7.5. Związek adresowania z innymi elementami SOA W y p o s a ż e n ie k o m u n ik a t u w z d o ln o ś ć d o s a m o d z ie ln e g o n a p r o w a d z a n ia s w e g o ła d u n k u u ż y ­ te c z n e g o i n a r z u c a n ia d o c e lo w e j u s łu d z e s p o s o b u je g o t r a k t o w a n ia z n a c z ą c o p o w ię k s z a p o te n c ja ł in t e r o p e r a c y jn o ś c i u s łu g s ie c io w y c h . L o g ik a s p e c y fic z n a d la z a d a n ia z o s ta je w z n a c z ą c e j c z ę ś c i w b u d o w a n a d o k o m u n ik a t ó w w y m ie n ia n y c h m ię d z y u s łu g a m i, co z w ię k s z a m o ż liw o ś c i p r o je k ­ t o w a n ia ty c h u s łu g ja k o w ie lo u ż y w a ln y c h i u ła t w ia o p e r o w a n ie ic h d o d a t k o w y m i m e t a d a n y m i. C o w ię c e j, w y k o r z y s ty w a n ie n a g łó w k ó w M I p o w ię k s z a z a k re s lo g ik i in te r a k c y jn e j w r a m a c h s k o m p lik o w a n y c h a k ty w n o ś c i, a n a w e t u m o ż li w i a d y n a m ic z n e k r e o w a n ie te j lo g ik i. I n ie o c z e k i­ w a n ie ta n ie k w e s t io n o w a n a z a le ta s ta je s ię , n ie s te ty , o b o s ie c z n y m m ie c z e m , b o je j n ie w ła ś c iw e w y k o r z y s t y w a n ie ( lu b n a d u ż y w a n ie ) p r o w a d z ić m o ż e d o t w o r z e n ia a k ty w n o ś c i w r ę c z k u r io z a l­ n y c h , n a d m ie r n ie s k o m p lik o w a n y c h i je ś li n a w e t r e a liz u ją c y c h z a m ie r z o n e ce le, to z w y k le w s p o só b b a rd z o o k rę ż n y . W r e s z c ie , m o ż liw o ś ć o d w o ły w a n ia s ię d o k o n k r e t n y c h in s t a n c ji u s łu g c z y n i S O A w y s o c e s k a lo w a ln y m i to w s t a n d a r d o w y s p o s ó b , b e z k o n ie c z n o ś c i s to s o w a n ia w y k o n c y p o w a n y c h te c h ­ n i k p r o je k t o w y c h . A s k a lo w a ln o ś ć je s t c e n n ą z a le tą u s łu g , k o r z y s t n ie w p ły w a ją c ą n a ic h ja k o ś ć . I je s z c z e je d n a w a ż n a u w a g a : p o p r z e z m o ż liw o ś ć o d w o ły w a n ia się d o k o n k r e t n y c h in s ta n c ji u s łu g s p e c y fik a c ja W S -A d d re s s in g p o ś r e d n io p r o p a g u je t w o r z e n ie u s łu g u t r z y m u ją c y c h i n f o r m a ­ c ję o s w y m s ta n ie ( s ta te fu l s e rv ic e s), co p o z o s ta je w s p rz e c z n o ś c i z b e z s ta n o w o ś c ią (statelessness) u s łu g ja k o f u n d a m e n t a ln ą z a s a d ą S O A ( p o w r ó c i m y d o te j k w e s tii w r o z d z ia le 8 .). Ś w ia d o m i te j s p rz e c z n o ś c i p r o g r a m iś c i p o w in n i w ię c u ż y w a ć o p is a n e j m o ż liw o ś c i z w y c z u c ie m i u m ia r e m .

7 .1 . A D R E S O W A N IE

205

A N A LIZA PRZYPADKU

W poprzednim rozdziale przedstawiliśmy kilka przykładów ilustrujących szczegóły tego, co dzieje się „pod podszewką” procesu wystawiania faktury dla TLS przez dostawcę części. Jed­ nym z tych szczegółów był dialog usług Płatność na konto i Profile dostawców, przeprowa­ dzany w celu walidacji danych dostawcy zawartych w nagłówku faktury. W obec ogromnej liczby faktur spływających nieustannie do TLS nie jest niczym dziwnym fakt, że w danej chwili funkcjonuje wiele instancji usługi Płatność na konto, a zatem w n a­ główku SOAP kom unikatu wysyłanego przez konkretną z tych instancji do usługi Profile dostawców m usi znaleźć się identyfikator tej instancji. Jest on niezbędny do tego, by usługa Profile dostawców mogła odesłać kom unikat z wynikami walidacji do właściwej instancji (oryginalnego nadawcy). Sytuację tę przedstawiliśmy na rysunku 7.6.

Rysunek 7.6. Poszczególne instancje ustug komunikują się, przy użyciu referencji punktów końcowych i nagłówków MI, między dwiema pulami ustug w TLS

206

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

P O D S U M O W A N IE •

Rozszerzenia dotyczące adresow ania, w kształcie definiow anym przez specyfikację WS-Addressing, w prow adzają dw ie now e koncepcje: referencję punktu końcowego i nagłów ek informacyjny komunikatu (M I).

•

Referencja punktu końcow ego jest standardow ym środkiem identyfikow ania konkretnej instancji usługi sieciowej.

•

N agłów ki informacyjne w zbogacają kom unikat o właściwości określające szczegóły jego przetw arzania, dostarczające jego adresatow i informacji o w ym aganej semantyce interakcji.

•

Specyfikacja WS-Addressing, jakko lw iek mało skom plikowana w porównaniu z w ielom a innymi specyfikacjami W S-*, definiuje potężną w arstw ę autonom ii komunikacyjnej w ramach architektury zorientow anej na usługi.

7 .2 . N ie z a w o d n e k o m u n ik o w a n ie Korzyści, jakie oferuje framework komunikacyjny luźno powiązanych usług, mają swoją cenę: jest nią utrata kontroli nad losami wysłanego kom unikatu. Po jego wysłaniu usługa-nadawca nie dys­ ponuje żadnymi bezpośrednim i środkam i uzyskania następujących informacji. • Czy kom unikat pomyślnie dotarł do żądanego miejsca przeznaczenia? • Czy może kom unikat zaginął po drodze i wymagana jest jego retransmisja? • Czy kom unikaty wysłane w ram ach sekwencji dotarły do miejsca przeznaczenia w wymaganej kolejności? Niezaw odne kom unikow anie likwiduje ten dotkliw y brak poprzez ustanow ienie pewnego stopnia zapewnienia jakości, który może mieć zastosowanie również do innych frameworków za­ rządzania aktywnością (patrz rysunek 7.7).

/

f

[

V \

S

'

X

Usługa A

\

„Chcę wiedzieć, czy dotarł mój komunikat"

X ----------------------1

y \ ---------------------

>

/ f 1

-V

Usługa B

< --------------------------„Wszystko, co mogę zrobić \ w tejmierze,toinformowanie \ cię o tym, które z twoich komunikatów otrzymałam"

\\

1

/

Rysunek 7.7. Niezawodne komunikowanie daje gwarancję powiadomienia o pomyślnym dostarczeniu albo niedostarczeniu wysłanego komunikatu

Specyfikacja WS-ReliableMessaging definiuje framework zdolny gwarantować, że: • usługi-dostarczyciele będę powiadamiane o losach — dostarczeniu lub nie — wysyłanych przez siebie komunikatów, • komunikaty, które mają dotrzeć do miejsca przeznaczenia w ustalonej kolejności, faktycznie tak właśnie zostaną odebrane albo wygenerowane zostanie powiadomienie, iż celu tego nie udało się zrealizować.

7 .2 . N IE Z A W O D N E K O M U N IK O W A N IE

207

C h o c i a ż r o z s z e r z e n ia n ie z a w o d n e g o k o m u n ik o w a n ia m a ją p o d w ie l o m a w z g lę d a m i w ie le w s p ó ln e g o z z a r z ą d z a n ie m a k ty w n o ś c ia m i, je d n a k s p e c y fik a c ja W S -R e lia b le M e s s a g in g r ó ż n i się z a s a d n ic z o o d s p e c y fik a c ji z a r z ą d z a n ia a k ty w n o ś c ia m i, k tó r e to s p e c y fik a c je o p is y w a liś m y w r o z ­ d z ia le 6 . O t ó ż n ie z a w o d n e k o m u n ik o w a n ie n ie z a p r z ę g a u s łu g i- k o o r d y n a t o r a d o k o n t r o lo w a n ia s ta n u a k t y w n o ś c i — w s z y s tk ie r e g u ły d o ty c z ą c e n ie z a w o d n o ś c i im p le m e n t o w a n e są w e w n ą t r z k o m u n ik a t ó w , n a b a z ie n a g łó w k ó w S O A P .

UWAGA W prow adzenie do języka WS-ReliableMessaging przedstawiamy w rozdziale 17., w punkcie „Podstawy języka WS-ReliableMessaging".

PO PROSTU W poprzednim rozdziale, w punkcie Choreografia, pisałem o tym , ja k naw iązaliśm y współpracę z myjnią znajdującą się po drugiej stronie autostrady. W ramach tej współpracy użyczamy sobie nawzajem pracowników, by sprostać n aw ałow i pracy w godzinach szczytu. Jeden z kolegów pracujących u partnerów ma na imię George. W ykonuje sw ą pracę bez zarzutu, lecz ma jedną przypadłość — słabą pamięć. Nasze myjnie dzieli niespełna kilometr, a mimo to zdarzyło się kilka razy, że George po prostu zabłądził, bo pom ylił drogę. To podsunęło nam pomysł, by podjąć pew ne środki ostrożności: ilekroć partnerzy w ysyłają nam pracow ­ ników do pomocy, inform ują nas o ich liczbie — gdyby w ięc ktoś po drodze zabłądził, będzie to dla nas od razu oczywiste. Ten schemat działa identycznie w drugą stronę, czyli w sytuacji, gdy my wysyłam y naszych pracow ników do pomocy. I ta k oto w budow aliśm y prosty elem ent zapew nienia niezawodności do naszego systemu w spółdzielenia zasobów.

7 .2 .1 .

R M S o u rc e , R M D e s tin a tio n , ź r ó d ło a p lik a c y jn e i p r z e z n a c z e n ie a p lik a c y jn e

S p e c y fik a c ja W S -R e lia b le M e s s a g in g w p r o w a d z a r o z r ó ż n ie n ie p o m ię d z y e le m e n t a m i r o z w ią z a n ia o d p o w ie d z ia ln y m i z a z a in ic jo w a n ie tr a n s m is ji k o m u n ik a t u a e le m e n t a m i r e a liz u ją c y m i tę tr a n s ­ m is ję . S z c z e g ó ło w o s p e c y f ik a c ja t a p r z y p is u je o k r e ś lo n e z n a c z e n ie t e r m i n o m s e n d ( „ w y ś l i j ” ) ,

tr a n s m it ( „ p r z e ś lij”) , re ce iv e ( „ o d b ie r z ”) i d e liv e r ( „ d o s ta r c z ” ). R o z r ó ż n ie n ie to je s t k o n ie c z n e d o w y o d r ę b n ie n ia f r a m e w o r k u n ie z a w o d n e g o k o m u n ik o w a n ia w o g ó ln y m k o n te k ś c ie S O A .

Źródłem aplikacyjnym ( a p p lic a t io n s o u rc e ) n a z y w a w s p o m n ia n a s p e c y fik a c ja lo g ik ę u s łu g i źródła RM 1 ( R M s o u rc e ) b ę d ą c e g o f iz y c z n y m

lu b a p lik a c ji w y s y ła ją c e j (s e n d in g ) k o m u n i k a t d o

p r o c e s o r e m lu b w ę z łe m w y k o n u ją c y m tr a n s m is ję ( tr a n s m is s io n ) k o m u n ik a t u p o p r z e z n o ś n ik

przeznaczenie RM ( R M d e s tin a tio n ) r e p r e z e n tu je d o c e lo w y p r o c e s o r lu b w ę z e ł o d b ie ra ją c y (re c e iv in g ) k o m u n ik a t i n a s tę p n ie d o s ta rc z a ją c y (d e liv e rin g ) g o d o przeznaczenia aplikacyjnego (a p p lic a tio n d e s tin a tio n ). E le m e n ty te u w id o c z n iliś m y n a r y s u n k u 7 .8 .

t r a n s m is y jn y . P o d o b n ie

1 A kronim RM pochodzi od Reliable Messaging, co po angielsku oznacza właśnie „niezawodne kom unikow anie” — przyp. tłum.

208

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

Rysunek 7.8. Źródło aplikacyjne, źródło RM, przeznaczenie RM i przeznaczenie aplikacyjne

7.2.2. Sekwencje S e k w e n c ja (seq u e n ce ) d e fin iu je k o le jn o ś ć , w k t ó r e j k o m u n ik a t y z p e w n e g o z b io r u m u s z ą z o s ta ć d o s ta r c z o n e d o m ie js c a p r z e z n a c z e n ia . K a ż d e m u k o m u n ik a t o w i w c h o d z ą c e m u w s k ła d s e k w e n c ji p r z y p o r z ą d k o w a n y je s t k o le jn y n u m e r (m essage n u m b e r ) id e n t y f ik u ją c y je g o p o z y c ję w s e k w e n ­ c ji; d o d a tk o w o , o s ta tn i k o m u n ik a t w s e k w e n c ji o z n a c z o n y je s t s p e c ja ln y m id e n t y f ik a t o r e m (la s t

m essage id e n t ifie r ).

7.2.3. Potwierdzenia C e n t r a ln y m m e c h a n iz m e m f r a m e w o r k u n ie z a w o d n e g o k o m u n ik o w a n ia je s t s y s te m p o w ia d o m ie ń r e a liz o w a n y c h p r z e z p r z e z n a c z e n ie R M n a r z e c z ź r ó d ła R M . P o o d e b r a n iu k o m u n ik a t u o z n a c z o ­ n e g o ja k o o s ta tn i w s e k w e n c ji p r z e z n a c z e n ie R M w y s y ła d o ź r ó d ła R M k o m u n ik a t p o t w ie r d z e n ia s e k w e n c ji (seque nce a c k n o w le d g e m e n t), t a k j a k n a r y s u n k u 7 .9 . K o m u n ik a t t e n in f o r m u je ź r ó d ło R M , k t ó r e k o m u n ik a t y z s e k w e n c ji fa k t y c z n ie d o t a r ły d o p r z e z n a c z e n ia R M . W g e s tii ź r ó d ła R M s p o c z y w a s p r a w d z e n ie , c z y k o m u n ik a t y o d e b r a n e p r z e z p r z e z n a c z e n ie R M są id e n ty c z n e z t y m i, k tó r e z o s ta ły w y s ła n e . W p r z y p a d k u s tw ie r d z e n ia , iż n ie k t ó r e z k o m u n ik a t ó w z o s ta ły z g u b io n e , ź r ó d ło R M m o ż e p o n o w ić ic h tr a n s m is ję , z a le ż n ie o d w y k o r z y s ty w a n e g o p o z io m u z a p e w n ie n ia d o s ta r c z e n ia ( p is z e m y o t y m w n a s tę p n y m p u n k c ie ) . P o w y ż s z y o p is m ó g łb y s u g e r o w a ć , ż e ź r ó d ło R M m u s i c z e k a ć n a p o t w ie r d z e n ie c a łe j s e ­ k w e n c ji z e s t r o n y p r z e z n a c z e n ia R M , b y d o w ie d z ie ć s ię c z e g o k o lw ie k o k t ó r y m k o l w i e k k o m u ­ n ik a c ie te j s e k w e n c ji — t a k j e d n a k w c a le n ie m u s i b y ć . Ź r ó d ł o R M m o ż e w k a ż d y m m o m e n c ie z a ż ą d a ć d o d a t k o w e g o p o t w ie r d z e n ia o d p r z e z n a c z e n i a R M , w y s y ła ją c w t y m c e lu s to s o w n y k o m u n ik a t (re q u e s t a c k n o w le d g e m e n ts ), co z ilu s t r o w a liś m y n a r y s u n k u 7 .1 0 . P o n a d t o d o s tę p n a je s t o p c ja n a ty c h m ia s t o w e g o w y s y ła n ia p r z e z p r z e z n a c z e n ie R M p o t w i e r d z e n i a n e g a t y w n e g o

(n e g a tiv e a c k n o w le d g e m e n ts ), in fo r m u ją c e g o ź r ó d ło R M o w y s tą p ie n iu s y tu a c ji w y ją tk o w e j ( p a t r z r y s u n e k 7 .1 1 ).

7 .2 . N IE Z A W O D N E K O M U N IK O W A N IE

Rysunek 7.9. Potwierdzenie sekwencji wysłane przez przeznaczenie RM po pomyślnym odebraniu komunikatów z tej sekwencji

Rysunek 7.10. Żądanie potwierdzenia wysyłane przez źródło RM do przeznaczenia RM, nakazujące wysyłanie potwierdzeń jeszcze przed odebraniem ostatniego komunikatu z sekwencji

209

210

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

Rysunek 7.11. Potwierdzenie negatywne wysyłane przez przeznaczenie RM do źródła RM, informujące o niepowodzeniu dostarczenia komunikatu jeszcze przed skompletowaniem sekwencji

7.2.4. Zapewnienia dostarczenia N a t u r a s e k w e n c ji z d e t e r m in o w a n a je s t p r z e z z b ió r r e g u ł n ie z a w o d n o ś c i, o k r e ś la n y c h m ia n e m

zapewnień dostarczenia ( d e liv e r y a s su ra n ce s ). R e g u ły te s ta n o w ią p r e d e f in io w a n e w z o r c e d o s ta r ­ c z a n ia k o m u n ik a t ó w i w y z n a c z a ją s z e re g z a ło ż e ń p o li t y k i n ie z a w o d n o ś c i ( r e lia b ilit y p o lic ie s ). Z d e f in io w a n o n a s tę p u ją c e w z o r c e d o s ta r c z a n ia k o m u n ik a t ó w . •

A tM o s tO n c e („ c o n a jw y ż e j je d e n ” ) — d o s ta r c z e n ie p o je d y n c z e g o k o m u n ik a t u lu b n ie d o s ta r c z e n ie ż a d n e g o ; w ie lo k r o t n e o d e b r a n ie te g o s a m e g o k o m u n ik a t u u w a ż a n e je s t z a s y tu a c ję a w a r y jn ą ( p a t r z r y s u n e k 7 .1 2 ) .

R y s u n e k 7 .1 2 . Przykład z re a liz o w a n ia w zo rc a A tM o s tO n c e

7 .2 . N IE Z A W O D N E K O M U N IK O W A N IE

211

AtLeastOnce („co najmniej jeden”) — dopuszcza dostarczenie kom unikatu raz lub więcej razy. Niedostarczenie kom unikatu uważane jest za błąd (patrz rysunek 7.13).

Rysunek 7.13. Przykład zrealizowania wzorca AtLeastOnce

ExactlyOnce („dokładnie jeden”) — wymaga dostarczenia danego kom unikatu dokładnie raz. Niedostarczenie kom unikatu albo dostarczenie go kilka razy uważane jest za błąd (patrz rysunek 7.14).

Rysunek 7.14. Przykład zrealizowania wzorca ExactlyOnce

212

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

•

I n O r d e r („po kolei”) — kom unikaty muszą zostać dostarczone w zdefiniowanej kolejności

(patrz rysunek 7.15). Odebranie kom unikatu naruszającego tę zasadę jest traktowane jako błąd. Zauważmy, że wzorzec ten może być łączony z dowolnym z poprzednio omawianych wzorców.

7.2.5. Niezawodne komunikowanie a adresowanie Specyfikacja W S -A d d re s s in g jest ściśle powiązana z frameworkiem definiowanym przez specyfi­ kację W S -R e lia b le M e s s a g in g . Właśnie ten framework był przyczyną zrewidowania pierwotnej wersji W S -A d d re s s in g . Zgodnie z oryginalną wersją W S -A d d re s s in g każdy kom unikat musiał być opa­ trzony unikatowym identyfikatorem. Nie istniała więc możliwość wyemitowania kilku kom uni­ katów o tym samym identyfikatorze, a zatem nie sposób było realizować retransmisji komunikatów wymaganych w przypadku błędu transmisji przez wzorce definiowane w W S -R e lia b le M e s s a g in g . W kolejnej edycji W S -A d d re s s in g zlikwidowano to krępujące ograniczenie.

7.2.6. Niezawodne komunikowanie a SOA Niezawodne kom unikow anie w sposób wym ierny przyczynia się do podnoszenia jakości usług w rozwiązaniach zorientowanych obiektowo (patrz rysunek 7.16). W prowadza elastyczny system gwarantujący prawidłowe dostarczanie sekwencji kom unikatów w połączeniu ze zrozumiałym raportow aniem sytuacji wyjątkowych. Zwiększa to solidność im plem entacji protokołu SOAP i uwalnia od specyficznych dla danej platform y komunikacyjnej problemów dotyczących jej nie­ zawodności. Zwiększenie jakości dostarczania kom unikatów SOAP przyczynia się także do polepszenia kanałów komunikacji między aplikacjami. Ograniczenia właściwe poszczególnym frameworkom komunikacyjnym nie wpływają już hamująco na potencjał integracyjny w skali przedsiębiorstwa.

7 .2 . N IE Z A W O D N E K O M U N IK O W A N IE

213

Rysunek 7.16. Związek niezawodnego komunikowania z innymi elementami SOA

A N A LIZA PRZYPADKU

W celu lepszego przystosowania do swych praktyk księgowych firm a RailCo preferuje wysy­ łanie faktur w skumulowanych wsadach pod koniec miesiąca. Ponieważ taka praktyka ko­ rzystna jest również dla wielu innych dostawców, TLS zgodziło się na nią — jednakże pod warunkiem, że wszystkie faktury z danego miesiąca od danego dostawcy muszą zostać prze­ słane w ram ach pojedynczej sekwencji. Daje to TLS możliwość skondensowanego potwier­ dzenia, że wszystkie kom unikaty z fakturami zostały pomyślnie odebrane. RailCo przystosowało się do tego wymogu i zmodyfikowało istniejącą usługę Wystawie­ nie faktury tak, że kom unikaty z fakturami pakowane są w sekwencje podlegające kontroli niezawodnego komunikowania (patrz rysunek 7.17).

Rysunek 7.17. Przy transmisji wsadu komunikatów z fakturami komunikat ostatni w sekwencji uruchamia wysłanie potwierdzenia przez TLS

214

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

P ie rw s z y w y s ła n y w s a d z a w ie r a ł 15 f a k tu r , z k tó r y c h — k u z a s k o c z e n iu R a ilC o — d o T L S d o t a r ło t y lk o 11 (c o w y n ik a ło z p o t w ie r d z e n ia s e k w e n c ji, w y s ła n e g o p o o d e b r a n iu o s ta tn ie g o k o m u n ik a t u ) . R a ilC o p o n o w n ie z m o d y f ik o w a ła w ię c w s p o m n ia n ą u s łu g ę : w p r z y p a d k u p o ­ w tó r n e g o w y s y ła n ia s e k w e n c ji k o m u n ik a t ó w w y m a g a n e je s t p o t w ie r d z a n ie k a ż d e g o k o m u ­ n ik a t u , co p o z w a la n a d o k ła d n ie js z e m o n it o r o w a n ie k o m u n ik a c ji i s k u te c z n ie js z e r e a g o w a n ie n a je j u s te r k i.

UWAGA W idoczna na rysunku 7 .17 bierna usługa R ów now ażenie obciążenia funkcjonuje bez związku z nie­ zaw odnym kom unikow aniem — przekazuje po prostu otrzym yw ane kom unikaty do docelowej usługi

Płatność na konto .

PODSUMOW ANIE •

Specyfikacja W S-ReliableMessaging definiuje fram ew ork gw arantujący dostarczanie kom unikatów SOAP oraz inform ow anie o nieudanych próbach ich dostarczenia.

•

Kluczowym elem entem tego fram ew orku jest system pow iadom ień bazujący na komunikatachpotwierdzeniach i zapew nieniach dostarczania składających się na reguły niezawodności.

•

Specyfikacja W S-R eliableM essagingjest ściśle powiązana ze specyfikacjami W S-Addressingi WS-Poiicy.

•

N iezaw odne kom unikow anie znacząco polepsza SOA na poziom ie jakości usług i powiększa jej potencjał interoperacyjności.

7 .3 . K o re la c je J e d n y m z fu n d a m e n t a ln y c h w y m a g a ń d o ty c z ą c y c h w y m i a n y in f o r m a c j i p r z e z u s łu g i s ie c io w e je s t z d o ln o ś ć d o u t r z y m y w a n ia p e w n e j in f o r m a c ji o k o n te k ś c ie i s ta n ie z ło ż o n e j in t e r a k c ji o b e jm u ją c e j w y m ia n ę w ie lu k o m u n ik a t ó w . F r a m e w o r k k o m u n ik a c y jn y ś r o d o w is k a z o r ie n to w a n e g o n a u s łu g i, ja k o z d e fin ic ji r e a liz u ją c y lu ź n e p o w ią z a n ie , p o z b a w io n y je s t g e n e r a ln ie r o d z im y c h m e c h a n iz m ó w w ią z a n ia z e w n ę tr z n e g o k o n te k s tu z p o s z c z e g ó ln y m i k o m u n ik a t a m i; n a w e t p r o s ty w z o r z e c M E P „ ż ą d a n ie - o d p o w ie d ź ” n ie d o s ta r c z a s a m z s ie b ie ż a d n y c h ś r o d k ó w u m o ż liw ia ją c y c h p o w ią z a n ie k o m u n ik a t u - o d p o w ie d z i z o d n o ś n y m k o m u n ik a t e m - ż ą d a n ie m .

K o r e la c ja ( c o r r e la tio n ) w y c h o d z i n a p r z e c iw t e m u z a p o tr z e b o w a n iu , f o r m u łu ją c ż ą d a n ie , b y p o w ią z a n e ze s o b ą k o m u n ik a t y z a w ie r a ły p e w n ą w s p ó ln ą w a rto ś ć , n a p o d s ta w ie k tó r e j u s łu g i b ę d ą m o g ły id e n t y f ik o w a ć f a k t , ż e w s p o m n ia n e k o m u n ik a t y u c z e s tn ic z ą w r e a liz a c ji w s p ó ln e g o z a d a ­ n ia ( lu b w in n y s p o s ó b są n a w z a je m z a le ż n e o d s ie b ie ). T a p r o s ta w s u m ie k o n c e p c ja je s t p r z e d ­ m i o t e m k i lk u s p e c y fik a c ji, w r ó ż n y s p o s ó b d e fin iu ją c y c h je j im p le m e n ta c ję . W k o le jn y c h p u n k ­ ta c h w y ja ś n i m y z a t e m , c z y m k o r e la c ja je s t w is to c ie i ja k im p le m e n t o w a n a je s t w ś w ie tle k i l k u r o z s z e r z e ń W S - * , k tó r e o m a w ia liś m y d o te j p o r y . N a r y s u n k u 7 .1 8 p r z e d s t a w io n o o b r a z o w o fa k t, że k o r e la c ja r e a liz o w a n a je s t n a p o z io m ie k o m u n ik a t ó w , a n ie k o m u n ik u ją c y c h się u s łu g .

7 .3 . KORELACJE

215

.Koleżanko B, jestem usługą bezstanową, a muszę w jakiś sposób upewnić się, że twoja odpowiedź faktycznie dotyczy mojego żądania"

„Ja też jestem bezstanowa, koleżanko A, więc jak miałabym ci to zapewnić?"

Rysunek 7.18. Korelacja powierza problem powiązania komunikatów samym komunikatom

UWAGA Przykłady typow ych im plem entacji korelacji za pom ocą n a g łó w kó w SOAP prezentujem y w rozdziale 17., w punkcie P odstaw y ję z yk a WS-Addressing.

PO PROSTU Aby dodatkow o zachęcić naszych klientów , w prow adziliśm y namiastkę programu lojalnościowego: każdy klient po dziesięciokrotnym skorzystaniu z naszych usług jedenaste mycie otrzymuje promocyjnie za darmo. Aby w prow adzić tę promocję w życie, udostępniliśmy każdemu klientow i kartę perforow aną, na której każda w izyta w naszej myjni odzwierciedlana jest w postaci kolejnego otw orka. Taka karta realizuje pew ną formę korelacji, bo kojarzy aktualną w izytę z poprzednimi. Bez niej trudno byłoby kontrolow ać wszystkich klientów pod w zględem uprawnień do promocji.

7.3.1. Korelacje jako abstrakcja Rozpocznijmy od podstawowego opisu korelacji, bez odwoływania się na razie do jakiejkolwiek jej implementacji. Na gruncie frameworków komunikacyjnych bazujących na ścisłych powiąza­ niach bardzo rzadko pojawia się problem korelowania ze sobą jednostek komunikacji (poszcze­ gólnych transmisji). Technologia realizująca powiązanie między kom ponentam i, bazami danych czy aplikacjami bazuje zwykle na aktywnym połączeniu, trwającym nieprzerwanie przez cały czas aktywności biznesowej (a być może i dłużej). Połączenie to stanowi wspólny kontekst wszystkich transmisji i korelacja tych transmisji zapewniana jest automatycznie przez protokół kom unika­ cyjny, na którym połączenie to się opiera. W w arunkach luźnego pow iązania nie m a takich trw ałych połączeń i opisany stan rzeczy zmienia się diametralnie. Gdy bezstanowa usługa wysyła kom unikat do innej, traci nad nim kon­ trolę i nie posiada żadnej inform acji na tem at kontekstu aktywności, w której kom unikat ten uczestniczy. Nie jest więc w stanie — sama z siebie — rozpoznawać związków między poszcze­ gólnymi komunikatami. A skoro tak, to realizację korelacji muszą wziąć na siebie same komunikaty. Realizuje się to przez wbudowanie pewnej wspólnej wartości w każdy z powiązanych kom unikatów (i w żaden inny). W artość ta jest umownym reprezentantem kontekstu, który w rzeczywistości może dotyczyć aktywności różnego rodzaju — prostego wzorca MEP, transakcji niepodzielnej lub długotrwałej

216

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

o r k ie s tr a c ji. U s łu g a , a n a liz u ją c tę w a r to ś ć w e w n ą tr z z b io r u k o m u n ik a t ó w , m o ż e w n io s k o w a ć o ic h z w ią z k u ze s o b ą (lu b o b r a k u ta k ie g o z w ią z k u ). Z o b a c z m y te r a z , j a k k o n c e p c ja k o r e la c ji r e a liz u je się w r a m a c h n ie k t ó r y c h ś r o d o w is k k o m p o ­ z y c ji o p is y w a n y c h w r o z d z ia le 6. o r a z n a g r u n c ie r o z s z e r z e ń k o m u n ik a t ó w o m a w ia n y c h d o ty c h c z a s w t y m r o z d z ia le .

7.3.2. Korelacje we wzorcach MEP i aktywno ś ciach Ja ko g e n e r y c z n e i z n a t u r y n ie p o s ia d a ją c e ż a d n y c h k o n o t a c ji b iz n e s o w y c h , w z o r c e M E P i a k t y w ­ n o ś c i n ie s k r y w a ją ż a d n y c h k o n c e p c ji k o r e la c y jn y c h . Są p o p r o s tu c e g ie łk a m i, z k t ó r y c h b u d o w a ć m o ż n a r o z w ią z a n ia w y k o r z y s tu ją c e w ła s n e f o r m y id e n t y f ik a t o r ó w k o r e la c ji ( w y n ik a ją c e z lo g ik i p r z e t w a r z a n ia ) b ą d ź t e ż o p ie r a ją c e s w e m e c h a n iz m y k o r e la c ji n a s ta n d a r d o w y c h s p e c y fik a c ja c h — z a jm i e m y się d o k ła d n ie j tą d r u g ą g r u p ą .

7.3.3. Korelacje w koordynacji F r a m e w o r k z a r z ą d z a n ia k o n te k s te m d e fin io w a n y p r z e z s p e c y fik a c ję W S - C o o r d in a tio n o b e jm u je z a a w a n s o w a n y m e c h a n iz m p r o p a g o w a n ia id e n t y f ik a t o r ó w i in f o r m a c j i k o n te k s to w e j m ię d z y u s łu g a m i. W y r ó ż n io n a u s łu g a a k ty w a c y jn a o d p o w ie d z ia ln a je s t z a k r e o w a n ie n o w y c h a k t y w n o ­ ś c i, a n a s tę p n ie t w o r z e n ie i d y s tr y b u c ję d a n y c h k o n t e k s t o w y c h z w ią z a n y c h z t y m i a k ty w n o ś c ia m i. U s łu g i m o g ą p r z e k a z y w a ć te in f o r m a c je i n n y m u s łu g o m , te n a to m ia s t w y k o r z y s t y w a ć j ą d o r e je ­ s tr o w a n ia się ja k o u c z e s tn ic z k i w s p o m n ia n e j a k ty w n o ś c i. Id e n t y f ik a t o r y k o r e la c ji, re p r e z e n tu ją c e k o n te k s ty o k re ś lo n e j a k ty w n o ś c i, to je d n a k ty lk o część z a a w a n s o w a n y c h m o ż liw o ś c i f r a m e w o r k u z a r z ą d z a n ia k o n te k s te m — m o ż liw o ś c i w y k o r z y s t y ­ w a n y c h p r z e z r o z m a it e p r o t o k o ły a k ty w n o ś c i, m i ę d z y i n n y m i d e fin io w a n e p r z e z r o z s z e r z e n ia

W S - A to m ic T r a n s a c tio n i W S -B u s in e s s A c tiv ity .

7.3.4. Korelacje w orkiestracji O r k ie s t r a c ja — w u ję c iu W S -B P E L — k o n c e n t r u je się n a k o r e la c ji k o m u n ik a t ó w w y m ie n ia n y c h m i ę d z y p r o c e s e m a u s łu g a m i p a r t n e r s k im i, c o s t w a r z a d o d a t k o w ą k o m p lik a c ję z w ią z a n ą z k o ­ n ie c z n o ś c ią r o z r ó ż n ia n ia p o s z c z e g ó ln y c h in s ta n c ji w s p o m n ia n e g o p r o c e s u w r a m a c h d a n y c h k o ­ r e la c y jn y c h . K o le jn a k o m p lik a c ja w y n ik a z f a k t u , ż e k o n k r e t n y k o m u n ik a t m o ż e u c z e s tn ic z y ć je d n o c z e ś n ie w w ie lu k o n te k s ta c h , id e n t y f ik o w a n y c h p r z e z r ó ż n e d a n e ( id e n t y f ik a t o r y ) k o r e la c ji. A b y u c z y n ić z a d o ś ć p o w y ż s z y m w y m a g a n io m , s p e c y fik a c ja W S -B P E L d e fin iu je s p e c y fic z n ą s k ła d n ię , p o z w a la ją c ą n a tw o r z e n ie r o z s z e r z a ln y c h z b i o r ó w k o r e l a c j i ( c o r r e la tio n sets). E le m e n ty te g o z b io r u , t r a k t o w a n e ja k o w ła ś c iw o ś c i (p ro p e rtie s ) k o m u n ik a t ó w , m o g ą b y ć d y n a m ic z n ie d o ­ d a w a n e , u s u w a n e i z m ie n ia n e , s to s o w n ie d o z m ie n ia ją c y c h się s c e n a r iu s z y w y m ia n y k o m u n ik a t ó w i s p e c y fik i r ó ż n y c h ś r o d o w is k .

7.3.5. Korelacje w adresowaniu Id e n t y f ik a t o r y ( I D ) k o m u n ik a t ó w d e fin io w a n e p r z e z W S -A d d re s s in g o r a z r e la c y jn e n a g łó w k i M I są n a t u r a l n y m i e l e m e n t a m i b u d o w a n ia k o r e la c ji, w y k o r z y s t y w a n y m i p r z e z w ie le r o z s z e r z e ń z w ią z a n y c h z k o m p o z y c ja m i u s łu g i ic h k o m u n ik o w a n ie m się.

7 .3 . KORELACJE

217

7.3.6. Korelacje w niezawodnym komunikowaniu Każdy komunikat będący częścią sekwencji definiowanej przez specyfikację WS-ReliableMessaging zawiera informację o sekwencji, której jest częścią. W skład tej informacji wchodzi unikatowy identyfikator wspom nianej sekwencji oraz identyfikator kom unikatu określający, jak ów kon­ kretny kom unikat wpisuje się w całą sekwencję. Informację tę m ożna by, co prawda, potraktować jako dane korelacyjne, jednakże podstawowym jej zadaniem jest zapewnienie niezawodności ko­ munikowania.

7.3.7. Korelacje a SOA Korelacja stanowi kluczowy czynnik zapewniający usługom zachowanie autonomii i bezstanowości. Możliwość postrzegania przez usługi kom unikatów jako skorelowanych ze sobą, jednak bez jakichkolwiek wymagań w tym względzie pod adresem samych usług, może nie wydawać się ni­ czym nadzwyczajnym, lecz z perspektywy SOA jest czynnikiem pierwszorzędnym dla zachowania luźnego powiązania i bezstanowości usług.

ANALIZA PRZYPADKU

Opisywany w rozdziale 6. proces wysyłania zleceń zakupu jest aktywnością złożoną obejmu­ jącą usługi Zlecenie zakupu (TLS) i Realizacja zamówienia (RailCo). W poprzednich przy­ kładach pokazywaliśmy, jak dynamicznie budowana jest ścieżka komunikatu zamówienia roz­ ciągająca się na wiele usług. Dla każdej usługi odbierającej komunikat wysłany przez usługę Zlecenie zakupu konieczne jest odróżnienie tego komunikatu od innych komunikatów wysyłanych przez tą usługę i okre­ ślenie kontekstu, w jakim ma on zostać przetworzony. W tym celu każdemu ze wspomnianych kom unikatów przyporządkowywany jest identyfikator będący funkcją num eru zamówienia i specyficznej wartości generowanej wewnętrznie przez rzeczoną usługę.

PODSUMOW ANIE •

Korelacja jest nieodłączną częścią dow olnej realizacji SOA, bo um ożliwia utrzym ywanie informacji o kontekście aktywności na przestrzeni wszystkich kom unikatów związanych z tą aktywnością, bez naruszania luźnego pow iązania między usługami.

•

Specyfikacje W S-* im plem entują korelacje w rozm aity sposób, jednak w większości zgodnie ze standardem specyfikacji

•

WS-Addressing.

M im o iż informacje zw iązane z korelacją mogą stanowić część ładunku użytecznego kom unikatów , jednak zadanie to powierza się najczęściej nagłów kom SOAP.

•

Korelacja jest podstaw ow ym elem entem kom unikow ania w SOA, poniew aż um ożliwia zachowanie bezstanowości usług i (do pewnego stopnia) wspiera autonom ię kom unikatów .

218

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

7 .4 .

Z a ło ż e n ia p o lity k i

Zostawmy na chwilę problematykę zaawansowanego komunikowania i zajmijmy się rozszerze­ niami WS-* definiującymi rozbudowane koncepcje zawiązane z m etadanymi usług sieciowych. Każde zadanie automatyzacji biznesu realizowane jest według pewnych reguł i w warunkach pewnych ograniczeń. Przekładają się one na określone zachowania usług składających się na to zadanie, a ich źródłem są między innymi: • bieżące wymagania biznesowe, • natura danych wymienianych w komunikatach, • organizacyjne środki zabezpieczeń. Ponadto każda usługa i każdy kom unikat posiadają unikatową charakterystykę, której ele­ m enty mogą być interesujące dla innych usług, jakie kom unikat spotyka na swej drodze. Do ele­ m entów tych należeć mogą: • charakterystyka behawioralna, • preferencje, • ograniczenia techniczne, • charakterystyka jakości usług (QoS). Powyższe właściwości, zwane powszechnie założeniami polityki lub po prostu politykami ( p o lic ie s ), mogą być odzwierciedlane w postaci publicznie dostępnych m etadanych należących do poszczególnych usług (patrz rysunek 7.19). „Dobrze, prześlij mi te dane"

'v

>

„Poczekaj, najpierw musisz zaakceptować moje reguły"

/

I

\

Usługa B

V\ , ____

\I J

Rysunek 7.19. Założenia polityki mogą wyrażać rozmaite właściwości usług, w tym reguły

Wykorzystywanie założeń polityki umożliwia usługom wyrażanie rozmaitych cech i preferen­ cji w sposób standardowy, bez konieczności samodzielnego implementowania reguł i ograniczeń. Założenia polityki dodają ważną warstwę abstrakcji, pozwalającą na niezależne zarządzanie wła­ ściwościami usług.

UWAGA W tym punkcie ograniczym y się do projektow ania założeń polityki na potrzeby usług sieciowych; w arto w spom nieć, że założenia polityki m ogą być kojarzone rów nież z innymi rodzajam i zasobów sieci W W W .

7 .4 . ZA ŁO ŻE N IA POLITYKI

219

PO PROSTU Pierwszą rzeczą, jaką oglądają kierowcy zajeżdżający do naszej myjni, jest instrukcja składająca się z trzech następujących punktów . •

Po w prow adzeniu samochodu na stanowisko należy wyłączyć silnik i opuścić pojazd.

•

Uprzedzamy, że nasze urządzenia pracują bardzo głośno.

•

Proponujemy oczekiwać na stacji paliw .

Pierwszy punkt wyraża w ym aganie, które spełnić musi kierowca (i ew entualni pasażerowie), by można było rozpocząć mycie samochodu; punkt drugi to informacja wyjaśniająca pewien aspekt funkcjonowania myjni, ostatni punkt zaw iera propozycję dla klientów (będzie dla nich bezpieczniej, a dla nas w ygodniej, gdy poczekają z dala od naszych stanowisk pracy). Każdy z wymienionych punktów wyraża fragm ent ogólnej polityki naszej firmy.

7.4.1. Framework WS-Policy F r a m e w o r k W S - P o lic y u s ta n a w ia r o z s z e r z e n ia d e d y k o w a n e z a r z ą d z a n iu s t r u k t u r ą d o k u m e n t ó w p o lit y k i ( p a tr z r y s u n e k 7 .2 0 ) o r a z k o ja r z e n ie m z a ło ż e ń p o lit y k i z z a s o b a m i sieci W W W . F r a m e w o r k t e n s k ła d a się z t r z e c h n a s tę p u ją c y c h s p e c y fik a c ji:

•

W S -P o lic y ,

•

W S - P o lic y A tta c h m e n ts ,

•

W S -P o lic y A s s e rtio n s .

( Z a u w a ż m y , ż e c z ę ś c ią f r a m e w o r k u W S -P o lic y je s t s p e c y fik a c ja o te j s a m e j n a z w ie ). S p e c y fi­ k a c ja W S - S e c u r ity P o lic y d e f in iu je z b ió r a s e rc ji p o l it y k i (p o lic y a s s e rtio n s ) n a u ż y t e k s p e c y fik a ­ c ji W S -S e c u rity ( k t ó r ą z a jm ie m y się d a le j w t y m r o z d z ia le ).

J

Opis polityki

Wariant polityki - typ asercji polityki - asercja polityki A - asercja polityki B

Wariant polityki - typ asercji polityki - asercja polityki C - asercja polityki D

R y s u n e k 7 .2 0 . P o d s ta w o w a struktura opisu polityki

220

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

U s łu g i-w n io s k o d a w c y m o g ą ( w czasie w y k o n y w a n ia ) p r o g r a m o w o u z y s k iw a ć d o s tę p d o z a ło ż e ń p o li t y k u s łu g -d o s ta r c z y c ie li, w c e lu r o z p o z n a n ia w y m a g a ń i o g r a n ic z e ń ty c h o s ta tn ic h . Z a ło ż e n ia p o lit y k i m o g ą b y ć ta k ż e s tu d io w a n e p r z e z lu d z i (n a e ta p ie p r o je k to w a n ia u s łu g ), b y p r z y s to s o w y w a ć p r o je k to w a n e u s łu g i-w n io s k o d a w c ó w d o s p e c y fic z n y c h w y m a g a ń k o n k r e tn y c h u s łu g -d o s ta rc z y c ie li. N a jn o w s z e p o p r a w k i w p r o w a d z o n e d o f r a m e w o r k u W S -P o lic y p o s z e r z y ły z a r ó w n o d e fin ic ję s t r u k t u r y d o k u m e n t u o p is u p o lit y k i, j a k i t e r m in o lo g ię z w ią z a n ą z te m a te m . W k o le jn y c h p u n k ­ ta c h p r z e d s ta w ia m y z a ry s w s p o m n ia n e g o f r a m e w o r k u w je g o o b e c n e j p o s ta c i.

UWAGA W rozdziale 17., w punkcie „Podstawy języka WS-Policy", przedstaw iam y przykładow e opisy polityki sporzą­ dzone w językach definiowanych przez specyfikacje z grupy WS-Policy.

7 . 4 . 2 . A s e r c je p o l i t y k i i w a r i a n t y p o l i t y k i

asercji polityki ( p o lic y a s s e rtio n s ); o p is p o li t y k i je s t w ię c z b io r e m t a k ic h a s e rc ji. A s e r c ja m o ż e o d z w ie r ­ P o s z c z e g ó ln e w ła ś c iw o ś c i u s łu g i, s k ła d a ją c e się n a o p is je j p o lit y k i, w y r a ż o n e są w f o r m ie

c ie d la ć c e c h ę c h a r a k te r y s ty c z n ą u s łu g i, je j p r e fe r e n c je , m o ż liw o ś c i, w y m a g a n ia lu b r e g u ły . D a n a a s e rc ja m o ż e b y ć o z n a c z o n a ja k o o b o w ią z k o w a a lb o o p c jo n a ln a . A s e rc je p o li t y k i m o g ą b y ć g r u p o w a n e w

warianty polityki 2 ( p o lic y a lte rn a tiv e s ) . K a ż d y ta k i

w a r ia n t s ta n o w i je d n ą z m o ż liw y c h ( lu b d o p u s z c z a ln y c h ) k o m b in a c ji a s e rc ji. D a je to u s łu g o m d o s ta r c z y c ie lo m z d o ln o ś ć o fe r o w a n ia u s łu g o m -w n io s k o d a w c o m r ó ż n y c h w a r ia n t ó w p o li t y k i d o w y b o r u . ( A n a lo g ic z n ie d o o s ta tn ie j h is to r y jk i „ P o p r o s t u ...” — k a ż d y z tr z e c h p u n k t ó w c y to w a n e j lis ty m o ż e b y ć t r a k t o w a n y ja k o a s e rc ja p o lity k i) .

7 . 4 .3 . T y p y a s e r c ji p o lit y k i i s ło w n ik i p o lity k i A s e rc je p o li t y k i m o g ą b y ć k la s y fik o w a n e w r a m a c h

typów asercji polityki (p o lic y a s s e rtio n ty p e s).

Z a lic z e n ie a s e r c ji d o o k r e ś lo n e g o t y p u o z n a c z a p o w ią z a n ie je j z o k r e ś lo n y m s c h e m a te m X S D . P o d o b n ie j a k s ł o w n ik i X M L d e f in io w a n e są w r a m a c h s c h e m a tó w X S D , t a k

słowniki polityki

( p o lic y v o c a b u la rie s ) r e p r e z e n t u ją k o le k c je t y p ó w a s e rc ji w r a m a c h d a n e j p o lit y k i. A n a lo g ic z n ie ,

słownik wariantów polityki ( p o lic y a lte r n a tiv e v o c a b u la r y ) o k re ś la t y p y a s e rc ji u ż y w a n e w o k r e ­ ś lo n y m w a r ia n c ie p o lit y k i.

7 .4 .4 . P o d m io ty p o lity k i i z a k r e s y p o lity k i Z a ło ż e n ia p o li t y k i m o g ą b y ć k o ja r z o n e z o b ie k t a m i r ó ż n e g o r o d z a ju : u s łu g a m i s ie c io w y m i, k o ­

pod­ miotem te j p o li t y k i ( p o lic y s u b je c t). D a n a p o lit y k a m o ż e b y ć s k o ja r z o n a z w ie lo m a p o d m io t a m i — ic h z b ió r o k re ś la się m ia n e m zakresu polityki ( p o lic y scope).

m u n i k a t a m i lu b i n n y m z a s o b a m i; z a s ó b s k o ja r z o n y z k o n k r e t n ą p o li t y k ą n a z y w a n y je s t

2 Tłum aczenie dosłowne „alternatywy polityki” nie byłoby w ierne znaczeniowo. W języku angielskim alternatives to zbiór równoprawnych możliwości, z których wybiera się jedną. W języku polskim „alternatywa” to rozwiązanie konkurencyjne dla pewnego rozwiązania zasadniczego; jeżeli nawet dopuścimy liczbę mnogą, to słowo „alternatywy” może oznaczać zbiór możliwości, z których każda stanowić może alternatywę dla rozwiązania zasadniczego nienależącego do tego zbioru. Różnica jest, jak widać, wyraźna, stąd polski odpowiednik „warianty”, a nie „alternatywy” — przyp. tłum.

7 .4 . ZA ŁO ŻE N IA POLITYKI

221

7 . 4 .5 . W y r a ż e n ia p o lit y k i i z a łą c z n ik i p o lity k i F iz y c z n e im p le m e n t a c je a s e rc ji p o li t y k i w ję z y k u W S -P o lic y n a z y w a n e są w y r a ż e n i a m i p o l i t y k i

( p o lic y e x p re s s io n s ). I n n y m i s ło w y , w y r a ż e n ie p o li t y k i to je j a s e rc ja z a p is a n a w f o r m ie in s t r u k c ji X M L m o ż liw e j d o p r z e t w o r z e n ia w s p o s ó b p r o g r a m o w y . W y r a ż e n ia p o li t y k i w ią z a n e są fiz y c z n ie z z a k r e s a m i p o li t y k i p r z y u ż y c iu z a łą c z n ik ó w p o l i t y k i ( p o lic y a tta c h m e n ts ).

7 . 4 .6 . Z a ło ż e n ia p o lit y k i w k o o r d y n a c ji G d y u s łu g a k o o r d y n a c y jn a g e n e r u je in f o r m a c ję k o n te k s to w ą d la u s łu g u c z e s tn ic z ą c y c h (z g o d n ie ze s p e c y fik a c ją W S - C o o r d in a tio n ) , d y s tr y b u c ja te j in f o r m a c j i s ta je się p o d m io t e m w a lid a c ji p o d k ą t e m u p r a w n i e ń , u w ie r z y t e ln ia n ia i in n y c h f o r m z a b e z p ie c z e ń . A b y tę w a lid a c ję u s k u t e c z n ić , k o o r d y n a c ja m o ż e b y ć s te r o w a n a r e g u ła m i u s ta n a w ia n y m i w r a m a c h z a ło ż e ń p o lit y k i.

7 . 4 .7 . Z a ło ż e n ia p o lit y k i w o r k ie s tr a c ji i c h o r e o g r a fia c h Z a ł o ż e n i a p o l i t y k i m o g ą b y ć s to s o w a n e w o d n ie s ie n iu d o d o w o ln y c h p o d m i o t ó w u w ik ł a n y c h w o r k ie s tra c je lu b c h o re o g ra fie . Z a ło ż e n ia p o lit y k i m o g ą m ię d z y in n y m i o k re ś la ć r o z m a ite w y m a ­ g a n ia p o d a d re s e m u s łu g p a r tn e r s k ic h o r k ie s tr a c ji i u s łu g u c z e s tn ic z ą c y c h w c h o r e o g r a fii.

7 .4 .8 . Z a ło ż e n ia p o lity k i w n ie z a w o d n y m k o m u n ik o w a n iu S p e c y fik a c ja W S -R e lia b le M e s s a g in g z a le ż n a je s t o d f r a m e w o r k u W S -P o lic y , g d y ż te n u m o ż liw ia fu n k c jo n o w a n ie n ie k tó r y c h je j f u n d a m e n t a ln y c h e le m e n tó w . Z a ło ż e n ia p o lit y k i u ż y w a n e są d o i m ­ p le m e n to w a n ia z a p e w n ie ń d o s ta r c z e n ia p o p r z e z d o łą c z a n ie d o k o m u n ik a t ó w ( w f o r m ie z a łą c z n i­ k ó w ) r e g u ł p o li t y k i o k re ś la ją c y c h n ie z a w o d n o ś ć k o m u n ik o w a n ia . U z u p e łn ia ją c e z b io r y a s e rc ji p o lit y k i m o g ą d e fin io w a ć d o d a tk o w e re g u ły , o g r a n ic z e n ia i w y m a g a n ia r e a liz u ją c e tę n ie z a w o d n o ś ć .

7 .4 .9 . Z a ło ż e n ia p o lity k i a S O A Jeśli p o r ó w n a ć S O A d o m ia s ta , z a ło ż e n ia p o li t y k i s ta ją się a n a lo g ią lo k a ln y c h p r a w , r e g u la c ji i w s k a z ó w e k o r g a n iz u ją c y c h ż y c ie m ie s z k a ń c ó w . P o lit y k a s ta je się n ie o d z o w n y m e le m e n t e m b u ­ d o w a n ia r o z w ią z a ń z o r ie n t o w a n y c h n a u s łu g i w s k a li p r z e d s ię b io r s tw , p o n ie w a ż d o s ta r c z a ś r o d k i d o r e a liz a c ji o g r a n ic z e ń , r e g u ł i w y t y c z n y c h d la k a ż d e g o n ie m a l a s p e k tu in t e r a k c ji u s łu g . W r e ­ z u lta c ie p r z y c z y n ia się d o o g ó ln e g o p o le p s z e n ia ja k o ś c i w s p ó łd z ia ła n ia u s łu g , p r z y z a c h o w a n iu ic h lu ź n e g o p o w ią z a n ia ( p a t r z r y s u n e k 7 .2 1 ) . P o li t y k a d a n e j u s łu g i u m o ż li w i a je j p o d a n ie n a s w ó j t e m a t z n a c z n ie w ię c e j i n f o r m a c j i, n iż b y ło b y to m o ż liw e p r z y u ż y c iu s ta n d a r d o w e j w y m i a n y d a n y c h i k o m u n ik a t ó w w o p a r c iu li ty lk o o d e fin ic je W S D L . Z a ło ż e n ia p o lity k i u s łu g p o s z e rz a ją r ó w n ie ż z a k re s d o s tę p u ty c h u s łu g d o r ó ż n y c h m e ta d a n y c h , p o z w a la ją c je d n o c z e ś n ie t y m u s łu g o m n a z a c h o w a n ie ic h w z a je m n e j n ie z a le ż n o ś c i. Z a ło ż e n ia p o lit y k i, n a r z u c a ją c z a s a d y i o g r a n ic z e n ia n a tr a n s m is ję k o m u n ik a t ó w , p r z y c z y n ia ją się d o o g ó ln e g o p o le p s z e n ia ja k o ś c i u s łu g d o s tę p n y c h w r a m a c h S O A . Z w ią z a n ie z a ło ż e ń p o lit y k i z p u n k t e m k o ń c o w y m z n a c z ą c o u w a ln ia a p lik a c ję z w ią z a n ą z t y m p u n k t e m o d p r z e t w a r z a n ia s y tu a c ji w y ją t k o w y c h w y w o ła n y c h o d b ie r a n ie m n ie d o z w o lo n y c h k o m u n ik a t ó w .

222

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

Rysunek 7.21. Związek założeń polityki z innymi elementami SOA

Założenia polityki w naturalny sposób podwyższają poziom interoperacyjności usług, bo sta­ nowią wygodny środek wyrażania i publikowania obszernej informacji na tem at punktów koń­ cowych tych usług. Ponadto, zwiększając treściwość kontraktów usług, otwierają drogę do ich dy­ namicznego odnajdywania i wiązania.

A N A LIZA PRZYPADKU

Niedawno firma TLS zaktualizowała część swego oprogramowania middleware, które teraz zdolne jest do współpracy z frameworkiem niezawodnego komunikowania na zasadach okre­ ślonych w najnowszej wersji specyfikacji WS-ReliableMessaging. Oczywiście, TLS chce wyko­ rzystywać tę możliwość, lecz zdaje sobie sprawę z tego, że jej partnerzy jeszcze przez jakiś czas korzystać będą ze starszej wersji wspomnianej specyfikacji. TLS zmuszona jest więc do zapewnienia obsługi obu wersji rzeczonej specyfikacji, w związku z czym pojawia się doku­ m ent zawierający odpowiedni w ariant polityki. Zgodnie w owym wariantem, usługa Profile dostawców akceptować będzie w otrzymy­ wanych kom unikatach nagłówki zgodne z obiema wersjami WS-ReliableMessaging, przy jed­ noczesnym preferowaniu nowej wersji. Nieco później wspomniany wariant wzbogacony został o asercję wyrażającą wymaganie dotyczące specyficznego kodowania komunikatu: niezależnie od tego, która wersja WS-ReliableMessaging zostanie wybrana przez usługę-wnioskodawcę, wymagane jest identyczne kodowanie tekstu.

P O D S U M O W A N IE •

Fram ew ork W S-Policy dostarcza środki do kojarzenia właściwości (reguł, zasad zachow ania, w ym agań

•

Poszczególne właściwości reprezentow ane są przez asercje polityki, które mogą być oznaczane jako obow iązkow e albo opcjonalne. Um ożliw ia to usługom kom unikow anie swych kategorycznych w arunków i preferencji.

•

Fram ew ork W S-Policy używ any jest łącznie z w ielom a innymi rozszerzeniami WS-*.

•

Założenia polityki dodają do SOA istotną w arstw ę metadanych, zwiększającą potencjał usług w zakresie w ykrywalności i interoperacyjności, co przyczynia się do ogólnego polepszenia jakości usług.

i preferencji) z zasobami sieciowymi W W W , głów nie usługami sieciowymi.

7 .5 . W Y M IA N A M E TA D A N Y C H

223

7 .5 . W y m ia n a m e ta d a n y c h G d y w r o z d z ia le 3. p o r a z p ie r w s z y o m a w ia liś m y k o n c e p c ję lu ź n e g o p o w ią z a n ia m ię d z y u s łu g a m i, w y ja ś n ia liś m y , że je d y n y m w y m a g a n ie m u s łu g i-w n io s k o d a w c y w s to s u n k u d o u s łu g i-d o s ta r c z y c ie la p e łn ią c e j r o lę o d b io r c y k o ń c o w e g o je s t p o s ia d a n ie o p is u te j o s ta tn ie j. O p is te n , s k ła d a ją c y się z d e fi­ n ic ji W S D L o r a z e w e n tu a ln ie s k o ja rz o n y c h z n ią s c h e m a tó w X S D , d o s ta rc z a u s łu d z e -w n io s k o d a w c y p o d s ta w o w y z b ió r m e ta d a n y c h (m e ta d a ta ) n ie z b ę d n y c h d o te g o , b y m o g ła o n a w y s y ła ć p o p r a w n e k o m u n ik a t y S O A P d o p r z e tw o r z e n ia p r z e z u s łu g ę -d o s ta rc z y c ie la . P o le k tu r z e f r a g m e n tu p o ś w ię c o n e g o z a ło ż e n io m p o lit y k i w ie m y ju ż , że z a ło ż e n ia te — je ś li się ic h u ż y w a — d o d a ją k o le jn ą is to tn ą w a rs tw ę d o stosu m e ta d a n y c h . D z ię k i n im u s łu g a -w n io s k o d a w c a m o ż e w y s y ła ć k o m u n ik a t y S O A P z g o d n e z a r ó w n o z w y m a g a n ia m i in te r fe js u z a w a r t y m i w d e fin ic ji W S D L , ja k i z e s k o ja r z o n y m i a s e rc ja m i p o lity k i. N ie z a le ż n ie je d n a k o d te g o , j a k o b s z e rn e n ie b y ły b y m e t a d a n e u d o s tę p n ia n e p r z e z u s łu g ę , p o ­ z o s ta je p r o b le m ic h o d n a jd y w a n ia , k t ó r e m o ż e b y ć r e a liz o w a n e n a r ó ż n e s p o s o b y , ta k ie ja k : •

r ę c z n e lo k a liz o w a n ie d r o g ą p r z e s z u k iw a n ia o p u b lik o w a n y c h d o k u m e n t ó w ,

•

u z y s k iw a n ie w d r o d z e k o n t a k t u z w ła ś c ic ie le m u s łu g i ( p o d m io t e m - d o s t a r c z y c ie le m ) ,

•

p r o g r a m o w e w y s z u k iw a n ie w p u b lic z n y m r e je s tr z e u s łu g ,

•

p r o g r a m o w e w y s z u k iw a n ie p r z e z in te r a k c ję ze s p e c ja ln y m i in t e r fe js a m i u d o s t ę p n ia n y m i p r z e z p o d m io t -d o s ta r c z y c ie la .

Z w y ją t k ie m t r z e c ie j p o z y c ji, w s z y s tk ie p o z o s ta łe w y d a ją się m a ło a tr a k c y jn e i m a ło e fe k ty w n e . B y ło b y w s p a n ia le , g d y b y m o ż n a b y ło w y s ła ć d o p o d m io tu -d o s ta r c z y c ie la s ta n d a rd o w e ż ą d a n ie w r o ­ d z a ju „ p o d a j m i k o m p le tn ą in fo r m a c ję , d z ię k i k tó r e j b ę d ę m o g ła o c e n ić m o ż liw o ś c i tw o je j u s łu g i-d o ­ s ta rc z y c ie la i n a w ią z a ć z n ią in t e r a k c ję ”. B y ło b y w s p a n ia le — i je s t w s p a n ia le , b o ta k a je s t w ła ś n ie f u n k c ja

wymiany metadanych ( m e ta d a ta e x c h a n g e ) z ilu s t r o w a n a p o g lą d o w o n a r y s u n k u 7 .2 2 .

Rysunek 7.22. Wymiana metadanych pozwala usługom-wnioskodawcom na uzyskiwanie żądanych informacji o usługach-dostarczycielach

PO PROSTU W miarę jak rosło zainteresow anie naszą myjnią i zwiększała się ilość pracy do w ykonania. postanowiliśmy zatrudnić now ego pracownika na pełny etat. Zamiast umieszczania ogłoszenia w lokalnej prasie, postanow i­ liśmy najpierw poszukać chętnych wśród starych znajomych. Poprosiliśmy ewentualnych kandydatów o dostarczenie CV w raz z referencjami z poprzedniego zatrud­ nienia. Zdarzało się, że do nadsyłanych CV nie były dołączone rzeczone referencje bądź załączone było wyjaśnienie, że zainteresow any może dosłać je na osobne żądanie. W takich przypadkach kontaktowaliśm y się z kandy­ datem , prosząc o dostarczenie brakującego dokum entu. Powyższa analogia ilustruje prostotę koncepcji wymiany metadanych. Najpierw kontaktowaliśmy się („wysyłali­ śmy żądanie") ze znajomymi („zasobami"), prosząc ich o dostarczenie (meta) informacji na swój temat. Jeśli dostar­ czona informacja nie była kompletna, kontaktowaliśmy się ponownie, prosząc („żądając") o uzupełnienie braków.

224

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

7 .5 .1 .

S p e c y f i k a c ja W S - M e t a d a t a E x c h a n g e

T y t u ło w a s p e c y fik a c ja o k r e ś la s t a n d a r d o w y s p o s ó b k o m u n ik o w a n ia s ię u s łu g i- w n io s k o d a w c y z p u n k t e m k o ń c o w y m p o te n c ja ln e j u s łu g i-d o s ta r c z y c ie la , w c e lu u z y s k a n ia p e łn e j lu b c z ę ś c io w e j m e t a in f o r m a c ji d o ty c z ą c e j te g o p u n k t u . I n n y m i s ło w y , je ś li u s łu g a -w n io s k o d a w c a z n a lo k a liz a c ję u s łu g i-d o s ta r c z y c ie la , m o ż e o d n ie j u z y s k a ć d o k u m e n t y s k ła d a ją c e się n a je j o p is i fo r m u łu ją c e je j k o n t r a k t , w y s y ła ją c

żądanie wymiany metadanych ( m e ta d a ta e x ch a n g e re q u e s t).

W p ie r w o t n e j w e r s ji s p e c y fik a c ja W S -M e ta d a ta E x c h a n g e d e f i n io w a ł a t r z y n a s tę p u ją c e t y p y k o m u n ik a t ó w : •

G et W SD L,

•

G e t S chem a,

•

G e t P o lic y .

I c h o ć k o m u n ik a t y te r e p r e z e n t u ją t y p y m e t a in f o r m a c ji n a jc z ę ś c ie j u ż y w a n e w o d n ie s ie n iu d o u s łu g s ie c io w y c h , to a u t o r z y r y c h ło d o s z li d o w n io s k u , że j u ż w n ie d a le k ie j p r z y s z ło ś c i m o g ą p o ­ ja w ić się i z y s k a ć p o p u la r n o ś ć in n e ty p y , tr u d n e d o p r z e w id z e n ia a p r io r i. W r e z u lta c ie z r e w id o w a n a tre ś ć s p e c y fik a c ji d e fin iu je o b e c n ie t y lk o je d e n ty p k o m u n ik a t u - ż ą d a n ia w y m i a n y m e ta d a n y c h : •

G e t M e ta d a ta

w o d m ia n a c h „ ż ą d a n ie ” i „ o d p o w ie d ź ” . K o m u n ik a t t e n u z u p e ł n io n y z o s ta ł o k o m u n i k a t G e t w id e n t y c z n y c h o d m ia n a c h . O b a k o m u n ik a t y o p is y w a n e są w n a s tę p n y c h p u n k t a c h .

UWAGA Przykłady żądań i odpowiedzi w ym iany metadanych, zgodnie ze specyfikacją WS-MetadataExchange, przed­ staw iam y w rozdziale 17., w punkcie „Podstawy języka W S-M etadataExchange"

7 .5 .2 .

K o m u n ik a ty ż ą d a n ia i o d p o w ie d z i G e t M e t a d a t a

Ja k w s p o m in a liś m y , u s łu g a -w n io s k o d a w c a m o ż e w y k o r z y s t y w a ć w y m ia n ę m e ta d a n y c h d o p r o ­ g r a m o w e g o ż ą d a n ia d o s tę p n y c h d o k u m e n t ó w m e ta d a n y c h s k o ja rz o n y c h z u s łu g ą s ie c io w ą . W t y m

komunikat-żądanie udostępnienia metadanych (G e t M e ta d a ta re q u e s t), kom unikat-odpowiedź udostępnienia metadanych (G e t M e ta d a ta response) d o p e łn ia ją c y te n w z o rz e c . O to , co s z c z e g ó ło w o

c e lu m u s i o n a w y s ła ć

s ta n o w ią c y p ie r w s z ą czę ś ć z n a n e g o w z o r c a M E P , w r e z u lt a c ie o t r z y m a d z ie je się z a k u lis a m i te g o w z o rc a .

1. U s łu g a -w n io s k o d a w c a w y s y ła k o m u n ik a t G e t M e t a d a ta re q u e s t. W k o m u n ik a c ie t y m m o ż e ż ą d a ć u d o s t ę p n ie n ia o k re ś lo n e g o e le m e n t u o p is u u s łu g i-d o s ta r c z y c ie la ( d e f in ic ji W S D L , s c h e m a tu X S D lu b z a ło ż e ń p o lit y k i) a lb o c a ło ś c i d o s tę p n y c h m e ta d a n y c h . 2. K o m u n ik a t G e t M e t a d a ta re q u e s t o d e b r a n y z o s ta je p r z e z p u n k t k o ń c o w y , d o k tó r e g o z o s ta ł z a a d r e s o w a n y . Ż ą d a n a m e t a in f o r m a c ja u f o r m o w a n a z o s ta je w p o s ta ć w y s y ła n e g o k o m u n i ­ k a t u G e t M e t a d a ta response. 3. K o m u n ik a t G e t M e ta d a ta response o d e b r a n y zo s ta je p r z e z u s łu g ę -w n io s k o d a w c ę . W je g o treś ci ż ą d a n a m e ta in fo r m a c ja m o ż e b y ć re p r e z e n to w a n a p r z e z k o p ie o d n o ś n y c h d o k u m e n tó w lu b a d ­ re s y ty c h d o k u m e n tó w ( w ty m s a m y m k o m u n ik a c ie m o g ą w y s tę p o w a ć i je d n e , i d r u g ie ).

7 .5 . W Y M IA N A M E T A D A N Y C H

225

P o w y ż s z y s c e n a r iu s z z ilu s tr o w a n o n a r y s u n k u 7 .2 3 .

Rysunek 7.23. Przykładowa treść komunikatu Get Metadata response

7 .5 .3 .

K o m u n ik a ty ż ą d a n ia i o d p o w ie d z i G e t

K o m u n ik a t G e t M e t a d a ta re sp o n se o d b ie r a n y p r z e z u s łu g ę -w n io s k o d a w c ę w k r o k u 3. p o p r z e d ­ n ie g o s c e n a r iu s z a n ie k o n ie c z n ie m u s i z a w ie r a ć k o p ie d o k u m e n t ó w z a w ie r a ją c y c h ż ą d a n ą m e ta in f o r m a c ję , m o ż e z a w ie r a ć je d y n ie a d re s y ( U R I ) ty c h d o k u m e n t ó w . W s c e n a r iu s z u p r z e d s ta w io ­ n y m n a r y s u n k u 7 .2 3 u d o s t ę p n io n a in f o r m a c ja z a w ie r a k o p ie d e fin ic ji W S D L i s c h e m a tu X S D , je d n a k ż e d o k u m e n t z a ło ż e ń p o li t y k i r e p r e z e n t o w a n y je s t je d y n ie p r z e z a d re s , s p o d k tó r e g o m o ż ­ n a d o p ie r o p o b r a ć ż ą d a n ą tre ś ć . A b y w p e łn i z a u to m a t y z o w a ć m a te r ia liz a c ję d o k u m e n t ó w r e p r e ­ z e n to w a n y c h w t a k p o ś r e d n i s p o s ó b , s p e c y fik a c ja W S -M e ta d a ta E x c h a n g e u d o s tę p n ia u s łu g o m w n io s k o d a w c o m d w a k o le jn e k o m u n ik a t y : ż ą d a n ie p o b r a n ia (G e t re q u e s t) i o d p o w ie d ź p o b r a n ia ( G e t re sponse ). O t o k r ó t k i o p is s c e n a r iu s z a te g o p o d p ro c e s u . 1. P o o d e b r a n iu k o m u n ik a t u G e t M e t a d a ta re sp o nse u s łu g a -w n io s k o d a w c a s tw ie r d z a , ż e p e ­ w ie n d o k u m e n t z a w ie r a ją c y ż ą d a n ą m e t a in f o r m a c ję r e p r e z e n t o w a n y je s t w t y m k o m u n ik a ­ c ie je d y n i e p r z e z a d re s U R I . U s łu g a w y s y ła w ię c k o m u n ik a t G e t re q u e s t z e w s k a z a n ie m , k t ó r a część m e t a in f o r m a c ji je s t d la n ie j in te r e s u ją c a . 2 . K o m u n ik a t G e t re q u e s t z o s ta je o d e b r a n y p r z e z p u n k t k o ń c o w y , d o k t ó r e g o z o s ta ł z a a d r e ­ s o w a n y . K o p ia ż ą d a n e g o d o k u m e n tu u fo r m o w a n a z o s ta je w p o s ta ć w y s y ła n e g o k o m u n ik a t u

G e t response. 3 . K o m u n ik a t G e t M e t a d a ta re sp o n se o d e b r a n y z o s ta je p r z e z u s łu g ę -w n io s k o d a w c ę . N a r y s u n k u 7 .2 4 p r z e d s t a w io n o p o w y ż s z y s c e n a r iu s z , s k u t k u ją c y d o s ta r c z e n ie m u s łu d z e - w n io s k o d a w c y c a łe j ż ą d a n e j m e t a in f o r m a c ji i t y m s a m y m z a m y k a ją c y p ro c e s w y m i a n y m e t a d a n y c h m ię d z y u s łu g a m i.

226

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

Rysunek 7.24. Przykładowa treść komunikatu Get response

7 .5 .4 .

S e le k ty w n e p o b ie r a n ie m e ta d a n y c h

M etadokum enty opisujące usługi z rozbudowanymi interfejsami mogą by objętościowe, zawłasz­ cza gdy grupowane są w olbrzymie megadokumenty. Selektywne użycie kom unikatów Get request może w takiej sytuacji wyeliminować przesyłanie sporych nawet porcji niepotrzebnych informacji. Usługa-wnioskodawca powinna rozpocząć wymianę metadanych od wysłania komunikatu Get M etadata request, otrzymując w rezultacie podstawowe porcje metainformacji; zwróćmy uwagę, że z pojedynczym punktem końcowym skojarzonych może być wiele definicji WSDL, schematów XSD i dokum entów założeń polityki. Po określeniu zestawu brakujących jeszcze informacji usłu­ ga może je pobrać za pom ocą kom unikatu Get request.

7 .5 .5 .

W y m i a n a m e t a d a n y c h a o d n a j d y w a n i e o p i s ó w u s łu g

Należy w tym miejscu zauważyć, że wymiana m etadanych nie stanowi dla usług-wnioskodawców znaczącej pom ocy w odnajdywaniu interesujących je usług-dostarczycieli. Temu celowi służą re­ jestry usług, między innym i te, które są zgodne ze standardem UDDI i ułatwiają wyszukiwanie usług spełniających określone kryteria. Ponieważ jednak rejestry te zawierają informację o bieżą­ cej lokalizacji definicji WSDL dla poszczególnych usług, wykorzystywane są często w kontekście wymiany metadanych. Usługa-wnioskodawca, przeszukując publiczny rejestr usług, odnajduje najpierw te kandydatury, które potencjalnie mogą być dla niej interesujące z pewnej perspektywy. Następnie, wykonując wy­ mianę m etadanych z punktam i końcowymi wstępnie wybranych kandydatur, uzyskuje na ich te­ m at bardziej szczegółowe inform acje i być może zawęża swój wybór; jednocześnie wchodzi ona w posiadanie informacji, które umożliwiają jej nawiązanie żądanych interakcji. Reasumując — mim o iż wymiana m etadanych jako taka nie przyczynia się do usprawnienia procesu odnajdywania usług, niewątpliwie stanowi wygodne uzupełnienie tego procesu. I w tym kontekście m ożna ją uważać za przyczynek do wykrywalności usług.

7 .5 . W Y M IA N A M E TA D A N Y C H

227

7.5.6. Wymiana metadanych a kontrola wersji Przedstaw ialiśm y dotąd proces w ym iany m etadanych jako narzędzie umożliwiające usługom-*wnioskodawcom uzyskiwanie informacji niezbędnych do nawiązywania interakcji z usługami-dostarczycielami. Specyfikacja W S-MetadataExchange jest użyteczna także z innej p er­ spektywy: w dużym stopniu automatyzuje administrowanie kontraktam i usług. Usługi nie są statyczne, podlegają rozwojowi, zm ienia się więc zakres i natura oferowanej przez nie funkcjonalności. Zmiany te uwidaczniają się także na poziomie warstwy m eta, w postaci nowych wersji definicji WSDL, schematów XSD i założeń polityki. A to rodzi odwieczny problem zgodności wersji. Usługi-wnioskodawcy współpracujące z określoną wersją usługi-dostarczyciela muszą być albo informowane zawczasu o dokonaniu opisanych zmian, albo też musi im zostać zapewniona możliwość dalszej współpracy a tą samą, nie najnowszą już, wersją usługi. Niektóre rozwiązania bazujące na usługach radzą sobie z tym problemem za pomocą specjali­ zowanych procesów wyszukujących najnowsze opisy określonych usług. Taką samą możliwość, i to w postaci zestandaryzowanej, oferuje wymiana m etadanych — każda aplikacja zorientowana na usługi, obsługująca ten mechanizm, może wyszukiwać i pobierać aktualne kontrakty interesu­ jących usług tak często, jak tylko jest to uzasadnione jej specyfiką. Jeśli oczekiwana dynamika zmian w metainformacji usług-dostarczycieli wydaje się być duża, m ożna projektować usługi-wnioskodawców w ten sposób, by okresowo pobierały tę informację w bieżącej postaci i konfrontowały ją z postacią dotychczasową. Efektem takiego porównania może być rezygnacja z nawiązania interakcji wskutek zbyt dużych różnic w zakresie interfejsu, sche­ matów czy założeń polityki albo wskutek odrzucenia (przez usługę-dostarczyciela) standardowego komunikatu SOAP (z tych samych przyczyn). Dalsze postępowanie usługi-wnioskodawcy w takiej wyjątkowej sytuacji może zostać powierzone procedurze obsługi wyjątków.

7.5.7. Wymiana metadanych a SOA Prosta skądinąd koncepcja wymiany m etadanych stanowi wsparcie dla niektórych kluczowych elementów SOA (patrz rysunek 7.25). Automatyzacja wyszukiwania metainformacji sprzyja kon­ cepcji luźnego powiązania między usługami i ułatwia usługom-wnioskodawcom uzyskiwanie nie­ zbędnej wiedzy na tem at potencjalnych usług-dostarczycieli. Weryfikowanie tychże pod kątem przydatności do określonego celu jest ułatwione dzięki temu, że odbywa się w sposób standardowy i może być wykonywane programowo. Dzięki temu usprawniony zostaje element wykrywalności usług, a także zwiększa się szansa na odkrywanie elementów wieloużywalności tkwiącej w tych usługach.

R y s u n e k 7 .2 5 . Z w ią z e k w y m ia n y m e ta d a n y c h z innym i e le m e n ta m i SOA

228

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

Ustanowienie standardowych środków wymiany opisów usług znacząco przyczynia się do ich interoperacyjności, zwłaszcza w dynam icznie ewoluujących środow iskach. Dzięki możliwości „przepytywania” usług-dostarczycieli przed nawiązaniem z nim i interakcji, usługi-wnioskodawcy mogą zweryfikować a priori poprawność zamierzonych scenariuszy wymiany komunikatów. Eli­ minuje to również wiele problemów związanych z administrowaniem kontraktam i usług, co jest znaczącym krokiem w kierunku polepszenia jakości usług. W arto również zauważyć, że standardow a w ym iana m etadanych uwalnia program istów od zajmowania się nią w czasie projektowania usługi oraz od tworzenia dedykowanych jej rozszerzeń we własnym zakresie. Wreszcie, dynamiczna wymiana opisów między usługami ułatwia autom a­ tyzowanie zarządzania wersjami usług i innym i funkcjami związanymi z metadanymi.

ANALIZA PRZYPADKU

Firma TLS kontynuuje rozwój swych systemów B2B — dodawane są nowe elementy funk­ cjonalne, modyfikowanych jest wiele istniejących. Oczywiście, nie odbywa się to bez wpływu na definicje WSDL usług oraz ich założenia polityki. I jest oczywiste, że zmiany te nie są nie­ zauważalne dla partnerów online, którzy regularnie łączą się z systemami TLS. W zw iązku z tym , w szystkie publiczne usługi TLS zapew niają przetw arzanie żądań WS-MetadataExchange, a partnerom TLS zarejestrowanym do współpracy z systemem B2B zaleca się częste wysyłanie żądań Get Metadata w celu jak najszybszego uwzględniania naj­ nowszych wersji kontraktów wspomnianych usług. O słuszności tego zalecenia przekonała się dotkliwie firma RailCo. Dotychczas nie uwzględ­ niała ona wymiany m etadanych w swoich usługach, bo nie było takiej potrzeby. Gdy zmody­ fikowana została definicja usługi TLS Płatność na konto, usługa Wystawienie faktury w RailCo otrzymała powiadomienie, że wysłany przez nią kom unikat zawierający fakturę został przez usługę Płatność na konto odrzucony. Zawarte we wspomnianym powiadomieniu wyjaśnienie przyczyny odrzucenia było mało czytelne, natom iast procedura obsługi wyjątków usługi Wystawienie faktury zidentyfiko­ wała tę przyczynę jako niedostępność usługi Płatność na konto. W systemach informatycznych zdarzają się różne dziwne sytuacje, które jednak ustępują równie szybko, jak się pojawiły; z taką nadzieją próba wysłania rzeczonego kom unikatu z fakturą ponawiana była wielokrotnie, nie­ stety, każdorazowo z takim samym skutkiem — mimo upływu trzech dni, ze strony TLS nie nadeszło oczekiwane potwierdzenie. Żm udna analiza przyczyn tego zjawiska ujawniła w końcu, że jego bezpośrednią przyczyną była zm iana definicji WSDL usługi-dostarczyciela w TLS. N auczeni przykrym doświadczeniem autorzy usługi W ystawienie faktury zm oderni­ zowali ją, wzbogacając o możliwość przetwarzania metadanych, między innymi oferowanych przez usługi TLS (patrz rysunek 7.26). Zgodnie z wcześniej wspomnianym zaleceniem, usługa ta periodycznie indagowała usługę Płatność na konto komunikatem-żądaniem Get Metadata; zwrotny komunikat-odpowiedź Get Metadata zawierał aktualne wersje definicji WSDL, sche­ m atu XSD i założeń polityki. Dawało to możliwość natychmiastowej weryfikacji, czy te naj­ nowsze wersje zgodne są z tymi, w których posiadaniu jest RailCo.

7 .6 . BEZPIECZEŃSTW O

229

Rysunek 7.26. Zmodernizowany proces wystawiania faktur w firmie RailCo obejmuje teraz periodyczną wymianę metadanych z TLS

Jeśli weryfikacja ta wypadała negatywnie — opis usługi Płatność na konto posiadany przez RailCo był nieaktualny — usługa Wystawienie faktury zaprzestawała generowania faktur i powiadam iała o tym fakcie adm inistratora za pom ocą specjalnego kom unikatu.

P O D S U M O W A N IE •

Proces w ym iany metadanych um ożliwia usługom -w nioskodaw com uzyskiwanie metadanych związanych z usługami-dostarczycielami.

•

Specyfikacja W S-M etadataExchange definiuje dw a standardow e typy kom unikatów . Komunikaty Get M etadata służą do uzyskiwania metainform acji w postaci kopii odnośnych dokum entów lub w postaci adresów tych dokum entów . Zadaniem kom unikatów G ctjest uzyskanie kopii dokumentu identyfikow anego jedynie przez adres w kom unikacie-odpowiedzi Get M etadata.

•

W ym iana metadanych w spom aga proces odnajdyw ania opisów usług i ułatwia autom atyzow anie kontroli wersji usług.

•

Zautom atyzow anie w yszukiw ania i pobierania metadanych prowadzi do kilku zestandaryzowanych usprawnień na gruncie SOA i uw ydatnia luźne pow iązanie między autonom icznym i usługami.

7 .6 . B e zp ie c ze ń s tw o Bezpieczeństwo rozwiązań automatyzujących biznes to w świecie IT nic nowego. Tak jak trady­ cyjne aplikacje wymagały zabezpieczeń pod kątem ochrony informacji i selektywnego do niej do­ stępu wyłącznie dla uprawnionych podm iotów, tak wymagają ich współczesne aplikacje zorien­ towane na usługi. Framework komunikacyjny SOAP, na fundam entach którego budow ana jest współczesna SOA, znacznie poszerza i zaostrza poszczególne aspekty wymagań bezpieczeństwa, stwarza tym samym zapotrzebowanie na czyniący im zadość framework zaprojektowany specjal­ nie pod kątem usług sieciowych.

230

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

T a k i f r a m e w o r k is tn ie je , o p ie r a s ię n a z b io r z e s p e c y fik a c ji w y w o d z ą c y c h s ię z e w s p ó ln e g o p r z o d k a — s p e c y fik a c ji W S -S e c u rity — i p o s z e r z o n y je s t p r z e z s e rię s p e c y fik a c ji u z u p e łn ia ją c y c h . W p o b lis k ie j b o c z n e j r a m c e z n a jd u je się a k tu a ln a lis ta r e fe r e n c y jn a te g o f r a m e w o r k u . Ja ko że n ie s p o s ó b w o g r a n ic z o n y c h r a m a c h te g o r o z d z ia łu o m ó w ić c h o ć p o k r ó t c e tr e ś ć ic h w s z y s tk ic h , s k o n c e n t r u je m y się n a p o d s ta w o w y c h fu n k c ja c h tr z e c h n a jw a ż n ie js z y c h , a m ia n o w ic ie : •

W S -S e c u rity ,

•

X M L - S ig n a tu r e ,

•

X M L - E n c r y p tio n .

P o n a d t o o m ó w i m y k r ó t k o f u n d a m e n t a ln e k o n c e p c je k r y ją c e się z a jednokrotnym logowa­ niem (s in g le s ig n -o n ) ja k o f o r m ą s c e n tr a liz o w a n e g o z a b e z p ie c z e n ia d o p e łn ia ją c e g o w y m ie n io n e r o z s z e r z e n ia .

•

WS-Secu rity

•

WS-Secu rityPolicy

•

WS-Tru s t

•

WS-Secu reCon versation

•

WS-Federation

•

Exten sib le A ccess Contro l M ark up Lang uag e (XACM L)

•

Exten sib l e Rig hts M ark up La ng uag e (XrM L)

•

XM L Key M anag em ent (XKM S)

•

XML-S ig nature

•

XM L-Encryption

•

Secu rity A ssertion M ark up La ng uag e (SA M L)

•

.NET Passp o r t

•

Secure Sockets Layer (SSL)

•

W S-i Basic Secu rity Profile Ramka 7.1. Lista specyfikacji bezpieczeństwa przydatnych na potrzeby SOA. Ich szczegółowe omówienie dostępne jest w sieci.

T e n f r a g m e n t r o z d z ia łu p o d z ie lo n y je s t n a p u n k t y , z g o d n ie z e s p o jr z e n ie m n a k o n c e p c ję b e z ­ p ie c z e ń s tw a z p e r s p e k ty w y p ię c iu n a jw a ż n ie js z y c h je j a s p e k tó w : id e n t y f ik a c ji, u w ie r z y t e ln ia n ia , a u to r y z a c ji, p o u fn o ś c i i in te g r a ln o ś c i.

UWAGA W rozdziale 17., w punkcie „Podstawy języka WS-Security", zamieszczamy ogólny przegląd języków WS-Security,

XML-Encryption i XML-Signature.

7 .6 . BEZPIECZEŃSTW O

231

PO PROSTU N iedaw no znaleźliśmy ofertę sprzedaży dobrze prosperującej myjni; Jim w yszedł dziś wcześniej z pracy, by spotkać się z właścicielem tej myjni i ostatecznie sfinalizować transakcję. Po drodze Jim musiał jeszcze odw iedzić swój bank, by podjąć gotów kę (sprzedawca myjni zażyczył sobie zapłatę gotów ką), a ja poprosiłem go, by przy okazji odebrał z pobliskiego urzędu pocztowego paczkę adre­ sowaną do mnie (wręczyłem mu aw izo, które znalazłem w skrzynce). W banku Jim wręczył kasjerowi praw idłow o wypełniony blankiet w ypłaty, zawierający jego imię i nazwisko, num er rachunku i żądaną kw otę. Kasjer porosił Jima o okazanie karty płatniczej oraz dow olnego dokumentu ze zdjęciem; Jim okazał rzeczoną kartę oraz praw o jazdy. Pozostało jeszcze tylko w prow adzenie tajnego kodu PIN i Jim trzym ał już w rękach upragnione banknoty. Na poczcie poszło Jimowi już trochę gorzej. Okazał w spom niane wcześniej aw izo i w ylegitym ow ał się praw em jazdy, potw ierdzając oczywiście, że paczka adresow ana jest nie do niego, lecz do kolegi. Urzędnik odm ów ił w ydania paczki, pow ołując się na przepisy, zgodnie z którymi przesyłkę w imieniu jej adresata m o­ że odebrać w yłącznie osoba nosząca to samo nazwisko, co adresat, lub w spólnie z tym adresatem zam iesz­ kująca. Jim nie spełniał żadnego z tych w arunków . Procedura, której uczestnikiem stał się Jim jako klient banku, to trzypoziom ow e potw ierdzenie upraw ­ nień: identyfikacja (blankiet w ypłaty z kw otą i nazwiskiem ), uw ierzytelnienie (karta płatnicza i dokum ent to ż­ samości ze zdjęciem) i autoryzacja (kod PIN). Ponieważ faza identyfikacji pozbaw iona jest jakichkolw iek ele­ m entów bezpieczeństwa (każdy może wpisać dow olne nazwisko), konieczne są dw ie następne fazy, w ramach których Jim czyni zadość w ym ogom bezpieczeństwa (i ostatecznie otrzymuje gotów kę). Na poczcie sprawy miały się cokolw iek inaczej: po identyfikacji (aw izo) i uwierzytelnieniu (praw o jazdy) Jim nie przeszedł pomyślnie trzeciego etapu — autoryzacji, bo nie spełniał formalnych w arunków , które upraw ­ niałyby go do odbierania przesyłek w moim imieniu.

7.6.1. Identyfikacja, uwierzytelnianie i autoryzacja U s łu g a - w n io s k o d a w c a , z a m ie r z a ją c a u z y s k a ć b e z p ie c z n y d o s tę p d o u s łu g i-d o s ta r c z y c ie la , m u s i n a jp ie r w o k a z a ć in f o r m a c ję n a t e m a t s w e g o p o c h o d z e n ia lu b s w e g o w ła ś c ic ie la ; n a z y w a się to

oświadczeniem ( c la im ) ( p a t r z r y s u n e k 7 .2 7 ). O ś w ia d c z e n ia r e p r e z e n to w a n e są p r z e z in f o r m a c ję id e n t y f ik a c y jn ą p r z e c h o w y w a n ą w n a g łó w k u S O A P . W z a w ie r a ją c y tę in f o r m a c ję o k r e ś la n y je s t ja k o

s p e c y fik a c ji W S - S e c u r ity b lo k n a g łó w k a

token ( to k e n ).

Rysunek 7.27. Identyfikacja jest oświadczeniem odnoszącym się do pochodzenia komunikatu

Uwierzytelnienie ( a u th e n tic a tio n ) to u d o w o d n ie n ie , ż e k o m u n ik a t d o c ie r a ją c y d o o d b io r c y fa k ty c z n ie p o c h o d z i o d n a d a w c y a r ty k u ło w a n e g o w o ś w ia d c z e n iu ( p a t r z r y s u n e k 7 .2 8 ) . I n n y m i s ło w y , u s łu g a m u s i d o s ta r c z y ć d o w ó d n a to , że a r t y k u ło w a n a w o ś w ia d c z e n iu to ż s a m o ś ć ( id e n tit y ) je s t a u te n ty c z n a .

232

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

Rysunek 7.28. Uwierzytelnienie to udowodnienie tożsamości P o p o m y ś ln y m u w ie r z y t e ln ie n iu n a d a w c y o d b io r c a m o ż e s p r a w d z ić , d o c z e g o u p r a w n i o n y je s t t e n n a d a w c a . N a z y w a s ię to a u t o r y z a c ją ( a u t h o r iz a t io n ) ( p a t r z r y s u n e k 7 .2 9 ) .

Rysunek 7.29. Autoryzacja to określenie obszaru obowiązywania uwierzytelnienia

7.6.2. Jednokrotne logowanie N a g r u n c ie S O A p r a w d z iw y m w y z w a n ie m p o d a d re s e m u w ie r z y t e ln ia n ia i a u to r y z a c ji je s t p r o p a ­ g o w a n ie u w ie r z y t e ln ie n ia i a u to r y z a c ji u s łu g i- w n io s k o d a w c y n a w ie le u s łu g , p o z a p o c z ą t k o w ą u s łu g ą -d o s ta r c z y c ie le m . P o n ie w a ż u s łu g i są z d e fin ic ji a u to n o m ic z n e i w z a je m n ie n ie z a le ż n e , k o ­ n ie c z n e je s t z a p e w n ie n ie d o d a tk o w e g o m e c h a n iz m u u tr z y m u ją c e g o k o n te k s t b e z p ie c z e ń s tw a u s ta ­ n o w io n y w w y n ik u u w ie r z y t e ln ie n ia w n io s k o d a w c y . B e z te g o m e c h a n iz m u u s łu g a -w n io s k o d a w c a m u s ia ła b y u w ie r z y te ln ia ć się p r z y k a ż d y m ż ą d a n iu . T a k w ła ś n ie p r e z e n tu je się k o n c e p c ja je d n o k r o t n e g o lo g o w a n ia (sin g le s ig n -o n ). G d y je s t z a im ­ p le m e n to w a n a , w y s ta rc z a ją c e staje się je d n o k r o tn e u w ie r z y te ln ie n ie u s łu g i-w n io s k o d a w c y , b o u t w o ­ r z o n y w je g o w y n ik u k o n te k s t b e z p ie c z e ń s tw a r o z c ią g a się n a w s z y s tk ie in n e u s łu g i-d o s ta r c z y c ie li, z k t ó r y c h w s p o m n ia n a u s łu g a -w n io s k o d a w c a m a p r a w o k o rz y s ta ć . W ś r ó d r o z s z e r z e ń im p le m e n t u ją c y c h k o n c e p c ję je d n o k r o t n e g o lo g o w a n ia w y m ie n ić n a le ż y p r z e d e w s z y s tk im : •

S A M L ( S e c u rity A s s e rtio n M a r k u p L a n g u a g e — ję z y k z n a c z n ik o w y a s e rc ji b e z p ie c z e ń s tw a ),

•

. N E T P a s s p o rt,

•

X A C M L (E x te n s ib le A ccess C o n tr o l M a r k u p L a n g u a g e — r o z s z e r z a ln y z n a c z n ik o w y ję z y k k o n t r o li d o s tę p u ).

Jako p r z y k ła d t e c h n o lo g ii je d n o k r o tn e g o lo g o w a n ia z g o d n e j ze s c e n tr a liz o w a n y m u w ie r z y t e l­ n ia n ie m i a u to r y z a c ją o m ó w i m y p o k r ó tc e n ie k t ó r e f u n d a m e n t a ln e k o n c e p c je k r y ją c e się w ję z y k u SAM L. S A M L im p le m e n t u je s y s te m je d n o k r o t n e g o lo g o w a n ia , w k t ó r y m p u n k t k o n t a k t u z u s łu g ą w n io s k o d a w c ą m o ż e fu n k c jo n o w a ć r ó w n ie ż ja k o o r g a n w y d a ją c y (is s u in g a u th o r it y ) . P o z w a la to n ie t y lk o n a u w ie r z y t e ln ie n ie i a u to r y z a c ję u s łu g i-w n io s k o d a w c y , le c z t a k ż e n a z a p e w n ie n ie p o z o ­ s ta ły c h u s łu g , ż e w s p o m n ia n a u s łu g a -w n io s k o d a w c a p r z e s z ła p o m y ś ln ie te e ta p y .

7 .6 . BEZPIECZEŃSTW O

233

In n e u s łu g i, z k t ó r y m i z a m ie r z a k o n t a k t o w a ć się w s p o m n ia n a u s łu g a -w n io s k o d a w c a , w c e lu z w e r y fik o w a n ia u p r a w n ie ń te jż e n ie m u s z ą ju ż w y m a g a ć o d n ie j u w ie r z y te ln ia n ia i a u to ry z a c ji, le c z m o g ą w t y m c e lu z w r ó c ić się d o rz e c z o n e g o o r g a n u w y d a ją c e g o , k t ó r y p o t w ie r d z i f a k t e w e n tu a l­ n e g o w y k o n a n i a t y c h c z y n n o ś c i. P o t w ie r d z e n ie t a k ie m a f o r m ę

asercji ( a s s e rtio n ) a r t y k u łu ją c e j

s z c z e g ó ły z a b e z p ie c z e n ia (d o k ła d n ie j — d w ó c h a s e rc ji, z w ią z a n y c h — o d p o w ie d n io — z u w ie r z y ­ te ln ia n ie m i a u to ry z a c ją ). N a r y s u n k u 7 .3 0 u w id o c z n io n o u p r o s z c z o n ą s tr u k tu r ę m e c h a n iz m ó w S A M L .

Rysunek 7.30. Podstawowa wymiana komunikatów, ilustrująca realizację jednokrotnego logowania w implementacji SAML

7.6.3. Poufnoś ć i integralno ś ć Poufność ( c o n f id e n tia lity ) z w ią z a n a je s t z z a c h o w a n ie m p r y w a tn o ś c i tre ś c i k o m u n ik a t u : k o m u ­ n ik a t m o ż e b y ć u w a ż a n y z a p o u fn y , je ś li ż ą d a n a u s łu g a lu b a g e n t n a je g o śc ie żc e n ie m a ją d o s tę p u d o je g o tre ś c i b e z w y m a g a n e j a u to r y z a c ji ( p a t r z r y s u n e k 7 .3 1 ) .

\ \

“

“

IFT7I

„Czy ktoś nieautoryzowany / w czytał treść tego / komunikatu po \ jego wysłaniu?" V

Odbiorca

j

Rysunek 7.31. Poufność komunikatu oznacza ochronę prywatności jego treści na całej jego ścieżce

Integralność ( in te g r it y ) to z k o le i p e w n o ś ć , że k o m u n ik a t p o w y s ła n iu n ie b y ł m o d y f ik o w a n y , ż e je g o tr e ś ć n ie z o s ta ła n a r u s z o n a a ż d o m o m e n t u d o s ta r c z e n ia g o d o m ie js c a p r z e z n a c z e n ia ( p a t r z r y s u n e k 7 .3 2 ).

234

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

Rysunek 7.32. Poufność komunikatu oznacza niezmienność jego treści na całej jego ścieżce

7.6.4. Bezpieczeństwo na poziomie transportu i na poziomie komunikatów Typ technologii wykorzystywanych do ochrony kom unikatu decyduje o rzeczywistym stopniu ochrony na całej ścieżce tego kom unikatu. Przykładowo SSL (S e c u re S o c k e c t L a y e r — warstwa bezpiecznych gniazd), najczęściej stosowany środek zabezpieczania kanałów kom unikacyjnych HTTP, w odniesieniu do usług sieciowych okazuje się skuteczny tylko częściowo, bo chroni kom unikat jedynie na odcinku między punktam i końcowymi usług (patrz rysunek 7.33). Stanowi zatem z a b e z p ie c z e n ie n a p o z io m ie t r a n s p o r t u ( tr a n s p o r t le v e l s e c u r ity ).

Rysunek 7.33. Zabezpieczenie na poziomie transportu chroni komunikat jedynie na odcinkach między punktami końcowymi usług

To, co dzieje się z kom unikatem po odebraniu go przez usługę pośredniczącą, pozostaje już poza kontrolą SSL. Pełną ochronę kom unikatu na całej jego ścieżce może zatem zapewnić tylko z a b e z p ie c z e n ie n a p o z io m ie k o m u n ik a t ó w (m e ssa g e -le ve l s e c u r ity — patrz rysunek 7.34), czyli zabezpieczenie, którego podmiotem jest sam komunikat, a nie tylko kanał jego transportu. Ochrona jest wówczas w pełni skuteczna, niezależnie od tego, jaką ścieżką rzeczony kom unikat wędruje.

7.6.5. Szyfrowanie i podpisy cyfrowe Zapewnienie poufności na poziomie komunikatów, w odniesieniu do form atu kom unikatów ba­ zującego na języku XML — na przykład form atu SOAP — można realizować w oparciu o specyfi­ kacje bezpieczeństwa, których listę zamieściliśmy w ramce na początku podrozdziału. W tym punkcie skupimy się na dwóch specyfikacjach tej rodziny — X M L - E n c r y p tio n i X M L - S ig n a tu r e — najważniejszych z perspektywy ochrony poufności i integralności komunikatów.

7 .6 . BEZPIECZEŃSTW O

235

\

\

Usługawnioskodawca

Usługadostarczyciel

Usługa pośrednicząca

L r

\

\

\

_|

\

\

\

Rysunek 7.34. Zabezpieczenie na poziomie komunikatów gwarantuje pełną ochronę na całej ścieżce (end-to-end) X M L - E n c r y p t io n to technologia szyfrowania zaprojektowana specjalnie dla form atu XML,

stanowiąca kam ień węgielny całego frameworku W S -S e c u rity . Szyfrowaniem może zostać objęty cały kom unikat bądź tylko jego część (na przykład hasło). Dla ochrony integralności kom unikatu potrzebna jest technologia zdolna do weryfikowania, czy odebrany kom unikat m a postać identyczną z tą, w której został wysłany po raz pierwszy. W e­ ryfikację taką przeprow adza się w oparciu o p o d p is c y f r o w y ( d ig it a l s ig n a tu r e ) — specyfikacja X M L - S ig n a tu r e umożliwia związanie z dokum entem XML pewnej informacji będącej algoryt­ miczną funkcją treści tego dokum entu, reprezentującej taki podpis. Po odebraniu kom unikatu inform acja ta jest ponow nie „obliczana” dla jego treści, a wynik tego obliczenia porównywany jest z oryginalnym podpisem, utworzonym w momencie wysyłania kom unikatu i dołączonym do niego. Rozbieżność tych dwóch wyników jest dowodem na ingerencję w treść kom unikatu3.

UWAGA Przy użyciu podpisów cyfrowych realizuje się również koncepcję niezaprzeczalności (non-repudiation), czyli zapobieżenia sytuacji, gdy nadawca komunikatu zaprzeczy wysłaniu tegoż komunikatu. Na podobnej zasa­ dzie sygnatariusz podpisujący elektronicznie określony dokument nie ma możliwości zakwestionowania (wy­ parcia się) autentyczności złożonego podpisu.

Jak pokazano na rysunku 7.35, szyfrowanie w wersji X M L - E n c r y p tio n można zastosować do całości kom unikatu SOAP bądź tylko do fragm entów jego nagłówka. Z kolei podpis cyfrowy kom unikatu (w wydaniu X M L - S ig n a tu r e ) m ożna umieścić w nagłówku SOAP jako jeden z jego bloków.

3 Czytelnikom zainteresowanym szczegółami szyfrowania i podpisów cyfrowych oraz ich zastosowaniem do za­ bezpieczania informacji chciałbym polecić dw utom ow ą monografię W. Stallingsa Kryptografia i bezpieczeństwo sieci komputerowych, wyd. polskie Helion, 2012 — przyp. tłum.

236

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

Rysunek 7.35. Podpisany cyfrowo komunikat SOAP zawierający szyfrowane fragmenty

UWAGA Szyfrow anie i deszyfrow anie treści oraz generow anie i w eryfiko w an ie jej podpisu cyfrowego to d w ie pary procesów algorytm icznych param etryzow anych kluczam i. Klucze te m ogą być w ykorzystyw ane w dw ojaki sposób. W w ariancie w spółdzielonym obie strony — szyfrująca i deszyfrująca — posługują się tym samym kluczem, w w ariancie kom plem entarnym mamy do czynienia z parą powiązanych kluczy, z których jeden („publiczny") jest ogólnie znany, drugi („pryw atny") znany jest tylko sw em u w łaścicielow i i utrzym yw any przez niego w tajemnicy. W szyfrowaniu w ykorzystyw ane są oba te w arianty; generow anie podpisu cyfro­ w ego odbyw a się natom iast przy użyciu klucza pryw atnego, a do w eryfikow ania autentyczności tego podpi­ su w ykorzystyw any jest pow iązany klucz publiczny.

7.6.6. Bezpieczeństwo a SOA B e zp ieczeń stw o n a p o z io m ie k o m u n ik a tó w jest w sposób o czyw isty k lu c z o w y m s k ła d n ik ie m r o z ­ w ią z a ń z o rie n to w a n y c h n a usługi. Zas to s o w a n e ś ro d k i b e zp ie c ze ń s tw a m o g ą c h ro n ić z a ró w n o k o ­ m u n ik a t, ja k i jeg o adresata. F r a m e w o r k W S -S e c u rity i spe c y fik a c je z n im s to w a rz y s z o n e w p is u ją się z a te m w fu n d a m e n ta ln e d la S O A w y m a g a n ia d o ty c zą ce ja k o ś c i u s łu g , u m o ż liw ia ją c p rz e d s ię ­ b io rs tw o m : •

w y k o rz y s ty w a n ie ro z w ią z a ń z o rie n to w a n y c h n a u s łu g i o d p rz e tw a rz a n ia „ w r a ż liw y c h ” d a n y c h o k ry ty c z n y m z n a c z e n iu ,

•

s e le k ty w n e o g ra n ic z a n ie d o s tę p u do p o s z c z e g ó ln y c h usług.

7 .6 . BEZPIECZEŃSTW O

237

Jak w id a ć n a ry s u n k u 7 .3 6 , fr a m e w o r k d e fin io w a n y p rz e z W S -S e c u rity u ła tw ia p ro je k ta n to m w y k o rz y s ty w a n ie fr a m e w o r k u W S - P o lic y o m a w ia n e g o w c z e ś n ie j w ty m r o z d z ia le (s p e c y fik a c ja W S -S e c u rity P o lic y d o s ta rc z a serię g o to w y c h , u ż y te c z n y c h asercji p o lity k i).

Rysunek 7.36. Związek zabezpieczeń z założeniami polityki, komunikatami SOAP i usługami sieciowymi

ANALIZA PRZYPADKU W T L S w p ro w a d z o n o z a ło ż e n ia p o lity k i b e z p ie c z e ń s tw a , za k ła d a ją c e o c h ro n ę , n a p o z io m ie k o m u n ik a tó w , każd eg o b izn eso w eg o d o k u m e n tu o d b ie ra n e g o p rz e z system B 2B. A k o n k re tn ie : •

k a ż d a k w o ta p ie n ię ż n a z a w a rta w d o k u m e n c ie m u s i b y ć s z y fro w a n a ,

•

k a ż d y k o m u n ik a t z a w ie ra ją c y fa k tu rę o p ie w a ją c ą n a k w o tę p rz e k ra c z a ją c ą 3 0 0 0 0 d o la ró w m u s i b y ć p o d p is a n y c y fro w o .

W celu d o s to s o w a n ia się d o ty c h n o w y c h w a r u n k ó w R a ilC o z m u s z o n a zo s ta ła do w z b o ­ g a c e n ia sw ej u s łu g i W y s ta w ie n ie f a k t u r y o s z y fro w a n ie (z g o d n ie z X M L - E n c r y p tio n ) k a żd e j k w o ty p ie n ię ż n e j z a w a rte j w w y s y ła n y c h k o m u n ik a ta c h . K o le jn a m o d y fik a c ja w s p o m n ia n e j u s łu g i p o le g a ła n a d o d a n iu lo g ik i k o n tro lu ją c e j k w o tę fa k tu r y i d o d a ją c e j do k o m u n ik a tu p o d p is c y fro w y (z g o d n y z X M L - S ig n a tu r e ) w s y tu a c ji, g d y k w o ta ta p rz e k ra c z a 3 0 0 0 0 d o la ró w .

PODSUMOW ANIE •

Bezpieczeństwo na gruncie SOA to problem o wielu aspektach, będący przedmiotem wielu specyfikacji. Część z nich składa się na framework W S S curyustanaw iający spójną i komponowalną architekturę bezpieczeństwa.

•

Podstaw ow ym i aspektami bezpieczeństwa w ujęciu wspom nianych specyfikacji są: identyfikacja, uw ierzytelnianie, autoryzacja, integralność i poufność, a także niezaprzeczalność.

•

D w ie podstaw ow e technologie zapew niające ochronę poufności i integralności dokum entu XM L są przedm iotem specyfikacji X M L-E ncryption i X M L-S ignature.

238

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

7 .7 . P o w ia d a m ia n ie i z d a rz e n io w a n ie T k w ią c y s w y m i k o r z e n ia m i w epoce o p ro g ra m o w a n ia m id d le w a re z o rie n to w a n e g o n a w y m ia n ę k o m u n ik a tó w , w z o rz e c M E P „ p u b lik u j-s u b s k ry b u j”, z ło ż o n y z d w ó c h p r y m ity w n y c h M E P , im ­ p le m e n tu je m o d e l „ w y p y c h a n e g o ” (p u s h ) d o s ta rc z a n ia in fo rm a c ji. U s ta n a w ia o n u n ik a to w ą re la ­ cję m ię d z y u s łu g ą -w n io s k o d a w c ą a u s łu g ą -d o s ta rc z y c ie le m , m ię d z y k tó r y m i w y m ia n a in fo r m a c ji s ta n o w i o d m ia n ę d y n a m ic z n e g o p o w ia d a m ia n ia ( n o tif ic a t io n ) , ta k ja k n a ry s u n k u 7 .3 7 .

Rysunek 7.37. Po dokonaniu subskrypcji przez usługę A usługa B będzie ją powiadamiać o wszystkim ze swej strony, co może ją zainteresować

C h o ć p o w ia d a m ia n ie ja k o ta k ie m o ż e b y ć re a liz o w a n e w z w ią z k u z r ó ż n y m i w z o rc a m i M E P , w ty m p u n k c ie s k u p im y się n a je g o re a liz a c ji p r z y u ż y c iu w z o rc a „ p u b lik u j-s u b s k ry b u j”.

7.7.1. Model „publikuj-subskrybuj" jako abstrakcja T y tu ło w y w z o rz e c m o ż e b y ć k w a lifik o w a n y ja k z ło ż o n y M E P , u tw o r z o n y p rz e z serię p r y m ity w ­ n y c h M E P (co w y ja ś n ia liś m y w ro z d z ia le 6 .). W ra m a c h tego w z o rc a w y r ó ż n ia m y u s łu g ę -w y d a w c ę (p u b lis h e r ) u d o s tę p n ia ją c ą in fo rm a c ję , p o s e g re g o w a n ą ze w z g lę d u n a t e m a t y ( to p ic s ), z a re je s tro ­ w a n y m u s łu g o m -s u b s k r y b e n to m (s u b s c rib e rs ). U s łu g i-s u b s k ry b e n c i re je s tru ją się w k o n te k ś c ie o k re ś lo n e g o te m a tu (lu b g r u p y te m a tó w ) i c z y n ią to b ą d ź w d r o d z e b e z p o ś r e d n ie j in te r a k c ji z u s łu g ą -w y d a w c ą , b ą d ź za p o ś re d n ic tw e m o d d z ie ln e j u s łu g i-b r o k e r a ( b ro k e r). O k re ś lo n y „ te m a t” m o ż e b y ć ro z m a ic ie r o z u m ia n y , n a jczęściej je d n a k je s t re p re z e n to w a n y p rz e z w y s tę p o w a n ie o k re ­ ś lo n y c h z d a rze ń . G d y p o ja w ia się n o w a p o rc ja in fo r m a c ji z w ią z a n a z d a n y m te m a te m (n a p r z y k ła d w s k u te k w y s tą p ie n ia je d n e g o ze w s p o m n ia n y c h z d a rz e ń ), u s łu g a -w y d a w c a ro zg łasza tę in fo rm a c ję p o m ię d z y te u s łu g i-s u b s k ry b e n tó w , k tó re z a re je s tro w a ły się w d a n e j k a te g o rii te m a ty c z n e j. R o zg ła s z a n ie to re a liz o w a n e jest ja k o w y s y łan ie k o m u n ik a tó w b ą d ź to b e zp o ś re d n io do s u b s k ry b e n tó w , b ą d ź też za p o śred n ictw em w sp o m n ian eg o b ro k e ra , działającego w im ie n iu w ydaw cy. O pisane procesy — rejestra­ cja i rozgłaszanie — są je d y n y m i c z y n n ik a m i w ią żą c y m i usługę-w ydaw cę z usłu g am i-su b skryb en tam i, p o z a ty m d z ia ła ją o n e n ie z a le ż n ie . W y s tę p o w a n ie u s łu g i-b ro k e ra d o d a tk o w o z w ię k s z a tę n ie z a ­ leżn o ść, b o w y d a w c a p o zo s ta je n ie w id o c z n y d la s u b s k ry b e n tó w i v ic e versa.

7 .7 . P O W IA D A M IA N IE I Z D A R Z E N IO W A N IE

239

PO PROSTU Nasza myjnia, podobnie ja k współpracująca z nami m yjnia-partner, jest członkiem św iatow ego konsorcjum W orld-W ide C ar W ashing C onsortium , działającego z intencją rozwoju trudnej sztuki przywracania w łaściw ej kondycji higienicznej karoseriom sam ochodowym . Konsorcjum to publikuje w odstępach tygodniow ych biu­ letyny o różnorodnej tem atyce z tej gałęzi w iedzy, zainteresow ani członkowie mogą prenum erow ać (sub­ skrybować) te, których treścią są najbardziej zainteresow ani. Nasz partner jest zainteresow any wszelkim i now inkam i w naszej profesji, my ograniczam y swe zaintere­ sowania do postępu w badaniach nad now ym i środkami czyszczącymi oraz do nowych odkryć w zakresie m odelow ania jak najefektywniejszego operow ania gąbką nasączoną mydlinam i. Nasz partner jest w ięc co tydzień dosłow nie zarzucany stertą makulatury, my zaś znajdujem y w naszej skrzynce zaledw ie kilka ulotek — i to tylko w tedy, gdy w ydarzy się coś godnego uw agi w jednej z w ym ienionych dyscyplin wiedzy. Konsorcjum W 3CC pełni w ięc rolę w ydaw cy; my adresaci biuletynów , jesteśmy subskrybentami.

7.7.2. Jedna koncepcja, dwie specyfikacje W śród rozszerzeń WS-* definiujących implem entację wzorca „publikuj-subskrybuj” występują przede wszystkim dwa następujące: • framework W S - N o tific a tio n autorstwa IBM, • specyfikacja W S - E v e n tin g autorstwa Microsoftu. Prezentują one odm ienne podejście i odm ienną term inologię jako konkurencyjne ujęcia zasadniczo tej samej koncepcji. Być może doczekamy się w przyszłości pojedynczej specyfikacji o statusie standardu przemysłowego, tymczasem w kolejnych punktach przyjrzymy się pokrótce obu wymienionym.

7.7.3. Framework WS-Notification Podobnie jak każdy framework kategorii WS-*, tak i W S - N o tific a tio n stanowi rodzinę powiąza­ nych i opracowywanych łącznie następujących rozszerzeń: • W S - B a s e N o tific a tio n , ustanawiającego zestandaryzowane interfejsy do wykorzystania przez usługi angażowane po którejkolwiek stronie wymiany powiadomień, • W S -T o p ic s , określającego zasady strukturalizacji i kategoryzacji tematów, • W S - B r o k e r e d N o tific a tio n , definiującego funkcjonowanie brokera jako pośrednika odbierającego i wysyłającego kom unikaty w im ieniu (odpowiednio) subskrybentów i wydawcy. S y tu a c je , k o m u n ik a t y p o w ia d a m ia ją c e i t e m a t y

Proces powiadam iania jest zwykle powiązany z występowaniem zdarzeń raportowanych przez wydawcę. Każde takie zdarzenie określane jest jako s y tu a c ja (s itu a tio n ). Sytuacja może spowodować wygenerowanie jednego lub kilku k o m u n ik a tó w p o w ia d a m ia ją c y c h (n o tific a tio n messages ), z któ­ rych każdy zawiera informację (bezpośrednią lub pośrednią) o przyczynowej sytuacji. Komunikaty te kategoryzowane są zgodnie ze zdefiniowanym zbiorem t e m a t ó w ( to p ic s ) — wysyłane są tylko do tych usług, które uprzednio subskrybowały określone tematy.

240

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

P r o d u c e n c i p o w ia d o m ie ń i p u b lik a t o r y

Tradycyjny podział ról na wydawcę i subskrybenta, zgodnie z abstrakcyjnym rozumieniem wzorca, na gruncie frameworku W S - N o tific a tio n staje się bardziej szczegółowy. Mianem p u b lik a t o r a (p u b lis h e r ) określa się tę część aplikacji, która reaguje na zachodzące zdarzenia i odpowiedzialna jest za generowanie związanych z tym zdarzeniem komunikatów. Publikator niekoniecznie jednak musi zajmować się dystrybucją tych komunikatów, bo ta należy do obowiązków p r o d u c e n ta p o w ia d o m ie ń ( n o tific a tio n p r o d u c e r ). Producent powiadomień zaj­ muje się zarządzaniem subskrypcjami i kontaktuje się bezpośrednio z subskrybentami, rozsyłając do nich komunikaty, zgodnie z ich podziałem tematycznym. Zauważmy, że: • publikator może, lecz nie musi, być usługą sieciową, podczas gdy producent powiadomień jest nią zawsze, • pojedyncza usługa sieciowa może pełnić obie role — publikatora i producenta powiadomień, • producent powiadomień może być uważany za usługę-dostarczyciela. K o n s u m e n c i p o w ia d o m ie ń i s u b s k ry b e n c i S u b s k r y b e n t (s u b s c rib e r ) to ta część aplikacji, która wysyła żądania subskrypcji do producenta powiadomień. Subskrybent niekoniecznie jednak musi być odbiorcą kom unikatów wysyłanych przez tego producenta, bo to zadanie kojarzone jest z rolą k o n s u m e n ta p o w ia d o m ie ń ( n o tific a tio n c o n s u m e r ), tak jak na rysunku 7.38. Ponownie zauważmy, że:

• subskrybent może, lecz nie musi, być usługą sieciową, podczas gdy konsument powiadomień jest nią zawsze, • pojedyncza usługa sieciowa może pełnić obie role — subskrybenta i konsumenta powiadomień, • subskrybent może być uważany za usługę-wnioskodawcę.

Rysunek 7.38. Zarys architektury powiadomień według WS-Notification

7 .7 . P O W IA D A M IA N IE I Z D A R Z E N IO W A N IE

241

B r o k e r p o w ia d a m ia n ia , m e n e d ż e r r e je s tr a c ji p u b lik a t o r a i m e n e d ż e r s u b s k ry p c ji

Aby uwolnić dwie opisane grupy usług od konieczności bezpośredniego współdziałania, we frameworku W S - N o tific a tio n zdefiniowano kilka usług pomocniczych (patrz rysunek 7.39). Oto one. •

B r o k e r p o w ia d a m ia n ia ( n o tific a tio n b r o k e r ) — usługa sieciowa działająca w imieniu publikatora i pełniąca rolę producenta powiadomień. Izoluje publikator od jakichkolwiek kontaktów z subskrybentami. Zauważmy, że w czasie odbierania kom unikatów od publikatora broker pełni tymczasowo rolę konsum enta powiadomień.

•

M e n e d ż e r r e je s tr a c ji p u b lik a t o r a (p u b lis h e r r e g is tr a tio n m a n a g e r ) — usługa sieciowa

dostarczająca interfejs dla potencjalnych subskrybentów, umożliwiająca im wyszukiwanie i lokalizowanie tem atów stanowiących podstawę rejestracji. Rolę tę może na siebie przyjmować broker powiadamiania, może być ona również implementowana w postaci oddzielnej usługi, tworzącej tym samym kolejną warstwę abstrakcji. •

M e n e d ż e r s u b s k r y p c ji (s u b s c rip tio n m a n a g e r ) — usługa sieciowa umożliwiająca

producentom powiadom ień dostęp do informacji przeznaczonej do wysyłania w ramach kom unikatów powiadamiających. Rolę tę może pełnić bądź to producent powiadomień, bądź też dedykowana usługa.

Rysunek 7.39. Architektura powiadamiania według WS-Notification, z warstwą pośredniczącą

242

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

7.7.4. Specyfikacja WS-Eventing Jak słusznie m ożna się domyślać z nazwy tytułowej specyfikacji, ujmuje ona model „publikujsubskrybuj” w ram y m odelu komunikacji zorientowanego zdarzeniowo ( e v e n t-o rie n te d ). Gdy wy­ stąpi zdarzenie powiązane z daną usługą sieciową, wszystkie inne usługi zainteresowane tym wy­ stąpieniem zostaną o nim powiadomione. Poniżej prezentujemy w skrócie koncepcję i term ino­ logię definiowaną przez specyfikację W S -E v e n tin g . Ź r ó d ła z d a r z e ń

W specyfikacji W S - E v e n tin g nie znajdujem y już term inu p u b lis h e r . Analogiczną rolę spełnia tu usługa sieciowa o szerszej funkcjonalności, zwana ź r ó d łe m z d a r z e ń (e v e n t s o u rc e ). Jako część ar­ chitektury zdarzeniowej odpowiedzialna jest ona zarówno za przyjmowanie żądań subskrypcji, jak i za wysyłanie odpowiednich kom unikatów powiadamiających o zaistniałych zdarzeniach. U jś c ia d a n y c h i s u b s k ry b e n c i

Po stronie subskrypcji wspomnianego m odelu zdarzeniowego m am y do czynienia z dwoma ro ­ dzajami usług. U jś c ie z d a r z e ń ( e v e n t s in k ) to usługa zaprojektowana jako odbiorca (konsument) kom unikatów powiadamiających wysyłanych przez źródło zdarzeń, natom iast s u b s k r y b e n c i (s u b s c rib e rs ) to usługi zdolne do formułowania różnych typów żądań subskrypcji. M e n e d ż e r y s u b s k ry p c ji

W dużych instalacjach sprawowanie obu funkcji — zarządzanie subskrypcjami i wysyłanie p o ­ wiadomień — mogłoby stanowić dla źródła zdarzeń nadm ierne obciążenie. Przewidziano zatem opcjonalną możliwość istnienia usług pośredniczących, zwanych m e n e d ż e r a m i s u b s k ry p c ji (s u b ­ s c r ip tio n m a n a g e rs ), solidarnie wyręczających źródło zdarzeń w dialogu z subskrybentami. K o m u n ik a t y p o w ia d a m ia ją c e i k o m u n ik a t y z a k o ń c z e n ia s u b s k ry p c ji

Wystąpienie określonego zdarzenia raportowane jest poprzez wysłanie k o m u n ik a t u p o w ia d a ­ m ia ją c e g o (s u b s c rip tio n m a n a g e rs ), zwanego także k o m u n ik a te m z d a r z e n io w y m (e v e n t m essage ). Jest to standardowy kom unikat SOAP zawierający szczegóły informacji o zdarzeniu w bloku n a­ główkowym dedykowanym specyfikacji W S -E v e n tin g . Specyfikacja W S - E v e n tin g umożliwia ustanawianie subskrypcji na czas określony. Subskrypcja nieodnowiona przed upływem swego czasu ważności wygasa, co kwitowane jest przez źródło zda­ rzeń wysłaniem odpowiedniego kom unikatu do ujścia zdarzeń; kom unikat ten nazywany jest k o m u n ik a t e m z a k o ń c z e n ia s u b s k ry p c ji (s u b s c rip tio n e n d m essage ). K o m u n ik a t y s u b s k ry p c ji i f i l t r y s u b s k ry p c ji

Jak przed chwilą wyjaśniliśmy, s u b s k ry b e n c i mogą wysyłać swe żądania subskrypcji bezpośrednio do źródła zdarzeń albo do jednego z pośredniczących m enedżerów subskrypcji. Mogą to być żądania różnego typu — W S - E v e n tin g definiuje następujące typy żądań subskrypcji. •

S u b s c rib e („subskrybuj”) — żądanie ustanowienia nowej subskrypcji, określające między innym i punkt końcowy, do którego wysłany m a zostać kom unikat oznajmiający zakończenie subskrypcji. Opcjonalnie żądanie to może także specyfikować szczegóły filtrowania zdarzeń (o tym za chwilę).

7 .7 . P O W IA D A M IA N IE I Z D A R Z E N IO W A N IE

•

U n s u b s c rib e („anuluj subskrypcję”) — żądanie zakończenia trwającej subskrypcji.

•

R e n e w („odnów”) — żądanie odnowienia subskrypcji ustanowionej uprzednio na czas

243

określony. •

G e tS ta tu s („pokaż status”) — żądanie udostępnienia statusu określonej subskrypcji.

Subskrybent dla zakomunikowania źródłu zdarzeń swego zainteresowania jedynie wybranymi typami zdarzeń może zawrzeć w żądaniu S u b s c rib e stosowny filtr (s u b s c rip tio n f i l t e r ). Jeśli źródło zdarzeń nie zaakceptuje tego filtru (lub w ogóle nie posiada zdolności filtrowania), żądanie subskrypcji zostaje przezeń odrzucone. Na rysunku 7.40 przedstawiono symboliczne powiązania między źródłem zdarzeń, menedże­ ram i subskrypcji, subskrybentami i ujściem zdarzeń.

Rysunek 7.40. Podstawowa struktura architektury zdarzeniowej według WS-Eventing

7.7.5. WS-Notification a WS-Eventing To, że dwie tytułowe specyfikacje pokrywają się w dużym stopniu pod względem opisywanych kon­ cepcji i rozwiązań nie oznacza, że ten stan będzie trwał wiecznie. Spekulatywne dociekania upatrują jego przyczyny w rozbieżności indywidualnych oczekiwań sponsorów: jednym z podstawowych celów IBM było zintegrowanie W S -N o tific a tio n z inicjatywą obliczeń siatkowych (g r id c o m p u tin g ), podczas gdy Microsoft dążył do wykorzystania swego W S -E v e n tin g z platformami administrowania systemami. Na fali wysiłków zm ierzających do zapewnienia współdziałania różnych „własnościowych” platform firm a IBM dołączyła niedawno do grem ium rozwijającego specyfikację W S - E v e n tin g . I prawdę mówiąc, m ożna zgadywać, czy któraś z dwóch specyfikacji podąży w stronę zgodności z drugą, czy może IBM i Microsoft porozumieją się w kwestii wypracowania wspólnej specyfikacji poświęconej powiadamianiu. Nie będziemy więc w tej książce zajmować się językami W S -N o tific a tio n ani W S -E v e n tin g , zainteresowanych ich szczegółami czytelników odsyłamy do sieci.

244

R O ZD ZIA Ł 7 . ■ USŁUGI S IE C IO W E I W SPÓ ŁC ZESN A SO A (CZĘŚĆ II. Z A A W A N S O W A N E K O M U N IK O W A N IE )

7.7.6. Powiadamianie i zdarzeniowanie a SOA D z ię k i im p le m e n ta c ji m o d e lu o d z w ie rc ie d la ją c e g o tr a d y c y jn y m e c h a n iz m „ p u b lik u j-s u b s k ry b u j” , w a rto ś c io w e cec h y „ s p a d k o w y c h ” a p lik a c ji m o g ą b y ć te ra z w p e łn i re a liz o w a n e w ś ro d o w is k a c h a p lik a c ji z o r ie n to w a n y c h n a u s łu g i (p a tr z ry s u n e k 7 .4 1 ). C o w ię c e j, w p la ta n ie w y r a fin o w a n y c h s y s te m ó w p o w ia d a m ia n ia w tw o r z o n e r o z w ią z a n ia z o r ie n to w a n e n a u s łu g i p r z y c z y n ia się z n a ­ cząco do w z b o g a c a n ia ic h m o d e lu k o m u n ik a c y jn e g o (c ze g o p r z y k ła d e m m o g ą b y ć w s p o m n ia n e w c ze ś n ie j o b lic z e n ia s ia tk o w e ).

Rysunek 7.41. Powiadamianie i zdarzeniowanie ustanawiają zestandaryzowane modele „publikuj-subskrybuj" wewnątrz SOA

M e c h a n iz m y p o w ia d a m ia n ia , re a liz u ją c e ro z m a ite o d m ia n y ra p o r to w a n ia z d a rz e ń , p rz y c z y ­ n ia ją się do p o le p s z a n ia ja k o ś c i u s łu g w r o z w ią z a n ia c h z o r ie n to w a n y c h n a u s łu g i. P r z y k ła d o w o z d a rz e n ia z w ią z a n e z z a r z ą d z a n ie m w y d a jn o ś c ią i o b s łu g ą w y ją tk ó w m o g ą w y z w a la ć ro z g ła s z a n ie p o w ia d o m ie ń in fo rm u ją c y c h u s łu g i-w n io s k o d a w c ó w o z a is tn ie n iu s p e c y fic z n y c h w a ru n k ó w .

ANALIZA PRZYPADKU W o d p o w ie d z i n a serię s k a rg o d d o s ta w c ó w , k tó r z y d o ś w ia d c z y li p ro b le m ó w ze w s p ó łp ra c ą o n lin e z p o w o d u z m ia n w o p is a c h u s łu g , f ir m a T L S p o s ta n o w iła u z u p e łn ić w y m ia n ę m e ta d a n y c h o sys tem p o w ia d o m ie ń : p a r tn e r z y T L S b ę d ą o d tą d p o w ia d a m ia n i z w y p rz e d z e n ie m o z m ia n a c h , k tó re m o g ą m ie ć w p ły w n a w s p ó łp ra c ę z ic h s y s te m a m i. S ystem B 2B f ir m y T L S s k ła d a się z w ie lu usług. K a ż d a re a liz u je sp e c y fic zn e fu n k c je , a n g a ­ ż u ją c e je d n e g o lu b w ię c e j p a rtn e ró w . K a ż d y p a r tn e r je s t w ię c z a in te re s o w a n y je d y n ie w y b r a ­ n y m i z m ia n a m i w u s łu g a c h T L S , z a te m o p is y w a n y system p o w ia d o m ie ń d z ia ła n a zasadzie s u b s k ry p c ji — k a ż d y p a r tn e r s u b s k ry b u je p o w ia d a m ia n ie o z m ia n a c h , k tó r e fa k ty c z n ie go d o ty c z ą . P o s tro n ie T L S s p e c ja ln a us łu g a P o w ia d a m ia n ie s y s te m o w e p e łn i ro lę w y d a w c y ( p u b li­ k a to ra ) k o m u n ik a tó w p o w ia d a m ia ją c y c h , a po s zc zeg ó ln i p a rtn e rz y z o b lig o w a n i zo s ta li do z a ­ im p le m e n to w a n ia p o sw ojej s tro n ie s to s o w n y c h u s łu g -s u b s k ry b e n tó w . O trz y m a n ie p rz e z ta k ą u s łu g ę -s u b s k ry b e n ta k o m u n ik a tu p o w ia d a m ia ją c e g o p o w o d u je a u to m a ty c z n e z a in ic jo w a n ie w y m ia n y m e ta d a n y c h , z g o d n ie ze specyfikacją W S -M e ta d a ta E x c h a n g e , z p u n k te m k o ń c o w y m o d p o w ie d n ie j u s łu g i w T L S .

7 .7 . P O W IA D A M IA N IE I Z D A R Z E N IO W A N IE

245

W firmie RailCo usługa-subskrybent nazwana została S u b s k ry p c ja T L S , co w przyszłości może prowadzić do nieporozum ień; tak czy inaczej, usługa ta subskrybuje powiadom ienia dotyczące zmian w dwóch usługach TLS, z którymi regularnie współpracuje — P ła tn o ś ć n a k o n t o i Z le c e n ie z a k u p u . Opisany stan rzeczy zilustrowano na rysunku 7.42.

Subskrypcja powiadomień o następującej tematyce: •zmiany w metadanych usługi TLS Płatność na konto •zmiany w metadanych usługi TLS Zlecenie zakupu

Rysunek 7.42. Nowa usługa-subskrybent w RailCo zapewnia otrzymywanie powiadomień od systemowej usługi powiadamiającej z TLS

PODSUMOW ANIE •

Fram ew ork WS-Notificationi specyfikacja modelu „publikuj-subskrybuj".

WS-Eventingum ożliw iają im plem entow anie tradycyjnego

•

Na fram ew ork WS-Notification składają się specyfikacje WS-BaseNotification, WS-Topics i WS-BrokeredNotification, w spólnie ustanaw iające system subskrypcji i pow iadam iania.

•

Specyfikacja WS-Eventingdefiniuje podobną funkcjonalność, lecz opartą na nieco odm iennej architekturze.

•

Pow iadam ianie i zdarzeniow anie realizują na gruncie SOA popularny model komunikacyjny „publikuj-subskrybuj". Zaaw ansow ane środowisko kom unikatów dostarczane przez SOA stwarza sprzyjające w arunki do spożytkowania tego modelu.

246

ROZDZIAŁ 7. ■ USŁUGI SIECIOWE I WSPÓŁCZESNA SOA (CZĘŚĆ II. ZAAWANSOWANE KOMUNIKOWANIE)

Część III

SOA i zorientowanie na usługi Rozdział 8. Zasady orientacji na usługi Rozdział 9. W arstwy usług

Dotąd skupialiśmy uwagę na SOA jako całości — jej fundam entalnych koncepcjach oraz licznych rozszerzeniach. Tę część książki poświęcamy paradygmatowi odpowiedzialnemu w pierwszym rzędzie za definicję SOA i wyróżniającemu SOA wśród modeli architektonicznych. Dwa następne rozdziały poświęcone są zasadom i koncepcjom składającym się na spektrum zorientowania na usługi. Ich treścią jest teoria (w niezbędnym zakresie) dotycząca podstawowych kom ponentów pierwotnej SOA, lecz także i koncepcje, które mogą być wdrażane i spożytkowywane w środowiskach zorientowanych na usługi. Tematyka ta stwarza podstawy dla modelowania i projektowania usług, czym zajmiemy się w następnej części książki, zatytułowanej „Budowanie SOA”.

Zasady orientacji na usługi 8.1. Orientacja na usługi z perspektywy przedsiębiorstwa 8.2. Anatomia architektury zorientowanej na usługi 8.3. Podstawowe zasady zorientowania na usługi 8.4. Jak powiązane są zasady zorientowania na usługi? 8.5. Orientacja na usługi oraz orientacja na obiekty (część II) 8.6. Natywne wsparcie dla zasad zorientowania na usługi ze strony usług sieciowych

250

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

Przed przystąpieniem do budowania rozwiązania zorientowanego na usługi konieczne jest zro­ zumienie, co sprawia, że konkretna usługa jest zgodna z wymaganiami SOA, czyli — w przełożeniu na praktyczne działania — jak projektować usługi sieciowe, by były prawdziwie zgodne z zasada­ m i orientacji na usługi. Odpowiedzią na to pytanie jest właściwe podejście do modelowania logiki automatyzacji pro­ cesów, dające w efekcie zbiór powszechnie akceptowanych zasad, które m ożna zastosować do każdej jednostki logiki składającej się na usługę w ramach SOA. Właściwe odzwierciedlenie tych zasad w pierwotnych kom ponentach SOA (usługach, ich opisach i kom unikatach) jest tym, co decyduje o orientacji na usługi. Rozpoczniemy ten rozdział od omówienia ogólnego związku orientacji na usługi jako całości z logiką przedsiębiorstwa, po czym zajmiemy się dokładniej poszczególnymi cechami tej orientacji.

PO PROSTU Zrozumienie zasad orientacji na usługi jest bodaj naw et ważniejsze niż koncepcje om aw iane w dotychczaso­ wych rozdziałach. Jest ono kluczowe dla projektowania usług w sposób niezależny od technologii, która służyć będzie do ich implementowania. Ułatwieniu tego zrozumienia służyć mają pozatechniczne analogie towarzyszące poszczególnym punktom, przedstawiające dalszy ciąg historyjki zapoczątkowanej w poprzednich rozdziałach.

A n a liz y p rz y p a d k ó w : W rozdziale 2. pisaliśmy, że jednym z celów biznesowych RailCo jest uspraw­ nienie firmowych procesów automatyzacji biznesu poprzez skierowanie ich ewolucji w stronę SOA. W tym rozdziale przyjrzymy się opracowanym do tej pory rozwiązaniom RailCo i prze­ analizujemy ich stopień zgodności (lub niezgodności) z poszczególnymi zasadami orientacji na usługi. Dla celów porównawczych wykorzystamy usługi składające się na aktualny stan systemu B2B firmy TLS, jako posiadające charakterystykę w pełni zgodną z tą orientacją.

8.1. Orientacja na usługi z perspektyw y przedsiębiorstw a Kolektywna logika definiująca funkcjonowanie przedsiębiorstwa to logika ciągłych jego zmian wymuszonych zmieniającą się rzeczywistością. Z perspektywy IT lo g ik a p r z e d s ię b io r s tw a (e n te r­ p r is e lo g ic ) dzieli się na dwie istotne domeny: lo g ik ę b iz n e s o w ą ( b u sin e ss lo g ic ) i lo g ik ę a p lik a c y jn ą ( a p p lic a tio n lo g ic ), co symbolicznie przedstawiono na rysunku 8.1. Każda z tych dom en egzystuje w swym własnym świecie, każda reprezentuje określoną część współczesnej struktury organizacyjnej. Logika biznesowa jest udokum entow aną im plem entacją wymagań biznesowych, wywodzących się z realiów rynkowych, w których funkcjonuje przedsię­ biorstwo. Jej postać jest zwykle odzwierciedlana w strukturze procesów wyrażających wspomniane wymagania, wraz z ewentualnymi ograniczeniami, zależnościami i uwarunkowaniami zewnętrznymi. Logika aplikacyjna to zautomatyzowana implementacja logiki biznesowej, zorganizowana w po­ staci rozmaitych rozwiązań technologicznych. W yraża przepływ pracy w procesach biznesowych za pomocą systemów informatycznych — zakupionych lub wyprodukowanych samodzielnie przez przedsiębiorstwo, funkcjonujących w granicach jego infrastruktury IT, przy ograniczeniach stwa­ rzanych przez zabezpieczenia, stosownie do możliwości technicznych i stopnia uzależnienia od producentów sprzętu oraz oprogramowania.

8 .1 . O RIEN TA C JA N A USŁUGI Z PERSPEKTYWY PR ZEDSIĘBIO RSTW A

251

Rysunek 8.1. Dwie domeny logiki przedsiębiorstwa — logika biznesowa i logika aplikacyjna

Orientacja na usługi odnosi się do logiki biznesowej jako całości. W prowadza nowe koncepcje poszerzające sposoby reprezentowania tej logiki, jej postrzegania, modelowania i współdzielenia. Chociaż zasady orientacji na usługi istnieją w próżni abstrakcji i teorii, jednocześnie stanowią niezbędne uzupełnienie technologii rzeczywistego świata, bo są dla tych technologii swoistym przewodnikiem, nadającym im właściwą strukturę. Związek koncepcji wprowadzanych przez orientacje na usługi z logiką przedsiębiorstwa uwi­ dacznia się w swoisty sposób — poprzez usługi zlokalizowane w specyficznym miejscu tej logiki. Jak pokazano na rysunku 8.2, usługi te ustanawiają wysoką formę abstrakcji, wtłoczoną między warstwę tradycyjnego biznesu a warstwę aplikacyjną. Na tej pozycji zdolne są one do enkapsulowania zarówno logiki fizycznych aplikacji, jak i logiki procesów biznesowych. Usługi modularyzują logikę przedsiębiorstwa, stanowiąc samodzielne jednostki logiki istniejące w warstwie spajającej logikę biznesową z logiką aplikacyjną. W arstwa ta może podlegać podziałowi na prostsze warstwy — złożone „macierzyste” usługi mogą enkapsulować prostsze usługi „potomne”. Powrócimy do tego tematu w rozdziale 9. Na rysunku 8.2 pokazaliśmy warstwę aplikacyjną pofragm entow aną między aplikacje za­ mknięte w granicach swych specyficznych platform technologicznych, indywidualnie odpowie­ dzialnych za enkapsulację części logiki aplikacyjnej. Chociaż na rysunku umiejscowiliśmy usługi w pojedynczej, ciągłej warstwie, należy zwrócić uwagę na powiązania między nim i — są to powią­ zania między ich interfejsami, w ram ach komunikacji opartej na otwartych protokołach, wolnej od uzależnienia od konkretnej technologii. Na poziomie fizycznym usługi są tworzone i wdrażane w konkretnych środowiskach techno­ logicznych i każda z nich odpowiedzialna jest za enkapsulowanie określonej porcji logiki aplika­ cyjnej. Na rysunku 8.3 widzimy, jak poszczególne usługi, reprezentowane przez interfejsy w swej własnej warstwie, enkapsulują logikę aplikacji wywodzących się z różnych platform.

252

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

Rysunek 8.2. Warstwa interfejsu usług umiejscowiona w sposób uwydatniający zarówno logikę biznesową, jak i logikę aplikacyjną

Rysunek 8.3. Warstwa interfejsów usług oddziela implementowanie procesów biznesowych od fizycznych środowisk

8 .2 . A N A T O M IA A R C H ITEK TU R Y ZO R IE N TO W A N E J N A USŁUGI

253

P O D S U M O W A N IE •

Logikę przedsiębiorstwa można podzielić na dw ie domeny: logikę biznesową i logikę aplikacyjną. Zasady orientacji na usługi stosują się do obu.

•

W arstw a interfejsów usług pozycjonuje usługi do reprezentow ania logiki biznesowej i abstrahow ania logiki aplikacyjnej.

8.2. A natom ia architektury zorientow anej na usługi W rozdziale 5. zdefiniowaliśmy kom ponenty podstawowego (czyli pierwszej generacji) frameworku usług sieciowych. Framework ten służyć może do implementowania usług w dowolnym niemal środowisku. Przykładowo usługi mogą być dołączane do tradycyjnych aplikacji rozproszonych w celu eksponowania ich „spadkowej” logiki, żadne jednak z tych środowisk nie przypomina „prawdziwej” architektury zorientowanej na usługi. Aby lepiej zrozumieć, co składa się na prawdziwą SOA, wyodrębnimy podstawowe elementy frameworku usług sieciowych i przestudiujemy dokładniej powiązania między nimi. W tym celu ponow nie spojrzymy na nie, ale z innej perspektywy: najpierw zmienimy nieco term inologię, na bardziej zgodną z duchem zorientow ania na usługi, po czym opiszemy ich poszczególne role w kontekście SOA.

8.2.1. Logiczne komponenty frameworku usług sieciowych Framework komunikacyjny ustanawiany przez usługi sieciowe oferuje podstawową technologię, którą utożsamiać możemy ze współczesną SOA. Omawialiśmy obszernie tę kwestię w rozdziale 5. i w tym rozdziale wykorzystamy to omówienie w charakterze punktu odniesienia w naszej dyskusji na tem at orientacji na usługi. Rozpocznijmy od wybranych cech usług sieciowych w kontekście modelowania logicznego. Jak pokazano na rysunku 8.4, każda usługa sieciowa realizuje jedną lub więcej operacji (zwróćmy uwagę na nowy symbol, reprezentujący operację wydzieloną z usługi).

Rysunek 8.4. Usługa sieciowa obejmująca dwie operacje

Każda operacja związana jest z pewnym elementem funkcjonalności usługi i polega na wysy­ łaniu, odbieraniu oraz przetwarzaniu komunikatów, co pokazano to na rysunku 8.5.

254

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

Rysunek 8.5 O peracja przetwarzająca komunikaty SOAP

Łącząc trzy wymienione elementy — usługi, operacje i komunikaty — otrzymujemy aktywność, w ramach której usługi sieciowe wspólnie automatyzują określone zadanie (patrz rysunek 8.6).

Aktywność

Rysunek 8.6. Podstawowy scenariusz komunikowania się dwóch usług sieciowych

8.2.2. Komponenty logiki automatyzacji Framework usług sieciowych nie tylko dostarcza technologię zapewniającą łączność między usłu­ gami, lecz także umożliwia m odularne spojrzenie na logikę automatyzacji jak na kompozycję nie­ zależnych jednostek. Aby przybliżyć tę m odularność, wyodrębnijmy następujące kluczowe ele­ m enty wspomnianego frameworku: • kom unikaty SOAP, • operacje usług sieciowych, • usługi sieciowe, • aktywności. Trzy ostatnie z wymienionych reprezentują jednostki logiczne odpowiedzialne za wykonywa­ nie rzeczywistej pracy i komunikujące się za pośrednictwem kom unikatów SOAP. Żeby lepiej zi­ lustrować tę zależność od strony orientacji na usługi, zastąpmy ten podział nieco innym, obej­ mującym: • komunikaty, • operacje, • usługi, • procesy (i instancje procesów).

8 .2 . A N A T O M IA A R C H ITEK TU R Y ZO R IE N TO W A N E J N A USŁUGI

255

Oba podziały są bardzo podobne, jednak wyraźna różnica występuje na czwartej pozycji. W po­ przednich rozdziałach używaliśmy określenia „aktywność” w różnych kontekstach odnoszących się do modelowania procesów biznesowych zorientowanych na usługi. Obecnie zwracamy uwagę na jeden ważny szczegół tego podejścia: podczas gdy aktywność usług sieciowych postrzegana jest jako tymczasowa interakcja w ram ach ich grupy, to proces stanowi statyczną definicję logiki tej interakcji. W tym ujęciu aktywność może być porów nana do instancji procesu, w ramach której grupa usług realizuje wspólne zadanie według specyficznego scenariusza. Powróćmy do drugiego z przedstawionych podziałów — każda z jego pozycji może zostać potratow ana jako jednostka logiczna na odpowiednim szczeblu hierarchii i wówczas • kom unikaty stają się jednostkami komunikacji, • operacje stają się jednostkam i pracy, • usługi stają się jednostkam i logiki przetwarzania (zbudowanymi z jednostek pracy), • procesy stanowią jednostki logiki autom atyzacji (czyli skoordynowane agregacje jednostek pracy). Na rysunku 8.7 przedstawiono w elementarnym ujęciu pozycję operacji i usług jako jednostek składających się na logikę automatyzacji. Jednostki te, by spełniać powierzone im role, muszą komunikować się ze sobą; na rysunku 8.8 uwidoczniono rolę kom unikatów jako środków zapew­ niających przepływ informacji między jednostkam i logiki przetwarzania (czyli usługami). Z ry­ sunku tego wynika jasno, że niezależnie od zakresu logiki przetwarzania reprezentowanej przez sam ą usługę, żaden elem ent tej logiki nie może zostać urzeczywistniony bez udziału jednostek komunikacji (którymi w tym przypadku są komunikaty).

Rysunek 8.7. Elementarne ujęcie ustanawianej przez SOA modularnej struktury logiki automatyzacji

Tak więc procesy, usługi i operacje, na najbardziej podstawowym poziomie, dostarczają ela­ styczne środki do partycjonowania i modularyzowania logiki. Jest to podstawowa prawda leżąca u podstaw zorientowania na usługi, niezależnie od platform technologicznych implementujących konkretne rozwiązania. W yprowadzamy to stwierdzenie, począwszy od frameworku usług sie­ ciowych, a zatem demonstrujem y wyjątkową przydatność usług sieciowych jako technologii im ­ plementacyjnej dla SOA.

256

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

8.2.3. Komponenty SOA Zidentyfikowaliśmy już kom ponenty logiki automatyzacji, teraz wyjaśnimy, jak charakterystyka i zachowanie owych kom ponentów determinowane są przez architekturę zorientowaną na usługi. Przypom nijm y — każdy ze w spom nianych kom ponentów ustanawia pewien poziom abstrakcji w logice przedsiębiorstwa, a mianowicie: • kom unikat reprezentuje dane niezbędne do zrealizowania niektórych (lub wszystkich) jednostek pracy; • operacja reprezentuje logikę wymaganą do przetworzenia kom unikatu (komunikatów) w celu zrealizowania jednostki pracy (patrz rysunek 8.9);

Jednostka pracy

Rysunek 8.9. Zakres operacji w ramach procesu

• usługa reprezentuje zbiór pogrupowanych logicznie operacji, zdolnych do realizowania powiązanych jednostek pracy; • proces zawiera reguły biznesowe decydujące o tym, które operacje usługi wykorzystywane są do urzeczywistnienia jednostki automatyzacji. Innym i słowy, proces reprezentuje dużą ilość pracy wymaganej do zrealizowania jednostek pracy z pewnego zbioru (patrz rysunek 8.10).

8 .2 . A N A T O M IA A R C H ITEK TU R Y ZO R IE N TO W A N E J N A USŁUGI

257

Rysunek 8.1 0 . Operacje należące do odmiennych usług reprezentujące różne elementy logiki przetwarzania

8.2.4. Jak powiązane są komponenty SOA? Znam y już podstawową charakterystykę kom ponentów SOA, zobaczmy zatem, jak są powiązane: • operacja wykonuje wysyłanie i odbieranie komunikatów w celu wykonywania pewnej pracy; • a zatem operacja definiowana jest przede wszystkim poprzez komunikaty, których przetwarzaniem się zajmuje; • usługa grupuje kolekcję powiązanych operacji; • a zatem usługa definiowana jest przede wszystkim przez operacje, które się na nią składają; • instancja procesu może komponować usługi; • instancja procesu niekoniecznie musi być definiowana przez swe usługi, ponieważ może wykorzystywać jedynie cząstkę oferowanej przez nie funkcjonalności; • instancja procesu, w celu realizowania powierzonej jej automatyzacji, wywołuje unikatowy ciąg operacji; • a zatem każda instancja procesu definiowana jest częściowo przez operacje wykorzystywanych usług. Powyższe związki zilustrowano na rysunkach 8.11 i 8.12.

Komunikaty

Rysunek 8.1 1 . Powiązania komponentów architektury zorientowanej na usługi

258

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

Rysunek 8.1 2 . Genealogia definicji komponentów architektury zorientowanej na usługi

Architektura zorientowana na usługi to zestandaryzowane zgodnie z określonymi zasadami środowisko, w którym wykonywane mogą być procesy bazujące na usługach. Przeanalizujmy więc dokładniej sens poszczególnych zasad zorientowania na usługi. P O D S U M O W A N IE •

Logiczne części SOA mogą być odw zorow yw ane na odpow iadające im kom ponenty podstaw ow ego fram ew orku usług sieciowych.

•

Rozpatrując rozw iązanie zorientow ane na usługi jako jednostkę logiki autom atyzacji, postrzegamy SOA jako w yrafinow ane środowisko um ożliwiające wysoce m odularną strukturalizację logiki w postaci jednostek o różnym rozmiarze.

•

SOA ustanawia specyficzne cechy i reguły zachowania wspom nianych kom ponentów oraz związki między nimi. Prowadzi to do przew idyw alnego środowiska zorientow anego na usługi.

8.3. P odstaw ow e zasady zo rientow ania na usługi Jak wyjaśnialiśmy w rozdziale 3., nie istnieje jakakolwiek oficjalna definicja SOA, nie istnieje też żadna organizacja standaryzacyjna, w której (wyłącznej) gestii spoczywałoby definiowanie zasad precyzujących określenie „orientacja na usługi”. To, co faktycznie ukształtowało się jako „zasady zorientowania na usługi”, to raczej zbiór wytycznych, stanowiących wypadkową wielu opinii, wy­ wodzących się z publicznych organizacji IT, producentów i firm konsultingowych. W edług powszechnie panującego przekonania, zorientowanie na usługi wywodzi swe korze­ nie od fundam entalnej dla projektow ania oprogram ow ania (i nie tylko oprogram owania) idei „separowania zagadnień”: otóż złożony problem staje się mniej kłopotliwy w rozwiązywaniu, jeśli rozpatrywać go jako kompozycję prostszych podproblemów. Logikę rozwiązywania tego problemu m ożna wówczas dekomponować na serię prostszych, powiązanych elementów, z których każdy dedykowany jest rozwiązywaniu jednego ze wspomnianych podproblemów. Opisana idea uzewnętrznia się w inżynierii oprogramowania pod różnymi postaciami, w formie różnych koncepcji programistycznych: dla przykładu w program owaniu strukturalnym separację złożonego problem u osiąga się za pom ocą powiązanych ze sobą bloków liniowych, instrukcji

8 .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

259

warunkowych, instrukcji wyboru i pętli, a w program owaniu zorientowanym obiektowo rolę tę pełnią klasy, interfejsy, obiekty i komponenty. Oczywiście, nie wspominalibyśmy o tym tutaj, gdyby nie fakt, że zorientowanie na usługi sta­ nowi kolejną egzemplifikację rzeczonej dekompozycji złożonych problemów. Gdy mianowicie przyjrzeć się zasadom orientacji na usługi, stwarzającym podwaliny pod cechy charakterystyczne dla współczesnej SOA, m ożna zauważyć, że większość tych zasad m a związek (bezpośredni lub pośredni) z ideą separacji podproblemów. Jak wspomnieliśmy przed chwilą, nie istnieje oficjalny zbiór zasad orientacji na usługi, niemniej jednak na kanwie miarodajnych opinii ukształtował się zestaw wytycznych, który z takim zbiorem może być utożsamiany. W ymieniam y je poniżej i opisujemy dokładniej w kolejnych punktach. •

U s łu g i są w ie lo u ż y w a ln e — niezależnie od tego, czy w danym kontekście istnieje możliwość wielokrotnego używania danej usługi, generalnie w projektowaniu usług powinno brać się pod uwagę ich potencjalną wieloużywalność.

•

U s łu g i w s p ó łd z ie lą m ię d z y s o b ą f o r m a ln e k o n t r a k t y — do współdziałania usługi nie potrzebują nic ponad wymianę formalnych kontraktów, opisujących poszczególne usługi i wyznaczających zasady ich współpracy z innymi usługami.

•

U s łu g i są lu ź n o p o w ią z a n e — współdziałanie usług musi być możliwe bez ustanawiania między nim i ścisłych uzależnień.

•

U s łu g i u k r y w a ją sw ą w e w n ę t r z n ą lo g ik ę — jedyną informacją o usłudze widoczną dla

świata zewnętrznego jest jej kontrakt. W ewnętrzna logika usługi, której elementy nie są ujęte w opisie tej usługi, jest niewidoczna na zewnątrz, a usługi-wnioskodawcy nie mogą być od niej w żaden sposób uzależniane. •

U s łu g i są k o m p o n o w a ln e — usługa może zostać zrealizowana jako kompozycja prostszych usług składowych. Umożliwia to reprezentowanie logiki usług na różnych poziomach granulacji, ponadto sprzyja wieloużywalności usług i budowaniu warstw abstrakcji.

•

U s łu g i są a u t o n o m ic z n e — logika usługi m a wyraźnie określone granice i w tych granicach pozostaje pod wyłączną kontrolą tej usługi. Żadne inne usługi nie mogą mieć bezpośredniego wpływu na realizację tej logiki.

•

U s łu g i są b e z s ta n o w e — od usługi nie m ożna wymagać zarządzania informacją o stanie realizowanego przez nią przetwarzania, bo kłóciłoby się to z wymogiem jej luźnego powiązania z otoczeniem. Usługi powinny być projektowane z jak największym stopniem bezstanowości, nawet wtedy, gdyby wiązało się to z koniecznością utrzymywania innych form informacji o stanie.

•

U s łu g i są w y k r y w a ln e — opisy usług powinny być formułowane w sposób ułatwiający ich odnajdywanie, czytelny dla człowieka i reprezentatywny dla usług-wnioskodawców poszukujących określonych form funkcjonalności.

Cztery spośród powyższych — autonomię, luźne powiązanie, ukrycie wewnętrznej logiki i wymóg formalnego kontraktu — uważać można za kluczowe („rdzenne”) zasady wyznaczające fundament SOA. Jak wyjaśnimy później w punkcie „Jak powiązane są zasady zorientowania na usługi?”, właśnie one stanowią punkt wyjścia dla pozostałych.

260

RO ZD ZIAŁ 8 . a ZASADY ORIENTACJI N A USŁUGI

D o lis ty o ś m iu w y m ie n io n y c h cech S O A m o ż n a b y d o d a ć jeszcze k ilk a , m ię d z y in n y m i s a m o d o k u m e n tu ją c y c h a ra k te r o p is ó w u s łu g o ra z g ru b o z ia rn is te in te r fe js y ty c h u s łu g . M i m o sw ego is to tn e g o z n a c z e n ia , tra k to w a n e są o n e je d n a k rac ze j ja k o w s k a z ó w k i n iż o b o w ią z u ją c e zasady, w ię c d yskusję n a ic h te m a t o d k ła d a m y do r o z d z ia łu 15.

UW AGA Czytelnicy zauważyli zapew ne, że wieloużywalność i autonomia usług to zasady odnoszące się także do w spół­ czesnej SOA, której charakterystykę om aw ialiśm y w rozdziale 3. To efekt zam ierzony, bo w tym rozdziale zajm ujem y się cechami zarów no SOA jako całości, jak i usług projektowanych na użytek SOA. W rozdziale 9. wyjaśnim y dokładniej zw iązek między charakterystyką współczesnej SOA a zasadam i orientacji na usługi.

B y w p e łn i z ro z u m ie ć , ja k za s a d y o rie n ta c ji n a u s łu g i k s z ta łtu ją a rc h ite k tu rę z o r ie n to w a n ą n a u s łu g i, p r z e a n a liz u je m y im p lik a c je ic h z a s to s o w a n ia ja k o g łó w n y c h s k ła d n ik ó w S O A , p o c z y m p r z y jr z y m y się d o k ła d n ie j k a ż d e j z ty c h zasad z o sobn a.

8.3.1. Usługi są wieloużywalne O rie n ta c ja n a u s łu g i n a k a z u je p ro je k to w a n ie w s z e lk ic h u s łu g z u w z g lę d n ie n ie m ic h w ie lo u ż y w a ln o ś c i, n ie z a le ż n ie o d te g o , c z y w y m ó g w ie lo u ż y w a ln o ś c i je s t a k tu a ln y ju ż w fa zie te g o p r o je k ­ to w a n ia . Z a s to s o w a n ie s ta n d a rd ó w p ro je k to w y c h , k tó re s p ra w ia ją , że u s łu g a staje się p o te n c ja ln ie w ie lo u ż y w a ln a , jest p r a k ty k ą z d e c y d o w a n ie d a le k o w z ro c z n ą , b o g d y fa k ty c z n ie p o ja w i się o k a z ja do w ielo k ro tn e g o u ż y w a n ia tej usługi, b ęd zie m o ż n a okazję tę s pożytkow ać za cenę n ie w ie lk ie g o w y ­ siłku. U s łu g i z n a tu ry w ie lo u ży w a ln e re d u k u ją także p o trzeb ę tw o rz e n ia specjalnych u sług-oto czek, ek s p o n u ją c y c h g e n e ry c z n e in te rfe js y w o k ó ł u s łu g o m a ły m s to p n iu w ie lo u ż y w a ln o ś c i. U s łu g a z n a tu r y w ie lo u ż y w a ln a u ła tw ia re a liz o w a n ie w s z e lk ic h fo r m je j w ie lo k ro tn e g o u ż y ­ w a n ia , m ię d z y in n y m i w e w s p ó łd z ia ła n iu m ię d z y a p lik a c y jn y m , w o p r o g ra m o w a n iu n a rz ę d z io w o u ż y tk o w y m c zy k o m u n ik a c ji s k ro ś n e j (c ro s s -c u ttin g ). Jako że us łu g a je s t w isto cie k o le k c ją p o w ią ­ z a n y c h o p e ra c ji, u c z y n ie n ie ty c h o p e ra c ji w ie lo u ż y w a ln y m i daje w e fekcie g w a ra n c ję o trz y m a n ia w ie lo u ż y w a ln e j u słu g i. I v ic e v e rs a — o p e ra c je e k s p o n o w a n e p rz e z w ie lo u ż y w a ln ą usługę sam e są w ie lo u ż y w a ln e , czego p rz y k ła d p rz e d s ta w ia m y n a r y s u n k u 8 .1 3 . K o m u n ik a ty ró w n ie ż (p o ś re d n io ) p rz y c z y n ia ją się do w ie lo u ż y w a ln o ś c i u sług, a to za s p ra w ą n a g łó w k ó w S O A P . N a g łó w k i te s p ra w ia ją , że k o m u n ik a ty są s a m o w y s ta rc z a ln e , b o ła d u n k o w i u ż y te c z n e m u k o m u n ik a tu to w a rz y s z ą m e ta d a n e z g ru p o w a n e w p o je d y n c z y m p a k ie c ie (z a ja k i m o ż e b y ć u w a ż a n a k o p e rta S O A P ). M e ta d a n e te z a w ie ra ją m ię d z y in n y m i in s tru k c je p r z e tw a r z a ­ n ia i re g u ły b izn e s o w e , d y k tu ją c e o d b io rc y k o m u n ik a tu sposób jeg o tr a k to w a n ia p o o d e b ra n iu . W b u d o w a n ie w k o m u n ik a t m e ta in fo r m a c ji o k re ś la ją c e j lo g ik ę je g o p r z e tw a r z a n ia u w a ln ia p ro je k ta n tó w o d w b u d o w y w a n ia te j lo g ik i b e z p o ś re d n io w u s łu g i, a p o n a d to s tw a rz a n a tu ra ln e w y m a g a n ie , b y u s łu g i b y ły w sta n ie p rz e tw a rz a ć ta k ą in fo rm a c ję , c zy li a b y b y ły w ysoce u n iw e r ­ s a ln e , „ g e n e ry c z n e ” — c z y li w z n ik o m y m s to p n iu z a le ż n e (lu b c a łk ie m n ie z a le ż n e ) o d ro d z a ju a k ty w n o ś c i, w k tó ry c h p rz e w id z ia n o u c ze s tn ic z e n ie o d n o ś n e j u s łu g i. T a k w ię c im b a rd z ie j g e n e ­ ry c z n e b ę d ą o p e ra c je o b e jm o w a n e p rz e z u sługę, ty m b a rd z ie j w ie lo u ż y w a ln a b ę d z ie s a m a usługa.

8 .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

261

Rysunek 8.1 3 . Wieloużywalna usługa eksponuje wieloużywalne operacje

A N A LIZA PRZYPADKU

Usługa W y s ta w ie n ie f a k t u r y w RailCo skonstruowana została w jednym celu — dla łączności z systemem B2B firmy TLS. Jej podstawową funkcją jest wysyłanie elektronicznych doku­ m entów faktur do usługi TLS P ła tn o ś ć n a k o n t o . Realizuje ona dwie operacje: W y ś lij fa k tu r ę i P o b ie r z m e ta d a n e T L S (patrz rysunek 8.14).

Rysunek 8.1 4 . Usługa RailCo Wystawienie faktury i jej operacje

O peracja W y ś lij f a k t u r ę po prostu inicjuje transm isję dokum entu faktury. Zadaniem operacji P o b ie r z m e ta d a n e T L S jest okresowe sprawdzanie wersji opisu usługi TLS P ła tn o ś ć n a k o n t o , co wyjaśniliśmy w rozdziale 7., w podrozdziale „W ymiana metadanych”.

262

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

Jako podyktowane doraźną potrzebą i skonstruowane w związku ze specyficznymi wy­ maganiami biznesowymi, operacje te nie przejawiają wyraźnego potencjału wieloużywalności. Operację W y ś lij fa k tu r ę utworzono w celu wysyłania komunikatów SOAP posiadających spe­ cyficzne nagłówki wymagane przez TLS i zawierających fakturę w postaci dokum entu XML, sformatowanego stosownie do wymagań TLS. Zadanie powierzone operacji P o b ie r z m e ta ­ d a n e T L S też jest wyraźnie określone, zgodnie zresztą z jej nazwą: jest nim periodyczne prze­ pytywanie punktu końcowego pod kątem aktualnej postaci jego metadanych. W TLS sprawy mają się cokolwiek inaczej. Usługa P ła tn o ś ć n a k o n t o obejmuje szereg generycznych operacji związanych z przetwarzaniem transakcji zapłaty za fakturę. Usługa ta wykorzystywana jest przez różne systemy TLS, z których jednym jest wspomniany wcześniej system B2B. Dla RailCo nic to jednak straconego: w rozdziałach 11. i 12. potraktujem y usługę W y s ta ­ w ie n ie f a k tu r y jako obiekt ćwiczeń z zakresu modelowania, w ramach których uczynimy z niej usługę implementującą zasady orientacji na usługi, w tym wieloużywalność.

PO PROSTU Pewnego dnia odw iedził nas specyficzny klient. Gdy zapytaliśm y go, czy życzy sobie, by umyć i nawoskow ać karoserię jego samochodu, spytał nas, czy posiadamy koncesję na świadczenie usług tego typu — i okazał legitymację inspektora. Z krótkiej rozm ow y w ynikało, iż nasza działalność istotnie jest koncesjonow ana. Nie m ieliśm y innego wyjścia, ja k zawiesić ją do czasu uzyskania rzeczonej licencji, co (mieliśmy nadzieję) pow inno nastąpić dość szybko. Niezw łocznie odw iedziliśm y okręgow e biuro koncesyjne w celu rozpoczęcia stosownej procedury. W spom niane biuro koncesyjne oferuje dobrze określoną usługę: w yd a w a n ie i odnaw ianie koncesji. Nie jest to usługa wym yślona na potrzeby naszej myjni, może z niej skorzystać każdy zainteresow any. Ponieważ w danym czasie biuro koncesyjne rozpatruje rów nolegle w iele w niosków o przyznanie koncesji, świadczona przez to biuro usługa może być uw ażana za w ieloużyw alną.

8.3.2. Usługi współdzielą formalne kontrakty K ontrakt usługi zawiera formalną definicję: • punktu końcowego usługi, • poszczególnych operacji obejmowanych przez usługę, • kom unikatów wejściowych i wyjściowych związanych z poszczególnymi operacjami, • reguł oraz charakterystyk usługi i jej operacji. Kontrakty usług definiują zatem niemal wszystkie pierwotne aspekty SOA (patrz rysunek 8.15). Dobry kontrakt usługi powinien także dostarczać semantykę wyjaśniającą, w jaki sposób projek­ tanci usługi przystosowali ją do wykonywania konkretnych zadań. Tak czy inaczej, inform acja zawarta w kontrakcie usługi stanowi płaszczyznę porozum ienia między usługą-dostarczycielem a jej potencjalnymi usługami-wnioskodawcami.

8 .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

263

Definiow ane przez kontrakt usługi

Rysunek 8.1 5 . Kontrakty usług formalnie definiują usługi, operacje i komunikaty jako komponenty architektury zorientowanej na usługi

Ponieważ kontrakt usługi współdzielony jest przez wiele usług-wnioskodawców, jego staranne zaprojektowanie jest sprawą wyjątkowej wagi. Od niego przecież zależna będzie jakość współpracy usługi-dostarczyciela z jej usługami-wnioskodawcami, dlatego powinien być starannie utrzymy­ wany i wersjonowany od samego początku. Jak wyjaśnialiśmy w rozdziale 5., dokum enty opisujące usługę — jej definicja WSDL, sche­ maty XSD i założenia polityki — mogą być kolektywnie traktowane jako kontrakty komunikacyjne, precyzujące sposób programowego dostępu do usługi.

A N A LIZA PRZYPADKU

W spółpraca RailCo z systemem B2B firmy TLS nie byłaby możliwa, gdyby nie kontrakty usług uzgodnione między tymi firmami. Reguły tych kontraktów oraz dokum enty składające się na opisy poszczególnych usług dostarczone zostały przez TLS wszystkim jej partnerom online w celu ustanowienia zestandaryzowanego poziomu współpracy. Pewnego dnia RailCo poinform owana została przez TLS o zmodyfikowaniu założeń po­ lityki związanych z usługą P ła tn o ś ć n a k o n t o . Otóż, oprócz dotychczasowej płatności w te r­ m inie 60-dniow ym , TLS oferuje także opcję term inu 30-dniowego, w zam ian za większy rabat cenowy. Oba warianty są warunkami kontraktu usługi opublikowanego przez TLS. Po ich dokład­ nym przeanalizowaniu i ewaluacji RailCo postanowiła pozostać przy dotychczasowych cenach i 60-dniowym term inie płatności, nie dostrzegając specjalnych korzyści w szybszym otrzy­ mywaniu zapłaty za faktury.

264

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

PO PROSTU Aby biuro koncesyjne mogło rozpocząć procedurę zmierzającą do przyznania nam koncesji, musimy wypełnić form ularz aplikacyjny. Stanowić on będzie formalizację naszego żądania w postaci oczekiwanej i w ym aganej przez biuro. W ypełniony form ularz aplikacyjny stanow i rodzaj kontraktu między biurem (jako dostarczycielem usługi) a naszą firm ą (jako w nioskodaw cą). Przyjmując form ularz, biuro zgadza się na rozpoczęcie procedury kon­ cesyjnej.

8.3.3. Usługi są luźno powiązane Ewolucja środowiska IT to długofalowy proces, którego przebiegu nie sposób przewidzieć. Nie da się zawczasu zaplanować, jak poszczególne rozwiązania automatyzacji będą rozwijane, integro­ wane czy zastępowane innym i, bo to uzależnione jest od (równie nieprzewidywalnych) czynni­ ków zewnętrznych w stosunku do wspomnianych środowisk. Skoro nie da się przewidywać przy­ szłych wydarzeń, nie pozostaje nic innego, jak zapewnić sobie możliwość szybkiego i skutecznego reagowania, gdy będą się pojawiać. Realizacji tej formy zwinności organizacyjnej sprzyja zacho­ wanie luźnego charakteru powiązania między usługami (patrz rysunek 8.16)

Logika wewnętrzna

I Luźno powiązane

Logika wewnętrzna

•

I i

Rysunek 8.1 6 . Usługi ograniczają wzajem ną zależność jedynie do swych kontraktów, co pozwala zachować niezależność wewnętrznej logiki wnioskodawcy i dostarczyciela

Usługi muszą być powiązane w pewien sposób, ponieważ do wzajemnego współdziałania wy­ magają pewnej wiedzy na swój temat. O ścisłości ich powiązania decyduje zakres tej niezbędnej wiedzy: w warunkach powiązania luźnego zakres ten ograniczony jest do niezbędnego minim um , same zaś usługi, mim o iż powiązane ze sobą, nie tracą swej względnej niezależności. Owo „nie­ zbędne minim um ” wiedzy o usłudze to nic innego jak jej kontrakt, umożliwiający interakcję z innymi usługami w ram ach predefiniowanych parametrów. W arto zauważyć w tym miejscu, iż w w arun­ kach luźnego powiązania między poszczególnymi usługami na gruncie każdego pojedynczego kontraktu występuje ścisłe powiązanie operacji z ich macierzystą usługą: w sytuacji, gdy usługa formalnie opisana zostaje jako umiejscowienie zbioru operacji, inne usługi stają się niezależne od tegoż umiejscowienia.

8 .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

265

A N A LIZA PRZYPADKU

Ponieważ współpraca online RailCo i TLS opiera się na uzgodnionych kontraktach usług, usługi te w naturalny sposób są luźno powiązane. Mimo to, stopień tego luźnego powiązania jest w każdej z firm znacząco różny. Usługi TLS zaprojektowane zostały z myślą o zarówno jednoczesnej obsłudze wielu part­ nerów B2B, jak i o wewnętrznym wykorzystywaniu (w ram ach kompozycji i innych form wieloużywalności). W ym agania te sprawiły, że usługi są b a r d z o luźno powiązane z każdą z usług-wnioskodawców. Dla odm iany, usługi RailCo zaprojektow ane zostały specjalnie na potrzeby interakcji z usługami firmy TLS składającymi się na jej system B2B; nie poczyniono żadnych specjalnych starań w kierunku ich użyteczności dla jakichkolwiek innych usług-wnioskodawców. Ich powiązanie z wnioskodawcami jest zdecydowanie m n ie j luźne niż w przypadku usług TLS.

PO PROSTU Po złożeniu formularza o przyznanie koncesji mogliśmy opuścić biuro koncesyjne; na (pom yślne, miejm y na­ dzieję) rozpatrzenie wniosku mogliśmy oczekiwać gdziekolw iek, niekoniecznie w biurze. Przypomina to nieco asynchroniczną w ym ianę kom unikatów , lecz jest jednocześnie przykładem luźnego pow iązania m iędzy biurem a jego petentam i, czyli m iędzy dostarczycielem usługi a jej w nioskodaw cam i. Jedynym środkiem ow ego pow iązania jest form ularz aplikacyjny, zaw ierający informację stanowiącą treść żądania. Po jego złożeniu nasz zespół (jako w nioskodaw ca) oraz biuro koncesyjne (jako dostarczyciel) pozo­ stajem y niezależni od siebie, ta k jak byliśmy niezależni dotychczas.

8.3.4. Usługi ukrywają wewnętrzną logikę Ta zasada, określana także jako a b s tr a h o w a n ie u s łu g n a p o z io m ie in te rfe js ó w (s e rv ic e in te rfa c e le v e l a b s tr a c t io n ), umożliwia traktow anie poszczególnych usług jak „czarnych skrzynek”, skry­ wających swe detale przed światem zewnętrznym. Zakładany zakres logiki reprezentowanej przez usługę m a znaczący wpływ na projektowanie jej operacji oraz jej pozycję w ram ach procesu. Rozmiar logiki reprezentowanej przez usługę jest praktycznie nieograniczony. Może ona wy­ konywać proste zadanie, lecz równie dobrze stanowić może bramę do kompletnego rozwiązania automatyzacyjnego. Podobnie nie m a ograniczenia charakteru źródła, z którego usługa czerpie swą logikę — przykładowo usługa może eksponować połączoną logikę dwóch różnych systemów, tak jak na rysunku 8.17. Granulacja operacji jest zatem podstawowym problemem projektowym, bezpośrednio zwią­ zanym z zakresem i naturą funkcjonalności eksponowanej przez projektowaną usługę. Bo to właśnie operacje kolektywnie abstrahują wewnętrzną logikę usługi, sama usługa jest tylko kontenerem na swe operacje.

266

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

Abstrahow anie na poziomie interfejsu jest jedną z przyrodzonych zalet usług sieciowych. Struktura komunikacji w warunkach luźnego powiązania wymaga, by jedyną porcją wiedzy nie­ zbędnej do interakcji między usługami były opisy tych usług.

Rysunek 8.1 7 . Operacje usługi oddzielają wewnętrzne detale od eksponowanej funkcjonalności

A N A LIZA PRZYPADKU

Ponieważ współpraca online między RailCo a TLS odbywa się przy użyciu usług sieciowych, każda z tych firm z pow odzeniem im plem entuje abstrahowanie na poziom ie interfejsów. Po stronie RailCo abstrakcja ta skrywa „spadkowe” systemy generujące elektroniczne faktury i przetwarzające nadchodzące zamówienia. Ze strony TLS usługi skrywają natom iast kom po­ zycje, w ramach których ciężar przetwarzania delegowany jest do specjalizowanych usług uczestniczących w poszczególnych aktywnościach (patrz rysunek 8.18).

8 .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

267

Rysunek 8.1 8 . Żadna z usług RailCo i TLS nie ma pojęcia o szczegółach tego, co dzieje się za kurtyną usług po drugiej stronie

PO PROSTU Procedura w eryfikow ania wniosku o przyznanie koncesji obejm uje między innymi spraw dzenie, czy: •

pod proponow aną nazw ą („Oasis Car W as h ") nie funkcjonuje już inna firm a,

•

żaden z członków-założycieli nie był w przeszłości ofiarą bankructwa,

•

um ow a subdzierżaw y ze stacją p a liw upraw nia nas do w ykonyw an ia działalności objętej w n io sko w an ą koncesją.

Te i inne formalności w ykonyw ane są jednak bez naszej wiedzy — generalnie nie musimy troszczyć się o to, jak w szczegółach przebiega weryfikacja naszego wniosku koncesyjnego. Interesuje nas jedynie finał — w ydanie upragnionej koncesji.

268

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

8.3.5. Usługi są komponowalne Usługa może reprezentow ać dowolny zakres logiki pochodzącej z różnego typu źródeł, w tym z innych usług. Głównym powodem im plementowania tej zasady jest zapewnienie, że projekto­ wane usługi będą mogły efektywnie funkcjonować jako ewentualne uczestniczki kompozycji. I to niezależnie od tego, czy sam a usługa projektow ana jest jako kom pozycja innych usług (patrz rysunek 8.19).

Rysunek 8.1 9 . Operacja Aktualizuj wszystko enkapsulująca kompozycję usług

Jednym z najbardziej spektakularnych przykładów rozszerzeń SOA zbudowanych na koncepcji komponowalności jest orkiestracja: zorientowany na usługi proces, który m ożna uważać za kom ­ pozycję usług, sterowany jest przez wybraną usługę-kontrolera procesu macierzystego, stanowią­ cego kompozycję tejże usługi oraz innych usług uczestniczących. Gdy chcemy nadać projektowanej usłudze wysoki stopień komponowalności, należy skon­ centrować się na odpowiednim projektowaniu jej operacji. Komponowalność to w istocie inna form a wieloużywalności: standardowy projekt tych operacji zapewnia im wieloużywalność, na­ tomiast ich komponowanie będzie łatwiejsze, gdy nada im się odpowiedni stopień granulacji.

A N A LIZA PRZYPADKU

Podobnie jak usługa W y s ta w ie n ie f a k t u r y , tak i usługa R e a liz a c ja z a m ó w ie n ia w RailCo powstała zgodnie z konkretnym i wymaganiami firmy TLS związanymi ze specyfiką kom uni­ kacji z jej systemem B2B.

S .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

269

U s łu g a R e a liz a c ja z a m ó w ie n ia z a w ie ra ty lk o je d n ą p u b lic z n ą operację o n a z w ie P r z e tw ó r z z a m ó w ie n ie T L S (p a tr z ry s u n e k 8 .2 0 ). O p e ra c ję tę z a p ro je k to w a n o z g o d n ie ze s p e c y fik a c ją T L S d la p a rtn e ró w o n lin e , jest w ię c zd o ln a odbierać i p rze tw a rza ć zlecenia z a k u p u w ysyłane p rze z usługę T L S Z le c e n ie z a k u p u . E le m e n te m w s p o m n ia n e j zg o d n o ś c i je s t z d o ln o ś ć do p r z e tw a ­ r z a n ia s p e c y fic z n y c h n a g łó w k ó w S O A P , z a w ie ra ją c y c h „ ż e to n y ” (to k e n s ) b e z p ie c z e ń s tw a .

Rysunek S.2G. Usługa RailCo Realizacja zamówienia z pojedynczą operacją

M im o iż usługa R e a liz a c ja z a m ó w ie n ia m o ż e fu n k c jo n o w a ć ja k o s k ła d n ik k o m p o z y c ji, jej m o ż liw o ś c i w ty m w z g lę d zie są rac ze j o g ra n ic z o n e . K o m p o n o w a ln o ś ć je s t p o d o b n a do w ie ­ lo u ż y w a ln o ś c i w ty m sensie, że w ię k s za u n iw e rs a ln o ś ć („g e n e ry c zn o ś ć ”) p u b lik o w a n e j fu n k ­ cjo n aln o ści n a d aje u słudze w ię k s zą zd o ln o ś ć do u c ze s tn ic ze n ia w k o m p o z y c ja c h . U s łu g a R e a li­ z a c ja z a m ó w ie n ia e k s p o n u je p o je d y n c z ą o p e ra c ję , re a liz u ją c ą w ysoce s p e c ja liz o w a n ą fu n k c ję p r z e tw a rz a n ia sp ecy fic zn e g o d o k u m e n tu o trz y m y w a n e g o ze s p e c y fic zn e g o ź ró d ła . O g e n e ry c z n o ś c i m o w y racze j b y ć tu n ie m o ż e i u s łu g a ja k o ta k a m a ło n a d a je się n a s k ła d n ik k o m ­ p o z y c ji. M o g ła b y n a to m ia s t z p o w o d z e n ie m s p e łn ia ć ro lę u s łu g i-k o n tro le ra , za p rzę g ają c e j in n e u s łu g i do w s p ó łu c z e s tn ic tw a w e w s p o m n ia n y m p rz e tw a rz a n iu z a m ó w ie n ia . D la o d m ia n y , usługa T L S P ła tn o ś ć n a k o n to z n a k o m ic ie p re z e n tu je się ja k o s k ła d n ik k o m ­ p o z y c ji, w k tó re j p e łn i ro lę k o n tro le ra k o o rd y n u ją c e g o fu n k c jo n o w a n ie usług P r o file d o s ta w ­ c ó w i R e je s tr k s ię g i g łó w n e j (p a tr z ry s u n e k 8 .2 1 ). W s z y s tk ie t r z y w y m ie n io n e u s łu g i e k s p o ­ n u ją z b io ry g e n e ry c z n y c h o p e ra c ji, w s zy s tk ie p rz y d a tn e są do u c z e s tn ic tw a w e w e n tu a ln y c h in n y c h k o n fig u ra c ja c h k o m p o z y c y jn y c h .

Rysunek 8.2 1 . Kompozycja TLS sterowana przez usługę Płatność na konto

270

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

PO PROSTU Ponieważ usługi oferow ane przez biuro koncesyjne są dobrze zdefiniow ane i w istocie w ieloużyw alne, mogą być świadczone nie tylko na rzecz podm iotów ubiegających się o koncesje, lecz również na rzecz innych or­ ganizacji administracyjnych. Taką organizacją jest na przykład Biuro Relokacji Biznesu, zarządzające proce­ durami zm iany lokalizacji firm w sytuacjach, gdy np. budynek mieszczący dotychczasową lokalizację firmy przeznaczony zostaje do wyburzenia. Wśród w ielu zadań związanych z taką relokacją biuro relokacji musi zrew idow ać koncesję relokowanej firm y. W tym celu kontaktuje się ono z biurem koncesyjnym w celu zre w id o w an ia aktualnej licencji firm y i wydania nowej. W ten sposób usługa świadczona przez biuro koncesyjne staje się uczestnikiem kompozycji usług kontrolowanej przez biuro relokacji, obejmującej w iele usług pomocniczych świadczonych przez inne podmioty.

8.3.6. Usługi są autonomiczne Autonom ia usługi oznacza sprawowanie przez nią wyłącznej kontroli nad enkapsulowaną przez siebie logiką, pozostającą w ściśle określonych granicach. A utonom ia eliminuje zatem zależność usługi od innych usług — zależność, która mogłaby ograniczać możliwości jej zastosowań i roz­ woju (patrz rysunek 8.22). Względy autonom ii usług należą do najważniejszych zagadnień pro­ jektowych na etapie partycjonowania logiki aplikacji między usługi i grupowania operacji w kontek­ ście poszczególnych usług.

Usługa w czasie realizacji sprawuje wyłączną kontrolę nad swą wewnętrzną logiką

Rysunek 8.2 2 . Autonomiczna usługa sprawująca wyłączną kontrolę nad swymi wewnętrznymi zasobami

8 .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

271

Jednym z p o m y s łó w n a zw iększenie a u to n o m ii usług i uczynienie ic h b ard ziej g e n e ry c zn y m i jest op óźnienie lo k o w a n ia re g u ł biznesow ych. R eg u ły b izneso w e d e te rm in u ją s tru k tu rę procesu i w konse­ kw encji w yznaczają sposób k o m p o n o w a n ia usług autom atyzujących logikę przetw arzania. T o także jeden z aspektów orkiestracji, o m a w ia n y d o k ła d n ie j w rozdziale 9., w p u n k c ie „ W a rs tw a orkiestracji usług”. W a r to w ty m m ie js c u za zn a c zy ć , że a u to n o m ia u s łu g i n ie k o n ie c z n ie m u s i o zn a c zać w y łą c z n ą w łasn o ść e n k a p s u lo w a n e j p rz e z n ią lo g ik i. A u to n o m ia s ta n o w i je d y n ie g w a ra n c ję te g o , że usługa w czasie r e a liz a c ji lo g ik i p o s ia d a p e łn ą k o n tro lę n a d tą re a liz a c ją . W z w ią z k u z ty m fa k te m w y ­ r ó ż n ia się d w a n a s tę p u ją ce ty p y a u to n o m ii: •

A u t o n o m ię n a p o z io m ie u s łu g (s e rv ic e -le v e l a u to n o m y ) — u s łu g i są w y ra ź n ie o d d z ie lo n e (ro z g ra n ic z o n e ) o d sieb ie, m o g ą je d n a k w s p ó łd z ie lić zaso b y. P r z y k ła d e m ta k ie j s y tu a c ji je s t u s łu g a -o to c z k a e n k a p s u lu ją c a „ s p a d k o w e ” ś ro d o w is k o , w s p ó łp ra c u ją c e je d n a k z in n y m i ś ro d o w is k a m i n ie z a le ż n ie o d o w e j u s łu g i. U s łu g a s p ra w u je w ó w c za s w y łą c z n ą k o n tro lę n a d e k s p o n o w a n ie m p rz e z siebie w y b ra n e g o z a k re s u lo g ik i tego ś ro d o w is k a , lecz n ie je s t w y łą c z n y m w ła ś c ic ie le m z a s o b ó w te g o ż ś ro d o w is k a , g d y ż w s p ó łd z ie li o w e za s o b y z in n y m i s p a d k o w y m i k lie n ta m i.

•

A u t o n o m ię z u p e łn ą ( p u re a u to n o m y ) — u s łu g a s p ra w u je w y łą c z n ą k o n tro lę n a d sw ą lo g ik ą i je st w y łą c z n y m w ła ś c ic ie le m z a s o b ó w d la tej lo g ik i s p e c y fic zn y c h . D o ty c z y to m ię d z y in n y m i ty c h usłu g , k tó ry c h lo g ik a p ro je k to w a n a je s t o d zera.

A N A LIZA PRZYPADKU

Z w a ż y w s z y n a ro z d z ie ln o ś ć z a d a ń w y k o n y w a n y c h p rz e z u s łu g i R a ilC o , m o ż n a u s łu g i w y ­ m ie n io n e p o n iż e j u w a ż a ć za a u to n o m ic z n e : •

W y s ta w ie n ie f a k tu r y ,

•

R e a liz a c ja z a m ó w ie n ia ,

•

S u b s k ry p c ja T L S .

L o g ik a k a ż d e j z n ic h z a m k n ię ta je s t w w y ra ź n y c h g ra n ic a c h i n ie n a k ła d a się n a lo g ik ę ża d n e j in n e j u sługi. A u to n o m ia u słu g R a ilC o jest rac ze j e fe k te m m im o w o ln y m , b o n ik t z p r o je k ta n tó w n ie z a b ie g a ł ś w ia d o m ie o u tr z y m a n ie lo g ik i ty c h u s łu g w ro z łą c z n y c h g ra n ic a c h . P ro je k to w a n o je w y łą c z n ie w celu s p e łn ie n ia o k re ś lo n y c h w y m o g ó w w s p ó łp ra c y z s y s te m e m B 2 B f ir m y T L S . Jak w id a ć n a ry s u n k u 8 .2 3 , u s łu g i P r z e t w a r z a n ie f a k t u r y i R e a liz a c ja z a m ó w ie n ia e n k a p s u lu ją „ s p a d k o w ą ” lo g ik ę . T ra d y c y jn y system fin a n s o w o -k s ię g o w y w y k o rz y s ty w a n y je s t p rz e z in n e k lie n ty , n ie z a le ż n ie o d w y m ie n io n y c h u s łu g , m a m y w ię c do c z y n ie n ia z a u to n o ­ m ią n a p o z io m ie u sługi. P e łn a a u to n o m ia cechuje n a to m ia s t usługę P o w ia d a m ia n ie T L S , ja k o w y k o rz y s tu ją c ą sp ec y fic zn e k o m p o n e n ty u tw o rz o n e w y łą c z n ie n a je j p o trz e b y . W ś ro d o w is k a c h , w k tó r y c h d z ia ła w ie le u s łu g i re g u la rn ie p o ja w ia ją się n o w e , ty p o w e je s t w p ro w a d za n ie d e d y k o w a n y c h p ro cesó w m o d e lo w a n ia , co nadaje p o szczeg ólnym u słu g o m p e łn ą a u to n o m ię . P rz y k ła d o w o u s łu g i T L S są e fe k te m za s to s o w a n ia a n a liz y z o rie n to w a n e j u s łu g o w o , co za g w a ra n to w a ło im a u to n o m ię i zapobiegło n a k ła d a n iu się ic h lo g ik i. (A n a liz ie z o rie n to w a n e j usługow o p o ś w ięca m y ro z d z ia ły 11. i 12.).

272

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

Rysunek 8.23. Usługi RailCo z powodzeniem enkapsulują określone porcje „spadkowej" i nowej logiki aplikacyjnej

PO PROSTU Przywołajmy ponownie trzy zadania wykonywane przez biuro koncesyjne w związku z przetwarzaniem nowej aplikacji: •

spraw dzenie proponowanej nazw y firmy,

•

spraw dzenie historii kredytow ej założycieli,

•

weryfikacja uprawnień lokalizacyjnych.

Biuro koncesyjne posiada bazę danych zaw ierającą nazw y wszystkich zarejestrowanych firm , zatrudnia także personel uprawniony do w izytow ania i w eryfikowania lokalizacji firm. Sprawuje zatem pełną kontrolę nad realizacją pierwszego i trzeciego z wym ienionych zadań. By je d n ak zw eryfiko w ać historię kredytow ą w n io sko d aw có w , musi sięgnąć (jako upraw niony do tego podm iot) do odpow iedniej bazy danych utrzym ywanej przez urząd skarbowy. W spółdzielenie tej bazy ogra­ nicza autonom ię biura koncesyjnego w kontekście drugiego z w ym ienionych zadań, pozostawia ją jednakże w kwestii wykorzystyw ania uzyskanych danych na potrzeby prow adzonej procedury koncesyjnej.

8 .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

273

8.3.7. Usługi są bezstanowe Projekt usługi powinien minimalizować zakres (czasowy i objętościowy) informacji o jej stanie. Informacja o stanie usługi to zestaw danych specyficznych dla aktywności, w której aktualnie usługa uczestniczy. Każda usługa traci na chwilę swój bezstanowy charakter, przetwarzając otrzymany kom unikat (patrz rysunek 8.24). Jeśli jednak usługa zmuszona jest utrzymywać informacje o sta­ nie przez dłuższy czas, jej dostępność dla potencjalnych usług-wnioskodawców staje się poważnie ograniczona.

Rysunek 8.2 4 . Stanowy i bezstanowy etap funkcjonowania usługi przetwarzającej komunikat

Bezstanowość usług jest ich preferowaną cechą, bo sprzyja osiąganiu przez nie wieloużywalności i skalowalności. Dla zminimalizowania utrzymywanej przez usługę informacji o stanie należy projektować jej operacje jako maksymalnie bezstanowe. Podstawowym środkiem zapewnienia usługom bezstanowości są kom unikaty w stylu doku­ mentowym. W im większą porcję inteligencji wyposażony jest taki komunikat, tym większą po­ siada niezależność i samowystarczalność. W rozdziałach 6. i 7. omawialiśmy różne rozszerzenia WS-* bazujące na używaniu nagłówków SOAP przenoszących różnorodne dane reprezentujące informację o stanie.

274

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

A N A LIZA PRZYPADKU

Podobnie jak luźne powiązanie, tak i bezstanowość m ożna mierzyć stopniami. Usługa RailCo R e a liz a c ja z a m ó w ie n ia w celu właściwego przetwarzania zamówień wysyłanych przez usługę

TLS Z le c e n ie z a k u p u zm uszona jest do parsowania i przetwarzania rozmaitych standardo­ wych bloków nagłówka SOAP. Jest więc związana informacją o stanie aktywności przez czas wyraźnie dłuższy niż (na przykład) usługa W y s ta w ie n ie f a k t u r y , po prostu przekazująca pre­ definiowany kom unikat SOAP usłudze księgowej TLS.

PO PROSTU Gdy złożyliśmy w niosek w biurze koncesyjnym, w ypełniony form ularz został w stępnie przeanalizow any przez personel biura, jego zaw artość w p ro w ad zo n a do systemu — i nie było potrzeby utrzym yw ania w pamięci faktu naszej w izyty. Ponieważ szczegóły naszego wniosku zarejestrowane zostały w różnych repozytoriach, nikt nie musiał ich dłużej pamiętać. W tym sensie biuro (i jego personel) przejawia pewien stopień bezstanowości. Przetwarza ono codziennie w ie le takich w n io skó w i pam iętanie szczegółów każdego z nich, po umieszczeniu ich w e w spom nianych repozytoriach, nie m iałoby w iększego sensu.

8.3.8. Usługi są wykrywalne Łatwość odnajdywania usług, zwana popularnie ich wykrywalnością, zapobiega przypadkowemu tworzeniu usług redundantnych lub usług im plem entujących redundantną logikę. Ponieważ każ­ da operacja reprezentuje potencjalnie wieloużywalną porcję logiki przetwarzania, m etadane sko­ jarzone z usługą powinny wystarczająco czytelnie opisywać nie tylko jej ogólne przeznaczenie, ale przede wszystkim funkcjonalność oferowaną przez jej operacje. Wykrywalność usług, jako jedna z zasad zorientowania na usługi, jest pokrewna wykrywalno­ ści rozumianej jako cecha współczesnej SOA, lecz od niej wyraźnie różna. Otóż, na poziomie SOA pojęcie wykrywalności oznacza zdolność architektury do zapewniania mechanizm u um oż­ liwiającego odnajdywanie usług — czyli na przykład rejestru usług lub ich katalogu. Odnosi się zatem do elementu infrastruktury IT implementującej SOA. N a poziomie pojedynczej usługi za­ sada wykrywalności odnosi się natom iast do takiego zaprojektowania tej usługi, by można ją było odnajdywać tak łatwo, jak to tylko możliwe.

A N A LIZA PRZYPADKU

Firm a RailCo nie dysponuje żadnym sposobem odnajdywania jej usług — ani lokalnie, ani z zewnątrz. Usługa W y s ta w ie n ie f a k t u r y , m im o iż wyposażona w definicję WSDL i w pełni zdolna do funkcjonow ania jako usługa-dostarczyciel, wykorzystywana jest głównie jako usługa-wnioskodawca, komunikująca się jedynie z usługą TLS P ła tn o ś ć n a k o n t o . Podobnie usługa RailCo R e a liz a c ja z a m ó w ie n ia , zarejestrowana ręcznie w systemie B2B firmy TLS jako upraw niona do przyjmowania zleceń zakupu, nie posiada cech wieloużywalności i jako taka nie m a żadnych wymagań pod względem jej wykrywalności.

8 .3 . P O D S T A W O W E ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI

275

W firmie TLS jest zgoła inaczej. Ze względu na wieloużywalną naturę jej usług, ich liczeb­ ność, zakres funkcjonalny oraz spodziewany wysoki stopień wykorzystywania uruchom iony został wewnętrzny rejestr usług (co pokazaliśmy na rysunku 8.25 i wcześniej wyjaśnialiśmy w rozdziale 5.). Rejestr ten jako element infrastruktury propaguje wykrywalność usług i za­ pobiega ich niezamierzonej redundancji. Efekt ten zostaje wzm ocniony przez czytelne do­ kum enty m etadanych jako wyraz zastosowania standardów projektowych.

Rysunek 8.2 5 . Usługi RailCo nie posiadają cech wykrywalności, natomiast w TLS inwentarz usług przechowywany jest w ich wewnętrznym rejestrze

Firma TLS nie jest zainteresowana publiczną wykrywalnością swoich usług, dlatego nie zarejestrowała ich w żadnym publicznym rejestrze. W spółpraca zainteresowanego dostawcy z systemem B2B wymaga odrębnego procesu rejestracyjnego.

PO PROSTU Nadszedł wreszcie ten dzień: otrzymaliśmy upragnioną koncesję i mogliśmy wreszcie powrócić do swych za­ jęć. Opisując w poprzednich historyjkach koleje losu całej procedury, pominęliśmy jeden drobny szczegół. Otóż, gdy dow iedzieliśm y się o konieczności uzyskania koncesji, musieliśmy odnaleźć regionalne biuro kon­ cesyjne — co też uczyniliśmy za pomocą książki teleadresow ej. Rejestr usług dostarcza mechanizm ich odnajdyw ania na podobnej zasadzie, ja k książka teleadresow a dostarcza spis abonentów , z którego można w ybrać żądaną pozycję. Tak jak rejestr usług udostępnia w skaź­ niki do ich opisów, tak książka teleadresow a udostępnia adresy konkretnych instytucji — w tym naszego re­ gionalnego biura koncesyjnego.

276

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

A nalogią zasady w ykrywalności usług mogą być rozm aite środki pomocnicze ułatw iające zainteresow anym petentom trafienie do biura koncesyjnego: m ow a tu na przykład o drogowskazach przy drogach prow adzą­ cych w okolice biura, tablicy informacyjnej w holu budynku czy w izytów ce na drzwiach sekretariatu.

P O D S U M O W A N IE •

Różne organizacje opublikow ały swe w łasne w ersje rozumienia „orientacji na usługi", nie istnieje w ięc żaden oficjalny zbiór zasad tej orientacji.

•

N ajw ażniejsze ze wspom nianych zasad odnoszą się do luźnego pow iązania usług, ich autonom ii, w ykrywalności, kom ponowalności, wieloużywalności, kontraktów , abstrahow ania i bezstanowości.

8.4. Jak pow iązane są zasady zo rientow ania na usługi? Dotychczasowa lektura tego rozdziału, ze względu na złożoność omawianych zagadnień, inspi­ rować może do zadawania różnych pytań. Oto przykłady. • Jaka jest różnica między wieloużywalnością a komponowalnością — czy angażując daną usługę jako składnik kompozycji, nie sprawiamy, że staje się wieloużywalna? • Jaka jest różnica między autonom ią usługi a jej bezstanowym charakterem — jedno i drugie jest przecież wykładnikiem niezależności usługi od pozostałych usług? • Jaka jest różnica między kontraktem usługi a jej luźnym powiązaniem z innymi usługami — czyż kontrakty nie im plem entują automatycznie luźnego powiązania? Na te i inne pytania oraz wątpliwości m ożna odpowiedzieć, szczegółowo porównując poszcze­ gólne zasady orientacji na usługi pod kątem tego, jak są nawzajem powiązane, w jakim stopniu sobie sprzyjają i jak nawzajem wpływają na siebie. Porównamy to w kolejnych punktach. Ich tytuły nieprzypadkowo zawierają słowo „usługa” w różnych przypadkach dla podkreślenia, że odnośne zasady odnoszą się jedynie do projektowania usług, nie do charakterystyki SOA jako całości.

UW AGA Ponieważ zaaranżow aliśm y nasze porów nanie w układzie poszczególnych cech, nie ich par, zestawienia nie­ których par cech pojaw ią się dw ukrotnie. To pow tórzenie jest zam ierzone, poniew aż ta część rozdziału ma charakter w ybitnie referencyjny. Czytelnicy niezainteresowani poszczególnymi porównaniam i mogą je pominąć bez szkody dla dalszej lektury.

8.4.1. Wieloużywalność usługi Usługę nazywamy wieloużywalną, jeżeli przejawia funkcjonalność użyteczną dla więcej niż jednej usługi-wnioskodawcy. Koncepcja wieloużywalności zbliżona jest do koncepcji wyrażanej przez inne zasady zorientowania na usługi — oto te zasady:.

8 .4 . JAK P O W IĄ Z A N E SĄ ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI?

•

277

A u t o n o m ia usługi ustanawia środowisko wykonawcze sprzyjające wieloużywalności,

ponieważ usługa ta jest niezależna i samozarządzająca. Im bardziej autonom iczna usługa, tym większe możliwości wielokrotnego wykorzystywania jej funkcjonalności. •

B e z s ta n o w o ś ć usługi sprzyja jej wieloużywalności, ponieważ maksymalizuje jej dostępność

dla usług-wnioskodawców. Ponadto projektowanie usługi jako bezstanowej promuje stosowanie generycznych wzorców, odkładających poza granice usługi zarządzanie inform acją specyficzną dla aktywności, w których usługa ta uczestniczy. •

A b s tra k c y jn o ś ć usługi czyni z niej rodzaj czarnej skrzynki, ukrywającej detale przetwarzania

przed usługami-wnioskodawcami i udostępniającej im jedynie to, co opublikowane jest w generycznym interfejsie. Generyczność to czynnik sprzyjający wieloużywalności. •

W y k r y w a ln o ś ć usługi ułatwia jej odnajdywanie wnioskodawcom poszukującym

•

L u ź n e p o w ią z a n ie między usługami ustanawia niezależność uwalniającą usługi od ścisłego

wieloużywalnych usług. związku z innym i usługami. Nienależność ta w znacznym stopniu ułatwia wielokrotne wykorzystywanie usług. Ponadto zasada wieloużywalności usług sprzyja realizacji innej zasady, czyli komponowalności. •

K o m p o n o w a ln o ś ć usług możliwa jest przede wszystkim dzięki ich wieloużywalności.

Możliwość kreowania złożonych usług, stanowiących w istocie kolekcje prostszych usług, staje się szczególnie opłacalna, gdy te prostsze usługi projektowane są z uwzględnieniem wieloużywalności. (Możliwe jest, oczywiście, tworzenie usług wyłącznie na potrzeby kompozycji, lecz generalnie wieloużywalność usług jest postrzegana jako ich zaleta). Opisane zależności przedstawiono na diagramie widocznym na rysunku 8.26.

Rysunek 8.2 6 . Wieloużywalność w relacji do innych zasad zorientowania na usługi

278

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

8.4.2. Kontraktowość usługi K o n tr a k t u s łu g i s ta n o w i re p re z e n ta c ję je j m e ta d a n y c h . W y r a ż a o n w s ta n d a rd o w e j f o r m ie re g u ły i w a r u n k i k o rz y s ta n ia z u s łu g i p rz e z p o te n c ja ln e u s łu g i-w n io s k o d a w c ó w . K o n tr a k ty u s łu g są k a ­ m ie n ie m w ę g ie ln y m całej k o n c e p c ji z o rie n to w a n ia n a u s łu g i, n ic w ię c d z iw n e g o , że w s p ie ra ją one — w r ó ż n y sposób — p o z o s ta łe za s a d y te j k o n c e p c ji. O to one. •

A b s tra k c y jn o ś ć u s łu g i re a liz o w a n a je s t z a p o m o c ą je j k o n tr a k tu , ja k o że z a w a rte w ty m k o n tra k c ie m e ta d a n e re p r e z e n tu ją je d y n ą in fo r m a c ję d o s tę p n ą d la p o te n c ja ln y c h w n io s k o d a w c ó w . W s z y s tk ie s z c ze g ó ły p r o je k to w a n ia , im p le m e n to w a n ia i lo g ik i p rz e tw a rz a n ia , n ie u w z g lę d n io n e w k o n tra k c ie , zo s ta ją p rz e d w n io s k o d a w c a m i u k ry te .

•

L u ź n e p o w ią z a n ie m ię d z y u s łu g a m i r e a liz o w a n e je s t w ła ś n ie w fo r m ie k o n tr a k tó w . S zc ze g ó ły lo g ik i p r z e tw a r z a n ia p o s z c z e g ó ln y c h u s łu g — te u k ry te p rz e d k o n tr a k te m — n ie p o w in n y p o z o s ta w a ć ze s obą w ż a d n y m z w ią z k u , p o n ie w a ż ta k o w y u s ta n a w ia łb y ścisły z w ią z e k m ię d z y t y m i u s łu g a m i. Jed y n ą f o r m ą z w ią z k u m ię d z y u s łu g a m i p o z o s ta je ś w ia d o m o ś ć ic h w y m a g a ń k o m u n ik a c y jn y c h , z a w a rty c h w o p is a c h s k ła d a ją c y c h się n a k o n tr a k ty .

•

K o m p o n o w a ln o ś ć u s łu g i r ó w n ie ż n ie m o ż liw a b y ła b y b e z k o n tr a k tu , b o za jeg o p o ś re d n ic tw e m u s łu g a -k o n tro le r p o d p o rz ą d k o w u je sobie, w łą c z a do k o m p o z y c ji i w y k o rz y s tu je tę usługę.

•

W y k r y w a ln o ś ć u s łu g i p o zo s ta je w ś c is ły m z w ią z k u z je j k o n tr a k te m . K o n tr a k ty usłu g r e p re z e n tu ją te u s łu g i w re je s tra c h i c h o c ia ż n ie k tó re re je s try u m o ż liw ia ją d o łą c za n ie u z u p e łn ia ją c y c h in fo r m a c ji n a te m a t re je s tro w a n y c h u s łu g , k o n tr a k ty p o zo s ta ją p o d s ta w o w y m ś ro d k ie m w y s z u k iw a n ia u s łu g s p e łn ia ją c y c h o k re ś lo n e k ry te ria .

R elacje k o n tr a k tó w u s łu g z in n y m i z a s a d a m i z o rie n to w a n ia n a u s łu g i ilu s tru je d ia g ra m z r y ­ s u n k u 8 .2 7 .

Rysunek 8.2 7 . Kontraktowość w relacji do innych zasad zorientowania na usługi

8 .4 . JAK P O W IĄ Z A N E SĄ ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI?

279

8.4.3. Luźne powiązanie usługi L u ź n e p o w ią z a n ie to stan u s łu g i o z n a c z a ją c y je j n ie za le żn o ś ć o d in n y c h u s łu g (d o k ła d n ie j — n ie ­ zależność u s łu g i-w n io s k o d a w c y o d usłu g i d o starczyciela i vice versa). Jak w cześniej w y ja ś n ia liś m y , niezależn o ś ć — a d o k ła d n ie j: b r a k u z a le ż n ie n ia — m ię d z y u s łu g a m i s ta n o w i fu n d a m e n ta ln y aspekt k a żd e j u słu g i i S O A ja k o całości. Z a te m zasada u trz y m y w a n ia lu źn e g o p o w ią z a n ia m ię d z y u s łu g a m i p rz y c z y n ia się do p ro p a g o w a n ia in n y c h zasad z o rie n to w a n ia n a usłu g i w sposób n astępujący. •

W ie lo u ż y w a ln o ś ć w s p ie ra n a je s t p rz e z lu ź n e p o w ią z a n ie , p o n ie w a ż o z n a c z a o n o b ra k p o w ią z a n ia ścisłego, k tó re o g ra n ic z a ło b y m o ż liw o ś c i w ie lo k ro tn e g o w y k o rz y s ty w a n ia u s łu g i.

•

K o m p o n o w a ln o ś ć u s łu g i jest w z n a c zn e j m ie rz e u ła tw io n a d z ię k i je j lu ź n e m u p o w ią z a n iu , z w ła s z c za w s y tu a c ji, g d y k o m p o z y c je usłu g b u d o w a n e są d y n a m ic z n ie .

•

B e z s ta n o w o ś ć u s łu g i w y n ik a b e z p o ś re d n io z je j lu źn e g o p o w ią z a n ia , b o to w y k lu c z a w p ra k ty c e m o ż liw o ś ć d łu g o trw a łe g o u tr z y m y w a n ia p rz e z usługę in fo r m a c ji o stanie a k ty w n o ś c i, w k tó re j u c ze s tn ic zy .

•

A u t o n o m ia u s łu g i je s t m o ż liw a d z ię k i lu ź n e m u p o w ią z a n iu , z z a ło ż e n ia m in im a liz u ją c e m u za le ż n o ś c i m ię d z y u s łu g a m i.

P o n a d to lu ź n e p o w ią z a n ie u s łu g i z in n y m i u s łu g a m i je s t b e z p o ś re d n ią k o n s e k w e n c ją za s to ­ s o w a n ia in n e j p o w ią z a n e j zasady. O to o n a. •

K o n t r a k t y u s łu g są ty m c z y n n ik ie m , d z ię k i k tó r e m u im p le m e n ta c ja lu źn e g o p o w ią z a n ia staje się w ogóle m o ż liw a . K o n tr a k ty te z a w ie ra ją in fo rm a c ję n ie z b ę d n ą do n a w ią z y w a n ia in te ra k c ji m ię d z y u s łu g a m i w ra m a c h tego p o w ią z a n ia .

P o w yższe z a le żn o ś c i w id o c z n e są n a ry s u n k u 8 .2 8 .

Rysunek 8.2 8 . Luźne powiązanie w relacji do innych zasad zorientowania na usługi

2S0

RO ZD ZIAŁ S. a ZASADY ORIENTACJI N A USŁUGI

B.4.4. Abstrakcyjność usługi Jednym z aspektów budowania rozwiązań na bazie niezależnych usług jest możliwość powierze­ nia tym usługom skomplikowanej często logiki, która jednak udostępniana będzie na zewnątrz za pośrednictwem generycznych i czytelnych interfejsów. To podstawowa zaleta abstrakcyjności usług — zasady zorientowania na usługi powiązanej z innymi zasadami w następujący sposób. s K o n t r a k t y usług z założenia im plem entują abstrakcyjność tych usług, bo każdy z nich

stanowi oficjalną informację opisową usługi udostępnianą na zewnątrz i oddzieloną („abstrahowaną”) od szczegółów jej wewnętrznej logiki. s

W ie lo u ż y w a ln o ś ć jest pochodną abstrakcyjności, o ile informacja udostępniana na zewnątrz

przez usługę posiada cechy wieloużywalności. Zależności te pokazano na rysunku 8.29.

Rysunek B.29. Abstrakcyjność w relacji do innych zasad zorientowania na usługi

8.4.5. Komponowalność usługi Projektowanie usług z uwzględnieniem możliwości ich kom ponow ania przez inne usługi jest kwestią fundam entalną dla rozwiązań zorientowanych na usługi. Zasada komponowalności usług powiązana jest z innymi wspierającymi ją zasadami zorientowania na usługi w sposób następujący. •

W ie lo u ż y w a ln o ś ć usługi jest czynnikiem ułatwiających jej wykorzystywanie w różnych

•

L u ź n e p o w ią z a n ie tworzy framework komunikacyjny wspierający koncepcję dynamicznego

kompozycjach, niezależnie przez wiele usług-wnioskodawców. kom ponowania usług. Usługi nieuwikłane w krępujące uzależnienia łatwiej dają się komponować z dowolnymi innymi. •

B e z s ta n o w o ść jest dla komponowalności usługi cechą wręcz niezbędną, zwłaszcza w przypadku

dużych kompozycji. Jakość kompozycji zależna jest od jakości zaprojektowania jej usług składowych oraz ich zdolności do współdziałania z innymi usługami. Jeśli wszystkie usługi tworzące kompozycję zaprojektowane są jako bezstanowe (bo na przykład obarczają kom unikaty całością informacji specyficznej dla aktywności), cała kompozycja może funkcjonować bardziej harmonijnie.

8 .4 . JAK P O W IĄ Z A N E SĄ ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI?

•

281

A u t o n o m ia każdej z usług tworzących kompozycję ułatwia budowanie takiej kompozycji;

zauważmy, że usługa-kontroler jest uzależniona od innych usług uczestniczących w kompozycji, więc jej naturalna autonomia zostaje w tym kontekście wyraźnie ograniczona. •

K o n t r a k t y usług tworzących kompozycję formalizują warunki współdziałania między nimi

w czasie istnienia tej kompozycji. Zależności te przedstawiono na rysunku 8.30.

Rysunek 8.3 0 . Komponowalność w relacji do innych zasad zorientowania na usługi

8.4.6. Autonomia usługi Autonom ia usługi odnosi się do jej wewnętrznej logiki. Fakt sprawowania wyłącznej kontroli nad tą logiką m a związek z innym i zasadami zorientowania na usługi. Oto one. •

W ie lo u ż y w a ln o ś ć usługi łatwiej osiągnąć, gdy usługa oferująca wieloużywalną logikę sprawuje wyłączną kontrolę nad swą logiką prywatną. W ymagania typu SLA (S ervice L e v e l A g re e m e n t ), między innym i dostępność i skalowalność, dotyczące usług użytkowych wykorzystywanych przez wielu wnioskodawców realizowane są łatwiej przez usługi autonomiczne.

•

K o m p o n o w a ln o ś ć usługi także jest wspierana przez jej autonomię — z tych samych mniej

więcej powodów, dla których autonom ia wspiera wieloużywalność. Kompozycja składająca się z autonom icznych usług jest solidna i łatwiej poddaje się kontroli. •

B e z s ta n o w o ś ć usługi łatwiej osiągnąć, gdy usługa ta może wykonywać się niezależnie od

innych; autonom ia przyczynia się więc pośrednio do bezstanowości (choć równie łatwo m ożna tworzyć usługi stanowe zachowujące pełną autonomię). •

A u t o n o m ię usługi trudno byłoby osiągnąć, gdyby nie jej lu ź n e p o w ią z a n ie z innymi

usługami. Diagram na rysunku 8.31 uwidacznia autonom ię usług na tle innych zasad zorientow ania na usługi.

282

RO ZD ZIAŁ 8 . ■ ZASADY ORIENTACJI N A USŁUGI

Bezstanowość usługi

Komponowalność usługi

Zwiększa jakość

Ułatwia

v Umożliwia

Dostarcza środowiska wykonawczego wiodącego dla

Luźne powiązanie usługi

Wieloużywalność usługi

Rysunek 8.3 1 . Autonomia w relacji do innych zasad zorientowania na usługi

8.4.7. Bezstanowość usługi Z a p ro je k to w a n ie u s łu g i ja k o b e z s ta n o w e j o z n a c z a k o n ie c zn o ś ć u p o ra n ia się z p ro b le m e m z a rz ą ­ d z a n ia s ta n e m z a s o b ó w w y k o rz y s ty w a n y c h p rz e z lo g ik ę u s łu g i p o p rz e z d e le g o w a n ie o w e g o z a ­ rz ą d z a n ia p o z a g ra n ic e tej u s łu g i. N ie z a le ż n ie o d tego zasada b e z s ta n o w o ś c i u s łu g w s p ie ra n a jest p o ś re d n io p rz e z n as tęp u ją ce za s a d y z o r ie n to w a n ia n a u sługi. •

A u t o n o m ia u s łu g i p o z w a la je j w p e łn i k o n tr o lo w a ć w ła s n e ś ro d o w is k o w y k o n a w c z e . D z ię k i e lim in o w a n iu lu b r e d u k o w a n iu z a le ż n o ś c i m ię d z y u s łu g a m i ła tw ie j re a liz o w a ć w s p o m n ia n ą d e le g a c ję z a r z ą d z a n ia s ta n e m z a s o b ó w u s łu g i, c z y li n a d a w a ć te j u s łu d z e cechę b e z s ta n o w o ś c i.

•

L u ź n e p o w ią z a n ie u s łu g i ( i o g ó ln ie cała k o n c e p c ja lu źn e g o p o w ią z a n ia ) u s ta n a w ia p a ra d y g m a t k o m u n ik a c y jn y o p a rty c a łk o w ic ie n a w y m ia n ie k o m u n ik a tó w . W b u d o w y w a n ie w k o m u n ik a ty całości in fo r m a c ji z a le ż n e j o d s ta n u u s łu g i u s u w a z je j g ra n ic u z a le ż n ie n ie o d b ie żą c e g o s ta n u a k ty w n o ś c i, w k tó re j u s łu g a ta u c ze s tn ic zy .

S am a zaś zasada b e zs ta n o w o ś c i z a p e w n ia w s p a rc ie d la n a s tę p u ją c y c h zasad. •

T w o rz e n ie k o m p o z y c ji z u s łu g b e z s ta n o w y c h re d u k u je w e w n ę trz n e za le ż n o ś c i w ra m a c h tej k o m p o z y c ji i u ła tw ia z a rz ą d z a n ie n ią . B e zs ta n o w o ś ć u s łu g i je s t w ię c k o rz y s tn a d la je j k o m p o n o w a ln o ś c i.

•

W ie lo u ż y w a ln o ś ć u s łu g i staje się b a rd z ie j re a ln a w p rz y p a d k u u s łu g i b e z s ta n o w e j, b o u w o ln ie n ie u s łu g i o d in fo r m a c ji s p e c y fic zn e j d la b ie żą c e j a k ty w n o ś c i s p ra w ia , że u s łu g a je s t b a rd z ie j d o s tę p n a d la p o te n c ja ln y c h w n io s k o d a w c ó w , a je j p r o je k t b a rd z ie j g e n e ry c z n y .

O p is a n e re lacje w id o c z n e są n a ry s u n k u 8 .3 2 .

8 .4 . JAK P O W IĄ Z A N E SĄ ZA SA D Y Z O R IE N T O W A N IA N A USŁUGI?

283

Rysunek B.32. Bezstanowość w relacji do innych zasad zorientowania na usługi

B.4.B. Wykrywalność usługi P ro je k to w a n ie usłu g i ja k o n a tu ra ln ie w y k ry w a ln e j zw ię k s za g ro n o p o te n c ja ln y c h w n io s k o d a w c ó w z a m ie rz a ją c y c h w y k o rz y s ty w a ć lo g ik ę e k s p o n o w a n ą p rz e z tę u sługę. Z w y k o r z y s ty w a n ie m ty m z w ią z a n e są ściśle n as tę p u ją ce za s a d y z o r ie n to w a n ia n a u s łu g i. s K o n t r a k t y u sług s ta n o w ią z a s a d n ic z y ś ro d e k id e n ty fik o w a n ia fu n k c jo n a ln o ś c i ty c h u sług n a u ż y te k p o te n c ja ln y c h u s łu g -w n io s k o d a w c ó w (lu b w ła ś c ic ie li ty c h u s łu g ) o ra z p o d s ta w ę ew en tu aln ej in te ra k c ji z ty m i w n io s k o d a w c a m i. Jakość k o n tra k tu danej usługi — w ro z u m ie n iu je g o c zy te ln o ś c i i re p re z e n ta ty w n o ś c i — p rz e s ą d za w ię c o s to p n iu w y k ry w a ln o ś c i te j u s ługi. s

W ie lo u ż y w a ln o ś ć u s łu g i to je d n o z n a jw a ż n ie js z y c h k r y te r ió w o c e n y p rz y d a tn o ś c i te jże u s łu g i d la p o te n c ja ln y c h w n io s k o d a w c ó w w pro cesie sele k c ji o d n a le z io n y c h k a n d y d a tu r. U s łu g i n ie p o s ia d a ją c e cec h y w ie lo u ż y w a ln o ś c i — o ile w o góle re p re z e n to w a n e są w re je s tra c h u słu g — p rz e z d o m n ie m a n ie tra k to w a n e są ja k s tw o rz o n e n a u ż y te k k o n k re tn e g o w n io s k o d a w c y i ja k o ta k ie n ie p rz e ja w ia ją sp e c ja ln e j a tra k c y jn o ś c i z p e rs p e k ty w y ic h p u b lic z n e g o w y k o rz y s ty w a n ia .

O p is a n e p o w ią z a n ia z ilu s tro w a n o n a ry s u n k u 8 .3 3 .

Rysunek 8.3 3 . Wykrywalność w relacji do innych zasad zorientowania na usługi

2S4

RO ZD ZIAŁ S. a ZASADY ORIENTACJI N A USŁUGI

P O D S U M O W A N IE

s Zasady zorientow ania na usługi nie egzystują w izolacji od siebie, lecz są pow iązane i w spierają się naw zajem w różnorodny sposób.

s Niektóre zasady, takie ja k w ieloużyw alność i kom ponowalność usług, są przedm iotem wsparcia ze strony innych zasad.

s Inne zasady, takie jak luźne pow iązanie, kontraktowość i autonom ia usług, zapew niają znaczące w sparcie dla pozostałych zasad.

8.5. Orientacja na usługi oraz orientacja na obiekty (część II) Skoro poznaliśmy już podstawy zasad zorientowania na usługi i różnorodne powiązania istniejące między nimi, powróćmy do konfrontacji tych zasad z zasadami zorientowania obiektowego, którą to konfrontację rozpoczęliśmy w rozdziale 4., w punkcie „Orientacja na usługi oraz orientacja na obiekty (część I)”. Czytelnicy znający dobrze analizę i projektowanie zorientowane obiektowo, zidentyfikują za­ pewne wiele podobieństw między powszechnymi zasadami zorientowania obiektowego a zasa­ dam i zorientow ania na usługi. To nie przypadek, bo zasady zorientow ania na usługi wiele za­ wdzięczają koncepcjom i teorii ze świata obiektów. Najważniejsze podobieństwa i różnice między nim i zestawiliśmy w tabeli 8.1. Tabela 8.1. Poglądowe zestawienie najważniejszych relacji między zasadami zorientowania na usługi a zasadami zorientowania obiektowego Z a sad a z o rie n to w a n ia . . na usługi

„ . . ■ * P o w ią za n a zasa d a z o rie n to w a n ia o b ie k to w e g o n 3

W ieloużyw alność

Świat orientacji obiektow ej k o n c en tru je się w w iększości w okół tw orzenia w ieloużyw alnych klas. Z asada m o d u la rn o śc i u stanaw ia dekom pozycję jako je d n ą ze standardow ych te c h n ik projektow ania. Powiązane zasady orientacji obiektowej — abstrakcja i enkapsulacja — skutkują rozdzieleniem interfejsu od im plem entacji i przyczyniają się w ten sposób do wieloużywalności klas. W ieloużyw alność usług stanow i kontynuację tej idei.

K ontraktow ość

K o n trak ty u słu g są ty m dla rozw iązań zorien to w an y ch n a usługi, czym interfejsy klas dla aplikacji zorien to w an y ch obiektow o. P o d o b n ie ja k definicje W SDL, tak interfejsy klas realizują abstrakcyjność, czyli oddzielenie logiki upublicznianej od ukryw anej w ew nętrznej logiki im plem entacyjnej. I, p o d o b n ie jak podejście „najpierw W SD L” n a gruncie SOA, ta k podejście „najpierw interfejs” jest zalecaną p rak ty k ą p ro jek to w ą w o d n iesien iu do klas.

L uźne pow iązanie

M im o iż interfejsy klas w pew nym sto p n iu oddzielają klasę o d jej ko n su m en tó w , to w tym m iejscu orientacja usługow a rozm ija się w yraźnie z orientacją obiektową. O tóż, relacja dziedziczenia klas, w p o łąc ze n iu z in n y m i zasadam i orientacji obiektow ej, u stanaw ia dość ścisłe pow iązanie m iędzy klasam i jako jed n o stk a m i logiki p rzetw arzania, k o n trastu ją ce z luźnym p o w iązaniem m iędzy usługam i.

8 .5 . O RIEN TA C JA N A USŁUGI O RAZ O R IEN TA C JA N A O BIEKTY (CZĘŚĆ II)

285

Tabela 8.1. Poglądowe zestawienie najważniejszych relacji między zasadami zorientowania na usługi a zasadami zorientowania obiektowego — ciąg dalszy Z a sad a z o rie n to w a n ia na usługi A bstrakcyjność

P o w ią za n a zasa d a z o rie n to w a n ia o b ie k to w e g o Z asad a a b strah o w a n ia n a g ru n c ie o rien tac ji obiektow ej oznacza, że logika klasy d o stę p n a je st dla św iata z ew n ętrzn eg o za p o śre d n ic tw e m jej interfejsu. Z asad a en k ap su la cji n a k azu je n a to m ia s t k lasie uk ry cie jej w ew n ętrzn ej logiki im p lem en tacy jn ej. W p ro jek to w a n iu usługi w p o d o b n y sposób jej logika u d o stę p n ia n a p otencjalnym w nioskodaw com oddzielona jest o d u krytej logiki w ew nętrznej, co stanow i analogię do obiektow ych zasad ab strahow ania i enkapsulacji.

K om ponow alność

E lem entem orientacji obiektow ej są k oncepcje asocjacyjne — agregacja i kom pozycja. W kontekście luźnego pow iązania analogiczne koncepcje obow iązują n a gru n cie p ro jek to w an ia usług. Przykładow o hierarchia klas ustanaw iana przez relację ich dziedziczenia m oże być u w ażana za hierarchię u sług ustanaw ianą poprzez b udow anie ich kom pozycji.

A u to n o m ia

Z aleta a u to n o m ii uw idacznia się w yraźniej n a g runcie z o rien to w an ia n a usługi niż w świecie orientacji obiektow ej. P o zio m niezależności usług, wynikającej z ich luźnego pow iązania, jest w yraźnie w iększy o d a u to n o m ii klas, pow ażnie ograniczonej p rzez relację dziedziczenia i o dw ołania m iędzyobiektow e.

B ezstanow ość

O biekt, jako połączenie definicji klasy z k o n k re tn y m i w artościam i jej atrybutów , jest ucieleśnieniem przechow yw ania in fo rm acji zw iązanej ze stanem środow iska, co stanow i zaprzeczenie zasady bezstanow ości, charakterystycznej dla orientacji n a usługi. I choć m ożliw e jest tw orzenie obiektów b ezstanow ych (p o d o b n ie ja k tw orzenie u słu g stanow ych), to n a gru n cie orientacji obiektow ej m ożliw ość ta nie jest e ksponow ana w tak im sto p n iu jak zasada bezstanow ości n a gruncie p ro jek to w an ia usług.

W ykryw alność

Projektow anie interfejsów klas w sposób spójny, czytelny i sam o d o k u m en tu jący to kolejna z zalecanych p ra k ty k p ro jek to w an ia klas, zm ierzająca do lepszej identyfikacji i rozró żn ialn o ści jed n o ste k logiki p rzetw arzania. Przyczynia się ona rów nież do większego sto p n ia w ieloużyw alności klas. N a g runcie p ro jek to w an ia usłu g w ykryw alność m a je d n a k znaczenie o wiele większe. Czytelne i k o m u n ik aty w n e k o n tra k ty u słu g m ają pierw szorzędne zn aczen ie dla w ykryw ania ty ch u słu g statycznie (p rzy p ro je k to w a n iu p o te n c ja ln y c h u słu g -w n io sk o d aw có w ) i d y n a m ic zn ie (w czasie trw ający ch aktyw ności).

Jak pokazuje codzienna praktyka, orientacja na usługi i orientacja obiektowa niekoniecznie muszą być postrzegane jako konkurencyjne paradygmaty. Orientacja na usługi tkwi wieloma swymi korzeniami w orientacji obiektowej, a większość współczesnych rozwiązań zorientowa­ nych na usługi stanowi mieszankę obu wymienionych paradygmatów — usług (zgodnych z zasa­ dami orientacji) i kom ponentów zorientowanych obiektowo. Właściwe spożytkowanie zalet obu koncepcji i sprawienie, by nawzajem się w projekcie dopełniały, jest kwestią umiejętnego wywa­ żenia proporcji tego projektu.

2S6

RO ZD ZIAŁ S. a ZASADY ORIENTACJI N A USŁUGI

P O D S U M O W A N IE •

W iele zasad zorientow ania na usługi ma sw e korzenie w zasadach orientacji obiektow ej i wyraźnie w iąże się z nimi.

•

N iektóre zasady zorientow ania obiektow ego — takie ja k dziedziczenie — nie mają odzwierciedlenia na gruncie zorientow ania na usługi.

•

Podobnie, niektóre zasady zorientow ania na usługi — takie ja k luźne pow iązanie czy autonom ia — nie mają odpow iedników na gruncie orientacji obiektow ej.

8.6. N atyw n e w sparcie dla zasad zo rientow ania na usługi ze strony usług sieciowych Spoglądając na obraz zasad zorientowania na usługi na pewnym stopniu szczegółowości, nietrud­ no zauważyć, że niektóre z tych zasad znajdują bezpośrednie wsparcie w technologii usług siecio­ wych. Jest więc pożądane bardziej szczegółowe rozpoznanie, które ze wspomnianych zasad wbu­ dowane są w platformę usług sieciowych, bo w ten sposób możemy zidentyfikować pozostałe — czyli te, których realizacja na owej platformie wymaga szczególnego wysiłku ze strony projektantów. W tabeli 8.2 zilustrowaliśmy opisany związek, wyjaśniając dla każdej z zasad zorientowania na usługi stopień jej natywnego wsparcia ze strony usług sieciowych. Tabela 8.2 Analiza natywnego wsparcia dla zasad zorientowania na usługi ze strony platformy usług sieciowych Z a sad a z o rie n to w a n ia na usługi W ieloużyw alność

W sp arcie ze strony usług sieciow ych U sługi sieciowe n ie są w ieloużyw alne sam e z siebie. Ich w ieloużyw alność w ynika z enkapsulow anej i udo stęp n ian ej p rzez n ie logiki.

K ontraktow ość

U sługi sieciowe fu n k cjo n u ją w o p arciu o opisy usług, zatem k o ntraktow ość u słu g jest fu n d a m e n te m kom u n ik acji u słu g sieciowych.

L uźne pow iązanie

U sługi sieciowe są n a tu ra ln ie lu źn o pow iązane, ze w zględu n a w ykorzystyw anie opisów usług.

A bstrakcyjność

U sługi sieciowe au tom atycznie em ulują m o d el czarnej skrzynki w ra m a ch swego fram e w o rk u kom unikacyjnego, skryw ając detale swej w ew nętrznej logiki.

K om ponow alność

U sługi sieciowe są z n a tu ry kom p o n o w aln e, jed n a k sto p ień kom p o n o w aln o ści kon k retn ej usługi z d eterm in o w a n y jest g eneralnie p rzez p ro jek t tej usługi i stopień w ieloużyw alności reprezentow anej p rzez n ią logiki.

A u to n o m ia

Zapewnienie autonom icznego środowiska wykonywania usługi sieciowej wymaga osobnych zabiegów projektowych, gdyż usługi sieciowe nie są z natury autonom iczne.

B ezstanow ość

Bezstanow ość jest p refero w an ą cechą u słu g sieciowych, usilnie p ro p ag o w an ą p rzez wiele specyfikacji W S-* i m o d el k o m u n ik acy jn y o p a rty n a k o m u n ik a tac h SOAP w stylu dokum entow ym .

W ykryw alność

W ykryw alność u słu g m u si zostać z aim p lem en to w an a w ra m a ch architektury, być m oże naw et jako rozszerzenie in fra stru k tu ry IT, bo n ie jest naty w n ą cechą p latfo rm y u słu g sieciowych.

8 .6 . N A T Y W N E W SPA R C IE D LA ZA SA D Z O R IE N T O W A N IA N A USŁUGI ZE STRO NY USŁUG SIEC IO W YC H

287

Jak w ię c w id a ć , a ż p o ło w a zasad z o rie n to w a n ia n a u s łu g i z n a jd u je o d z w ie rc ie d le n ie w n a tu rz e usług sieciow ych. F a kt te n jest o b ra ze m udanego m a ria ż u S O A z tec h n o lo g ią usług sieciow ych i w iele w y ja ś n ia w k w e s tii, dlaczeg o u s łu g i s ie c io w e o d n io s ły ta k i sukces ja k o p la tfo r m a re a liz a c ji S O A . Jak r ó w n ie ż w id a ć , z a le d w ie p o ło w a zasad z o rie n to w a n ia n a u s łu g i z n a jd u je o d z w ie rc ie d le n ie w n a tu rz e u s łu g s ie c io w y c h . T o o z n a c z a , że p r z y p r o je k to w a n iu r o z w ią z a ń z o r ie n to w a n y c h n a u słu g i szczególną uw agę n a le ż y p o św ięcić c z te re m p o n iż s z y m za s a d o m , p o z b a w io n y m w s p o m n ia ­ nego o d z w ie rc ie d le n ia , czyli: •

w ie lo u ż y w a ln o ś c i,

•

a u to n o m ii,

•

b e zs ta n o w o ś c i,

•

w y k ry w a ln o ś c i.

W ro z d z ia ła c h o d 11. do 15., p o ś w ię c o n y c h s z c ze g ó ło w e m u o m ó w ie n iu m o d e lo w a n ia usług, p rz e d s ta w ia m y w s k a z ó w k i p o m o c n e w u p e w n ie n iu się, że te is to tn e z a s a d y z o s ta ły w z ię te p o d u w ag ę p r z y tw o rz e n iu u s łu g p rz e z n a c z o n y c h do fu n k c jo n o w a n ia w ra m a c h S O A . T o , że c z te ry za s a d y z o rie n to w a n ia n a u s łu g i z n a jd u ją sw e b e z p o ś re d n ie o d z w ie rc ie d le n ie n a p la tfo rm ie u słu g s ie c io w y c h , n ie o z n a c z a w c a le , iż a u to m a ty c z n ie b ę d ą o n e w ła ś c iw ie im p le m e n ­ to w a n e . P rz y k ła d o w o fa k t, że u s łu g i s ie c io w e b a z u ją n a w y k o rz y s ty w a n iu k o n tr a k tó w u sług, n ija k n ie w p ły w a n a sposób p r o je k to w a n ia i ( w e fe k c ie ) ja k o ś ć p o s z c z e g ó ln y c h o p is ó w u sług. T ę w a ż n ą te m a ty k ę ró w n ie ż u w z g lę d n ia m y w e w s p o m n ia n y c h ro z d z ia ła c h . P O D S U M O W A N IE

s Abstrakcyjność, kom ponowalność, luźne pow iązanie i w ym óg stosowania kontraktów usług to natyw ne cechy usług sieciowych w pełni zgodne z analogicznych zasadam i zorientow ania na usługi.

s W ieloużyw alność, autonom ia, bezstanowość i wykryw alność to zasady zorientow ania na usługi nieposiadające natyw nego odzwierciedlenia na platform ie usług sieciowych. Ich realizacja w ym aga w ięc specjalnych w ysiłków związanych z m odelow aniem i projektow aniem .

UW AGA W ięcej szczegółowych informacji na tem at zasad projektow ania zorientow anego na usługi znajdą czytelnicy na stronach www.soaprinciples.comi www.servicetechbooks.com/ , a także na stronie www.soaposters.com, na której zobaczyć można (i pobrać) kolorowy plakat ilustrujący istotę poszczególnych zasad zorientowania na usługi. Polecamy również stronę www.soapatterns.org, poświęconą wzorcom projektowania usług sieciowych.

288

ROZDZIAŁ 8. ■ ZASADY ORIENTACJI NA USŁUGI

Rozdział 9

Warstwy usług 9.1. Zorientowanie na usługi a współczesna SOA 9.2. Usługowe warstwy abstrakcji 9.3. W arstwa usług aplikacyjnych 9.4. W arstwa usług biznesowych 9.5. W arstwa orkiestracji usług 9.6. Agnostycyzm usług 9.7. Scenariusze konfiguracji warstwy usług

290

RO ZD ZIAŁ 9 . ■ W A R S T W Y USŁUG

Omawiane w poprzednim rozdziale zasady i koncepcje zorientowania na usługi są fundamentalne dla definicji SOA i odróżniają SOA od innych platform architektonicznych, jednakże wciąż są tylko teorią. By urzeczywistnić je pod postacią faktycznych rozwiązań automatyzacyjnych, musimy stwo­ rzyć środowisko pozwalające wcielić w życie te fundamentalne zasady. W ielokrotnie już wspominaliśmy, że środowisko takie oferuje framework usług sieciowych. Aby więc zaimplementować orientację na usługi jako wsparcie dla charakterystyki współczesnej SOA — ze wszystkimi pożytkami, o których pisaliśmy w rozdziale 3. — potrzebujemy środków do propagacji i koordynowania orientacji na usługi w skali całego przedsiębiorstwa. Cel ten reali­ zuje się za pom ocą warstw abstrakcji usług. Rozdział niniejszy jest poświęcony strukturalizacji i wdrażaniu specjalizowanych warstw usług poprzez realizację kluczowych cech współczesnej SOA. A n a l i z y p r z y p a d k ó w : W tym rozdziale rów nież kilkakrotnie odw iedzim y znajom e firm y

RailCo i TLS, by przyjrzeć się działającym w nich usługom z perspektyw y tw orzonych przez nie w arstw abstrakcji.

9.1. Zorientow anie na usługi a współczesna SOA Współczesna SOA to złożona, wyrafinowana platforma architektoniczna, przejawiająca znaczący potencjał w zakresie rozwiązywania problemów związanych z infrastrukturą IT — zarówno tą tradycyjną, jak i tą tworzoną na bazie nowych technologii. Potencjał ten jest niewątpliwie konse­ kwencją wykorzystywania istniejących paradygm atów i technologii, kreujących ogólną wizję współczesnej SOA, jego spożytkowanie jest jednak kwestią dogłębnej analizy i właściwie ukierun­ kowanego projektowania. Jak pokazano na rysunku 9.1, trzema głównymi czynnikami kształtującymi oblicze współczesnej SOA są: • koncepcje pierwszej generacji usług sieciowych (omawiane w rozdziale 5.), • koncepcje drugiej generacji usług sieciowych, na czele z rozszerzeniami WS-* (poświęciliśmy im rozdziały 6. i 7.), • zasady zorientowania na usługi (te omawialiśmy szczegółowo w rozdziale 8.). Oczywiście, jeszcze wiele innych czynników nie pozostało bez wpływu na kształt współczesnej SOA, że wymienimy tylko standard XML, stanowiący fundam ent zarówno SOA, jak i usług sie­ ciowych. W tym rozdziale ograniczymy się jednak do trzech wcześniej wymienionych. Aby w pełni wykorzystać wspomniany potencjał, musimy wpierw zrozumieć genealogię cha­ rakterystyki SOA; wiedza ta pozwoli poznać wewnętrzne mechanizmy napędzające fundamentalne aspekty SOA, a ponadto — co ważniejsze — wskaże te elementy współczesnej SOA, które muszą być zaimplementowane explicite i o poprawności zaimplementowania których będziemy musieli przekonać się za pom ocą odpowiednich technik analizy i projektowania.

9 .1 . Z O R IE N T O W A N IE N A USŁUGI A W S PÓ ŁC ZESN A SOA

291

Rysunek 9.1. Czynniki zewnętrzne kształtujące i wspierające współczesną SOA

9.1.1. Charakterystyka współczesnej SOA a jej genealogia i zasoby wspomagające W rozdziale 3. w ym ieniliśm y konkretne cechy, pow szechnie kojarzone ze współczesną SOA. Reprezentują one zarówno aktualny etap rozwoju tej platformy, jak i oczekiwania oraz prognozy wiązane z tym rozwojem, ale są także odzwierciedleniem postępu technologii opracowywanych na potrzeby tego rozwoju. Skoro zidentyfikowaliśmy trzy główne czynniki odpowiedzialne za aktualny kształt SOA, poucza­ jącym zapewne będzie skonfrontowanie dwóch z tych czynników z poszczególnymi cechami współ­ czesnej SOA, za które to cechy są odpowiedzialne lub przynajmniej w pewien sposób z nimi powiąza­ ne. W ten prosty sposób uwidocznimy te cechy współczesnej SOA, których związek ze wspomnianymi czynnikami jest znikomy lub żaden i które z tego względu stają się przedmiotem szczególnej troski na etapie analizy i projektowania usług. W tabeli 9.1 zamieszczamy zatem stosowne porównanie. Tabela 9.1. Wpływ ustug sieciowych i zasad orientacji na usługi na charakterystykę współczesnej SOA Cecha ch arak terys tyczn a

G e n e a lo g ia i (lu b ) źró d ło w s p a rc ia

F u n d a m en ta ln a a u to n o m ia

A u to n o m ia to je d n a z rd zen n y ch zasad o rientacji n a usługi, k tó rą stosow ać m o żn a do różnych części SOA. Z apew nienie au to n o m ii b udo w an y ch i k o m p o n o w a n y ch u słu g przyczynia się do realizacji w ielu in n y ch cech SOA.

B azow anie n a otw artych

W spółczesna SO A opiera swą egzystencję n a p latfo rm ie u słu g sieciow ych

stan d ard ach

i coraz bogatszej kolekcji zw iązanych z tą p latfo rm ą specyfikacji WS-*. Z n ak o m ita w iększość tych specyfikacji m a c h a ra k te r o tw arty i niezależna jest o d k o n k re tn y c h dostaw ców .

Podw yższanie jakości usług

Przyczynek SOA do p o p ra w y jakości u słu g to w głów nej m ierze zasługa im p lem en tacji w ielu rozszerzeń WS-*.

K om ponow alność

K om ponow alność to je d n a z fu n d a m e n ta ln y ch zasad z o rien to w an ia n a

architektoniczna

usługi; w o d niesieniu do a rch ite k tu ry oznacza ona je d n a k technologię z d o ln ą do fizycznej realizacji (lu b co n ajm niej w sparcia) tej zasady. Specyfikacje tw orzące św iat rozszerzeń W S-* w w iększości tę zasadę realizują, pozw alając n a im p lem en to w an ie w danej arch itek tu rze tylko ty ch rozszerzeń, k tó re są dla niej rzeczyw iście niezbędne.

292

R O ZDZIAŁ 9 . ■ W A R S T W Y USŁUG

Tabela 9.1. Wpływ ustug sieciowych i zasad orientacji na usługi na charakterystykę współczesnej SOA — ciąg dalszy Cecha ch arakterystyczna

G en e alo g ia i (lub) źród ło w sparcia

Z różnicow anie

To raczej konsekw encja w ielu zalet SOA niż k o n k retn a cecha jej charakterystyki;

dostaw ców

tak czy inaczej, uniezależnienie od konkretnego dostawcy wynika przede wszystkim z otw artych standardów , n a których opiera się p latform a usług sieciowych.

N a tu raln a

S tandardow y fram ew o rk k o m u n ik acy jn y d o starczan y p rz ez u sługi sieciowe

interoperacyjność

stw arza nieo g ran iczo n e w ręcz m ożliw ości w zakresie w spółdziałania usług. Rzeczyw iste w ykorzystanie tych m ożliw ości w ym aga je d n a k starannych przem yśleń i w y b o ru dobrych sta n d ard ó w projektow ych. Jakkolw iek k o ncepcja intero p eracy jn o ści w sp ieran a jest p rzez wiele specyfikacji W S-*, to jed n a k n ie w ydaje się być b ezpośrednio zw iązana z k tó ry m ś z tytułow ych czynników .

W ykryw alność

Im plem entacja w ram ach SOA tej jednej z najw ażniejszych zasad zorientow ania n a usługi w ym aga użycia tech n o lo g ii katalogow ych, tak ic h ja k U D D I (to jeden ze sta n d ard ó w u słu g sieciow ych pierw szej generacji).

Federacyjność

Federacja to stan będący rezultatem rozciągnięcia SO A n a św iat integracji zorientow anej n a usługi. O siągnięciu tego sta n u dedykow ano wiele rozszerzeń W S-*, w śró d nich najistotniejsze są te, k tó re zw iązano z kon cep cjam i orkiestracji i choreografii.

N a tu raln a

To jed n a z najw ażniejszych zasad zorientow ania n a usługi, k tórej realizacja

w ieloużyw alność

przekraczać m oże granice pojedynczego rozw iązania. SOA propaguje tw orzenie usług n aturalnie wieloużywalnych, czyli niezw iązanych a p rio ri z k on k retn ą kom pozycją ani aktywnością.

Rozszerzalność

Rozszerzalność, jako zaleta platform y usług sieciowych, jest konsekwencją innych jej zalet — oparcia na otwartych standardach i kom ponowalności. W iele rozszerzeń W S-* definiuje m echanizm y architektoniczne w budow ujące rozszerzalność w tw orzone rozw iązania, jednakże m uszą być one explicite uw zględniane zarów no na poziom ie projektow anych usług, jak i n a poziom ie SOA jako całości.

M odelow anie biznesow e

T a cecha w sp ieran a jest p rzez orkiestrację, lecz n ie autom atycznie.

zorien to w an e usługow o

Specyfikacje W S-*, m iędzy in n y m i W S-BPEL, dostarczają dialekt języka um ożliw iający w yrażanie p rocesów biznesow ych w k ategoriach syntaktyki operacyjnej. Spożytkow anie tej m ożliw ości uw aru n k o w an e jest jed n a k przem yślanym zastosow aniem zaaw ansow anych te c h n ik projektow ania.

T w orzenie w arstw abstrakcji

Z asady zorientow ania n a usługi w p e łn i h o łd u ją m odelow i „czarnej skrzynki”, czyli abstrahow aniu logiki usług n a poziom ie ich interfejsów. Skoordynow anie tej abstrakcji w form ie w arstw w ym aga jed n ak odpow iedniej organizacji usług i projektow ania ich zgodnie ze specyficznym i standardam i.

L uźne pow iązanie w globalnej skali

Luźne powiązanie jest jedną z fundam entalnych cech usług sieciowych. Jej realizacja to jedna z potencjalnych korzyści, jakie daje skoordynow ana ekspansja SOA oraz

p rzedsiębiorstw a

warstwy abstrakcji reprezentujące dom enę biznesową i dom enę aplikacyjną.

Z w inność organizacyjna

C hociaż w ykorzystyw anie u słu g sieciowych, zasad z o rien to w an ia n a usługi i specyfikacji W S-* sprzyja koncepcji zw iększania zw inności organizacyjnej, to je d n a k nie urzeczyw istnia tej koncepcji autom atycznie. U rzeczyw istnienie to w ym aga specjalnej analizy i specjalnego projektow ania, poza tym uzależnione jest o d realizacji innych cech SOA.

9 .1 . Z O R IE N T O W A N IE N A USŁUGI A W S PÓ ŁC ZESN A SOA

293

9.1.2. Niewspierane cechy SOA S p o g lą d ając n a ta b e lę 9.1 i p o ró w n u ją c ją z w y m ie n io n y m i w ro z d z ia le 3. c e c h a m i w sp ó łc ze s n e j S O A , m o ż e m y w y o d rę b n ić sześć je j cech, p o z o s ta ją c y c h b e z (w y ra ź n e g o ) w p ły w u ze s tro n y u sług s ie c io w y c h z a ró w n o p ie rw s z e j, ja k i d ru g ie j g e n e ra c ji. D o cech ty c h n a le żą : •

n a tu ra ln a in te ro p e ra c y jn o ś ć ,

•

ro zs ze rza ln o ś ć ,

•

lu ź n e p o w ią z a n ie w s k a li p rz e d s ię b io rs tw a ,

•

m o d e lo w a n ie b izn e s o w e z o rie n to w a n e u s łu g o w o ,

•

z w in n o ś ć o rg a n iz a c y jn a ,

•

b u d o w a n ie w a rs tw a b s tra k c ji.

D w ie p ie rw s ze z w y m ie n io n y c h p o z o s ta ją je d n a k w p e w n y m z w ią z k u z n ie k tó r y m i ro z s ze rz e ­ n ia m i W S - * , choć ic h realizacja n a g runcie S O A w y m a g a stan d aryzo w an eg o , starannego za p ro je k to ­ w a n ia — w y ty c z n e w ty m w z g lę d z ie z n a jd ą c z y te ln ic y w ro z d z ia le 15. U s u w a m y je w ię c z n aszej lis ty , k tó r ą ty m s a m y m r e d u k u je m y do c z te re c h p o z y c ji (p o n u m e r o w a liś m y je w y łą c z n ie w celu o d w o ły w a n ia się do n ic h w n a s tę p n y c h p u n k ta c h ). O to o n e : 1. lu ź n e p o w ią z a n ie w s k a li p rz e d s ię b io rs tw a , 2. m o d e lo w a n ie b izn e s o w e z o rie n to w a n e u s łu g o w o , 3. z w in n o ś ć o rg a n iz a c y jn a , 4. b u d o w a n ie w a rs tw a b s tra k c ji. N a jb a rd z ie j in te re s u ją c y je s t w ty m w s z y s tk im fa k t, że p o w y ż s z e c z te ry „ o s ie ro c o n e ” e le m e n ty , m im o b ra k u w y ra ź n e g o z w ią z k u z k o r z e n ia m i a r c h ite k tu r y S O A , m a ją d la u ż y te c z n o ś c i te j a r­ c h ite k tu r y z n a c z e n ie k ry ty c z n e . A to p r z e k ła d a się w p ro s te j lin ii n a z w ię k s z o n y w y s iłe k p ro je k ­ ta n tó w w i ta k tru d n e j b a ta lii z w ią z a n e j z w k ro c z e n ie m n a te r y to r iu m b u d o w y w s p ó łc ze s n e j S O A . W c ie le n ie ty c h k lu c z o w y c h zasad n a g ru n c ie S O A w y m a g a w s tę p n e g o p o d ję c ia tru d n y c h de­ c y z ji, o fu n d a m e n ta ln y m z n a c z e n iu i d łu g o fa lo w y c h k o n s e k w e n c ja c h , p rz e d p rz y s tą p ie n ie m do tw o r z e n ia p o s z c z e g ó ln y c h u s łu g . W k o le jn y c h p u n k ta c h te g o r o z d z ia łu o m ó w im y s z c ze g ó ło w o s tru k tu ra liza c ję S O A p o p rz e z b u d o w ę s p e c ja lizo w a n y c h w a rs tw u s łu g o w y c h , b e zp o ś re d n io d eter­ m in u ją c y c h zakres, w ja k im m a n ife s to w a ć się b ę d ą rze c zo n e zasady. P O D S U M O W A N IE •

Podstaw ow e czynniki zewnętrzne, które ukształtowały współczesną SOA, to specyfikacje usług sieciowych pierwszej generacji oraz zasady zorientowania na usługi.

•

W spółczesna SOA wywodzi zatem wiele swych cech charakterystycznych z tych właśnie czynników zewnętrznych.

•

Te cechy współczesnej SOA, które w e wspomnianych czynnikach nie znajdują swych źródeł, wym agają specjalnych zabiegów przy modelowaniu i projektowaniu usług.

•

Mimo braku związku z korzeniami współczesnej SOA, te w łaśnie jej cechy mają krytyczne znaczenie dla jej użyteczności.

294

RO ZD ZIAŁ 9 . ■ W A R S T W Y USŁUG

9.2. Usługow e w a rs tw y abstrakcji Jak p a m ię ta m y z p o p rz e d n ie g o r o z d z ia łu , w m o d e lu lo g ik i p rz e d s ię b io rs tw a w a rs tw a in te rfe js u u sług z lo k a liz o w a n a jest p o m ię d z y d w ie m a je j d o m e n a m i — w a rs tw ą p ro c e s ó w b izn e s o w y c h i w a r ­ s tw ą a p lik a c y jn ą . T u w ła ś n ie re z y d u ją u s łu g i spajające o b ie p o rc je w s p o m n ia n e j lo g ik i i tu n a jw y ­ ra ź n ie j m a n ife s tu je się c h a ra k te ry s ty k a S O A . B y c h a ra k te ry s ty k ę tę e fe k ty w n ie z a im p le m e n to w a ć , n a le ż y je d n a k zn a le ź ć o d p o w ie d ź n a k ilk a k lu c z o w y c h p y ta ń . •

Jaki ro d z a j lo g ik i p o w in ie n b y ć re p re z e n to w a n y p rz e z usługi?

•

W ja k i sposób u s łu g i p o w in n y zostać p o w ią z a n e z is tn ie ją c ą lo g ik ą a p lik a c y jn ą ?

•

W ja k i sposób m o ż n a z a p o m o c ą u s łu g n a jle p ie j re p re z e n to w a ć lo g ik ę p ro c e s ó w b izn eso w yc h ?

•

Jak n a le ż y tw o rz y ć i u m ie js c a w ia ć u s łu g i, b y p rz y c z y n ia ło się to do z w ię k s z a n ia z w in n o ś c i o rg a n iza c yjn e j?

Z a z w y c z a j p o s z u k iw a n ie o d p o w ie d z i n a p o w y żs ze p y ta n ia o d b y w a się w fa zie a n a liz y z o r ie n ­ to w a n e j n a u s łu g i, k ie d y to u s łu g i te są s ta ra n n ie m o d e lo w a n e , z g o d n ie z z e w n ę tr z n y m i w y m o ­ g a m i i u w a r u n k o w a n ia m i. Z a n im je d n a k z a g łę b im y się w t a jn ik i o w e g o m o d e lo w a n ia (k tó r e m u p o ś w ię c o n e b ę d ą r o z d z ia ły 11. i 1 2 .), s p ró b u je m y w s tę p n ie u d z ie lić o g ó ln y c h o d p o w ie d z i n a p o ­ s ta w io n e p y ta n ia .

9.2.1. Problemy rozwiązywane przez aranżowanie usług w warstwy Jaki rodzaj logiki powinien być reprezentowany przez usługi? P o n ie w a ż w a rs tw a u słu g eg zystu je n a s ty k u lo g ik i b izn e s o w e j i lo g ik i a p lik a c y jn e j, m o ż e b y ć m o ­ d e lo w a n a w k ie r u n k u r e p r e z e n to w a n ia k tó r e jk o lw ie k z ty c h d o m e n b ą d ź o b u , p o d w a r u n k ie m , że z a c h o w a n e z o s ta n ą zas a d y z o rie n to w a n ia n a u s łu g i. A b y je d n a k o siągnąć w s k a li g lo b a ln e j lu ź n e p o w ią z a n ie m ię d z y u s łu g a m i — s ta n o w ią c e je d n ą z czterech „o s ie ro c o n y c h ” cech w spółczesn ej S O A — k o n ie c zn e je s t fizy c zn e ro z s e p a ro w a n ie usług, re z y d u ją c y c h w sw ej lo g ic z n e j w a rs tw ie , n a d w ie prostsze w a rs tw y : p ie rw s z a z n ic h o b e jm o w a ć b ę d z ie u s łu g i re p re z e n tu ją c e k o r p o ra c y jn ą lo g ik ę b iz n e s o w ą , d ru g a — u s łu g i re p re z e n tu ją c e spe­ c y fic z n ą lo g ik ę a p lik a c y jn ą . W te n o to sposób u n ik n ie m y p o w s ta n ia b e zp o ś re d n ie g o u z a le ż n ie n ia m ię d z y b iz n e s o w ą a a p lik a c y jn ą d o m e n ą p rz e d s ię b io rs tw a — u z a le ż n ie n ia , k tó re o z n a c z a ło b y z a ­ p rz e c z e n ie cech y n r 1. z w c ze ś n ie js ze j n u m e ro w a n e j lis ty , c z y li lu źn e g o p o w ią z a n ia . O b ie d o m e n y p o z o s ta ją w ię c lu ź n o p o w ią z a n e , co u n ie z a le ż n ia e w o lu c ję lo g ik i r e p re z e n to w a ­ n ia p ro c e s ó w b iz n e s o w y c h o d e w o lu c ji lo g ik i n a p o z io m ie te c h n o lo g ic z n y m , o d p o w ie d z ia ln e j za z a u to m a ty z o w a n ą re a liz a c ję ty c h p ro c e s ó w .

W jaki sposób usługi powinny zostać powiązane z istniejącą logiką aplikacyjną? O d p o w ie d ź n a to p y ta n ie z a le ż n a je s t p rz e d e w s z y s tk im o d teg o , c zy u s łu g i w y k o rz y s ty w a n e b ę d ą d o e k s p o n o w a n ia lo g ik i tra d y c y jn y c h a p lik a c ji, c z y te ż p re z e n to w a ć b ę d ą w ła s n ą lo g ik ę , z a p ro ­ je k to w a n ą c a łk o w ic ie „ o d z e ra ” . Jest o c zy w is te , iż tra d y c y jn e „ s p a d k o w e ” s y s te m y s tw a rza ć m o g ą szereg o g ra n ic z e ń i za s trz e że ń o ra z w y m a g a ć s p e łn ie n ia o k re ś lo n y c h w a ru n k ó w , b y w ogóle m o ­ g ły fu n k c jo n o w a ć — w s z y s tk o to m u s i, o c z y w iś c ie , b y ć b r a n e p o d u w a g ę p r z y p r o je k to w a n iu u s łu g e k s p o n u ją c y c h lo g ik ę ty c h s y s te m ó w . B y w a n a w e t i ta k , że w celu w y e k s p o n o w a n ia lo g ik i „ s p a d k o w e j” a p lik a c ji n ie u n ik n io n a jest re z y g n a c ja z n ie k tó ry c h zasad z o rie n to w a n ia n a u s ługi.

9 .2 . U SŁU G O W E W A R S T W Y ABSTRAKCJI

295

Tego ty p u k ło p o tliw e , krępujące sytuacje są m a ło p ra w d o p o d o b n e , g d y lo g ik a usługi p ro je k to w a n a jest a b o vo i p ro je k ta n t spraw uje p e łn ą k o n tro lę n a d je j zgodnością ze w s p o m n ia n y m i zasadam i. T a k czy in a c ze j, u s łu g i z a p ro je k to w a n e sp e c ja ln ie d la re p r e z e n to w a n ia lo g ik i a p lik a c y jn e j p o ­ w in n y eg zysto w ać w o d d z ie ln e j w a rs tw ie ; b ę d z ie m y z a te m n a z y w a ć tę g ru p ę u sług w a rs tw ą u s łu g a p lik a c y jn y c h ( a p p lic a tio n s e rv ic e la y e r).

W jaki sposób można za pomocą usług najlepiej reprezentować logikę procesów biznesowych? L o g ik a b iz n e s o w a d e fin io w a n a je s t p rz e z m o d e l b iz n e s o w y p rz e d s ię b io rs tw a i je g o p ro c e s y b iz n e ­ sowe. P rz y m o d e lo w a n iu usług p rz e zn a c z o n y c h do re p re z e n to w a n ia tej lo g ik i n a jw a żn ie js z ą rzeczą jest z a p e w n ie n ie , b y u s łu g i te b y ły zg o d n e z is tn ie ją c y m i m o d e la m i b iz n e s o w y m i. I, p o d o b n ie ja k w p rz y p a d k u u s łu g a p lik a c y jn y c h , ta k i ty m ra z e m u ż y te c z n e je s t w y d z ie le n ie u sług ta k p ro je k to w a n y c h w postaci o d rę b n e j w a rs tw y : u sługi d e d y k o w a n e re p re z e n to w a n iu lo g ik i b izn e s o w e j b ę d z ie m y u w a ż a ć z a n a le żą c e do w a rs tw y u s łu g b iz n e s o w y c h (b u sin e s s s e rv ic e la y e r). W y o d rę b n ie n ie tej w a rs tw y jest p rz e ja w e m cechy n r 2. spośród w cześniej w y m ie n io n y c h — m o d e ­ lo w a n ia b izn eso w eg o z o rie n to w a n e g o usłu g o w o .

Jak należy tworzyć i umiejscawiać usługi, by przyczyniało się to do zwiększania zwinności organizacyjnej? K lu c z e m do b u d o w a n ia z w in n e j S O A je s t m in im a liz o w a n ie u z a le ż n ie ń , s k ry w a n y c h w w e w n ę trz ­ n ej lo g ice k a ż d e j u s łu g i. U s łu g i, k tó re z z a ło ż e n ia fu n k c jo n o w a ć m u s z ą z g o d n ie z o k re ś lo n y m i r e ­ g u ła m i b iz n e s o w y m i, m n ie j się n a d a ją (lu b n ie n a d a ją się w c a le ) do d z ia ła n ia p o z a ś ro d o w is k ie m , któ re re g u ły te w ym u sza. P o d o b n ie u s łu g a -k o n tro le r, k tó ra w swej logice z a k o d o w a n e m a w y m a g a n ie b u d o w a n ia k o m p o z y c ji, z w y k le u s ta n a w ia o k re ś lo n e u z a le ż n ie n ia w s tru k tu rz e tej k o m p o z y c ji. W p ro w a d z e n ie do m o d e lu lo g ik i przedsięb iorstw a kolejnej w arstw y, zaw ierającej usłu g ę -k o n tro le ra za p rzę g ają c ą do k o m p o z y c ji s p e c ja liz o w a n e u s łu g i z n iżs ze j w a rs tw y , p o z w a la n a s c e n tra liz o w a n ie r e g u ł b iz n e s o w y c h i lo g ik i k o m p o z y c ji p rze s ą d za ją c e j o k o le jn o ś c i w y k o n y w a n ia p o s z c z e g ó ln y c h u sług uczestniczących. W ty m w ła ś n ie celu w y m y ś lo n o o rk ie s tra c ję (p a trz p o d ro z d z ia ł 6 .6 ) w p r o ­ w a d za ją c ą k o n c e p c ję u s łu g i p ro c e s o w e j, z d o ln e j fo rm o w a ć k o m p o z y c ję z u d z ia łe m in n y c h u sług w celu z re a liz o w a n ia p ro c e s u b izn e s o w e g o z g o d n ie z je g o p re d e fin io w a n ą lo g ik ą . W m o d e lu lo g i­ k i p rz e d s ię b io rs tw a ta k a u s łu g a p ro c e s o w a u s ta n a w ia w a rs tw ę , k tó r ą ok re ś la ć b ę d z ie m y m ia n e m w a r s tw y o r k ie s tr a c ji u s łu g (o rc h e s tr a tio n s e rv ic e la y e r). D o d a n ie w s p o m n ia n e j w a rs tw y do m o d e lu lo g ik i p rz e d s ię b io rs tw a z n a c z n ie z w ię k s z a z w in ­ n o ś ć o rg a n iz a c y jn ą (c z y li cechę n r 3. n aszego z e s ta w ie n ia ), n ie m n ie j je d n a k n ie je s t to w ty m d z ie le p rz y c z y n e k je d y n y . K a ż d a fo r m a z o rg a n iz o w a n e j a b s tra k c ji u s łu g w n o s i do tej z w in n o ś c i p o z y ty w n y w k ła d , z a te m g e n e ra ln ie p rz y c z y n ia się do n ie j s a m a k o n c e p c ja p o d z ia łu lo g ik i p r z e d ­ s ię b io rs tw a n a tr z y w a rs tw y : b iz n e s o w ą , a p lik a c y jn ą i o rk ie s tra c y jn ą .

Abstrakcja jest kluczem do sukcesu N a liście n a s zy c h cech S O A n ie w s p ie ra n y c h p rz e z u s łu g i s ie c io w e p ie rw s ze j g e n e ra c ji p o z o s ta ła jeszcze do o m ó w ie n ia o s ta tn ia p o z y c ja — cecha n r 4 ., c z y li b u d o w a n ie w a rs tw a b s tra k c ji. I n ie jest n ic z y m z a s k a k u ją c y m fa k t, że cecha ta m a n ife s tu je się n ie p o p rz e z k tó r ą k o lw ie k z w a rs tw , ale p o ­ p rz e z sam ą koncepcję ic h w y o d rę b n ie n ia . W y k o rz y s tu ją c koncepcję k o m p o z y c ji usług, w y d z ie liliś m y t r z y ic h s p e c ja liz o w a n e w a rs tw y , z k tó r y c h k a ż d a d e d y k o w a n a je s t a b s tra h o w a n iu s p ecyficzn eg o a s p e k tu ro z w ią z a n ia , a s p e k tu p o zo s ta ją c e g o w ś c is ły m z w ią z k u z je d n ą ze w s p o m n ia n y c h cech S O A . I n ie je s t to z a b ie g w y łą c z n ie f o r m a ln y , b o w te n w ła ś n ie sposób u c ie le ś n ia się p o p u la r n a ,

296

RO ZD ZIAŁ 9 . ■ W A R S T W Y USŁUG

w ie lo k ro tn ie ju ż w tej książce p rz y w o ły w a n a , zasada s e p a ra c ji p ro b le m u n a p o d p ro b le m y : k o n ­ c e n tru ją c się n a p o je d y n c ze j w a rs tw ie , u n ik a m y k o n ie c zn o ś c i z a jm o w a n ia się je d n o c ześ n ie w szyst­ k im i trz e m a a s p e k ta m i S O A — b iz n e s o w y m , a p lik a c y jn y m i z w in n o ś c io w y m . N a ry s u n k u 9 .2 w id o c z n e są t r z y z id e n ty fik o w a n e p r z e z nas w a rs tw y u s łu g — o rk ie s tra c ji, b iz n e s o w a i a p lik a c y jn a — o ra z ic h u m ie js c o w ie n ie w m o d e lu lo g ik i p rz e d s ię b io rs tw a . K a ż d e j z n ic h p o ś w ię c im y je d e n z n a s tę p n y c h p o d r o z d z ia łó w .

UW AGA Dalej w tym rozdziale będziemy powoływać się na modele usług zdefiniowane w poprzednich rozdziałach, zdefi­ niujemy też nowe modele. W dodatku B znajdą czytelnicy kompletną listę referencyjną modeli usług omawianych w tej książce, wraz z odsyłaczami do rozdziałów, w których modele te są definiowane lub do nich się odwołujemy.

P O D S U M O W A N IE •

Poprzez abstrakcyjność im plem entowaną w postaci wydzielonych w arstw usług realizowane są podstaw ow e cechy charakterystyki współczesnej SOA — między innymi zwinność organizacyjna.

•

W spom niane warstwy usług to warstwa orkiestracji, w arstw a usług biznesowych i warstwa usług aplikacyjnych.

9 .3 . W A R S T W A USŁUG APLIKACYJNYCH

297

9.3. W arstw a usług aplikacyjnych W a r s tw a u s łu g a p lik a c y jn y c h z z a ło ż e n ia g ru p u je u s łu g i n ie b iz n e s o w e (c z y li te, k tó r y c h lo g ik a n ie w y p ły w a z m o d e li b iz n e s o w y c h p rz e d s ię b io rs tw a ) w z b ió r , k t ó r y n a z y w a ć b ę d z ie m y p o p ro s tu u s łu g a m i a p lik a c y jn y m i ( a p p lic a tio n services) lu b u s łu g a m i u ż y tk o w y m i ( u t ili t y se rvice s), co p rz e d ­ sta w io n o n a ry s u n k u 9.3. Z a d a n ie m ty c h usług je s t d o starczen ie w ie lo u ż y w a ln y c h fu n k c ji r e p r e ­ z e n tu ją c y c h u n iw e rs a ln e m e c h a n iz m y i za s o b y p rz e d s ię b io rs tw a .

Rysunek 9.3. Warstwa usług aplikacyjnych

T y p o w e u s łu g i a p lik a c y jn e s c h a ra k te ry zo w a ć m o ż n a n astęp u jąco : •

e k s p o n u ją e le m e n ty fu n k c jo n a ln e w k o n te k ś c ie k o n k re tn e g o p rz e tw a rz a n ia ,

•

w y k o rz y s tu ją d o s tę p n e za s o b y w ra m a c h k o n k re tn e j p la tfo r m y ,

•

są ag n o s tyc zn e p ro c e s o w o , c z y li n ie ś w ia d o m e sw ego u d z ia łu w k o n k r e tn y m ro z w ią z a n iu ,

•

są g e n e ry c z n e i w ie lo u ż y w a ln e ,

•

m o ż n a m ię d z y n im i u s ta n a w ia ć k a n a ły in te g ra c y jn e ty p u „ p u n k t -p u n k t ”,

•

są za zw y c z a j n ie s p ó jn e p o d w z g lę d e m g ra n u la c ji in te rfe js ó w ,

•

m o g ą s ta n o w ić m ie s z a n k ę u s łu g tw o r z o n y c h d o ra ź n ie i z e w n ę trz n y c h u sług, z a k u p io n y c h lu b w y d z ie rż a w io n y c h .

298

RO ZD ZIAŁ 9 . ■ W A R S T W Y USŁUG

G d y u s ta n o w io n a je s t o d d z ie ln a w a rs tw a u s łu g b iz n e s o w y c h (k tó r e j d e d y k u je m y n a s tę p n y p o d r o z d z ia ł), p o ja w ia się s iln a m o ty w a c ja do n a d a n ia w s z y s tk im u s łu g o m a p lik a c y jn y m f o r m y g e n e ry c z n y c h u słu g u ż y tk o w y c h . W te n sposób zo s ta n ą o n e o d s e p a ro w a n e o d k o n k re tn e g o r o z ­ w ią z a n ia (ro z w ią z a ń ), n a rze c z k tó re g o (k tó ry c h ) d zia ła ją , a to u m o ż liw i ic h w ie lo u ż y w a n ie i k o m ­ p o n o w a n ie p rz e z u słu g i b izn e s o w e . D la o d m ia n y , g d y u s łu g i b izn e s o w e n ie z o s ta n ą z g ru p o w a n e e x p lic ite w w y o d rę b n io n e j w a r ­ s tw ie, u s łu g o m a p lik a c y jn y m m o ż e zostać p o w ie rz o n e z a d a n ie im p le m e n to w a n ia m o d e li b iz n e ­ sow ych, z w ią z a n e raczej z w a rs tw ą b izn e s o w ą n iż a p lik a c y jn ą . P o je d y n c za usługa a p lik a c y jn a m o że w ięc b yć n ie k ie d y u w aża n a ró w n ie ż za usługę bizneso w ą, p o n ie w a ż w s p ó łd zia ła bezp o śred n io z w a r­ stw ą aplikacyjn ą, lecz jed nocześn ie jej lo g ik a z a w ie ra w b u d o w a n e re g u ły bizneso w e. T a k ie h e te ro g e n ic z n e u s łu g i a p lik a c y jn o -b iz n e s o w e o k re ś la n e są m ia n e m h y b ry d o w y c h u s łu g a p lik a c y jn y c h ( h y b r id a p p lic a tio n s e rv ic e s ) lu b k r ó tk o u s łu g h y b ry d o w y c h ( h y b r id s e rv ic e s ). T a k i m o d e l u słu g s p o ty k a n y je s t najczęściej w tra d y c y jn y c h a rc h ite k tu ra c h ro z p ro s z o n y c h . I ch o ć sta­ n o w c z o n ie z a le c a n y p rz y p r o je k to w a n iu u s łu g o w y c h w a rs tw a b s tra k c ji, jest n a ty le ro z p o w s z e c h ­ n io n y , że za s łu g u je n a n a le ż n ą uw a g ę w te j książce. W re s zc ie , usługa a p lik a c y jn a m o ż e an g a żo w a ć do k o m p o z y c ji in n e usłu g i a p lik a c y jn e , o m n ie j­ szej g ra n u la c ji fu n k c jo n a ln e j (n a p r z y k ła d ja k o u s łu g i p ro x y ), tw o rz ą c w te n sposób b a rd z ie j g r u ­ b o z ia rn is tą je d n o s tk ę lo g ik i p rz e tw a rz a n ia . T a k ą s tra te g ię stosuje się najczęściej w cela c h in te g ra ­ c y jn y c h ; u s łu g i a p lik a c y jn e is tn ie ją c e w y łą c z n ie n a p o tr z e b y in te g r a c ji s y s te m ó w n a z y w a n e są p o p u la rn ie in te g r a c y jn y m i u s łu g a m i a p lik a c y jn y m i ( a p p lic a t io n in t e g r a t io n s e rv ic e s ) lu b k ró c e j u s łu g a m i in te g r a c y jn y m i ( in te g r a tio n s e rvice s). U w a ż n i c z y te ln ic y d o s trz e g li z a p e w n e p o d o b ie ń s tw o u s łu g a p lik a c y jn y c h d o m o d e lu u s łu g i u ż y tk o w e j opisyw an eg o w ro z d z ia le 5. Z e w z g lę d u n a to p o d o b ie ń s tw o w a rs tw a usług a p lik a c y jn y c h n a z y w a n a b y w a często ta k że w a rs tw ą u s łu g u ż y tk o w y c h ( u t il i t y se rv ic e la y e r). In n y m p o w szech n ie u ż y w a n y m s y n o n im e m je s t w a rs tw a u s łu g in f r a s tr u k tu r a ln y c h ( in fr a s tr u c tu r e s e rv ic e la y e r), sam e zaś u s łu g i o k re ś la n e są m ia n e m u s łu g in fr a s tr u k tu r a ln y c h ( in fr a s tr u c tu r e se rv ic e s). T r u d n o p re fe ­ ro w a ć k tó ry ś z ty c h w a r ia n tó w , w y b ó r k o n k re tn e g o je s t zaw s ze k w e s tią p re fe ro w a n e j k o n w e n c ji n a z e w n ic z e j. O m a w ia n ie w a rs tw y usług a p lik a c y jn y c h s ta n o w i d o s k o n a łą o k a zję do z a p re z e n to w a n ia jeszcze je d n e g o m o d e lu u s łu g często s p o ty k a n y c h w tej w a rs tw ie — m o w a o u s łu g a c h -o to c z k a c h ( w r a p p e r se rv ic e s). Jak s u g e ro w a ć m o ż e n a z w a , ic h z a d a n ie m je s t e n k a p s u lo w a n ie („ o ta c z a n ie ”) części lu b całości fu n k c jo n a ln o ś c i c ze rp a n e j ze „ s p a d k o w y c h ” s y s te m ó w i k o n w e rto w a n ie je j do p o s ta c i lo ­ g ik i u s łu g i, b y s ta ła się „ s tr a w n a ” d la p o te n c ja ln y c h u s łu g -w n io s k o d a w c ó w . O to c z k i ta k ie m o g ą w y s tę p o w a ć w ró ż n y c h o d m ia n a c h , z k tó r y c h najczęściej s p o ty k a n ą je s t u s łu g a -a d a p te r, d e d y k o ­ w a n a k o n k re tn e m u ś ro d o w is k u i d o s ta rc za n a p rz e z dostaw cę tegoż ś ro d o w is k a . O tr z y m u je m y ty m s a m y m n o w o c z e s n y in te rfe js d la starej a p lik a c ji w p o s ta c i u s łu g i sie c io w e j. In n y m w a ria n te m u s łu g i-o to c z k i (n ie b ę d z ie m y się n im w tej książce z a jm o w a ć ) je s t u s łu g a p r o x y ( p r o x y s e rv ic e ) m a ją c a p o s ta ć a u to m a ty c z n ie g e n e ro w a n e g o k o d u d e fin ic ji W S D L ( a u t o ­ g e n e ra te d W S D L ). K o d te n o d z w ie rc ie d la (w ję z y k u W S D L ) in te rfe js is tn ie ją c e g o k o m p o n e n tu , d z ię k i c z e m u z k o m p o n e n te m ty m z w ią z a n y zostaje p u n k t k o ń c o w y u m o ż liw ia ją c y m u u czest­ n ic tw o w k o m u n ik a c ji S O A P .

9 .3 . W A R S T W A USŁUG APLIKACYJNYCH

299

UW AGA Nie należy mylić usługi pro xy (w opisanym znaczeniu) z usługą-namiastką kom ponentu (service p ro xy, re­ prezentującą usługę-dostarczyciela, obudowującą zdalny komponent dla potencjalnych usług-wnioskodawców (wyjaśnimy dokładniej tę rolę w rozdziale 18., patrz również podrozdział 4.3.3 „SOA a rozproszona archi­ tektura internetowa").

A N A LIZA PRZYPADKU

W

a r c h ite k tu r z e u s łu g T L S is tn ie je w y r a ź n ie z a r y s o w a n a w a rs tw a u s łu g a p lik a c y jn y c h .

W ś r ó d u s łu g , k tó re o m a w ia liś m y w ra m a c h d o ty c h c z a s o w y c h a n a liz p rz y p a d k ó w , za u s łu g i a p lik a c y jn e m o ż n a u w a ż a ć następujące:

• Równoważenie obciążenia , • Politykę wewnętrzną , • Powiadamianie systemowe . K a ż d a z n ic h to g e n e ry c z n a u s łu g a u ż y tk o w a o ce c h a c h w ie lo u ż y w a ln o ś c i, z d o ln a f u n k ­ c jo n o w a ć ja k o s k ła d n ik k o m p o z y c ji s p e łn ia ją c e j s p e c y fic zn e z a d a n ie w e w n ą trz w ię k s ze j je d ­ n o s tk i a u to m a ty z a c ji. W y m ie n io n e p o n iż e j u s łu g i R a ilC o r e a liz u ją p r z e tw a r z a n ie c h a ra k te ry s ty c z n e d la u s łu g a p lik a c y jn y c h :

• Wystawienie faktury, • Realizacja zamówienia , • Subskrypcja TLS. U s łu g i Wystawienie faktury i Realizacja zamówienia są w p e w n y m sensie h y b ry d o w e , p o n ie w a ż k a ż d a z n ic h z a w ie ra w b u d o w a n e e le m e n ty lo g ik i b iz n e s o w e j (co w y ja ś n im y b liż e j w n a s tę p n e j a n a liz ie p r z y p a d k u ). U s łu g a Subskrypcja TLS m o ż e b y ć n a to m ia s t u w a ż a n a za usługę czysto a p lik a c y jn ą , g d y ż re a liz u je pro ste ty p o w o a p lik a c y jn e z a d a n ie . O g ó ln ie w ą tp liw e jest, b y ja k a k o lw ie k usługa R a ilC o m o g ła b y ć u w a ż a n a za usługę u ż y tk o w ą , ja k o że ż a d n a z n ic h n ie b y ła p ro je k to w a n a z m y ś lą o w ie lo u ż y w a ln o ś c i.

P O D S U M O W A N IE •

W arstwa usług aplikacyjnych składa się z usług aplikacyjnych reprezentujących logikę specyficzną dla użytych technologii.

•

Typowe odmiany usług aplikacyjnych to usługa użytkowa i usługa-otoczka.

•

Usługi aplikacyjne to idealnie wieloużywalne usługi angażow ane do kompozycji przez usługi biznesowe; istnieją również usługi hybrydowe, zawierające oba typy logiki — biznesową i aplikacyjną.

300

RO ZD ZIAŁ 9 . ■ W A R S T W Y USŁUG

9.4. W arstw a usług biznesowych W a r s tw a u s łu g b iz n e s o w y c h re p re z e n tu je k o le k c ję u s łu g b a z u ją c y c h n a m o d e lu z w a n y m u s łu g ą b iz n e s o w ą (b u sin e s s s e rv ic e ). W ła ś n ie d z ię k i tej w a rs tw ie m o ż liw e je s t os ią g n ię c ie ścisłej zg o d n o ś c i m ię d z y d o m e n ą b iz n e ­ s o w ą a d o m e n ą te c h n o lo g ic z n ą p rz e d s ię b io rs tw a . A n a lity c y , a rc h ite k c i i in n i specjaliści z za k re s u I T w s p ó ln ie p ro w a d z ą pro ces a n a liz y , w r a m a c h k tó re g o k a ż d e j u s łu d z e b izn e s o w e j p rz y p is a n y zo staje k o n te k s t fu n k c jo n a ln y w y w o d z ą c y się z je d n e g o b ą d ź k ilk u m o d e li lu b s p e c y fik a c ji b iz n e ­ s o w y c h p rz e d s ię b io rs tw a (p ro c e s e m a n a liz y z o r ie n to w a n e j u s łu g o w o z a jm ie m y się d o k ła d n ie j w ro z d z ia le 1 1.). U m ie js c o w ie n ie w a rs tw y u s łu g b iz n e s o w y c h w m o d e lu lo g ik i p rz e d s ię b io rs tw a p rz e d s ta w io n o n a ry s u n k u 9.4.

Rysunek 9.4. Warstwa usług biznesowych

W w ię k s zo ś c i p rz e d s ię b io rs tw p ro je k to w a n ie w a rs tw y u s łu g b iz n e s o w y c h p r o w a d z i do p o ­ w s ta w a n ia d w ó c h p o w s ze c h n y c h m o d e li usług b izn e s o w y c h , z k tó ry c h k a ż d y u s ta n a w ia sw ą w ła s n ą p o d w a rs tw ę . •

U s łu g a b iz n e s o w a u k ie r u n k o w a n a z a d a n io w o ( ta s k - c e n tr ic b u sin e ss s e rv ic e ) e n k a p s u lu je lo g ik ę b izn e s o w ą s pecyficzną d la o k reślonego z a d a n ia lu b p rocesu b izn eso w eg o angażującego d w a p o d m io ty b izn e s o w e lu b w ięcej ta k ic h p o d m io tó w . U s łu g i tej k a te g o rii m a ją g e n e ra ln ie o g ra n ic z o n ą w ie lo u ż y w a ln o ś ć i często n a z y w a n e są (p o p ro s tu ) u s łu g a m i z a d a n io w y m i (ta s k s e rvice s).

9 .4 . W A R S T W A USŁUG B IZNESO W YC H

•

301

U s łu g a b iz n e s o w a u k ie r u n k o w a n a p o d m io to w o ( e n tity - c e n tr ic b u sin e ss s e rv ic e ) e n k a p s u lu je lo g ik ę p rz e tw a rz a n ia s k o ja rz o n ą z k o n k r e tn y m p o d m io te m (e n c ją ) b iz n e s o w y m — fa k tu rą , k a rtą czasu p ra c y i p o d o b n y m i. U s łu g i tej k a te g o rii to zazw yczaj usługi agnostyczne procesow o, o d u ż y m s to p n iu w ie lo u ż y w a ln o ś c i. Ic h s y n o n im ic z n e n a z w y to u s łu g i p o d m io t ó w b iz n e s o w y c h (b u sin e s s e n tity s e rvice s) lu b (p o p ro s tu ) u s łu g i p o d m io to w e ( e n tit y s e rvice s).

G d y w y o d rę b n io n a jest w a rs tw a usług a p lik a c y jn y c h , u s łu g i b izn e s o w e w y m ie n io n y c h k a te g o rii m o g ą a n g a ż o w a ć u s łu g i a p lik a c y jn e tej w a rs tw y w k o m p o z y c je d e d y k o w a n e re a liz a c ji sw ej lo g ik i b iz n e s o w e j. W y ja ś n im y d o k ła d n ie j tę k w e s tię w r o z d z ia le 11., w p o d ro z d z ia le „ W y o d r ę b n ia n ie u s łu g b iz n e s o w y c h ” . Z a u w a ż m y , że u s łu g i h y b r y d o w e , o k tó r y c h p is a liś m y w c z e ś n ie j w ty m ro z d z ia le , z a w ie ra ją o b a ty p y lo g ik i — b iz n e s o w ą i a p lik a c y jn ą — i z tego w z g lę d u często tra k to w a n e są ja k o o d m ia n a u s łu g b izn e s o w y c h . W y o d r ę b n ia ją c w a rs tw ę b izn e s o w ą , re z e r w u je m y ją je d n a k d la u s łu g czysto b iz n e s o w y c h , c z y li a b s tra h u ją c y c h je d y n ie lo g ik ę b iz n e s o w ą ; u s łu g i h y b r y d o w e t r a k tu je m y ty m s a m y m ja k o d m ia n ę u s łu g a p lik a c y jn y c h i u m ie js c a w ia m y je s t w w a rs tw ie ty c h że usług.

A N A LIZA PRZYPADKU

W ś r ó d u sług T L S , k tó re o m a w ia liś m y w ra m a c h d o ty c h c z a s o w y c h a n a liz p rz y p a d k ó w , n a ­ stęp u jące m o ż n a u w a ż a ć z a u s łu g i b izn e s o w e : •

Płatność na konto ,

•

Zlecenie zakupu ,

•

Rejestr księgi głównej ,

•

Profile dostawców .

K a ż d a z n ic h d e d y k o w a n a je s t lo g ic e b iz n e s o w e j o s a d z o n e j w w y r a ź n ie o k re ś lo n y c h g ra n ic a c h , a z m u s z o n a w y k o n a ć z a d a n ie w y k ra c z a ją c e p o z a te g ra n ic e w y k o r z y s tu je (n a z a ­ sadzie w ie lo u ż y w a ln o ś c i) fu n k c jo n a ln o ś ć d o s ta rc za n ą p rz e z in n ą usługę b izn e s o w ą lu b usługę a p lik a c y jn ą . Jak w s p o m in a liś m y w p o p rz e d n ie j a n a liz ie p r z y p a d k u , u s łu g i R a ilC o W ystawienie fak­ tury i Realizacja zamówienia u w a ż a n e są za h y b ry d o w e , b o w y k o n u ją p rz e tw a rz a n ie c h a ­ r a k te ry s ty c z n e d la o b u ty p ó w lo g ik i — b iz n e s o w e j i a p lik a c y jn e j. T a k ie u s łu g i s p o ty k a się często w p rz e d s ię b io rs tw a c h w y k o rz y s tu ją c y c h u s łu g i w sposób p e ry fe ry jn y . D la c e ló w m o ­ d e lo w a n ia w y m ie n io n e u s łu g i z o s ta ły z a k la s y fik o w a n e ja k o h y b ry d o w e u s łu g i a p lik a c y jn e . P o n ie w a ż w R a ilC o n ie d o k o n a n o e x p lic ite a b s tra h o w a n ia lo g ik i b iz n e s o w e j, w m o d e lu usłu g tej f ir m y is tn ie je w y łą c z n ie w a rs tw a u s łu g a p lik a c y jn y c h .

P O D S U M O W A N IE

•

W arstwa usług biznesowych składa się z usług bezpośrednio implementujących modele biznesowe.

•

Usługi biznesowe nadają się idealnie do organizowania kompozycji angażujących usługi aplikacyjne do realizowania swej w ewnętrznej logiki.

•

Usługi hybrydowe, mimo iż zawierają także logikę biznesową, nie są uważane za usługi biznesowe.

302

R O ZD ZIA Ł 9 . ■ W A R S T W Y USŁUG

9.5. W arstw a orkiestracji usług W ro z d z ia le 6. o p is y w a liś m y k o n c e p c ję o rk ie s tra c ji, k tó r e j is to tą je s t w y o d rę b n ie n ie n a d rz ę d n e j u s łu g i p ro ce so w ej o rg a n iz u ją c e j fu n k c jo n o w a n ie p o d p o rz ą d k o w a n y c h sobie u s łu g i s p ra w u ją c e j n a d ty m fu n k c jo n o w a n ie m p e łn ą k o n tro lę . W o d n ie s ie n iu d o w a r s tw y in te r fe js u u s łu g w m o d e lu lo g ik i p rz e d s ię b io rs tw a o rk ie s tra c ja o k a z u je się n ie z w y k le u ż y te c z n a , b o p o z w a la n a b e z p o ś re d n ie o d n ie s ie n ie lo g ik i p ro c e s u b iz n e ­ so w e g o d o in te r a k c ji u s łu g i lo g ik i p r z e p ły w u p ra c y w te jż e in te r a k c ji. U m o ż liw ia to p o łą c z e n ie m o d e lo w a n ia p ro c e s ó w b iz n e s o w y c h z m o d e lo w a n ie m i p r o je k to w a n ie m z o r ie n to w a n y m n a u s łu g i. P o n a d to , p o n ie w a ż ję z y k i o r k ie s tra c ji (m ię d z y in n y m i W S -B P E L ) w y ra ż a ją z a rz ą d z a n ie p rz e p ły w e m p ra c y w k a te g o ria c h m o d e lu u s łu g i p ro c e s o w e j, o rk ie s tra c ja p o z y c jo n u je p roces b iz ­ n e s o w y w w a rs tw ie u s łu g p o d p o s ta c ią g łó w n e g o k o n tro le r a k o m p o z y c ji. W a r s tw a o rk ie s tra c ji u s łu g w p r o w a d z a n a d r z ę d n y p o z io m a b s tra k c ji, o rg a n iz u ją c s z c ze g ó ły w s p ó łd z ia ła n ia p o d p o r z ą d k o w a n y c h s o b ie u s łu g w e d łu g o k re ś lo n e g o s c e n a riu s za , u w a ln ia ty m s a m y m te u s łu g i o d z a jm o w a n ia się s z c ze g ó ła m i w s p ó łd z ia ła n ia w e w ła s n y m z a k re s ie (p a tr z ry s u ­ n e k 9 .5 ). R e zy d u ją c e w w a rs tw ie o rk ie s tra c ji u s łu g i p ro c e s o w e (p ro ce ss s e rvice s) re a liz u ją k o m p o ­ zycje z u d z ia łe m in n y c h u s łu g , n ie ś w ia d o m y c h z a zw y c z a j z a ró w n o r e g u ł b iz n e s o w y c h n a d r z ę d ­ n eg o p ro c e s u , ja k i lo g ik i s c e n a riu s za s k o ja rzo n e g o z in s ta n c ją tego p rocesu.

Rysunek 9.5. Warstwa orkiestracji usług

9 .6 . A G N O S TY C Y ZM USŁUG

303

K a ż d a u słu g a p ro c e s o w a je s t w ię c z n a tu r y u s łu g ą -k o n tro le re m k o m p o z y c ji a n g a żu jąc e j u s łu g i p o d p o rz ą d k o w a n e . C zę s to o k re ś la się ją m ia n e m o r k ie s tr o w a n e j u s łu g i z a d a n io w e j (o rc h e s tra te d ta s k s e rv ic e ) d la p o d k re ś le n ia je j szczeg ó ln ej r o li w m o d e lu lo g ik i p rz e d s ię b io rs tw a , a ta k że d la u w y d a tn ie n ia fa k tu , że z d o ln a je s t o n a z a rzą d za ć k o m p o z y c ja m i d u ży c h , d łu g o trw a ły c h ak ty w n o ś c i. A n a lity c y często n a z y w a ją w a rs tw ę o rk ie s tra c ji n a d rz ę d n ą w a rs tw ą p ro c e s ó w b iz n e s o w y c h ( p a r e n t business p ro ce s s la y e r ), co w o c z y w is ty sposób w y n ik a z n a d rz ę d n e j r o li w s p o m n ia n y c h u s łu g p r o ­ cesow ych. N a ry s u n k u 9 .5 p rz e d s ta w io n o z w ią z e k w a rs tw y o rk ie s tra c ji z in n y m i u s łu g a m i o ra z je j u m ie js c o w ie n ie w m o d e lu lo g ik i p rz e d s ię b io rs tw a . U ż y te c z n o ś ć w a rs tw y o rk ie s tra c ji m a je d n a k sw ą cenę, b o z r e g u ły w ią ż e się z w p r o w a d z e n ie m do in fr a s tr u k tu r y I T n o w e g o o p ro g ra m o w a n ia m id d le w a re . W d r a ż a n ie s e rw e ró w o rk ie s tra c ji n ie jest — n ie s te ty — o p e ra c ją a n i b a n a ln ą , a n i ta n ią .

A N A LIZA PRZYPADKU

W T L S i w R a ilC o n ie fu n k c jo n u je u s łu g a p ro c e s o w a w y d z ie lo n a w p o s ta c i o d rę b n e j w a rs tw y . Jak w ie le n o w o c ze s n y c h f ir m , T L S r ó w n ie ż z a in te re s o w a n a je s t o rk ie s tra c ją , m a je d n a k o g ra ­ n ic z o n e z a u fa n ie do re a liz u ją c y c h ją te c h n o lo g ii, o b a w ia się ta k że je j w p ły w u n a sw ą a k tu a ln ą a rc h ite k tu rę usług. O s ta te c zn ie T S L zd e c y d u je się n a w y p ró b o w a n ie o rk ie s tra c ji, co o m ó w im y w ro z d z ia le 16. W m ięd zy c za s ie w k o le jn y c h a n a liz a c h p rz y p a d k ó w opisyw ać b ę d z ie m y drogę d o s fo rm u ło w a n ia d e fin ic ji p ro c e s u b izn e s o w e g o T L S w ję z y k u W S -B P E L , k tó r a to d e fin ic ja u s ta n a w ia ć b ę d z ie o fic ja ln ą w a rs tw ę o rk ie s tra c ji.

P O D S U M O W A N IE •

W arstwa orkiestracji usług składa się z jednej usługi procesowej lub wielu takich usług, komponujących usługi biznesowe i usługi aplikacyjne zgodnie z regułami biznesowymi oraz logiką biznesową w budow aną w definicję procesu.

•

Orkiestracja oddziela usługi od scenariusza ich wykonywania i reguł biznesowych wyznaczających ten scenariusz, co pozytywnie wpływa na wieloużywalność wspomnianych usług i zwinność organizacyjną.

9.6. Agnostycyzm usług K lu c z o w y m a s p e k te m w a rs tw y in te rfe js ó w u s łu g je s t u n ie z a le ż n ie n ie ty c h że usłu g o d k o n k r e tn e ­ go p ro ce su czy ś ro d o w is k a . P o w o d u je to z a c ie ra n ie g ra n ic a rc h ite k to n ic z n y c h p o m ię d z y p o s zc ze ­ g ó ln y m i r o z w ią z a n ia m i z o r ie n to w a n y m i n a u s ługi. S O A n a p o z io m ie a p lik a c ji, z a w ie ra ją c a u s łu g i a g n o s ty c zn e , fa k ty c z n ie w y k ra c z a p o z a g ra n ic e p o je d y n c z e j a p lik a c ji. I v ic e -v e rs a : S O A n a p o z io m ie a p lik a c ji, k tó r a z a le ż n a je s t o d is tn ie n ia u s łu g a g n o s ty c zn y c h , n ie ś w ia d o m y c h k o n k re tn e g o ro z w ią z a n ia , n ie p o s ia d a ściśle z d e fin io w a ­ n y c h g ra n ic a p lik a c ji. R o zs ze rza ją c te n p u n k t w id z e n ia , s p o jrz y jm y p o n o w n ie n a w a rs tw ę u s łu g z p e rs p e k ty w y d o ­ s ta rc z a n ia p rz e z n ie w ie lo u ż y w a ln e j lo g ik i.

304

RO ZD ZIAŁ 9 . ■ W A R S T W Y USŁUG

•

U s łu g i b izneso w e u k ie ru n k o w a n e p o d m io to w o p ro je k to w a n e p o w in n y by ć w celu dostarczania m e c h a n iz m ó w z a rz ą d z a n ia d a n y m i z w ią z a n y m i w y łą c z n ie z o k re ś lo n y m i p o d m io ta m i. S tają się o n e w ó w c za s n ie ś w ia d o m e („ a g n o s ty c z n e ”) p ro c e s ó w b iz n e s o w y c h , n a rze c z re a liz a c ji k tó ry c h d z ia ła ją — ta sam a usługa u k ie ru n k o w a n a p o d m io to w o m o ż e (i p o w in n a ) b y ć w y k o rz y s ty w a n a p rz e z w ie le p ro c e s ó w lu b u s łu g u k ie ru n k o w a n y c h z a d a n io w o .

•

U s łu g i a p lik a c y jn e p o w in n y b y ć p ro je k to w a n e z g o d n ie z m o d e le m u s łu g i u ż y tk o w e j. T a k ie p o d ejście s p ra w ia , że u s łu g i a p lik a c y jn e są w ysoce g e n e ry c z n e , w ie lo u ż y w a ln e i n ie ś w ia d o m e („ a g n o s ty c z n e ”) ro z w ią z a ń , w ra m a c h k tó r y c h fu n k c jo n u ją . R ó żn e r o z w ią z a n ia z o rie n to w a n e n a u s łu g i m o g ą (i p o w in n y ) w y k o rz y s ty w a ć te sam e u s łu g i a p lik a c y jn e .

Jak p o k azan o n a ry s u n k u 9.6, w z m ia n k o w a n y „ag n o stycyzm ” usług w n ic z y m n ie p rzeszkadza im , b y re z y d u ją c n a d a l w w a rs tw ie u s łu g , łą c z y ły r ó ż n e p ro c e s y b izn e s o w e i o d m ie n n e ro z w ią z a n ia .

Rysunek 9.6. Usługi jednoczące izolowane poprzednio procesy biznesowe i środowiska rozwiązań

In w e s ty c je w a g n o s ty c z n e u s łu g i p rz y n o s z ą o b fite o w o c e w p o s ta c i ś ro d o w is k a o w y s o k im s to p n iu w ie lo u ż y w a ln o ś c i. W ty m sensie b u d o w a n ie ro z w ią z a ń z o rie n to w a n y c h n a u s łu g i staje się b a rd z ie j ć w ic z e n ie m z m o d e lo w a n ia n iż p r o je k te m p ro g r a m is ty c z n y m . P O D S U M O W A N IE •

Usługi agnostyczne wiążą wiele procesów biznesowych i rozwiązań automatyzacji.

•

Usługi te propagują wieloużywalność, lecz jednocześnie przyczyniają się do zacierania granic między poszczególnymi rozwiązaniami.

9 .7 . SCENARIUSZE K O NFIG URACJI W A R S T W Y USŁUG

305

9.7. Scenariusze konfiguracji w a rs tw y usług O p is a n y m o d e l w a rs tw y in te rfe js ó w u s łu g w dość k la r o w n y sposób p a rty c jo n u je tę w a rs tw ę n a t r z y w y ra ź n e , ro z łą c z n e (p o d )w a rs tw y , u s ta n a w ia ją c z n a k o m ic ie z d e fin io w a n ą h ie ra rc h ię k o m p o ­ zy c ji. T o je d n a k — n ie s te ty — ty lk o te o ria , rz a d k o z n a jd u ją c a w ie rn e o d z w ie rc ie d le n ie w rz e c z y ­ w is te j S O A . W ś r ó d k o n k re tn y c h re a liz a c ji S O A z id e n ty fik o w a ć m o ż e m y w ie le ró ż n y c h k o n fig u ra c ji b ę d ą ­ cyc h p rz y b liż e n ia m i o w e g o k la ro w n e g o m o d e lu ; p rz e d s ta w im y najczęściej s p o ty k a n e , k r ó tk o o p i­ sując specy fikę k a ż d e j z n ic h . W y k o r z y s ta m y p r z y ty m n a s tę p u ją ce m o d e le u s łu g z a p re z e n to w a n e w c ze ś n ie j w ty m ro z d z ia le : •

h y b ry d o w e u s łu g i a p lik a c y jn e , c z y li u s łu g i z a w ie ra ją c e lo g ik ę o b u ś w ia tó w : b izn e s o w e g o i a p lik a c y jn e g o ;

•

u ż y tk o w e u s łu g i a p lik a c y jn e , za w ie ra ją c e w ie lo u ż y w a ln ą lo g ik ę a p lik a c ji;

•

u s łu g i b izn e s o w e u k ie ru n k o w a n e z a d a n io w o , z a w ie ra ją c e lo g ik ę p ro c e s ó w b izn e s o w y c h ;

•

u sługi b izn eso w e u k ie ru n k o w a n e p o d m io to w o , z a w ie ra ją c e lo g ik ę z w ią z a n ą z k o n k re tn y m i p o d m io ta m i b izn e s o w y m i;

•

u s łu g i p ro c e s o w e , egzystu jące w w a rs tw ie o rk ie s tra c ji usług.

UW AGA W tym podrozdziale będziemy kwalifikować usługi aplikacyjne jako „hybrydowe" albo „użytkowe", jednak w na­ stępnych rozdziałach pod pojęciem usług aplikacyjnych rozumieć będziemy wyłącznie usługi użytkowe.

9.7.1. Scenariusz nr 1: wyłącznie usługi hybrydowe G d y u s łu g i siecio w e są p o p ro s tu „ p rz y p in a n e ” do is tn ie ją c y c h ś ro d o w is k a p lik a c ji ro z p ro s z o n y c h lu b ro z w ią z a n ie b a zu ją c e n a u s łu g a c h s ie c io w y c h tw o rz o n e je s t b e z p e rs p e k ty w w ie lo u ż y w a ln o ś c i c z y m o d e lo w a n ia p ro c e s ó w b iz n e s o w y c h , w y n ik o w a a r c h ite k t u r a k s z ta łtu je się p o d o b n ie do p rz e d s ta w io n e j n a ry s u n k u 9 .7 , c z y li z a w ie ra m o n o lity c z n ą w a rs tw ę in te r fe js ó w u s łu g , z ło ż o n ą z h y b ry d o w y c h u słu g a p lik a c y jn y c h .

Rysunek 9.7. Usługi hybrydowe enkapsulujące zarówno logikę biznesową, jak i logikę aplikacyjną

306

RO ZD ZIAŁ 9 . ■ W A R S T W Y USŁUG

9.7.2. Scenariusz nr 2: usługi hybrydowe i usługi użytkowe O d m ia n ą p o p rz e d n ie j k o n fig u r a c ji je s t a rc h ite k tu ra u s łu g s ie c io w y c h , z a w ie ra ją c a d w ie w a rs tw y — h y b ry d o w e u s łu g i a p lik a c y jn e o ra z u ż y tk o w e u s łu g i a p lik a c y jn e . U s łu g i h y b ry d o w e m o g ą a n ­ g a ż o w a ć do k o m p o z y c ji n ie k tó re z w ie lo u ż y w a ln y c h u s łu g u ż y tk o w y c h . M a m y tu do c z y n ie n ia z p e w n y m s to p n ie m a b s tra k c ji, ja k o że u s łu g i u ż y tk o w e u s ta n a w ia ją w a rs tw ę a g n o s ty c z n ą , c z y li n ie ś w ia d o m ą p ro c e s ó w b iz n e s o w y c h (p a tr z ry s u n e k 9 .8 ).

Rysunek 9.8. Usługi hybrydowe komponujące dostępne usługi użytkowe

9.7.3. Scenariusz nr 3: biznesowe usługi zadaniowe i aplikacyjne usługi użytkowe T o p o d ejś cie o w o c u je a b s tra k c ją n a p o z io m ie b a rd z ie j s k o o rd y n o w a n y m , p o n ie w a ż lo g ik a p ro c e ­ s ó w b iz n e s o w y c h je s t c a łk o w ic ie re p re z e n to w a n a p rz e z w a rs tw ę u s łu g b iz n e s o w y c h u k ie ru n k o ­ w a n y c h z a d a n io w o . U s łu g i te z k o le i k o rz y s ta ją z w a rs tw y (a g n o s ty c zn y c h ) u s łu g a p lik a c y jn y c h w y k o n u ją c y c h całość p r z e tw a r z a n ia w y n ik a ją c e g o z lo g ik i b izn e s o w e j. K o n fig u ra c ję tę p rz e d s ta ­ w io n o n a ry s u n k u 9.9.

Rysunek 9.9. Usługi biznesowe ukierunkowane zadaniowo oraz użytkowe usługi aplikacyjne wyraźnie rozdzielają logikę biznesową od logiki aplikacyjnej

9 .7 . SCENARIUSZE K O NFIG URACJI W A R S T W Y USŁUG

307

9.7.4. Scenariusz nr 4: oba typy usług biznesowych i aplikacyjne usługi użytkowe T ę ko n fig u rację o trz y m u je m y , w staw iając p o m ię d z y d w ie w a rs tw y p o p rze d n ie j k o n fig u ra c ji w arstw ę usług b izn e so w ych zo rie n to w a n y c h p o d m io to w o . U s łu g i u k ie ru n k o w a n e z a d a n io w o m o g ą w tej sytu­ acji p e łn ić ro lę k o n tro le ró w k o m p o z y c ji a n g a żu jąc y c h (n a p o trz e b y re a liz a c ji lo g ik i p ro c e s ó w b iz n e ­ s o w ych ) z a ró w n o u słu g i z o rie n to w a n e p o d m io to w o , ja k i u sługi a p lik a c y jn e (p a trz ry s u n e k 9 .1 0 ).

Rysunek 9.10. Dwa typy usług komponowanych przez usługi ukierunkowane zadaniowo

9.7.5. Scenariusz nr 5: usługa procesowa i oba typy usług aplikacyjnych W ty m sc e n a riu s zu p o ja w ia się w a rs tw a o rk ie s tra c ji, z a w ie ra ją c a usługę p ro c e s o w ą (lu b k ilk a ta ­ k ic h u s łu g ) k o m p o n u ją c ą u s łu g i z o b u n iż s z y c h w a rs tw a p lik a c y jn y c h — h y b ry d o w e j i u ż y tk o w e j. T a często s p o ty k a n a k o n fig u ra c ja s ta n o w i w y n ik d o d a n ia w a rs tw y o rk ie s tra c ji do starszej a rc h i­ t e k tu r y ro z p ro s z o n e j w y k o rz y s tu ją c e j u s łu g i s ie c io w e (p a trz ry s u n e k 9 .1 1 ).

Rysunek 9.11. Warstwa orkiestracji zawierająca usługę procesową komponującą różne typy usług aplikacyjnych

308

RO ZD ZIAŁ 9 . ■ W A R S T W Y USŁUG

Z a u w a ż m y , że m im o iż usłu g i h y b ry d o w e k o m p o n o w a n e są p rz e z szc zy to w ą usługę p rocesow ą, je d n a k w c ią ż z a w ie ra ją w b u d o w a n e e le m e n ty lo g ik i b izn e s o w e j i ja k o ta k ie p o ś re d n io z w ią z a n e są z w a rs tw ą b izn e s o w ą . Z a u w a ż m y ta k że , iż u s łu g a p ro c e s o w a k o m p o n o w a ć m o ż e u s łu g i z o b u n iż ­ szych w a rs tw , c z y li ró w n ie ż u s łu g i u ż y tk o w e .

9.7.6. Scenariusz nr 6: usługa procesowa, biznesowe usługi zadaniowe i aplikacyjne usługi użytkowe N a d rz ę d n a usługa p ro ce s o w a m o ż e k o m p o n o w a ć z a ró w n o u ż y tk o w e u sługi a p lik a c y jn e , ja k i u sługi u k ie ru n k o w a n e z a d a n io w o , m im o iż te ostatn ie z a w ie ra ją lo g ik ę b izn e s o w ą . I choć z a p e w n ia ją one je d y n ie częściow ą ab stra k c ję , w p o łą c z e n iu z c e n tra liz a c ją d o k o n y w a n ą p rz e z usługę p ro c e s o w ą lo g ik a b iz n e s o w a ja k o całość n a d a l p o zo s ta je o d d z ie lo n a o d a p lik a c y jn e j (p a tr z ry s u n e k 9 .1 2 ).

Rysunek 9.12. Usługa procesowa komponująca usługi ukierunkowane zadaniowo oraz usługi aplikacyjne

9.7.7. Scenariusz nr 7: usługa procesowa, oba typy usług biznesowych i aplikacyjne usługi użytkowe D o d a n ie w a rs tw y u s łu g u k ie ru n k o w a n y c h p o d m io to w o s k u tk u je p o w s ta n ie m m o d e lu z c z te re m a w a rs tw a m i usług. S tra te g ic z n ie u m ie js c o w io n e u s łu g i u k ie ru n k o w a n e z a d a n io w o , o rk ie s tro w a n e p rz e z n a d rz ę d n ą usługę p ro c e s o w ą , o rg a n iz u ją k o m p o z y c je p o d p ro c e s ó w n a le żą c y c h z a ró w n o do w a rs tw y u s łu g z o r ie n to w a n y c h p o d m io to w o , ja k i d o w a r s tw y a p lik a c y jn y c h u s łu g u ż y tk o w y c h (p a trz ry s u n e k 9 .1 3 ).

9.7.8. Scenariusz nr 8: usługa procesowa, biznesowe usługi podmiotowe i aplikacyjne usługi użytkowe W ty m m o d e lu n a s tę p u je w y ra ź n e r o z d z ie le n ie lo g ik i b iz n e s o w e j i a p lik a c y jn e j z je d n o c z e s n ą m a k s y m a liz a c ją w ie lo u ż y w a ln o ś c i d z ię k i w y k o rz y s ty w a n iu w a rs tw y u sług a g n o s ty c z n y c h p ro c e sow o. C a ło ś ć lo g ik i specyficznej d la p ro c e s ó w b izn e s o w y c h z a rzą d z a n a je s t p rz e z usługę p rocesow ą, o rk ie s tru ją c ą u s łu g i u k ie ru n k o w a n e p o d m io to w o , k tó re z k o le i o rg a n iz u ją k o m p o z y c je a p lik a c y j­ n y c h u słu g u ż y tk o w y c h (p a tr z ry s u n e k 9 .1 4 ).

9 .7 . SCENARIUSZE KONFIG URACJI W A R S T W Y USŁUG

309

Rysunek 9.1 3 . Usługa procesowa i usługi biznesowe komponujące aplikacyjne usługi użytkowe

Rysunek 9.1 4 . Usługa procesowa orkiestrująca usługi ukierunkowane podmiotowo i komponujące usługi aplikacyjne

P O D S U M O W A N IE SOA może przyjmować różne kształty konfiguracyjne, zależne przede wszystkim od typów usług, z których jest budow ana. Hybrydowe usługi aplikacyjne spotykane są głównie w środowiskach zorientowanych usługowo, obejmujących logikę tradycyjnych („spadkowych") aplikacji rozproszonych. Poprzez strategiczne umiejscawianie usług biznesowych i orkiestracyjnych usług procesowych można uzyskać oddzielenie logiki biznesowej od logiki aplikacyjnej.

310

ROZDZIAŁ 9. ■ WARSTWY USŁUG

Część IV

Budowanie SOA (planowanie i analiza) R o z d z ia ł 10. S tra te g ie re a liz a c ji S O A R o z d z ia ł 11. A n a liz a z o rie n to w a n a n a u s łu g i (C zę ś ć I. W p r o w a d z e n ie ) R o z d z ia ł 12. A n a liz a z o rie n to w a n a n a u s łu g i (C zę ś ć I I . M o d e lo w a n ie u s łu g )

R o z d z ie le n ie a n a liz y b iz n e s o w e j, p r o je k to w a n ia i tw o r z e n ia a p lik a c ji to cecha ty p o w a d la w ię k ­ szości p ro je k tó w p ro g ra m is ty c z n y c h . A n a lity c y z b ie ra ją i d o k u m e n tu ją w y m a g a n ia b izn e s o w e , po c z y m p rz e k a z u ją je a rc h ite k to m i p ro g r a m is to m o d p o w ie d z ia ln y m z a p ro je k to w a n ie i b u d o w a n ie lo g ik i a u to m a ty z a c ji. P ro je k ty re a liz u ją c e ro z w ią z a n ia b a zu ją c e n a w sp ó łc ze s n e j S O A z m ie n ia ją n ie c o te n o b ra z , bo z a c ie ra ją w y ra ź n e d o tyc h c za s g ra n ic e o d d z ie la ją c e p o c z ą tk o w e fa zy . N a g ru n c ie S O A u w y d a tn io ­ n a zostaje b e z p o ś re d n ia z a le żn o ś ć m ię d z y in te lig e n c ją a n a liz y b iz n e s o w e j a u s łu g a m i r e p re z e n tu ­ ją c y m i i im p le m e n tu ją c y m i lo g ik ę b izn e s o w ą . P rz e k ła d a się to n a k o n ie c zn o ś ć u n ik a to w e j f o r m y a n a liz y , k tó rą w y k o n a ć n a le ż y p rz e d r o z p o ­ częciem p ro je k to w a n ia po s zc zeg ó ln y c h usług, co w y ja ś n ia m y d o k ła d n ie w treści r o z d z ia łó w 11. i 12. Z a n im je d n a k z a jm ie m y się s z c ze g ó ła m i tej a n a liz y , p o ś w ię c im y n ie c o u w a g i o rg a n iz a c ji p r o je k ­ tó w , k tó ry c h c e le m je s t b u d o w a n ie u s łu g z in te n c ją w y k o rz y s ty w a n ia ic h ja k o ś ro d k ó w e w o lu c ji in fr a s tr u k tu r y w k ie r u n k u S O A .

Rozdział 10

IM N T A

U *

'« 7 ? r ssm

I

4 » W >,

STO! ' t a * I* lll V

Strategie realizacji SOA 10.1. F a z y c y k lu ż y c io w e g o S O A 10.2. S tra te g ia z s tę p u ją c a 10.3. S tra te g ia w s tę p u ją c a 10.4. S tra te g ia z w in n a

314

RO ZDZIAŁ 1 0 . ■ STRATEGIE REALIZACJI SOA

R o z d z ia ł te n p o ś w ię c a m y g łó w n y m fa z o m (e ta p o m ) b u d o w a n ia i w d ra ż a n ia usług o ra z s tra te g io m a ra n ż u ją c y m te fa z y w o k re ś lo n e sekw encje, z g o d n ie z u s ta lo n y m i p rio ry te ta m i o rg a n iz a c y jn y m i.

Analizy przypadków : T L S i R a ilC o p r z y ję ły ró ż n e s tra te g ie r e a liz a c ji S O A , co z ilu s tr u je m y w ra m a c h k o le jn y c h a n a liz p rz y p a d k ó w .

10.1. Fazy cyklu życiow ego SOA C y k l ż y c io w y re a liz a c ji S O A to p o p ro s tu seria k r o k ó w , k tó re n a le ż y w y k o n a ć w celu u tw o rz e n ia u słu g s k ła d a ją c y c h się n a k o n k re tn e r o z w ią z a n ie z o rie n to w a n e u s łu g o w o .

10.1.1. Podstawowe fazy realizacji SOA B u d o w a n ie ro z w ią z a n ia z o rie n to w a n e g o usługow o n a p ie rw s zy rz u t o k a n ie ró ż n i się w y ra ź n ie od b u ­ d o w a n ia tra d y c y jn y c h a p lik a c ji ro z p ro s z o n y c h : p ro je k to w a n e są i tw o rz o n e u s łu g i s ie c io w e , k tó re następnie są w d ra ża n e — to w szystko p rz y u życiu i z u w z g lę d n ie n ie m s ta n d a rd o w y c h k o m p o n e n tó w z g o d n y c h z te c h n o lo g ia m i in te rfe js u c zo ło w eg o ( fr o n t- e n d ) i zap lecza (b a c k -e n d ). G d y je d n a k w zią ć p o d uw agę o m a w ia n e w p o p rz e d n im ro z d z ia le m o d e le usłu g i ic h w a rs tw y abstra k c ji, d o s trze g a m y is to tn ą ró ż n ic ę z m u s zają c ą do p e w n e g o z re w id o w a n ia tra d y c y jn e g o po d ejścia do p ro je k tu . R z u t o k a n a ry s u n e k 10.1 m o ż e r o d z ić p y ta n ie , dlaczeg o d w ie p ie rw s ze z p re z e n to w a n y c h fa z k w a lifik o w a n e są ja k o „ z o rie n to w a n e u s łu g o w o ”, po d czas g d y p o zo s ta łe o d n o s zo n e są je d y n ie do „ u s łu g ” . O tó ż , g łó w n y m te g o p o w o d e m je s t fa k t, iż w ła ś n ie n a ty c h d w ó c h e ta p a c h c a ły p r o je k t n a c e c h o w a n y zo s ta je z a s a d a m i z o r ie n to w a n ia n a u s łu g i, k tó r e o m a w ia liś m y d o ty c h c z a s w tej książce, i d zię ki te m u zasady te z n a jd u ją odzw iercied len ie w tw o rz o n y m ro zw ią za n iu ; analiza i p ro je k ­ to w a n ie zostają ty m zasadom w p e łn i p o d p o rzą d k o w a n e i to jest w łaśnie w y n ik w sp o m n ian eg o w cze­ śniej z re w id o w a n ia p odejścia stosow anego p rz y p ro je k to w a n iu tra d y c y jn y c h aplik a c ji rozp ro szo n ych .

1f

yf

Analiza zorientowana usługowo

Tworzenie usług

Wdrażanie usług

>

>f

Projektowanie zorientowane usługowo

Testowanie usług

f

Administrowanie usługami

Rysunek 10.1. Podstawowe fazy cyklu życiowego SOA

P r z y jr z y jm y się d o k ła d n ie j specyfice p o s z c z e g ó ln y c h faz.

1 0 .1 . FAZY CYKLU ŻY C IO W E G O SOA

315

10.1.2. Analiza zorientowana usługowo N a ty m , p o c z ą tk o w y m , etapie n astępuje okre ś le n ie p o te n c ja ln e g o zakresu b u d o w a n e j S O A . Id e n ty ­ fik o w a n e są w a rs tw y u s łu g , m o d e lo w a n e są ta k że p o s zc zeg ó ln e u s łu g i ja k o w s tę p n e k a n d y d a tu ry n a s k ła d n ik i te jże S O A . F o r m a ln ie o p is z e m y p roces m o d e lo w a n ia usłu g , k r o k po k r o k u , w r o z ­ d z ia ła c h 11. i 12. d e d y k o w a n y c h te m u e ta p o w i.

10.1.3. Projektowanie zorientowane usługowo S ko ro z r o z u m ie m y ju ż , co c h c e m y z b u d o w a ć , n a le ż y się z a s ta n o w ić , j a k to w y k o n a ć . P ro je k to w a ­ n ie z o rie n to w a n e u słu g o w o to fa za siln ie o p a rta n a s ta n d a rd a c h , k o n w e n c ja c h p rz e m y s ło w y c h i — oczyw iście — zasad ach z o rie n to w a n ia n a u s łu g i. P ro je k ta n c i stają tu p rz e d k o n ie c zn o ś c ią p o d ję c ia k lu c z o w y c h d e c y z ji d o ty c z ą c y c h z a k re ś le n ia w y ra ź n y c h g ra n ic m ię d z y p o r c ja m i lo g ik i e n k a p s u lo w a n e j p rz e z p o szczeg ó ln e u s łu g i. W y o d rę b n ia n e n a ty m e ta p ie w a rs tw y u s łu g m o g ą z a w ie ra ć w a rs tw ę o rk ie s tra c ji, co r ó w n a się s fo rm u ło w a n iu fo r m a ln y c h d e fin ic ji p ro c e s ó w b izn e s o w y c h . C z te re m fo r m a ln y m p ro c e s o m p r o je k to w a n ia z o rie n to w a n e g o u s łu g o w o p o ś w ię c a m y c z te ry o d ­ d z ie ln e ro z d z ia ły tej k s ią ż k i, o d 13. do 16.

10.1.4. Tworzenie usług N a s tę p n a fa z a to — o c zy w iś c ie — tw o rz e n ie s a m y c h usług. N a ty m e ta p ie u w id a c z n ia się z a le ż ­ ność o d u ż y w a n y c h te c h n o lo g ii; szczególnie w y b ó r k o n k re tn e g o ję z y k a (ję z y k ó w ) p ro g r a m o w a n ia i ś ro d o w is k a p ro g ra m is ty c z n e g o d e c y d u je o fiz y c z n e j fo r m ie u s łu g i o rk ie s tro w a n y c h p ro c e s ó w b iz n e s o w y c h , p r z y z a c h o w a n iu ic h zg o d n o ś c i z p ro je k te m . W ro z d z ia le 18. z a jm ie m y się p ro b le ­ m a ty k ą tw o rz e n ia u słu g w ś ro d o w is k a c h .N E T i J 2 E E o ra z te c h n o lo g ia m i w s p o m a g a ją c y m i, z w ią ­ z a n y m i z t y m i ś ro d o w is k a m i.

10.1.5. Testowanie usług Z w a ż y w s z y n a g e n e ry c z n ą n a tu r ę tw o rz o n y c h u s łu g i p o te n c ja ln e m o ż liw o ś c i ic h w ie lo u ż y w a n ia i k o m p o n o w a n ia w s y tu a c ja c h n ie m o ż liw y c h do p rz e w id z e n ia a p r io r i, z r o z u m ia ła staje się p o ­ trz e b a ry g o ry s ty c zn e g o ic h p rz e te s to w a n ia p rz e d w d ro ż e n ie m w ś ro d o w is k u p ro d u k c y jn y m . O to lis ta p rz y k ła d o w y c h p y ta ń , n a k tó re te s to w a n ie u s łu g i m a dać o d p o w ie d ź lu b p r z y n a jm ­ n ie j ją p rz y b liż y ć . •

Jakie ty p y usług n a le ży w zią ć p o d uw agę ja k o p o te n c ja ln y c h w n io s k o d a w c ó w d la danej usługi?

•

C z y us łu g a s p e łn ia w s zy s tk ie w a r u n k i w y ra ż o n e p rz e z asercje p o lity k i?

•

Jakich ty p ó w w y ją tk ó w i s y tu a c ji a w a ry jn y c h n a le ż y się s p o d z ie w a ć w z w ią z k u z fu n k c jo n o w a n ie m usługi?

• •

C z y opis u s łu g i k o m u n ik u je je j s e m a n ty k ę w c z y te ln y sposób? C z y z re w id o w a n y opis u s łu g i z a w ie ra z m ia n y lu b ro z s z e rz e n ia w s to s u n k u do p o p rz e d n ie j w ersji?

•

Jak ła tw o usłu g a m o ż e b y ć a n g a ż o w a n a do u c z e s tn ic tw a w k o m p o z y c ji?

•

Jak d o b rz e w y k ry w a ln y je s t op is usługi?

•

C z y w y m a g a n a je s t zg o d n o ś ć u s łu g i ze s p e c y fik a c ja m i W S - I P ro file s ?

316

RO ZDZIAŁ 1 0 . ■ STRATEGIE REALIZACJI SOA

•

Jakie p ro b le m y d o ty c zą ce ty p o w a n ia d a n y c h m o g ą w y s tą p ić w ra m a c h usługi?

•

C z y m o ż liw e je s t z id e n ty fik o w a n ie w s z y s tk ic h a k ty w n o ś c i i w s z y s tk ic h k o m p o z y c ji, w k tó re usłu g a m o ż e b y ć za a n g a żo w a n a ?

• •

C z y p ro c e s y k o m p e n s a c y jn e a k ty w n o ś c i b iz n e s o w y c h z o s ta ły g ru n to w n ie p rze te s to w a n e ? Jakie m o g ą b y ć k o n s e k w e n c je w y s tą p ie n ia e w e n tu a ln e g o w y ją tk u w re a liz a c ji pro c e s u k o m p e n s a c y jn e g o ?

• •

C z y w szystk ie n o w e u s łu g i zg o d n e są z is tn ie ją c y m i s ta n d a rd a m i p ro je k to w y m i? C z y w z w ią z k u z n o w y m i u s łu g a m i d e fin io w a n e są n o w e ty p y n a g łó w k ó w S O A P ? Jeśli ta k , to c z y w s zy s tk ie p o te n c ja ln e u s łu g i-w n io s k o d a w c y (w ty m r ó w n ie ż u s łu g i p o ś re d n ic z ą c e ) z d o ln e są do p o p ra w n e g o ro z p o z n a w a n ia i p o p ra w n e g o p rz e tw a rz a n ia ty c h n a g łó w k ó w ?

•

C z y n o w e u sługi p o w o d u ją p o w s ta w a n ie w y m a g a ń fu n k c jo n a ln y c h lu b w y m a g a ń w zakresie Q o S , k tó ry m bieżąca a rc h ite k tu ra n ie je s t w stanie sprostać?

10.1.6. Wdrażanie usług E ta p im p le m e n ta c ji to fe s tiw a l a tra k c ji z w ią z a n y c h z in s ta lo w a n ie m n a s e rw e rze (s e rw e ra c h ) p r o ­ d u k c y jn y m i k o n fig u r o w a n ie m k o m p o n e n tó w ro z p ro s z o n y c h , in te rfe js ó w u s łu g i r o z m a ity c h p r o d u k tó w m id d le w a r e . T y p o w e p y ta n ia i w ą tp liw o ś c i, k tó re m o g ą p o ja w ić się w tej fa zie , są n a ­ stępujące. • •

W ja k i sposób n a le ż y ro z p ro s z y ć usługi? C z y is tn ie ją c a in fr a s tr u k tu r a z d o ln a je s t s p e łn ić w y m a g a n ia w z a k re s ie p rz e tw a rz a n ia w s z y s tk ic h usług?

•

Jak w p ro w a d z e n ie n o w y c h u s łu g w p ły n ie n a fu n k c jo n o w a n ie is tn ie ją c y c h u s łu g i ap lik a c ji?

•

Jak n a le ż y w d ra ż a ć i p o z y c jo n o w a ć u s łu g i w y k o rz y s ty w a n e p rz e z w ie le ro z w ią z a ń ?

•

W ja k i sposób w p ro w a d z a n ie p o s z c z e g ó ln y c h k o m p o n e n tó w m id d le w a r e w p ły n ie n a is tn ie ją c e śro d o w is k o ?

•

C z y w z w ią z k u z b ie ż ą c y m w d ro ż e n ie m p o ja w ia ją się n o w e o p is y u s łu g , k tó re p o w in n y eg zysto w ać ró w n o le g le z d o ty c h c z a s o w y m i lu b je zastąpić?

•

Jakie p a ra m e try z a b e zp ie c z e ń są w y m a g a n e i za p o m o c ą ja k ic h ś ro d k ó w z a m ie rz a się je osiągnąć?

•

Jak fu n k c jo n o w a ć b ę d ą i ja k b ę d ą u tr z y m y w a n e p u le u s łu g m a ją c e sprostać w y m a g a n io m s k a lo w a n ia w p la n o w a n y c h o ra z n ie p rz e w id y w a ln y c h sytuacjach?

•

C z y i ja k k o n tro lo w a n e b ę d z ie fu n k c jo n o w a n ie „ s p a d k o w y c h ” s y s te m ó w c e c h u ją c y c h się o g ra n ic z e n ia m i w z a k re s ie w y d a jn o ś c i lu b n ie za w o d n o ś c i?

UW AGA Podobnie jak tw orzenie usług, ta k i ich w drażanie jest specyficzne dla platformy technologicznej użytej do ich w ytw arzania. W rozdziale 18. zajm iem y się w ybranym i szczegółami fizycznej im plem entacji usług w środo­ wiskach J2EE i .NET.

1 0 .1 . FAZY CYKLU ŻY C IO W E G O SOA

317

10.1.7. Administrowanie usługami U s łu g i p o w d ro ż e n iu stają się o b ie k te m z a b ie g ó w a d m in is tra c y jn y c h . A d m in is tr o w a n ie u s łu g a m i r ó ż n i się o d a d m in is t r o w a n ia a p lik a c ja m i b a z u ją c y m i n a k o m p o n e n t a c h t y m , że w p e w n y c h k o n te k s ta c h o d n o s i się do z e s ta w ó w u s łu g ja k o całości (w p rz e c iw ie ń s tw ie do u s łu g p o s trz e g a ­ n y c h ja k o e le m e n ty określo n ej a p lik a c ji). T u ró w n ie ż n a le ży ro zs trzy g n ą ć k ilk a k lu c z o w y c h k w e s tii, z w ią z a n y c h m ię d z y in n y m i z •

m o n ito r o w a n ie m w y k o rz y s ty w a n ia u sług,

•

z a rz ą d z a n ie m w e rs ja m i d o k u m e n tó w o p is ó w usłu g ,

•

z a rz ą d z a n ie m k o m u n ik a ta m i i ic h m o n ito r o w a n ie m ,

•

w y k ry w a n ie m „ w ą s k ic h g a rd e ł” p rz e tw a rz a n ia .

UW AGA Testow aniem usług i adm inistrow aniem usługami nie będziemy się zajm ow ać w tej książce.

10.1.8. Strategie wdrożeniowe SOA P o s zc z e g ó ln e fa z y c y k lu ż y c io w e g o S O A z id e n ty fik o w a n e w p u n k c ie 1 0 .1 .1 z o s ta ły ta m u ło ż o n e w p o g lą d o w ą ścieżkę re p re z e n tu ją c ą b u d o w a n ie p o s z c z e g ó ln y c h u sług. D la c e ló w p ra k ty c z n y c h fa z y te n a le ż y je d n a k z o rg a n iz o w a ć w r a m y p ro c e s u , k tó ry : •

o d z w ie rc ie d li p re fe re n c je w z a k re s ie ty p ó w tw o rz o n y c h w a rs tw usług;

•

s k o o rd y n u je re a liz a c ję u s łu g a p lik a c y jn y c h , u s łu g b iz n e s o w y c h i u s łu g p ro c e s o w yc h ;

•

u ła tw i tra n s fo rm a c ję w k ie r u n k u s ta n d a ry z o w a n e j S O A , p o m a g a ją c je d n o c z e ś n ie w o s ią g n ię c iu d o ra ź n y c h c e ló w s p e c y fic z n y c h d la p ro je k tu .

S z c z e g ó ln ie o s ta tn i z w y m ie n io n y c h c e ló w k r y je w s o b ie n ie la d a w y z w a n ie . S ukces S O A w p rz e d s ię b io rs tw ie je s t g e n e ra ln ie z a le ż n y o d s to p n ia je j s ta n d a ry z a c ji p rz y w p r o w a d z a n iu do d o m e n y b izn eso w ej i a p lik a c y jn e j, je d n a k że sukces p ro je k tu w p ro w a d za ją c e g o ro z w ią z a n ie z o rie n ­ to w a n e n a u s łu g i m ie r z o n y je s t ta k ż e s to p n ie m , w ja k im p r o je k t te n re a liz u je p o k ła d a n e w ty m r o z w ią z a n iu o c z e k iw a n ia , w z a ło ż o n y c h ra m a c h c za s o w y c h i b u d ż e to w y c h . B y te n p r o b le m r o z w ią z a ć , p o tr z e b u je m y o d p o w ie d n ie j s tra te g ii. M u s i o n a o p ie ra ć się n a p r io ry te ta c h o rg a n iz a c y jn y c h , b o je s t to n ie z b ę d n e do p o g o d z e n ia d łu g o fa lo w y c h c e ló w m ig r a ­ c y jn y c h z d o r a ź n y m i c e la m i k r ó t k o t e r m in o w y m i. O w o c e m w ie lo le tn ic h d o ś w ia d c z e ń n a p o lu w y tw a r z a n ia i w d r a ż a n ia p r o je k tó w in fo r m a ty c z n y c h są t r z y n a s tę p u ją c e , m o d e lo w e s tra te g ie , w r ó ż n y sposób a ta k u ją c e p r z e d m io to w y p ro b le m : •

s tra te g ia z s tę p u ją c a ( to p - d o w n ) , z w a n a ta k ż e p o d e jś c ie m o d o g ó łu d o s z c z e g ó łó w ,

•

s tra te g ia w s tę p u ją c a ( b o tto m - u p ) , z w a n a ta k że p o d e jś c ie m o d s z c z e g ó łó w d o o g ó łu ,

•

s tra te g ia z w in n a (a g ile ), p o g lą d o w o z w a n a r ó w n ie ż „ s p o tk a n ie m p o ś ro d k u ” ( m e e t- in - th e - m id d le ).

318

RO ZDZIAŁ 1 0 . ■ STRATEGIE REALIZACJI SOA

R ó ż n ią się o n e s tru k tu r ą p rz y ję ty c h p r io r y te tó w i u w a ru n k o w a n ia m i p ra k ty c z n y m i. O p is z e m y je szczegółow o w k o le jn y c h p o d ro zd zia ła c h , w skazując korzyści i p ro b le m y w y n ik a ją c e z k ażd ej z nich. O d w y b o ru o k re ś lo n e j s tra te g ii z a le ż y o s ta te c zn y w y n ik re a liz a c ji p ro je k tu , a k a ż d a ze s tra te g ii s ta w ia p r o je k ta n tó w p rz e d k o n ie c z n o ś c ią p o d e jm o w a n ia k lu c z o w y c h d e c y z ji o d łu g o fa lo w y c h n ie k ie d y k o n s e k w e n c ja c h . P ie rw s z ą a b s o lu tn ie d e c y zją je s t w ię c rz e c z o n y w y b ó r o d p o w ie d n ie j s tra te g ii, b o to o n d e te r m in u je s to p ie ń , w ja k im w y s iłe k z a in w e s to w a n y w m o d e lo w a n ie i p r o ­ je k to w a n ie p rz e ło ż y się n a w y k o rz y s ta n ie p o te n c ja łu S O A .

UW AGA Czytelnicy niezainteresow ani szczegółami kroków składających się na opisyw ane strategie mogą bez szkody dla dalszej lektury pominąć ich opisy i przejść od razu do punktu podsum owującego zalety i w ady konkretnej strategii.

P O D S U M O W A N IE •

Podstaw ow y cykl życiowy SOA składa się z serii faz podobnych do tych, które tw orzą tradycyjne projekty programistyczne.

•

SOA w prow adza unikatow e uw arunkow ania na konstrukcję i w drażanie usług.

•

Fazy cyklu życiowego SOA mogą być organizow ane w edług różnych strategii, dostarczających różne układy specjalizowanych w arstw usług.

10.2. Strategia zstępująca T a s tra te g ia to p o d e jś c ie ty p u „ n a jp ie r w a n a liz a ” n ie ty lk o w y m a g a ją c e z o r ie n to w a n ia p ro c e s ó w b iz n e s o w y c h n a u s łu g i, le c z ta k ż e p ro m u ją c e u tw o rz e n ie (lu b d o s to s o w a n ie ) o g ó ln e g o m o d e lu b izn e s o w e g o p rz e d s ię b io rs tw a . Jest to w ię c s tra te g ia ściśle z w ią z a n a z is tn ie ją c ą lo g ik ą b izn e s o w ą lu b z n ie j w y p ro w a d z a n a . S tra te g ia z s tę p u ją c a s p rz y ja k r e o w a n iu w s z y s tk ic h tr z e c h w a rs tw u s łu g o w y c h , o p is y w a n y c h w p o p rz e d n im ro z d z ia le . Jej re z u lta te m je s t za zw y c z a j u tw o rz e n ie p e w n e j lic z b y w ie lo u ż y w a ln y c h u s łu g b iz n e s o w y c h i a p lik a c y jn y c h .

10.2.1. Proces S tra te g ia zs tę p u ją c a z a w ie ra z w y k le n ie k tó re lu b w s zy s tk ie z k r o k ó w p o k a z a n y c h n a ry s u n k u 10.2. Z a u w a ż m y , iż z a k ła d a o n a u p rz e d n ie z d e fin io w a n ie w y m a g a ń b izn e s o w y c h .

Etap nr 1: definiowanie korporacyjnych m odeli biznesowych F o rm a t m o d e li p rz e d s ię b io rs tw a je s t z r e g u ły s p e c y fic z n y d la d o m e n b iz n e s o w y c h tego p rz e d s ię ­ b io rs tw a . W ś r ó d ty c h m o d e li w y s tę p u je najczęściej fo r m a ln a o n to lo g ia , m o d e l p o d m io tó w (e n c ji) p rz e d s ię b io rs tw a , m o d e l je g o d a n y c h i a rc h ite k tu ra ic h s ta n d a rd o w e j re p re z e n ta c ji (z w y k le r e a li­ z o w a n a p o p rz e z k o le k c ję s ta n d a rd o w y c h s c h e m a tó w X M L ) , a ta k że in n e f o r m y m o d e li s p e c y fic z­ n y c h d la a rc h ite k tu ry in fo rm a ty c z n e j d a n e g o p rz e d s ię b io rs tw a .

1 0 .2 . STR ATEG IA ZSTĘPUJĄCA

319

Kroki Definiowanie korporacyjnych modeli biznesowych

Krok 2

>f

Definiowanie modelu usług przedsiębiorstwa

i

i

Rysunek 10.2. Typowe kroki strategii zstępującej

N ie k tó r e ze w s p o m n ia n y c h m o d e li d o s ta rc z a ją b iz n e s o w o u k ie ru n k o w a n e g o s p o jrz e n ia n a o rg a n iz a c ję , s ta n o w ią w ię c c e n n e ź r ó d ła d la c e ló w id e n ty fik o w a n ia w y m a g a n y c h u s łu g b iz n e s o ­ w y c h . M o d e le p o d m io tó w (e n c ji) p rz e d s ię b io rs tw a p rz e k ła d a ją się n ie m a l b e z p o ś re d n io n a u s łu g i b izn e s o w e u k ie ru n k o w a n e p o d m io to w o . J a k k o lw ie k r o z p a tru je m y tu d e fin io w a n ie m o d e li b iz n e s o w y c h w y s o k o p o z io m o w o , w u ję c iu p o je d y n c z e g o p ro c e s u , w rz e c zy w is to ś c i z a d a n ie to w y k o n y w a n e je s t p rz e w a ż n ie ja k o g ru p a p r o ­ cesów re a liz o w a n y c h w fo r m ie o d rę b n y c h p r o je k tó w o p ra c o w y w a n y c h p rz e z o d rę b n e g ru p y r o ­ b o c ze. Jeśli je d n a k w d a n y m p rz e d s ię b io rs tw ie fu n k c jo n u ją ju ż m o d e le b izn e s o w e , z a d a n ie ic h z d e fin io w a n ia s p ro w a d z a się do ic h p o p ra w n e j id e n ty fik a c ji.

Etap nr 2: komponowanie SOA T e n etap o d p o w ia d a p ro c e s o w i o p is a n e m u s zc ze g ó ło w o w p o d ro z d z ia le 1 4 .1 , „ E ta p y k o m p o n o ­ w a n ia S O A ” . G d y sto s o w a n a je s t s tra te g ia zs tę p u ją c a , k r o k te n p o s trz e g a n y je s t ra c ze j ja k o ele ­ m e n t w s tę p n e j a n a liz y p o p rz e d z a ją c e j tw o rz e n ie u s łu g i ja k o ta k i tra k to w a n y je s t ja k o część fa z y p ro je k to w a n ia z o rie n to w a n e g o u s łu g o w o .

Etap nr 3: definiowanie modelu usług przedsiębiorstwa N a ty m e ta p ie n a s tę p u je b u d o w a n ie s p e c y fic z n e g o m o d e lu — m o d e lu u s łu g p r z e d s ię b io rs tw a ( e n te r p ris e s e rv ic e m o d e l). Jego s p e c y fik a c ja s ta n o w i fo r m a ln e u d o k u m e n to w a n ie p la n o w a n e g o in w e n ta rz a u słu g , w ra m a c h k tó re g o d e fin io w a n a je s t w ię k s zo ś ć (lu b n ie k ie d y k o m p le t) k a n d y ­ d a tu r n a u słu g i. W m o d e lu ty m z d e fin io w a n e zo s ta ją ta k ż e w a rs tw y u sług, w y o d rę b n io n e n a e ta ­ p ie 2., d z ię k i c z e m u w y ła n ia się o g ó ln y o b ra z u s łu g p rz e d s ię b io rs tw a w s ta n d a rd o w e j, w a rs tw o w e j a ra n ż a c ji. Jak p o k a z a n o n a ry s u n k u 1 0 .2 , m o ż liw e je s t p e w n e o d s tę p s tw o o d ściśle s e k w e n c y jn e g o p rz e ­ b ie g u s tra te g ii, w p o sta c i ite ra c y jn e g o s p rz ę że n ia z w ro tn e g o m ię d z y n in ie js z y m e ta p e m a e ta p e m n a s tę p n y m — a n a liz ą z o rie n to w a n ą u s łu g o w o . Is to tn ie , z a le c a n ą p r a k ty k ą je s t w y k o n y w a n ie ta ­ k ie j ite ra c ji d la ka żd e g o zn a n e g o p ro c e s u b izn e s o w e g o , p o n ie w a ż p rz y c z y n ia się o n a do b a rd z ie j

320

RO ZDZIAŁ 1 0 . ■ STRATEGIE REALIZACJI SOA

a d e k w a tn e g o w y o d r ę b n ia n ia ( i u le p s z a n ia ) w s p o m n ia n e g o in w e n t a r z a k a n d y d a tu r n a u s łu g i (s zc z e g ó ln ie k a n d y d a tu r a g n o s ty c z n y c h ) jeszcze p rz e d ro z p o c z ę c ie m w ła ś c iw e g o p ro je k to w a n ia i p ro g r a m o w a n ia usług.

Etap nr 4: przeprowadzanie analizy zorientowanej usługowo A n a liz ie z o rie n to w a n e j u s łu g o w o p o ś w ię c a m y ro z d z ia ły 11. i 12.

Etap nr 5: przeprowadzanie projektowania zorientowanego usługowo N a ty m e ta p ie z o s ta ją f o r m a ln ie z d e fin io w a n e w a r s tw y u s łu g , w sposób o p is y w a n y s z c ze g ó ło w o w r o z d z ia ła c h o d 13. d o 16.

Etap nr 6: tworzenie wymaganych usług K o le jn y etap to fiz y c z n e tw o rz e n ie (p r o g ra m o w a n ie ) u s łu g z g o d n ie z ic h s p e c y fik a c ją p ro je k to w ą i o p is a m i, b ę d ą c y m i w y n ik a m i a n a liz y p r z e p ro w a d z o n e j n a eta p ie 4.

Etap nr 7: testowanie usług i wszystkich ich operacji N a ty m eta p ie n a s tę p u je te s to w a n ie w s z y s tk ic h o p e ra c ji w s z y s tk ic h u s łu g w celu z a p e w n ie n ia , iż operacje te s p e łn ia ją p rz y ję te w y m a g a n ia w zakresie ja k o ś c io w y m . Z a k re s tego te s to w a n ia w y k ra c z a z w y k le p o z a te s to w a n ie w y m a g a n e p rz e z lo g ik ę tw o rz o n e g o r o z w ią z a n ia z o c zy w is te g o p o w o d u : te s to w a n e u s łu g i, ja k o w ie lo u ż y w a ln e i k o m p o n o w a ln e , w y k o rz y s ty w a n e b ę d ą p r a w d o p o d o b n ie ró w n ie ż p o z a k o n te k s te m tego k o n k re tn e g o ro z w ią z a n ia i ic h zd o ln o ś ć do fu n k c jo n o w a n ia w ty c h w a ru n k a c h ró w n ie ż trz e b a g ru n to w n ie z w e ry fik o w a ć .

Etap nr 8: wdrażanie usług P rze te s to w a n e u s łu g i in s ta lo w a n e są i w d ra ż a n e ja k o e le m e n ty ro z w ią z a n ia , c h o ć w d ra ż a n ie to p o w in n o u w z g lę d n ia ć p o te n c ja ł w ie lo u ż y w a ln o ś c i p re z e n to w a n y p rz e z te u s łu g i. O z n a c z a to n ie ty lk o b r a k o g ra n ic z e ń u s łu g do o b s za ru k o n k re tn e g o r o z w ią z a n ia , le c z ta k że z a p e w n ie n ie o d p o ­ w ie d n ie j m o c y o b lic z e n io w e j (n a u ż y te k p o te n c ja ln ie w ie lu u s łu g -w n io s k o d a w c ó w ) o ra z s p e łn ie ­ n ie o k re ś lo n y c h w y m a g a ń w z a k re s ie b e z p ie c z e ń s tw a i k o n tr o li d o s tę p u .

10.2.2. Za i przeciw R e z u lta te m za s to s o w a n ia s tra te g ii zs tę p u ją c e j b u d o w a n ia S O A je s t z w y k le z d e fin io w a n ie w y s o k ie j ja k o ś c i a rc h ite k tu ry usłu g . P r o je k t i p a r a m e tr y k a ż d e j u s łu g i zo s ta ją g ru n to w n ie p rz e a n a liz o w a n e , d z ię k i c z e m u u s łu g i te tw o rz o n e są ja k o w ie lo u ż y w a ln e i p rz e ja w ia ją c e d u ż ą z d o ln o ś ć do w ią z a n ia w ko m p o zy c je . S tw arza to s o lid n y fu n d a m e n t p o d ze s ta n d aryzo w a n ą i sfederow aną s tru k tu rę p rz e d ­ siębiorstw a, k tó re j to s tru k tu rze usługi za p e w n ia ją za ró w n o d u ż y s topień adaptow alności, ja k i u je d ­ n o lic a n ia istniejących n iejed n o ro d n o ści. T o w s z y s tk o m a je d n a k s w o ją c e n ę w w y m ia r z e z a r ó w n o e k o n o m ic z n y m , ja k i c z a s o w y m . P rz e d s ię b io rs tw a d e c y d u ją c e się n a s tra te g ię zs tę p u ją c ą m u s z ą n a w s tę p ie z a in w e s to w a ć sporo ś ro d k ó w i p o ś w ię c ić s p o ro czasu (p ro p o rc jo n a ln ie do sw ego r o z m ia r u o ra z z ło ż o n o ś c i p la n o w a ­ n y c h ro z w ią z a ń ) o ra z w y k a z a ć s p o ro c ie rp liw o ś c i w o c z e k iw a n iu n a p ie rw s ze w y m ie r n e efe k ty .

1 0 .3 . STR ATEG IA W STĘPU JĄC A

321

A N A LIZA PRZYPADKU

W f ir m ie T L S p rz y p ie rw s z y m p o d e jś c iu do u s łu g tw o rz ą c y c h s ystem B 2B za s to s o w a n o o d ­ m ia n ę s trate g ii zstępującej (o g ra n ic z o n ą do k o n k re tn e j d o m e n y b izn e s o w e j); o trz y m a n o w re ­ zu lta c ie z b ió r u słu g b iz n e s o w y c h i a p lik a c y jn y c h , z e s ta n d a ry z o w a n y c h i w ysoce w ie lo u ż y w a ln y c h . M o ż liw o ś ć re k o m p o n o w a n ia tego p o c zą tk o w e g o z b io ru usług w ro z m a ite k o n fig u ra c je , sto s o w n ie do z m ie n ia ją c y c h się w y m a g a ń b iz n e s o w y c h , o k a z a ła się p r a w d z iw y m sukcesem . O c z e k iw a n ie n a te n sukces, s p o w o d o w a n e g łó w n ie d łu g o tr w a ły m p ro c e s e m a n a liz y , b y ło je d n a k p rzy g n ę b ia ją c e . T e ra z , g d y w s p o m n ia n e u s łu g i s ta ły się k lu c z o w y m i e le m e n ta m i ś ro ­ d o w is k a te c h n o lo g ic z n e g o T L S , w c ią ż p o ja w ia się w ie le n o w y c h w y m a g a ń , s k u tk u ją c y c h tw o ­ rz e n ie m n o w y c h u s łu g , a n a w e t n o w y c h r o z w ią z a ń . In fo r m a ty c y p ra c u ją p o d d u ż ą p re s ją sz yb kieg o d o s ta rc z a n ia p o trz e b n y c h p r o d u k tó w — i c hoć za s to s o w a n ie s tra te g ii zstęp u jącej o k a za ło się n ie k w e s tio n o w a n y m sukcesem , to je d n a k w y ją tk o w o n ie c h ę tn ie m y ś lą o p rz e c h o ­ d z e n iu p rz e z te n proces jeszcze raz.

P O D S U M O W A N IE •

Strategia zstępująca przyczynia się do sform ułowania formalnych definicji biznesowych modeli korporacyjnych przed określeniem funkcjonalnych granic poszczególnych usług.

•

Efektem strategii zstępującej może być SOA na najwyższym poziom ie jakościow ym , w ym aga to jednak sporych nakładów w zakresie w stępnej analizy.

10.3. Strategia w stępująca Is to tą s tra te g ii w s tę p u ją c e j ( b o tto m - u p ) je s t tw o rz e n ie u s łu g ja k o ś ro d k ó w z a p e w n ia ją c y c h s p e ł­ n ie n ie d o ra ź n y c h w y m a g a ń o c h a ra k te rz e a p lik a c y jn y m . U s łu g i s ie c io w e m o d e lo w a n e są g łó w n ie p o d k ą te m e n k a p s u lo w a n ia lo g ik i a p lik a c ji w sposób ja k n a jle p ie j o d z w ie rc ie d la ją c y bie żą c e p o ­ trz e b y ro z w ią z a n ia . G łó w n y m m o ty w a to r e m z a s to s o w a n ia te j s tra te g ii są w z g lę d y in te g ra c ji — d o łą c z a n ie do tra d y c y jn e g o r o z w ią z a n ia u s łu g -o to c z e k s p ra w ia , że r o z w ią z a n ie to staje się k o m ­ p a ty b iln e z fr a m e w o rk ie m k o m u n ik a c y jn y m o p a rty m n a k o m u n ik a ta c h S O A P .

10.3.1. Proces T y p o w e podejście w stępujące p o d o b n e jest do procesu zilu stro w an eg o sym b o liczn ie n a ry s u n k u 10.3. T a k ja k s trateg ia zstępująca, ta k i ta w y m a g a u p rz e d n ie g o z d e fin io w a n ia w y m a g a ń b izn e s o w y c h .

Etap nr 1: modelowanie wymaganych usług aplikacyjnych W s z y s tk o ro z p o c z y n a się o d z d e fin io w a n ia w y m a g a ń a p lik a c y jn y c h , k tó re m a ją zostać s p e łn io n e za p o m o c ą tw o rz o n y c h usług. N a jc z ę ś c ie j są to w y m a g a n ia u s ta n o w ie n ia k a n a łó w in te g ra c y jn y c h ty p u „ p u n k t -p u n k t ” m ię d z y „ s p a d k o w y m i” s y s te m a m i lu b ro z w ią z a n ia m i B 2 B b ą d ź te ż za s tą p ie ­ n ia tra d y c y jn y c h te c h n o lo g ii z d a ln e j k o m u n ik a c ji p rz e z n o w o c z e s n y fr a m e w o r k o p a r ty n a k o ­ m u n ik a ta c h S O A P .

322

RO ZDZIAŁ 1 0 . ■ STRATEGIE REALIZACJI SOA

Kroki

Krok 3

Modelowanie usług aplikacyjnych

Krok 2

>f

*r

Tworzenie usług aplikacyjnych

Krok 4

Projektowanie usług aplikacyjnych

Krok 5

^

Wdrażanie usług

^r

Testowanie usług

Rysunek 10.3. Typowe kroki strategii wstępującej

W p rz y p a d k u ro z w ią z a ń , o d k tó r y c h w w y n ik u za s to s o w a n ia o p is y w a n e j s tra te g ii o c ze k u je się w y s o k ie g o s to p n ia z o rie n to w a n ia n a u s łu g i, m o d e lo w a n ie u s łu g a p lik a c y jn y c h p ro w a d z ić b ę d z ie p r a w d o p o d o b n ie do z a m k n ię c ia w ic h r a m a c h r ó w n ie ż lo g ik i b iz n e s o w e j i re g u ł b iz n e s o w y c h . P rzyp u s zcza ln ie zo stan ą w ów czas w y o d rę b n io n e d w ie w a rs tw y u słu g o w e, o b e jm u ją c e (o d p o w ie d ­ n io ) u s łu g i h y b ry d o w e i u s łu g i u ż y tk o w e . Jako w ie lo u ż y w a ln e , u s łu g i te p e łn ić m o g ą s a m o d z ie ln e ro le p u n k tó w k o ń c o w y c h a p lik a c ji d la c e ló w in te g ra c ji ty c h że a p lik a c ji, m o g ą b y ć je d n a k r ó w n ie ż z a a n g a żo w a n e w k o m p o z y c je , k o n tro lo w a n e p rz e z n a d rz ę d n e u s łu g i h y b ry d o w e .

Etap nr 2: projektowanie wymaganych usług aplikacyjnych N ie k tó r e z usłu g , o k tó r y c h m o w a w o p is ie e ta p u n r 1, m o g ą s ta n o w ić g o to w e o to c z k i d la tr a d y ­ c y jn y c h a p lik a c ji, o to c z k i d o s ta rc z a n e p rz e z p r o d u c e n tó w ty c h a p lik a c ji, m o g ą te ż b y ć w y n ik ie m a u to m a ty c z n e g o g e n e ro w a n ia u s łu g p ro x y . T e g o ro d z a ju u s łu g i d a ją n ie w ie lk ie o k a z je d o w z b o ­ gacan ia ic h o d o d a tk o w e cechy, n a to m ia s t p ro je k to w a n ie usłu g w e w ła s n y m zakresie m u s i o d b y w a ć się p r z y u ż y c iu o d p o w ie d n ic h s ta n d a rd ó w , n ie z b ę d n y c h do u z y s k a n ia o k re ś lo n e g o s to p n ia s p ó j­ n o ści ro z w ią z a n ia . P ro je k to w a n ie u s łu g a p lik a c y jn y c h , ze s z c ze g ó ln y m u w z g lę d n ie n ie m ic h w ie lo u ż y w a ln o ś c i, jes t p rz e d m io te m r o z w a ż a ń w ro z d z ia le 15.

Etap nr 3: tworzenie wymaganych usług aplikacyjnych N a ty m etap ie n a s tę p u je fiz y c z n e tw o rz e n ie (p r o g ra m o w a n ie ) u s łu g z g o d n ie z ic h o p is a m i i o d ­ p o w ie d n im i s p e c y fik a c ja m i p r o je k to w y m i.

Etap nr 4: testowanie usług P rz e d m io te m te s to w a n ia je s t p rze d e w s z y s tk im lo g ik a tra d y c y jn y c h a p lik a c ji e n k a p s u lo w a n a w r a ­ m a c h tw o rz o n y c h usłu g , a ta k że w e ry fik a c ja u s łu g -o to c z e k p o d k ą te m m o ż liw o ś c i ic h s p ro s ta n ia w y m o g o m w y d a jn o ś c io w y m s ta w ia n y m „ o b u d o w y w a n y m ” a p lik a c jo m . Is to tn y m e le m e n te m testów je s t te ż z a zw y c z a j b e zp ie c z e ń s tw o in te g ro w a n y c h a p lik a c ji, w p ły w ic h in te g ra c ji n a s ta b iln o ś ć in ­ fr a s tru k tu ry o ra z m e c h a n iz m y k o n tr o lo w a n ia d o s tę p u do p o s z c z e g ó ln y c h p u n k tó w k o ń c o w y c h .

1 0 .3 . STR ATEG IA W STĘPU JĄC A

323

Etap nr 5: wdrażanie usług U tw o r z o n e u s łu g i a p lik a c y jn e są n a ty m e ta p ie w d ra ż a n e do p r o d u k c ji. W d r o ż e n ie to w ią ż e się z r e g u ły ze s p e łn ie n ie m o k re ś lo n y c h w y m a g a ń d o ty c z ą c y c h ic h w y d a jn o ś c i i b e z p ie c z e ń s tw a .

10.3.2. Za i przeciw S tra te g ia w s tę p u ją c a s to s o w a n a je s t p rz e z w ię k s zo ś ć f ir m „ p rz e c h o d z ą c y c h ” n a u s łu g i s ie c io w e . G łó w n y m tego p o w o d e m je s t z a m ia r w z b o g a c a n ia is tn ie ją c y c h a p lik a c ji o te c h n o lo g ie u s łu g sie­ c io w y c h . A r c h ite k tu ra , k tó re j częścią stają się te u s łu g i, p o zo s ta je ra c ze j n ie z m ie n io n a , z a te m z a ­ s a d y z o rie n to w a n ia n a u s łu g i rz a d k o m a ją tu z n a c ze n ie . I w efekcie o k a zu je się, że okre ś le n ie „strateg ia w s tę p u jąc a ” jest n ie do k o ń c a a d e k w a tn e , b o n ie m a m y do c z y n ie n ia z ja k ą ś rz e c z y w is tą „s tra te g ią ” a n i te ż w o góle z p o d e jś c ie m p ro w a d z ą c y m do z b u d o w a n ia w sp ó łczes n e j S O A . T a s m u tn a p ra w d a o k a z u je się e w id e n tn a d la w ie lu f ir m w m o ­ m e n c ie , g d y z a c z y n a ją tr a k to w a ć „ z o r ie n to w a n ie n a u s łu g i” w k a te g o ria c h m o d e lu a rc h ite k to ­ n iczn e g o . C h o c ia ż strateg ia w s tę p u jąc ą u m o ż liw ia szybkie d o s ta rc za n ie usług sie c io w y c h w y c h o d z ą ­ cych n a p rz e c iw d o ra ź n y m w y m a g a n io m aplikacji, późniejsze w y s iłk i zm ierzające do im p le m e n to w a n ia „ p ra w d z iw e j S O A ” w y m a g a ją d a le k o p o s u n ię te j r e w iz ji is tn ie ją c y c h ro z w ią z a ń , a n a w e t w p ro w a ­ d z a n ia n o w y c h , ze s ta n d a ry z o w a n y c h w a rs tw u s łu g o w y c h , u m ie js c o w io n y c h n a d rz ę d n ie w s to su n ku do n ie s ta n d a rd o w y c h u s łu g s ta n o w ią c y c h r e z u lta t w cześn iejszeg o u ż y c ia s tra te g ii w s tę p u ją c y c h .

A N A LIZA PRZYPADKU

W f ir m ie R a ilC o tw o rz e n ie u s łu g n a p o trz e b y łą c zn o ś c i z s y s te m e m B 2 B f ir m y T L S o d b y w a ło się bez u życia jakiejś szczególnej „strategii”: usługi te z b u d o w a n e zo stały w ra m a c h tra d y c y jn y c h p ro je k tó w p ro g ram isty c zn y c h , oczyw iście, z u w zg lę d n ie n ie m specyfikacji o p u b lik o w a n y c h p rze z T L S n a u ż y te k je j p a r tn e r ó w o n lin e . C h o ć b y ć m o ż e n ie w p e łn i te g o ś w ia d o m i, in fo r m a ty c y z a s to s o w a li tu je d n a k de fa c to p o d e jś c ie w s tę p u ją c e — c z y li u tw o rz e n ie z e s ta w u u s łu g s ie c io w y c h n a p o tr z e b y s p e łn ie n ia o k re ś lo n y c h , d o ra ź n y c h w y m a g a ń b iz n e s o w y c h , to z n a c z y po d e jś c ie o d z w ie rc ie d la ją c e ty p o ­ w e fa z y k la s y c z n y c h m e to d o lo g ii p r o g r a m o w a n ia . I r e z u lta ty z g ru b s z a o k a z a ły się z g o d n e z p rz e w id y w a n ia m i: d o s ta rc z o n e u s łu g i s p e łn ia ły swe z a d a n ie , w y k o n a n e zo s ta ły dość szybko i p r z y n ie w ie lk ic h n a k ła d a c h fin a n s o w y c h . P ro je k t m o ż n a b y ło u z n a ć z a u d a n y . K ło p o ty za c zę ły się p ó ź n ie j. T L S z a im p le m e n to w a ło n o w e z a ło ż e n ia p o lity k i w s to s u n k u d o fo r m u ło w a n ia i r e a liz o w a n ia z a m ó w ie ń , co w y m a g a ło z m ia n p o s tro n ie R a ilC o . P o n a d to R a ilC o z m u s z o n a z o s ta ła d o z r e w id o w a n ia s w y c h w e w n ę tr z n y c h p ro c e s ó w b iz n e s o w y c h , w z w ią z k u z a k tu a liza c ją k ilk u m o d u łó w p rzestarzałeg o system u fin a n s o w o -k s ię g o w e g o . O b ie te okoliczności w y m u s za ły konieczno ść z m ia n w zakresie n is k o p o zio m o w e g o dostępu do da n y c h ze s tro n y usługi Wystawienie faktury. T o w s z y s tk o n ie w r ó ż y ło n ic ze g o d o b re g o — i rze c zy w iś c ie : w z g lę d y k o m p a ty b iln o ś c i, w y d a jn o ś c i i re a k ty w n o ś c i p rz e s ą d ziły o k o n ie c zn o ś c i d o k o n a n ia zn aczących z m ia n w ra m a c h tra d y c y jn y c h s y s te m ó w , k tó ry c h lo g ik a e k s p o n o w a n a b y ła z a p o ś re d n ic tw e m w s p o m n ia n y c h u sług. P rz e d p ro g r a m is ta m i p o c z ę ła się ry s o w a ć p e rs p e k ty w a dość n ie w e s o ła , g d y u ś w ia d o ­ m ili sobie, iż

324

RO ZDZIAŁ 1 0 . ■ STRATEGIE REALIZACJI SOA

•

k a ż d a z m ia n a , n ie z a le ż n ie o d p rz y c z y n y , w y m a g a ła zna c zą c e g o w y s iłk u zw ią z a n e g o z m o d y fik o w a n ie m k ilk u usłu g . P o n ie w a ż p r z y p r o je k to w a n iu ty c h u s łu g n ie ro z d z ie lo n o lo g ik i b izn e s o w e j o d lo g ik i a p lik a c y jn e j, ja k a k o lw ie k z m ia n a w o b rę b ie je d n e j z ty c h d o m e n o z n a c z a ła g e n e ra ln ie z m ia n ę w z a k re s ie całej u s łu g i. A p o n ie w a ż ż a d n a z u tw o rz o n y c h u s łu g n ie b y ła w ie lo u ż y w a ln a , szansa n a c h o c ia ż częściow e s p e łn ie n ie n o w y c h w y m a g a ń p rz e z is tn ie ją c e u s łu g i o k a z a ła się p ra k ty c z n ie z e ro w a .

•

k a ż d a m o d y fik a c ja w p r o w a d z o n a do d z ia ła ją c e g o k o d u s ta w ia ła p o d z n a k ie m z a p y ta n ia jeg o w ia ry g o d n o ś ć i w y m a g a ła u r u c h o m ie n ia o d p o w ie d n ic h te s tó w w celu p rz y w ró c e n ia te j w ia ry g o d n o ś c i. P rz e te s to w a n y k o d m u s ia ł zo s ta ć w d r o ż o n y w ś ro d o w is k u p r o d u k c y jn y m , co te ż n ie k o n ie c z n ie o d b y w a ło się b e z k ło p o tó w . Z w ię k s z a ło to tz w . k o s z t p o s ia d a n ia k a ż d e j z m o d y fik o w a n y c h usług.

•

d o ra ź n a m o d y fik a c ja k a ż d e j z usłu g o z n a c z a ła p o c z ą te k ry z y k o w n e j m e ta m o r fo z y — ro z s z e rz a n ia je j fu n k c jo n a ln o ś c i i w a r u n k ó w u ż y tk o w a n ia n a za k re s , k tó r y n ie z o s ta ł o ry g in a ln ie u ję ty w je j p ro je k c ie .

P O D S U M O W A N IE •

Strategia wstępująca to podejście bazujące na dostarczaniu usług aplikacyjnych w celu spełnienia doraźnych w ym agań.

•

Strategia ta jest efektywna w realizacji, nie jest jednak krokiem w kierunku budowania współczesnej SOA czy naw et w cielania w życie zasad zorientow ania na usługi.

10.4. Strategia zw inna G d y w e ź m ie się p o d u w a g ę o p is y w a n e „ za i p rz e c iw ” k a ż d e j z o b u s tra te g ii — zs tę p u ją c e j i w s tę ­ p u ją c e j — n a tu ra ln e w y d a je się p y ta n ie o in n ą je s zc ze s tra te g ię , s ta n o w ią c ą a k c e p to w a ln y k o m ­ p ro m is m ię d z y t y m i d w ie m a s k ra jn o ś c ia m i, c z y li u m o ż liw ia ją c ą rz e c z y w is ty p o s tę p w k ie r u n k u b u d o w a n ia S O A i w d r a ż a n ia w ży c ie zasad z o r ie n to w a n ia n a u s łu g i, b e z je d n a k ż e k o n ie c z n o ś c i d łu g ie g o o c z e k iw a n ia n a rz e c z y w is te ro z p o c z ę c ie in te g r o w a n ia te c h n o lo g ii u s łu g s ie c io w y c h z is tn ie ją c y m ś r o d o w is k ie m . K o m p ro m is e m ta k im je s t proces, w k tó r y m a n a liza n a p o z io m ie b iz n e s o w y m o d b y w a się r ó w ­ no le g le z p ro je k to w a n ie m i tw o rz e n ie m usług. P roces te n , z w a n y strategią zwinną (a g ile s tra te g y ) lu d p o d e jś c ie m „ s p o tk a n ie p o ś ro d k u ” ( m e e t-in -th e m id d le a p p ro a c h ), jest b a rd z ie j s k o m p lik o w a n y n iż o p isan e u p rz e d n io s tra te g ie , p o n ie w a ż w y m a g a s p e łn ie n ia d w ó c h p rz e c iw s ta w n y c h z e s ta w ó w w ym agań.

10.4.1. Proces W id o c z n y n a ry s u n k u 1 0 .4 s c h e m a t to p r z y k ła d te g o , ja k s tra te g ia z w in n a p ro w a d z ić m o ż e do o s ią g n ię c ia c e ló w w ła ś c iw y c h o b u s tra te g io m — zs tę p u ją c e j i w s tę p u jąc e j.

1 0 .4 . STR ATEG IA Z W IN N A

325

Kontynuacja

Rysunek 10.4. Prosty przykład procesu odzwierciedlającego strategię zwinną

Etap nr 1: przeprowadzanie analizy zstępującej E ta p te n o b e jm u je z a s a d n ic z o e ta p y 1., 2. i 3. o p is a n e j w c z e ś n ie j s tra te g ii zs tę p u ją c e j — z ty m w s za k że w y ją tk ie m , iż te o b s za ry p rz e d s ię b io rs tw a , w k tó r y c h w d ra ż a n ie u s łu g je s t p r io r y te te m , p o w in n y zostać p o tra k to w a n e s zczeg ó ln ie s ta ra n n ie . G d y ro z p o c z n ie się e tap n r 2, etap n r 1 p r o ­ w a d z o n y je s t ró w n o le g le z n im ja k o n ie p rz e rw a n e d ą ż e n ie do s p e łn ie n ia c e ló w g lo b a ln e j a n a liz y , w ła ś c iw e j p o d e jś c iu z s tę p u ją c e m u .

Etap nr 2: przeprowadzanie analizy zorientowanej usługowo, po odpowiednim zaawansowaniu analizy zstępującej E ta p n r 1 je s t k o n ty n u o w a n y , ty m c z a s e m etap n r 2 ro z p o c z y n a fazę a n a liz y z o rie n to w a n e j u s łu ­ g o w o — o p is u je m y ją w ro z d z ia ła c h 11. i 12. M o m e n t ro zp o c zę c ia eta p u n r 2 m u s i zostać w y b ra n y o d p o w ie d n io w sto s u n k u do z a a w a n s o w a n ia eta p u n r 1 — im w ię k s zy s to p ie ń tego za a w a n s o w a n ia , ty m w ięcej ko rzy ś c i d la pow stająceg o p ro je k tu usług.

326

RO ZDZIAŁ 1 0 . ■ STRATEGIE REALIZACJI SOA

G d y a n a liz a zs tę p u ją c a je s t ju ż w y s ta rc za ją c o z a a w a n s o w a n a , m o ż n a p rz y s tą p ić do m o d e lo ­ w a n ia u s łu g b iz n e s o w y c h w sposób ja k n a jle p ie j o d z w ie rc ie d la ją c y d o s tę p n e r e z u lta ty tej a n a liz y . W ła ś c iw a o cen a „ d o jrz a ło ś c i” tej a n a liz y do ro z p o c z ę c ia w s p o m n ia n e g o m o d e lo w a n ia je s t p r a w ­ d z iw y m w y z w a n ie m i w y m a g a d u ż e g o d o ś w ia d c z e n ia . O c z y w iś c ie , d u ż e z n a c z e n ie m a w ty m w z g lę d zie is to tn o ś ć i p iln o ś ć p o s z c z e g ó ln y c h w y m a g a ń p ro je k tu .

Etap nr 3: przeprowadzanie projektowania zorientowanego usługowo N a ty m e ta p ie z o s ta ją fo r m a ln ie z d e fin io w a n e w a rs tw y u s łu g o ra z z a p ro je k to w a n e sam e u s łu g i, w sposób o p is y w a n y s z c ze g ó ło w o w r o z d z ia ła c h o d 13. do 16.

Etapy nr 4, 5 i 6: tworzenie, testowanie i wdrażanie usług T e eta p y , p o d o b n ie ja k w s tra te g ii zs tę p u ją c e j, o b e jm u ją tw o rz e n ie u s łu g , ic h s ta n d a rd o w e te s to ­ w a n ie i w d ra ż a n ie .

Etap nr 7: konfrontacja z aktualnymi wynikami analizy N ie z a p o m in a jm y , że ró w n o le g le do e ta p ó w o d 1. do 6. tr w a etap n r 1 — a n a liz a zs tę p u ją c a . Po u tw o rz e n iu , p rz e te s to w a n iu i w d r o ż e n iu u s łu g p rz y c h o d z i m o m e n t ic h k o n fr o n ta c ji z n a jn o w ­ s z y m i r e z u lt a t a m i te j a n a liz y . E w id e n c jo n o w a n a je s t ro z b ie ż n o ś ć c e c h p r e z e n to w a n y c h p r z e z u s łu g i w ic h a k tu a ln e j p o s ta c i z w y m a g a n ia m i o k re ś lo n y m i p rz e z rz e c z o n ą a n a lizę ; tw o r z o n y jest h a r m o n o g ra m u s u n ię c ia ty c h ro z b ie ż n o ś c i, p re fe ru ją c y te z u sług, w p rz y p a d k u k tó r y c h ro z b ie ż ­ ność je s t n a jb a rd z ie j zn a c zą c a . D la p o s z c z e g ó ln y c h u s łu g n a s tę p u je z re w id o w a n ie ic h p ro je k tu , z m o d y fik o w a n ie k o d u , p o n o w n e p rz e te s to w a n ie i p o n o w n e w d ro ż e n ie . A b y z a c h o w a ć in te g ra ln o ś ć u s łu g w tra k c ie tego ite ra c y jn e g o p ro c e s u , k o n ie c z n e je s t w p r o w a ­ d z e n ie d o ń (i ry g o ry s ty c zn e re s p e k to w a n ie ) e le m e n tu s ta b iln o ś c i, ja k im je s t niezm ienność kon­

traktów usług (s e rv ic e c o n tra c ts im m u t a b ilit y ) — g d y k o n tr a k t u s łu g i z o s ta n ie ju ż o p u b lik o w a n y , n ie m o ż n a go z m ie n ia ć , le c z co n a jw y ż e j ro z s ze rz a ć o n o w e o p e ra c je i d e fin ic je W S D L . T e n etap to w ła ś n ie czas p u b lik a c ji ty c h ro z s ze rz e ń i u w z g lę d n ie n ia ic h w system ie k o n tr o li w e rs ji.

10.4.2. Za i przeciw S tra te g ia z w in n a p r z e jm u je k o rz y s tn e c e c h y o b u s k ra jn o ś c i — s tra te g ii z s tę p u ją c e j i s tra te g ii w s tę p u jąc e j — z a p e w n ia ją c re a liz a c ję d o ra ź n y c h w y m a g a ń b e z n a ra ż a n ia n a s z w a n k in te g ra ln o ś c i b izn e s o w e g o m o d e lu f ir m y i k o rz y s tn y c h cech je j a rc h ite k tu ry , w y n ik a ją c y c h z zasad z o r ie n to w a ­ n ia n a u s łu g i. P o g o d z e n ie p rz e c iw s ta w n y c h — d o ra ź n y c h i d a le k o s ię ż n y c h — c e ló w m a sw ą cenę w z w ię k s z o n y m w y s iłk u w k ła d a n y m w re a liz a c ję k a ż d e j u s łu g i. Ite ra c y jn a n a tu ra p ro c e s u , w y m a ­ g a jąca w ie lo k ro tn e g o p r o je k to w a n ia , r e k o n s tru o w a n ia , te s to w a n ia i w d r a ż a n ia s p ra w ia , że te n w y s iłe k staje się p r o p o r c jo n a ln y z a r ó w n o do lic z b y ite r a c ji, ja k i lic z e b n o ś c i sa m e g o z e s ta w u w s p o m n ia n y c h usług. P o n a d to o p is y w a n e p o d e jś c ie w y m a g a d o d a tk o w y c h z a b ie g ó w z m ie rz a ją c y c h do u tr z y m y w a ­ n ia is tn ie ją c y c h u sług w z g o d n o ś c i z r e w id o w a n y m i m o d e la m i b iz n e s o w y m i — g d y m o d e le te się z m ie n ia ją , n ie u s ta n n ie is tn ie je ry z y k o n a ru s z e n ia tej zg o d n o ś c i.

1 0 .4 . STR ATEG IA Z W IN N A

327

A N A LIZA PRZYPADKU

W o d p o w ie d z i n a n o w e w y m a g a n ia b izn e s o w e w T L S z a is tn ia ła p o trz e b a u tw o r z e n ia p ię c iu sześciu n o w y c h usług. M u s z ą one zostać d o starczo n e s to s u n k o w o w cześnie, b y ja k najszybciej z n iw e lo w a ć w y ra ź n e ro z b ie ż n o ś c i m ię d z y czasem p ra c y z d a ln y c h p r a c o w n ik ó w a fa k tu r a m i w y s ta w ia n y m i d la k lie n tó w . W ro z d z ia le 12. o p is ze m y (w ra m a c h a n a liz p rz y p a d k ó w ) s zczegółow o proces m o d e lo w a n ia w s p o m n ia n y c h u sług. P ode jś c ie , w ra m a c h k tó re g o z o s ta n ą u tw o rz o n e , o p a rte je s t w ła ś n ie n a s tra te g ii z w in n e j.

P O D S U M O W A N IE •

Strategia zwinna stanow i kompromis między strategią zstępującą a strategia w stępującą.

•

W ramach strategii zw innej dostarczanie usług realizow ane jest rów nolegle z trw ającą analizą.

•

Tw orzone usługi periodycznie konfrontow ane są z najnowszymi w ynikam i analizy i iteracyjnie dostosow yw ane do tychże w yników .

328

ROZDZIAŁ 10. ■ STRATEGIE REALIZACJI SOA

Rozdział 11

Analiza zorientowana na usługi (Część I. Wprowadzenie) 1 1.1. W p ro w a d z e n ie do a n a liz y z o rie n to w a n e j n a u s łu g i 1 1.2. K o rz y ś c i z S O A u k ie ru n k o w a n e j b izn e s o w o 1 1.3. W y o d r ę b n ia n ie u s łu g b izn e s o w y c h

330

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

P ie rw s z y m i n a jw a ż n ie js z y m b o d a j e ta p e m c y k lu ży c io w e g o S O A je s t a n a liz a p ro w a d z ą c a do r o z ­ p o z n a n ia , ja k w ła ś c iw ie w y g lą d a ć p o w in ie n z e s ta w u s łu g s k ła d a ją c y c h się n a b u d o w a n ą S O A . R o z d z ia ły te n i n a s tę p n y p o ś w ię c a m y p o d s ta w o w y m a s p e k to m te j fa z y p r o je k tu , u s ta n a w ia ją c f o r m a ln y proces m o d e lo w a n ia u s łu g i o m a w ia ją c szereg p r o b le m ó w , ja k ie n a le ż y ro z w ią z a ć p rz e d ro z p o c z ę c ie m fa z y p r o je k to w a n ia usług.

„Architektura zorientowana na usługi” a „środowisko zorientowane na usługi” Jak w y ja ś n ia liś m y w ro z d z ia le 4 ., a rc h ite k tu ra z o rie n to w a n a n a u s łu g i to te c h n ic z n e uję c ie r o z ­ w ią z a n ia a u to m a ty z a c y jn e g o , b a z u ją c e n a za s a d a c h z o rie n to w a n ia n a u s łu g i. P o n ie w a ż treść tego r o z d z ia łu k o n c e n tru je się w o k ó ł a n a liz y b izn e s o w e j ja k o p rz y g o to w a n iu do p ro c e s u m o d e lo w a n ia u s łu g , b ę d z ie m y często u ż y w a ć o k re ś le n ia „ ś ro d o w is k o z o rie n to w a n e n a u s łu g i” ( s e rv ic e -o rie n te d e n v ir o n m e n t) o zn ac zają c e g o d o m e n ę lo g ik i p rz e d s ię b io rs tw a , w o d n ie s ie n iu do k tó re j za s to s o w a ­ n e z o s ta ły za s a d y z o r ie n to w a n ia n a u s łu g i; w k o n te k ś c ie tego r o z d z ia łu o z n a c z a to ś ro d o w is k o o b e jm u ją c e p ro c e s y b izn e s o w e w r a z z te c h n o lo g ią u ż y w a n ą do ic h a u to m a ty z a c ji.

UW AGA

Często spotykanym synonimem terminu „środowisko zorientowane na usługi" jest „ekosystem SOA".

Analizy przypadków : W ię k s z o ś ć a n a liz p rz y p a d k u w ty m ro z d z ia le d o ty c z y ś ro d o w is k a f i r ­ m y R a ilC o , k tó re s ta n ie się p r z e d m io te m a n a liz y z o rie n to w a n e j n a u sługi; z a le c a m y p rz e a n a ­ liz o w a n ie ty c h p rz y k ła d ó w p rz e d ro z p o c z ę c ie m s tu d io w a n ia szczeg ó łó w p rocesu m o d e lo w a n ia , o p is y w a n e g o w ro z d z ia le 12. P re z e n tu je m y ta k ż e ś ro d o w is k o S O A f ir m y T L S , z u w z g lę d n ie n ie m je g o u s łu g u k ie r u n ­ k o w a n y c h p o d m io to w o . T re ś c ią o s ta tn ie g o z p r z y k ła d ó w je s t z a m ia r p rz e p ro w a d z e n ia p rz e z T L S a n a liz y z o rie n to w a n e j n a usłu g i ja k o pierw szego k r o k u do s tw o rz e n ia ro z w ią z a n ia Z a r z ą ­ d z a n ie k a r t a m i cza su p r a c y ; w s p o m n ia n a a n a liz a o p is a n a z o s ta n ie s zc ze g ó ło w o p o d k o n ie c r o z d z ia łu 12.

11.1. W prow ad zenie do analizy zorientow anej na usługi R e p r e z e n to w a n ie w y m a g a ń z w ią z a n y c h z a u to m a ty z a c ją b iz n e s u w f o r m ie z o r ie n t o w a n ia n a u s łu g i to te m a t, k tó re g o szc ze g ó ło w e ro z p ra c o w a n ie jes t w ła ś n ie z a d a n ie m a n a liz y z o rie n to w a n e j n a u słu g i.

11.1.1. Cele analizy zorientowanej na usługi R ó żn e f ir m y o d m ie n n ie p o d c h o d z ą d o p r o b le m u a n a liz y a u to m a ty z a c ji b iz n e s u i ró ż n e w y p ra c o ­ w u ją w tej m ie rz e ro z w ią z a n ia , często n a p rz e s trz e n i w ie lu la t d o k u m e n to w a n y c h d o ś w ia d c z e ń , p ro w a d z ą c y c h do z d e fin io w a n ia r a m fo rm a ln e g o p rocesu. N ie je s t in te n c ją tego r o z d z ia łu b a g a te liz o w a n ie tego w y s iłk u i p ro p o n o w a n ie w z a m ia n ja k ie jś je d y n ie słu szn ej filo z o fii; o fe ru je m y rac ze j z b ió r u z u p e łn ia ją c y c h p ro c e d u r, k tó re w za m y ś le p o ­ m ó c m a ją o rg a n iz a c jo m w k s z ta łto w a n iu ic h lo g ik i a u to m a ty z a c ji p o d k ą te m p rz y g o to w a n ia do

1 1 .1 . W P R O W A D Z E N IE D O A N A L IZ Y ZO R IE N TO W A N E J N A USŁUGI

331

p ro c e s ó w p r o je k to w a n ia z o rie n to w a n e g o n a u s łu g i. P ro c e d u ry u w y d a tn ia ją te z ja w is k a i k o n c e p ­ c je , k tó r e s ta n o w ią p o d s ta w ę d o f o r m u ło w a n ia w s tę p n e j d e f in ic ji u s łu g , n a p o d s ta w ie m o d e li ty c h że u słu g , w p o łą c z e n iu z z a s a d a m i z o rie n to w a n ia n a u s łu g i (i in n y m i k lu c z o w y m i u w a r u n ­ k o w a n ia m i). W s p o m n ia n e p ro c e d u ry m a ją c h a ra k te r g e n e ry c z n y i w y s o k o p o z io m o w y : u s ta n a w ia ją p e w ie n p u n k t w y jś c ia d la f ir m , k tó re , z a m ie rz a ją c n a d a ć w y p ra c o w y w a n y m p rz e z sieb ie w a r ia n to m p o ­ d ejścia do a n a liz y k s z ta łt z g o d n y z tra n s fo rm a c ją w s tro n ę S O A , c h c ia ły b y je d n o c z e ś n ie p o zo s ta ć w z g o d n o ś c i z is tn ie ją c y m i p r a k ty k a m i w z a k re s ie a n a liz y b izn e s u . D w a p o d s ta w o w e p y ta n ia , n a k tó re o c ze k u je się o d p o w ie d z i b ęd ącej r e z u lta te m a n a liz y z o ­ rie n to w a n e j n a u s łu g i, są na s tę p u ją ce . •

Jakie u s łu g i n a le ż y z b u d o w a ć ?

•

Jaki zakres lo g ik i e n k a p s u lo w a ć p o w in n a k a ż d a z ty c h usług?

O d w y s iłk u z a in w e s to w a n e g o w a n a liz ę z a le ż n y je s t s to p ie ń w ia ry g o d n o ś c i ty c h o d p o w ie d z i. Jako o g ó ln e cele p r z e p r o w a d z a n ia a n a liz y z o r ie n to w a n e j n a u s łu g i w y m ie n ić n a le ż y p rz e d e w s zy s tk im : • •

z d e fin io w a n ie w s tę p n y c h k a n d y d a tu r n a o p e ra c je usług; p o g ru p o w a n ie w s p o m n ia n y c h k a n d y d a tu r z g o d n ie z ic h lo g ic z n y m k o n te k s te m ; k a ż d y z k o n te k s tó w za k re ś la r a m y p e w n e j k a n d y d a tu r y n a usługę;

•

w s tę p n e o k re ś le n ie fu n k c jo n a ln y c h g ra n ic k a ż d e j z usług;

•

u s ta le n ie s to p n ia w ie lo u ż y w a ln o ś c i e n k a p s u lo w a n e j lo g ik i;

•

z a p e w n ie n ie , że k o n te k s t e n k a p s u lo w a n e j lo g ik i je s t z g o d n y z je j z a m ie r z o n y m w y k o rz y s ty w a n ie m ;

•

w s tę p n e z id e n ty fik o w a n ie p r o b le m ó w z w ią z a n y c h z w y m a g a n ą a u to n o m ią usług;

•

w s tę p n e z id e n ty fik o w a n ie e w e n tu a ln y c h m o d e ló w k o m p o z y c y jn y c h .

11.1.2. Analiza zorientowana na usługi a model usług przedsiębiorstwa A n a liz ę z o r ie n to w a n ą n a u s łu g i p rz e p ro w a d z a ć m o ż n a n a ró ż n y c h p o z io m a c h , z a le ż n ie o d w y ­ b ra n e j s tra te g ii re a liz o w a n ia S O A . Jak to w y ja ś n ia liś m y w p o p r z e d n im ro z d z ia le , w y b ó r te j s tra te ­ g ii d e c y d u je o ty m , czy u s ta n o w io n a zo staje ja k a ś fo r m a m o d e lu u s łu g p rz e d s ię b io rs tw a i w ja k im z a k re s ie d e fin io w a n e są szc ze g ó ły tego m o d e lu . T e c h n ic z n ie m o ż liw e je s t za s to s o w a n ie p o d e jś c ia ściśle zs tę p u ją c e g o , w r a m a c h k tó re g o a n a li­ za z o r ie n to w a n a n a u s łu g i ite r a c y jn ie p rz e p la ta się z d e fin io w a n ie m w s p o m n ia n e g o m o d e lu (to s p rz ę że n ie z w ro tn e w id o c z n e je s t n a ry s u n k u 1 0 .2 ), i w re z u lta c ie k a ż d a z u s łu g z d e fin io w a n a z o ­ staje n a p o z io m ie szcze g ó ło w o ś c i p o z w a la ją c y m w p ro s t n a s fo rm u ło w a n ie je j k o n tr a k tu . Z w y k le je d n a k re z u lta te m s tra te g ii zs tę p u ją c e j jest je d y n ie w y s o k o p o z io m o w e o k re ś le n ie m o d e lu usług, ic h w a rs tw i ze s ta w u p r o p o n o w a n y c h k o n te k s tó w , b e z w n ik a n ia w s zc ze g ó ły lo g ik i e n k a p s u lo w a n e j p rz e z k a ż d ą z usług. Z tej te ż p e rs p e k ty w y n a le ż y tra k to w a ć o p is y w a n y w ty m ro z d z ia le proces. W y k o rz y s tu ją c ja k o p u n k t o d n ie s ie n ia to , co z d e fin io w a n e zostało w m o d e lu usług p rze d s ię b io rs tw a , proces te n u m o ż ­ liw ia w stępne z d e fin io w a n ie usług w p re d e fin io w a n y m zakresie.

332

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

11.1.3. Proces analizy zorientowanej na usługi A n a liz a z o rie n to w a n a n a u s łu g i je s t p o d p ro c e s e m c y k lu ży c io w e g o S O A . K r o k i p o k a z a n e n a r y ­ s u n k u 11.1 r e p re z e n tu ją ty p o w e z a d a n ia z w ią z a n e z tą fa z ą — p o n iż e j o p is u je m y je w s z y s tk ie szczeg ó ło w o . Kroki Analiza zorientowana usługowo

>r Projektowanie zorientowane usługowo

>t Tworzenie usług

Definiowanie zakresu analizy

Krok 2

>f

Identyfikacja systemów automatyzacji

Krok 3

>f

Modelowanie kandydatur na usługi

r Testowanie usług

r Wdrażanie usług

r Administrowanie usługami

Rysunek 11.1. Analiza zorientowana na usługi w ujęciu wysokopoziomowym jako element cyklu życiowego SOA

Z a u w a ż m y , że k r o k i n r 1 i 2 są w isto cie z b ie ra n ie m in fo r m a c ji n ie z b ę d n e j d la p ro c e s u m o d e ­ lo w a n ia s ta n o w iąc e g o k r o k 3.

1 1 .1 . W P R O W A D Z E N IE D O A N A L IZ Y ZO R IE N TO W A N E J N A USŁUGI

333

Krok nr 1: zdefiniowanie zakresu analizy G e n e ra ln ie d o b ry m p o m y s łe m je s t w y ra ź n e o k re ś le n ie z a k re s u lo g ik i a u to m a ty z a c ji p rz e d ro z p o ­ c zę c ie m całego c y k lu re a liz a c ji p ro je k tu . W tra d y c y jn y c h p rz e d s ię w z ię c ia c h p ro g ra m is ty c z n y c h z a k re s te n w y z n a c z o n y je s t p rz e z s a m p ro c e s b iz n e s o w y w y m a g a ją c y a u to m a ty z a c ji b ą d ź p rz e z p o trz e b ę ro z s z e rz e n ia is tn ie ją c e j k o n fig u ra c ji (k tó r a to p o trz e b a najczęściej i ta k d y k to w a n a jest z m ia n a m i w p ro cesie b iz n e s o w y m ). P ro je k t tw o rz e n ia n o w e j u s łu g i ró w n ie ż m o ż n a b y ta k w ła ś n ie p o tra k to w a ć , s ta n o w i o n w s z a k re p re z e n ta c ję p e w n e j d o b rz e o k re ś lo n e j części lo g ik i b iz n e s o w e j pro c e s u . W rz e c zy w is to ś c i je d ­ n a k dość n ie ty p o w e b y ło b y d o s ta rc ze n ie p o je d y n c z e j u s łu g i, ag n o s ty c zn e j b iz n e s o w o , ja k o je d n e ­ go z e le m e n tó w całego p o r tfo lio u s łu g n a p o trz e b y p rz y s z ły c h a u to m a ty z a c ji p ro c e s ó w b iz n e s o ­ w y c h . W t a k im p rz y p a d k u za k re s lo g ik i a u to m a ty z a c ji n ie o g ra n ic z a się do p o je d y n c z e g o z a d a n ia , lec z s ta n o w i serię z a d a ń (lu b o p e ra c ji) s k o ja rz o n y c h z k o n te k s te m g e n e ry c z n e j u s łu g i. I ta k n a p rz y k ła d za k re s d u że g o p ro c e s u b izn e s o w e g o , re p re z e n to w a n e g o p rz e z k o m p o z y c ję w ie lu u s łu g , o b e jm u je d e fin ic je k ilk u n o w y c h u s łu g i (lu b ) k ilk u u s łu g is tn ie ją c y c h . N a d r z ę d n a lo g ik a sam eg o p ro c e s u m o ż e , le c z n ie m u s i, r ó w n ie ż re z y d o w a ć w fo r m ie u s łu g i (z a le ż n ie o d s tr u k tu r y w a rs tw u s łu g ). R e a liz a c ja u s łu g i b izn e s o w e j u k ie ru n k o w a n e j p o d m io to w o o b e jm u je je d n a k szereg p ro c e s ó w , z k tó ry c h k a ż d y z w ią z a n y je s t z g e n e ry c z n y m z a d a n ie m re p re z e n tu ją c y m fra g m e n t lo g ik i p rz e ­ z n ac zo n ej do en k a p s u la c ji w ra m a c h tej usługi. N a w e t w ię c w p rz y p a d k u p o je d y n c ze j usłu g i isto tn e je s t z d e te rm in o w a n ie je j z a k re s u fu n k c jo n a ln e g o , b o k a ż d a z je j o p e ra c ji m o ż e o s ta te c zn ie r e p re ­ z e n to w a ć lo g ik ę w y m a g a ją c ą z a a n g a ż o w a n ia (w r a m a c h k o m p o z y c ji) in n y c h usług. A b y to w szys tko m ia ło szansę p o w o d z e n ia , m u s im y za d b a ć , b y w y m a g a n ia b izn e s o w e , k t ó ­ ry c h s p e łn ie n ie p o k ła d a m y w p rz e w id y w a n y c h u s łu g a c h , b y ły n a ty le d o jrz a łe i n a ty le w y ra ź n ie w y a rty k u ło w a n e , b y p r z y n a jm n ie j je d e n p roces b iz n e s o w y (a n a jle p ie j — g ru p a ta k ic h p ro c e s ó w ) m ó g ł zostać s zc ze g ó ło w o u d o k u m e n to w a n y . D o k u m e n ta c ja ta s ta n o w ić b ę d z ie p u n k t w y jś c ia d la p ro c e s u m o d e lo w a n ia u sług, s ta n o w ią c e g o k r o k 3.

Krok nr 2: identyfikacja istniejących systemów automatyzacji P o n ie w a ż b u d o w a n ie S O A o d b y w a ć się b ę d z ie n a jp ra w d o p o d o b n ie j z u d z ia łe m is tn ie ją c e j in fr a ­ s tru k tu ry , n a le ż y z n a le źć tk w ią c e w tej in fra s tru k tu rz e e le m e n ty lo g ik i m a ją c e ja k ik o lw ie k z w ią z e k z a u to m a ty z o w a n ie m w y m a g a ń b iz n e s o w y c h , k tó re z id e n ty fik o w a liś m y w k r o k u 1. I ch o ć a n a liz a z o rie n to w a n a n a u s łu g i n ie je s t w sta n ie o k re ś lić , w ja k im s to p n iu tw o rz o n e u s łu g i m a ją za s tę p o ­ w a ć lu b e n k a p s u lo w a ć lo g ik ę tra d y c y jn y c h a p lik a c ji, m o ż e o n a o k a za ć się p o m o c n a w z id e n ty fi­ k o w a n iu w s p o m n ia n e g o z w ią z k u . D o k ła d n e o k re ś le n ie re la c ji p la n o w a n y c h u s łu g w s to s u n k u d o is tn ie ją c y c h s y s te m ó w o d b y w a się w fa zie p ro je k to w a n ia z o rie n to w a n e g o n a u s łu g i. W fa zie a n a liz y w s tę p n a in fo r m a c ja n a te m a t ty c h re la c ji o k a z u je się n a to m ia s t p o m o c n a w z id e n ty fik o w a n iu n ie k tó ry c h o g ra n ic z e ń , m a ją c y c h w p ły w n a d e fin io w a n ie k a n d y d a tu r w p ro c e s ie m o d e lo w a n ia u s łu g w k r o k u 3. Z a s a d n ic z o k r o k te n d e d y k o w a n y je s t w s p ie ra n iu w y s iłk ó w m o d e lo w a n ia p r z y b u d o w a n iu w ie lk o s k a lo w y c h ro z w ią z a ń z o r ie n to w a n y c h n a u s łu g i. P r z y m o d e lo w a n iu m n ie js z y c h z b io r ó w u s łu g ro z p o z n a n ie ic h z w ią z k u z is tn ie ją c y m i s y s te m a m i w c ią ż je s t — co p ra w d a — is to tn e , le c z z re g u ły n ie w y m a g a z a w a n s o w a n e g o p ro c e s u a n a liz y .

334

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Krok nr 3: modelowanie kandydatur na usługi M o d e lo w a n ie u sług to p roces, w k tó r y m k a n d y d a tu r y n a o p e ra c je u s łu g są id e n ty fik o w a n e i g ru ­ p o w a n e w o p a rc iu o ic h lo g ic z n y k o n te k s t. G r u p y te stają się k a n d y d a tk a m i n a u sługi, k tó re z k o le i s k ła d a ją się n a p ró b n y m o d e l re p re z e n tu ją c y p o łą c z o n ą lo g ik ę p la n o w a n y c h usług. P roces te n jest s zcze g ó ło w o o p is y w a n y w ro z d z ia le 12., w p o d ro z d z ia le „ M o d e lo w a n ie u sług k r o k p o k r o k u ”. Jego c e le m je s t s tw o rz e n ie w y id e a liz o w a n e j re p re z e n ta c ji lo g ik i a u to m a ty z a c y jn e j p o p rz e z z o rie n to w a n ie n a u s łu g i. B ędące jeg o r e z u lta te m k a n d y d a tu r y n a u s łu g i stają się m a te ­ ria łe m d la p r o je k to w a n ia z o rie n to w a n e g o n a u s łu g i, k tó re g o p ro c e s y o p is u je m y w ro z d z ia le 15.

A N A LIZA PRZYPADKU

W ro z d z ia le 2., z a p o c z ą tk o w u ją c serię a n a liz p rz y p a d k ó w , p rz e d s ta w iliś m y d łu g o fa lo w e z a ­ m ie rz e n ie R a ilC o , ja k im jest s ta n d a ry z a c ja je g o s y s te m ó w w p o s ta c i S O A w celu ro z w ią z a n ia b ie ż ą c y c h p r o b le m ó w z a u to m a ty z a c ją b iz n e s u o ra z p o s z e rz e n ia k rę g u p a r tn e ró w b iz n e s o ­ w y c h o n lin e . W n a s tę p n y c h ro z d z ia ła c h o p is y w a liś m y s to p n io w ą re a liz a c ję tego z a m ie rz e n ia , w p o staci b u d o w a n ia ze s ta w u u s łu g u m o ż liw ia ją c y c h R a ilC o in te ra k c ję o n lin e z s y s te m e m B 2B f ir m y T L S . D o ty c h c z a s o w y m tego e fe k te m je s t z b ió r w ie lo k r o tn ie ju ż c y to w a n y c h n a s tę ­ p u ją c y c h usług:

• Wystawienie faktury, • Realizacja zamówienia , • Subskrypcja TLS. M im o iż u sługi te is to tn ie s ta n o w ią ro zs ze rze n ie tra d y c y jn e j in fra s tru k tu ry R a ilC o o te c h ­ n o lo g ię u s łu g s ie c io w y c h , t r u d n o u z n a ć je z a p r z e ja w „ p r a w d z iw e j” S O A . Jak w y ja ś n ia liś m y w p o p rz e d n im ro z d z ia le , u s łu g i te u tw o rz o n o p r z y u ż y c iu czystej s tra te g ii w s tę p u ją c e j, s k u t­ k ie m czego n o s zą o n e w s ze lk ie z n a m io n a h y b ry d o w y c h u s łu g a p lik a c y jn y c h (c z y li u s łu g a p li­ k a c y jn y c h z a w ie ra ją c y c h ta k że e le m e n ty lo g ik i b izn e s o w e j o d p o w ia d a ją c e w ąsko ro z u m ia n y m z a d a n io m b iz n e s o w y m ). U s łu g i te zostały „poskładan e” naprędce, p o d k ą te m w y m a g a ń jed nego p a rtn e ra — f ir m y TLS . P o n ie w a ż je d n a k te n (d u ż y ) k lie n t z a c z ą ł s to p n io w o o g ra n ic z a ć w o lu m e n z a k u p ó w w R a ilC o , zw ra c a ją c się w s tro n ę k o n k u re n c y jn y c h d o s ta w c ó w o fe ru ją c y c h a tra k c y jn ie js ze i w y g o d n ie js ze w a r u n k i w s p ó łp ra c y , n o w e re lia o k a z a ły się d la R a ilC o w y s ta rc za ją c o s iln ą m o ty w a c ją do za­ in w e s to w a n ia w stan d aryzację sw ej a rc h ite k tu ry , z g o d n ie z za s a d a m i z o rie n to w a n ia n a usługi. P o w s tę p n e j a n a liz ie w y k o rz y s ty w a n y c h u sług s ie c io w y c h R a ilC o u ś w ia d o m iła sobie, że b u d o w a n ie n o w e j a rc h ite k tu ry n a ic h b a z ie ja w i się ja k o m a ło k o rz y s tn e . Z d e c y d o w a n o w ię c o z b u d o w a n iu „ o d z e ra ” c a łk ie m n o w e g o z b io r u usług. W y b r a n o s trateg ię z w in n ą (o p is y w a n ą w p o p r z e d n im ro z d z ia le ); z d e c y d o w a n o o m o d e ­ lo w a n iu je d y n ie d w ó c h w a rs tw u s łu g o w y c h — w a rs tw y u s łu g b iz n e s o w y c h i w a rs tw y usłu g a p lik a c y jn y c h — n ie z n a jd u ją c u z a s a d n ie n ia in w e s ty c ji w o p ro g ra m o w a n ie m id d le w a r e i m ­ p le m e n tu ją c e w a rs tw ę o rk ie s tra c ji. W m ia rę p ostępującej a n a liz y z o rie n to w a n e j n a u s łu g i fir m a s to p n io w o u ś w ia d a m ia ła sobie, iż d z ię k i S O A z re a liz o w a ć m o ż e w p e łn i z a k ła d a n e cele b iz n e s o w e , z a s p ra w ą d w ó c h n a s tę ­ p u ją c y c h w y m ie rn y c h ko rzy ś c i:

1 1 .2 . KORZYŚCI Z SO A U K IE R U N K O W A N EJ B IZN ESO W O

•

335

Z a s to s o w a n ie zasad z o rie n to w a n ia n a u s łu g i i w p ro w a d z a n a p rz e z S O A s ta n d a ry z a c ja p o z w o li f ir m ie R a ilC o n a w s p ó łp ra c ę o n lin e z w ie lo m a r ó ż n y m i p a r tn e ra m i b iz n e s o w y m i, co u w o ln i ją o d w y łą c z n o ś c i w s p ó łp ra c y z T L S i u m o ż liw i s ukcesyw ne n a w ią z y w a n ie in te r a k c ji z n o w y m i p a r tn e r a m i b e z k o n ie c z n o ś c i k a ż d o ra z o w e g o in w e s to w a n ia w n o w e ze s ta w y usług.

•

S O A u ła tw i f ir m ie in te g ro w a n ie n o w o tw o rz o n y c h ro z w ią z a ń z ju ż d z ia ła ją c y m i, tra d y c y jn y m i a p lik a c ja m i, p o p rz e z tw o rz e n ie d la ty c h a p lik a c ji p u n k tó w k o ń c o w y c h . W szczeg ó ln o ści a b s tra k c je w p ro w a d z a n e p rz e z w a rs tw y u s łu g u m o ż liw ią tw o rz e n ie k a n a łó w in te g ra c y jn y c h , k tó re b ę d ą m o g ły zostać z a c h o w a n e , g d y k o n ie c z n a o każe się w y m ia n a tra d y c y jn y c h te c h n o lo g ii. M ię d z y in n y m i p o z w o li to n a z in te g ro w a n ie ze sobą d w ó c h w e w n ę trz n y c h s y s te m ó w — s y s te m u ks ię g o w e g o i s y s te m u k o n ta k tu z m e n e d ż e r a m i — m im o n ie u c h ro n n e j p e rs p e k ty w y w y m ia n y p ie rw s ze g o z w y m ie n io n y c h n a n o w o c ze s n ą w ersję.

P o n ie w a ż p o trz e b y f ir m y R a ilC o k o n c e n tru ją się g łó w n ie n a u n o w o c ze ś n ia n iu istniejącego z b io ru u słu g , n ie p o ja w ia ją się w y ra ź n ie z id e n ty fik o w a n e , sp e c y fic zn e w y m a g a n ia d o tyczące w ie lo u ż y w a ln o ś c i ty c h u s łu g . M im o to , z a d e c y d o w a n o je d n a k , iż u s łu g i p r o je k to w a n e b ę d ą z m y ślą o p o te n c ja ln e j w ie lo u ż y w a ln o ś c i — zw ła s zc za te, w o d n ie s ie n iu do k tó ry c h za p o w ia d a ć się to b ę d z ie szczególnie o b iecująco. S zc zeg ó ły p rz e p ro w a d z o n e j p rz e z R a ilC o a n a liz y z o rie n to w a n e j n a u s łu g o p is z e m y w e w s p o m n ia n y m ju ż p o d ro z d z ia le M o d e lo w a n ie u s łu g k r o k p o k r o k u r o z d z ia łu 12.

P O D S U M O W A N IE

•

W fazie analizy zorientowanej na usługi podejmowane są krytyczne decyzje dotyczące projektu SOA, mające decydujący w pływ na kształt zarówno pojedynczych usług, jak i całych warstw usługowych.

•

Modelowanie usług to proces identyfikowania kandydatur na operacje usług i logiczne grupowanie tych kandydatur w kandydatury na usługi.

11.2. Korzyści z SOA ukierunkow anej biznesowo P o ja w ie n ie się u sług s ie c io w y c h u ś w ia d o m iło p ro je k ta n to m z n a c z e n ie fr a m e w o r k u o tw a rte j k o ­ m u n ik a c ji. W re z u lta c ie p ro fe s jo n a liś c i I T s ta n ę li p rz e d k o n ie c z n o ś c ią d o c e n ie n ia p rz y d a tn o ś c i u słu g s ie c io w y c h w n o w o c ze s n y c h ro z w ią z a n ia c h . M ó w iliś m y ju ż o t y m , że w ię k s z o ś ć w s p ó łc z e s n y c h u s łu g s ie c io w y c h to u s łu g i h y b r y d o w e , łą cząc e o b a ro d z a je lo g ik i — b iz n e s o w ą i a p lik a c y jn ą . T e n ty p u s łu g je s t s zc ze g ó ln ie a tra k c y jn y z p e rs p e k ty w y d o ra ź n y c h k o rzy ś c i: p r z y m in im a ln y m w y s iłk u m o ż n a s p o d z ie w a ć się zn acząceg o w s k a ź n ik a z w r o tu in w e s ty c ji ( R O I — R e tu r n O f In v e s tm e n t) . N o i p rz e d e w s z y s tk im s ta n o w ią one d o ra ź n y ś ro d e k in te g ro w a n ia tra d y c y jn y c h a rc h ite k tu r z o tw a rty m fr a m e w o r k ie m k o m u n ik a c y j­ n y m u sług sieciow ych. T łu m a c z y to w ystarczająco p o p u la rn o ś ć tw o rz e n ia ta k ic h usług i g e n e ra ln ie całej s tra te g ii w s tę p u jąc e j, w ra m a c h k tó re j są p ro je k to w a n e i tw o rz o n e . U s łu g i s tr ic te b izn e s o w e — c z y li re p re z e n tu ją c e w y łą c z n ie lo g ik ę tego je d n e g o ro d z a ju — n ie ja w ią się ja k o ta k a tra k c y jn e o d p ie rw s ze g o w e jrz e n ia : w ie lu p r o je k ta n tó w p o zo s ta je w n ie ś w ia ­ d o m o ś c i (b ą d ź n ie p rz y jm u je do w ia d o m o ś c i) k o rzy ś c i, ja k ie p rz y n o s ić m o że w p ro w a d z e n ie zasad

336

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

z o rie n to w a n ia n a u s łu g i do d o m e n y a n a liz y b izn e s o w e j. Ł a tw o z ig n o ro w a ć m o d e lo w a n ie b iz n e ­ sow e w w y d a n iu o rie n ta c ji n a u s łu g i i s k u p ić się n a za s to s o w a n iu tej o rie n ta c ji w y łą c z n ie do te c h ­ n o lo g ii i a rc h ite k tu ry te c h n ic z n e j. Jako najczęstsze u z a s a d n ie n ie tego p o d e jś c ia p r z y w o ły w a n y jest fa k t, że k a ż d a a u to m a ty z a c ja p ro c e s u b iz n e s o w e g o d a się z re a liz o w a ć w fiz y c z n y m p o d z ia le n a u s łu g i sieciow e. I trze b a p rz y zn a ć , że w ie le cech c h a ra k te ry s ty k i w spółczesn ej S O A , o m a w ia n y c h w ro z d z ia le 3., fa k ty c z n ie m o ż n a u rz e c z y w is tn ić b e z u d z ia łu u s łu g s tr ic te b iz n e s o w y c h , o s zc zę d za ją c w z w ią z k u z ty m s p o ro czasu. W g lo b a ln y m r o z r a c h u n k u , w d łu g o fa lo w e j p e rs p e k ty w ie , tego ro d z a ju k o r z y ­ ści b ę d ą je d y n ie k o rz y ś c ia m i p o z o r n y m i. D la c z e g o ? N a to p y ta n ie p o s ta ra m y się o d p o w ie d z ie ć w k o le jn y c h p u n k ta c h , s z c ze g ó ło w o o m a w ia ją c p o te n c ja ln e p o ż y tk i w y n ik a ją c e z z a s to s o w a n ia o rie n ta c ji n a u s łu g i n a p o z io m ie p ro c e s ó w b izn e s o w y c h .

11.2.1. Usługi biznesowe wbudowują zwinność w modele biznesowe O rie n ta c ja n a u s łu g i n a d a je m o d e lo m b iz n e s o w y m s tru k tu rę , d z ię k i k tó re j m o g ą o n e b y ć ła tw o p r z e m o d e lo w y w a n e w p rz y s z ło ś c i, g d y o k a ż e się to k o n ie c z n e w s k u te k z m ia n z a c h o d z ą c y c h w u w a ru n k o w a n ia c h z e w n ę trz n y c h . U s łu g i b izn e s o w e , g d y p ra w id ło w o z a p ro je k to w a n e , u s ta n a ­ w ia ją ś ro d o w is k o te c h n o lo g ic z n e ła tw o d o s to s o w y w a ln e do o k re ś lo n y c h w y m a g a ń z a p o m o c ą re k o m p o z y c ji p ro c e s ó w b iz n e s o w y c h i (lu b ) re a liz u ją c e j je a rc h ite k tu r y te c h n o lo g ic z n e j (w y ra ż o n e j w fo rm ie w a rs tw y u słu g a p lik a c y jn y c h ). M im o iż b u d o w a n ie S O A k o n c e p c y jn ie je s t p rz e d s ię w z ię c ie m s te ro w a n y m w z g lę d a m i b iz n e ­ s o w y m i, je d n a k re a lia rz e c z y w is te g o ś w ia ta — in fr a s tr u k tu r a , w z g lę d y b e z p ie c z e ń s tw a , o g r a n i­ c z e n ia b u d ż e to w e — s p ra w ia ć m o g ą , że d e c y d u ją c a o b ie ż ą c y m k s z ta łc ie S O A staje się s tro n a te c h n o lo g ic z n a . A to w y z w a la k o n ie c z n o ś ć p rz y s to s o w y w a n ia m o d e li b iz n e s o w y c h do n o w y c h w a ru n k ó w . Ic h a d a p ta c ja m o ż e zostać p rz e p ro w a d z o n a w sposób z w in n y w ła ś n ie d z ię k i w a rs tw ie u s łu g b iz n e s o w y c h , k tó re stają się w y łą c z n y m i o b ie k ta m i k o n ie c z n y c h z m ia n . T a k w ię c z m ia n y w o b rę b ie k tó r e jk o lw ie k z d o m e n — lo g ik i b iz n e s o w e j lu b lo g ik i a p lik a c y jn e j — p o z o s ta ją b e z w p ły w u n a d ru g ą d o m e n ę . K o n ie c z n e z m ia n y k o n c e n tru ją się w w a rs tw ie abs­ tra k c ji u słu g , z n a jd u ją c y c h się n ie ja k o „ m ię d z y m ło te m a k o w a d łe m ” o b u d o m e n . S tan te n p rz e d ­ s ta w io n o p o g lą d o w o n a r y s u n k u 11.2.

11.2.2. Usługi biznesowe przygotowują proces do orkiestracji Jeśli n a w e t a k tu a ln a k o n c e p c ja b u d o w a n ia S O A n ie p rz e w id u je tw o r z e n ia w a rs tw y o rk ie s tra c ji u s łu g , b y ło b y n ie ro z s ą d n ie w y k lu c z y ć z a s a d n o ś ć (lu b k o n ie c z n o ś ć ) w y d z ie le n ia ta k ie j w a rs tw y w p rzy s zło ś c i. O rk ie s tra c ja je s t p rz e c ie ż je d n ą z fu n d a m e n ta ln y c h cech S O A , a g d y z a im p le m e n ­ to w a n a , je s t n a jb a rd z ie j s p e k ta k u la rn ą m a n ife s ta c ją je j o b ecno ści. M o d e lo w a n ie b ie żą c y c h p ro c e ­ s ó w w sposób u ła tw ia ją c y ic h p rz y s z łą m ig ra c ję do ś ro d o w is k a s te ro w a n e g o o rk ie s tra c ją jest w ię c z d e c y d o w a n ie p o ż ą d a n ą p ra k ty k ą .

11.2.3. Usługi biznesowe umożliwiają wieloużywalność W y o d rę b n ie n ie w a rs tw y usług b izn e s o w y c h s p rzy ja w ie lo u ż y w a ln o ś c i usług z a ró w n o b izn e s o w y c h , ja k i a p lik a c y jn y c h , z n a s tę p u ją cy c h w zg lę d ó w .

1 1 .2 . KORZYŚCI Z SO A U K IE R U N K O W A N EJ B IZN ESO W O

337

Rysunek 11.2. Zmiany wywodzące się z domeny biznesowej rekompensowane są przez usługi aplikacyjne i vice versa

M o d e lu ją c lo g ik ę b iz n e s o w ą w p o s ta c i ze s ta w u o d rę b n y c h u s łu g o w y ra ź n ie z a k re ś lo n y c h g ra n ic a c h , z y s k u je m y m o ż liw o ś ć w ie lo k ro tn e g o w y k o rz y s ty w a n ia (w ie lo u ż y w a n ia ) ty c h u s łu g n a p o z io m ie p ro c e s ó w b izn e s o w y c h . N ie p o d z ie ln e fra g m e n ty lo g ik i (p o d p ro c e s y ) lu b n a w e t k o m p le tn e p ro c e s y m o g ą s k ła d a ć się n a lo g ik ę z ło ż o n y c h p ro c e s ó w (co b e z p o ś re d n io p rz e k ła d a się n a k o m p o z y c je u s łu g rzą d zą c e się w ła s n y m i p r a w a m i). P o św ięc ając n a le ż y tą uw a g ę w ła ś c iw e m u z s y n c h ro n iz o w a n iu m o d e li b iz n e s o w y c h z ic h re p re z e n ta cją w postaci usług b izn e s o w y c h , m o ż e m y s p ra w ić , że w a rs tw a usług a p lik a c y jn y c h sta n ie się c a łk o w ic ie n ie z a le ż n a o d p rz e tw a rz a n ia s p e c y fic zn e g o d la k o n k re tn e g o z a d a n ia czy k o n k re tn e j ak ty w n o ś c i. D a je to u s łu g o m a p lik a c y jn y m m o żliw o ś ć e w o lu o w a n ia w p ostaci czysty ch u słu g u ż y tk o w y c h , z d e fin ic ji w ie lo u ż y w a ln y c h i z d o ln y c h do p rz e k ra c z a n ia g ra n ic p o s z c z eg ó ln y c h ro z w ią z a ń .

11.2.4. Tylko za pomocą usług biznesowych można realizować przedsiębiorstwo zorientowane na usługi M o d e lo w a n ie u słu g b iz n e s o w y c h o z n a c z a m a ria ż zasad z o rie n to w a n ia n a u s łu g i z m o d e le m b iz ­ n e s o w y m o rg a n iz a c ji. W re z u lta c ie n a d rz ę d n y cel, ja k im je s t s p e łn ie n ie w y m a g a ń b iz n e s o w y c h tej o r g a n iz a c ji, k la r o w n ie w y r a ż o n y zo s ta je (c a łk o w ic ie lu b w z n a c zą c e j części) w ła ś n ie w p o s ta c i p la n o w a n y c h i tw o rz o n y c h usług.

338

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Z a s to s o w a n ie u s łu g b iz n e s o w y c h z m u s z a o rg a n iz a c ję d o p o n o w n e g o z in te r p r e to w a n ia w ła ­ snej w ie d z y b iz n e s o w e j w sposób w ła ś c iw y z o r ie n to w a n iu n a u s łu g i. S p o jrz e n ie z n o w e j p e rs p e k ­ ty w y n a to , ja k p ro c e s y b izn e s o w e m o g ą b y ć s tru k tu ra liz o w a n e , p a rty c jo n o w a n e i m o d e lo w a n e s ta n o w i z n a c zą c y k r o k w s tro n ę u z y s k a n ia ś ro d o w is k a , w k tó r y m o rie n ta c ja n a u s łu g i jest s p ó jn a , z e s ta n d a ry z o w a n a i p o w s ze c h n a . C h o c ia ż u s łu g i b iz n e s o w e m o g ą a d e k w a tn ie o d z w ie rc ie d la ć k o r p o r a c y jn y m o d e l b iz n e s o w y w czasie ic h im p le m e n to w a n ia , je d n a k n ie m o ż n a w y k lu c z y ć , że stracą sw ą a d e k w a tn o ś ć w m o ­ m e n c ie p o ja w ie n ia się n o w y c h lu b z m o d y fik o w a n y c h w y m a g a ń b iz n e s o w y c h . T a k d łu g o je d n a k , ja k d łu g o b ę d ą u trz y m y w a n e w e w z g lę d n e j z g o d n o ś c i z a k tu a ln y m s ta n e m m o d e li b izn e s o w y c h , w c ią ż m o g ą s pełniać ro lę m ia ro d a jn e g o s p o jrze n ia n a p rze d s ię b io rs tw o — m ia ro d a jn e g o , g d y ż n ie egzys tu ją ja k o ab stra k c ja , le c z w z a im p le m e n to w a n e j, d z ia ła ją c e j p o staci.

A N A LIZA PRZYPADKU

Jak w s p o m in a liś m y w p o p rz e d n ie j a n a liz ie p rz y p a d k u , w f ir m ie R a ilC o z d e c y d o w a n o o w y ­ o d r ę b n ie n iu w b u d o w a n y m S O A d w ó c h p o d w a r s tw u s łu g o w y c h , z ło ż o n y c h (o d p o w ie d n io ) z u s łu g s tric te b iz n e s o w y c h i u s łu g a p lik a c y jn y c h . Z e w z g lę d u n a s k ro m n e rac ze j w y m a g a n ia b izn e s o w e m o ż n a o c ze k iw a ć , że lic ze b n o ś ć u s łu g w k a ż d e j z ty c h p o d w a rs tw b ę d z ie rac ze j n ie w ie lk a ; is to tn y m a s p e k te m tego p o c z ą tk o w e g o p r o je k tu je s t je d n a k z d e fin io w a n ie a rc h i­ t e k tu ry n a tu ra ln ie p rzy s to s o w a n e j do p o w ię k s za n ia tej liczeb n o ści, z g o d n ie z p o trz e b a m i n o w o b u d o w a n y c h p rz y s z ły c h r o z w ią z a ń . E le m e n te m p rz e p ro w a d z o n e j a n a liz y s ta ła się k o n s ta ta c ja p o te n c ja ln y c h k o rz y ś c i w y n i­ k a ją c y c h z z a in w e s to w a n ia w ro z s ze rz a ln e u s łu g i b izn e s o w e . •

M o d e lo w a n ie u s łu g b iz n e s o w y c h m o ż e b y ć p ro w a d z o n e w k a te g o rii g e n e ry c zn e j fu n k c jo n a ln o ś c i, w o d e rw a n iu o d k o n k r e tn y c h u s łu g -w n io s k o d a w c ó w b ę d ą c y c h k o n s u m e n ta m i tej fu n k c jo n a ln o ś c i. D a je to f ir m ie R a ilC o m o ż liw o ś ć s p e łn ie n ia je d n e g o z n a jw a ż n ie js z y c h w y m a g a ń — z d o ln o ś c i do w s p ó łp ra c y o n lin e z w ie lo m a p a r tn e ra m i, p r z y u ż y c iu tego sam ego u n iw e rs a ln e g o ze s ta w u usług.

•

O d s e p a ro w a n ie lo g ik i b izn e s o w e j o d lo g ik i a p lik a c y jn e j u m o ż liw i R a ilC o „ o b u d o w a n ie ” tra d y c y jn e g o s y s te m u fin a n s o w o -k s ię g o w e g o w o to c z k ę z ło ż o n ą z je d n e j lu b k ilk u u słu g . U s łu g i te s ta n o w ić b ę d ą za c zą te k w a rs tw y u s łu g a p lik a c y jn y c h , d o s tę p n e j w spo só b w ie lo u ż y w a ln y d la u s łu g b iz n e s o w y c h u k ie ru n k o w a n y c h z a d a n io w o .

•

W a n a lo g ic z n y sposób — z a p o m o c ą o d p o w ie d n ie j u s łu g i-o to c z k i — m o ż liw e je s t w y e k s p o n o w a n ie lo g ik i in n e g o tra d y c y jn e g o sy s te m u , c z y li s y s te m u k o n ta k tu z m e n e d ż e ra m i. T o z k o le i daje n a tu r a ln ą m o ż liw o ś ć z in te g ro w a n ia te g o ż s ystem u z b u d o w a n ą a rc h ite k tu rą S O A .

N a le ż y z a zn a c zy ć , że są to w n io s k i n a w s k ro ś u n iw e rs a ln e , w y n ik a ją c e z o g ó ln e g o s p o j­ r z e n ia n a p ro c e s y b izn e s o w e w sposób z g o d n y z za s a d a m i z o r ie n to w a n ia n a u s łu g i. D o ty c z ą u s łu g , k tó re n ie b y ły jeszcze n a w e t p r z e d m io te m m o d e lo w a n ia i ja k o ta k ie is tn ie ją w fo r m ie n ie z b y t k o n k re tn y c h k o n c e p c ji.

1 1 .3 . W Y O D R Ę B N IA N IE USŁUG B IZN ESO W YC H

339

P O D S U M O W A N IE

•

Zainwestowanie w oddzielną warstwę usług biznesowych przyczynia się do zwiększenia zwinności organizacyjnej, ponieważ obie domeny logiczne — biznesowa i aplikacyjna — reprezentowane przez własne warstwy abstrakcji uwolnione zostają od bezpośredniej zależności. Dzięki temu mogą ewoluować niezależnie od siebie i łatwo nawzajem przystosowywać się do zmian zachodzących w obrębie jednej z nich.

•

Wyodrębnienie warstwy usług biznesowych sprawia, że SOA jest gotowa na wprowadzenie warstwy orkiestracji, ponadto przyczynia się do wieloużywalności zarówno logiki procesów biznesowych, jak i logiki aplikacyjnej, dzięki starannie zaplanowanej enkapsulacji i abstrakcyjności.

•

Usługi biznesowe stanowią kluczowy środek osiągnięcia standaryzacji i zorientowania na usługi w globalnej skali przedsiębiorstwa.

11.3. W yodrębnianie usług biznesowych N ie is tn ie je ż a d n a d e fin ic ja S O A m a ją c a ra n g ę s ta n d a rd u p rz e m y s ło w e g o , n ie is tn ie je ja k a ś o fi­ c ja ln a , z e s ta n d a ry z o w a n a fo r m a zasad z o r ie n to w a n ia n a u s łu g i, to te ż n ic d z iw n e g o , iż b r a k u je z e s ta n d a ry z o w a n e j w y k ła d n i w te m a c ie m o d e lo w a n ia u s łu g b iz n e s o w y c h . T a k ja k in n e e le m e n ty S O A , ró w n ie ż i te n je j aspekt jest p r z e d m io te m n ie z lic z o n y c h o p in ii i ź ró d łe m m n ó s tw a k o n c e p c ji, n a to m ia s t k o n k re tn y c h m e to d o lo g ii w je j z a k re s ie u k s z ta łto w a ło się z a le d w ie k ilk a . I w p ra k ty c e m o d e lo w a n ie u s łu g b iz n e s o w y c h je s t d ziś ra c z e j s z tu k ą w y b o r u k o n k r e tn e g o p o d e jś c ia , b a rd z ie j w d a n y c h w a ru n k a c h a k c e p to w a ln e g o n iż p o zo s ta łe . T r u d n o z a te m m ó w ić o ja k im ś ś c is ły m , ry g o ry s ty c z n y m p o d e jś c iu d o w y o d r ę b n ia n ia usług. T y p o w y m o d e l b iz n e s o w y p rz e d s ię b io rs tw a n ie je s t s ta ty c z n y m re z u lta te m k re a ty w n o ś c i a n a lity ­ k ó w , lec z p rz e z la ta d o z n a je ty s ię c y m o d y fik a c ji w c elu ciąg łeg o p rz y s to s o w y w a n ia do w a r u n k ó w , w ja k ic h p rz y c h o d z i te m u p rz e d s ię b io rs tw u fu n k c jo n o w a ć . S pecyficzne d la d an ej o rg a n iz a c ji m e to ­ d o lo g ie , re la c je m ię d z y p o d m io ta m i (e n c ja m i) b iz n e s o w y m i c z y s ło w n ic tw o — to w s zy s tk o p r o ­ w a d z i do p o w s ta w a n ia i e w o lu o w a n ia s p e c y fic z n e j s tr u k tu r y m o d e lu b iz n e s o w e g o . C o w ię c e j, o d m ie n n e d la ró ż n y c h f ir m u w a ru n k o w a n ia k u ltu ro w e o ra z z w ią z k i z d o s ta w c a m i s p rzę tu i o p ro ­ g ra m o w a n ia p o w o d u ją z ró ż n ic o w a n ie w z a k re s ie n a rz ę d z i i ję z y k ó w w y k o rz y s ty w a n y c h do a r ty ­ k u ło w a n ia i u trz y m y w a n ia m o d e li b iz n e s o w y c h ty c h fir m . E rg o — k a ż d y m o d e l b iz n e s o w y je s t tw o r e m u n ik a to w y m ; w y k o rz y s tu ją c go z a te m ja k o p o d ­ staw ę do w y o d rę b n ia n ia u s łu g b iz n e s o w y c h n ie sposób u n ik n ą ć u p rz e d n ie j g ru n to w n e j a n a liz y , je ż e li u s łu g i te m a ją ja k n a jle p ie j re p re z e n to w a ć o rg a n iz a c ję ja k o s p ó jn y p o d m io t g o s p o d a rc zy .

11.3.1. Źródła dla wyodrębniania usług biznesowych F u n k c jo n o w a n ie k a ż d e j o rg a n iz a c ji, n ie z a le ż n ie o d je j s tru k tu ry i r o z m ia r u , p o s trze g a n e z w n ę ­ trz a te jże o rg a n iz a c ji daje się z d e k o m p o n o w a ć w p o s ta c i k o le k c ji u s łu g b iz n e s o w y c h . K a ż d a z ty c h u s łu g re p re z e n tu je p e w n ą lo g ic z n ą je d n o s tk ę p ra c y , a fu n k c jo n o w a n ie w s p o m n ia n e j o rg a n iz a c ji je s t w ła ś n ie k o n g lo m e ra te m ta k ic h je d n o s te k .

340

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

D la k a ż d e j o rg a n iz a c ji sp e c y fic zn e są s tr u k tu ra i sposób d o k u m e n to w a n ia je j d z ia ła ln o ś c i. W y ja ś n ia liś m y p rz e d c h w ilą , że s p e c y fik a k a ż d e j o rg a n iz a c ji p r z e k ła d a się n a spec y fik ę je j m o d e lu b izn e s o w e g o o ra z m e to d jeg o im p le m e n to w a n ia i u tr z y m y w a n ia . Z a d a n ie m a n a lity k ó w je s t w ię c p rz e ło ż e n ie te j s p e c y fik i n a s p e c y fic zn e , ja k n a jb a rd z ie j a d e k w a tn e , o d w z o ro w a n ie lo g ik i b iz n e ­ sow ej w p o s ta c i z b io ru usług. P r z e d s ta w ia m y p o n iż e j k ilk a p r z y k ła d ó w ty p o w y c h p o d e jś ć do a n a liz y b iz n e s o w e j, sto s o ­ w a n y c h w w ie lu p rz e d s ię b io rs tw a c h , a s zc ze g ó ln ie sposób w y o d rę b n ia n ia u s łu g b iz n e s o w y c h n a g ru n c ie k a żd e g o z ty c h podejść.

Modele zarządzania procesami biznesowymi (BPM) P o ja w ie n ie się m o d e li B P M (B u s in e ss P rocess M a n a g e m e n t) s p o w o d o w a ło , że f ir m y z a c zę ły d o c e ­ n ia ć z n a c ze n ie m o d e li b iz n e s o w y c h i po ś w ię c a ć n a le ż n ą u w a g ę m o d e lo w a n iu i re m o d e lo w a n iu b iz n e s o w e m u . M o d e l b iz n e s o w y p rz e d s ię b io rs tw a s tał się c e n tra ln y m p u n k te m d o k u m e n to w a n ia a n a liz y b izn e s u , lo g ik a p rz e p ły w u p ra c y m ię d z y p ro c e s a m i b iz n e s o w y m i s ta ła się m a te r ia łe m ź r ó ­ d ło w y m d la d e fin io w a n ia u s łu g b izn e s o w y c h . Jak p is a liś m y w ro z d z ia le 3 ., za k re s lo g ik i e n k a p s u lo w a n e j p rz e z usługę b iz n e s o w ą m o ż e b y ć w ie lc e z ró ż n ic o w a n y : m o ż e re p re z e n to w a ć k r o k (e ta p ) p ro c e s u , p o d p ro c e s w ię k s ze g o p ro c e s u lu b n a w e t k o m p le tn y proces. Z ilu s tr o w a liś m y to s c h e m a ty c z n ie n a ry s u n k u 3.1 i p r z y p o m in a m y n a ry s u n k u 11.3.

Rysunek 11.3. Zróżnicowanie zakresu logiki biznesowej reprezentowanej przez pojedynczą usługę

1 1 .3 . W Y O D R Ę B N IA N IE USŁUG B IZN ESO W YC H

341

W y o d rę b n ia n ie u s łu g i b izn e s o w e j n a p o d s ta w ie p ro c e s u b izn e s o w e g o w y m a g a d o g łę b n e j w ie ­ d z y n a te m a t lo g ik i p rz e p ły w u p ra c y . D e fin io w a n ie za k re s u lo g ik i b iz n e s o w e j je s t w g łó w n e j m ie ­ rz e k w e s tią s u b ie k ty w n e j oceny; o d tra fn o ś c i tej o c e n y z a le ż y ja k o ś ć w s p o m n ia n e j u s łu g i ja k o s k ła d n ik a całego ś ro d o w is k a . I v ic e v e rs a — o d ja k o ś c i p o s z c z e g ó ln y c h u s łu g z a le ż y o g ó ln a ja k o ś ć śro d o w iska, k tó re g o są s k ła d n ik a m i. Jest z ro z u m ia łe , że p o d e jm o w a n ie d ecyzji o ta k d a le k o s ię żn y c h k o n s e k w e n c ja c h m u s i o p ie ra ć się n a s o lid n y c h p o d s ta w a c h .

UW AGA

Warto w tym miejscu przypomnieć, że jakkolwiek zwykło się ilustrować enkapsulowanie logiki biznesowej w podziale na kompletne usługi, w rzeczywistości jednostkami logicznymi tego enkapsulowania są poszcze­ gólne operacjetych usług. Identyfikując zatem elementy logiki przeznaczone do wspomnianej enkapsulacji, należy czynić to na poziomie pojedynczych operacji; dopiero na bazie proponowanego grupowania tychże operacji następuje wyodrębnianie kandydatur na usługi.

A N A LIZA PRZYPADKU

P o n iż e j o p is u je m y d w a p ro c e s y f ir m y R a ilC o częścio w o z a u to m a ty z o w a n e z a p o m o c ą usług. W p o p rz e d n ic h ro z d z ia ła c h k o n c e n tro w a liś m y się w y łą c z n ie n a in te ra k c ja c h u sług, o g r a n i­ c z y liś m y się z a te m je d y n ie do r o li u s łu g W ystawienie faktury i Realizacja zam ówienia w sc e n a riu s zu w s p ó łd z ia ła n ia z s y s te m e m B 2B f ir m y T L S . T e n opis p rz e d s ta w ia n a to m ia s t s tru k tu rę w e w n ę trz n y c h p ro c e s ó w R a ilC o , b o ic h g łó w n ie do ty c zy ć b ę d ą k o n s e k w e n c je w p r o ­ w a d z a n ia S O A . Z a c z n ijm y o d Procesu wystawiania faktury . S ta n o w i o n n a s tę p u ją c y szereg e ta p ó w g e n e ­ r o w a n ia fa k tu r d la f ir m y T L S . 1. P ra c o w n ik k s ię g o w o ś c i s p o rz ą d z a i w y s y ła fa k tu rę e le k tro n ic z n ą , k o rz y s ta ją c z tra d y c y jn e g o s y s te m u fin a n s o w o -k s ię g o w e g o . 2. Z a p is y w a n ie fa k tu r y je s t z d a rz e n ie m u ru c h a m ia ją c y m s k ry p t p o w o d u ją c y e k s p o rto w a n ie k o p ii fa k tu r y do fo ld e r u sie c io w e g o . 3.

S p e c ja ln ie s k o n s tru o w a n y k o m p o n e n t w o d s tę p a c h 1 0 -m in u to w y c h a n a liz u je z a w a rto ś ć tego fo ld e ru i w p r z y p a d k u s tw ie rd z e n ia ob e c n o ś c i n o w e g o d o k u m e n tu t w o r z y jeg o o b ra z w fo rm a c ie X M L .

4.

D o k u m e n t-o b r a z w fo rm a c ie X M L p o d d a w a n y je s t w a lid a c ji. G d y u z n a n y z o s ta n ie z a p o p ra w n y , p r z e k a z y w a n y je s t u s łu d ze Wystawienie faktury ; n e g a ty w n y w y n ik w a lid a c ji p o w o d u je o d rz u c e n ie d o k u m e n tu i z a k o ń c z e n ie całego p rocesu.

5. Z a le ż n ie o d te g o , ja k d a w n o n a s tą p iło p o b ra n ie m e ta d a n y c h z s y s te m u B 2B f ir m y T L S , u słu g a Wystawienie faktury m o ż e w y s ła ć k o m u n ik a t-ż ą d a n ie G e tM e ta d a ta d o tego s ystem u w celu s p ra w d z e n ia a k tu a ln e j w e rs ji o p is ó w u s łu g tego system u.

342

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

6.

Jeżeli z o trz y m a n e g o k o m u n ik a tu -o d p o w ie d z i G e tM e ta d a ta w y n ik a , że w s p o m n ia n e m e ta d a n e n ie z m ie n iły się (b ą d ź te ż d o m n ie m y w a n a je s t ic h a k tu a ln o ś ć b e z w y s y ła n ia ż ą d a n ia G e tM e ta d a ta ), d o k u m e n t-fa k tu ra tra n s m ito w a n y jest do system u B 2B f ir m y T L S p r z y u ż y c iu z a p e w n ie n ia d o s ta rc z e n ia E x a c tly O n c e (p a trz p u n k t 7 .2 .4 ). Jeśli n a to m ia s t s tw ie rd z o n a zostaje z m ia n a w s p o m n ia n y c h m e ta d a n y c h , d o k u m e n t-fa k tu ra n ie zostaje w ys łan y. W o b u p rz y p a d k a c h c a ły proces zostaje z a k o ń c zo n y .

D r u g i w e w n ę trz n y proces — Proces realizacji zamówienia — jest p o d o b n y p o d w z g lę d e m re la c ji zachodzącej m ię d z y s y stem em fin a n s o w o -k s ię g o w y m a usługą sieciow ą, je d n a k ż e dane p rz e p ły w a ją w o d w ro tn y m k ie ru n k u , w e d łu g następująceg o scenariusza: 1. U s łu g a Realizacja zamówienia o trz y m u je o d T L S k o m u n ik a t S O A P , w k tó re g o ła d u n k u u ż y te c z n y m z n a jd u je się d o k u m e n t z a m ó w ie n ia w fo rm a c ie X M L . 2. U s łu g a Realizacja zamówienia w a lid u je w s p o m n ia n y d o k u m e n t. G d y d o k u m e n t u z n a n y z o s ta n ie za p o p ra w n y , p r z e k a z y w a n y jest do sp ecjaln eg o k o m p o n e n tu ; n e g a ty w n y w y n ik w e ry fik a c ji p o w o d u je o d rz u c e n ie d o k u m e n tu i w y s ła n ie k o m u n ik a tu -p o w ia d o m ie n ia do T L S o ra z z a k o ń c z e n ie całego p rocesu. 3. W s p o m n ia n y s p e c ja ln y k o m p o n e n t tra n s fo rm u je o trz y m a n y d o k u m e n t z fo r m a tu X M L do p o sta c i fo r m a tu n a ty w n e g o d la s y s te m u fin a n s o w o -k s ię g o w e g o . 4.

S k o n w e rto w a n y d o k u m e n t p rz e s y ła n y je s t do s y s te m u fin a n s o w o -k s ię g o w e g o p r z y u ż y c iu fu n k c ji im p o r tu tego system u.

5.

S ystem fin a n s o w o -k s ię g o w y w s ta w ia o trz y m a n y d o k u m e n t do k o le jk i d o k u m e n tó w o c z e k u ją c y c h n a p r z e tw o rz e n ie p rz e z p ra c o w n ik a k s ięg ow ości.

D la p rz e jrz y s to ś c i c e lo w o p o m in ę liś m y n ie k tó re k r o k i w k a ż d y m z p ro c e s ó w : w p r z y p a d ­ k u Procesu wystawiania faktury je s t to o d e b ra n ie o d T L S p o tw ie r d z e n ia o tr z y m a n ia fa k tu ry , w p rz y p a d k u Proces realizacji zamówienia — w y s y ła n e do T L S p o tw ie rd z e n ie o trz y m a n ia z a m ó w ie n ia (jeśli p o tw ie rd ze n ie ta k ie jest p rze z T L S w y m a g a n e ). O g ra n ic zy liś m y się do k ro k ó w n a jis to tn ie js z y c h d la n aszego s tu d iu m im p le m e n to w a n ia S O A w f ir m ie R a ilC o . D o p o w y żs ze g o o p is u p o w ró c im y w ro z d z ia le 12., g d zie s ta n o w ić o n b ę d z ie p o d s ta w ę d la p re z e n ta c ji p ro c e s u m o d e lo w a n ia usług.

M odele podm iotów biznesowych P o d s ta w o w e p o d m io ty (e n c je ) r e p re z e n tu ją g łó w n e o b s z a ry tra n s a k c ji i d o k u m e n tó w w p rz e d s ię ­ b io rs tw ie . F a k tu r a , z le c e n ie z a k u p u , k lie n t, re k la m a c ja — to p r z y k ła d y p o d m io tó w n a jc zę ś c ie j s p o ty k a n y c h w k a ż d e j n ie m a l g a łę zi b izn e s u . O c z y w iś c ie , p o d m io ty te n ie egzy s tu ją w p r ó ż n i, lecz są p o w ią z a n e i p o d p o rz ą d k o w a n e re g u ło m b iz n e s o w y m o ra z z a ło ż e n io m p o lity k i; c h a ra k te r ty c h p o w ią z a ń i re g u ł je s t k w e s tią s p e c y fik i d a n e j fir m y . U s łu g i u k ie r u n k o w a n e p o d m io to w o ( z a jm ie m y się n im i z a c h w ilę ) o d z w ie r c ie d la ją m o d e l p o d m io tó w f ir m y w p o s ta c i z b io ru g e n e ry c z n y c h o p e ra c ji, o d p o w ia d a ją c y c h fu n k c jo m s k o ja rz o ­ n y m z p r z e tw a rz a n ie m o k re ś lo n y c h p o d m io tó w . K o m u n ik a c ja m ię d z y u s łu g a m i u k ie ru n k o w a ­ n y m i p o d m io to w o ró w n ie ż m o że po d leg ać re g u ło m i o g ra n ic z e n io m o d z w ie rc ie d la ją c y m n a tu ra ln e re lac je z ach o d ząc e m ię d z y p o d m io ta m i.

1 1 .3 . W Y O D R Ę B N IA N IE USŁUG B IZN ESO W YC H

343

UW AGA

Nazwy usług ukierunkowanych podmiotowo wzorowane są na konwencji zaczerpniętej z obszaru progra­ mowania zorientowanego obiektowo, gdzie obiekty opatrywane są nazwami rzeczownikowymi, podczas gdy form czasownikowych używa się do nazywania metod. Ponieważ usługi ukierunkowane podmiotowo re­ prezentują encje danych, więc zwykle ich nazwy są rzeczownikami, natomiast poszczególnym ich operacjom przyporządkowywane są nazwy czasownikowe.

A N A LIZA PRZYPADKU

W R a ilC o z d e c y d o w a n o o b u d o w a n iu u sług u k ie r u n k o w a n y c h n a k o n k re tn e z a d a n ia , z a te m m o d e le p o d m io tó w n ie b ę d ą w y k o rz y s ty w a n e ja k o ź ró d ło w y o d rę b n ia n ia usłu g . M im o to , b y z a d e m o n s tr o w a ć s a m ą k o n c e p c ję p o d m io tó w b iz n e s o w y c h , s p r ó b u jm y z id e n t y f ik o w a ć te z n ic h , k tó re w y s tą p iły (p o s tro n ie R a ilC o ) w z a p re z e n to w a n y c h d o ty c h c za s a n a liz a c h p r z y ­ padków . W b e z p o ś re d n im z w ią z k u z d w o m a p ro c e s a m i o p is a n y m i w p o p rz e d n ie j a n a liz ie p r z y ­ p a d k u p o z o s ta ją n astę p u ją ce p o d m io ty :

• faktura , • zlecenie zakupu . P ro ce sy te z w ią z a n e są je d n a k (w sposób m n ie j o c z y w is ty ) z in n y m i d o d a tk o w y m i p o d ­ m io ta m i, a m ia n o w ic ie z:

• pracownikiem , • zamówieniem , • potwierdzeniem zamówienia , • klientem . W d o ty c h c z a s o w y c h a n a liz a c h p r z y p a d k u m o ż e m y ta k że z id e n ty fik o w a ć n a s tę p u ją ce r e ­ lacje z a ch o d zące p o m ię d z y p o s z c z e g ó ln y m i p o d m io ta m i R a ilC o .

• Zlecenie zakupu m o ż e b y ć p o w ią z a n e z n ie u je m n ą lic z b ą faktur . • Zlecenie zakupu m o ż e b y ć p o w ią z a n e z d o k ła d n ie je d n y m klientem . • Zamówienie m o ż e b y ć p o w ią z a n e z je d n y m zleceniem zakupu lu b k ilk o m a t a k im i z le c e n ia m i.

• Potwierdzenie zamówienia m o ż e d o ty c z y ć je d n e g o zlecenia zakupu lu b k ilk u zleceń . • Faktura m o ż e b y ć p o w ią z a n a z d o k ła d n ie je d n y m klientem . • Pracownik m o ż e b y ć p o w ią z a n y z n ie u je m n ą lic z b ą faktur , zleceń zakupu , zam ówień , potwierdzeń lu b klientów . O p is a n e p o w y ż e j re la c je to re la c je ty p u „ je d e n do je d n e g o ” i „ je d e n do w ie lu ”. Z ilu s tr o ­ w a n o je n a ry s u n k u 11.4.

344

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Rysunek 11.4. Relacje zachodzące między podmiotami (encjami) RailCo (zwykle wewnątrz symbolu podmiotu specyfikuje się także jego atrybuty)

11.3.2. Typy wyodrębnianych usług biznesowych Jest z ro z u m ia łe , że w y o d rę b n ia n ie u sług b iz n e s o w y c h n a p o d s ta w ie d w ó c h ró ż n y c h ź ró d e ł s k u t­ k o w a ć m u s i o trz y m a n ie m d w ó c h ró ż n y c h ty p ó w ty c h usług.

Zadaniowe usługi biznesowe T o u s łu g i sie cio w e , k tó r y c h m o d e lo w a n ie s łu ży ć m a re a liz a c ji o k re ś lo n e g o p ro c e s u b izn e s o w e g o . O p e ra c je ta k ic h u sług g ru p o w a n e są s to s o w n ie do z w ią z k u z w y k o n y w a n ie m k o n k r e tn y c h z a d a ń p o d p o rz ą d k o w a n y c h w s p o m n ia n e m u p ro c e s o w i. N a p o d s ta w ie d o ty c h c z a s o w y c h a n a liz p r z y p a d k ó w d o m n ie m y w a ć m o ż n a is tn ie n ie w R a ilC o i T L S d w ó c h u s łu g teg o r o d z a ju , ta k ic h ja k :

• Weryfikacja faktury , • Raport historii zleceń .

1 1 .3 . W Y O D R Ę B N IA N IE USŁUG B IZN ESO W YC H

345

K a ż d a z ty c h usług o b e jm u je operacje zw ią z a n e z k o n k r e tn y m i z a d a n ia m i w k o n te k ś c ie procesu. U s łu g i z a d a n io w e s ta n o w ią za zw y c z a j re z u lta t m o d e lo w a n ia s k o n c e n tro w a n e g o n a s p e łn ie n iu d o ­ ra ź n y c h w y m a g a ń b iz n e s o w y c h . T y p o w y m i m a te r ia ła m i ź r ó d ło w y m i do ta k ie g o m o d e lo w a n ia są m o d e le p rz y p a d k ó w u ż y c ia (use-case m o d e ls ) i d e fin ic je p ro c e s ó w m o d e lu B P M . C h o ć u s łu g i tego ty p u w y m a g a ją m n ie j p ra c o c h ło n n e j a n a liz y , je d n a k m o ż liw o ś c i ic h w ie lo u ż y w a n ia są m o c n o o g ra n ic z o n e . M o ż n a z w ię k s z y ć ic h p o te n c ja ł w ie lo u ż y w a ln o ś c i, a n a liz u ją c u p rz e d n io w ie le m o d e li p r z y p a d k ó w u ż y c ia i p ro c e s ó w b iz n e s o w y c h w c e lu z id e n ty fik o w a n ia w s p ó ln y c h e le m e n tó w , jeszcze p rz e d p rz y s tą p ie n ie m do w ła ś c iw e g o m o d e lo w a n ia .

A N A LIZA PRZYPADKU

P oniższe usługi, choć z a p ro je k to w a n e ja k o h y b ry d o w e , o p ierają się n a m o d e lu u k ie ru n k o w a n y m n a zadania:

• Wystawienie faktury, • Realizacja zamówienia , • Subskrypcja TLS. (O s ta tn ia z w y m ie n io n y c h , m im o iż z a w ie ra w n a z w ie c z ło n „ T L S ” , je s t je d n a k u s łu g ą R a ilC o re a liz u ją c ą k o m u n ik a c ję z T L S ).

Podmiotowe usługi biznesowe U s łu g i b izn e s o w e u k ie ru n k o w a n e p o d m io to w o są z w y k le częścią re z u lta tu d łu g o fa lo w y c h w y s ił­ k ó w a n a lity c z n y c h z m ie rz a ją c y c h do z s y n c h ro n iz o w a n ia u s łu g b iz n e s o w y c h z k o rp o r a c y jn y m i m o d e la m i b iz n e s o w y m i. P rz y ro d z o n a g e n e ry c zn o ś ć ta k ic h u s łu g s p ra w ia , że są w ysoce w ie lo u ż y w a ln e d la w ie lu p ro c e s ó w b izn e s o w y c h . M im o iż są o n e często p ro je k to w a n e i tw o rz o n e w r a ­ m a c h p ro je k tó w o b ra c a ją c y c h się w o k ó ł k o n k r e tn y c h p ro c e s ó w b iz n e s o w y c h , r ó ż n ią się o d u sług z a d a n io w y c h ty m , że n ie d o s ta rc z a ją in te rfe js ó w s p e c y fic z n y c h d la ty c h p ro c e s ó w , b o in s p iro w a n e są m o d e la m i p o d m io to w y m i, n ie z a d a n io w y m i. W p o r ó w n a n iu z u s łu g a m i z a d a n io w y m i, u s łu g i p o d m io to w e z a p e w n ia ją w ię k s zą z w in n o ś ć p o d c za s r e m o d e lo w a n ia p ro c e s ó w b iz n e s o w y c h z o rie n to w a n y c h n a u s łu g i. Jest ta k d la te g o , że u s łu g i z a d a n io w e b u d o w a n e są z w y k le z m y ś lą o a u to m a ty z a c ji k o n k re tn e g o p ro c e s u i ja k o ta k ie stają się ściśle p o w ią z a n e z ty m p ro cesem . G d y te n się z m ie n ia , z m ie n ia się ta k że k o n te k s t, w ja k im w s p o m n ia n e u s łu g i są w y k o rz y s ty w a n e i k o m p o n o w a n e ; sposób p o g ru p o w a n ia o p e ra c ji w u s łu g i m o ż e w ó w czas o k a z y w a ć się n ie a d e k w a tn y do n o w e j s y tu a c ji — co s p o w o d u je k o n ie c zn o ś ć p o ­ n o w n e g o p ro je k to w a n ia i tw o r z e n ia p o s z c z e g ó ln y c h usług. U s łu g i p o d m io to w e w o ln e są o d ta k ie g o u z a le ż n ie n ia , b o tw o rz o n e są ja k o g e n e ry c z n e , n ie m a ją c e z w ią z k u a p r io r i z lo g ik ą k o n k re tn e g o p ro c e s u b izn e s o w e g o . W lo g ik ę ta k ą u w ik ła n e z o ­ stają d o p ie ro z a s p ra w ą n a d rz ę d n y c h k o n tr o le r ó w , k t ó r y m i m o g ą b y ć u s łu g i z a d a n io w e b ą d ź p r o ­ c e so w a u s łu g a o rk ie s tr u ją c a . Jak w y ja ś n ia liś m y w r o z d z ia le 9 ., w a r s tw a u s łu g p o d m io to w y c h k o m p o n o w a n y c h p rz e z usługę p ro c e s o w ą re z y d u ją c ą w w a rs tw ie o rk ie s tra c ji s ta n o w i fo r m ę S O A n a jb a rd z ie j p o ż ą d a n ą , b o n a jb a rd z ie j p rz e jrz y ś c ie re p re z e n tu ją c ą m o d e l b iz n e s o w y i z a p e w n ia ją c ą w y s o k i s to p ie ń z w in n o ś c i o rg a n iz a c y jn e j. W s z y s tk ie te z a le ty o k u p io n e są je d n a k k o n ie c zn o ś c ią d o g łę b n e j a n a liz y w s tę p n e j, co p rz e k ła d a się z a ró w n o n a w y ż s zy k o s z t k a ż d e j z u sług, ja k i d łu żs z y czas o c z e k iw a n ia n a je j w y p ro d u k o w a n ie .

346

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

A N A LIZA PRZYPADKU

W p o p rz e d n ie j a n a lizie p rz y p a d k u s tw ie rd z iliś m y , że m im o z id e n ty fik o w a n ia w fir m ie R a ilC o p o d m io tó w b iz n e s o w y c h , n ie u tw o rz o n o w tej f ir m ie u s łu g u k ie r u n k o w a n y c h p o d m io to w o . W f ir m ie T L S je s t z g o ła in a c ze j: in w e s tu ją c w s tra te g ię z s tę p u ją c ą re a liz a c ji S O A , w y o d rę b ­ n io n o i u tw o rz o n o ta m ze s ta w n a s tę p u ją c y c h u s łu g p o d m io to w y c h (p a tr z ry s u n e k 11.5):

• Płatność na konto , • Zlecenie zakupu , • Rejestr księgi głównej , • Profile dostawców .

Rysunek 11.5. Różne organizacje — różne podejścia do budowania usług

Jako w y ko rzysty w a n e w e w n ę trz n ie w ra m a c h system u B 2B, usługi te n ie w y m a g a ją n a d rz ę d ­ nego k o n tro lo w a n ia p rz e z o d d z ie ln e u sługi z a d a n io w e czy usługę p rocesow ą. U s łu g i Płatność

na konto i Zlecenie zakupu n ie są częścią k o n k re tn e g o p ro c e s u b izn e s o w e g o s p ecyficzn eg o d la w s p o m n ia n e g o system u B 2B , lecz w y k o n u ją je d y n ie proste fu n k c je p rz e tw a rza n ia n a p o trz e b y s y s te m u fin a n s o w o -k s ię g o w e g o : p r z y jm o w a n ie p o p ra w n y c h fa k tu r i w y s y ła n ie p o p ra w n y c h z le c e ń z a k u p u . T a p ro s ta lo g ik a n ie w y m a g a ż a d n e j d o d a tk o w e j o rg a n iz a c ji. T L S p lan u je b u d o w ę k o le jn y c h usług p o d m io to w y c h , lecz (o c zy m p isaliśm y w ro zd zia le 10.) p rz y u ż y c iu strateg ii z w in n e j, a n ie zastoso w anej u p rz e d n io czystej s tra te g ii zstępującej. R a ilC o , d la o d m ia n y , n ie p o s ia d a ś ro d k ó w b u d ż e to w y c h a n i w y s ta rc za ją c e g o czasu n a w y p o s a ż a n ie k a ż d e j n o w e j u słu g b izn e s o w e j w d o d a tk o w ą fu n k c jo n a ln o ś ć z w ią z a n ą z m o ż liw o ś c ią w ie lo u ż y w a n ia . N ie p la n u je w ię c b u d o w a n ia u sług p o d m io to w y c h .

1 1 .3 . W Y O D R Ę B N IA N IE USŁUG B IZN ESO W YC H

347

11.3.3. Usługi biznesowe i orkiestracje U s łu g a p ro c e s o w a o rk ie s tru ją c a u s łu g i b izn e s o w e z w a rs tw n iż s z y c h s a m a m o ż e b y ć u w a ż a n a za o d m ia n ę u s łu g i b izn e s o w e j. Jest s iln ie „ u k ie r u n k o w a n a b iz n e s o w o ”, re z y d u je n a s a m y m szczycie h ie ra rc h ii u słu g i o d p o w ie d z ia ln a je s t za k o m p o n o w a n ie u s łu g b iz n e s o w y c h z g o d n ie z u s ta lo n y m i re g u ła m i lo g ik i p rz e p ły w u p ra c y . K o n cep cję i szczegóły fu n k c jo n o w a n ia usług p ro c e s o w yc h o p is y w a liś m y w ro z d z ia le 6. (w p o d ­ ro z d z ia le „ O rk ie s tra c je ”) i w ro z d z ia le 9. ( w p o d ro z d z ia le „ W a r s tw a o rk ie s tra c ji u s łu g ”) , p o w r ó ­ c im y do tej te m a ty k i ta k że w ro z d z ia le 16. O rk ie s tra c ja w o g ó ln y m p rz y p a d k u m o ż e k o m p o n o w a ć m ie s z a n k ę o b u ty p ó w u sług b iz n e s o w y c h — z a d a n io w y c h i p o d m io to w y c h : m o d e l b iz n e s o w y jest w ó w c za s re p re z e n to w a n y p rz e z u s łu g i p o d m io to w e , p odczas g d y u s łu g i z a d a n io w e , im p le m e n ­ tu ją c e z a d a n ia z w ią z a n e z lo g ik ą b iz n e s o w ą , p e łn ią ro lę u z u p e łn ia ją c ą w s to s u n k u do u s łu g i p r o ­ cesow ej (d o k tó re j to r o li z o s ta ły s p e c ja ln ie z a p ro je k to w a n e ). R ea su m u jąc, m o ż e m y p o w ie d z ie ć , że zastoso w anie o rk ie s tra c ji u s ta n a w ia n astęp u jącą h ie ra rc h ię w w a rs tw ie usług. 1. L o g ik a p rz e p ły w u p ra c y i r e g u ły b izn e s o w e sp e c y fic zn e d la p ro c e s u w b u d o w a n e są w d e fi­ n ic ję u s łu g i p ro c e s o w e j. U s łu g a p ro c e s o w a p e łn i ro lę k o n tr o le r a k o m p o n u ją c e g o u s łu g i b izn e s o w e (i, b y ć m o ż e , u s łu g i a p lik a c y jn e ) s to s o w n ie do o w e j d e fin ic ji. 2. U s łu g i b izn e s o w e p e łn ią ro lę k o n tr o le ró w , k o m p o n u ją c u s łu g i a p lik a c y jn e o d p o w ie d z ia ln e za re a liz a cję lo g ik i b izn e s o w e j. 3. U s łu g i a p lik a c y jn e o d p o w ia d a ją za in te ra k c ję z s y s te m a m i re a liz u ją c y m i żą d a n e fu n k c je . D z ię k i o rk ie s tra c ji lo g ik a p rz e p ły w u p ra c y zostaje w y a b s tra h o w a n a i u m ie js c o w io n a p o z a g ra n i­ c a m i k o n k re tn y c h u słu g b iz n e s o w y c h i a p lik a c y jn y c h ; p rz y s złe z m ia n y w z a k re s ie tej lo g ik i b ę d z ie w ię c m o ż n a u w z g lę d n ia ć b e z in te rw e n io w a n ia w te usługi. T o n ie z w y k le w a żn e z p u n k tu w id z e n ia z w in n o ś c i o rg a n iz a c y jn e j: lo g ik a p ro c e s ó w b iz n e s o w y c h p o d a tn a je s t n a n ie o c z e k iw a n e z m ia n y w y n ik a ją c e z lu d z k ie j in te r w e n c ji, z m ia n y w k o r p o ra c y jn y c h re g u ła c h b iz n e s o w y c h lu b z a ło ż e ­ n ia c h p o lity k i, n ie p rz e w id y w a ln e s ytuacje w y ją tk o w e i ty m p o d o b n e . S k u p ie n ie re p re z e n ta c ji tej lo g ik i w je d n y m m ie js c u — u s łu d ze p ro c e s o w ej — s k u te c zn ie u ła tw ia a d e k w a tn ą re a k c ję n a tego ty p u z m ia n y .

A N A LIZA PRZYPADKU

C zę ś c ią p la n ó w T L S d o ty c z ą c y c h ro z b u d o w y is tn ie ją c e j S O A je s t w p ro w a d z e n ie w a rs tw y o r ­ k ie s tra c ji usług. R e a liza c ja ty c h p la n ó w ro z p o c z n ie się o d z d e fin io w a n ia u s łu g i p ro c e s o w ej a b s tra h u ją c e j re g u ły b iz n e s o w e i lo g ik ę p r z e p ły w u p ra c y , d z ię k i c z e m u e le m e n ty te b ę d z ie m o ż n a w y e lim in o w a ć z ju ż is tn ie ją c y c h usług. I c h o c ia ż w y m a g a to zn a c zą c y c h w y s iłk ó w z w ią z a n y c h z m o d e lo w a n ie m , z a k ła d a się, iż p o c z ą tk o w o p o zo s ta n ie b e z w p ły w u n a istn ie ją c ą s tru k tu rę usług i ic h in te rfe js ó w . G d y w fazie p ro je k to w a n ia z o rie n to w a n e g o n a u s łu g i z d e te r m in o w a n y z o s ta n ie sposób r e p re z e n to w a n ia lo g ik i p r z e p ły w u p ra c y p rz e z u s łu g ę p ro c e s o w ą , b ę d z ie m o ż n a o k re ś lić rz e c z y w is ty w p ły w w a rs tw y o rk ie s tra c ji u s łu g n a is tn ie ją c e u s łu g i b izn e s o w e . P o w ró c im y do tego te m a tu w n a s tę p n y m ro z d z ia le , w p o d ro z d z ia le „ P o ró w n a n ie p o d ejść d o m o d e lo w a n ia u słu g (p r z y k ła d )”.

348

RO ZD ZIA Ł 1 1 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

P O D S U M O W A N IE

•

Usługi biznesowe wyodrębniane są na podstawie głównych dokumentów modeli biznesowych: modeli przypadków użycia, definicji procesów biznesowych i modeli podmiotów (encji).

•

Wyodrębniane są zasadniczo dwa podstawowe typy usług biznesowych: usługi zadaniowe i usługi podmiotowe. Różnią się one funkcjami spełnianymi w ramach logiki biznesowej oraz sposobem enkapsulowania tej logiki.

Analiza zorientowana na usługi (Część II. Modelowanie usług) 1 2.1. M o d e lo w a n ie u s łu g k r o k p o k r o k u 1 2.2. W y ty c z n e i w s k a z ó w k i d o ty c zą ce m o d e lo w a n ia u sług 1 2.3. K la s y fik a c ja lo g ik i m o d e lu u sług 1 2.4. P o ró w n a n ie p o d e jś ć do m o d e lo w a n ia (p rz y k ła d )

350

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

W tym rozdziale kontynuujem y tematykę rozdziału poprzedniego, opisując szczegółowo proces modelowania usług jako scenariusz prowadzący do zdefiniowania kandydatur na operacje usług i kandydatur na usługi. Analizy przypadków: Ponownie odwiedzamy firmę RailCo z intencją zastąpienia aktualnego zestawu usług w jej środowisku przez dobrze zdefiniowane warstwy usług biznesowych i apli­ kacyjnych. Po opisaniu procesu modelowania usług na początku rozdziału zajmiemy się ko n ­ struow aniem kandydatur na usługi oraz ich kom ponow aniem we wstępną postać warstw usługowych. Pod koniec rozdziału odwiedzimy zespół projektantów w TLS, by w ram ach (dłuższej niż zwykle) analizy przypadku śledzić ich próby zastosowania trzech podejść do modelowania usług w związku z pojawieniem się nowego problemu na drodze transformacji firmy w stronę SOA.

1 2 .1 . M o d e lo w a n ie u sług k ro k p o kroku Proces modelowania usług to w istocie eksperymentowanie w zakresie organizowania informacji zebranej w obu krokach analizy zorientowanej na usługi. Informacja ta pochodzić może z róż­ nych źródeł — od istniejących rozmaitych modeli biznesowych do wywiadów i konsultacji z per­ sonelem posiadającym wymaganą wiedzę w określonych dziedzinach biznesu. Proces modelowania może mieć zatem różną strukturę. Podobnie jak w przypadku analizy zorientowanej na usługi, tak i tym razem opisywane kroki pomyślane są jako pewien punkt odniesienia dla własnego pro­ cesu modelowania, specyficznego dla konwencji i procedur istniejących w przedsiębiorstwie.

12.1.1. „Usługi" a „kandydatury na usługi" N a początek m usim y wyjaśnić ważną koncepcję — kandydaturę. Podstawowym celem analizy zorientowanej na usługi jest próba zdefiniowania poszczegól­ nych usług na poziomie logicznym, w charakterze wstępu do ich projektowania i konstruowania w dalszych fazach. M usimy sobie uświadomić, że na etapie analizy jesteśmy jeszcze daleko od im ­ plementowania projektu: na razie dokonujem y tylko wstępnej separacji logiki — separacji wyko­ rzystywanej jako podstawa do fazy projektowania zorientowanego na usługi. Innymi słowy, pro­ duktem naszych działań są jedynie abstrakcyjne kandydatury, które ostatecznie mogą, lecz wcale nie muszą stać się przedm iotem konkretnego projektowania. To na pozór banalne spostrzeżenie jest jednak istotne z podstawowej przyczyny: wspomniane kandydatury, będące tworami wyidealizowanymi, w momencie wejścia w fazę projektowania skon­ frontowane zostają z rzeczywistością technicznej architektury, w której mają rezydować, z jej wy­ maganiami i ograniczeniami. I konieczność uwzględnienia tychże wymagań i ograniczeń powodować może, iż usługa będąca przedm iotem projektowania różnić się będzie znacząco od kandydatury stanowiącej jej pierwowzór. I dlatego — powtórzmy to — nie tworzymy na razie usług, lecz jedynie kandydatury na usługi (service candidates). Nie tworzymy również operacji usług, lecz jedynie kandydatury na operacje (service operation candidates). Kandydatury te stanowią końcowy efekt procesu zwanego m ode­ lowaniem usług (service modeling).

1 2 .1 . M O D E L O W A N IE USŁUG KROK PO KROKU

351

12.1.2. Proces Proponow any w tym miejscu proces modelowania usług składa się z maksymalnie dwunastu kro­ ków, przedstawionych schematycznie na rysunku 12.1.

Rysunek 12.1. Proces modelowania usług

Krok 1.: dekompozycja procesu biznesowego Tytułowa dekompozycja to rozkład udokumentowanego procesu biznesowego na serię kroków. Rozkład ten powinien mieć charakter drobnoziarnisty: logika przepływu pracy w procesie powinna zostać podzielona na kroki jak najbardziej elementarne — ich granulacja powinna być zdecydo­ wanie drobniejsza od tej, na poziomie której sporządzono dokumentację tego procesu. W przed­ ostatnim podrozdziale, poświęconym klasyfikacji usług, wprowadzimy kilka nowych term inów pom ocnych w rozróżnianiu usług pod kątem zakresu enkapsulowanej przez nie logiki. ANALIZA PRZYPADKU

W firmie RailCo zakres analizy zorientowanej obiektowo obejmuje dwa procesy opisane w punk­ cie „Modele zarządzania procesami biznesowymi (BPM)”, w rozdziale 11. Proces wystawiania faktury zdekomponowany został na ciąg następujących kroków (patrz rysunek 12.2). • Sporządzenie faktury elektronicznej. • Zapisanie faktury elektronicznej. • W yeksportowanie pliku faktury do folderu sieciowego.

352

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Rysunek 12.2. Dekompozycja Procesu wystawiania faktury w firmie RailCo

Periodyczne sprawdzanie zawartości folderu sieciowego na obecność nowej faktury. Pobranie pliku faktury z folderu sieciowego. Skonwertowanie zawartości pobranego pliku na dokum ent w formacie XML. Zweryfikowanie poprawności dokum entu faktury; negatywny wynik weryfikacji powoduje zakończenie całego procesu. Sprawdzenie potrzeby pobrania m etadanych z systemu B2B firmy TLS. W miarę potrzeb pobranie wspomnianych metadanych i zweryfikowanie ich wersji: jeśli wersja ta uległa zmianie w porównaniu z ostatnim ich pobraniem, należy zakończyć cały proces.

1 2 .1 . M O D E L O W A N IE USŁUG KROK PO KROKU

353

Dekompozycja Procesu realizacji zam ówienia przedstawia się następująco (patrz ry­ sunek 12.3). • Odebranie dokum entu zamówienia. • Zweryfikowanie poprawności dokum entu zamówienia. • Jeśli dokum ent zamówienia okaże się niepoprawny, należy wysłać powiadomienie o jego odrzuceniu i zakończyć proces. • Skonwertowanie dokum entu zamówienia z form atu XML na form at natywny dla systemu finansowo-księgowego. • Zaimportowanie skonwertowanego dokum entu do systemu finansowo-księgowego. • Umieszczenie zaimportowanego dokum entu w kolejce dokum entów oczekujących na przetworzenie przez pracownika księgowości.

Rysunek 12.3. Dekompozycja Procesu realizacji zamówienia w firmie RailCo

354

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Krok 2.: odfiltrowanie kroków, które nie kwalifikują się do enkapsulowania przez usługę Niektóre z kroków stanowiących wynik dekompozycji procesu biznesowego zdecydowanie oka­ zują się pozostawać poza zakresem logiki przeznaczonej do enkapsulowania przez kandydaturę na usługę. Do takich kroków należą między innymi te, które realizowane są m anualnie i nie powinny zo­ stać zautomatyzowane; drugą grupę stanowią te kroki realizowane przez tradycyjny system finan­ sowo-księgowy, które nie m ogą lub nie pow inny być enkapsulowane w ram ach wspomnianej kandydatury (identyfikowanie tej drugiej grupy jest częścią kroku nr 2 analizy zorientowanej na usługi, opisanej w punkcie „Krok nr 2: identyfikacja istniejących systemów autom atyzacji”, w rozdziale 11.). Eliminując wspomniane kroki, otrzymujemy scenariusz adekwatny do procesu modelowania usług. Ponieważ jednak modelowanie prowadzone jest w dużej mierze m etodą „prób i błędów”, eliminacja ta nie jest prawdopodobnie definitywna i kroki będące jej rezultatem należy udoku­ mentować na specjalnej liście, która być może ulegnie weryfikacji w procesie projektowania.

UWAGA Równolegle z wyodrębnianiem poszczególnych kroków procesu biznesowego warto wstępnie zastanowić się nad możliwymi sposobami ich logicznego pogrupowania.

ANALIZA PRZYPADKU

Po przejrzeniu listy kroków scenariuszy obu procesów RailCo zdecydowano, że z listy tej usunięte zostaną kroki niekwalifikujące się jako elementy przyszłego rozwiązania zoriento­ wanego na usługi. Wykreślamy je więc, opatrując krótkim wyjaśnieniem przyczyny wykre­ ślenia; kom entujem y także krótko pozycje pozostawione na liście. Po weryfikacji dekompozycja Procesu wystawiania faktury przyjmuje postać następującą. • Sporządzenie faktury elektronicznej. (Czynność m anualna, wykonywana przez pracownika księgowości). • Zapisanie faktury elektronicznej. (Czynność m anualna, wykonywana przez pracownika księgowości). • W yeksportowanie pliku faktury do folderu sieciowego. (Obecnie specyficzne rozszerzenie tradycyjnego systemu, w przyszłości być może część kandydatury na usługę). • Periodyczne sprawdzanie zawartości folderu sieciowego na obecność nowej faktury. (Obecnie wykonywane przez specyficzny kom ponent, w przyszłości być może część kandydatury na usługę). • Pobranie pliku faktury z folderu sieciowego. (Podobnie jak poprzedni krok). • Skonwertowanie zawartości pobranego pliku na dokum ent w formacie XML. (Podobnie jak poprzedni krok).

1 2 .1 . M O D E L O W A N IE USŁUG KROK PO KROKU

355

• Zweryfikowanie poprawności dokum entu faktury; negatywny wynik weryfikacji powoduje zakończenie całego procesu. (Obecnie wykonywane przez parser stanowiący część usługi W ystawienie faktury, nie przewiduje się zmiany tego stanu rzeczy). • Sprawdzenie potrzeby pobrania m etadanych z systemu B2B firmy TLS. (Obecnie wykonywane przez parser stanowiący część usługi Wystawienie faktury; ze względu na generyczny charakter kandydatura na wieloużywalną operację, być może stanowiącą część osobnej kandydatury na usługę). • W miarę potrzeb pobranie wspomnianych m etadanych i zweryfikowanie ich wersji: jeśli wersja ta uległa zmianie w porów naniu z ostatnim pobraniem, należy zakończyć cały proces. (Podobnie jak poprzedni krok). W Procesie realizacji zamówienia lista kroków pozostaje niezmienna. • Odebranie dokum entu zamówienia. (Aktualnie wykonywane przez usługę Realizacja zamówienia, nie przewiduje się zmiany tego stanu rzeczy). • Zweryfikowanie poprawności dokum entu zamówienia. (Podobnie jak poprzedni krok). • Jeśli dokum ent zamówienia okaże się niepoprawny, należy wysłać powiadomienie o jego odrzuceniu i zakończyć proces. (Podobnie jak poprzedni krok). • Skonwertowanie dokum entu zamówienia z form atu XML na form at natywny dla systemu finansowo-księgowego. (Obecnie wykonywane przez specyficzny kom ponent, w przyszłości być może część kandydatury na usługę). • Zaimportowanie skonwertowanego dokum entu do systemu finansowo-księgowego. (Obecnie specyficzne rozszerzenie tradycyjnego systemu, w przyszłości być może część kandydatury na generyczną usługę). • Umieszczenie zaimportowanego dokum entu w kolejce dokum entów oczekujących na przetworzenie przez pracownika księgowości. (Podobnie jak poprzedni krok). Rezultatem przeprowadzonego filtrowania kroków scenariuszy jest więc usunięcie dwóch kroków Procesu wystawiania faktury i pozostawienie niezmienionego scenariusza Procesu realizacji zamówienia.

Krok 3.: zidentyfikowanie kandydatur na usługi agnostyczne Wykorzystując jako punkt startowy dowolny model przedsiębiorstwa będący rezultatem analizy zstępującej (którą opisywaliśmy szczegółowo w rozdziale 10.), identyfikujemy (lub tworzymy) zbiór logicznych kontekstów, agnostycznych w stosunku do procesu biznesowego, lecz wciąż mających związek z krokami procesu biznesowego zdefiniowanymi w krokach 1. i 2. Każdy ze wspomnia­ nych kontekstów reprezentuje kandydaturę na agnostyczną usługę; identyfikując i grupując kroki mające związek z danym kontekstem, otrzymujemy zbiór potencjalnych kandydatur na operacje tej usługi. Jeśli celem analizy jest zdefiniowanie pojedynczej usługi agnostycznej, należy zidentyfikować i pogrupować wszystkie akcje wydające się mieć związek z kontekstem tejże usługi. Następnie, przeglądając model usług przedsiębiorstwa lub analogiczną dokumentację inwentaryzacji usług, należy wyszukać wszystkie usługi agnostyczne mające związek z pozostałymi akcjami.

356

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Nie trzeba się przy tym zbytnio przejmować liczebnością kroków w każdej z grup: zasadni­ czym celem tego ćwiczenia jest ustanowienie początkowego zbioru kontekstów.

UWAGA Zgodnie z konwencją nazewniczą, którą wyjaśnialiśmy w punkcie 11.3.1, dalej w tym rozdziale opisywać będziemy operacje usług (i kandydatury na operacje) w formie imperatywów czasownikowych, zachowując rzeczownikową formę nazw samych usług (i kandydatur na usługi).

ANALIZA PRZYPADKU

Analizując kontekst każdego z kroków wyodrębnionych w ramach obu procesów biznesowych RailCo, pogrupowaliśmy te kroki następująco. • Kandydatura na usługę Tradycyjny system • W yeksportuj plik faktury do folderu sieciowego. • Zaim portuj skonwertowany dokum ent do systemu finansowo-księgowego. • Umieść zaimportowany dokum ent w kolejce dokum entów oczekujących na przetworzenie przez pracownika księgowości. • Kandydatura na usługę Kontrola metadanych • Sprawdź potrzebę pobrania m etadanych z systemu B2B firmy TLS. • Jeśli trzeba, pobierz m etadane i zweryfikuj ich aktualność; gdy okażą się nieaktualne, zakończ proces. Na rysunku 12.4.1 ukazano inny widok znajomych już kandydatur operacji — w pogru­ powaniu ich według kontekstów reprezentujących kandydatury na usługi.

Rysunek 12.4.1. Pierwsza wersja zbioru kandydatur na agnostyczne usługi

1 2 .1 . M O D E L O W A N IE USŁUG KROK PO KROKU

357

Krok 4.: zidentyfikowanie logiki specyficznej dla procesu A k c je , k tó re p o z o s ta ły jeszcze n ie u w z g lę d n io n e p o w y k o n a n iu k r o k u 3 ., p ra w d o p o d o b n ie r e p re ­ z e n tu ją lo g ik ę s p e c y fic z n ą d la k o n k r e tn y c h z a d a ń lu b p ro c e s ó w b iz n e s o w y c h : s p e c y fic z n e d la p ro cesu re g u ły b izn e s o w e , lo g ik ę w a r u n k o w ą , lo g ik ę o b s łu g i s y tu a c ji w y ją tk o w y c h c zy te ż lo g ik ę w y z n a c za ją c ą k o le jn o ś ć w y k o n y w a n ia a k c ji w r a m a c h s e k w e n c ji. T a fo r m a lo g ik i p ro c e s u n ie k o n ie c z n ie m u s i b y ć w y ra ź n ie o d z w ie rc ie d lo n a w op is ie k ro k u . P rz y k ła d o w o n ie k tó r e k r o k i s ta n o w ią p o łą c z e n ie w a r u n k u i a k c ji („ je ż e li . . . , to w y k o n a j . . . ”) — w t a k im p rz y p a d k u n a le ż y s k o n c e n tro w a ć się n a a k c ji. Z a le ż n ie o d z b o ru w y o d rę b n io n y c h w a rs tw usłu g , lo g ik a tego ty p u tw o r z y z w y k le k o n te k s t d e fin ic ji p ro c esu b izn e s o w e g o ja k o część ś ro d o w is k a o rk ie s tra c ji b ą d ź z a d a n io w y c h u s łu g b iz n e ­ s o w y c h (je d n e j lu b k ilk u ) . W ty m d r u g im p r z y p a d k u n a le ż y z a d b a ć o s ta ra n n e z d e fin io w a n ie k o n te k s tu k a ż d e j z u słu g , m ię d z y in n y m i p o p rz e z n a d a n ie im n a z w in tu ic y jn ie o d z w ie rc ie d la ją ­ cy ch zakres w y k o n y w a n y c h z a d a ń . N a jc z ę ś c ie j n a ty m e ta p ie w y o d rę b n io n a zo staje p o je d y n c z a u słu g a z a d a n io w a , k tó r a n a s tę p n ie o b s a d z o n a zo staje w r o li k o n tr o le r a k o m p o z y c ji. W y ją t k ie m o d o p isa n e j r e g u ły je s t sy tu a c ja , g d y d e fin iu je m y ty lk o je d n ą usługę agn o s ty c zn ą . W c h o d z ą c e w je j zakres p ro c e s y n a d rz ę d n e im p le m e n to w a n e są z w y k le w p o s ta c i k o n k re tn y c h o p e ra c ji (lu b ic h c ią g ó w ) te j u s łu g i. N a le ż y z a te m u w a ż n ie p rz e a n a liz o w a ć a kcje, k tó re jeszcze p o ­ z o s ta ły p o z a k o ń c z e n iu k r o k u 3., p o d k ą te m ic h z w ią z k u z k o n te k s te m w s p o m n ia n e j u s łu g i; e w i­ d e n tn y b r a k ta k ie g o z w ią z k u w p rz y p a d k u k tó re jś (je d n e j lu b w ię c e j) a k c ji o z n a c z a b ą d ź to z a p o ­ trz e b o w a n ie n a n o w ą us łu g ę , b ą d ź te ż k o n ie c zn o ś ć z r e d u k o w a n ia o ry g in a ln e g o z a k re s u a n a liz y . M o ż e się r ó w n ie ż i ta k z d a rz y ć , że n ie z a le ż n ie o d sp o s o b u p r z y p o r z ą d k o w y w a n ia a k c ji p o ­ s z c ze g ó ln y m k a n d y d a tu r o m n a u s łu g i, część lo g ik i p r z e p ły w u p ra c y b ę d z ie m u s ia ła p o zo s ta ć n ie u w z g lę d n io n a . P o w ó d tego je s t o c zy w is ty : n ie w s zy s tk ie k r o k i p ro c e s u k w a lifik u ją się do p rz e ­ k s z ta łc e n ia n a o p e ra c je usług.

ANALIZA PRZYPADKU N ie u w z g lę d n io n e jeszcze k r o k i s c e n a riu s z y o b u p ro c e s ó w w R a ilC o p o g ru p o w a n e z o s ta ły w n a s tę p u ją c y sp o só b , tw o rz ą c ty m s a m y m k a n d y d a tu r y n a d w ie u s łu g i z a d a n io w e . •

Przetwarzanie faktury •

S p ra w d z a j o k re s o w o za w a rto ś ć fo ld e r u sie c io w e g o n a o becno ść n o w e j fa k tu ry .

•

P o b ie rz p lik fa k tu r y z fo ld e ru siecio w eg o .

•

S k o n w e rtu j z a w a rto ś ć p o b ra n e g o p lik u n a d o k u m e n t w fo rm a c ie X M L .

•

Z w e r y fik u j p o p ra w n o ś ć d o k u m e n tu fa k tu ry ; g d y o k a że się n ie p o p ra w n y , z a k o ń c z proces.

•

Przetwarzanie zamówienia •

O d b ie rz d o k u m e n t z a m ó w ie n ia .

•

Z w e r y fik u j p o p ra w n o ś ć d o k u m e n tu z a m ó w ie n ia .

•

Jeśli d o k u m e n t z a m ó w ie n ia o k a że się n ie p o p ra w n y , w y ś lij p o w ia d o m ie n ie o jeg o o d rz u c e n iu i z a k o ń c z proces.

•

S k o n w e rtu j d o k u m e n t z a m ó w ie n ia z fo r m a tu X M L n a fo r m a t n a ty w n y d la s y stem u fin a n s o w o -k s ię g o w e g o .

358

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Rezultat opisanego grupowania przedstawiono na rysunku 12.4.2.

Rysunek 12.4.2. Pierwsza wersja zbioru kandydatur na zadaniowe usługi biznesowe

Ponadto następujące elementy logiki — warunkowe i odpowiedzialne za sekwencjonowanie — umieszczone zostały na odrębnych listach związanych z potencjalnymi kandydaturam i na usługi. • Jeśli dokum ent faktury jest poprawny, przejdź do kroku sprawdzania metadanych. • Jeśli dokum ent faktury jest niepoprawny, zakończ proces. • Jeśli upłynął okres sprawdzenia metadanych, wykonaj krok weryfikacji metadanych. • Jeśli nie upłynął jeszcze okres sprawdzenia metadanych, pom iń krok weryfikacji metadanych. • Jeśli dokum ent zamówienia jest poprawny, wykonaj krok jego transformacji. • Jeśli dokum ent zamówienia jest nie poprawny, zakończ proces. Ten typ logiki biznesowej nie reprezentuje kandydatur na operacje usług, lecz powinien zostać uwzględniony w postaci odpowiednich usług zadaniowych.

Krok 5.: uwzględnienie zasad zorientowania na usługi Dotychczas zajmowaliśmy się grupowaniem kroków wyodrębnionych jako elementy istniejącego procesu biznesowego. By jednak wyodrębniane kandydatury na usługi rzeczywiście okazały się godne m iana prowadzących w stronę SOA, m usim y bacznie przyjrzeć się każdej z kandydatur na operacje pod kątem zasad zorientowania na usługi. Na etapie modelowania usług szczególne znaczenie mają dwie spośród wspomnianych zasad — wieloużywalność i autonom ia (pozostałe zasady okażą się istotne na etapie projektow ania zorientowanego na usługi, na którym to etapie obie wymienione zasady zachowują w pełni swe znaczenie). Wskazane jest zatem, by kandydatury na biznesowe usługi podmiotowe i usługi aplikacyjne wyposażone zostały w dodatkowe operacje ułatwiające osiągnięcie przyszłej wieloużywalności, choć niekoniecznie wymagane przez bieżącą postać procesu biznesowego. W przypadku usług biznesowych celowa może być fachowa pom oc analityków biznesowych.

1 2 .1 . M O D E L O W A N IE USŁUG KROK PO KROKU

359

UWAGA Wskazane jest specjalne wyróżnienie wspomnianych nowych operacji, na przykład za pomocą specyficznych nazw, by odróżniały się od operacji wynikających z aktualnych wymagań procesu biznesowego. Rozróżnienie to okaże się istotne w przypadku ewentualnego „skalowania w dół" kandydatur na usługi w fazie projektowania usług.

Co się tyczy autonomii usług, wskazane jest skonfrontowanie wyodrębnionych kandydatur na usłu­ gi z realiami środowiska wykonawczego szczególnie wtedy, gdy przewidywane jest tworzenie usług enkapsulujących logikę „spadkowych” systemów (czemu głównie poświęcony był krok nr 2.). I choć na etapie modelowania koncentrujemy się głównie na logicznych definicjach usług, korzystne będzie uświadomienie sobie zawczasu ograniczeń i wymagań związanych z tradycyjnymi technologiami.

UWAGA Kwestia wykrywalności wyodrębnianych usług także może być rozważana na etapie modelowania. Wykrywalność, choć niemająca bezpośredniego wpływu na strukturę wyodrębnianych kandydatur na usługi, ma jednak zwią­ zek z semantyką enkapsulowanej logiki. Warto więc wykorzystać dostępność analityków biznesowych (zaangażo­ wanych w procesy analizy i modelowania) do nadania właściwego kształtu także opisom planowanych usług.

ANALIZA PRZYPADKU

Przeglądając wyodrębnione kandydatury na operacje, odnajdujemy szereg okazji do zweryfi­ kowania ich zestawu. W ram ach kandydatury na usługę Tradycyjny system akcja Umieść zaim portow any do­ k u m e n t w kolejce dokum entów oczekujących na przetw orzenie p rze z pracow nika księgowości

wykonywana jest tylko w przypadku dotarcia dokum entu do systemu finansowo-księgowego, czyli jest bezpośrednio zależna od akcji Z a im p o rtu j sk o n w erto w a n y d o k u m e n t do system u finansow o-księgow ego . Decydujemy się więc na połączenie dwóch kandydatur na operacje w jedną kandydaturę. Akcja W yeksportuj plik fa k tu ry do folderu sieciowego wykonywana jest automatycznie przez makro dodane do tradycyjnego systemu finansowo-księgowego, nie jest więc pożądanym kan­ dydatem na bycie częścią usługi. Traktujemy ją więc jako odosobnioną kandydaturę na ope­ rację, którą zamierzamy uczynić bardziej wieloużywalną poprzez wyposażenie ją w możliwość eksportowania dokum entów różnego typu. Ostatecznie więc lista kandydatur na operacje usługi Tradycyjny system redukuje się do dwóch następujących elementów: = W yeksportuj dokum ent do folderu sieciowego. • Zaim portuj dokum ent i wstaw go do kolejki. W ram ach kandydatury na usługę Przetwarzanie faktury znajdujemy szereg okazji do udoskonalenia listy kandydatur na jej operacje. Zauważmy od razu, że dedykowaną akcję Spraw dzaj okresowo zaw artość folderu sieciowego na obecność nowej fa k tu r y m ożna uczynić bardziej generyczną, czyli dokonującą okresowego przepytywania dowolnego wskazanego

360

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

folderu na okoliczność pojawiania się w nim nowych dokum entów różnych typów. Co wię­ cej, każdorazowe pojawienie się nowego dokum entu jest rodzajem zdarzenia; stąd pomysł, by w spom niana operacja stałą się częścią usługi-publikatora powiadamiającej subskrybentów 0 zdarzeniach tego rodzaju. Kolejne usprawnienie jest wynikiem ścisłej zależności między akcjami Pobierz plik faktury z folderu sieciowego, Skonwertuj zawartość pobranego pliku na dokum ent w form acie XM L 1 Zweryfikuj poprawność dokum entu faktury. Łączymy je w jedną akcję o nazwie Pobierz i skonwertuj dokum ent faktury. Nie wyszczególniamy aspektu walidacji dokum entu, ponie­ waż dokumentowi XML automatycznie przyporządkowywany jest odpowiedni schemat, więc walidacja ta staje się wewnętrzną sprawą procesu konwersji. Efektem przeprowadzonej analizy jest między innymi pojawienie się nowego kontekstu — czyli nowej kandydatury na usługę Obserwowanie folderu — reprezentującego następu­ jącą generyczną akcję powiadamiania. • Skanuj wskazany folder na okoliczność pojawiania się w nim nowych dokumentów. • W przypadku pojawienia się nowego dokum entu, w związku z którym istnieją zarejestrowani subskrybenci, wyślij powiadomienia do tych subskrybentów. Zrewidowana kandydatura na usługę Przetwarzanie faktury pozostaje zatem z jedną tylko operacją: • Pobierz i skonwertuj dokum ent faktury. Przejdźmy teraz do akcji związanych z przetwarzaniem zamówienia. Mimo iż explicite wyartykułowana, akcja Odbierz dokum ent zamówienia nie jest odpowiednią kandydaturą na operację: odebranie k om unikatu niosącego dokum ent zam ów ienia jest n aturalną częścią działalności usługi, nie m a więc powodu wyodrębniać tego odebrania jako osobnej operacji. Skreślamy więc tę kandydaturę z naszej listy. Kolejny rzut oka na listę akcji pozwala odkryć bezpośrednią zależność między akcjami Jeśli dokum ent zamówienia okaże się niepoprawny, wyślij powiadomienie o jego odrzuceniu i zakończ proces i Zweryfikuj poprawność dokum entu zamówienia. Łączymy je zatem w jedną akcję o nazw ie Z w eryfikuj popraw ność doku m en tu zam ów ienia i wyślij pow iadom ienie w p rzyp a d ku jego odrzucenia. Kolejna zależność to podobieństwo akcji Skonwertuj dokument zamówienia z form atu XM L na form at natywny dla systemu finansowo-księgowego oraz Pobierz i skonwertuj dokumentfaktury: obie wykonują konwersję formatu dokumentu księgowego. Podobieństwo to predestynuje obie akcje do wejścia w skład kandydatury na nową usługę — Konwersja dokumentów księgowych — wykonującą generyczną transformację formatu i obejmującą dwie następujące operacje: • Konwertuj dokum ent z natywnego form atu na form at XML, • Konwertuj dokum ent z form atu XML na format natywny. I tym sposobem kandydatura na usługę Przetwarzanie zamówienia pozostaje z jedną tylko operacją: • Zweryfikuj poprawność dokum entu zamówienia i wyślij powiadomienie w przypadku jego odrzucenia.

1 2 .1 . M O D E L O W A N IE USŁUG KROK PO KROKU

361

Ostatnia grupa operacji związana jest z kontrolą metadanych. Co prawda, są one zdefiniowane w sposób względnie zgodny z naszymi zamiarami; ponieważ jednak zdecydowaliśmy się wyabstra­ hować je jako kandydatury na generyczną usługę, musimy nieco skonkretyzować ich opis, a także — to ważne — dodać do wspomnianej usługi funkcję powiadamiania. Ostatecznie więc kandy­ datura na usługę Kontrola metadanych zamyka się w zestawie dwóch następujących operacji. • Sprawdź, czy nadszedł czas na weryfikację metadanych; jeśli tak, wykonaj tę weryfikację. • W przypadku negatywnego wyniku weryfikacji wyślij stosowne powiadomienie. Reasumując — znacząco zrewidowaliśmy oryginalną logikę procesu biznesowego, otrzy­ mując w efekcie nowe kandydatury na usługi, realizujące abstrahowanie logiki, zgodnie z za­ sadami zorientowania na usługi. Nowy stan pogrupowania kandydatur na operacje w ramach kandydatur na usługi przedstawiamy na rysunku 12.5.

Rysunek 12.5. Zrewidowany zbiór kandydatur na usługi RailCo

362

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Krok 6.: zidentyfikowanie prawdopodobnych kompozycji usług Po zarysowaniu granic poszczególnych usług powinniśmy zastanowić się nad najbardziej praw­ dopodobnymi scenariuszami realizowanymi w granicach danego procesu biznesowego. W danym scenariuszu należy wzorować się na istniejących krokach, nie przejmując się zbytnio konkretnymi typami danych przetwarzanych przez przyszłe usługi i przekazywanych między nimi. Najważniej­ szy jest w tym momencie przepływ akcji między usługami i między operacjami. Nie m ożna jed­ nak zapom inać o uwzględnieniu w każdym ze scenariuszy logiki związanej z obsługą możliwych sytuacji wyjątkowych. Identyfikując potencjalne kompozycje, możemy jednocześnie ocenić trafność pogrupowania operacji w ram ach kandydatur na usługi, a jednocześnie dokonać rozpoznania w zakresie poten­ cjalnych relacji między warstwami usług. Może się też okazać (i często faktycznie się okazuje), że zestaw zdefiniowanych kroków (i kandydatur na operacje) nie jest kompletny, bo jakiś fragment logiki przepływu pracy nie został uwzględniony. I często pojawiają się wówczas nie tylko nowe kandydatury na operacje, ale również zapotrzebowanie na nowe usługi. Tak czy inaczej, krok ten stanowi doskonałą okazję do zrewidowania kształtu wyodrębnio­ nych kandydatur na usługi. ANALIZA PRZYPADKU

W kroku 4. zidentyfikowaliśmy szereg kandydatur na usługi, form ujących wstępną postać warstw usług aplikacyjnych i usług biznesowych. Mowa o następujących usługach: • Tradycyjny system, • Obserwowanie folderu, • Konwersja dokumentów księgowych, • Kontrola metadanych. Każda z wymienionych kandydatur reprezentuje generyczną, wieloużywalną i agnostyczną biznesowo logikę. Innym i słowy, są to wybitne kandydatury na usługi aplikacyjne, ustana­ wiające wstępną postać warstwy usług aplikacyjnych. A co z kandydaturam i na usługi biznesowe? Kandydatura na usługę Przetwarzanie za­ mówienia zredukowana została do jednej operacji, za to kandydatura na usługę Przetwarzanie faktury zdematerializowała się całkowicie — wszystkie jej operacje wchłonięte zostały przez inne kandydatury. Nie oznacza to jednak, że obie te usługi są niepotrzebne. Przypom nijm y sobie, że p o d ­ stawową rolą usług zadaniow ych jest rola k ontrolera kom ponującego usługi aplikacyjne w dziele realizacji żądanej logiki biznesowej. Tak więc zarówno Przetwarzanie zamówienia, jak i Przetwarzanie faktury ustanawiają wstępną wersję nadrzędnej warstwy usług bizne­ sowych, dysponując logiką niezbędną do kom ponow ania odnośnych usług aplikacyjnych. Hierarchię tę zilustrow ano na rysunkach 12.6 i 12.7.

1 2 .1 . M O D E L O W A N IE USŁUG KROK PO KROKU

363

Rysunek 12.6. Przykładowa kompozycja usług reprezentująca Proces wystawiania faktury

Warstwa usług biznesowych Warstwa usług aplikacyjnych

Rysunek 12.7. Przykładowa kompozycja usług reprezentująca Proces realizacji zamówienia

Aby jednak skonfrontować scenariusze instancji procesów z potencjalnymi kompozycjami usług, należy posłużyć się diagramami bardziej szczegółowymi niż te z rysunków 12.6 i 12.7: konieczne jest bowiem odwzorowanie relacji między kandydaturam i na usługi na poziomie poszczególnych operacji tych usług.

Krok 7.: analiza wymagań aplikacyjnych Ponieważ dotąd skupialiśmy się na logice procesu biznesowego, wyodrębnianie kandydatury na usługi dotyczyło głównie usług biznesowych. Nadszedł zatem czas na przyjrzenie się każdej z wy­ odrębnionych kandydatur na operacje pod kątem wymagań związanych z jej (domniemaną) fi­ zyczną realizacją, bo być może konieczne okaże się dodanie nowych elementów logiki przetwa­ rzania do warstwy usług aplikacyjnych w jej początkowej postaci.

364

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

W tym celu każda ze zidentyfikowanych już kandydatur na operacje powinna zostać poddana minianalizie, w ram ach której należy odpowiedzieć przede wszystkim na następujące pytania. • Jakie elementy logiki przetwarzania konieczne są do zrealizowania akcji reprezentowanej przez kandydaturę na operację? • Czy wspomniane elementy już istnieją, czy też należy je dopiero skonstruować? • Czy wymagana logika przetwarzania przekracza granice rozwiązań — innymi słowy: czy do realizacji danej akcji wymagany jest udział więcej niż jednego systemu? Rezultatem przeanalizowania pod tym kątem wszystkich zidentyfikowanych akcji jest lista dotycząca wymagań w zakresie przetwarzania, stanowiąca materiał dla kroku 8. modelowania. Ten i następne kroki modelowania są szczególnie istotne w przypadku dogłębnej analizy dużych, skomplikowanych procesów biznesowych. Zauważmy, że informacja, jaką zebraliśmy w kroku 2. procesu analizy zorientowanej na usługi, będzie zdecydowanie pom ocna w tym kroku. ANALIZA PRZYPADKU Nasz proces biznesowy nie zasługuje w żaden sposób na miano złożonego, a my zidentyfiko­ waliśmy już wszystkie kandydatury na usługi aplikacyjne, reprezentujące wstępną wersję wymaganej logiki przetwarzania. N astępne kroki nie m ają więc już związku z firm ą RailCo i nie będą ilustrowane analizami przypadków.

Krok 8.: zidentyfikowanie kandydatur na operacje usług Krok 7. stworzył okazję do zidentyfikowania nowych kroków składających się na proces bizneso­ wy — kroków przekładających się na kandydatury operacji dla usług aplikacyjnych. W tym celu każde wymaganie związane z logiką przetwarzania należy przełożyć na jeden lub kilka kroków procesu. W ażne jest przy tym zachowanie odpowiedniej koncepcji nazewniczej. Z jednej strony, nazwa usługi czy operacji pow inna intuicyjnie odzwierciedlać wykonywaną funkcję, z drugiej jednak, bardzo łatwo zawrzeć wówczas w poszczególnych nazwach elementy procesów biznesowych, na rzecz których działać m ają przyszłe usługi aplikacyjne — a tego właśnie chcielibyśmy uniknąć, wszak próbujem y definiować generyczne i autonomiczne usługi aplikacyjne, nieprzywiązane bez­ pośrednio do procesów biznesowych, których realizacji mają służyć. Krok 9.: zdefiniowanie kandydatur na usługi aplikacyjne W yłonione w poprzednim kroku kandydatury na operacje należy teraz pogrupować w celu wyod­ rębnienia kandydatur na nowe usługi aplikacyjne. W przeciwieństwie jednak do usług bizneso­ wych, usługi aplikacyjne nie mają wyraźnego związku z kontekstem, predefiniowanym przez ist­ niejące modele i procesy biznesowe; są one raczej ukierunkowane na przetwarzanie (processingcentric) i to przetwarzanie jest ich zasadniczym kontekstem. To oznacza, że podstawą wspomnianego grupowania powinno być poszukiwanie logicznych relacji i podobieństw między wyodrębnionymi kandydaturam i na operacje. Takie podobieństwo może na przykład wynikać ze związku z tym samym tradycyjnym systemem lub tymi samymi jego komponentami, czy też (co częściej spotykane) ze zbliżonej natury enkapsulowanej funkcjonalności.

1 2 .1 . M O D E L O W A N IE USŁUG KROK PO KROKU

365

Częścią tego kroku pow inna być inwentaryzacja zestawu zidentyfikowanych kandydatur na usługi z oczywistego powodu: należy upewnić się, że w zestawie tym nie znajdują się już usługi aplikacyjne mające związek z kontekstem przetwarzania nowo proponowanych kandydatur na operacje. Krok 10.: ponowne uwzględnienie zasad zorientowania na usługi To w zasadzie powtórzenie kroku 5., tym razem jednak w odniesieniu do kandydatur na usługi aplikacyjne zdefiniowanych w trakcie kroków 7., 8. i 9. Wieloużywalność i autonom ia są w odnie­ sieniu do usług aplikacyjnych nie mniej ważne niż w odniesieniu do usług biznesowych. I tak autonom ia odrywa ogrom ną rolę w zdeterm inow aniu funkcjonalnego zakresu każdej z kandydatur na operacje usług aplikacyjnych (co z grubsza przekłada się na stopień granulacji tychże kandydatur). Gdy zostanie już rozpoznany kontekst przetwarzania każdej ze zdefiniowanych kandydatur na operacje, może się okazać, że alternatywą dla definiowania nowych operacji jest rewizja już zdefi­ niowanych w celu uczynienia ich bardziej ogólnymi (generycznymi). W końcu usługa obejmująca wysoce generyczne operacje sama zwykle jest wysoce generyczna. Gdy kandydatury na usługi staną się przedm iotem następnego etapu — projektowania zo­ rientowanego na usługi — może pojawić się jeszcze wiele interesujących zależności tego rodzaju. Na razie ograniczmy się do stwierdzenia, że zidentyfikowane kandydatury (na operacje i usługi) ustanawiają początkową postać warstwy usług aplikacyjnych. Krok 11.: zrewidowanie kandydatur na kompozycje W tym kroku powracamy do scenariuszy zdefiniowanych w kroku 6., by ponownie je przeanali­ zować i zmodyfikować, tym razem również z udziałem nowo wyodrębnionych kandydatur na usługi i ich operacje. W rezultacie powinniśm y otrzymać złożone nieraz aktywności, powołujące do życia poszerzone kompozycje usług. Musimy przy tym upewnić się, że sprawujemy całkowitą kontrolę nad tym, w jaki sposób zidentyfikowane kandydatury na usługi biznesowe mapowane są w zbiór zdefiniowanych kandydatur na usługi aplikacyjne. Krok 12.: zrewidowanie grupowania kandydatur na operacje Mapowanie scenariuszy będące treścią kroku 11. jest jednocześnie sprawdzianem trafności wyod­ rębnienia kandydatur na operacje i ich grupowania w kandydatury na usługi — sprawdzianem nierzadko skutkującym zrewidowaniem wspomnianego grupowania, jak i być może zmodyfiko­ waniem definicji samych operacji. ANALIZA PRZYPADKU

Nasza analiza zorientow ana na usługi doprow adziła do wyjątkowo użytecznego rezultatu, który spożytkujemy w ram ach nadchodzącego procesu projektowania zorientowanego na usługi. Ćwiczenie z modelowania było pierwszym podejściem do realizacji celów, jakie po­ stawiła sobie oryginalnie RailCo na swej drodze do SOA. Celem tym jest zbudowanie środo­ wiska złożonego z usług, których logika przetwarzania nie będzie specyficzna dla konkretnego klienta, dzięki czemu będzie możliwe pozyskiwanie nowych partnerów biznesowych bez każ­ dorazowego inwestowania w tworzenie specyficznych usług.

366

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Duży stopień w yabstrahow ania logiki aplikacyjnej zaowocował pow staniem warstwy w pełni wieloużywalnych usług aplikacyjnych. Te (planowane) usługi zdolne są do realizacji wielu żądań ze strony usług biznesowych, między innymi przetwarzania dokum entów faktur i dokum entów zamówień związanych z klientami. Jako usługi agnostyczne biznesowo mogą być również wykorzystywane przez usługi biznesowe innych typów. W RailCo uczyniono tym samym pierwszy krok w kierunku tworzenia inwentarza wielo­ używalnych usług, przydatnych na potrzeby rozmaitych przyszłych rozwiązań. Przecież wszystko zaczęło się od oddzielnych procesów, nieposiadających wspólnych elementów logiki, a obecnie zbiór wyabstrahowanych operacji usług stoi do dyspozycji tych i potencjalnie wielu innych procesów.

UWAGA Przedstawiony opis odzwierciedla tylko jedną iterację procesu modelowania usług. W ramach następnych iteracji pierwotny zestaw zdefiniowanych kandydatur będzie prawdopodobnie wiele razy udoskonalany. Czytelnikom zainteresowanym dalszymi informacjami na temat iteracyjnego modelowania usług polecamy stronę w w w .soam ethodology.com .

PODSUMOW ANIE •

Modelowanie usług jest zasadniczo procesem zbierania i organizowania informacji mających źródło w modelach biznesowych.

1 2 .2 . W y ty c z n e i w s k a z ó w k i d o ty c zą c e m o d e lo w a n ia usług M odelowanie usług to proces złożony, obejmujący wiele trudnych wyborów i kom prom isów. Prezentowane poniżej wytyczne mają w zamierzeniu dopomóc w osiągnięciu właściwych proporcji między adekwatnym odwzorowaniem logiki biznesowej a zgodnością z zasadami zorientowania na usługi w zestawie wyodrębnianych kandydatur na usługi. Niektóre ze wspomnianych wytycz­ nych odnoszą się tylko do jednego typu usług — biznesowych albo aplikacyjnych — co każdora­ zowo zaznaczone będzie w tytule odnośnego punktu.

12.2.1. Rozważanie potencjalnej wieloużywalności międzyprocesowej enkapsulowanej logiki (kandydatury na biznesowe usługi zadaniowe) Identyfikowanie potencjalnych cech wieloużywalności jest niezmiernie ważnym elementem gru­ powania kandydatur na operacje w kandydatury na usługi, bo przyczynia się do lepszego wyko­ rzystywania istniejących jednostek logiki biznesowej i tworzenia m odularnych modeli bizneso­ wych. Oczywiście, wymaga to znajom ości innych procesów biznesow ych przedsiębiorstw a — tych istniejących i tych będących dopiero w opracowywaniu (patrz rysunek 12.8).

1 2 .2 . W YTYC ZN E I W S K A Z Ó W K I DOTYCZĄCE M O D E L O W A N IA USŁUG

367

Rysunek 12.8. Wielokrotne wykorzystanie logiki usługi w różnych procesach biznesowych

W spom nianą identyfikację może wydatnie ułatwić przyjęcie odpowiedniego stopnia granula­ cji modelowanych kandydatur na usługi zadaniowe — im mniejszy zakres logiki enkapsulowanej przez kandydaturę na usługę, tym większa szansa na wielokrotne używanie tej usługi w innych procesach. Oczywiście, nie oznacza to, że usługi „gruboziarniste” nie posiadają cech wieloużywalności: jak później wyjaśnimy, takie usługi mogą być dekomponowane, co dodatkowo wyzwala wieloużywalność m a poziomie jednostek ich dekompozycji.

12.2.2. Rozważanie potencjalnej wieloużywalności wewnątrzprocesowej enkapsulowanej logiki (kandydatury na biznesowe usługi zadaniowe) Możliwości wieloużywania danej usługi istnieć m ogą nie tylko w wielu różnych procesach, lecz również w ram ach jednego procesu. Ogrom ne i skomplikowane przepływy pracy zwykle zawie­ rają wiele powtarzających się kolekcji aktywności. Jeśli ta redundancja jest wyraźna i spójna, a lo­ gika reprezentowana przez te kolekcje wystarczająco niepodzielna, należy rozważyć przekształce­ nie tych kolekcji w kandydatury na usługi (tak jak na rysunku 12.9). Wiele systemów przepływu pracy umożliwia wykonanie tego zadania przy użyciu predefiniowanych, standardowych procesów i podprocesów.

12.2.3. Wykrywanie wewnętrznych uzależnień od procesu (kandydatury na biznesowe usługi zadaniowe) Po wyodrębnieniu ciągu kroków procesu reprezentujących logikę przeznaczoną do enkapsulacji konieczne jest rozpoznanie wszelkich zależności, jakie wiążą tę logikę z bieżącym procesem lub z ustaloną pozycją w tym procesie. Takiej ocenie poddać trzeba każdy z kroków, analizując dokładnie jego parametry lub warto­ ści wejściowe pod kątem ich związku z regułami biznesowymi, punktami decyzyjnymi, formułami, instrukcjami warunkowymi i podobnym i elementami logiki przepływu pracy. Zakres, w jakim dana kandydatura na usługę zależna jest od informacji zewnętrznej, czyli ge­ nerowanej poza granicami procesu biznesowego, decyduje o ograniczeniach tej usługi w zakresie mobilności, wieloużywalności i komponowania.

368

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

12.2.4. Modelowanie wieloużywalności międzyaplikacyjnej (kandydatury na usługi aplikacyjne) Każdej kandydaturze na usługę biznesową nadaw ana jest struktura reprezentująca specyficzną część modelu biznesowego. Kandydatury te są zatem wysoce specjalizowane i starannie modelo­ wane, tak aby zapewnić wierne odwzorowanie dobrze określonej części logiki biznesowej. Dla odmiany, usługi aplikacyjne nie wymagają zazwyczaj modelowania pod kątem zgodności ze specyficznymi wymaganiami biznesowymi. W ręcz przeciwnie: im bardziej generyczna — czyli im mniej uzależniona od wspom nianych wymagań — kandydatura na usługę aplikacyjną, tym bardziej m a szansę stać się wieloużywalna. Projektowanie agnostyczne biznesowo umożliwia spełnienie wielu potencjalnych wymagań w zakresie wieloużywania kandydatur na usługi aplika­ cyjne między granicami poszczególnych rozwiązań. Tak więc kontekst, wokół którego kandydatury na operacje grupowane są w kandydatury na usługi aplikacyjne, jest kompletne neutralny względem konkretnych rozwiązań, na potrzeby któ­ rych usługi te będą ostatecznie używane.

12.2.5. Prognozowanie dalszych wymagań dekompozycyjnych Pouczającym ćwiczeniem dotyczącym części procesu biznesowego wyodrębnionej jako kandy­ datura na usługę jest spekulatywna analiza pod kątem tego, czy i jak część ta mogłaby zostać od­ wzorowana nie w postaci pojedynczej usługi, lecz w postaci kompozycji usług. Innym i słowy, jeśli nawet aktualnie wyodrębnione kandydatury na usługi okazują się zadowalające z perspektywy

1 2 .2 . W YTYC ZN E I W S K A Z Ó W K I DOTYCZĄCE M O D E L O W A N IA USŁUG

369

doraźnych wymagań biznesowych, warto rozważyć potencjalną możliwość podziału logiki enkapsulowanej przez te usługi na usługi bardziej drobnoziarniste. Jeżeli wspom niana dekompozycja istotnie okaże się możliwa, należy zastanowić się nad za­ gadnieniem następnym — jakie jest prawdopodobieństwo tego, że jej przeprowadzenie okaże się rzeczywiście użyteczne. Oprócz rozstrzygnięcia w temacie opłacalności jej wykonania (albo za­ niechania), zyskujemy wówczas wiedzę niezbędną do odpowiedniego zaklasyfikowania kandy­ datury na usługę (co wyjaśniamy dokładniej w podrozdziale „Klasyfikacja logiki modelu usług”, w tym rozdziale).

12.2.6. Identyfikowanie logicznych jednostek pracy w określonych granicach To prosta reiteracja zastosowania zasady autonom ii do w yodrębnianych kandydatur na usługi (i samych usług). Przypom inam y tu tę zasadę, ponieważ stanowi ona złotą regułę modelowania usług. Logika enkapsulowana przez kandydaturę na usługę m usi mieć wyraźnie zdefiniowane granice, czyli musi być zdolna do istnienia jako niepodzielna kolekcja poszczególnych zadań. Elementem autonom ii usługi jest także określony poziom niezależności tej usługi od logiki (biznesowej lub aplikacyjnej) pozostającej poza wspomnianymi granicami. W przypadku zmian w wymaganiach biznesowych usługi cechujące się taką niezależnością łatwiej poddają się ponow ­ nem u modelowaniu. Ponadto niezależność taka sprzyja większej wieloużywalności i komponowalności usługi na poziomie logicznym. Definiowanie wspomnianych granic może być w przypadku usług aplikacyjnych trudniejsze niż w przypadku usług biznesowych, jeżeli granice te muszą uwzględniać skomplikowane trady­ cyjne aplikacje. Szczegóły enkapsulowania logiki takich aplikacji przez usługi aplikacyjne rozwa­ żane są na etapie projektowania zorientowanego na usługi. I może się wówczas okazać, że granice wyznaczone w trakcie projektowania usługi okażą się znacząco różne w porównaniu z tymi, jakie zakreślone zostały przy definiowaniu kandydatury na tę usługę.

12.2.7. Zapobieganie pełzaniu granic W miarę jak definiowane są coraz to nowe usługi i kandydatury na usługi może się zdarzyć, że niektóre z nich powielać będą część (lub całość) logiki biznesowej enkapsulowanej już przez inne. Zjawisko to, zwane popularnie pełzaniem granic (boundary creeping), może przejawiać się m ię­ dzy innym i w następujących okolicznościach. • Dwie usługi w yodrębnione na podstawie dwóch różnych procesów biznesowych, tworzone w różnym czasie, enkapsulują tę sam ą logikę. • Logika enkapsulowana przez dwie (tworzone w różnym czasie) usługi wyodrębnione na podstawie różnych procesów biznesowych posiada wspólne elementy. Jest tak między innymi wtedy, gdy dwa różne przepływy pracy realizują podobną logikę, lecz zaprojektowane są na dwa odmienne sposoby. • Dwie usługi wyodrębnione w różnym czasie na podstawie tego samego procesu biznesowego enkapsulują podobną logikę. Przykładem takiej sytuacji jest tworzenie dwóch widoków — ogólnego i szczegółowego — tego samego procesu, przez dwa niezależne zespoły projektowe. Prawdopodobieństwo wystąpienia tej okoliczności wzrasta w przypadku procesów o dużej dynamice zmian.

370

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Ryzyko występowania takich okoliczności m ożna redukować przez staranne modelowanie usług, między innym i za pom ocą następujących zabiegów. • Studiowania dostępnej dokumentacji m etadanych istniejących usług przed przystąpieniem do wyodrębniania nowych kandydatur (piszemy o tym w rozdziale 15., w punkcie „Dokumentowanie usług za pom ocą m etadanych”). • Definiowania zestawu obowiązujących standardów w zakresie modelowania usług (o tym piszemy w punkcie „Tworzenie i publikowanie standardów modelowania usług biznesowych”, dalej w tym rozdziale). • Upowszechniania wiedzy na tem at wystąpienia opisanego ryzyka wśród personelu zaangażowanego w modelowanie usług i procesów biznesowych. Zauważmy przy tym, iż zjawiskiem zupełnie innym od opisanego jest dublowanie tych samych elementów logiki w ramach różnych kompozycji usług. Jest rzeczą naturalną i pożądaną wykorzy­ stywanie tych samych usług w różnych kompozycjach jako efektu zamierzonego działania kon­ trolerów tych kompozycji, a nie mimowolnego uchybienia w projekcie.

12.2.8. Emulowanie usług procesowych przy braku orkiestracji (kandydatury na biznesowe usługi zadaniowe) W prowadzenie warstwy orkiestracji usług zmienia stopień złożoności warstwy usług bizneso­ wych i warstwy usług aplikacyjnych, dzięki ustanow ieniu jednej lub wielu usług-kontrolerów, zajmujących się wyłącznie organizacją pracy usług podporządkowanych. Jednak nawet budując warstwy abstrakcji usług bez w yróżniania osobnej warstwy orkiestracji, m ożna podjąć pewne kroki sprawiające, że ewentualne dodanie tej warstwy w przyszłości odbędzie się za cenę m ini­ malnego wysiłku. Istotą tych kroków jest emulowanie (nieistniejącej explicite) usługi procesowej za pomocą od­ powiednio zaprojektowanej usługi zadaniowej (lub zespołu takich usług), w rzeczywistości peł­ niącej rolę kontrolera kompozycji kandydatur na usługi biznesowe (patrz rysunek 12.10). W raz z warstwami podporządkow anych usług biznesowych i aplikacyjnych przypom ina to wyraźnie m odel orkiestracji.

12.2.9. Równoważenie celów modelowania Zarówno przebieg modelowania, jak i jego rezultaty, dalekie są zwykle od perfekcji; nawet jednak perfekcyjne rezultaty szybko tracą swą użyteczność, bo środowisko i uwarunkowania zewnętrzne nieustannie się zmieniają. Nie m a więc innego wyjścia, jak zaakceptować realia i porzucić zamiar m arnotraw ienia czasu oraz wysiłków na konstruowanie nierealistycznych ideałów. Przypomnijmy po raz kolejny — fundam entalnym celem zorientowania środowiska na usługi jest jego właściwe rozpartycjonowanie i stworzenie jego reprezentacji w postaci usług modelowa­ nych zgodnie z: • wymaganiami biznesowymi, • spójnymi standardami, • przyjętymi konwencjami przemysłowymi.

1 2 .2 . W YTYC ZN E I W S K A Z Ó W K I DOTYCZĄCE M O D E L O W A N IA USŁUG

371

Nadrzędna usługa-kontroler działająca jako usługa procesowa Warstwa usług biznesowych emulująca warstwę orkiestracji usług Warstwa usług biznesowych

Warstwa usług aplikacyjnych

Rysunek 12.10. Nadrzędna warstwa usług biznesowych funkcjonująca jako warstwa orkiestracji

I jak nietrudno się domyślić, wymagania zgodności z powyższym przekładają się na często sprzeczne wymogi w zakresie modelowania. I nieuniknione są wówczas kom prom isy rozstrzyga­ ne na podstawie ustanowionych priorytetów. A ostatecznym m iernikiem jakości kandydatury na usługę jest jej przydatność w dziele realizacji celów przedsiębiorstw a — tych doraźnych i tych długofalowych.

12.2.10. Klasyfikowanie logiki modelowanych usług Usługa usłudze nierówna, usługi różnią się zarówno zakresem enkapsulowanej logiki, jak i speł­ nianymi rolami. W ynikają stąd rozmaite relacje między kandydaturam i na usługi oraz rozmaite możliwości w zakresie ich komponowania. Jedne i drugie powinny zostać czytelnie rozpoznane, w przeciwnym razie budowany m odel okaże się mylący i niespójny. Przykładow em u system owi klasyfikacyjnem u poświęcam y przedostatni podrozdział tego rozdziału.

12.2.11. Alokowanie wystarczających zasobów na potrzeby modelowania Nieodłącznym aspektem środowiska firm y zorientowanego na usługi jest relacja działalności biz­ nesowej tej firmy do technologii odpowiedzialnych za automatyzację tejże działalności. O rienta­ cja na usługi w pełni wspiera — a nawet wymusza — wizję rozwiązań sterowanych biznesowo, opartych na technologii adaptowalnej w stopniu umożliwiającym szybkie reagowanie na zmiany zachodzące w logice biznesowej i jej uwarunkowaniach.

372

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Byłoby jednak błędem, poważnie ograniczającym możliwości spełnienia się tej wizji, zawęże­ nie stosowalności zasad zorientowania na usługi wyłącznie do personelu technicznego IT. Archi­ tekci techniczni i programiści nie posiadają (zazwyczaj) wiedzy w zakresie pozwalającym na m o­ delowanie wysokiej jakości usług adekw atnie reprezentujących logikę biznesową; w procesie modelowania wskazany (a nawet konieczny) staje się udział analityków biznesowych (co obrazo­ wo zilustrowano na rysunku 12.11), legitymujących się głęboką wiedzą i doświadczeniem w za­ kresie modeli i procesów biznesowych.

Rysunek 12.11. Uproszczone przedstawienie gałęzi wiedzy niezbędnych do właściwego modelowania poszczególnych warstw usług

12.2.12. Tworzenie i publikowanie standardów modelowania usług biznesowych Przedstawione wskazówki mają charakter orientacyjny, w zamierzeniu wskazywać mają jedynie zarys im plem entowania procesu modelowania usług w konkretnej firmie. Szczegóły tego imple­ mentow ania zależne będą nie tylko od specyfiki biznesu tej firmy, lecz także od przyjętych w fir­ mie metodologii i stosowanych narzędzi, sprawdzonych w dotychczasowej praktyce analizy i m o­ delowania. Niezależnie od stopnia preferencji zaprezentowanych wytycznych i ostatecznego kształtu pro­ cesu modelowania, zalecane jest sformalizowanie szczegółów tego procesu jako oficjalnych stan­ dardów. N a drodze do zorientow ania na usługi nie m a miejsca na improwizację ani dowolność interpretacji.

1 2 .3 . KLASYFIKACJA LOGIKI M O D E LU USŁUG

373

PODSUMOW ANIE •

Wykorzystywanie okazji do wielokrotnego stosowania usług (wieloużywalności) jest kluczowym elementem modelowania wysokiej jakości kandydatur na usługi. Usługi biznesowe reprezentują inny potencjał wieloużywalności niż usługi aplikacyjne.

•

Kluczowym wymaganiem warunkującym jakość i efektywność modelowania usług biznesowych w firmie jest solidna wiedza na temat logiki procesów biznesowych tej firmy.

•

Granice funkcjonalne kandydatury na usługę powinny być wyraźnie określone nie tylko w czasie jej modelowania, lecz także później, gdy pojawią się inne, nowe usługi.

1 2 .3 . K la s yfika c ja lo g ik i m o d e lu usług Dotychczas rezultaty modelowania klasyfikowaliśmy w kategoriach dwóch jednostek: kandydatur na operacje i kandydatur na usługi. Jak wyjaśnialiśmy wcześniej w punkcie „»Usługi« a »kandy­ datury na usługi«”, term in „kandydatura” służy odróżnieniu abstrakcyjnej porcji logiki od kon­ kretnego projektu. Taka kategoryzacja nie zawiera jednak żadnej informacji na temat natury logiki reprezentowanej przez wspomniane kandydatury. Enkapsulacja zorientowana na usługi umożliwia pojedynczej operacji wyrażanie logiki o silnie zróżnicowanym zakresie: operacja ta może reprezentować pojedyncze zadanie wykonujące proste obliczenia, lecz równie dobrze może wywoływać cztery usługi w celu wykonywania serii skompli­ kowanych zadań, związanych z różnymi systemami i procesami. I dlatego, modelując logikę biznesową, warto znać zakres logiki reprezentowanej przez kan­ dydaturę na operację, usługę lub proces. Opisywany dalej przykładowy system klasyfikacji kan­ dydatur bazuje na koncepcji bloku konstrukcyjnego lub budulca ( building block ) — ta metafora znakomicie pasuje do kompozycyjnej natury środowisk zorientowanych na usługi. Takie bloki konstrukcyjne (zwane również „jednostkami modelowania usług” — service m o ­ deling units ) reprezentowane są poprzez etykiety (labels) skojarzone z jednostkam i logiki bizne­ sowej, towarzyszące tym jednostkom w trakcie kom ponowania lub dekomponowania modelu przedsiębiorstwa zorientowanego na usługi. Etykiety te ułatwiają identyfikowanie konkretnych typów logiki, różniących się przede wszystkim pod względem zakresu. Ponadto, jako część opisywanego systemu klasyfikacyjnego, zdefiniujemy kilka dodatkowych terminów, ułatwiających identyfikowanie innych elementów modeli SOA. System ten został przez nas pom yślany jedynie jako swoisty pierwowzór, na podstawie którego konkretni użytkownicy mogą tworzyć własne reguły klasyfikacji, modyfikując istniejące lub dodając nowe, stosownie do własnych standardów przeprowadzania analizy biznesowej. Lektura tego podrozdziału jest konieczna dla czytelników zainteresowanych podrozdziałem następnym — „Porównanie podejść do modelowania (przykład)” — w którym powołujemy się na opisywane tu reguły klasyfikacji.

12.3.1. Model SOE Rozpoczniemy od przedstawienia ogólnego widoku przedsiębiorstwa zorientowanego usługowo (service-oriented enterprise ) znanego jako model SOE. Jak widać na rysunku 12.12, zawiera on ciągi bloków konstrukcyjnych, których zakres logiki zwiększa się stopniowo od strony lewej do prawej.

374

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Rysunek 12.12. Model SOE

Bloki konstrukcyjne m odelu SOE umożliwiają kategoryzowanie różnych jednostek logiki na potrzeby zarówno modelowania, jak i projektowania. Pierwsza warstwa tego modelu odzwiercie­ dla model biznesowy przedsiębiorstwa w postaci ciągu bloków reprezentujących wyłącznie m o­ delowanie biznesowe. Trzecia warstwa modelu to ciąg bloków związanych z modelem technolo­ gicznym przedsiębiorstwa. Druga, pośrednia warstwa to rdzeń modelu SOE, definiowany wspólnie przez warstwy abstrakcyjną (biznesową) i konkretną (technologiczną). Model biznesowy przed­ siębiorstwa jest ściśle związany z procesem m odelowania usług i jako taki zostanie dokładniej opisany w kolejnych punktach.

12.3.2. Model biznesowy przedsiębiorstwa Bloki konstrukcyjne pierwszej warstwy klasyfikują wyłącznie logikę enkapsulowaną przez kandy­ datury na usługi biznesowe. Reprezentują one w sposób abstrakcyjny inteligencję biznesową przed­ siębiorstwa, niezależnie od platformy technologicznej implementującej tę inteligencję. Gdy zatem zaistnieje konieczność dokonania zmian w ramach tej platformy technologicznej, zmiany te będzie można uskutecznić bez naruszania wspomnianej abstrakcyjnej, zorientowanej na usługi, perspektywy logiki biznesowej. W kategoriach modelowania usług bloki konstrukcyjne pierwszej warstwy modelu SOE odnoszą się do logiki rezydującej w warstwie usług biznesowych i warstwie orkiestracji usług.

12.3.3. „Bloki konstrukcyjne" a „modele usług" Bloki konstrukcyjne m odelu SOE stanowią środek klasyfikacji kom plem entarny w stosunku do m odeli usług (o których pisaliśmy w punkcie 5.2.2, „Modele usług”). Podczas gdy modele usług klasyfikują je w kategoriach natury enkapsulowanej logiki, to wspomniane bloki konstrukcyjne odnoszą się do zakresu logiki. W konsekwencji m odel usługi odnosi się zawsze do konkretnej, pojedynczej usługi, podczas gdy blok konstrukcyjny może reprezentować bądź to konkretną usługę, bądź część enkapsulowanej przez nią logiki, bądź też połączoną logikę wielu usług.

1 2 .3 . KLASYFIKACJA LOGIKI M O D E LU USŁUG

375

12.3.4. Podstawowe bloki konstrukcyjne modelowania Wszystko, cokolwiek zawiera się w modelowaniu środowiska zorientowanego na usługi, może zo­ stać przedstawione jako kolekcja bloków konstrukcyjnych, z których każdy należy do jednej z na­ stępujących kategorii: • aktywność, • usługa, • proces. Kategorie te ustanawiają ogólny kontekst i stanowią punkt wyjścia dla nazewnictwa bloków m o­ delu SOE. Wymienione poniżej bloki konstrukcyjne tego modelu składają się na jego część biznesową: • pierwotna aktywność biznesowa, • pierwotna usługa biznesowa, • pierwotny proces biznesowy, • rozszerzony proces biznesowy, • proces biznesowy dom eny przedsiębiorstwa, • proces biznesowy przedsiębiorstwa. W tym punkcie opisujemy pierwsze trzy z wymienionych (patrz rysunek 12.13) jako repre­ zentujące fundam entalne i najbardziej powszechne części modelowanego środowiska. Trzy pozo­ stałe związane są raczej ze skomplikowanymi konfiguracjami procesów biznesowych, a ich opis wykraczałby poza ram y tej książki.

Rysunek 12.13. Trzy fundamentalne bloki konstrukcyjne modelu biznesowego przedsiębiorstwa

Pierwotne aktywności biznesowe Pierwotna aktywność biznesowa (primitive business activity) reprezentuje najmniejszą definio­ walną i wykonywalną cząstkę logiki środowiska zorientowanego na usługi. Oznacza to, że w jaki­ kolwiek sposób nie dokonywano by podziału procesu biznesowego, pierwotna aktywność bizne­ sowa zawsze będzie najdrobniejszą porcją tego podziału. Najdrobniejszą, czyli niedającą się już zdekomponować bądź też niewymagającą dalszej dekompozycji. Jak wyjaśnialiśmy w podrozdziale „Modelowanie usług krok po kroku”, zalecanym podej­ ściem do modelowania usług jest właśnie dekompozycja logiki procesu biznesowego na pierwotne aktywności biznesowe i wykorzystanie każdej z tych wynikowych aktywności jako kandydatury na operacje usługi.

376

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Fizyczną implementację pierwotnej aktywności biznesowej m ożna więc porównać do funk­ cjonalności dostarczanej przez drobnoziarnistą operację usługi; operacje gruboziarniste ekspo­ nują natom iast logikę biznesową dającą się zdekom ponować na serię pierw otnych aktywności biznesowych. A zatem drobnoziarnista operacja eksponująca logikę aplikacyjną automatyzującą pojedynczą akcję procesu biznesowego jest m iarodajną jednostką implementacji.

UWAGA W terminologii tradycyjnych metodologii modelowania procesów biznesowych odpowiednikiem pierwotnej aktywności biznesowej jest aktywność niepodzielna (a to m ic a c tiv ity .

Aktywności procesowe Pojęciem powiązanym z pierwotną aktywnością biznesową jest aktywność procesowa (process activity). Nie jest to blok konstrukcyjny modelu SOE, lecz nieformalne określenie wykonywalnego kroku w ram ach logiki przepływu pracy procesu biznesowego. Odmiennie niż pierwotna aktyw­ ność biznesowa, aktywność procesowa nie posiada ustalonego zakresu logiki — zakres ten wynika z przyjętego stopnia granulacji procesu biznesowego. Aktywność procesowa może więc, ale nie musi, dekomponować się na wiele pierwotnych aktywności biznesowych. Procesy biznesowe m ożna modelować na różnych poziomach abstrakcji. Gruboziarnisty pro­ ces zawiera zwykle pewną liczbę gruboziarnistych kroków, z których każdy stanowi aktywność procesu w opisanym powyżej sensie. Niektóre z tych aktywności procesu mogą być praw dopo­ dobnie wyrażone przez ciąg wielu pierwotnych aktywności biznesowych. Im bardziej szczegółowa (drobnoziarnista) definicja samego procesu, tym większa liczba jego kroków. Równocześnie jednak większe prawdopodobieństwo, że dany krok dekomponować się będzie na mniejszą liczbę pierwotnych aktywności biznesowych lub nawet stanowić pojedynczą taką aktywność. A zatem drobnoziarnista definicja procesu biznesowego bliższa jest wynikowi jego dekompozycji na pierwotne aktywności biznesowe niż definicja gruboziarnista.

UWAGA W terminologii klasycznych konwencji modelowania przepływu pracy pojedynczy krok reprezentujący kolekcje innych kroków nazywany jest procesem predefiniowanym (predefined process lub podprocesem (subprocess. Tradycyjne metodologie modelowania procesów biznesowych określają aktywności procesowe jako (po prostu) aktywności (,a c tiv itie s .

Usługi biznesowe O usługach biznesowych (business services) i kandydaturach na te usługi (business service candi­ dates) napisaliśmy już sporo. W kontekście opisywanego systemu klasyfikacji każda usługa bizne­ sowa składa się z jednej lub wielu pierwotnych aktywności biznesowych. Aktywności te mogą re­ zydować niepodzielnie wewnątrz usługi bądź też formować logiczny algorytm realizujący logikę niezależnego przepływu pracy w oparciu o reguły biznesowe.

1 2 .4 . P O R Ó W N A N IE PODEJŚĆ DO M O D E L O W A N IA (PRZYKŁAD)

377

Po zaimplementowaniu kandydatura na usługę biznesową przyjmuje zazwyczaj postać usługi sieciowej. Zależnie od zakresu enkapsulowanej logiki kandydatury na usługi biznesowe podlegają dalszej klasyfikacji; poniżej opisujemy dwie wybrane podkategorie tej klasyfikacji. Pierw otne usługi biznesowe Pierwotna usługa biznesowa (primitive business service) lub kandydatura na tę usługę (primitive business service candidate) to typ usługi biznesowej prezentujący funkcjonalność ograniczoną do prostego zadania biznesowego lub prostej funkcji biznesowej; innymi słowy, jest to blok kon­ strukcyjny o najmniejszej granulacji w ram ach rozwiązania zorientowanego na usługi. Tym, co odróżnia ten typ usługi od innych typów, jest założenie, iż usługa ta nie enkapsuluje funkcjonalności oferowanej przez inne usługi — czyli nie komponuje innych usług, a po prostu odpowiada za wykonanie konkretnego zadania (które swoją drogą może, choć nie musi, stanowić składnik kompozycji). Pierwotne usługi biznesowe implementowane są zwykle jako drobnoziar­ niste usługi sieciowe, choć mogą być także wyrażane przez gruboziarniste operacje takich usług. Pierw otny proces biznesowy Pierwotny proces biznesowy (primitive business process) reprezentuje ciało logiki przepływu pra­ cy złożonego z powiązanych aktywności procesowych. Definiowany jest w ścisłych granicach funkcjonalnych, wyznaczanych zwykle przez konkretne zadanie biznesowe (na przykład wysta­ wienie faktury czy realizowanie zamówienia). Implementowany może być jako usługa procesowa lub zadaniowa usługa biznesowa. PODSUMOW ANIE •

System klasyfikacji usług rozróżnia je na podstawie zakresu enkapsulowanej przez nie logiki.

•

Logika biznesowa reprezentowana przez bloki konstrukcyjne wspomnianego systemu może być dekomponowana na aktywności, usługi i procesy.

1 2 .4 . P o ró w n a n ie p o d e jś ć d o m o d e lo w a n ia (p rz y k ła d ) ANALIZA PRZYPADKU

Dotychczas przyglądaliśmy się bacznie początkom transformacji firmy RailCo w kierunku SOA, tym razem odwiedzimy naszych znajomych z TLS, by przyjrzeć się innem u wariantowi m odelow ania usług, powodowanego koniecznością stawienia czoła nowym wymaganiom biznesowym, przed którymi stanęła firma TLS. Realia są tu zgoła inne niż w RailCo, inne też będą param etry samego modelowania. • Modelowanie kandydatur na usługi wykonywane jest przy użyciu trzech różnych podejść, dla celów porównawczych. • Dwa spośród wymienionych podejść zakładają wyodrębnienie warstwy orkiestracji poprzez zdefiniowanie kandydatury na usługę procesową.

378

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

• W jednym z podejść wyodrębniane są kandydatury na podmiotowe usługi biznesowe. • Modelowanie odbywa się z użyciem systemu klasyfikacji opisanego w poprzednim podrozdziale, stąd też stosowana w tym przykładzie terminologia różnić się będzie od występującej w poprzednich analizach przypadków. Zobaczm y zatem, jak TLS zamierza sobie poradzić z pewnym problem em związanym z rozliczaniem czasu pracy pracowników delegowanych do klientów na zasadzie outsourcingu. Problem W celu wykonania pewnych typów robót konserwacyjnych TLS deleguje swoich pracowni­ ków do siedzib klienckich. Delegowani pracownicy rozliczają się z czasu pracy w cyklu tygo­ dniowym, wpisując w karty pracy liczbę godzin spędzonych u klientów. Podstawą wystawiania faktur dla klientów są jednak nie wspomniane karty pracy, lecz umowy (kontrakty) z klien­ tami, określające rozmiar pracy planowany w ram ach outsourcingu w związku z określonym zadaniem. Może się więc zdarzyć (i zdarza się — na tym właśnie polega cały problem ), że sum a­ ryczne zestawienie czasu spędzonego przez wszystkich delegowanych pracowników u klienta pozostaje w wyraźnej rozbieżności z liczbą roboczogodzin ustalonych z klientem w ramach wspom nianego kontraktu. I wówczas istnieje ryzyko, iż klient uzna wystawioną fakturę za nieuzasadnioną (zawyżoną), bo pozostającą w sprzeczności ze stanem faktycznym, czyli ilością roboczogodzin faktycznie poświęconych przez TLS klientowi. W celu rozwiązywania tego typu problemów postanowiono w TLS o zastąpieniu dotychczas używanego tradycyjnego systemu rozliczania czasu pracy poprzez zintegrowanie jego funkcji ze swym rozproszonym syste­ m em finansowo-księgowym. Początkowy proces rozliczania karty czasu pracy Po zebraniu wymagań biznesowych analitycy TLS sporządzili wstępną dokumentację prostego Procesu rozliczania karty czasu pracy. Otóż każda karta czasu pracy dostarczana przez pra­ cownika poddawana m a być serii kroków weryfikacyjnych; pozytywny wynik weryfikacji skut­ kować m a zaakceptowaniem rozliczenia, negatywny wynik powodować m a wykonanie serii kroków związanych z odrzuceniem rozliczenia, a następnie zakończenie procesu. Na rysunku 12.14 przedstawiono ogólny schemat tego procesu, obejmujący następujące kroki. 1. Odbierz kartę czasu pracy. 2. Zweryfikuj odebraną kartę czasu pracy. 3. W przypadku weryfikacji pozytywnej zaakceptuj kartę czasu pracy i przejdź do kroku 5. 4. Odrzuć kartę czasu pracy. 5. Zakończ proces. Proces ten jest samodzielny i samowystarczalny, niezależny od innych procesów. W zorien­ towanym na usługi środowisku TLS jest zatem uważany za pierwotny proces biznesowy.

1 2 .4 . P O R Ó W N A N IE PODEJŚĆ DO M O D E L O W A N IA (PRZYKŁAD)

(

Start

379

)

Odbierz kartę czasu

/

P^cy

Rozbudowa procesu rozliczania karty czasu pracy Choć prosty, bo składający się z zaledwie pięciu kroków, proces ten wymaga głębszej analizy. Jego szczegóły definiować będziemy, dekom ponując go z użyciem bloków konstrukcyjnych opisywanego wcześniej systemu klasyfikacji. Rozpoczniemy od kroku Zweryfikuj odebraną kartę czasu pracy, będącego w istocie podprocesem posiadającym własną logikę. Podproces ten możemy wyrazić jako serię następujących prostszych kroków. 2a. Skonfrontuj czas pracy deklarowany w karcie z czasem pracy figurującym na fakturze dla klienta. 2b. Sprawdź, czy wszystkie deklaracje nadgodzin na karcie są autoryzowane przez klienta. 2c. Sprawdź, czy czas pracy deklarowany w związku z konkretnym projektem nie przekracza limitu predefiniowanego dla tego projektu. 2d. Sprawdź, czy czas pracy deklarowany przez pracownika nie przekracza predefiniowanego lim itu tygodniowego ustalonego dla tegoż pracownika. Każdy z powyższych kroków jest p rostą akcją, traktow aną jako pierw otna aktywność biznesowa.

380

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Kolejny dekom ponowany krok — Odrzuć kartę czasu pracy — przekłada się na następu­ jącą serię pierwotnych aktywności biznesowych. 4a. Zaktualizuj profil pracownika o notatkę na tem at odrzuconej karty czasu pracy. 4b. Wyślij do pracownika powiadomienie o odrzuceniu jego karty czasu pracy. 4c. Wyślij powiadomienie do kierownika. W wyniku powyższych dekompozycji uzyskujemy większą liczbę pierwotnych aktywności biznesowych. Nasz zrewidowany proces składa się teraz z 10 następujących kroków (patrz rysunek 12.15). 1. Odbierz kartę czasu pracy. 2. Skonfrontuj czas pracy deklarowany w karcie z czasem pracy figurującym na fakturze dla klienta. 3. Sprawdź, czy wszystkie deklaracje nadgodzin na karcie są autoryzowane przez klienta. 4. Sprawdź, czy czas pracy deklarowany w związku z konkretnym projektem nie przekracza limitu predefiniowanego dla tego projektu. 5. Sprawdź, czy czas pracy deklarowany przez pracownika nie przekracza predefiniowanego limitu tygodniowego ustalonego dla tegoż pracownika. 6. W przypadku weryfikacji pozytywnej zaakceptuj kartę czasu pracy i przejdź do kroku 10. 7. Odrzuć kartę czasu pracy i zaktualizuj profil pracownika o notatkę na temat odrzuconej karty czasu pracy. 8. Wyślij do pracownika powiadomienie o odrzuceniu jego karty czasu pracy. 9. Wyślij powiadomienie do kierownika. 10. Zakończ proces. Jak wspominaliśmy, chociaż początkowy zbiór usług TLS został stworzony przy użyciu podejścia zstępującego, uwieńczonego pełnym sukcesem, to jednak krytykowanego ze wzglę­ du na rozm iar koniecznej wstępnej analizy. Tym razem więc analitycy zamierzają wypróbo­ wać alternatywne podejścia przed przystąpieniem do dalszej rozbudowy SOA na wielką skalę. Projekt stwarza świetną okazję ku tem u — przed przejściem do fazy projektowania porów ­ nane zostaną rezultaty każdego z zastosowanych podejść, w postaci wyodrębnionych kandy­ datur na usługi. Podejście 1.: w yodrębnianie usług hybrydowych N a początek podejście najbardziej efektywne kosztowo i czasowo: stworzenie hybrydowych usług zadaniowych. Analitycy są w pełni świadomi tego, iż podejście to nie doprowadzi do wysokiej jakościowo SOA, lecz m uszą brać pod uwagę uwarunkowania praktyczne, poza tym ciekawi są efektów wynikających ze skrajności, jaką przecież prezentuje to podejście. Pierw­ szym posunięciem jest podzielenie zdefiniowanych pierwotnych aktywności biznesowych na dwie kategorie, tak jak przedstawiono to na rysunku 12.16.

1 2 .4 . P O R Ó W N A N IE PODEJŚĆ DO M O D E L O W A N IA (PRZYKŁAD)

Rysunek 12.15. Zrewidowany Proces rozliczania karty czasu pracy — każda aktywność procesowa jest jednocześnie pierwotną aktywnością biznesową

381

382

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Rysunek 12.16. Wynik grupowania ad hoc pierwotnych aktywności biznesowych

Dwie utworzone grupy zadań wydają się adekwatnie reprezentować kolektywną logikę procesu biznesowego, mogą więc stanowić punkt wyjścia dla wyodrębnienia dwóch poniższych kandydatur na usługi: • Weryfikacja karty czasu pracy, • Odrzucenie karty czasu pracy. Każda z powyższych kandydatur wymaga jeszcze pewnej adjustacji, czyli dokładnego określenia kandydatur na operacje na poziom ie ziarnistości mniejszej niż dotychczasowa. W ynik tej adjustacji widzimy na rysunkach 12.17 i 12.18.

Rysunek 12.17. Kandydatura na usługę Weryfikacja karty czasu pracy

1 2 .4 . P O R Ó W N A N IE PODEJŚĆ DO M O D E L O W A N IA (PRZYKŁAD)

383

Rysunek 12.18. Kandydatura na usługę Odrzucenie karty czasu pracy

Obie kandydatury tworzą banalną kompozycję widoczną na rysunku 12.19: kandydatura Weryfikacja karty czasu pracy podobna jest do usługi procesowej, jako że zawiera kolekcję logiki pierwotnych procesów biznesowych, jak również logikę niezbędną do podporządko­ wania (skomponowania) usługi Odrzucenie karty czasu pracy po negatywnej weryfikacji.

Rysunek 12.19. Prosta kompozycja składająca się z dwóch kandydatur na hybrydowe usługi zadaniowe

No i m am y konkretny rezultat, osiągnięty niewielkim nakładem czasu; nie m ożna jednak zapom inać o drugiej stronie medalu, którą są niedostatki zastosowanego podejścia. Za: • Mało pracochłonna analiza i modelowanie. • W yodrębnienie prostych i łatwych do zrozumienia kandydatur na usługi. Przeciw: • Brak wyodrębnienia specjalizowanych warstw usług, co eliminuje potencjalne korzyści płynące z abstrahowania logiki. • Brak realnych możliwości wieloużywania usług jako specyficznych dla konkretnego procesu. • Brak perspektyw zwinności organizacyjnej, bo obie usługi powiązane są sztywno z logiką procesu.

384

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

UWAGA Opisane podejście odpowiada pierwszemu spośród ośmiu scenariuszy opisanych w podrozdziale 9.7 „Scenariusze konfiguracji warstwy usług".

Podejście 2.: w yodrębnianie usług podm iotowych Następne z zastosowanych podejść opiera się na biznesowych usługach podmiotowych. Jego celem jest zbudowanie warstwy kandydatur na takie usługi oraz nadrzędnej warstwy orkiestracji zawierającej pojedynczą kandydaturę na usługę procesową. Rozpoczynamy od przeglądu widocznego na rysunku 12.20 modelu podm iotów związa­ nych z Procesem rozliczania karty czasu pracy.

Rysunek 12.20. Model podmiotów TLS z wyszczególnieniem podmiotów związanych z Procesem rozliczania karty czasu pracy

Analitycy TLS przestudiowali ten model wraz z następującą listą drobnoziarnistych kan­ dydatur na operacje, zidentyfikowanych w ram ach poprzedniej analizy: • pobierz godziny deklarowane dla danego klienta we wskazanym zakresie dat, • pobierz godziny naliczone dla danego klienta we wskazanym zakresie dat, • porównaj godziny deklarowane z naliczonymi, • pobierz godziny nadliczbowe we wskazanym zakresie dat, • pobierz autoryzację, • sprawdź autoryzację, • pobierz tygodniowy limit godzin, • porównaj godziny deklarowane przez pracownika z jego limitem tygodniowym, • zaktualizuj historię pracownika,

1 2 .4 . P O R Ó W N A N IE PODEJŚĆ DO M O D E L O W A N IA (PRZYKŁAD)

385

• wyślij kom unikat do pracownika, • wyślij kom unikat do kierownika. Przed przystąpieniem do grupowania wymienionych kandydatur analitycy zdefiniowali wpierw wstępną kandydaturę na usługę procesową o nazwie Usługa procesowa rozliczania karty czasu pracy, opierając się na kandydaturach reprezentujących reguły biznesowe i logikę warunkową — tak jak na rysunku 12.21.

/ /

/

Usługa procesowa rozliczania karty czasu pracy

\ \

Porównaj godziny deklarowane z naliczonymi Sprawdź autoryzację Porównaj godziny deklarowane przez pracownika z jego limitem tygodniowym /

Rysunek 12.21. Kandydatura na usługę procesową rozliczania karty czasu pracy

Następnie, przeglądając podmiot Karta czasu pracy, analitycy zdecydowali o wyodrębnieniu kandydatury na usługę o tej samej nazwie. Na podstawie atrybutów wspomnianego podmiotu analitycy zdecydowali, że usługa ta stanowić będzie wynik grupowania następujących operacji: • pobierz godziny deklarowane dla danego klienta we wskazanym zakresie dat, • pobierz godziny nadliczbowe we wskazanym zakresie dat, • pobierz autoryzację. W dalszym ciągu prowadzonej analizy odkryto możliwość uczynienia dwóch pierwszych operacji bardziej wieloużywalnymi, dopuszczając dodatkowe kryteria filtrowania, oprócz do­ tychczasowego filtrowania w oparciu o zakres dat. Mimo iż bieżący proces wykorzystuje tylko to ostatnie, niewykluczone, że potencjalne przyszłe procesy żądać będą zliczania godzin (zwy­ kłych i nadliczbowych) w oparciu o inne kryteria. Ostatecznie wyodrębniono kandydaturę na usługę Karta czasu pracy w postaci widocznej na rysunku 12.22.

Rysunek 12.22. Kandydatura na usługę Karta czasu pracy

386

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Przeglądając podmiot Faktura, analitycy zgodzili się, iż zasługuje on na reprezentację w po­ staci osobnej usługi podmiotowej. Kandydatura na tę usługę otrzymała nazwę (oczywiście) Faktura i pojedynczą operację: • pobierz godziny naliczone dla danego klienta we wskazanym zakresie dat. Konfrontując tę kandydaturę z zasadami zorientowania na usługi (głównie wieloużywalnością), analitycy zdecydowali jednak o tym, by wspomniana operacja była bardziej ogólna, oraz o dodaniu jeszcze jednej, czego wynik widoczny jest na rysunku 12.23. Dzięki takiej postaci usługi potencjalne usługi-wnioskodawcy będą mogły pobierać dane dotyczące naliczonych godzin niezależnie od pobierania danych klientów.

Rysunek 12.23. Kandydatura na usługę Faktura

Ponieważ podm ioty Pracownik i Historia pracownika są ściśle związane, analitycy zde­ cydowali o ich wspólnej reprezentacji w postaci usługi podmiotowej Pracownik. Kandydaturze na tę usługę przyporządkowano dwie operacje, czego wynik widoczny jest na rysunku 12.24.

Rysunek 12.24. Kandydatura na usługę Pracownik

W yczerpał się tym samym zestaw dostępnych podmiotów, lecz nie uwzględniono jeszcze dwóch następujących operacji: • wyślij kom unikat do pracownika, • wyślij kom unikat do kierownika.

1 2 .4 . P O R Ó W N A N IE PODEJŚĆ DO M O D E L O W A N IA (PRZYKŁAD)

387

Zgrupowano je w wieloużywalną usługę aplikacyjną o nazwie Powiadamianie, po czym, mając na względzie potencjalną wieloużywalność tej usługi, postanowiono połączyć je w jedną operację, tak jak na rysunku 12.25.

Rysunek 12.25. Kandydatura na usługę Powiadamianie

W arto nadm ienić w tym miejscu, że w typowym modelowaniu biznesowych usług pod­ miotowych, gdzie każda z wielu pojawiających się kandydatur na usługę musi zostać w pełni wyposażona w zestaw operacji czyniących zadość istniejącym wymaganiom przetwarzania, wieloużywalność jest zagadnieniem znacznie większej wagi, niż mogłoby to wynikać z nasze­ go prostego przykładu, bo w przykładzie tym większość zidentyfikowanych operacji wynika wyłącznie z doraźnych wymagań. Ostateczny rezultat prezentowanego podejścia, z uwzględnieniem warstw abstrakcji — orkiestracyjnej, biznesowej i aplikacyjnej — widoczny jest na rysunku 12.26.

Warstwa orkiestracji usług Warstwa usług biznesowych

Warstwa usług biznesowych

1-------------Warstwa usług aplikacyjnych

Rysunek 12.26. Kompozycja usług kontrolowana przez warstwę orkiestracji

388

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

I, jak poprzednio, pora na ocenę tego podejścia. Za: • Możliwość tworzenia kandydatur na wieloużywalne usługi. • Ustanowienie dodatkowego poziomu abstrakcji w postaci warstwy orkiestracji. • Duży stopień rozszerzalności i perspektywa zwinności organizacyjnej. Przeciw: • W ymagany większy wysiłek związany z analizą. • Bardziej skomplikowana wynikowa kompozycja usług. • Konieczność utworzenia dodatkowych, niezidentyfikowanych jeszcze usług — usług aplikacyjnych realizujących przetwarzanie na rzecz usług Pracownik, Karta czasu pracy i Faktura.

UWAGA Zaprezentowane podejście jest odpowiednikiem ostatniego, ósmego spośród scenariuszy opisanych w podrozdziale 9.7, „Scenariusze konfiguracji warstwy usług".

Podejście 3.: łączenie usług zadaniowych i usług podm iotowych Przed podjęciem ostatecznej decyzji dotyczącej wyboru strategii rozwiązania opisanego na wstępie problem u w TLS postanowiono wypróbować jeszcze jedną opcję. Ponieważ odkryto, że kolekcja zadań weryfikacyjnych Procesu rozliczania karty czasu pracy skrywa potencjał wieloużywalności, dodając kandydaturę na usługę zadaniow ą do zdefiniow anych właśnie kandydatur na usługi podmiotowe, można otrzymać wieloużywalną kompozycję. Kompozycja ta reprezentowałaby podproces, który mógłby być używany przez wiele procesów nadrzędnych. Ponieważ większość pracy w tym kierunku została już wykonana, dodatkowe modelowanie nie powinno zająć wiele czasu. Rozpoczęto więc od zidentyfikowania zadań weryfikacyjnych i pogrupowania ich w ram y kandydatury na nową usługę — Weryfikacja karty czasu pracy (patrz rysunek 12.27).

Rysunek 12.27. Kandydatura na usługę Weryfikacja karty czasu pracy

1 2 .4 . P O R Ó W N A N IE PODEJŚĆ DO M O D E L O W A N IA (PRZYKŁAD)

389

Realokacja dwóch kandydatur na operacje nie m a wpływu na żadną z poprzednio zdefi­ niowanych kandydatur na usługi podmiotowe, redukuje jedynie przepływ pracy w kandy­ daturze na Usługę procesową rozliczania karty czasu pracy. Zmienia ona jednak również konfigurację kompozycji, w której kandydatura na usługę zadaniową tworzy nową warstwę, co widoczne jest na rysunku 12.28.

Rysunek 12.28. Zrewidowana kompozycja usług, zawierająca usługę zadaniową

Zobaczmy zatem, czy było warto. Za: • Podobnie jak poprzednio, m am y korzyści w zakresie zwinności organizacyjnej i rozszerzalności. • Jeśli podproces kontrolowany przez usługę Weryfikacja karty czasu pracy jest prawdziwie wieloużywalny, korzystne może być wyabstrahowanie go z większego zakresu logiki przepływu pracy.

390

RO ZD ZIA Ł 1 2 . ■ A N A L IZ A Z O R IE N T O W A N A N A USŁUGI (CZĘŚĆ II. M O D E L O W A N IE USŁUG)

Przeciw: •

Jeszcze b a rd z ie j s k o m p lik o w a n a s tr u k tu r a k o m p o z y c ji z p o w o d u w p ro w a d z e n ia n o w e j w a rs tw y ab s tra k c ji.

•

U s u n ię c ie d w ó c h o p e ra c ji z u s łu g i p ro c e s o w e j p o w o d u je d e c e n tra liza c ję k o n tr o li n a d

Procesem rozliczania karty czasu pracy. UWAGA To ostatnie z zaprezentowanych podejś ć odpowiada siódmemu spośród scenariuszy opisa­ nych w podrozdziale 9.7, „Scenariusze konfiguracji warstwy usł ug". P o d k o n ie c d n ia a n a lity c y p o ró w n a li w szystkie tr z y p o d e jś c ia p o d k ą te m ic h słab ych i m o c ­ n y c h s tro n , a ta k że z p e rs p e k ty w y d o ra ź n y c h i d łu g o fa lo w y c h c e ló w T L S ( i k o m p r o m is ó w w y n ik a ją c y c h ze s p rz e c zn y c h e le m e n tó w ty c h c e ló w ). O s ta te c z n ie z d e c y d o w a n o się n a d ru g ie z z a p re z e n to w a n y c h tu ro z w ią z a ń , b a zu ją c e w y łą c z n ie n a u s łu g a c h p o d m io to w y c h . P o rz u c o n o ta k ż e z a m ia r s to s o w a n ia w p rz y s z ło ś c i czystej s tra te g ii z s tę p u ją c e j, ja k o n ie m o ż liw e j w w a ru n k a c h o g ra n ic z o n e g o czasu i p re s ji n a d o s ta rc z a n ie n o w y c h usług. Z a z a ­ a k c e p to w a n y w a r ia n t u z n a n o s tra te g ię z w in n ą .

PODSUMOWANIE •

Porównanie róż nych podejść do modelowania usł ug dowodzi, ż e każ de z nich wiąż e się zarówno z korzyściami, jak też i rezygnacją z niektórych korzyści.

•

Im bardziej dogłę bna analiza wstę pna, tym wię ksze potencjalne korzyści z perspektywy celów dł ugofalowych.

Część V

Budowanie SOA (technologie i projekt) Rozdział 13. Projektowanie zorientowane na usługi (Część I. Wprowadzenie) Rozdział 14. Projektowanie zorientowane na usługi (Część II. Wytyczne kom ponowania SOA) Rozdział 15. Projektowanie zorientowane na usługi (Część III. Projektowanie usług) Rozdział 16. Projektowanie zorientowane na usługi (Część IV. Projektowanie procesu biznesowego) Rozdział 17. Podstawowe rozszerzenia WS-* Rozdział 18. Platformy SOA

Przygotowania do podróży zakończone — zatem w drogę! Opisywane w poprzednich rozdziałach teorie, koncepcje i rezultaty analiz trzeba teraz skonfrontować z realnym światem, czyli konkret­ nymi projektam i SOA. Ten i wszystkie następne rozdziały tej książki poświęcone są rozmaitym aspektom technologii SOA i w drażaniu tych technologii, opisywanemu krok po kroku zarówno w odniesieniu do poszczególnych usług, jak i SOA w całości.

Projektowanie zorientowane na usługi (Część I. Wprowadzenie) 13.1. W prowadzenie do projektowania zorientowanego na usługi 13.2. Podstawy XML Schema związane z WSDL 13.3. Podstawy języka WSDL 13.4. Podstawy języka SOAP 13.5. Narzędzia do projektowania interfejsów usług

394

R O ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Na początku rozdziału 11. stwierdziliśmy, że faza analizy zorientowanej na usługi jest bodaj najważ­ niejszym etapem cyklu realizacji SOA. Jeżeli tak, to etap projektowania zorientowanego na usługi zde­ cydowanie plasuje się na drugiej pozycji i to z naprawdę niewielką stratą do pozycji lidera. Podejmo­ wane na tym etapie decyzje dotyczące usług determinują jakość i długowieczność wynikowej SOA. Jak dowiedziemy w tym i trzech następnych rozdziałach, opracowanie własnych standardów projektowych jest kluczową częścią tego etapu. Standardy te, gdy właściwie ustanowione i konse­ kwentnie przestrzegane, stają się potencjalnym „barom etrem ” realizacji wielu podstawowych ko­ rzyści płynących ze współczesnej SOA.

1 3 .1 . W p r o w a d z e n ie d o p r o je k to w a n ia z o rie n to w a n e g o na usługi Istotą procesu projektowania zorientowanego na usługi jest wyprowadzanie konkretnych postaci usług z ich logicznych kandydatur wyodrębnionych na etapie modelowania, a następnie składanie tych konkretnych usług w abstrakcyjne kompozycje implementujące proces biznesowy.

13.1.1. Cele projektowania zorientowanego na usługi Faza projektowania usług to konieczność udzielenia odpowiedzi na następujące pytania. • Jak z kandydatur na usługi, będących rezultatem analizy i modelowania, wyprowadzić fizyczną postać definicji interfejsów usług? • Które z cech charakterystycznych SOA chcemy zrealizować i rozwijać? • Jakich związanych z SOA standardów przemysłowych będziemy musieli przestrzegać i jakie rozszerzenia będziemy wykorzystywać w implementowaniu projektów usług i wybranych cech SOA? Poszukiwanie odpow iedzi na powyższe pytania wymaga dalszej analizy, dotyczącej przede wszystkim czynników środowiskowych i standardów projektowych, które kształtować będą pro­ jektowane usługi. W śród podstawowych celów przyświecających projektowaniu zorientowanem u na usługi wymienić należy następujące. • Określenie podstawowego zbioru rozszerzeń architektonicznych. • Ustanowienie granic architektury. • Zidentyfikowanie wymaganych standardów projektowych. • Zdefiniowanie abstrakcyjnego projektu interfejsów usług. • Zidentyfikowanie potencjalnych kompozycji usług. • Oszacowanie wsparcia dla zasad zorientowania na usługi. • Zbadanie wsparcia dla charakterystyki współczesnej SOA.

13.1.2. „Standardy projektowe" a „standardy przemysłowe" W tym rozdziale często używać będziemy term inu „standard” w różnych znaczeniach, które nie­ trudno pomylić ze sobą. By ryzyko tej pomyłki zminimalizować, użyjemy odpow iednich przy­ miotników. Standardami projektowymi (design standards) nazywać będziemy standardy wypra­

1 3 .1 . W P R O W A D Z E N IE DO P R O JEK TO W A N IA Z O R IE N T O W A N E G O N A USŁUGI

395

cowywane indywidualnie przez poszczególne organizacje w celu upewnienia się, że budowanie SOA postępuje zgodnie ze spójnym zbiorem przyjętych konwencji. Mianem standardów prze­ mysłowych (industry strandards) określać będziemy natom iast standardy wypracowywane przez organizacje standaryzacyjne i publikowane w form ie specyfikacji dotyczących usług sieciowych i języka XML (o czym pisaliśmy w punkcie 4.2.1, „Standardy, specyfikacje i rozszerzenia”).

13.1.3. Proces projektowania zorientowanego na usługi Podobnie jak analiza zorientowana na usługi, tak i projektowanie zorientowane na usługi stero­ wane jest przez pewien nadrzędny proces, rozpoczynający się od pewnych prac przygotowaw­ czych. Ten nadrzędny proces urucham ia serię iteracyjnych procesów organizujących różne typy projektów usług i ostatecznie całościowy projekt przepływu pracy w ram ach kompletnego roz­ wiązania (patrz rysunek 13.1). Analiza zorientowana usługowo

Kroki — Projektowanie zorientowane usługowo

Komponowanie SOA

Rozdział 14

Krok 2 Tworzenie usług

Projektowanie biznesowych usług podmiotowych

Krok 3

usług

Projektowanie usług aplikacyjnych

Rozdział 15

Krok 4

Wdrażanie usług

Projektowanie biznesowych usług zadaniowych

Krok 5 Administrowanie usługami

Projektowanie procesu biznesowego zorientowanego na usługi

Rozdział 16

Rysunek 13.1. Wysokopoziomowa struktura procesu projektowania zorientowanego na usługi

396

R O ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Krok 1.: komponowanie SOA Fundam entalną zaletą SOA jest fakt, że każda instancja architektury zorientowanej na usługi jest unikatowo komponowalna. Chociaż przeważnie SOA im plementowana jest z użyciem powszech­ nego zestawu współdzielonych technologii bazujących na kluczowych specyfikacjach, związanych z XML i usługami sieciowymi pierwszej generacji, to m odularna natura świata specyfikacji WS-* umożliwia elastyczne rozszerzanie tego podstawowego wariantu w miarę potrzeb. Krok kom ponow ania SOA podzielić m ożna na trzy poniższe stadia, opisywane dokładniej w rozdziale 14. 1. W ybór warstw usług. 2. Umiejscowienie rdzennych standardów SOA. 3. W ybór rozszerzeń SOA. Kroki 2., 3. i 4.: projektowanie usług Tytułowe kroki reprezentowane są przez następujące trzy osobne procesy opisywane w rozdziale 15. • Proces projektowania biznesowych usług podmiotowych. • Proces projektowania usług aplikacyjnych. • Proces projektowania biznesowych usług zadaniowych. Materiałem wejściowym dla każdego z tych procesów jest zestaw kandydatur na usługi, wyod­ rębnionych w procesie modelowania na etapie analizy zorientowanej na usługi. Krok 5.: projektowanie procesu biznesowego zorientowanego na usługi Po sporządzeniu inwentaryzacji projektów usług nadchodzi czas na stworzenie warstwy orkiestracji — spoiwa wiążącego projektowane usługi z logiką procesu biznesowego. Rezultatem tego kroku jest formalna, wykonywalna definicja logiki przepływu pracy, na podstawie której tworzona jest definicja procesu w języku WS-BPEL (o czym piszemy szczegółowo w rozdziale 16.).

13.1.4. Przygotowania Przed rozpoczęciem właściwego procesu projektowania konieczne jest upewnienie się, że wystar­ czająco rozum iane są kluczowe elementy składni i semantyki języków, przy użyciu których zapi­ sywane będą definicje projektowanych usług. W rozdziale 5. pisaliśmy o koncepcjach związanych z językiem WSDL i protokołem SOAP, teraz w kolejnych punktach zajmiemy się podstawowymi elementami tych języków oraz kluczowymi elementami języka X M L Schema Definition Language. Powiązanie między trzema wymienionymi specyfikacjami widoczne jest na rysunku 13.2. Te skrótowe opisy nie mają — oczywiście — zastąpić regularnego tutoriala, ich zadaniem jest raczej dostarczenie wiedzy niezbędnej do zrozum ienia następujących części rozdziałów poświę­ conych projektowaniu usług: • odwołań do specyficznych elementów języka w rozdziale 14., „Wytyczne komponowania SOA”, oraz opisów procesów projektowania w rozdziale 15.; • przykładowego kodu w licznych analizach przypadków przeplatających się ze wspomnianymi opisami procesów w rozdziale 15.

1 3 .2 . PO D S TA W Y X M L S C H E M A Z W IĄ Z A N E Z W S D L

397

Definiuje typy danych i strukturę ładunku użytecznego dla SOAP

XML Schema

\

Definiuje typy danych dla

Więżę się z

WSDL

Rysunek 13.2. Trzy podstawowe specyfikacje związane z projektowaniem usług

Czytelnicy znający języki WSDL, SOAP i XML Schema mogą ten skrócony opis z powodze­ niem pominąć. PODSUMOW ANIE •

Przed rozpoczęciem właściwego projektowania usług konieczne jest podjęcie kluczowych decyzji dotyczących warstw usług oraz zbioru przemysłowych specyfikacji, na podstawie których budowana będzie SOA. Tematyka ta jest treścią rozdziału 14.

•

Podstawowym zadaniem etapu projektowania jest transformacja wymodelowanych uprzednio kandydatur na usługi na fizyczne projekty usług. Procesy projektowania opisywane są krok po kroku w rozdziale 15.

•

Do powiązania projektowanych usług w spójną jednostkę logiki przetwarzania konieczna jest agnostyczna implementacyjnie definicja przepływu pracy. W rozdziale 16. opisujemy wykonanie tego zadania za pomocą języka WS-BPEL.

1 3 .2 . P o d s ta w y X M L S c h em a z w ią z a n e z W S D L Język XM L Schema Definition Language, w skrócie XSD, stał się centralną i najczęściej wykorzy­ stywaną częścią standardu XML i architektury usług sieciowych. Hierarchiczną strukturę doku­ m entów XML m ożna formalnie definiować, tworząc schematy XSD — w tym rozum ieniu doku­ m ent XML może być uważany za instancję odpowiadającego m u schematu. Ponadto struktura ustanawiana przez schemat XSD (której przykład widzimy na rysunku 13.3) zawiera szereg reguł i ograniczeń, do których musi stosować się odnośny dokum ent XML, by mógł zostać uznany za popraw ny przez przetwarzające go parsery i procesory. Fundam entalne reguły reprezentowania danych dostarczane przez schematy XSD opierają się na typach danych: tak jak typy danych w językach program ow ania podlegają regułom składni i semantyki tych języków, tak schematy XSD dostarczają zbiór predefiniowanych typów danych wykorzystywanych do reprezentowania informacji w instancjach dokum entów XML. Zbiór typów danych obsługiwanych przez XSD jest rozszerzalny, lecz niekoniecznie w sposób typowy dla definiowania nowych typów użytkownika w językach programowania. W wielu zatem środowiskach konieczne jest dokonanie swoistego mapowania danych, o typach specyficznych dla konkretnych aplikacji czy źródeł, na jak najlepiej odpowiadające im typy zgodne z regułami XSD.

398

R O ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Schemat XSD

«element > «sequence» «element .../> «element .../> «element .../> «/sequence» «/complexType» «/element» «/schema»

Rysunek 13.3. Przykładowy schemat XSD

Schematy XSD mogą istnieć albo w formie osobnych dokum entów (zazwyczaj plików *.xsd), albo w postaci wbudowanej w inne dokumenty, na przykład instancje dokum entów XML lub de­ finicje WSDL. Instancje dokum entów XML zawierają zwykle odsyłacze („linki”) do odnośnych dokum entów XSD, tak więc jedna definicja XSD może być w spółdzielona przez wiele instancji wspomnianych dokumentów. Definicje WSDL mogą importować treść plików *.xsd albo zawie­ rać schematy XSD wbudowane w jawnej postaci (inline). Ponieważ prawie wszystkie specyfikacje związane z XML i usługami sieciowymi same napisane są w języku XML, schem aty XSD stały się naturalną częścią reprezentacji danych w postaci XML i architektur zorientowanych na usługi. Niezależnie od tego, czy schemat XSD definiowany jest specjalnie na potrzeby konkretnego rozwiązania, czy też nie, procesor przetwarzający dokumenty XML na potrzeby usług sieciowych i tak zapewne funkcjonow ał będzie w kontekście jakiegoś schematu XSD. (Rola schematów XSD w ramach SOA wyjaśniona jest dokładniej w punkcie 14.3.5, „Schematy XML a SOA”). „Elementy” a „konstrukcje” Każda ze specyfikacji, które omawiać będziemy w tym i następnych rozdziałach, definiuje pewien język znaczników stanowiący dialekt języka XML. Oznacza to, że składnia każdego takiego języka opiera się na elementach języka XML, a więc elementy te istotne są z perspektywy wspomnianych rozdziałów. Niekiedy będziemy używać term inu konstrukcje na określenie elementów języka: konstrukcją jest kluczowy element złożony, czyli element „rodzicielski” powiązany z serią doku­ m entów „potom nych”. Użycie tego term inu m a więc oznaczać, że omawiany właśnie element może zawierać inne elementy, tworzące blok XML.

1 3 .2 . PO D S TA W Y X M L S C H E M A Z W IĄ Z A N E Z W S D L

399

13.2.1. Element schema Element schema jest korzeniem (root) każdego schematu XSD. Jest on opatrzony serią atrybutów wykorzystywanych przede wszystkim do ustanawiania związków z przestrzeniami nazw (nam e­ spaces). Przykładowo atrybut xmlns specyfikuje domyślną przestrzeń nazw albo wykorzystywany jest do deklarowania prefiksu kwalifikującego przynależność innych elementów schem atu do określonej przestrzeni nazw. Przestrzeń nazw http://www.w3.org/2001/XMLSchema jest zawsze dostępna, więc m ożna ją wy­ korzystywać do reprezentowania treści schematów wywodzących się ze specyfikacji XSD oraz elementów tych schematów. Umożliwia to procesorom odróżnianie treści natywnych schematów od treści definiowanych przez użytkowników. Przykład 13.1. Najbardziej podstawowa forma deklarowania schematu

Spośród inny ważnych atrybutów elementu schema wymienić należy targetNamespace, wyko­ rzystywany do przyporządkow ania przestrzeni nazw elem entom i atrybutom deklarowanym w dokumencie schematu, a także elementFormDefault — gdy ten ma wartość q u alifie d ; dla każ­ dego elem entu w dokum encie XML wymagane jest jawne („kwalifikowane”) określenie prze­ strzeni nazw.

13.2.2. Element element Za pom ocą tego elementu użytkownik może deklarować elementy, do których m ożna odwoływać się za pom ocą nazw w instancji dokum entu XML — na przykład: Przykład 13.2. Przykładowa deklaracja elementu w schemacie XSD < e le m e n t n a m e = "N u m e rF a ktu ry" t y p e = " x s d : i n t e g e r " / >

W instancji dokum entu XML odwołanie do zadeklarowanego elementu m a postać: Przykład 13.3. Odwołanie do zadeklarowanego elementu w instancji dokumentu XML < N u m e rF a k tu ry > 1 2 3 4 5 < /N u m e rF a k tu ry>

Zgodnie z atrybutem type="xsd:integer", w deklaracji elementu wymaga się, by jego wartość (tu 12345) miała postać liczby całkowitej. Atrybut ten może określać jeden z predefiniowanych typów XML Schema albo typ złożony (co wkrótce dokładniej wyjaśnimy).

13.2.3. Elementy complexType i simpleType Element complexType umożliwia grupowanie elementów i atrybutów w typy złożone, wykorzy­ stywane do reprezentowania zbiorów powiązanych danych. W poniższym przykładzie dwa ele­ m enty o nazwie ID i TygodniowyLimitGodzin grupowane są w typ złożony GodzinyPracownika.

400

RO ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Przykład 13.4. Element complexType grupujący deklaracje dwóch innych elementów < complexType n a m e = " G o d z i n y P r a c o w n i k a " > < e le m e n t n a m e = "ID " t y p e = " x s d : i n t e g e r " / > < e le m e n t n a m e = " T y g o d n io w y L im itG o d z in " t y p e = " x s d : s h o r t " / > < /compl exType >

Zadeklarowany typ złożony GodzinyPracownika może być przypisywany wielu deklarowanym elementom. Umożliwia to unikanie wielokrotnego powtarzania tej samej deklaracji, sprzyja więc standaryzacji i unikaniu redundancji. Element w deklaracji typu złożonego oznacza wymaganie, by wartości poszczególnych składowych tego typu (w instancji dokum entu XML) wystąpiły w ściśle określonej kolejności. Element simpleType także umożliwia grupowanie powiązanych danych, nie może jednak za­ wierać atrybutów lub zagnieżdżonych typów złożonych (żaden z prezentowanych w tej książce przykładów nie zawiera elementu simpleType).

13.2.4. Elementy import i include Dokum enty XSD mogą być modularyzowane: treść jednego dokum entu może być importowana do innych dokumentów. Oba elementy wymienione w tytule używane są do wskazywania lokali­ zacji pliku im portow anego dokum entu XSD, którego zawartość „wciągana” jest do dokum entu nadrzędnego w trakcie jego przetwarzania. Przykład 13.5. Elementy import i include
...>

nam espace="h t t p : // w w w .x m lt c . c o m / tls / s c h e m a " / > < include s c h e m a L o c a t i o n = " . . . " / >

Różnica między tytułowymi elementami jest taka, że element include umożliwia importowanie dokum entów jedynie z tej przestrzeni nazw, która przypisana jest do dokum entu nadrzędnego, podczas gdy za pom ocą elementu import można importować dokumenty także z innych prze­ strzeni nazw. Atrybut namespace nie może więc wystąpić wewnątrz elementu include.

13.2.5. Inne ważne elementy XML Schema Definition Language to język obszerny i skomplikowany, dostarczający wielu opcji dla strukturalizowania i walidacji danych dokum entów XML. Zawiera wiele istotnych części nieprezentowanych w przykładach tej książki, między innymi: • dodatkowe elementy definicji typów ( a ttrib u te , complexContent, simpleContent), • elementy związane z ograniczeniami (r e s tr ic tio n , enumeration, p attern ), • indykatory elementów (maxOccurs, minOccurs, group), • elementy związane z rozszerzalnością (any, extension, redefine), • elementy symulujące relacje między elementami (unique, key, keyref).

1 3 .3 . P O D S TA W Y JĘZYKA W S D L

40 1

Na tem at języka XML Schema Definition Language napisano wiele książek; listę polecanych źródeł znajdą czytelnicy pod adresem www.serviceoriented.ws. PODSUMOW ANIE •

Język XML Schema Definition Language stanowi organiczną część standardu XML i specyfikacji usług sieciowych, jest także kluczem do definiowania interfejsów usług sieciowych jako nieodłącznej części procesu projektowania tych usług.

•

Schematy XSD mogą być importowane do definicji WSDL lub osadzane w tych definicjach.

1 3 .3 . P o d s ta w y ję z y k a W S D L Język WSDL ( Web Services Description Language — język opisywania usług sieciowych) jest chyba najbardziej fundamentalnym standardem technologicznym skojarzonym z projektowaniem usług. Jak okaże się to oczywiste przy lekturze następnych rozdziałów, definicje WSDL są centralną częścią wszystkich aspektów tego projektowania. W rozdziale 5. opisaliśmy pokrótce strukturę doku­ m entu WSDL, w szczególności jej podział na części abstrakcyjną i skonkretyzowaną. Dla przypomnienia — część abstrakcyjna zawiera serię elementów związanych z typem portu (interfejsem), operacjami i komunikatami, podczas gdy część skonkretyzowana łączy się z wiązaniem, portem (punktem końcowym-lokalizacją) i usługą (rozumianą jako zbiór punktów końcowych). Każda z wymienionych części odpowiada elementowi XSD wchodzącemu w skład definicji WSDL (patrz rysunek 13.4). W kolejnych punktach opiszemy teraz składniową implementację tych elementów, jako że są one istotne dla większości analiz przypadków (prezentowanych w rozdziale 15.) demonstrujących definiowanie interfejsów usług. (Związki między WSDL i SOA omówione zostaną oddzielnie w punkcie 14.3.4, „WSDL a SOA”).

Część abstrakcyjna

Część skonkretyzowana

Rysunek 13.4. Struktura definicji WSDL

402

R O ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

13.3.1. Element definitions To korzeń (root) każdego dokum entu WSDL, nadrzędny w stosunku do innych elementów defi­ nicji i ustalający lokalizację przestrzeni nazw powoływanych w treści w dokumentu. Przykład 13.6. Element definitions usługi Pracownik z licznymi deklaracjami przestrzeni nazw < d e fin itio n s n a m e = " P r a c o w n i k " targ e tN a m e sp a ce = "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /w s d l/ " x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o r g /w s d l/" x m ln s :a c t= "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /s c h e m a /a c c o u n tin g /" x m ln s :h r= "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /s c h e m a /h r/" x m ln s :s o a p = "h ttp ://s c h e m a s .x m ls o a p .o rg /w s d l/s o a p /" x m ln s :tn s = "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /w s d l/ " x m ln s : x s d = " h ttp ://w w w .w 3 .o r g /2 0 0 1 /X M L S c h e m a "> < / d e fin itio n s >

Element d e fin itio n s widoczny w przykładzie 13.6 nadaje nazwę usłudze (Pracownik) i po­ wołuje liczne przestrzenie nazw, wykorzystywane w definicji WSDL tej usługi. Przykładowo atrybut xmlns ustanawia domyślną przestrzeń nazw jako http://schemas.xmlsoap.org/wsdl/, dzięki czemu wszystkie elementy języka WSDL nie muszą być prefiksowane (kwalifikowane) w celu wykazania ich związku ze specyfikacją WSDL. Za sprawą deklaracji xmlns:xsd=... wszystkie elementy należące do języka XSD muszą być pre­ fiksowane kwalifikatorem xsd:. Zwróćmy także uwagę na deklaracje xmlns:act=... i xmlns:hr=...: służą one rozróżnieniu dwóch różnych schematów im portowanych w ram ach konstrukcji types. Deklaracja przestrzeni nazw xmlns:soap=... ustanawia kwalifikator soap: dla elementów wpro­ wadzanych w konstrukcji bindings, gdzie abstrakcyjne definicje operacji wiązane są z (konkretnym) protokołem SOAP.

13.3.2. Element types W konstrukcjach types lokowane są treści schematów XSD bądź to w postaci osadzonej (ele­ m enty schema), bądź też w formie importowanej (element import) z zewnętrznych dokum entów (w jednym dokumencie WSDL mogą występować obie te formy). Jak widać na rysunku 13.5, typy definiowane w tej części definicji WSDL wykorzystywane są do reprezentowania treści (w formacie XML) ciała komunikatów. Elementy message (o nich za chwilę) zawierają odwołania do tych typów i wiążą je z komunikatami. Ciało kom unikatu SOAP zawiera treść w formacie XML, która reprezentować może dosłow­ nie wszystko — od prostego param etru do skomplikowanych dokum entów biznesowych. Treść może być formalnie definiowana za pom ocą typów specyfikowanych w obszarze elementu types. Najczęściej więc spotkać tu m ożna elementy complexType, grupujące zbiory powiązanych ze sobą typów, reprezentujące kompletne struktury ciała komunikatów. W poniższym przykładzie element types zawiera pojedynczy osadzony schemat XSD.

1 3 .3 . P O D S TA W Y JĘZYKA W S D L

403

Scher definiuj w rannacn konstrukcji types

Schemat XSD

Konstrukcje message definiują abstrakcyjne komunikaty

Komunikat

Rysunek 13.5. Konstrukcje WSDL types generowane przez schematy XSD, wykorzystywane przez konstrukcje message do reprezentowania ciała komunikatu SOAP Przykład 13.7. Konstrukcja types z osadzoną konstrukcją schema, w ramach której definiowany jest typ złożony (complexType) < types > < c o m p le xT y p e na m e = "T yp K o d u P o w ro tu "> < e le m e n t nam e="Kod" t y p e = " x s d : i n t e g e r " / > < e le m e n t n a m e = "K o m u n ik a t" t y p e = " x s d : s t r i n g " / > < /c o m p le x T y p e > < / types >

Używanie konstrukcji types jest powszechne w definicjach WSDL o dużych rozmiarach, lecz nie jest obowiązkowe. Do natywnych typów XSD m ożna się odwoływać z elementu message bez­ pośrednio, co niebawem bliżej wyjaśnimy.

13.3.3. Elementy message i part Każdy kom unikat, który wysyłać lub odbierać m a opisywana przez WSDL usługa, koniecznie musi zawierać konstrukcję message. Przyporządkowuje ona kom unikatowi nazwę i zawiera jeden lub wiele elementów potomnych part, przypisujących typy poszczególnym częściom komunikatu. Elementy message kojarzone są z elementami operation w celu powiązania wejściowych i wyj­ ściowych kom unikatów z poszczególnymi operacjami.

404

R O ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Odpowiedni typ specyfikowany jest przez element p art za pomocą jednego z atrybutów type albo element. Atrybut type może określać typ prosty lub złożony i generalnie stosowany jest do kom unikatów w stylu RPC; dla kom unikatów w stylu dokumentowym elementy p art wykorzy­ stują zazwyczaj atrybut element, odwołujący się do elementu element schematu XSD (przeczytaj to jeszcze raz uważnie). Poszczególne części kom unikatu opatrywane są nazwami za pom ocą atrybutu name elementów p a rt; nazwy te muszą być unikatowe dla każdego elementu p art w ra­ m ach tej samej konstrukcji message. W poniższym przykładzie definiowane są dwa kom unikaty — żądanie i odpowiedź — przy użyciu dwóch konstrukcji message. Każda z nich zawiera jeden element p a rt określający typ za pomocą atrybutu element. Przykład 13.8. Dwie konstrukcje message, definiujące prawdopodobnie wyjściowy i wejściowy komunikat dla operacji < message n a m e = " g e t E m p l o y e e W e e k l y H o u r s R e q u e s t M e s s a g e " > < p a rt n a m e = " R e q u e s t P a r a m e t e r " e le m e n t= "a c t:E m p lo y e e H o u rs R e q u e s tT y p e "/> < / message> < message n a m e = " g e t E m p l o y e e W e e k l y H o u r s R e s p o n s e M e s s a g e " > < p a rt n a m e = " R e s p o n s e P a r a m e t e r " e le m e n t= "a ct:E m p lo y e e H o u rs R e sp o n se T yp e "/> < / message>

W poniższym przykładzie typ części komunikatu określany jest natomiast w sposób bezpośredni. Przykład 13.9. Prosty parametr komunikatu, określany za pomocą jednej liczby całkowitej < p a r t typ e="xsd :in teg e r" / >

Jeśli wszystkim komunikatom w definicji WSDL przyporządkowywane są natywne (proste) typy XSD (jak w przykładzie 13.9), to osobne konstrukcje types nie są w tej definicji w ogóle potrzebne.

13.3.4. Elementy portType, interface i operation W obszarze portType definicji WSDL definiowane są operacje usługi — konstrukcja portType jest kolekcją konstrukcji operation, z których każda, odpowiednio nazwana, jest definicją jednej operacji. Przykład 13.10. Konstrukcja portType hostująca dwie konstrukcje operation < portType n a m e = " E m p l o y e e I n t e r f a c e " > < operation n a m e = " P o d a j T y g o d n i o w y L i m i t G o d z i n " > < / operatio n > < operation n a m e = " A k t u a l i z u j H i s t o r i e " > < / operatio n > < / portType >

Element portType definiowany jest w wersji 1.1 specyfikacji WSDL, wersja 2.0 zmienia nazwę tego elementu na in terface. W prezentowanych przykładach zachowujemy zgodność ze starszą wersją i konsekwentnie używamy elementu portType.

1 3 .3 . P O D S TA W Y JĘZYKA W S D L

405

13.3.5. Elementy input i output (jako potomne elementu operation) Każda konstrukcja operation zawiera elementy potom ne input i (lub) output reprezentujące komunikaty-żądania i komunikaty-odpowiedzi, jakie usługa zdolna jest przetwarzać. W poniższym przykładzie każda operacja skojarzona jest z jedną parą takich elementów. Każdemu z nich za pomocą atrybutu message przyporządkowany został konkretny komunikat. Przykład 13.11. Elementy operation z potomnymi elementami input i output < o p e r a t io n n a m e = "P o d a jT y g o d n io w y L im itG o d z in "> < in put m e s s a g e = " t n s : g e t W e e k l y H o u r s R e q u e s t M e s s a g e " / > < output m e s s a g e = " t n s : g e t W e e k l y H o u r s R e s p o n s e M e s s a g e " / > < /o p e ra tio n > < o p e ra tio n n a m e = " A k tu a liz u jH is to rie " > < in put m e s s a g e = " t n s : u p d a t e H i s t o r y R e q u e s t M e s s a g e " / > < output m e s s a g e = " t n s : u p d a t e H i s t o r y R e s p o n s e M e s s a g e " / > < /o p e ra tio n >

Jak pisaliśmy w rozdziale 6., WSDL zapewnia obsługę predefiniowanych wzorców wymiany kom unikatów (MEP). Obecność elementów input i output oraz kolejność, w jakiej występują wewnątrz konstrukcji operation, to czynniki w zasadzie determ inujące MEP dla danej operacji. W przykładzie 13.11 ewidentnie mamy dwukrotnie do czynienia z wzorcem „żądanie-odpowiedź”. Dla odmiany, posiadanie przez element operation tylko pojedynczego elementu input jest ob­ razem wzorca komunikacji jednokierunkowej. Przykład 13.12. Element operation z jednym elementem potomnym input < o p e r a t io n nam e="W ystaw "> < in put m e s s a g e = " t n s : r e c e i v e S u b m i t M e s s a g e " / > < /o p e ra tio n >

UWAGA W pierwszej chwili może się wydawać mylące kojarzenie wzorca „żądanie-odpowiedź" z sekwencją ele­ mentów input i output (w tej kolejności), ponieważ intuicyjnie „żądanie" kojarzy się z inicjowaniem komuni­ kacji przez usługę, czyli z elementem o utput , nie in p u t . Otóż, nie należy zapominać, że definicja WSDL usługi wyraża interfejs tej usługi z pozycji jej roli jako dostarczyciela, nie wnioskodawcy. Z tej perspektywy wzorzec „żądanie-odpowiedź" oznacza najpierw odebranie żądania, a następnie wysłanie odpowiedzi.

13.3.6. Element binding Wszystkie opisywane dotąd elementy definicji WSDL to elementy należące do jej części abstrak­ cyjnej. Kolektywnie opisują one interfejs usługi, lecz bez jakiegokolwiek związku z konkretną technologią komunikacyjną. Element binding rozpoczyna część skonkretyzowaną definicji WSDL. Specyfikuje protokół kom unikacyjny zapewniający interakcję z usługą i dostęp do jej opisu. Na pierwszy rzut oka element binding może wydawać się podobny w strukturze do elementu portType, bo podobnie jak on zawiera jeden lub wiele elementów operation. Spoglądając jednak na treść przykładu 13.13, zauważyć można dodatkowe elementy soap:binding i soap:operation — to wła­ śnie one ustanawiają protokół SOAP jako środek komunikacji z definicją WSDL (i generalnie z usługą).

406

RO ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Przykład 13.13. Konstrukcja binding hostująca skonkretyzowane opisy operacji < binding n a m e = " E m p l o y e e B i n d i n g " t y p e = " t n s : E m p l o y e e I n t e r f a c e " > < soap:binding s t y l e = " d o c u m e n t " tra n s p o rt= " h ttp ://s c h e m a s .x m ls o a p .o rg /s o a p /h ttp "/> < o p e r a t io n n a m e = "P o d a jT y g o d n io w y L im itG o d z in "> < soap:operation s o a p A c t i o n = " . . . " / > < /o p e ra tio n > < o p e ra tio n n a m e = " A k tu a liz u jH is to rie " > < soap:operation s o a p A c t i o n = " . . . " / > < /o p e ra tio n > < / binding >

Atrybut s ty le elementu soap:binding określa sposób formatowania kom unikatów związanych z operacją, zależny od stylu tych komunikatów. Wartość "document" oznacza komunikaty w stylu do­ kumentowym, których ciało zawiera w pełni definiowalną strukturę dokum entu XML. W artość "rpc" wymaga zgodności ciała komunikatu ze strukturą definiowaną w specyfikacji SOAP, zgodnie z którą (między innymi) korzeń tej struktury musi mieć nazwę zgodną z nazwą operacji.

13.3.7. Elementy input i output (jako potomne elementu binding) Każdy element operation wewnątrz konstrukcji binding pełni rolę podobną do elementów po­ tomnych o tej samej nazwie w abstrakcyjnej części definicji. Jednakże wewnątrz konstrukcji binding elementy input i output nie odwołują się ponownie do elementów message, specyfikują natomiast szczegóły protokołu odpowiedzialne za sposób interpretowania i przetwarzania komunikatów na gruncie wybranej technologii komunikacyjnej. W poniższym przykładzie interfejs usługi powiązany zostaje z protokołem SOAP. Przykład 13.14. Elementy input i output dostarczające informacje o sposobie przetwarzania komunikatów < o p e r a t io n n a m e = "P o d a jT y g o d n io w y L im itG o d z in "> < s o a p :o p e ra tio n s o a p A c tio n = " ..." /> < in p u t > < soap:body u s e = " l i t e r a l " / > < / in p u t > < output > < soap:body u s e = " l i t e r a l " / > < / output > < /o p e ra tio n > < o p e ra tio n n a m e = " A k tu a liz u jH is to rie " > < s o a p :o p e ra tio n s o a p A c tio n = " ..." /> < in p u t > < soap:body u s e = " l i t e r a l " / > < / in p u t > < output > < soap:body u s e = " l i t e r a l " / > < / output > < /o p e ra tio n >

1 3 .3 . P O D S TA W Y JĘZYKA W S D L

407

W powyższym przykładzie wykorzystywany jest element soap:body języka SOAP, definiujący, poprzez atrybut use, typ przetwarzania danych przez procesory SOAP. Dopuszczalnymi warto­ ściami atrybutu use są "encoding" i " l it e r a l" .

UWAGA Znaczenie wymienionych wartości dla przetwarzania komunikatów SOAP opisujemy dokładniej w punkcie 14.3.4, „WSDL a SOA".

13.3.8. Elementy service, port i endpoint Element serv ice dostarcza po prostu informacje o fizycznej lokalizacji (adresie) usługi; dokład­ niej, informację tę specyfikuje hostowany element port. Przykład 13.15. Elementy service i port ustanawiające fizyczny adres usługi < service n a m e = " E m p l o y e e S e r v i c e " > < p o rt b i n d i n g = " t n s : E m p l o y e e B i n d i n g "

n a m e = "E m p lo ye e P o rt">

< s o a p :a d d re ss lo c a tio n = "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /"/> < / p o rt > < / se rv ic e >

Ponieważ w powyższym przykładzie usługa powiązana jest z protokołem SOAP, element p o rt zaw iera p o to m n y elem ent so a p :a d d re ss, którego atrybut lo c a tio n wskazuje fizyczną lokalizację usługi. W wersji 2.0 specyfikacji WSDL elem ent p o rt zastąpiony został przez ele­ m ent endpoint.

13.3.9. Element import Definicje WSDL oferują formę modularności, podobną do tej ze schematów XSD. Element import umożliwia importowanie zarówno innych definicji WSDL, jak i schematów XSD. Przykład 13.16. Element import odwołujący się do schematu XSD < import n a m e s p a c e = " h t t p : / / w w w . x m l t c . c o m / t l s / s c h e m a s / " lo c a tio n = " h ttp ://w w w .x m ltc .c o m /tls /s c h e m a s /e m p lo y e e .x s d "/>

UWAGA O modularyzacji definicji WSDL, możliwej między innymi dzięki importowaniu treści, piszemy w punkcie 15.5.5, „Rozważ modularyzację dokumentów WSDL".

408

R O ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

1 3 .3 .1 0 .

E le m e n t d o c u m e n ta tio n

Ten opcjonalny element umożliwia umieszczanie wewnątrz definicji WSDL czytelnych dla czło­ wieka, opisowych komentarzy. Informacja taka jest użyteczna dla program istów i projektantów opracowujących usługi-wnioskodawców, może być też interpretow ana w sposób program owy przez rejestry usług, które dzięki tem u odnajdywać m ogą żądane usługi w bardziej precyzyjny sposób. Przykład 1 3 .17 . Element documentation zawierający ogólny opis interfejsu usługi < p o rtT y p e n a m e = "T ra n s fo rm In te rfa c e "> < documentation > O d b i e r a d o k u m e n t w f o r m a c i e XML i

k o n w e r t u j e go

na fo r m a t n a ty w n y d l a s y ste m u fin a n s o w o - k s ię g o w e g o . < / documentation > < /p o rtT yp e >

P O D S U M O W A N IE

•

Język WSDL jest kluczowym mechanizmem projektowania usług, ponieważ służy do opisywania abstrakcyjnych i konkretnych aspektów interfejsów tych usług.

•

Definicja WSDL hostuje wiele konstrukcji potomnych, związanych z abstrakcyjną i skonkretyzowaną częścią opisu usługi.

1 3 .4 . P o d s ta w y ję z y k a SOAP Jak wiadomo, w definicji WSDL celowo odseparowano abstrakcyjny aspekt usługi od szczegółów jej skonkretyzowanego opisu. Jednym z pożytków płynących z tej separacji jest możliwość od­ dzielenia protokołu komunikacyjnego wymaganego przez usługę od jej abstrakcyjnego interfejsu. Ponieważ jednak SOAP jest komunikacyjnym „protokołem z wyboru” dla SOA, interfejsy te naj­ częściej wiązane są z tym właśnie protokołem. W procesie projektowania zorientowanego na usługi przywiązuje się dużą wagę do staranno­ ści opracowywania zarówno definicji WSDL, jak i wymaganych schematów XSD. Komunikaty SOAP nie wymagają zwykle aż tak wielkiego skupienia uwagi. Szczegółami składni języka SOAP zajmiemy się w rozdziale 17., gdzie analizować będziemy rozszerzenia WS-* i sposób ich im ple­ m entow ania w nagłówkach protokołu SOAP; teraz ograniczymy się do przedstawienia jedynie najważniejszych szczegółów tego języka. Strukturę kom unikatu SOAP, niezbyt skomplikowaną, opisywaliśmy w rozdziale 5. Składa się ona z nagłówka (header), ciała (body) i sekcji usterek (fault), wszystko to zam knięte w kopercie (envelope). W ym ienione części odzwierciedlane są przez elementy o odpow iednich nazwach — Envelope, Header, Body i Fault, tak jak na rysunku 13.6. (Wpływem SOA na sposób wykorzysty­ wania możliwości protokołu SOAP zajmujemy się w punkcie 14.3.6, „SOAP a SOA”.

1 3 .4 . P O D S TA W Y JĘZYKA SOAP

409

A

Koperta SOAP

U

Rysunek 13.6. Struktura dokumentu komunikatu SOAP

1 3 .4 .1 .

E le m e n t E n v e lo p e

Element Envelope, stanowiący analogię koperty SOAP, jest korzeniem (root) struktury kom uni­ katu SOAP. Zawiera obowiązkowo element potom ny Body, będący ciałem kom unikatu, i opcjo­ nalnie element Header, będący nagłówkiem tego komunikatu. Przykład 13.18. Korzeń Envelope hostujący konstrukcje Header i Body < Envelope x m l n s = " h t t p : / / s c h e m a s . x m l s o a p . o r g / s o a p / e n v e l o p e / " > < H eader> < /H ead er> < / Envelope >

1 3 .4 .2 .

E le m e n t H e a d e r

Jak pisaliśmy w rozdziale 5., to właśnie nagłówki kom unikatu SOAP umożliwiają im plem ento­ wanie rozszerzeń wprowadzanych przez specyfikacje WS-*. Większość z tych rozszerzeń jest im ­ plementowana na poziomie komunikatów, w postaci standardowych bloków przeznaczonych do wbudowywania w konstrukcję Header.

410

RO ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Przykład 13.19. Konstrukcja Header hostująca blok nagłówkowy komunikatu SOAP < Header > < x :C o rre la tio n ID x m ln s :x = "h ttp ://w w w .x m ltc .c o m /tls /h e a d e rs a m p le /" m u stU n d e rs ta n d = "1 "> 0 1 31858580-JD J903K D < /x :C o rre la tio n ID > < / Header>

Bloki nagłówka SOAP mogą być konfigurowane: w przykładzie 13.19 w nagłówku SOAP hostowany jest element CorrelationID. W artość "1" atrybutu mustUnderstand oznacza wymaganie, by zawartość nagłówka była zrozumiała dla każdego odbiorcy komunikatu, od którego to odbiorcy oczekuje się przetworzenia tegoż nagłówka. Gdy w spomniany atrybut ma wartość "0", przetwo­ rzenie bloku nagłówka jest opcjonalne — odbiorca nierozpoznający tego bloku może go zignorować bez sygnalizowania błędu.

1 3 .4 .3 .

E le m e n t B o d y

To jedyny wymagany elem ent potom ny konstrukcji Envelope, zawierający ciało kom unikatu w postaci dobrze uformowanego (well-formed) dokum entu XML. Struktura i konwencje nazewnicze tego elem entu uzależnione są od wartości atrybutów s ty le i use, o czym pisaliśmy już w punktach 13.3.6 i 13.3.7 przy okazji opisywania elem entu binding. Konstrukcje Body dla komunikatów SOAP definiowane są wewnątrz konstrukcji message od­ wołujących się (o czym też już pisaliśmy) do schematów XSD określających typy danych w ramach konstrukcji types (co schematycznie pokazano na rysunku 13.7).

Rysunek 13.7. Ciało komunikatu SOAP definiowane (jako element Body) wewnątrz konstrukcji message w definicji WSDL. Szczegóły przetwarzania komunikatu SOAP przez wybrany protokół komunikacyjny definiowane są w skonkretyzowanej części definicji WSDL

1 3 .4 . P O D S TA W Y JĘZYKA SOAP

41 1

Przykład 13.20. Postać przykładowej konstrukcji Body < Body> < s o a :b o o k x m ln s : s o a = " h t t p : / / w w w . s e r v i c e o r i e n t e d . w s / "> < s o a :IS B N > 0131858580 < /s o a :IS B N > < s o a :title > S e rv ic e -O rie n te d A rc h ite c tu re C o n c e p ts , T e c h n o lo g y , and D e s ig n < /s o a :title > < /s o a :b o o k > < / Body>

O ile m o ż liw a je s t c z y n n a in g e r e n c ja w n a g łó w k i k o m u n ik a t u S O A P n a tra s ie je g o p r z e t w a ­ r z a n ia , to je g o c ia ła n ie p o w in n o się m o d y f ik o w a ć . U s łu g i p o ś r e d n ic z ą c e m o g ą n a to m ia s t o d c z y ­ ty w a ć i w y k o r z y s ty w a ć in f o r m a c ję z a w a r tą w t y m c ie le — w p r z y k ła d z ie 1 3 .2 0 n u m e r IS B N k s ią ż ­ k i r e p r e z e n t o w a n e j w c ie le k o m u n ik a t u m o ż e b y ć w y k o r z y s ty w a n y p r z e z w s p o m n ia n e u s łu g i ja k o ź r ó d ło d o g e n e r o w a n ia id e n t y f ik a t o r a k o r e la c ji.

1 3 .4 . 4 . E le m e n t F a u lt O p c jo n a ln a k o n s t r u k c ja

Fault d o s ta r c z a g o to w e ś r o d k i d o r e a g o w a n ia n a b łę d n e s y tu a c je , d e f i­

n io w a n e w p r o s t w c ie le k o m u n ik a t u . Ja k w id a ć n a p o n iż s z y m p r z y k ła d z ie , k o n s tr u k c ja ta p o s ia d a s w ą w e w n ę t r z n ą s tr u k tu r ę — i t a k e le m e n t fik a c ji S O A P p r z y c z y n b łę d u , zaś e le m e n ty w y ja ś n ie n ie te j p r z y c z y n y . E le m e n t

faultcode o k re ś la je d n ą z p r e d e f in io w a n y c h w s p e c y ­ faul ts tr in g i d etail d o s ta rc z a ją c z y te ln e d la c z ło w ie k a

d e ta il m o ż e p o n a d to h o s to w a ć fr a g m e n t k o d u X M L p r e z e n tu ­

ją c y s z c z e g ó ły b łę d u w p o s ta c i s t r u k tu r a ln e j.

Przykład 13.21. Konstrukcja Fault rezydująca wewnątrz konstrukcji Body < F a u lt > < fa u ltc o d e > M u stU n d e rs ta n d < /fa u ltc o d e > < fa u lts trin g > n ie ro z p o z n a n o n a g łó w ka < /fa u lts trin g > < d e ta il> < x :a p p M e s sa g e x m l n s : x = " h t t p : / / w w w . x m l t c . c o m / t l s / f a u l t s "> N a g łó w e k C o r r e l a t i o n I D n i e z o s t a ł r o z p o z n a n y p r z e z o d b i o r c ę z o b o w i ą z a n e g o do j e g o p r z e t w o r z e n i a . W y g e n e r o w a n y z o s t a ł w y j ą t e k s y g n a liz u ją c y praw dopodobne p ro b le m y z fu n k cjo n o w a n ie m te g o o d b io r c y . < /d e ta il> < / F a u lt > < /B o d y>

W id o c z n a w tre ś c i p r z y k ła d u 1 3 .2 1 k o n s tr u k c ja

Fault o d z w ie r c ie d la n ie m o ż n o ś ć p r z e t w o r z e ­ "1"

n ia n a g łó w k a S O A P p r z e z u s łu g ę , o d k tó r e j p r z e t w o r z e n ia te g o się w y m a g a ( p o p r z e z w a r to ś ć a try b u tu

mustUnderstand ).

412

R O ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

P O D S U M O W A N IE

• SOAP to podstawowy standard definiowania komunikatów na potrzeby wymiany informacji między usługami. • Większość cech opisywanych przez rozszerzenia WS-* implementowana jest za pomocą nagłówków komunikatów SOAP. • Dokument komunikatu SOAP ma postać konstrukcji Envelope hostującej obowiązkową konstrukcję Body oraz opcjonalne konstrukcje Header i Fault.

1 3 .5 . N a rz ę d z ia d o p ro je k to w a n ia in te rfe js ó w usług W s k o m p lik o w a n y m d z ie le t w o r z e n ia u s łu g s ie c io w y c h fa z a p r o je k t o w a n ia s ta n o w i p ie r w s z e z e ­ tk n ię c ie p r o je k t a n t ó w i p r o g r a m is t ó w z r z e c z y w is ty m i t e c h n o lo g ia m i. I m i m o że w c ią ż n ie m a m y je s z c z e d o c z y n ie n ia z r e a ln y m p r o g r a m o w a n ie m , o p r a c o w y w a n ie fiz y c z n y c h in te r fe js ó w u s łu g s t a n o w i j u ż je g o n a m ia s tk ę . W ś r ó d te c h n o lo g ii p r z y d a t n y c h n a t y m e ta p ie b e z w z g lę d n ie w y m ie n ić n a le ż y W S D L i X S D . W k o le jn y c h p u n k t a c h o p is z e m y t r z y r ó ż n e , n a jc z ę ś c ie j s p o ty k a n e , p o d e jś c ia d o w y k o r z y s ty w a n ia ty c h ję z y k ó w .

1 3 .5 .1 . A u to m a ty c z n e g e n e r o w a n ie Is t n ie ją n a r z ę d z ia a u to m a ty c z n ie g e n e r u ją c e d e fin ic je W S D L i s c h e m a ty X S D n a p o d s ta w ie o k r e ­ ś lo n y c h ź r ó d e ł, n a p r z y k ła d d e fin ic ji k la s k o m p o n e n t ó w . T e c h n ik a ta je s t s z c z e g ó ln ie p r z y d a t n a ja k o ś r o d e k e fe k ty w n e g o g e n e r o w a n ia in te r fe js ó w u s łu g , s t a n o w ią c y c h o d z w ie r c ie d le n ia in t e r f e j­ s ó w r o z p r o s z o n y c h k o m p o n e n t ó w z a p le c z a t r a d y c y jn y c h a p lik a c ji. W r e z u lt a c ie o t r z y m u j e m y u s łu g i z g o d n e z m o d e le m u s łu g i p r o x y , a ta k ż e p r z e n ie s ie n ie k la s y c z n e j k o m u n ik a c ji w s ty lu R P C n a g r u n t f r a m e w o r k u k o m u n ik a c y jn e g o S O A P . Z p e r s p e k t y w y S O A to p o d e jś c ie je s t s ta n o w c z o n ie p o ż ą d a n e . S to i w ja s k r a w e j s p rz e c z n o ś c i z w y m o g ie m u s ta n a w ia n ia s p ó jn e g o z b io r u p u n k t ó w k o ń c o w y c h w ś r o d o w is k u z o r ie n t o w a n y m n a u s łu g i, a p o n a d t o n ie s p r z y ja p r e f e r o w a n iu k o m u n ik a t ó w w s ty lu d o k u m e n t o w y m , t a k u ż y ­ te c z n y c h z p e r s p e k ty w y im p le m e n t o w a n ia r o z s z e r z e ń W S - * . T a k w ię c , m i m o iż a u to m a ty c z n e g e n e r o w a n ie in t e r fe js ó w u s łu g je s t c e c h ą p r o m o w a n ą p r z e z w ie le z n a c z ą c y c h p la t f o r m d e w e lo p e r s k ic h , n ie b ę d z ie m y w te j k s ią ż c e z g łę b ia ć je g o s z c z e g ó łó w . W s z y s tk ie o p is y w a n e w r o z d z ia le 1 5 . p r o c e s y p r o je k t o w a n ia u s łu g b a z u ją n a p o d e jś c iu „ n a jp ie r w W S D L ” , k tó r e g o is to tą je s t z a p r o je k t o w a n ie in te r fe js u u s łu g i p r z e d p r z y s tą p ie n ie m d o z g łę b ia n ia s z c z e g ó łó w je j lo g ik i a p lik a c y jn e j.

1 3 .5 .2 . N a r z ę d z ia p r o je k t o w e Is tn ie je w ie le n a r z ę d z i re a liz u ją c y c h w iz u a ln e o d w z o r o w a n ie r ó ż n y c h części is tn ie ją c y c h in te r fe js ó w u s łu g . W ie le z n ic h u m o ż liw ia t a k ż e w iz u a ln e k o n s tr u o w a n ie s c h e m a tó w X S D i d e fin ic ji W S D L z n a n ą m e t o d ą „ p r z e c ią g n ij i u p u ś ć ” u m o ż liw ia ją c ą w y g o d n e b u d o w a n ie n a w e t s k r a jn ie s k o m p li­ k o w a n y c h k o n s t r u k c ji z a p o m o c ą p r o s ty c h s to s u n k o w o c z y n n o ś c i.

1 3 .5 . N A R ZĘ D ZIA D O P R O JEK TO W A N IA INTERFEJSÓ W USŁUG

413

P r o je k t a n to m , k t ó r z y d o p ie r o „ p r z e s ia d a ją s ię ” n a n o w o c z e s n e t e c h n ik i G U I z t r a d y c y jn y c h ś r o d o w is k k o m p o n e n t o w y c h , n ie k t ó r e w s p o m n ia n e n a r z ę d z ia o fe r u ją m e c h a n iz m y , k t ó r e w y r a ź ­ n ie z a lic z y ć m o ż n a d o k a t e g o r ii „ n ie m a r t w się o W S D L ” . P r z y w y d a t n y m w s p a r c iu z e s t r o n y u ż y w a n e g o n a r z ę d z ia p r o je k t a n c i r e a liz u ją w ó w c z a s n a w p ó ł a u to m a t y c z n e g e n e r o w a n ie k o d u W S D L n a je ż o n e g o z n a c z n ik a m i w s p o s ó b c h a r a k t e r y s t y c z n y d la k o n w e n c j i w s p o m n ia n e g o n a r z ę d z ia . W

m i a r ę j a k p l a t f o r m y p r o g r a m is t y c z n o - p r o je k t o w e o b r a s ta ją w c o r a z to n o w e e le m e n t y

w s p a r c ia d la u s łu g s ie c io w y c h , w iz u a ln e n a r z ę d z ia p r o je k t o w a n ia in te r fe js ó w c z o ło w y c h te ż s ta ją się c o ra z b a r d z ie j w y r a fin o w a n e . P la n u ją c z a te m w y k o r z y s t y w a n ie k o n k r e t n e g o n a r z ę d z ia te j k a te g o r ii, w a r t o z a s ta n o w ić się n a d n a s tę p u ją c y m i te g o a s p e k ta m i. •

C z y z a p e w n ia o n o w y s ta r c z a ją c y s to p ie ń k o n t r o li u ż y t k o w n ik a (b y ć m o ż e — c a łk o w itą k o n tr o lę ) n a d g e n e r o w a n y m i a u to m a ty c z n ie d e fin ic ja m i W S D L ? Jeśli ta k , to a u to m a ty c z n ie w y g e n e r o w a ć m o ż n a je d y n ie z a c z ą te k te j d e fin ic ji, k tó r y u ż y t k o w n ik d o s k o n a lić i c y z e lo w a ć j u ż b ę d z ie w e d le w ła s n y c h p o tr z e b i u p o d o b a ń .

•

C z y u m o ż liw ia o n o a d e k w a tn ą w iz u a liz a c ję is tn ie ją c y c h , g o to w y c h d e fin ic ji W S D L ? N ie z m ie r n ie u ż y te c z n e i p o u c z a ją c e je s t o g lą d a n ie r ę c z n ie n a p is a n y c h d e fin ic ji w p r z e jr z y s ty m , h ie r a r c h ic z n y m u k ła d z ie . N ie s te t y , n ie k tó r e n a r z ę d z ia n ie są z d o ln e d o w ie r n e g o in t e r p r e t o w a n ia d e fin ic ji W S D L u t w o r z o n y c h p r z y u ż y c iu in n y c h n a r z ę d z i.

•

C z y w y k o n u je o n o w a lid a c ję d e fin ic ji z g o d n ie ze s p e c y fik a c ją W 3 C W S D L ? N ie k t ó r e n a r z ę d z ia p r z y w ią z a n e są d o s p e c y fik i k o n k r e t n y c h p la t f o r m s e r w e r o w y c h i w s p o m n ia n a w a lid a c ja p r o w a d z o n a je s t p o d k ą te m s p e c y fik i i o g r a n ic z e ń w ła ś c iw y c h ty m ż e p la t f o r m o m .

•

C z y e d y c ja z a je g o p o m o c ą g o t o w y c h d e fin ic ji W S D L n ie w ią ż e się z w p r o w a d z a n ie m d o k o d u n a d m ia r u n ie p o t r z e b n y c h z n a c z n ik ó w ? T o je d e n z p o d s ta w o w y c h p r o b le m ó w w ie lu p la t f o r m p r o g r a m is t y c z n o - p r o je k t o w y c h — n ie z a le ż n ie o d te g o , c z y k o d d e fin ic ji t w o r z o n y je s t „ o d z e r a ” , c z y te ż e d y t o w a n y , g ą s zc z n a d m ia r o w y c h z n a c z n ik ó w w y r a ź n ie p o g a rs z a je g o c z y te ln o ś ć .

O p is y w a n e w te j k s ią ż c e p r o c e s y p r o je k t o w a n ia u s łu g d a ją się p r z e p r o w a d z a ć p r z y u ż y c iu k a ż d e g o „ p r z y z w o ite g o ” n a r z ę d z ia . N a jle p s z e są e d y to r y , k tó r e u m o ż liw ia ją w y g o d n e , n a ty c h m ia ­ s to w e p r z e łą c z a n ie się m ię d z y k o d e m ź r ó d ło w y m u s łu g i a je g o w iz u a liz a c ją ; n ie z w y k le p o ż ą d a n ą f u n k c ją ta k ic h e d y t o r ó w je s t t a k ż e te s to w a n ie t w o r z o n e g o k o d u w s p o s ó b z g o d n y z z a le c e n ia m i t e s to w y m i s p e c y fik a c ji W S - I B a s ic P r o file .

1 3 .5 .3 .

R ę c z n e k o d o w a n ie

P r o g r a m iś c i i p r o je k t a n c i o b e z n a n i z e s k ła d n ia m i W S D L , X M L i p o k r e w n y c h ję z y k ó w d o te g o s to p n ia , iż ic h e le m e n ty s y n ta k ty c z n e ś n ią i m się p o n o c a c h , b y ć m o ż e p r e fe r o w a ć b ę d ą tw o r z e n ie d e fin ic ji W S D L z a p o m o c ą e d y to r ó w X M L c z y n a w e t z w y k ły c h e d y t o r ó w te k s to w y c h . W te n s p o ­ só b g w a r a n tu ją s o b ie c a łk o w itą i w y łą c z n ą k o n t r o lę n a d t w o r z o n y m k o d e m i o b c e są i m fr u s tr a c je w y n ik a ją c e z id i o m a t y k i fu n k c jo n o w a n ia ta k ie g o c z y in n e g o s p e c ja liz o w a n e g o n a r z ę d z ia .

414

R O ZD ZIA Ł 1 3 . ■ PR O JEKTO W ANIE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ I. W P R O W A D Z E N IE )

Z a w s z e z re s z tą m o g ą k o r z y s ta ć z e s p e c ja liz o w a n y c h n a r z ę d z i w c e la c h w y łą c z n ie w iz u a liz a ­ c y jn y c h , a b y ć m o ż e t a k ż e i w a lid a c y jn y c h . P o g r ą ż e n i w k o n t e m p lo w a n iu o b r a z u G U I w ła s n e j t w ó r c z o ś c i lit e r a c k ie j m u s z ą o n i je d n a k b a c z y ć n a t o , b y — p r z y p a d k ie m lu b o d r u c h o w o — n ie k lik n ą ć p r z y c is k u Z a p is z , b o g ro s z a in w e s to w a n e g o w y s iłk u m o ż e p ó jś ć — n ie s te ty — n a m a r n e ( z c z e g o , n a s z c z ę ś c ie , z d a je s o b ie s p ra w ę w ie lu t w ó r c ó w t a k ic h n a r z ę d z i i w y m u s z a a u to m a ty c z n e t w o r z e n ie k o p ii z a p a s o w e j is tn ie ją c e g o p li k u p r z e d je g o z a s tą p ie n ie m ). I c h o c ia ż w ię k s z o ś ć p r o je k t a n t ó w s k ła n ia się ra c z e j k u s p e c ja liz o w a n y m n a r z ę d z io m d o t w o ­ r z e n ia d e fin ic ji in t e r fe js ó w u s łu g , n a p o t r z e b y te j k s ią ż k i z a d o w o lim y się r ę c z n y m k o d o w a n ie m , tw o r z ą c „ o d z e r a ” c a ły k o d z w ią z a n y z re a liz a c ją tr z e c h p ro c e s ó w p r o je k to w y c h o p is y w a n y c h w r o z ­ d z ia le 1 5 ., z g o d n ie z n a s z y m i s t a n d a r d a m i i p r e fe r e n c ja m i. W k o n s e k w e n c ji p r e z e n to w a n e a n a liz y p r z y p a d k ó w ta k ż e o p ie r a ć się b ę d ą n a t y m p o d e jś c iu .

A N A LIZA PRZYPADKU P r z y g o to w u ją c się d o k o le jn e g o e ta p u n a d r o d z e d o s ta r c z e n ia s w y c h r o z w ią z a ń S O A , o b ie f i r m y — R a ilC o i T L S — s ta n ę ły p r z e d w y b o r e m t e c h n ik i u r z e c z y w is tn ie n ia p r o je k t ó w i n ­ te r fe js ó w u s łu g . P e r s o n e l I T o b u f i r m p o s ia d a d o ś w ia d c z e n ie n a b y te p r z y t w o r z e n iu u s łu g s ie c io w y c h w r a m a c h p o p r z e d n ic h p r o je k t ó w i je s t d o ś ć d o b r z e z a z n a jo m io n y z p o d s t a w o ­ w y m i te c h n o lo g ia m i S O A . W ty c h w a r u n k a c h o b a z e s p o ły z d e c y d o w a ły o t w o r z e n iu d e fin ic ji W S D L i s c h e m a tó w X S D d r o g ą rę c z n e g o k o d o w a n ia , p r z y u ż y c iu e d y to r a z a p e w n ia ją c e g o w a lid a c ję i te s to w a n ie k o d u w s p o s ó b z g o d n y ze s p e c y fik a c ja m i W S - I .

P O D S U M O W A N IE

•

Automatyczne generowanie interfejsów usług na podstawie istniejących definicji klas komponentów nie jest zalecanym podejściem do projektowania usług w procesie budowania SOA.

•

Narzędzia modelowania znacząco wspomagać mogą projektowanie usług, o ile nie interferują z wyjściową definicją WSDL.

•

Ręczne kodowanie definicji WSDL i związanych z nimi schematów XSD zapewnia najwyższy stopień kontroli nad ich postacią; narzędzia modelowania mogą być w tym przypadku pomocne w walidacji i testowaniu tworzonego ręcznie kodu.

Projektowanie zorientowane na usługi (Część II. Wytyczne komponowania SOA) 1 4 .1 . K o m p o n o w a n ie S O A — k r o k p o k r o k u 1 4 .2 . U w a r u n k o w a n ia w y b o r u w a r s t w u s łu g 1 4 .3 . U w a r u n k o w a n ia u m ie js c o w ie n ia r d z e n n y c h s ta n d a r d ó w S O A 1 4 .4 . U w a r u n k o w a n ia w y b o r u r o z s z e r z e ń S O A

416

RO ZD ZIA Ł 1 4 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ II. W Y TYC ZN E K O M P O N O W A N IA SOA)

D e f in i o w a n ie a r c h it e k t u r y je s t z w y c z a jo w y m k r o k ie m w c y k lu ż y c io w y m k a ż d e g o p r o je k t u a u to ­ m a ty z a c ji. O z n a c z a z d e f in io w a n ie g r a n ic a p lik a c ji, z e s ta w u w s p ie r a n y c h te c h n o lo g ii i d o c e lo w e g o ś r o d o w is k a , w k t ó r y m w d r a ż a n e m a ją b y ć r e z u lt a t y w s p o m n ia n e g o p r o je k t u . Ja k je d n a k z d ą ż y li­ ś m y się ju ż z o r ie n to w a ć , S O A w n o s i w t y m w z g lę d z ie n o w ą ja k o ś ć , co o d r ó ż n ia je j m e to d o lo g ie o d tr a d y c y jn e g o p r o je k to w a n ia ; w k o n s e k w e n c ji s a m o d e fin io w a n ie a r c h it e k t u r y S O A r ó w n ie ż w y m a g a s p e c y fic z n e g o p o d e jś c ia .

A n a l i z y p r z y p a d k ó w : O b ie n a s z e f ik c y jn e f i r m y s to ją w ła ś n ie p r z e d p o d ję c ie m s t r a t e g ic z ­ n y c h d e c y z ji w r a m a c h p r z y g o t o w a ń d o p r o c e s u p r o je k t o w a n ia z o r ie n to w a n e g o n a u s łu g i. D o k o n y w a n e w t y m m o m e n c ie w y b o r y d o ty c z ą c e p la n o w a n e g o k s z ta łtu b u d o w a n e j S O A o d ­ z w ie r c ie d lo n e b ę d ą w p r z e b ie g u p r o c e s u p r o je k t o w a n ia u s łu g o p is y w a n e g o n a p r z e s tr z e n i c z te r e c h r o z d z ia łó w .

1 4 .1 . K o m p o n o w a n ie SO A — k ro k p o kroku K a ż d y e g z e m p la r z S O A , n ie z a le ż n ie o d s p e c y fic z n e g o k s z ta łtu c z y r o z m ia r u , z ło ż o n y je s t z k o m ­ p o n e n t ó w t e c h n o lo g ic z n y c h u s ta n a w ia ją c y c h ś r o d o w is k o , w k t ó r y m r e z y d u ją d z ia ła ją c e u s łu g i ( p a t r z r y s u n e k 1 4 .1 ). N a jw a ż n ie js z e w ś r ó d w s p o m n ia n y c h k o m p o n e n t ó w to : • •

a r c h it e k t u r a r e p r e z e n t a c ji d a n y c h X M L , u s łu g i s ie c io w e z b u d o w a n e z u w z g lę d n ie n ie m o b o w ią z u ją c y c h s t a n d a r d ó w p r z e m y s ło w y c h ,

•

p la t f o r m a z d o ln a d o h o s to w a n ia u s łu g s ie c io w y c h i p r z e t w a r z a n ia d a n y c h X M L .

Usługi sieciowe

Reprezentacja danych w standardzie XML

Platforma dostawcy

Rysunek 14.1. Najbardziej podstawowe komponenty SOA T o je d n a k ty lk o część p r a w d y : a b y u w z g lę d n ić i z r e a liz o w a ć z a s a d y o r a z c e c h y c h a r a k te r y ­ s ty c z n e z a r ó w n o p ie r w o tn e j, ja k i w s p ó łc z e s n e j S O A , p r o je k t a n c i m u s z ą się je s z c ze tr o c h ę p o s ta ra ć . O t o p y ta n ia n a jc z ę ś c ie j z a d a w a n e n a t y m e ta p ie . • •

J a k ie g o t y p u ( ja k ic h t y p ó w ) u s łu g i n a le ż y z b u d o w a ć i j a k z o r g a n iz o w a ć je w w a r s tw y ? Ja k u m ie js c o w ić s ta n d a r d y u s łu g s ie c io w y c h p ie r w s z e j g e n e r a c ji, b y z a p e w n ić j a k n a jle p s z e w s p a r c ie d la b u d o w a n e j S O A ?

•

J a k ie m e c h a n iz m y d e fin io w a n e p r z e z d o s tę p n e r o z s z e r z e n ia w y m a g a n e są p r z e z b u d o w a n ą SOA?

1 4 .1 . K O M P O N O W A N IE SO A — KROK PO KROKU

417

P o s z u k iw a n ie o d p o w ie d z i n a te p y t a n ia to ć w ic z e n ie z k o m p o z y c ji, c z y li s k ła d a n ie ( m e t o d ą p r ó b i b łę d ó w ) k o m p o n e n t ó w a r c h it e k to n ic z n y c h i t e c h n o lo g ic z n y c h w s p o s ó b j a k n a jle p ie j s łu ­ żący b u d o w an ej S O A . N a r y s u n k u 1 4 .2 w id z im y n ie f o r m a l n y z e s ta w k r o k ó w p r o c e s u k o m p o n o w a n ia a r c h it e k t u r y z o r ie n to w a n e j n a u s łu g i; o p is u je m y je p o k r ó tc e w k o le jn y c h p u n k ta c h . S to s o w n ie d o w y ty c z o n y c h c e ló w i n a t u r y ś r o d o w is k a te c h n o lo g ic z n e g o b ę d ą o n e p r a w d o p o d o b n ie w y m a g a ć u z u p e łn ie n ia o d o d a t k o w e c z y n n o ś c i.

Rysunek 14.2. Sugerowane kroki procesu budowania wstępnej wersji SOA. Jak pisaliśmy w rozdziale 13., zależnie od zastosowanej strategii realizacji SOA krok komponowania SOA może być albo częścią analizy zstępującej, albo specjalnym etapem poprzedzającym proces projektowania zorientowanego na usługi

1 4 .1 .1 .

W y b ó r s t r u k t u r y w a r s t w u s łu g

K o m p o n o w a n ie S O A p o w in n o ro z p o c z ą ć się o d z a p r o je k to w a n ia k o n fig u r a c ji w a r s tw u s łu g , k tó r e to w a r s tw y s k ła d a ją się n a lo g ik ę b u d o w a n e j a r c h ite k tu r y i lo g ik ę tę s ta n d a r y z u ją . Z a d a n ie to r e a li­ z u je się p o p r z e z s tu d io w a n ie k a n d y d a tu r n a u s łu g i w y o d r ę b n io n y c h n a e ta p ie a n a liz y o r a z e k s p lo r a ­ cję w a r s tw u s łu g ( i s c e n a riu s z y ic h k o n fig u r o w a n ia ) o p is y w a n y c h w r o z d z ia le 9. P e w n e w s k a z ó w k i w t y m w z g lę d z ie p r z e d s ta w im y w p o d r o z d z ia le 1 4 .2 , „ U w a r u n k o w a n ia w y b o r u w a r s tw u s łu g ” .

1 4 .1 .2 .

U m ie js c o w ie n ie rd z e n n y c h s t a n d a r d ó w

N a s t ę p n y k r o k to o c e n a , k t ó r e z r d z e n n y c h s ta n d a r d ó w S O A w c h o d z ić m a ją w s k ła d n a s z e g o e g ­ z e m p la r z a S O A i j a k je z a im p le m e n t o w a ć , b y n a jle p ie j r e a liz o w a ły z a k ła d a n e c e c h y i w y m a g a n ia t w o r z o n e g o r o z w ią z a n ia . W p o d r o z d z ia le 1 4 .3 , „ U w a r u n k o w a n i a u m i e js c o w ie n ia r d z e n n y c h s ta n d a r d ó w S O A ” , p r z e d s ta w ia m y o g ó ln e w s k a z ó w k i d o ty c z ą c e w p ły w u p o d s ta w o w y c h s p e c y fi­ k a c ji X M L i u s łu g s ie c io w y c h n a u n ik a ln o ś ć c h a r a k te r y s ty k i S O A .

418

RO ZD ZIA Ł 1 4 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ II. W Y TYC ZN E K O M P O N O W A N IA SOA)

1 4 .1 .3 .

W y b ó r ro zs ze rze ń S O A

O s t a t n i z k r o k ó w p r z y g o to w a w c z y c h d o p r o je k t o w a n ia to d e c y z ja , k t ó r y m c e c h o m c h a r a k te r y ­ s t y c z n y m w s p ó łc z e s n e j S O A c h c e m y z a p e w n ić w s p a r c ie w b u d o w a n e j a r c h it e k t u r z e , a w k o n s e ­ k w e n c ji — k tó r e z ro z s z e r z e ń W S - * m a ją się sta ć e le m e n ta m i n a s ze g o ś r o d o w is k a z o r ie n to w a n e g o n a u s łu g i. W p o d r o z d z ia le 1 4 .4 , „ U w a r u n k o w a n i a w y b o r u r o z s z e r z e ń S O A ” , p r z e d s ta w ia m y k ilk a w s k a z ó w e k z w ią z a n y c h z t a k im w y b o r e m . P O D S U M O W A N IE •

Przed przystąpieniem do projektow ania poszczególnych usług zalecane jest w ykonanie kliku zadań przygotowawczych zmierzających do form alnego zdefiniow ania architektury zorientow anej na usługi.

•

Do wspom nianych zadań zaliczyć należy przede wszystkim sfinalizow anie konfiguracji w arstw usług i w ybranie rozszerzeń koniecznych do spełnienia w ym agań stawianych budow anej SOA jako całości.

•

Także um iejscowienie standardów usług sieciowych jest istotną kwestią, jako że SOA narzuca szereg wyraźnych zasad i cech projektow ania.

1 4 .2 . U w a ru n k o w a n ia w y b o ru w a r s tw u sług J e d n y m z r e z u lt a t ó w p r o c e s u a n a liz y z o r ie n to w a n e j n a u s łu g i je s t z w y k le w s tę p n a p o s ta ć k o n f ig u ­ r a c ji w a r s t w u s łu g . P ie r w s z y m k r o k ie m w p r o je k t o w a n iu S O A je s t z a t e m d e c y z ja o k o n k r e t n y m s p o s o b ie s k o n f ig u r o w a n ia ty c h w a r s tw ( p a t r z r y s u n e k 1 4 .3 ).

Id o o o a l (0 0 0 0 0 ) Usługi sieciowe

Reprezentacja danych w standardzie XML

Platforma dostawcy

Rysunek 14.3. Wyznaczone warstwy usług organizują i standaryzują usługi sieciowe w ramach SOA Z a le ż n ie o d z a k r e s u p la n o w a n e j a r c h it e k t u r y , k r o k t e n m o ż e w y m a g a ć p r o c e s u a n a liz y , w y ­ so ce s p e c y fic z n e g o d la d a n e j f ir m y , u w z g lę d n ia ją c e g o je j ce le z a r ó w n o d o r a ź n e , j a k i d łu g o fa lo w e . U s t a n a w ia ją c o k r e ś lo n ą k o n fig u r a c ję w a r s tw u s łu g , t w o r z y m y t a k n a p r a w d ę s ta n d a r d o w e ś r o d k i r e p r e z e n to w a n ia p r z e t w a r z a n y c h d a n y c h i lo g ik i ic h p r z e tw a r z a n ia . I w t y m m o m e n c ie p o ja w ia się je d n o z n a jw a ż n ie js z y c h p y ta ń . C z y w o g ó le p o w in n iś m y in w e ­ s to w a ć w t w o r z e n ie u s łu g b iz n e s o w y c h ? P y ta n ie n a le ż y d o n a jw a ż n ie js z y c h , b o w t y m m o m e n c ie n a s z a S O A z n a jd u je się n a r o z d r o ż u : d w ie m o ż liw e o d p o w ie d z i o z n a c z a ją p o p r o w a d z e n ie r o z ­ w o ju S O A w d w ó c h z u p e łn ie r ó ż n y c h k ie r u n k a c h . P o m o c n ą w p o d ję c iu te j — i w ie lu in n y c h — d e c y z ji m o ż e o k a z a ć się a n a liz a p o n iż s z y c h c z y n n ik ó w .

1 4 .2 . U W A R U N K O W A N IA W Y B O R U W A R S T W USŁUG

•

419

Is tn ie ją c e k o n fig u ra c je . Jeśli w p rz e d s ię b io rs tw ie f u n k c jo n u ją ju ż s ta n d a r d o w e w a r s t w y u s łu g , o c z y w is te b ę d z ie u s iło w a n ie z a p e w n ie n ia z g o d n o ś c i p r o je k t o w a n y c h u s łu g z k o n fig u r a c ją ty c h w a r s tw . W y j ą t k i e m je s t je d n a k s y tu a c ja , g d y z id e n ty fik o w a n o p o tr z e b ę z m o d y fik o w a n ia te j k o n fig u r a c ji: w ó w c z a s z a k r e s p r o je k t u r o z c ią g a się n a z m ia n ę o g ó ln e g o o b r a z u S O A w e w s p o m n ia n y m p r z e d s ię b io r s tw ie .

•

W y m a g a n e s ta n d a rd y . T w o r z ą c n o w e u s łu g i lu b k o n fig u r u ją c n a n o w o (b ą d ź o d z e ra ) w a r s tw y u s łu g , k o n ie c z n ie p o w in n iś m y k ie r o w a ć się z g o d n o ś c ią z u s ta n o w io n y m i s ta n d a r d a m i p r o je k to w a n ia . S ta n d a r d y te p o w in n y z o s ta ć u t r w a lo n e (z a p is a n e ) w c z y te ln e j p o s ta c i, b o o b o w ią z u ją c e b ę d ą w o d n ie s ie n iu z a r ó w n o d o b ie ż ą c e g o , ja k i d o p r z y s z ły c h p r o je k tó w .

•

W y d a jn o ś ć k o m p o z y c ji u słu g . K o m p o z y c je u s łu g m o g ą w y m a g a ć n ie k ie d y z n a c z ą c e j p o r c ji d o d a tk o w e g o p r z e tw a r z a n ia , s k u p io n e g o g łó w n ie w u s łu g a c h p o ś re d n ic z ą c y c h p rz e tw a rz a ją c y c h k o m u n ik a ty S O A P — k a ż d y p r z e s k o k n a tra s ie m ię d z y w n io s k o d a w c ą a d o s ta rc z y c ie le m w y k o n u je w a lid a c ję , d e s e ria liz a c ję i s e ria liz a c ję k o m u n ik a t u . M o ż e to o k a z a ć się w ie lc e c z a s o c h ło n n e , z w ła s z c z a g d y in fr a s tr u k tu r a I T p o z b a w io n a je s t s p e c ja liz o w a n y c h p ro c e s o ró w lu b a k c e le r a to ró w . P o d ję c ie d e c y z ji w k w e s tii b u d o w a n ia lu b n ie w ie lo p o z io m o w y c h k o n fig u r a c ji w a r s tw u s łu g p o w in n o w ię c b y ć p o p r z e d z o n e o d p o w ie d n im i te s ta m i w y d a jn o ś c i.

•

W d ra ż a n ie u s łu g . P r z y p r o je k t o w a n iu w a r s t w u s łu g z a w ie r a ją c y c h u s łu g i a g n o s ty c z n e p ro c e s o w o p r a w d z iw y m w y z w a n ie m m o ż e o k a z a ć się w d r a ż a n ie ty c h u s łu g . W ś r o d o w is k u o d u ż y m s to p n iu r o z p r o s z e n ia z lo k a liz o w a n e c e n tr a ln ie w ie lo u ż y w a ln e u s łu g i m o g ą s ta w a ć się p r a w d z iw y m i „ w ą s k im i g a r d ła m i” p r z e t w a r z a n ia , s tw a r z a ją c y m i o d c z u w a ln e o p ó ź n ie n ia w s to s u n k u d o p o t e n c ja ln y c h u s łu g - w n io s k o d a w c ó w ( i e w e n tu a ln ie in n y c h o b ie k t ó w z a m ie r z a ją c y c h n a w ią z y w a ć p o łą c z e n ia ). T y p o w y m ś r o d k ie m z a r a d c z y m w te j s y tu a c ji je s t r e d u n d a n t n e w d r a ż a n ie k r y t y c z n y c h u s łu g , to je d n a k w ią ż e się z d o d a t k o w y m w y s iłk ie m a d m in is t r a c y jn y m . S ta je m y w ó w c z a s p r z e d k o n ie c z n o ś c ią w y w a ż e n ia tr z e c h w y m ie n io n y c h a s p e k tó w — a g n o s ty c y z m u , w y d a jn o ś c i i z ło ż o n o ś c i a d m in is t r o w a n ia .

•

W e rs jo n o w a n ie u s łu g . P la n u ją c re a liz a c ję w ie lo u ż y w a ln y c h u s łu g ja k o e le m e n tó w b u d o w a n e j S O A , n a le ż y z d a w a ć so b ie w p e łn i s p ra w ę z ic h re la c ji d o p o te n c ja ln y c h u s łu g -w n io s k o d a w c ó w , w b liż s z e j i d a ls z e j p rz y s z ło ś c i. W d r o ż o n a u s łu g a m o ż e b y ć p ó ź n ie j p o d d a w a n a r o z b u d o w ie w y n ik a ją c e j ze w z b o g a c a n ia o n o w e c e c h y fu n k c jo n a ln e ; je ś li w y n ik a ją c e s tą d z m ia n y w in te r fe js ie u s łu g i p o w o d u ją z a k łó c e n ie w s p o m n ia n e j re la c ji, k o n ie c z n e sta je się z a im p le m e n to w a n ie ja k ie g o ś s y s te m u w e r s jo n o w a n ia u s łu g — ta k b y d a n a u s łu g a -w n io s k o d a w c a łą c z y ła się z u s łu g ą w te j w e r s ji, n a k o m u n ik a c ję z k tó r ą je s t p r z y g o to w a n a .

•

P ro je k to w a n ie u s łu g b iz n e s o w y c h i s c h e m a tó w X S D . G d y w f ir m i e is tn ie je j u ż o b s z e rn a a r c h ite k tu r a r e p r e z e n to w a n ia d a n y c h X M L , w a r t o p r z y jr z e ć się z d e f in io w a n y m w je j r a m a c h s c h e m a to m X S D p o d k ą t e m ic h k o m p a t y b iln o ś c i z p la n o w a n y m i u s łu g a m i b iz n e s o w y m i. S ta je się to s z c z e g ó ln ie is to tn e w p r z y p a d k u u s łu g p o d m io t o w y c h , ja k o ż e te b a z u ją z w y k le n a p r z e t w a r z a n iu d o k u m e n t ó w - e n c ji, k o ja r z o n y c h n a jle p ie j ze s p e c y fic z n y m i s c h e m a ta m i u k ie r u n k o w a n y m i p o d m io t o w o .

•

U tr z y m y w a n ie u s łu g b iz n e s o w y c h . G d y s to s o w a n a je s t s tr a te g ia z w in n a r e a liz a c ji S O A ( p a t r z p o d r o z d z ia ł 1 0 .4 ), n a le ż y p o w a ż n ie z a s ta n o w ić się n a d p r o b le m e m u t r z y m a n ia e w o lu u ją c y c h w c ią ż u s łu g b iz n e s o w y c h . W m ia r ę p r z e b ie g u a n a liz y z s tę p u ją c e j it e r a c y jn e u a k t u a ln ia n ie d z ia ła ją c y c h j u ż u s łu g z g o d n ie z n o w o id e n t y f ik o w a n y m i e le m e n ta m i lo g ik i b iz n e s o w e j m u s i z o s ta ć p o g o d z o n e z ic h a k t u a ln ą d o s tę p n o ś c ią d la w n io s k o d a w c ó w . P o n o w n ie s tw a r z a to k o n ie c z n o ś ć u ż y c ia ja k ie g o ś s y s te m u w e r s jo n o w a n ia .

420

RO ZD ZIA Ł 1 4 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ II. W Y TYC ZN E K O M P O N O W A N IA SOA)

P O D S U M O W A N IE •

Przy rozważaniu konfiguracji w arstw usług budow anej SOA podstaw ow e znaczenie mają uw arunkow ania praktyczne.

•

Pogodzenia w ym agają w ów czas trzy kluczowe czynniki: wydajność, konfiguracja w drażania i złożoność adm inistrow ania.

1 4 .3 .

U w a r u n k o w a n ia

u m ie js c o w ie n ia rd z e n n y c h s ta n d a r d ó w

SOA

D r u g i m k r o k ie m p o d p r o c e s u k o m p o n o w a n ia S O A je s t u s ta n o w ie n ie s t a n d a r d ó w fo r m u ją c y c h f u n d a m e n t y n a s z e j a r c h ite k tu r y . W

p ie r w s z e j c h w ili m o ż e się to w y d a w a ć z a d a n ie m b a r d z o ła ­

t w y m , ja k o ż e p la t f o r m y w ię k s z o ś c i d o s ta w c ó w d o s ta r c z a ją w s p a r c ie d la a k c e p to w a ln e g o z b io r u s p e c y fik a c ji X M L i p ie r w s z e j g e n e r a c ji u s łu g s ie c io w y c h ( p a t r z r y s u n e k 1 4 .4 ).

fZ

f= -

¿ 2

f i

Usługi sieciowe

/T Reprezentacja danych w standardzie XML Platforma dostawcy

Rysunek 14.4. SOA standaryzuje sposób wykorzystywania powszechnych standardów XML i usług sieciowych W rz e c z y w is to ś c i je d n a k n ie je s t to z a d a n ie p r o s te g o w y b o r u ż ą d a n y c h p o z y c ji z r o g u o b f it o ­ ści s ta n d a r d ó w i s p e c y fik a c ji, b o w y b r a n e e le m e n t y m u s z ą je s z c z e z o s ta ć o d p o w ie d n io u m ie js c o ­ w io n e w b u d o w a n e j a r c h ite k tu r z e , t a k b y z a p e w n ić ja k n a jle p s z e w s p a r c ie d la ty c h c h a r a k te r y s ty k S O A , k tó r e w r a m a c h te j a r c h it e k t u r y c h c e m y u r z e c z y w is tn ić . W k o le jn y c h p u n k t a c h p r z e d s ta ­ w ia m y w ię c d y s k u s ję o t y m , j a k w y k o r z y s ty w a n ie r d z e n n y c h s t a n d a r d ó w u s łu g s ie c io w y c h i s ta n ­ d a r d u X M L w p ły w a ć m o ż e n a p r z e b ie g p r o je k t o w a n ia u s łu g i ic h w a r s tw w a r c h ite k tu r z e z o ­ r ie n to w a n e j n a u s łu g i.

1 4 .3 .1 .

S ta n d a r d y p r z e m y s ło w e a S O A

M i m o a b s tr a k c y jn o ś c i p r o je k t ó w u s łu g , p r o je k t y te w c ią ż r e a liz o w a n e są p r z y u ż y c iu ję z y k ó w z n a c z n ik o w y c h s p e c ja ln ie p r z y s to s o w a n y c h d la u s łu g s ie c io w y c h . J ę z y k i te w y w o d z ą się z e s p e c y ­ f ik a c j i p u b lik o w a n y c h w r ó ż n y c h w e r s ja c h i n a r ó ż n y m s to p n iu d o jr z a ło ś c i — n o w e w e rs je p o ­ tr a f ią n ie r a z d r a s ty c z n ie z m ie n ia ć u s ta le n ia p o c z y n io n e w r a m a c h w e r s ji p o p r z e d n ic h . Jest z a t e m r z e c z ą n ie z m ie r n ie is to tn ą u p e w n ie n ie się, że b u d u ją c S O A , z a c h o w u je m y s p ó jn o ś ć p o d w z g lę d e m w e r s ji s t a n d a r d ó w p r z e m y s ło w y c h tw o r z ą c y c h je j f u n d a m e n t y . T a s p ó jn o ś ć to n ie ty lk o k w e s tia s ta n d a r y z a c ji ś r o d o w is k a f ir m o w e g o , to ta k ż e k w e s tia s p ó jn o ś c i m e ta d a n y c h , z k t ó ­ r y c h k o r z y s ta ć b ę d ą z e w n ę t r z n i p a r t n e r z y o n lin e , c z y li — w k a te g o r ia c h S O A — w s p a r c ie d la i n te r o p e r a c y jn o ś c i.

1 4 .3 . U W A R U N K O W A N IA U M IE J S C O W IE N IA R D ZEN N Y C H S T A N D A R D Ó W SOA

421

N a r y s u n k u 1 4 .5 w id o c z n e są s y m b o le c z te r e c h s ta n d a r d ó w s p o ty k a n y c h p o w s z e c h n ie w k a ż ­ d e j n ie m a l im p le m e n t a c ji S O A o r a z lo g ic z n e p o w ią z a n ia m ię d z y n im i. P r z y jr z y jm y się, j a k k a ż d y z ty c h s t a n d a r d ó w o d z w ie r c ie d lo n y z o s ta je w p ro c e s ie p r o je k t o w a n ia u s łu g i j a k u m ie js c a w ia się w o g ó ln e j s tr u k t u r z e S O A .

Rysunek 14.5. Zależności operacyjne między rdzennymi specyfikacjami SOA

1 4 .3 .2 .

X M L a SOA

R e p r e z e n t o w a n ie d a n y c h w s ta n d a r d z ie X M L to je d e n z f ila r ó w k a ż d e g o w r ę c z e le m e n tu S O A . P r a k ty c z n ie w s z y s tk ie s p e c y fik a c je z w ią z a n e z p la t f o r m ą u s łu g s ie c io w y c h w y r a ż a n e są w ję z y k u X M L i z z a ło ż e n ia w a r u n k u ją w s z e lk ą k o m u n ik a c ję w r a m a c h te j p la t f o r m y o d m o ż liw o ś c i p r z e ­ t w a r z a n ia d o k u m e n t ó w X M L . B u d o w a n ie S O A n ie m o ż e się w ię c z a k o ń c z y ć p o w o d z e n ie m b e z w y k o r z y s ty w a n ia a r c h it e k t u r y r e p r e z e n t o w a n ia d a n y c h X M L i p e łn e j z g o d n o ś c i z tą a r c h it e k t u r ą . T o w y m a g a r o z w a ż e n ia w ie lu s z c z e g ó ło w y c h z a g a d n ie ń , z k t ó r y c h w y b r a n e p o n iż e j p r e z e n tu je m y . S t y l R P C a s ty l d o k u m e n t o w y k o m u n i k a t ó w S O A P A b y u c z y n ić z a d o ś ć w y m o g o m k o m u n ik a c ji R P C , tr a d y c y jn e a r c h it e k t u r y r e p r e z e n t o w a n ia d a ­ n y c h w y k a z u ją t e n d e n c ję d o k s z ta łto w a n ia d o k u m e n t ó w X M L n a w z ó r m o d e lu w y m i a n y d a n y c h p a r a m e tr ó w . W t e n s p o s ó b t w o r z o n e są lic z n e d r o b n o z ia r n is te k o m u n ik a t y i u s ta n a w ia się m o d e l w y m ia n y k o m u n ik a t ó w S O A P w s ty lu R P C . M o d e l te n p o z o s ta je w w y r a ź n e j o p o z y c ji d o w y m ia n y k o m u n ik a t ó w w s ty lu d o k u m e n t o w y m , p r e fe r o w a n y c h p r z e z w ię k s z o ś ć s p e c y fik a c ji W S - * (p is z e m y o t y m o b s z e rn ie j w p u n k c ie „ S O A P a X M L ”). A u t o m a t y c z n e g e n e r o w a n ie k o d u X M L W ie le n a r z ę d z i d e w e lo p e r s k ic h o fe r u je m o ż liw o ś ć a u to m a ty c z n e g o g e n e r o w a n ia r ó ż n e g o r o d z a ju d o k u m e n t ó w w k o d z ie X M L , w o p a r c iu o r ó ż n o r o d n e ź r ó d ła : m o d e le d a n y c h , d e fin ic je k la s i ty m p o d o b n e . F u n k c ja ta , c h o ć n i e z m ie r n ie w y g o d n a z p e r s p e k t y w y d o r a ź n e j k o n w e r s ji d a n y c h ,

422

RO ZD ZIA Ł 1 4 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ II. W Y TYC ZN E K O M P O N O W A N IA SOA)

n a p r z y k ła d n a p o tr z e b y ic h w s p ó łd z ie le n ia z in n y m i a p lik a c ja m i, m a je d n a k z w y k le te n m a n k a m e n t, ż e p r o w a d z i d o p r o life r a c ji r e p r e z e n to w a n ia d a n y c h w s p o s ó b d a le k i o d p r z y ję ty c h s ta n d a r d ó w . D o k u m e n t y X M L g e n e r o w a n e a u to m a ty c z n ie n a p o d s ta w ie r ó ż n y c h ź r ó d e ł z w y k le r ó ż n ią się p o d w z g lę d e m s t r u k t u r y , p o d o b n ie j a k te ź r ó d ła — w s z a k n p . d e fin ic ja k la s y m a s tr u k t u r ę in n ą n iż s c h e m a t ta b e li re la c y jn e j b a z y d a n y c h . S y tu a c ja , g d y w z o r c e m s ta ją się lo k a ln e u w a r u n k o w a n ia , a n ie z d e f in io w a n e a p r io r i s ta n d a r d y , je s t b a r d z o n ie k o r z y s tn a z p e r s p e k t y w y S O A , z a k ła d a ją c e j z u n if ik o w a n e r e p r e z e n to w a n ie d a n y c h , s p rz y ja ją c e in te r o p e r a c y jn o ś c i i fe d e ra c y jn o ś c i w g lo b a ln e j s k a li p rz e d s ię b io rs tw a . B u d o w a n i e S O A n a k a n w ie is t n ie ją c e j a r c h i t e k t u r y r e p r e z e n t a c j i d a n y c h G d y w f ir m i e f u n k c jo n u je j u ż u s ta b iliz o w a n a a r c h it e k t u r a r e p r e z e n t o w a n ia d a n y c h X M L , n ie k o ­ n ie c z n ie m u s i b y ć o n a z g o d n a z w y m o g a m i b u d o w a n e j S O A i w ó w c z a s f i r m o w i in f o r m a t y c y s ta ją p r z e d k o n ie c z n o ś c ią „ p o ż e n ie n ia ” je j z t y m i w y m o g a m i. N ie z a le ż n ie o d s to p n ia r o z b ie ż n o ś c i — m ię d z y t y m , co is tn ie ją c e a t y m , co w y m a g a n e — p ie r w s z y m k r o k ie m n a te j d r o d z e p o w in n o b y ć z e s ta n d a r y z o w a n ie is tn ie ją c y c h r e p r e z e n t a c ji je s z c z e p r z e d r o z p o c z ę c ie m p o d r ó ż y w s tr o n ę S O A . Jeśli n a w e t w y p r a c o w a n y w te n s p o s ó b s ta n d a r d n a d a l o d b ie g a ć b ę d z ie o d te g o , z g o d n ie z k t ó r y m n a s ze u s łu g i w y r a ż a ć m a ją d a n e k o r p o r a c y jn e , to n a jw a ż n ie js z a je s t je g o s p ó jn o ś ć i p r z e w id y w a ln o ś ć w z a k r e s ie r e p r e z e n t o w a n ia d a n y c h . B o w ó w c z a s w s p o m n ia n ą n ie z g o d n o ś ć d a się z n iw e lo w a ć d z ię k i a b s tr a k c y jn o ś c i s a m y c h u s łu g . T e g o t y p u m ig r a c ja n ie m o ż e się je d n a k o d b y w a ć s p o n ta n ic z n ie , le c z m u s i b y ć r e a liz o w a n a w e d łu g z d e fin io w a n e g o p la n u . T a k i o g ó ln y p la n tr a n s fo r m a c ji w s tro n ę S O A p o w in ie n u w z g lę d n ia ć k o m p a ty b iln o ś ć r e p r e z e n t a c ji d a n y c h ja k o je d e n z n a jw a ż n ie js z y c h e le m e n tó w .

1 4 .3 .3 .

W S - I B a s ic P r o f ile

B a s ic P r o f ile to r e z u lt a t d z ia ła ń W S - I z m ie r z a ją c y c h d o s tw o r z e n ia z b io r u d o jr z a ły c h , r d z e n n y c h s p e c y fik a c ji f o r m u ją c y c h k s z ta łt p o w s z e c h n ie d o s tę p n e j i w y r a ź n ie z d e fin io w a n e j p la t f o r m y u s łu g s ie c io w y c h . S p e c y fik a c je e w a lu o w a n e są in d y w id u a ln ie d la ic h p o s z c z e g ó ln y c h w e r s ji. Z g o d n o ś ć z r e g u ła m i i w y ty c z n y m i B as ic P r o file s ta n o w i g w a r a n c ję a k c e p to w a ln o ś c i i k o m p a ty b iln o ś c i z p o ­ w s z e c h n ie p r z y ję ty m i s t a n d a r d a m i p r z e m y s ło w y m i, n ic w ię c d z iw n e g o , iż c o ra z w ię c e j o r g a n iz a c ji p r z y w ią z u je d o te j z g o d n o ś c i n a le ż y tą w a g ę . I t a k w w e r s ja c h 1.0 i 1.1 B a s ic P r o f ile z a w a r ta je s t p r o p o z y c ja u z n a n ia z a w z o r c o w e n a s tę p u ­ ją c y c h s p e c y fik a c ji1: •

W S D L 1.1,

•

S O A P 1 .1 ,

•

U D D I 2 .0 ,

•

X M L 1 .0 ,

•

X M L S c h e m a 1.0.

1 Obecnie (lipiec 2013) ostatnia wersja Basic Profile nosi num er 2.0. Zainteresowanych czytelników odsyłam na stronę http://ws-i.org/Profiles/BasicProfile-2.0-2010-11-09.html — przyp. tłum.

1 4 .3 . U W A R U N K O W A N IA U M IE J S C O W IE N IA R D ZEN N Y C H S T A N D A R D Ó W SOA

423

O p r ó c z lis ty r e k o m e n d o w a n y c h s p e c y fik a c ji, B a s ic P r o file d o s ta r c z a ją ta k ż e w s k a z ó w e k d o t y ­ c z ą c y c h te g o , j a k p o w in n y — i j a k n ie p o w in n y — b y ć im p le m e n t o w a n e k o n k r e t n e e le m e n ty ty c h s p e c y fik a c ji. Są w ię c w ia r y g o d n y m p u n k t e m o d n ie s ie n ia d la d e fin io w a n ia s ta n d a r d ó w p r o je k t o ­ w y c h , u ła t w ia ją c y m u n ik a n ie p o te n c ja ln y c h p r o b le m ó w z w ią z a n y c h z in te r o p e r a c y jn o ś c ią i r o z ­ w ią z y w a n ie t a k ic h p r o b le m ó w , je ś li tr z e b a . P o n ie w a ż d o k u m e n t y B a s ic P r o f ile s a m e p o d le g a ją w e r s jo n o w a n iu , p r z y jm u ją c k o n k r e t n ą ic h w e r s ję ja k o p o d s ta w ę w ła s n e j s ta n d a r y z a c ji S O A , n a le ż y k o n ie c z n ie u p e w n ić s ię , iż w y k o r z y s ty ­ w a n e n a r z ę d z ia i t e c h n ik i są w p e łn i z g o d n ie z r e k o m e n d a c ją te jż e w e r s ji. O t o k i lk a p r o p o z y c ji s ta n d a r d ó w p r o je k t o w a n ia r e k o m e n d o w a n y c h p r z e z B a s ic P r o file . •

K o p e r t y S O A P n ie m o g ą z a w ie r a ć d e fin ic ji D T D (D o c u m e n t T y p e D e c la r a tio n s )

•

N ie z a le c a się u ż y w a n ia a t r y b u t u e n c o d in g S t y le w e w n ą t r z k o p e r t S O A P .

•

W y m a g a n e b lo k i n a g łó w k o w e k o m u n ik a t u S O A P p o w in n y b y ć w e r y fik o w a n e

a n i in s t r u k c ji p r z e tw a r z a n ia .

i p r z e t w a r z a n e w p ie r w s z e j k o le jn o ś c i, p r z e d p r z e t w o r z e n ie m b lo k ó w o p c jo n a ln y c h i tre ś c i k o m u n ik a t u . •

G d y w d e f in ic ji W S D L k o n s t r u k c ja p a r t ( z a g n ie ż d ż o n a w e w n ą t r z k o n s t r u k c ji m essag e) w y k o r z y s tu je a t r y b u t e le m e n t, je g o w a r to ś ć m u s i m ie ć p o s ta ć g lo b a ln e g o o d w o ła n ia .

•

K o le jn o ś ć e le m e n tó w z a g n ie ż d ż o n y c h w k o n s t r u k c ji Body k o m u n ik a t u S O A P m u s i b y ć id e n ty c z n a z k o le jn o ś c ią o d p o w ia d a ją c y c h i m k o n s t r u k c ji p a r t .

•

E le m e n t b in d in g m o ż e s p e c y fik o w a ć je d y n ie w ią z a n ie S O A P ( s o a p : b in d in g ) .

Z g o d n o ś ć d e fin ic ji W S D L z z a le c e n ia m i W S - I B a s ic P r o file je s t je j c e n n ą z a le tą , g o d n ą z a s to ­ s o w a n ia n a w e t w t e d y , g d y n ie w y n ik a b e z p o ś r e d n io z b ie ż ą c y c h w y m a g a ń . P o w r ó c im y d o te j k w e s tii w p u n k c ie 1 5 .5 .9 , „ K o n s e k w e n t n e z a c h o w y w a n ie z g o d n o ś c i z z a le c e n ia m i W S - I ” .

1 4 .3 .4 .

W SDL a SOA

T w o r z e n ie d e f i n ic j i W S D L to c e n t r a ln y p u n k t p r o c e s u p r o je k t o w a n ia u s łu g . K a ż d a d e fin ic ja W S D L je s t (a p r z y n a jm n ie j — p o w in n a b y ć ) p ie r w s z y m m a t e r ia ln y m p r z e ja w e m is t n ie n ia u s łu g i. Z b ió r d e f in ic ji W S D L to k o ń c o w y r e z u lt a t a n a liz y b iz n e s o w e j i a n a liz y te c h n o lo g ic z n e j, to je d n o ­ c z e ś n ie z e s ta w p u n k t ó w k o ń c o w y c h tw o r z ą c y c h n o w ą w a r s tw ę in f r a s t r u k t u r y p r z e d s ię b io r s tw a z o r ie n t o w a n e g o n a u s łu g i. P o n iż e j o p is u je m y k i l k a s z c z e g ó łó w z w ią z a n y c h z p r o je k t o w a n ie m W S D L w ra m a c h S O A . Z e s ta n d a ry z o w a n e w y k o rz y s ty w a n ie p r z e s tr z e n i n a z w D o k u m e n t y W S D L s k ła d a ją się z e le m e n tó w s k o ja r z o n y c h z r ó ż n y m i s p e c y fik a c ja m i — S O A P , X M L S c h e m a i s a m ą s p e c y fik a c ją W S D L — o r a z e le m e n tó w d e fin io w a n y c h p r z e z u ż y t k o w n ik ó w . B y n ie p o g u b ić się w ic h g ą s z c z u , k o n ie c z n ie tr z e b a p o ś w ię c ić b a c z n ą u w a g ę s ta n d a r y z a c ji p r z e ­ s tr z e n i n a z w . S z c z e g ó ło w e w s k a z ó w k i w t y m w z g lę d z ie p r z e d s ta w ia m y w p u n k c ie 1 5 .5 .6 , „ U w a ż n e w y k o r z y s t y w a n ie p r z e s tr z e n i n a z w ” .

424

RO ZD ZIA Ł 1 4 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ II. W Y TYC ZN E K O M P O N O W A N IA SOA)

M o d u l a r n e d e f i n ic j e u s łu g P o d o b n ie j a k w ie le s p e c y fik a c ji d o ty c z ą c y c h X M L i r o z s z e r z e ń W S - * , t a k s p e c y fik a c ja W S D L s t w o r z o n a z o s ta ła z u w z g lę d n ie n ie m m o ż liw o ś c i k o m p o n o w a n ia u s łu g . W p r a k ty c e u m o ż li w i a to w i e l o u ż y w a n ie d o k u m e n t ó w i c e n t r a li z o w a n ie z a r z ą d z a n ia n i m i . P o w r ó c im y d o te j k w e s t ii w p u n k c ie 1 5 .5 .5 , „ R o z w a ż m o d u la r y z a c ję d o k u m e n t ó w W S D L ” . K o m p a t y b i ln o ś ć g r a n u la c ji G r a n u la c ja in te r fe js u u s łu g i p o w in n a o d p o w ia d a ć g r a n u la c ji d o k u m e n t u X M L , je d n a k ż e z d e f i­ n io w a n e j u ż s t r u k t u r y d o k u m e n t ó w X M L m o g ą p o z o s ta w a ć n ie z g o d n e z d u c h e m p o d e jś c ia „ n a j­ p ie r w W S D L ” . P r z y p a d k i ta k ie , je ś li są w c z e ś n ie w y k r y t e , m o ż n a n iw e lo w a ć z a p o m o c ą r ó ż n y c h z a b ie g ó w p r o je k t o w y c h , n a p r z y k ła d tw o r z ą c d o d a tk o w e w a r s tw y a b s tr a k c ji u s łu g .

1 4 .3 .5 .

X M L Schem a a SOA

D e f in ic je X M L S c h e m a ( c z y li s c h e m a ty X S D ) to p o d s t a w o w y ś r o d e k z a p e w n ie n ia in te g r a ln o ś c i d a n y c h w a r c h ite k t u r a c h z o r ie n t o w a n y c h n a u s łu g i. W y k o r z y s t y w a n e są w e w n ę t r z n ie w w ie lu s p e c y fik a c ja c h W S - * , le c z z p e r s p e k ty w y S O A b a r d z ie j is t o tn a je s t ic h r o la w d e fin io w a n iu p u ­ b lic z n y c h m o d e li d a n y c h u s łu g . P o n iż e j p r z e d s t a w ia m y k i lk a c z y n n ik ó w d e c y d u ją c y c h o u m i e j­ s c o w ie n iu i w y k o r z y s t y w a n iu s c h e m a tó w X S D n a p o t r z e b y S O A . M o d u la r n e s c h e m a ty X S D S c h e m a ty X S D m o g ą b y ć p a r ty c jo n o w a n e n a m n ie js z e m o d u ły , in te g r o w a n e d y n a m ic z n ie w czasie w y k o n y w a n ia p r z y u ż y c iu in s tr u k c ji in c l ude (g d y w s z y s tk ie d o k u m e n ty s k ła d o w e n a le ż ą d o te j sa m e j p r z e s tr z e n i n a z w ) lu b in s t r u k c ji im p o r t ( w o g ó ln y m p r z y p a d k u ) . P o n ie w a ż d o k u m e n t y W S D L ta k ż e m o g ą b y ć z m o d u la r y z o w a n e , s c h e m a ty X S D z a w ie ra ją c e k o n s tr u k c je W S D L ty p e s m o g ą r e ­ z y d o w a ć w o s o b n y c h d o k u m e n ta c h . M o d u la r y z a c ja s c h e m a tó w u s ta n a w ia e la s ty c z n ą a r c h it e k tu r ę r e p r e z e n t o w a n ia d a n y c h , w p i­ s u ją c ą się z n a k o m ic ie w k o m p o n o w a ln y ś w ia t S O A . M o d u ł y s c h e m a tó w X S D m o g ą b y ć w ie l o ­ k r o t n i e u ż y w a n e , n a p r z y k ł a d p r z e z r ó ż n e d e fin ic je W S D L u s łu g p r z e t w a r z a ją c y c h k o m u n ik a t y o ta k ie j s a m e j lu b z b liż o n e j s t r u k tu r z e ła d u n k u u ż y te c z n e g o . C o w ię c e j, s c h e m a ty X S D u k ie r u n ­ k o w a n e n a p o d m i o t y (e n c je ) m o g ą b y ć z a p r o je k t o w a n e d o r e p r e z e n t o w a n ia s p e c y fic z n y c h i n ­ f o r m a c ji o d p o w ia d a ją c y c h k o r p o r a c y jn y m m o d e lo m p o d m io t ó w . S ta n o w i to b e z p o ś r e d n ie w s p a rc ie d la b iz n e s o w y c h a s p e k tó w w s p ó łc z e s n e g o S O A , p o p r z e z im p le m e n t a c ję w a r s t w y b iz n e s o w y c h u s łu g p o d m io t o w y c h . K o m u n i k a t y w s t y lu d o k u m e n t o w y m a s c h e m a t y X S D W y m a g a n e p r z e z S O A k o m u n ik a t y S O A P w s ty lu d o k u m e n t o w y m c e c h u ją się z w y k le d u ż y m ła ­ d u n k ie m in te lig e n c ji i ja k o ta k ie w y m a g a ją s z c z e g ó ln e j tr o s k i p o d k ą te m z a w a n s o w a n y c h w a lid a c ji. Is t n ie je p r z y k ła d o w o te n d e n c ja d o g r u p o w a n ia w ie lu r ó ż n y c h d a n y c h X M L w p o je d y n c z y k o m u ­ n ik a t S O A P . W n ie k t ó r y c h je d n a k s y tu a c ja c h — n a p r z y k ła d w t e d y , g d y d a n y d o k u m e n t r e p r e z e n to w a ć m a w ie le k o n te k s tó w d a n y c h — n a w e t z a a w a n s o w a n e m e c h a n iz m y ję z y k a X S D o k a z u ją się n ie w y ­ s ta rc z a ją c e . P r z y d a ją się w ó w c z a s te c h n o lo g ie w s p o m a g a ją c e , n a p r z y k ła d X S L T (X S L T r a n s fo r ­

m a tio n s , E x te n s ib le S ty le sh e e t L a n g u a g e T r a n s fo r m a tio n s — p r z e k s z ta łc e n ia r o z s z e r z a ln e g o ję z y k a a r k u s z y s ty ló w ) c z y r o z s z e r z e n ia z w ią z a n e z w a lid a c ja m i w a r u n k o w y m i.

1 4 .3 . U W A R U N K O W A N IA U M IE J S C O W IE N IA R D ZEN N Y C H S T A N D A R D Ó W SOA

1 4 .3 .6 .

425

SOAP a SOA

K o m u n ik a t y S O A P są n ic z y m p a liw o n a p ę d z a ją c e s iln ik i w s p ó łc z e s n e j S O A . Są w ię c d la ś r o d o w i­ s k a z o r ie n to w a n e g o n a u s łu g i t a k s a m o w a ż n e j a k d e fin ic je W S D L . O t o d w a a s p e k ty f r a m e w o r k u k o m u n ik a c y jn e g o S O A P , n a k t ó r e S O A m a n a jw ię k s z y w p ły w . S t y le k o m u n i k a t ó w S O A P a t y p y d a n y c h P r z y p u s z c z a ln ie n a jw ię k s z y w p ły w S O A n a is tn ie ją c ą p o s ta ć f r a m e w o r k u S O A P p r z e ja w ia się w p r e fe r o w a n e j p r z e z S O A s tr u k t u r z e ła d u n k u u ż y te c z n e g o i s y s te m ie t y p ó w d a n y c h . O d n o s i się to s z c z e g ó ln ie d o a tr y b u tu s t y l e e le m e n tu s o a p :b in d in g i a tr y b u tu use e le m e n tu s o a p :b o d y , o c z y m p is a liś m y j u ż w p o d r o z d z ia le 1 3 .3 , „ P o d s ta w y ję z y k a W S D L ” , i p is a ć b ę d z ie m y w p u n k c ie 1 5 .5 .7 , „ S ty l d o k u m e n t o w y i lit e r a ln y f o r m a t k o m u n ik a t ó w S O A P ” . P o n ie w a ż w p r o w a d z e n ie S O A d o ś r o d o w is k a r o z p r o s z o n e g o o p a r te g o n a k o m u n ik a c ji w s ty lu R P C p o z b a w ia u ż y t k o w n ik a w ie lu k o r z y ś c i o f e r o w a n y c h p r z e z s p e c y fik a c je W S - * w s to s u n k u d o ła d u n k ó w u ż y te c z n y c h w s ty lu d o k u m e n t o w y m , p e w n e z m ia n y w e w s p o m n ia n y m ś r o d o w is k u są a b s o lu tn ie k o n ie c z n e . P r z y k ła d o w o p o d e jś c ie o p a r te n a R P C p r e fe r u je tr a n s m is ję d r o b n o z ia r n i­ s ty c h d o k u m e n t ó w X M L z a w ie r a ją c y c h „ u k ie r u n k o w a n e ” d a n e , co p r z e k ła d a się n a t w o r z e n ie w ie lu m a ły c h d o k u m e n t ó w X M L w s ty lu p a r a m e tr y c z n y m . N a le ż y w ię c te „ d r o b n e ” d o k u m e n t y p o łą c z y ć w je d e n b a r d z ie j o b ję to ś c io w y , w c e lu w s p a r c ia d la g r u b o z ia r n is te g o m o d e lu k o m u n i ­ k a t ó w w s ty lu d o k u m e n t o w y m . D o w y k o n a n ia te g o łą c z e n ia k o n ie c z n e m o ż e b y ć u ż y c ie z m o d u la r y z o w a n y c h s c h e m a tó w X S D , b o p o s z c z e g ó ln e d o k u m e n t y ź r ó d ło w e m o g ą b y ć s k o ja r z o n e z r ó ż n y m i s c h e m a ta m i. J e d n a k i m w ię k s z e p o d o b ie ń s t w a m ię d z y n i m i , t y m g e n e r a ln ie m n ie j s k o m p lik o w a n e o k a z u je się o p is a n e łą c z e n ie . N a g łó w k i S O A P D e f in i c ja W S D L u s łu g i, j a k ju ż w s p o m in a liś m y , s ta n o w i p ie r w s z e m a t e r ia ln e ś w ia d e c tw o je j is t­ n ie n ia . Je śli c h o d z i o w y m ia n ę k o m u n ik a t ó w p r z e z tę u s łu g ę , to w d e fin ic ji W S D L je s t o n a o k r e ­ ś lo n a je d y n ie c z ę ś c io w o : p o d c z a s g d y d e fin ic je t y p ó w X S D o k re ś la ją s tr u k tu r ę c ia ła k o m u n ik a t u ( w r a m a c h k o n s tr u k c ji Body), to n ie d o s ta rc z a ją z w y k le in f o r m a c ji n a te m a t b lo k ó w n a g łó w k o w y c h S O A P im p le m e n t o w a n y c h p o p r z e z r o z s z e r z e n ia W S - * . M o ż liw o ś ć w b u d o w y w a n ia m e ta d a n y c h w b lo k i n a g łó w k o w e S O A P u w a ln ia u s łu g i o d k o ­ n ie c z n o ś c i u t r z y m y w a n ia lo g ik i s p e c y fic z n e j d la k o n k r e tn y c h s c e n a riu s z y w y m ia n y k o m u n ik a tó w . R e p e r tu a r i p o s ta c i ty c h n a g łó w k ó w z a le ż ą w g łó w n e j m ie r z e o d z e s ta w u r o z s z e r z e ń W S - * im p le ­ m e n t o w a n y c h w ś r o d o w is k u h o s tu ją c y m u s łu g i. T a k w ię c id e n ty fik a c ja i d e fin io w a n ie n a g łó w k ó w S O A P je s t ściśle u z a le ż n io n e o d k s z ta łtu k o n k r e tn e g o e g z e m p la r z a S O A i w s p ie r a n y c h p r z e z e ń s p e c y fik a c ji W S - * . O d z e s ta w u ty c h s p e c y fik a c ji z a le ż y o g ó ln y k s z ta łt f r a m e w o r k u k o m u n ik a c y jn e g o S O A P i — w k o n s e k w e n c ji — s t o p ie ń , w j a k i m k o m u n ik a t y o k a z u ją się s a m o w y s ta r c z a ln e n a s w e j tra s ie p r z e t w a r z a n ia . T o z k o le i je d e n z p o d s ta w o w y c h c z y n n ik ó w k s z ta łtu ją c y c h p o s ta ć p r o je k t o w a ­ n y c h u s łu g .

426

RO ZD ZIA Ł 1 4 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ II. W Y TYC ZN E K O M P O N O W A N IA SOA)

1 4 .3 . 7 . P r z e s tr z e n ie n a z w a S O A In f o r m a c ją , k t ó r ą ła tw o p r z e o c z y ć w p ro c e s ie b u d o w a n ia S O A , je s t o r g a n iz a c ja lo g ik i p r z e d s ię ­ b io r s t w a w p o s ta c i s y s te m u d o m e n , p r z e ja w ia ją c a się w s p o s o b ie u ż y w a n ia p r z e s tr z e n i n a z w . N a g ru n c ie S O A p rz e s trz e n ie n a z w n ie m o g ą b y ć d e fin io w a n e w sp o só b c a łk o w ic ie d o w o ln y , le c z m u s z ą b y ć p o s trz e g a n e ja k o id e n ty fik a to r y d o m e n (b iz n e s o w y c h i te c h n o lo g ic z n y c h ) i w ła ś c iw ie u ż y w a n e d o k w a lif ik o w a n ia o d n o ś n y c h e le m e n tó w X M L . D o k u m e n t y W S - I B a s ic P r o file d o s ta r c z a ją k i lk u u ż y te c z n y c h w s k a z ó w e k i z a le c a n y c h p r a k ­ t y k d o ty c z ą c y c h im p le m e n t o w a n ia p r z e s t r z e n i n a z w w e w n ą t r z d e fin ic ji W S D L . O c z y w iś c ie , s to ­ s o w a n ie p r z e s tr z e n i n a z w n ie o g r a n ic z a się d o d e fin ic ji W S D L , k o n ie c z n e je s t z a te m o p r a c o w a n ie d o d a t k o w y c h z a s a d w y k o r z y s t y w a n ia p r z e s t r z e n i n a z w ( i g e n e r a ln ie d o k u m e n t ó w X M L ) p o z a t y m i d e fin ic ja m i. K ilk a u w a g n a t e n t e m a t z a m ie s z c z a m y w p u n k c ie 1 5 .5 .6 , „ U w a ż n e w y k o r z y ­ s ty w a n ie p r z e s t r z e n i n a z w ” .

1 4 .3 .8 . U D D I a S O A U D D I to p r z e m y s ło w y s ta n d a r d o r g a n iz o w a n ia o p is ó w u s łu g w f o r m ę r e je s tr ó w , u ła tw ia ją c y c h w y s z u k iw a n ie ż ą d a n y c h u s łu g p r z e z ic h p o te n c ja ln y c h k o n s u m e n t ó w . Z a im p le m e n t o w a n y U D D I r e p r e z e n tu je z w y k le k o m p o n e n t , g lo b a ln y w s k a li p r z e d s ię b io r s tw a , u m ie js c o w io n y c e n tr a ln ie n a p o t r z e b y w y k r y w a ln o ś c i u s łu g w e w n ą t r z S O A . T a k w ię c , z a le ż n ie o d z a k r e s u p r o je k t o w a n e j a r c h it e k t u r y ( n a p o z io m ie a p lik a c ji, g lo b a ln y w p r z e d s ię b io r s t w ie i t d .) U D D I m o ż e s ta ć s ię je d n ą z t e c h n o lo g ii ś r o d o w is k a z o r ie n t o w a n e g o n a u s łu g i. C h o c ia ż U D D I z n a k o m ic ie s p is u je się w s w e j r o li i n a w e t je s t s p e c y fik a c ją r e k o m e n d o w a n ą p r z e z B as ic P r o file , n ie k tó r e p r z e d s ię b io rs tw a z w r a c a ją się k u tr a d y c y jn y m t e c h n ik o m k a ta lo g o w y m ( n a p r z y k ła d L D A P ) n a p o tr z e b y z a r z ą d z a n ia o p is a m i w ła s n y c h u s łu g . N ie z a le ż n ie je d n a k o d k o n k r e t n y c h ś r o d k ó w z a p e w n ia ją c y c h w y k r y w a ln o ś ć u s łu g , n a le ż y p r z e d e w s z y s tk im u w z g lę d n ić c z y n n ik w y k r y w a ln o ś c i n a p o z io m ie p r o je k t o w a n ia s a m y c h u s łu g , n a d a ją c k la r o w n ą p o s ta ć ic h in t e r fe js o m i c z y te ln ie d o k u m e n t u ją c p o w ią z a n e m e ta d a n e . P is z e m y o t y m o b s z e rn e j w p u n k c ie 1 5 .5 .9 . „ D o k u m e n t o w a n ie u s łu g z a p o m o c ą m e t a d a n y c h ”.

A N A LIZA PRZYPADKU W s z y s tk o , co d o b r e , k ie d y ś się k o ń c z y — częs to p o to , b y u s tą p ić m ie js c a le p s z e m u . W d ą ż e n iu d o z b u d o w a n ia ś r o d o w is k a n a c e c h o w a n e g o o r ie n ta c ją n a u s łu g i o d s a m e g o p o c z ą tk u w fir m ie R a ilC o z d e c y d o w a n o o r e z y g n a c ji z a r c h it e k t u r y h o s tu ją c e j d o ty c h c z a s o w e u s łu g i s ie c io w e . I p r z y g o t o w a n ia r u s z y ły p e łn ą p a rą . 1.

P o p r z e a n a liz o w a n iu u ż y w a n y c h f o r m a t ó w d a n y c h X M L s t w ie r d z o n o , iż n ie p r z y s ta ją o n e d o o b e c n y c h p o tr z e b f ir m y , s a m o zaś p r z e tw a r z a n ie d o k u m e n t ó w X M L o d b y w a się w s p o s ó b d a le k i o d s ta n d a r y z a c ji. W r a m a c h n o w e g o p r o je k t u z d e f in io w a n o n o w e re p r e z e n ta c je d a n y c h X M L , s p e c y fik u ją c s c h e m a ty X S D o d z w ie r c ie d la ją c e k o r p o r a c y jn e in f o r m a c je w y m ie n ia n e z a p o m o c ą ( p la n o w a n y c h ) k o m u n ik a t ó w S O A P w s ty lu d o k u m e n to w y m .

1 4 .3 . U W A R U N K O W A N IA U M IE J S C O W IE N IA R D ZEN N Y C H S T A N D A R D Ó W SOA

2.

427

Ja ko p r e f e r o w a n y m o d e l k o m u n ik a c ji w y b r a n o n ie k o d o w a n e (lit e r a ln e ) k o m u n ik a t y S O A P w s ty lu d o k u m e n t o w y m . W y k o n a n o ta k ż e p r z e g lą d u ż y w a n y c h d o tą d n a r z ę d z i p r o g r a m is t y c z n o - p r o je k t o w y c h i s e r w e r ó w a p lik a c ji p o d k ą t e m z g o d n o ś c i z t y m m o d e le m k o m u n ik a c ji — i n ie o c z e k iw a n ie o d k r y to , ż e je d e n z k o m p o n e n t ó w z d o ln y je s t d o p r z e t w a r z a n ia je d y n ie k o m u n ik a t ó w S O A P w s ty lu R P C . S z c z ę ś liw ie je d n a k w y m ia n a te g o k o m p o n e n t u n ie p o w in n a o k a z a ć się a n i k o s z to w n a , a n i z b y t k ło p o t liw a , ja k o że w f ir m i e n ie fu n k c jo n u ją in n e r o z w ią z a n ia z o r ie n t o w a n e n a u s łu g i.

3.

Z e s ta n d a r y z o w a n o p r z e s tr z e n ie n a z w w s p o s ó b o d z w ie r c ie d la ją c y p la n o w a n e d e fin ic je W S D L i s c h e m a ty X S D .

4.

Z d e c y d o w a n o w r e s z c ie , iż n ie tr z e b a im p le m e n t o w a ć w r a m a c h b u d o w a n e j S O A k o m p o n e n t u w s p o m a g a ją c e g o w y k r y w a n ie u s łu g , e lim in u ją c t y m s a m y m U D D I z z e s ta w u im p le m e n t o w a n y c h r d z e n n y c h te c h n o lo g ii.

O s ta te c z n ie te c h n o lo g ic z n y k s z t a łt p r o je k t o w a n e j S O A p r z e d s t a w ia się ta k , j a k n a r y ­ s u n k u 1 4 .6 .

W f ir m i e T L S a n a lo g ic z n y p ro c e s r o z p o c z ą ł się j u ż w c z e ś n ie j i są je g o o w o c e , c z y li p ie r w ­ sze r o z w ią z a n ie z o r ie n to w a n e n a u s łu g i ( p is a liś m y o t y m w r o z d z ia le 1 2 .). P o n ie w a ż o b e c n y k s z ta łt S O A d e te r m in u je d o g łę b n a a n a liz a z s tę p u ją c a , p o p r z e d z a ją c a je g o s k o n s tr u o w a n ie , a r c h ite k c i T L S m a ją n a d z ie ję , iż a r c h ite k tu r a n ie b ę d z ie w y m a g a ła r e w a lu a c ji w r a m a c h p r z y ­ szłe g o r o z w o ju .

P O D S U M O W A N IE •

Dokum enty WS-I Basic Profile dostarczają użyteczne wskazówki dotyczące w ykorzystywania poszczególnych wersji rdzennych specyfikacji SOA — XM L, X M L Schema, WSDL, SOAP i UDDI.

•

SOA narzuca określone w ym agania i stwarza pew ne preferencje w zakresie wykorzystywania i umiejscawiania tych podstawowych specyfikacji w budow anej architekturze.

428

RO ZD ZIA Ł 1 4 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ II. W Y TYC ZN E K O M P O N O W A N IA SOA)

1 4 .4 . U w a ru n k o w a n ia w y b o ru ro zs ze rze ń SO A W r a m a c h k r o k ó w 2 1. i 2. s k o m p o n o w a liś m y j u ż z e s ta w r d z e n n y c h s ta n d a r d ó w S O A i z d e f in i o ­ w a liś m y p la n o w a n e w a r s t w y u s łu g . P o r a z a t e m n a k r o k 3 ., w r a m a c h k tó r e g o s k o m p o n u je m y k o n k r e t n ą o d m ia n ę w s p ó łc z e s n e j S O A ( p a t r z r y s u n e k 1 4 .7 ). Rozszerzenia

Usfugi sieciowe

Reprezentacja danych w standardzie XML

Platforma dostawcy

Rysunek 14.7. Odpowiednio wybrany zbiór rozszerzeń WS-* nadaje budowanemu SOA konkretny, unikatowy kształt

1 4 .4 .1 .

S e l e k c ja c h a r a k t e r y s t y k i S O A P

Ja k ju ż w ie lo k r o t n ie p is a liś m y , p ie r w o t n a S O A o p ie r a się n a z a s a d a c h o r ie n ta c ji n a u s łu g i o d ­ z w ie r c ie d la ją c y c h k o r z e n ie k o n c e p c y jn e b u d o w a n e g o ś r o d o w is k a . G d y je d n a k z a c z n ie m y r o z w a ż a ć m o ż liw o ś c i r o z s z e r z a n ia p r o c e s ó w b iz n e s o w y c h i ś r o d o w is k a p lik a c y jn y c h , ic h k o m p o n o w a n ia c z y n a w e t r e k o n f ig u r a c ji, d o p ie r o w ó w c z a s p r a w d z iw y p o t e n c ja ł S O A z a c z n ie s ię m a n if e s t o w a ć w w id o c z n e j p o s ta c i. W r o z d z ia le 3. p r z e d s ta w iliś m y lis tę p o d s ta w o w y c h c e c h w s p ó łc z e s n e j S O A , a w r o z d z ia le 9. z a s ta n a w ia liś m y się n a d c z y n n ik a m i m a ją c y m i z a s a d n ic z y w p ły w n a je j k s z t a łt — k o n k lu d u ją c , iż są n im i: •

z a s a d y z o r ie n t o w a n ia n a u s łu g i,

•

k o n c e p c je p ie r w s z e j g e n e r a c ji u s łu g s ie c io w y c h ,

•

k o n c e p c je d e fin io w a n e w r a m a c h r o z s z e r z e ń W S - * .

W p o p r z e d n ic h p u n k t a c h te g o r o z d z ia łu p is a liś m y o r d z e n n y c h s ta n d a r d a c h im p le m e n t u j ą ­ c y c h w y b r a n e z a s a d y o r ie n ta c ji n a u s łu g i z a p o ś r e d n ic tw e m s p e c y fik a c ji z w ią z a n y c h z p ie r w s z ą g e n e r a c ją u s łu g s ie c io w y c h o r a z s ta n d a r d e m X M L . I c h o ć is tn ie je p e w n a d o w o ln o ś ć w w y b o r z e t y c h s ta n d a r d ó w ( U D D I n a te n p r z y k ła d c z ę s to n ie je s t im p le m e n t o w a n y ) , to je d n a k te r d z e n n e s t a n d a r d y g e n e r a ln ie f o r m u j ą p o w s z e c h n ie a k c e p to w a ln ą f u n d a m e n t a ln ą a r c h ite k tu r ę i ja k o ta k ie u w a ż a n e są z a o b o w ią z k o w e k o m p o n e n t y w s p ó łc z e s n e j S O A .

2 W kategoriach rysunku 14.1 — przyp. tłum.

1 4 .4 . U W A R U N K O W A N IA W Y B O R U ROZSZERZEŃ SOA

429

Z k o le i w ię k s z o ś ć c e c h c h a r a k te r y s ty k i w s p ó łc z e s n e j S O A , k t ó r y m p o ś w ię c iliś m y r o z d z ia ł 9., to c e c h y o p c jo n a ln e — w y b ie r a się ty lk o te z n ic h , k t ó r e o k a z u ją się p o t r z e b n e w k o n k r e t n e j i m ­ p le m e n ta c ji S O A . T a k w ła ś n ie m a n ife s tu je się k o m p o z y c y jn a n a tu r a k o n c e p c ji S O A . W r e z u lta c ie , d e c y z je , k tó r e p r z y c h o d z i n a m p o d e jm o w a ć , a d o ty c z ą c e d o c e lo w e g o k s z ta łtu S O A , d e t e r m in o ­ w a n e są w z n a c z ą c e j m ie r z e m o ż liw o ś c ia m i s p e łn ie n ia p o s z c z e g ó ln y c h w y m a g a ń p r z e z p o s z c z e ­ g ó ln e c e c h y w s p ó łc z e s n e j S O A . Z a le c a n e je s t z a t e m z id e n t y f ik o w a n ie ty c h c e c h p ie r w o t n e j S O A , k t ó r y m w s p a r c ie i p r o m o c ję c h c e m y z a p e w n ić z a p o ś r e d n ic tw e m p la n o w a n y c h u s łu g . G d y b u d u je się S O A n a p o z io m ie a p li­ k a c y jn y m , p r z e z n a c z o n ą d o r e z y d o w a n ia w r a m a c h g lo b a ln e j S O A k o r p o r a c y jn e j, id e n t y f ik a c ja ta je s t ju ż w z a s a d z ie d o k o n a n a ; g d y je d n a k b u d u je m y s w o ją p ie r w s z ą S O A o d p o d s ta w , m a o n a z n a c z e n ie k r y t y c z n e i w a r t o w y k o n a ć ją je s z c z e p rz e d p r z y s t ą p ie n ie m d o p r o je k t o w a n ia in t e r f e j­ s ó w u s łu g .

1 4 . 4 . 2 . S e l e k c ja s p e c y f i k a c j i W S - * T o w ła ś n ie s p e c y fik a c je W S - * s ta n o w ią ś r o d k i im p le m e n t o w a n ia n a s z y c h s p e c y fic z n y c h w y m a ­ g a ń a u to m a ty z a c y jn y c h n a f u n d a m e n c ie , o k t ó r y m p is a liś m y w p o p r z e d n im p u n k c ie . G d y z a te m r o z p o z n a m y z b ió r c e c h , k tó r e z r e a liz o w a ć c h c e m y z a p o m o c ą p la n o w a n e j a r c h it e k t u r y , r o z p o ­ c z y n a m y e k s p lo r a c ję k r a in y w s p o m n ia n y c h r o z s z e r z e ń w c e lu w y b r a n ia ty c h , k tó r e z p e r s p e k ty w y n a s z y c h p o tr z e b o k a ż ą się s z c z e g ó ln ie p r z y d a tn e . T a k się je d n a k s k ła d a , iż w y b ó r te n d a le k i je s t o d k o m f o r t u p o r ó w n y w a ln e g o z z a z n a c z e n ie m ż ą d a n y c h o p c ji n a f o r m u l a r z u i k lik n ię c ie m p r z y c is k u Z a s to s u j . K r a in a r o z s z e r z e ń to n ie p o m n ik k u lt u r y a n ty c z n e j c z y s k a m ie n ia ło ś ć , le c z ś w ia t ż y w y i e w o lu u ją c y . Jego n ie u s t a n n a z m ie n n o ś ć p o w o d u je , że w s p a r c ie , ja k ie g o d la p o s z c z e g ó ln y c h r o z s z e r z e ń u d z ie la ją r ó ż n i p r o d u c e n c i s p rz ę tu i o p r o g r a m o w a n ia , s ta je się w d u ż y m s t o p n iu n ie s p ó jn e . C o w ię c e j, d o p ó k i d a n a s p e c y fik a c ja n ie z o s ta n ie w p e łn i z a im p le m e n t o w a n a n a p la t f o r m ie d a n e g o p r o d u c e n ta , t r u d n o p o d d a w a ć j ą j a ­ k ie jś w e r y f ik a c ji c z y p o r ó w n y w a n iu z k o n k u r e n c y jn y m i im p le m e n t a c ja m i. D o c h o d z im y z a te m d o k o le jn e g o is to tn e g o c z y n n ik a , c z y li p o z io m u d o jr z a ło ś c i k o n k r e t n e j s p e c y fik a c ji. W z m ie n n y m ś w ie c ie S O A e g z y s tu ją z a r ó w n o s p e c y fik a c je p o z o s ta ją c e w s ta n ie w y ­ so ce s t a b iln y m , j a k i s p e c y fik a c je o d u ż y m s to p n iu u lo tn o ś c i. Z t y m w ią ż e się z r ó ż n ic o w a n y s to ­ p ie ń a k tu a ln e g o w s p a r c ia d la p o s z c z e g ó ln y c h r o z s z e r z e ń u r ó ż n y c h p r o d u c e n tó w , w t y m p r z e d e w s z y s tk im u p r o d u c e n t a , z k tó r e g o p r o d u k t ó w ju ż k o r z y s ta m y .

1 4 .4 .3 . W S -B P E L a S O A S p o ś ró d w s z y s tk ic h s p e c y fik a c ji W S - * n a s z c z e g ó ln ą u w a g ę z a s łu g u je w t y m m ie js c u W S - B P E L . Je st to je d n a z t y c h s p e c y fik a c ji, d la k t ó r y c h w ię k s z o ś ć d o s t a w c ó w z a p e w n ia s o lid n e w s p a r c ie . K ilk a k o n c e p c ji o p is y w a n y c h w r a m a c h te j s p e c y fik a c ji p r z e d s ta w ia liś m y ju ż w r o z d z ia le 6. p r z y o k a z ji o m a w ia n ia k o n c e p c ji o r k ie s tr a c ji.

W S - B P E L to je d n o c z e ś n ie p r z y k ł a d b iz n e s o w e g o ję z y k a o p e r a c y jn e g o , n ie z w y k le is to tn e g o w p r o c e s ie p r o je k t o w a n ia u s łu g , b o u m o ż liw ia ją c e g o t w o r z e n ie u s łu g p r o c e s o w y c h s k ła d a ją c y c h się n a w a r s tw ę o r k ie s tr a c ji ( p a t r z r y s u n e k 1 4 .8 ).

430

RO ZD ZIA Ł 1 4 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ II. W Y TYC ZN E K O M P O N O W A N IA SOA)

Rysunek 14.8. Specyfikacja WS-BPEL jako środek definiowania podwarstwy orkiestracji w warstwie abstrakcji usług P o d s ta w o w ą k o r z y ś c ią u ż y w a n ia ję z y k a W S -B P E L je s t m o ż liw o ś ć o p is a n ia z a je g o p o m o c ą p r o c e s u w o d e r w a n iu o d ja k ie jk o l w i e k k o n k r e t n e j te c h n o lo g ii im p le m e n t a c y jn e j. I n n ą p r z y c z y n ą , d la k tó r e j z w r a c a m y w ty m m ie js c u u w a g ę n a ję z y k W S -B P E L , je s t fa k t, iż u ż y je m y g o w ro z d z ia le 16. w r a m a c h a n a liz y p r z y p a d k u d o z a d e m o n s tr o w a n ia t w o r z e n ia w a r s tw y o r k ie s tr a c ji.

A N A LIZA PRZYPADKU O b e c n a s y tu a c ja R a ilC o n ie p o z w a la n a b u d o w a n ie p e r fe k c y jn e j S O A — w ię c t a k ie z a le ty u s łu g j a k w b u d o w a n a in te r o p e r a c y jn o ś ć z k o n ie c z n o ś c i u s tą p ić m u s z ą m ie js c a w z g lę d o m b a r d z ie j p r a k t y c z n y m . P o n a d to ż a d e n z p r o d u k t ó w s k ła d a ją c y c h się n a o b e c n e ś r o d o w is k o te c h n o lo g ic z n e R a ilC o n ie z a p e w n ia ju ż d a ls z e g o w s p a r c ia d la s p e c y fik a c ji W S - * w y k o r z y ­ s ty w a n y c h w o b e c n e j in f r a s t r u k t u r z e (o p is y w a n e j w r o z d z ia ła c h 6. i 7 .). J e d n o c z e ś n ie a r c h it e k c i c h c ie lib y z a p r o je k t o w a ć n o w e ś r o d o w is k o n a ty le p e r s p e k t y w ic z ­ n ie , b y u n ik n ą ć k o n ie c z n o ś c i je g o z n a c z ą c e j r e k o n s t r u k c ji w n a jb liż s z e j p r z y s z ło ś c i. P o p r z e ­ d y s k u to w a n iu k o r z y ś c i o fe r o w a n y c h p r z e z w s p ó łc z e s n ą S O A z d e c y d o w a li, że c e c h ą n a jw a ż ­ n ie js z ą z p u n k t u w id z e n ia p r z y s z ły c h c e ló w je s t r o z s z e r z a ln o ś ć b u d o w a n e g o r o z w ią z a n ia . W ie r z ą , że n o w e ś r o d o w is k o p o z w o li n a z r e a liz o w a n ie b ie ż ą c y c h w y m a g a ń , d a ją c się je d n o ­ c z e ś n ie o d p o w ie d n io r o z b u d o w y w a ć w p r z y s z ło ś c i, g d y p o ja w ią się n o w e w y m a g a n ia .

1 4 .4 . U W A R U N K O W A N IA W Y B O R U ROZSZERZEŃ SOA

43 1

J a k w y ja ś n ia liś m y w r o z d z ia le 9 ., r o z s z e r z a ln o ś ć n a le ż y d o ty c h c e c h w s p ó łc z e s n e j S O A , k t ó r e n ie są a u to m a ty c z n ie im p le m e n t o w a n e p r z e z s p e c y fik a c je W S - * i k t ó r y c h r e a liz a c ja s p o c z y w a g łó w n ie w g e s tii p r o je k t a n t ó w k o n k r e t n y c h r o z w ią z a ń (o t y m , j a k p o r a d z il i s o b ie z t y m p r o je k t a n c i R a ilC o , p is z e m y w n a s tę p n y m r o z d z ia le ). W T L S s y tu a c ja je s t z g o ła in n a — t a m fu n k c jo n u je ju ż p r a w d z iw a S O A , s ta n o w ią c a o w o c d o g łę b n e j a n a liz y , w s p o m a g a n a p r z e z s ta n d a r d y p r o je k to w e m a ją c e n a w z g lę d z ie p o d s ta w o w e c e c h y S O A , m i ę d z y i n n y m i w ie lo u ż y w a ln o ś ć , w y k r y w a ln o ś ć i in te r o p e r a c y jn o ś ć . N o w ą ja k o ś c ią , k tó r e j p r o p a g o w a n ie m w s w y m ś r o d o w is k u z a in te r e s o w a n e je s t T L S , je s t p a r a d y g m a t z o rie n to w a n e g o n a u s łu g i m o d e lo w a n ia b iz n e s o w e g o . Z e w z g lę d u n a n ie d o s tę p n o ś ć a d e k w a tn e g o s iln ik a o rk ie s tra c y jn e g o w czasie tw o r z e n ia o r y g in a ln e g o s y s te m u B 2 B w o b e c n y m r o z w ią z a n iu z o r ie n t o w a n y m n a u s łu g i ta k ż e n ie w y o d r ę b n io n o w a r s tw y o rk ie s tra c ji. J e d n a k o d c z a s ó w w s p o m n ia n e g o o r y g in a ln e g o s y s te m u z n a c z ą c o r o z w in ę ła się te c h n o ­ lo g ia o r a z w y d a t n ie z w ię k s z y ło się w s p a r c ie d la k lu c z o w y c h r o z s z e r z e ń W S - * — m ię d z y i n ­ n y m i d la s iln ik a o r k ie s tr a c ji W S -B P E L . W T L S z d e c y d o w a n o z a te m o z d e f in io w a n iu P r o c e s u r o z l i c z a n i a k a r t y c z a s u p r a c y w k a te g o r ia c h p r o c e s u W S -B P E L — c z e g o s z c z e g ó ła m i z a j­ m i e m y się w r o z d z ia le 16. N a r y s u n k u 1 4 .9 p r z e d s ta w io n o z e s ta w s p e c y fik a c ji s k ła d a ją c y c h się n a r o z s z e r z o n ą S O A w f ir m i e T L S .

Rysunek 14.9. Zbiorczy widok SOA planowanej w firmie TLS w związku z rozliczaniem kart czasu pracy

P O D S U M O W A N IE •

O rozszerzeniach niezbędnych dla budow anej SOA generalnie decyduje konieczność realizacji określonych cech współczesnej SOA.

•

Praktyczna możliwość im plem entow ania konkretnych rozszerzeń W S -* zależna jest zarów no od dojrzałości specyfikacji tych rozszerzeń, ja k i dostępnego dla nich wsparcia ze strony dostawców.

432

ROZDZIAŁ 14. ■ PROJEKTOWANIE ZORIENTOWANE NA USŁUGI (CZĘŚĆ II. WYTYCZNE KOMPONOWANIA SOA)

Projektowanie zorientowane na usługi (Część III. Projektowanie usług) 1 5 .1 . O p r o je k t o w a n iu u s łu g o g ó ln ie 1 5 .2 . P r o je k t o w a n ie b iz n e s o w y c h u s łu g p o d m io t o w y c h — k r o k p o k r o k u 1 5 .3 . P r o je k t o w a n ie u s łu g a p lik a c y jn y c h — k r o k p o k r o k u 1 5 .4 . P r o je k t o w a n ie b iz n e s o w y c h u s łu g z a d a n io w y c h — k r o k p o k r o k u 1 5 .5 . W y t y c z n e d la p r o je k t o w a n ia u s łu g

434

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

A b s o lu tn ie p ie r w s z y m k r o k ie m p r o je k t o w a n ia u s łu g i je s t z d e f in io w a n ie je j in te r fe js u — ta b e z ­ w z g lę d n a z a s a d a , p o w t a r z a n a n ic z y m m a n t r a p r z e z p r o je k t a n t ó w u s łu g s ie c io w y c h , s ta n o w i is to tę p o d e jś c ia „ n a jp ie r w W S D L ” i p o d s ta w ę k a ż d e g o z tr z e c h p r o c e s ó w o p is y w a n y c h w t y m ro z d z ia le . Jej p rz e s tr z e g a n ie p r z y c z y n ia się d o p o w s ta w a n ia w y s o c e z e s ta n d a r y z o w a n e j a r c h ite k tu r y z o r ie n t o ­ w a n e j n a u s łu g i, a ta k ż e je s t k o n ie c z n e d o r e a liz a c ji w ie lu c e c h c h a r a k te r y s ty k i w s p ó łc z e s n e j S O A . Je śli w ię c m o w a o k o r z y ś c ia c h p ły n ą c y c h z e w s p o m n ia n e j z a s a d y , to w y n i k a j ą o n e p r z e d e w s z y s tk im z fa k t u , iż in te r fe js u s łu g i je s t t w o r e m z n a c z n ie b a r d z ie j e la s ty c z n y m n iż ja k a k o lw ie k b a r d z ie j k o n k r e t n a p o s ta ć te j u s łu g i, a m ia n o w ic ie : •

u s łu g a m o ż e z o s ta ć z a p r o je k t o w a n a w s p o s ó b j a k n a jle p ie j o d z w ie r c ie d la ją c y k o n te k s t i fu n k c jo n a ln o ś ć je j k a n d y d a t u r y w y ło n io n e j w p ro c e s ie a n a liz y ;

•

o p e r a c jo m u s łu g i m o ż n a p r z y p o r z ą d k o w a ć n a z w y w y n ik a ją c e z p r z y ję ty c h k o n w e n c ji, co w e fe k c ie p r o w a d z i d o z e s t a n d a r y z o w a n y c h d e f in ic ji p u n k t ó w k o ń c o w y c h ;

•

is tn ie je d u ż a s w o b o d a w d o b o r z e g r a n u la c ji o p e r a c ji, co p r o w a d z i d o p r z e w id y w a ln y c h d e fin ic ji in t e r fe js ó w , a p o n a d t o u m o ż liw ia w ła ś c iw e w y w a ż e n ie k o m p r o m is u m ię d z y o b ję to ś c ią k o m u n ik a t ó w a n a tę ż e n ie m ic h w y m ia n y , s to s o w n ie d o s p e c y fik i d o c e lo w e j in f r a s t r u k t u r y ;

•

a p lik a c je p o d p o r z ą d k o w a n e z o s ta ją p r o je k t o m u s łu g , n ie o d w r o tn ie ; d la n o w o t w o r z o n y c h a p lik a c ji n ie je s t to p r o b le m e m , d la s ta rs z y c h a p lik a c ji, z w ła s z c z a k o m u n ik u ją c y c h się w s ty lu R P C , m o ż e b y ć k o n ie c z n e s tw o r z e n ie w t y m c e lu d o d a tk o w e j w a r s tw y a b s tr a k c ji w p o s ta c i fa s a d y 1;

•

a s ys ta d o ś w ia d c z o n y c h a n a lit y k ó w b iz n e s o w y c h w p r o je k t o w a n iu u s łu g b iz n e s o w y c h z p e w n o ś c ią o k a ż e się p o m o c n a w a d e k w a tn y m o d w z o r o w a n iu p r z e z n ie lo g ik i b iz n e s o w e j.

P r z e d s ta w io n e w t y m r o z d z ia le o p is y p r o c e s ó w m a ją c h a r a k te r g e n e r y c z n y i są je d y n ie su g e stią d o ty c z ą c ą s e r ii k r o k ó w s c e n a r iu s z a p r o je k t o w a n ia in t e r fe js u u s łu g i, c z y li p u n k t e m s ta r t o w y m , n a p o d s ta w ie k tó r e g o k o n k r e t n e o r g a n iz a c je d e fin io w a ć m o g ą w ła s n e , s p e c y fic z n e s c e n a riu s z e .

A n a l i z y p r z y p a d k ó w : Z a m ie s z c z o n e w t y m r o z d z ia le a n a liz y p r z y p a d k ó w m a ją z n a c z e n ie s z c z e g ó ln e , z a ic h p o m o c ą p r e z e n t u je m y f r a g m e n t y p r z y k ła d o w e g o k o d u w ję z y k a c h z n a c z ­ n ik o w y c h . F r a g m e n t y te ilu s tr u ją w y k o r z y s ta n ie w y b r a n y c h k a n d y d a t u r , w y ło n io n y c h w r o z ­ d z ia le 1 1 ., ja k o m a t e r ia łu w s tę p n e g o d la p r o c e s ó w p r o je k t o w a n ia k o n k r e t n y c h u s łu g . C z ę ś c ią t y c h p r o c e s ó w b ę d z ie t w o r z e n ie r ó ż n y c h d e f i n ic j i W S D L i p o w ią z a n y c h z n i m i s c h e m a tó w X S D . K o m p l e t n y k o d w s p o m n ia n y c h d e fin ic ji i s c h e m a tó w m o ż n a p o b r a ć z s e r­ w e r a F T P w y d a w n ic t w a H e li o n ftp :/ /f tp . h e lio n .p l/p r z y k la d y / s o a k o n .z ip .

1 Fasada (façade) to jeden z najpopularniejszych strukturalnych wzorców projektowych. Stanowi w ynik nałożenia prostego interfejsu na system złożonych obiektów, rządzący się zasadami bardziej skom plikowanym i lub nie­ kom patybilnym i w stosunku do wymagań klienta. Te skom plikowane zasady stają się dla klienta niewidoczne, do funkcjonalności wspomnianego systemu uzyskuje on dostęp wyłącznie za pośrednictwem rzeczonego interfejsu. C zytelnikom zainteresow anym szczegółam i zagadnienia polecam znakom itą m onografię autorstw a słynnej „bandy czworga” Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, wyd. Helion 2010, http://helion.pl/ksiazki/wzoele.htm ' — przyp. tłum.

1 5 .1 . O P R O JEK TO W A N IU USŁUG O G Ó LN IE

435

UW AGA Ostateczna postać kodu wspomnianych dokumentów przetestowana została pod kątem zgodności z zaleceniami WS-i Basic Profi/ew wersji 1.1.

1 5 .1 . O p ro je k to w a n iu usług o g ó ln ie O s ta te c z n y m c e le m o p is y w a n y c h w t y m r o z d z ia le p r o c e s ó w je s t u z y s k a n ie w y w a ż o n y c h p r o je k ­ t ó w u s łu g . P o d p o ję c ie m u s łu g i „ w y w a ż o n e j” r o z u m ie m y t u u s łu g ę s ie c io w ą p r z y s to s o w a n ą d o fu n k c jo n o w a n ia w o ta c z a ją c y m ś w ie c ie i je d n o c z e ś n ie : •

e n k a p s u lu ją c ą w y m a g a n ą p o r c ję lo g ik i,

•

z g o d n ą z z a s a d a m i o r ie n t a c ji n a u s łu g i,

•

s p e łn ia ją c ą z a ło ż o n e w y m a g a n ia b iz n e s o w e .

S p o g lą d a ją c n a (s to s u n k o w o r o z b u d o w a n ą ) lis tę k a n d y d a tu r n a u s łu g i, m o ż n a się z a s ta n a w ia ć , k t ó r ą z n ic h w z ią ć „ n a w a r s z ta t” ja k o p ie rw s z ą . N ie je s t to p y ta n ie b a n a ln e , b o p o k r ó t k im z a s ta n o ­ w ie n iu sta je się z r o z u m ia łe , iż k o le jn o ś ć p r o je k t o w a n ia p o s z c z e g ó ln y c h u s łu g u w z g lę d n ia ć m u s i z a ­ le ż n o ś c i p a n u ją c e m ię d z y n im i. I t a k o to p o ja w ia się z b ió r k a n d y d a tu r u p r z y w ile jo w a n y c h , o d k t ó ­ re g o n a le ż y za c z ą ć p r o je k to w a n ie — są to u s łu g i a g n o s ty c z n e i w ie lo u ż y w a ln e — tw o r z ą c z n ic h (ja k o u s ta lo n y c h ju ż z a s o b ó w ) s to s o w n e k o m p o z y c je , b ę d z ie m y m o g li a d e k w a tn ie w y r a ż a ć lo g ik ę s p ecy­ fic z n ą d la p ro c e s u , a je d n o c z e ś n ie w s p o m n ia n e u s łu g i n ie z o s ta n ą p o z b a w io n e ce ch w ie lo u ż y w a ln o ś c i. D o k ła d n ie j — w k a te g o r ia c h c z te r e c h t y p ó w w y o d r ę b n io n y c h p o p r z e d n io w a r s tw u s łu g s u g e ­ r o w a n a k o le jn o ś ć p r o je k t o w a n ia p r e z e n tu je się n a s tę p u ją c o . 1. B iz n e s o w e u s łu g i p o d m io t o w e . 2 . U s łu g i a p lik a c y jn e . 3 . B iz n e s o w e u s łu g i z a d a n io w e . 4 . U s łu g i p r o c e s o w e . P r o c e s y p r o je k t o w a n ia tr z e c h p ie r w s z y c h p o z y c ji o p is y w a n e są w t y m r o z d z ia le , p r o je k t o w a ­ n i e m u s łu g i p r o c e s o w e j z a jm i e m y się w r o z d z ia le n a s t ę p n y m . O c z y w iś c ie , z g o d n ie z w c z e ś n ie j­ s z y m z a s tr z e ż e n ie m p r z e d s t a w io n a k o le jn o ś ć je s t r a c z e j w s k a z ó w k ą n iż b e z w z g lę d n y m w y m o ­ g ie m , b o w r e a ln y m ś w ie c ie p r o je k t o w a n ie u s łu g n ie z a w s z e d a się t a k k la r o w n ie u p o r z ą d k o w a ć . P r z y k ła d o w o p o u t w o r z e n i u w s tę p n e j w e r s ji p r o je k t u u s łu g a p lik a c y jn y c h i p r z y s t ą p ie n iu d o p r o je k t o w a n ia o p e r a c ji u s łu g z a d a n io w y c h m o ż e się o k a z a ć , że o p e r a c je te n ie m o g ą z o s ta ć o d ­ w z o r o w a n e w w a r s tw ie a p lik a c y jn e j, b o ta p o z b a w io n a je s t o d p o w ie d n ic h d o te g o m e c h a n iz m ó w . W r a c a m y w ię c d o u s łu g a p lik a c y jn y c h , w k t ó r y c h p o ja w ia ją się w z w ią z k u z t y m n o w e o p e r a c je , a b y ć m o ż e n a w e t n o w e k o m p le t n e u s łu g i.

1 5 .1 .1 . S ta n d a r d y p r o je k to w a n ia N a le ż y w y r a ź n ie z a z n a c z y ć , ż e je d n y m z w a r u n k ó w o s ią g n ię c ia c e ló w p r o je k t o w a n ia je s t z d e f i­ n io w a n ie z b io r u c z y t e ln y c h s t a n d a r d ó w p r o je k t o w y c h . P r o je k t y u s łu g , w p r z e c iw ie ń s t w ie d o k a n d y d a t u r , m a ją ju ż k o n k r e t n y w y m i a r , a w ię c p o w in n y b y ć m o ż liw ie j a k n a jb a r d z ie j s p ó jn e ;

436

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

w p r z e c i w n y m r a z ie p o d s ta w o w e z a le t y S O A — w ie lo u ż y w a ln o ś ć , k o m p o n o w a ln o ś ć , a p r z e d e w s z y s tk im z w in n o ś ć o r g a n iz a c y jn a — m o g ą s ta n ą ć p o d z n a k ie m z a p y ta n ia . Z a t e m n a jp ie r w z d e ­ f i n i o w a n i e s t a n d a r d ó w p r o je k t o w y c h , a d o p ie r o p o t e m ( z g o d n e z n i m i ) p r o je k t o w a n ie . K i l k a w s k a z ó w e k , k t ó r e m o g ą o k a z a ć się p o m o c n e w d z ie le te g o d e f in io w a n ia , p r z e d s t a w ia m y w p o d ­ r o z d z ia le 1 5 .5 , „ W y t y c z n e d la p r o je k t o w a n ia u s łu g ” . W p ro c e s ie a n a liz y k w e s tia s ta n d a r d ó w p r o je k t o w y c h n ie b y ła t a k s iln ie a k c e n to w a n a — ic h p r z y d a tn o ś ć b y ła je d y n ie w s k a z ó w k ą , a n ie c z ę ś c ią p ro c e s u , j a k o b e c n ie . P o d s ta w o w ą te g o p r z y ­ c z y n ą b y ł fa k t, że k a n d y d a t u r y n a u s łu g i m o ż n a m o d y f ik o w a ć i u d o s k o n a la ć — i to b e z z n a c z ą c e ­ g o w p ły w u n a ic h fu n k c jo n o w a n ie — n a w e t w ó w c z a s , g d y s a m e u s łu g i są ju ż z a im p le m e n to w a n e . W fa z ie p r o je k t o w a n ia je s t in a c z e j: s t a n d a r d y p r o je k t o w a n ia są je j in t e g r a ln ą c zęś cią .

1 5 . 1 . 2 . O p is y p r o c e s ó w O p is y w a n e w t y m r o z d z ia le p r z y k ła d o w e p ro c e s y p r o je k t o w a n ia u s łu g s k ła d a ją się z g e n e r y c z n y c h s e k w e n c ji k r o k ó w u w y d a t n ia ją c y c h p o d s t a w o w e a s p e k ty te g o p r o je k t o w a n ia . M a m y o to o s ta tn ią sza n s ę u p e w n ie n ia się, że d la k a ż d e j z u s łu g n a le ż y c ie w y r a ż o n e z o s ta ły c e l i m o ż liw o ś c i. D la k a ż d e g o z t w o r z o n y c h p r z e z n a s a b s tr a k c y jn e g o o p is u u s łu g i z d e f in iu je m y t r z y f o r m a ln e c z ę ś c i je g o tw o r z e n ia : •

z d e f in io w a n ie w s z y s tk ic h o p e r a c ji,

•

z d e f in io w a n ie k o m u n ik a t ó w w e jś c io w y c h i w y jś c io w y c h d la k a ż d e j o p e r a c ji,

•

z d e f in io w a n ie s c h e m a tó w X S D n ie z b ę d n y c h d o r e p r e z e n t o w a n ia s t r u k t u r ła d u n k u u ż y te c z n e g o w s p o m n ia n y c h k o m u n ik a t ó w .

T w o r z o n e w t y m r o z d z ia le p r o je k t y u s łu g s k o m p o n o w a n e z o s ta n ą n a s tę p n ie w d e fin ic ję p r o ­ ce su , z g o d n ie ze s p e c y fik a c ją W S -B P E L , co o p is z e m y s z c z e g ó ło w o w r o z d z ia le n a s tę p n y m .

1 5 .1 .3 . P r z y g o to w a n ia Z g o d n ie z z a p o w ie d z ią z r o z d z ia łu 13 ., p ro c e s y p r o je k t o w a n ia u s łu g o p is y w a ć b ę d z ie m y p o d k ą te m r ę c z n e g o k o d o w a n ia , w z w ią z k u z c z y m w o p is a c h p o ja w ią się lic z n e o d w o ła n ia d o tw o r z o n e g o k o d u . P o n a d t o , d la le p s z e g o z r o z u m ie n ia w s p o m n ia n y c h p r o c e s ó w , w p r z y k ł a d o w y c h a n a li­ z a c h p r z y p a d k ó w p o ja w ią się c y ta ty f r a g m e n t ó w k o d u d e fin ic ji W S D L i s c h e m a tó w X S D . C z y t e l­ n ik o m s ła b o z n a ją c y m w y m ie n io n e ję z y k i p o le c a m y k r ó t k i p r z e w o d n ik , k t ó r y z a p r e z e n t o w a liś m y w r o z d z ia le 13.

A N A LIZA PRZYPADKU O b ie n a s z e f ik c y jn e f i r m y m a ją j u ż z a s o b ą e ta p a n a liz y n a d r o d z e d o b u d o w a n ia w ła s n y c h S O A . W k a ż d e j z n ic h w y o d r ę b n io n o s to s o w n e k a n d y d a t u r y n a u s łu g i, s ta n o w ią c e te r a z p o d ­ s ta w ę d o ro z p o c z ę c ia p ro c e s u p r o je k to w a n ia . W y b r a n e z n ic h s ta n ą się p r z e d m io t e m r o z w a ż a ń d a ls z e j c z ę ś c i te g o r o z d z ia łu . W w y n ik u p r z e p r o w a d z o n e g o w f ir m i e T L S m o d e lo w a n ia w y o d r ę b n io n o p ię ć k a n d y d a ­ t u r n a n a s tę p u ją c e u s łu g i tw o r z ą c e r o z w ią z a n ie r o z lic z a n ia c z a s u p ra c y :

1 5 .1 . O P R O JEK TO W A N IU USŁUG O G Ó LN IE

437

•

U s łu g a p r o c e s o w a r o z l i c z a n i a k a r t y c z a s u p r a c y ,

•

P r a c o w n ik (u s łu g a p o d m io t o w a ) ,

•

K a r t a c z a s u p r a c y (u s łu g a p o d m io t o w a ) ,

•

F a k t u r a (u s łu g a p o d m io t o w a ) ,

•

P o w ia d a m i a n ie (u s łu g a a p lik a c y jn a ).

Z g o d n ie z s u g e r o w a n ą w c z e ś n ie j k o le jn o ś c ią p r o je k t o w a n ia , n a p r z y s ło w io w y p ie r w s z y o g ie ń p ó jd ą t r z y u s łu g i p o d m io to w e . P o n ic h z a p r o je k to w a n a z o s ta n ie u s łu g a P o w ia d a m ia n ie , w r a z z i n n y m i n ie z b ę d n y m i u s łu g a m i a p lik a c y jn y m i. N a k o n ie c z d e f in io w a n a z o s ta n ie lo g ik a p r o c e s u b iz n e s o w e g o , c z y li U s łu g a p r o c e s o w a r o z l i c z a n i a k a r t y c z a s u p r a c y w y r a ż o n a z o ­ s ta n ie w ję z y k u W S -B P E L . W ś r ó d c a łe j te j a k ty w n o ś c i s k u p im y n a s z ą u w a g ę n a p r o je k t o w a n iu d w ó c h n a s tę p u ją c y c h u s łu g . •

K a n d y d a tu r a n a u s łu g ę P r a c o w n ik w y k o r z y s ty w a n a b ę d z ie w p r z y k ła d a c h to w a rz y s z ą c y c h o p is o w i p r o je k to w a n ia b iz n e s o w e j u s łu g i p o d m io to w e j ( w p o d r o z d z ia le 1 5 .2 ).

•

K a n d y d a t u r a n a U s łu g ę p r o c e s o w ą r o z l i c z a n i a k a r t y c z a s u p r a c y s ta n ie się p r z e d m io t e m a n a liz y lo g ik i p r z e p ły w u p r a c y , n ie z b ę d n e j d o z b u d o w a n ia p r a w id ło w e j k o m p o z y c ji u s łu g d la P r o c e s u r o z l i c z a n i a k a r t y c z a s u p r a c y ( w r o z d z ia le 1 6 .).

W

R a ilC o w y ło n io n o n a t o m ia s t k a n d y d a t u r y n a n a s tę p u ją c e c z t e r y u s łu g i a p lik a c y jn e

i d w ie u s łu g i z a d a n io w e : •

P r z e t w a r z a n ie f a k t u r y (u s łu g a z a d a n io w a ),

•

P r z e t w a r z a n ie z a m ó w ie n ia (u s łu g a z a d a n io w a ) ,

•

T r a d y c y j n y s y s te m (u s łu g a a p lik a c y jn a ) ,

•

O b s e r w o w a n ie f o l d e r u (u s łu g a a p lik a c y jn a ) ,

•

K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h (u s łu g a a p lik a c y jn a ),

•

K o n t r o l a m e t a d a n y c h (u s łu g a a p lik a c y jn a ) .

S p o ś ró d k a n d y d a tu r w y m ie n io n y c h w p r z y k ła d a c h te g o r o z d z ia łu w y k o rz y s ta n e z o s ta n ą d w ie . •

K a n d y d a t u r a n a u s łu g ę K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h p o s łu ż y d o ilu s t r a c ji p r o je k t o w a n ia u s łu g i a p lik a c y jn e j ( w p o d r o z d z ia le 1 5 .3 ).

K a n d y d a tu r a n a u s łu g ę P r z e t w a r z a n ie f a k t u r y p o s łu ż y d o c e ló w p r e z e n ta c ji p r o je k t o w a n ia b iz n e s o w e j u s łu g i z a d a n io w e j ( w p o d r o z d z ia le 1 5 .4 ).

P O D S U M O W A N IE •

Trzy opisywane w tym rozdziale procesy projektowania opierają się na podejściu „najpierw WSDL".

•

Standardy projektowe odgrywają krytyczną rolę w kształtowaniu procesu projektowania usług i są niezbędne do otrzymania spójnego stanu wynikowego SOA.

438

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

1 5 .2 . P ro je k to w a n ie b izn e s o w y c h usług p o d m io to w y c h — k ro k po kroku B iz n e s o w e u s łu g i p o d m io t o w e t w o r z ą w a r s tw ę u s łu g n a jm n ie j p o d a t n ą n a w p ły w y z e s tr o n y i n ­ n y c h w a r s tw . Z a d a n ie m ty c h u s łu g je s t r e p r e z e n to w a n ie o d p o w ie d n ic h p o d m io t ó w ( e n c ji) s k ła ­ d a ją c y c h się n a m o d e l b iz n e s o w y f ir m y . U s łu g i te są w y s o c e a g n o s ty c z n e — n ie ś w ia d o m e z a r ó w n o p r o c e s u b iz n e s o w e g o , n a r z e c z k tó r e g o są w y k o r z y s ty w a n e , j a k i r o z w ią z a n ia , w r a m a c h k tó r e g o f u n k c jo n u ją . Ic h r o lą je s t z a p e w n ia n ie i n n y m u s łu g o m i a p lik a c jo m d o s tę p u d o p o s z c z e g ó ln y c h p o d m io t ó w w s p o s ó b w ie lo u ż y w a ln y . U m ie js c o w ie n ie b iz n e s o w y c h u s łu g p o d m io t o w y c h w m o ­ d e lu lo g ik i p r z e d s ię b io r s tw a p o k a z a n o n a r y s u n k u 1 5 .1 .

Rysunek 15.1. Biznesowe usługi podmiotowe tworzące warstwę usług biznesowych P o n ie w a ż r e la c ja b iz n e s o w y c h u s łu g p o d m io t o w y c h d o in n y c h w a r s tw u s łu g je s t r a c z e j n ie p o ­ d z ie ln a , k o r z y s tn e je s t r o z p o c z ę c ie c a łe g o p r o c e s u p r o je k t o w a n ia w ła ś n ie o d n ic h . W t e n s p o s ó b z b u d u je m y a b s tr a k c y jn ą w a r s tw ę u s łu g , w o k ó ł k tó r e j u m ie js c a w ia n a b ę d z ie lo g ik a u s łu g i p r o c e ­ s o w e j i u s łu g a p lik a c y jn y c h .

1 5 .2 .1 .

P ro c e s

N a r y s u n k u 1 5 .2 p r z e d s t a w ia m y p o s z c z e g ó ln e k r o k i z a le c a n e j s e k w e n c ji p r o je k t o w a n ia w y s o k ie j ja k o ś c i in te r fe js u b iz n e s o w e j u s łu g i p o d m io t o w e j.

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

Rysunek 15.2. Proces projektowania biznesowej usługi podmiotowej

439

440

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

P r z e d s t a w io n a n a r y s u n k u k o le jn o ś ć k r o k ó w n ie je s t b e z w z g lę d n ie o b o w ią z u ją c a , a je d y n ie s u g e r o w a n a . P r z y k ła d o w o n i e k t ó r z y m o g ą p r e f e r o w a ć o k r e ś le n ie w s tę p n e j p o s t a c i in t e r f e js u u s łu g i p r z e d z d e f in io w a n ie m t y p ó w d a n y c h w y k o r z y s ty w a n y c h d o r e p r e z e n t o w a n ia c ia ła k o m u ­ n ik a t ó w a lb o n ie k ie d y c e lo w e m o ż e się o k a z a ć p r z e p r o w a d z e n ie s p e k u la ty w n e j a n a liz y d o ty c z ą c e j p o t e n c ja ln y c h s p o s o b ó w r o z b u d o w y w a n ia u s łu g i, z a n im w o g ó le r o z p o c z n ie się p r a c ę n a d je j i n ­ te r fe js e m . I są to c a łk o w ic ie p o p r a w n e p o d e jś c ia ; w a ż n e je s t, b y p r z y ję te s ta n d a r d y p r o je k to w e s to s o w a ­ n e b y ły je d n a k o w o d o w s z y s tk ic h o p e r a c ji u s łu g i i w s z y s tk ie w y m o g i z w ią z a n e z je j p r z e t w a r z a ­ n ie m z o s ta ły d o k ła d n ie z id e n ty fik o w a n e . A le n a r a z ie d o ś ć t e o r ii — r o z p o c z n ijm y p r o je k t o w a n ie u s łu g i p o d m io t o w e j.

A N A LIZA PRZYPADKU P o w r a c a m y d o ś r o d o w is k a T L S i b ie r z e m y n a w a r s z ta t k a n d y d a tu r ę n a u s łu g ę P r a c o w n ik ( p a t r z r y s u n e k 1 5 .3 ), w y ło n io n ą w p ro c e s ie m o d e lo w a n ia o p is a n y m w r o z d z ia le 12.

Rysunek 15.3. Kandydatura na usługę Pracownik K a n d y d a t u r ę tę w y m o d e lo w a n o z in t e n c ją u ła t w ie n ia g r u p o w a n ia o p e r a c ji u k ie r u n k o w a ­ n y c h p o d m io t o w o . O d u s łu g i P r a c o w n ik ja k o częś ci P r o c e s u r o z l i c z a n i a k a r t y c z a s u p r a c y o c z e k u je się w k ła d u w s p e łn ia n ie d w ó c h s p e c y fic z n y c h fu n k c ji. P ie r w s z a z n ic h to o k r e ś le n ie m a k s y m a ln e j lic z b y g o d z in , ja k ą d a n y p r a c o w n ik m a p r a w o p r z e p r a c o w a ć w c ią g u ty g o d n ia ; in f o r m a c ję tę m o ż n a u z y s k a ć , o d n a jd u ją c i o d c z y tu ją c r e ­ k o r d p r a c o w n ik a w f ir m o w e j b a z ie d a n y c h . D r u g ą f u n k c ją je s t a k t u a liz a c ja h is t o r ii p r a c o w ­ n ik a w e w s p o m n ia n e j b a z ie : j a k p a m ię ta m y z r o z d z ia łu 1 2 ., o d r z u c e n ie p r z e d s ta w io n e j p r z e z p r a c o w n ik a k a r t y c z a s u p r a c y k w it o w a n e je s t o d p o w ie d n ią a d n o ta c ją w te j h is t o r ii. W e fe k c ie m o d e lo w a n ia fu n k c je te s k o n k r e ty z o w a n e z o s ta ły p o d p o s ta c ią d w ó c h k a n d y ­ d a tu r n a o p e ra c je : •

P o b i e r z t y g o d n io w y l i m i t g o d z in ,

•

Z a k t u a l i z u j h is t o r ię p r a c o w n ik a .

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

441

T a k a w ła ś n ie k a n d y d a t u r a je s t w te j c h w ili m a t e r ia łe m w e jś c io w y m d o r o z p o c z ę c ia p r z e ­ k s z ta łc a n ia je j w b iz n e s o w ą u s łu g ę p o d m io t o w ą , z g o d n ie z p r z e d s t a w io n y m s c e n a r iu s z e m p r o c e s u p r o je k to w a n ia .

UW AGA Kandydatura na operację Pobierz ty g o d n io w y lim it g o d zin (która później przeobrazi się w operację P o b ie rzT y g o d n io w y L im itG o d zin ) to propozycja operacji niezwykle drobnoziarnistej. Generalnie należy dążyć do projektow ania operacji o większym stopniu ziarnistości, bo im większa ziarnistość, tym poten­ cjalnie mniejsze tem po w ym iany kom unikatów SOAP. Ze względu na prostotę postanowiliśm y jednak pozostawić tę operację, zwłaszcza że spełnia ona w ym agania naszego procesu biznesowego. Tematykę doboru odpow iedniej ziarnistości operacji om aw iam y w punkcie 1 5 .5 .3 , „Dobór odpow iedniej ziarni­ stości interfejsu".

K r o k 1 .: in w e n t a r y z o w a n ie is t n ie ją c y c h u s łu g W y ł o n io n e w p ro c e s ie m o d e lo w a n ia k a n d y d a t u r y n a u s łu g i s ta n o w ią w y n ik g r u p o w a n ia k a n d y ­ d a tu r n a o p e r a c je , w y n ik a ją c y c h b e z p o ś r e d n io z w y m a g a ń b iz n e s o w y c h , k t ó r e z k o le i s ta n o w ią p o d s ta w ę p r o c e s u a n a liz y z o r ie n t o w a n e j n a u s łu g i. W a r t o w ię c u p e w n ić się, c z y n ie k t ó r e ( a m o ż e — w s z y s tk ie ? ) e le m e n t y f u n k c jo n a ln o ś c i k r y ją c e się z a w s p o m n ia n y m i o p e r a c ja m i n ie z o s ta ły ju ż u w z g lę d n io n e w r a m a c h in n y c h u s łu g . Z a t e m p ie r w s z y m k r o k ie m p r o je k to w a n ia n o w e j u s łu g i p o w in n o b y ć s p ra w d z e n ie , c z y u s łu g a ta w o g ó le m a r a c ję b y tu . B y ć m o ż e o p e r a c je te j u s łu g i ( id e n ty c z n e lu b p o d o b n e ) is tn ie ją ju ż w r a ­ m a c h in n y c h u s łu g a lb o (to in te r e s u ją c e ) in n e u s łu g i s ta n o w ią o d p o w ie d n i k o n te k s t d la n o w y c h o p e r a c ji i t w o r z e n ie d la t y c h o p e r a c ji o d r ę b n e j u s łu g i n ie je s t u z a s a d n io n e .

A N A LIZA PRZYPADKU J a k p a m ię ta m y , w f ir m i e T L S p ie r w s z e z r o z w ią z a ń z o r ie n t o w a n y c h n a u s łu g i s k o n s tr u o w a n e z o s ta ło ja k o d e fa c to in te r fe js u s łu g o w y d la is tn ie ją c e g o s y s te m u B 2 B . Z b u d o w a n o je w o p a r ­ c iu o g r u n t o w n ą a n a liz ę z s tę p u ją c ą , m a o n o z a t e m f o r m ę k o le k c ji b iz n e s o w y c h u s łu g p o d ­ m io t o w y c h . A r c h it e k c i p r z y s tę p u ją c y d o p r o je k t o w a n ia d r u g ie g o fir m o w e g o r o z w ią z a n ia z o r ie n t o w a ­ n e g o n a u s łu g i — s y s te m u r o z lic z a n ia c z a s u p r a c y — są p r z e k o n a n i, że je g o e le m e n ty f u n k ­ c jo n a ln e n ie p o k r y w a ją się n a w e t w d r o b n e j częś ci z f u n k c jo n a ln o ś c ią p ie r w s z e g o r o z w ią z a ­ n ia . P o n ie w a ż j e d n a k s t w o r z o n e o n o z o s ta ło p r z e z i n n y z e s p ó ł, w a r t o o s ta te c z n ie u p e w n ić się o s łu s z n o ś c i te g o p r z y p u s z c z e n ia p r z e d r o z p o c z ę c ie m p r o je k t o w a n ia p ie r w s z e j u s łu g i — P r a c o w n ik . E k s p lo r a c ja is tn ie ją c e g o r o z w ią z a n ia d o p r o w a d z iła d o z id e n t y f ik o w a n ia c z te r e c h w s p o ­ m n ia n y c h u s łu g p o d m io to w y c h : P ła t n o ś ć n a k o n t o , Z le c e n ie z a k u p u , R e je s t r k s ię g i g łó w n e j i P r o f i l e d o s t a w c ó w ( p a t r z r y s u n e k 1 5 .4 ).

442

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

P o d m io t y r e p r e z e n t o w a n e p r z e z te u s łu g i z d a ją się n ie m ie ć n ic w s p ó ln e g o z p r a c o w n i­ k i e m (ja k o p o d m io t e m lo g ik i b iz n e s o w e j). D o g łę b n a a n a liz a o p is ó w ty c h u s łu g o s ta te c z n ie to s p o s tr z e ż e n ie p o tw ie r d z a : z a p a la się z ie lo n e ś w ia tło d la p r o je k t o w a n ia n o w e j u s łu g i.

K r o k 2 .: d e f i n i o w a n i e t y p ó w d a n y c h d la k o m u n i k a t u P r o je k to w a n ie in te r fe js u u s łu g i n a jle p ie j r o z p o c z ą ć o d fo r m a ln e g o z d e f in io w a n ia k o m u n ik a t ó w , k tó r e u s łu g a t a b ę d z ie p r z e tw a r z a ć . P ie r w s z y m k r o k ie m te j f o r m a liz a c ji je s t z d e f in io w a n ie s to ­ s o w n y c h t y p ó w d a n y c h w r a m a c h k o n s t r u k c ji

types d e f in ic ji W S D L . Body k o p e r t y S O A P . T r e ś ć te j s e k c ji

K o m u n ik a t y S O A P p r z e n o s z ą ła d u n e k u ż y t e c z n y w s e k c ji

m u s i b y ć o d p o w ie d n io z e s t r u k t u r a liz o w a n a p o p r z e z z d e f in io w a n ie s to s o w n y c h s c h e m a tó w X S D : p o s z c z e g ó ln e s c h e m a t y o s a d z a n e w k o n s t r u k c ja c h

types ( lu b i m p o r t o w a n e d o n ic h ) d e f i n iu ją

s t r u k tu r ę p o s z c z e g ó ln y c h e le m e n t ó w c ia ła k o m u n ik a t u . W

p r z y p a d k u u s łu g i p o d m io t o w e j k o r z y s tn a je s t s y tu a c ja , g d y s c h e m a t X S D o d z w ie r c ie d la

w ie r n ie s tr u k tu r ę p o d m io t u r e p r e z e n to w a n e g o p r z e z u s łu g ę : t a k i „ s c h e m a t u k ie r u n k o w a n y p o d ­ m i o t o w o ” m o ż e s ta ć się p o d s ta w ą d e fin ic ji W S D L te j u s łu g i, ja k o że ( p r a w d o p o d o b n ie ) w ię k s z o ś ć k o m u n ik a t ó w o d b ie r a n y c h i w y s y ła n y c h p r z e z tę u s łu g ę p r z e n o s ić b ę d z ie d o k u m e n t r e p r e z e n t u ­ ją c y o d n o ś n y p o d m io t . W a r t o p r z y p o m n ie ć , ż e w d a n y m ś r o d o w is k u o d w z o r o w a n ie p o d m io t ó w b iz n e s o w y c h n a u s łu g i p o d m io t o w e n ie k o n ie c z n ie m u s i b y ć o d w z o r o w a n ie m „ je d e n - n a - je d e n ”: je d e n z p r z y k ł a ­ d ó w te g o w id z ie liś m y w r o z d z ia le 1 2 ., g d z ie d w a p o d m io t y — P r a c o w n ik i H i s t o r i a p r a c o w n ik a — p r z y p o r z ą d k o w a n e z o s ta ły je d n e j u s łu d z e p o d m io t o w e j P r a c o w n ik . W s p o m in a m y o t y m tu t a j, p o n ie w a ż w o p is a n e j s y tu a c ji m o ż e o k a z a ć się c e lo w e p o łą c z e n ie s c h e m a tó w X S D r e p r e z e n t u ją ­ c y c h p o s z c z e g ó ln e p o d m io t y w je d e n o g ó ln y s c h e m a t. P o s tę p o w a n ie ta k ie z a le c a n e je s t je d n a k t y lk o w p r z y p a d k u p e w n o ś c i, że łą c z o n e w te n s p o s ó b p o d m io t y n ig d y n ie b ę d ą m u s ia ły b y ć p o ­ n o w n ie r o z s e p a r o w a n e .

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

443

UW AGA

Jak zobaczymy w prezentowanej poniżej analizie przypadku, definicje schematów XSD mogą być importo­ wane w ramach konstrukcji types definicji WSDL. Opcja ta jest szczególnie użyteczna w odniesieniu do standardowych schematów reprezentujących poszczególne podmioty. Powrócimy do tej kwestii w punkcie 15.5.6, „Modularyzowanie dokumentów WSDL".

A N A LIZA PRZYPADKU E le m e n t e m p ie r w s z e g o w T L S r o z w ią z a n ia z o r ie n t o w a n e g o n a u s łu g i je s t a r c h it e k t u r a r e p r e ­ z e n t o w a n ia d a n y c h X M L , a je j n a tu r a ln ą c z ę ś c ią — s e ria u k ie r u n k o w a n y c h p o d m io t o w o s c h e m a tó w X S D , z w ią z a n y c h z d o m e n ą fin a n s o w o -k s ię g o w ą . M o ż n a b y z a te m m ie ć n a d z ie ję , ż e s c h e m a ty n ie z b ę d n e d la n o w e g o r o z w ią z a n ia ( r o z lic z a n ia c z a s u p r a c y ) j u ż is t n ie ją i n a d a ją się d o p o n o w n e g o w y k o r z y s ta n ia . B liż s z a ic h a n a liz a w y k a z a ła je d n a k , iż są o n e z b y t o b s z e rn e i n a d m ie r n ie s k o m p lik o w a n e . P o d łu ż s z e j n a r a d z ie a r c h it e k c i z d e c y d o w a li w ię c — tr o c h ę m o ż e r y z y k o w n ie — iż d la p r o ­ je k t o w a n e j u s łu g i P r a c o w n ik s k o n s tr u o w a n e z o s ta n ą ic h „ lż e js z e ” w e rs je , w p e łn i k o m p a t y ­ b iln e z p ie r w o w z o r a m i. R o z p o c z ę to o d id e n t y f ik o w a n ia t y p ó w d a n y c h n ie z b ę d n y c h d la w y m o g ó w p r z e t w a r z a n ia k a n d y d a t u r y n a o p e r a c ję P o b i e r z t y g o d n i o w y l i m i t g o d z in , u s ta la ją c w r e z u lt a c ie d e fin ic je d w ó c h z ło ż o n y c h ty p ó w : je d n e g o w y k o r z y s ty w a n e g o p r z e z k o m u n ik a t - ż ą d a n ie w y s y ła n y p r z e z u s łu g ę P r a c o w n ik i d r u g ie g o , s to s o w a n e g o w k o m u n ik a c ie - o d p o w ie d z i o d b ie r a n y m p r z e z tę u s łu g ę . In t u ic y jn e n a z w y o b u t y p ó w o d r a z u z d r a d z a ją ic h z w ią z e k z o d p o w ie d n im i k o m u n i­ k a ta m i2. O b ie d e fin ic j e, w id o c z n e n a p r z y k ła d z ie 15 .1 , z a p is a n o w p lik u o n a z w ie P ra c o w n ik .x s d .

Przykład 15 .1. SchematPracownik.xsd definiujący dwa złożone typy danych (complexType) dla planowanej operacji Pobierz tygodniowy limit godzin < x s d : e l e m e n t n a m e = " EmployeeHoursRequestType " > < x s d :c o m p le x T y p e > < x s d : e le m e n t n a m e = "ID " t y p e = " x s d : i n t e g e r " / > < /x s d :s e q u e n c e >

2 Nawet m ało doświadczeni program iści doskonale wiedzą, jak trudno „polonizuje” się elem enty składniowe ko­ du, m iędzy innym i nazwy zmiennych, typów, m etod i tym podobne, z dwóch podstawowych powodów: nie­ m ożności używania polskich liter oraz odm iany przez przypadki, osoby i liczby, nieobecnej w języku angielskim. By nie tworzyć kuriozalnych identyfikatorów, ograniczyłem się (w tym i następnych rozdziałach) do polonizacji nazw usług i nazw operacji, pozostawiając w brzm ieniu oryginalnym nazwy typów, zm iennych i kom unikatów. Karykaturalna poniekąd postać polskich odpow iedników — pojedyncze wyrazy w „notacji wielbłądziej” i brak polskich liter — to wymogi reguł składni wykorzystywanych języków. Dla lepszej orientacji czytelników za­ mieszczam przypisy wyjaśniające angielskie oryginały nazw operacji przy pierwszym użyciu ich polskich odpo­ wiedników — przyp. tłum.

444

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

< /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d : e l e m e n t n a m e = " EmployeeHoursResponseType" > < x s d :c o m p le x T y p e > < x s d : e le m e n t n a m e = "ID " t y p e = " x s d : i n t e g e r " / > < x s d :e le m e n t n a m e = "W e e k ly H o u rs L im it" t y p e = " x s d : s h o r t " / > < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /x s d :s c h e m a >

UW AGA

Konstrukcje complexType zagnieżdżone są wewnątrz konstrukcji element, bo takie jest zalecenie WSBasicProfi/edla literalnych dokumentowych komunikatów SOAP.

G d y j e d n a k a r c h it e k c i p r z y s t ą p ili d o d e f i n io w a n i a t y p ó w d a n y c h d la o p e r a c ji Z a k t u a l i z u j h i s t o r i ę p r a c o w n ik a , d a ł z n a ć o s o b ie in n y p r o b le m . O k a z a ło się m ia n o w ic ie , ż e o r y g in a ln y s c h e m a t, k t ó r y p o s łu ż y ł j a k p o d s ta w a d o s k o n s tr u o w a n ia s c h e m a tu P ra c o w n ik .x s d , n ie z a ­ w ie r a d e fin ic ji ty p u d a n y c h o d z w ie r c ie d la ją c e g o p o d m io t H i s t o r i a p r a c o w n ik a , r ó w n ie ż r e ­ p r e z e n t o w a n y p r z e z u s łu g ę P r a c o w n ik . D o k ła d n ie js z a a n a liz a is tn ie ją c e g o r o z w ią z a n ia p o z w o liła s tw ie r d z ić , ż e in f o r m a c ja o h i ­ s t o r ii p r a c o w n ik ó w n ie je s t w o g ó le p r z e t w a r z a n a p r z e z s y s te m f in a n s o w o - k s ię g o w y , je s t n a to m ia s t e le m e n te m s y s te m u z a r z ą d z a n ia tz w . z a s o b a m i lu d z k i m i ( H R — H u m a n R esources), d la k tó r e g o to s y s te m u n ie s t w o r z o n o je d n a k ż a d n y c h s c h e m a tó w X S D . N ie c h ę t n i d o in g e ­ r o w a n ia w d o p ie r o co s p o r z ą d z o n y s c h e m a t P ra c o w n ik .x s d a r c h ite k c i z d e c y d o w a li o s tw o ­ r z e n iu o d r ę b n e g o s c h e m a tu H is to r ia P r a c o w n ik a .x s d ( p a t r z r y s u n e k 1 5 .5 i p r z y k ła d 1 5 .2 ).

Rysunek 15.5.

Dwa schematy wywodzące się z dwóch źródeł danych

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

445

Przykład 15 .2. Schemat HistoriaPracownika.xsd odwołujący się do swej źródłowej przestrzeni nazw < x sd:sch em a x m ln s :x s d = " h ttp ://w w w .w 3 .o rg /2 0 0 1 /X M L S c h e m a "

targetNamespace="h ttp ://w w w .xm ltc.co m /tls/em p lo yee/sch em a/h r/"> < x s d :e le m e n t n a m e = "E m p lo y e e U p d a te H is to ry R e q u e s tT y p e "> < x s d :c o m p le x T y p e > < x s d : e le m e n t n a m e = "ID " t y p e = " x s d : i n t e g e r " / > < x s d : e le m e n t name="Com m ent" t y p e = " x s d : s t r i n g " / > < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d :e le m e n t n a m e = "E m p lo y e e U p d a te H is to ry R e s p o n s e T y p e "> < x s d :c o m p le x T y p e > < x s d :e le m e n t nam e="ResponseCode" t y p e = " x s d : b y t e " / > < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /x s d :s c h e m a >

A b y u n ie z a le ż n ić o b a s c h e m a ty o d k o n k r e t n e j d e f in ic ji W S D L i u w y d a t n ić t y m s a m y m ic h w ie lo u ż y w a ln o ś ć , z in te g r o w a n o je z d e fin ic ją W S D L u s łu g i P r a c o w n ik z a p o m o c ą in s t r u k ­ c ji im p o r t z a g n ie ż d ż o n e j w e w n ą t r z k o n s t r u k c ji ty p e s ( p a t r z p r z y k ła d 1 5 .3 ). Przykład 15 .3. Konstrukcja types importująca dwa schematy XSD < typ e s> < x sd :sch e m a ta rg e tN a m e s p a c e = " h t t p : / / w w w . x m l t c . c o m / t l s / e m p l o y e e / s c h e m a / "> < x s d : import n a m e s p a c e = " h t t p : / / w w w . x m l t c . c o m / t l s / e m p l o y e e / s c h e m a / a c c o u n t i n g / " sc h e m a L o c a tio n = "P ra c o w n ik .x s d "/> < x s d : import n a m e s p a c e = " h t t p : / / w w w . x m l t c . c o m / t l s / e m p l o y e e / s c h e m a / h r / " s c h e m a L o c a tio n = "H is to ria P ra c o w n ik a .x s d "/> < /xs d :s ch e m a > < /typ e s >

K r o k 3 .: d e f i n i o w a n i e a b s t r a k c y jn e g o in t e r f e j s u u s łu g i T e n k r o k to p r z e a n a liz o w a n ie p r o p o n o w a n y c h k a n d y d a t u r n a u s łu g i i s p o r z ą d z e n ie w s tę p n e j d e ­ f in ic ji in t e r fe js u u s łu g i w e d łu g n a s tę p u ją c e g o s c e n a riu s z a . 1. U p e w n ie n ie się, że k a ż d a z p r o p o n o w a n y c h o p e r a c ji je s t w y s ta r c z a ją c o g e n e r y c z n a i w ie lo u ż y w a ln a , p o p r z e z a n a liz ę z ia r n is to ś c i lo g ik i e n k a p s u lo w a n e j p r z e z tę o p e ra c ję . 2. N a d a n ie p o s z c z e g ó ln y m o p e r a c jo m in t u ic y jn y c h n a z w , s to s o w n ie d o s t r u k t u r d a n y c h z d e ­ f in io w a n y c h w k r o k u d e fin io w a n ia t y p ó w d a n y c h d la k o m u n ik a t u . 3. U t w o r z e n i e k o n s t r u k c ji p o r tT y p e (a lb o i n t e r f a c e ) w d o k u m e n c ie W S D L i w y p e łn ie n ie je j k o n s t r u k c ja m i o p e r a t io n , o d p o w ia d a ją c y m i p o s z c z e g ó ln y m o p e r a c jo m . 4 . S fo r m a liz o w a n ie lis ty w a r to ś c i w e jś c io w y c h i w y jś c io w y c h z w ią z a n y c h z lo g ik ą p r z e t w a ­ r z a n ia k a ż d e j z o p e r a c ji, p r z y u ż y c iu k o n s t r u k c ji m essag e, z a w ie r a ją c e j z a g n ie ż d ż o n e k o n ­ s tr u k c je p a r t o d w o łu ją c e się d o s to s o w n y c h s c h e m a t ó w X S D .

446

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

A N A LIZA PRZYPADKU

Architekci TLS zdecydowali o nadaniu następujących nazw poszczególnym operacjom usługi P r a c o w n ik : • kandydatura P o b i e r z t y g o d n io w y l i m i t g o d z in staje się operacją o nazwie P o b i e r z T y g o d n i o w y L i m i t G o d z i n P r a c o w n i k a 3, • kandydatura Z a k t u a l i z u j h i s t o r i ę p r a c o w n ik a staje się operacją o nazwie Z a k t u a l i z u j H i s t o r i e P r a c o w n i k a 4. W efekcie daje to usługę o postaci przedstawionej na rysunku 15.6.

Rysunek 15.6. Operacje usługi Pracownik

Zdefiniowane w ten sposób operacje i opisane aspekty ich realizacji odzwierciedlone zostały następnie w formie konstrukcji message i portType w dokumencie WSDL (patrz przykład 15.4). Przykład 15 .4. Elementy message i portType dokumentu WSDL implementujące szczegóły abstrakcyjnej definicji dwóch operacji usługi Pracownik < m e s s a g e name= < p a r t name= e le m e n t= < m e s s a g e name= < p a r t name= e le m e n t=

g e tE m p lo y e e W e e k ly H o u rs R e q u e s tM e s s a g e "> R e q uestP aram eter" a c t:E m p lo y e e H o u rs R e q u e s tT y p e "/>

< m e s s a g e name= < p a r t name= e le m e n t= < m e s s a g e name= < p a r t name= e le m e n t=

u p d a te E m p lo y e e H is to ry R e q u e s tM e s s a g e "> R e q uestP aram eter" h r:E m p lo y e e U p d a te H is to ry R e q u e s tT y p e "/>

g e tE m p lo y e e W e e k ly H o u rs R e s p o n s e M e s s a g e "> R e s ponseP aram eter" a c t:E m p lo y e e H o u rs R e s p o n s e T y p e "/>

u p d a te E m p lo y e e H isto ry R e sp o n s e M e ss a g e "> R e s ponseP aram eter" h r:E m p lo y e e U p d a te H is to ry R e s p o n s e T y p e "/>

3 W oryginale GetEmployeeWeeklyHoursLimit — przyp. tłum. 4 W oryginale UpdateEm ployeeHistory — przyp. tłum.

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

447

< p o rtT y p e n a m e = "E m p lo y e e In te rfa c e "> < o p e r a t i o n n a m e = " PobierzTygodniowyLimitGodzinPracownika " > < in p u t message= "tn s :g e tE m p lo y e e W e e k ly H o u rs R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :g e tE m p lo y e e W e e k ly H o u rs R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " Z a k tu a li zu jH isto rieP raco w n ika " > < in p u t message= " tn s :u p d a te E m p lo y e e H is to ry R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :u p d a te E m p lo y e e H is to ry R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < /p o rtT yp e >

UW AGA

Architekci TLS trzymają się zgodności ze specyfikacją WSDL w wersji 1.1, ponieważ jest ona rekomen­ dowana przez WS-iBasicProfiiew wersji 1.1, a ponadto żadna z platform aplikacyjnych firmy nie ob­ sługuje wersji WSDL 2.0. Stąd użycie elementu portType zamiast elementu interface, definiowanego dopiero w wersji 2.0.

K r o k 4 .: z a s t o s o w a n ie z a s a d o r i e n t a c j i n a u s łu g i

W tym kroku powracamy do czterech poniższych zasad orientacji na usługi, które w rozdziale 8. rozpoznaliśmy jako niewspierane przez technologię usług sieciowych: • wieloużywalności, • autonomii, • bezstanowości, • wykrywalności. Wieloużywalność i autonomia, którym przyglądaliśmy się dokładniej w związku z modelowa­ niem usług, to poniekąd naturalne cechy m odelu projektow ania zorientowanego podm iotow o, ponieważ operacje eksponowane przez biznesowe usługi podmiotowe z założenia projektowane są jako generyczne i wieloużywalne (a dostępność instrukcji import zachęca do tworzenia m odu­ larnych definicji WSDL, skutkujących wielokrotnym wykorzystywaniem tych samych definicji schematów XSD). Promocja wieloużywalności jest częścią kroku 6., w którym sugerujemy rozsze­ rzenie projektu w kierunku spełnienia wymagań wykraczających poza granice określone dla kan­ dydatury. Ponieważ biznesowe usługi podmiotowe często kom ponowane są przez nadrzędną warstwę usług i polegają na warstwie aplikacyjnej urzeczywistniającej ich logikę biznesową, bezpośrednia autonomia tych usług jest generalnie dobrze zdefiniowana. Poza szczególnymi przypadkami, kiedy kom ponowane są przez nadrzędny kontroler podm iotowy lub też podlegają ograniczeniom inne­ go rodzaju, m ożna je zatem uważać za autonomiczne.

448

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

Z p o d o b n y c h w z g lę d ó w u s łu g i p o d m io t o w e z a c h o w u ją te ż z a s a d n ic z o b e z s ta n o w o ś ć . Z u s łu ­ g a m i p o d m io t o w y m i n ie w ią ż e się z r e g u ły d u ż a p o r c ja lo g ik i p r z e tw a r z a n ia , a w s y tu a c ja c h , g d y d o z r e a liz o w a n ia d a n e j o p e r a c ji z a p r z ę g n ię ty c h z o s ta je w ie le a p lik a c ji lu b u s łu g b iz n e s o w y c h , z a ­ le c a się o d k ła d a n ie z a r z ą d z a n ia s ta n e m p r z e t w a r z a n ia ta k d a le c e , ja k to t y lk o m o ż liw e — n a p r z y ­ k ła d s k ła d a ją c tę f u n k c ję n a k a r b k o m u n ik a t ó w S O A P w s ty lu d o k u m e n t o w y m . W y k r y w a ln o ś ć u s łu g je s t is t o t n y m a s p e k te m z a r ó w n o ic h p r o je k t o w a n ia , j a k i f u n k c jo n o w a ­ n ia p o w d r o ż e n iu . Jak w s p o m in a liś m y w k r o k u 1., w p r o je k t o w a n iu u s łu g i n a le ż y u n ik a ć im p le ­ m e n t o w a n ia lo g ik i ju ż z a im p le m e n t o w a n e j w e w n ą t r z in n y c h u s łu g — e f e k t y w n y m e c h a n iz m w y ­ k r y w a n ia u s łu g m o ż e n a m w t y m d z ie le w y d a t n ie d o p o m ó c . I v ic e v e rs a : s to p ie ń i a d e k w a tn o ś ć w y k r y w a n ia u s łu g i z a le ż y w d u ż e j m ie r z e o d s p o s o b u je j z a p r o je k t o w a n ia , a s z c z e g ó ln ie o d w y p o ­ s a ż e n ia w a d e k w a tn y z e s ta w m e ta d a n y c h . W y j a ś n ia m y d o k ła d n ie j tę k w e s tię w p u n k c ie 1 5 .5 .1 0 , „ D o k u m e n t o w a n ie u s łu g z a p o m o c ą m e ta d a n y c h ” .

A N A LIZA PRZYPADKU P o p r z e jr z e n iu w s tę p n e j d e fin ic ji in te r fe js u u s łu g i P r a c o w n ik z d e c y d o w a n o , ż e d r o b n a je g o m o d y fik a c ja u c z y n i s a m ą u s łu g ę b a r d z ie j z g o d n ą z fu n d a m e n t a m i o r ie n ta c ji n a u s łu g i. A k o n ­ k r e tn ie , p o s ta n o w io n o d o d a ć m e t a in fo r m a c ję b liż e j w y ja ś n ia ją c ą f u n k c jo n o w a n ie o b u o p e r a c ji ( p a t r z p r z y k ła d 1 5 .5 ). Przykład 15 .5. Porcja metainformacji uzupełniająca interfejs usługi < p o rtT y p e n a m e = "E m p lo y e e In te rfa c e ">

O p e ra c ja P o b ie rz T y g o d n io w y L im itG o d z in P ra c o w n ik a w y k o r z y s tu je

ID p r a c o w n ik a

do o k r e ś l e n i a w a r t o ś c i j e g o t y g o d n i o w e g o l i m i t u g o d z i n r o b o c z y c h . O p e r a c j a Z a k t u a l i z u j H i s t o r i e P r a c o w n i k a z a p i s u j e n o t a t k ę o k r e ś l o n ą p r z e z Comment w h i s t o r i i p ra c o w n ik a o i d e n t y f i k a t o r z e ID .

< o p e r a tio n n a m e = "P o b ie rz T y g o d n io w y L im itG o d z in P ra c o w n ik a "> < in p u t message= "tn s :g e tE m p lo y e e W e e k ly H o u rs R e q u e s tM e s s a g e "/> < o u t p u t m essage= "tn s :g e tE m p lo y e e W e e k ly H o u rs R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e ra tio n n a m e = " Z a k tu a liz u jH is to rie P ra c o w n ik a "> < in p u t message= " tn s :u p d a te E m p lo y e e H is to ry R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :u p d a te E m p lo y e e H is to ry R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < /p o rtT yp e >

K r o k 5 .: s t a n d a r y z a c ja i u d o s k o n a la n ie in t e r f e j s u u s łu g i K r o k te n , z a le ż n ie o d k o n k r e t n y c h w y m a g a ń , m o ż e o b e jm o w a ć w ie le r ó ż n y c h z a d a ń . O t o p r z y ­ k ła d o w a lis ta a k c ji, k t ó r e m o g ą d o p o m ó c w u z y s k a n iu z e s ta n d a r y z o w a n e g o i e le g a n c k ie g o p r o ­ je k t u u s łu g i.

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

•

449

P r z e g lą d a ją c o b o w ią z u ją c e s ta n d a r d y i w y ty c z n e p r o je k to w e p o d k ą te m s to s o w a ln o ś c i d o d a n e j u s łu g i, m o ż n a s k o n fr o n to w a ć tę u s łu g ę z w y b r a n y m i z n ic h (ja k o p u n k t s ta r t o w y m o ż n a w y b r a ć w s k a z ó w k i, k tó r e p r e z e n t u je m y p r z y k o ń c u te g o r o z d z ia łu ) .

•

P o z a d ą ż e n ie m d o u z y s k a n ia s ta n d a rd o w e j p o s ta c i in te rfe js u , te n k r o k d a je ta k że o k a zję d o z w e ry fik o w a n ia re la c ji p r o je k tu u s łu g i d o c h a ra k te ry s ty k i w sp ó łc z e s n e j S O A , k tó r ą o m a w ia liś m y w p u n k c ie 9 .1 .2 p o ś w ię c o n y m c e c h o m S O A n ie w s p ie ra n y m p r z e z u s łu g i siecio w e.

•

Jeśli in t e g r a ln ą c z ę ś c ią w y m a g a ń p r o je k t o w y c h je s t z g o d n o ś ć z w y t y c z n y m i W S - I B a s ic

P ro file , n a d a r z a się w ła ś n ie o k a z ja d o z w e r y f ik o w a n ia te j z g o d n o ś c i. C h o c ia ż w s p o m n ia n e w y ty c z n e o d n o s z ą się r a c z e j d o d e fin ic ji W S D L ja k o c a ło ś c i, m o ż n a s p r ó b o w a ć je d o p a s o w a ć d o te g o , co ju ż z o s ta ło w r a m a c h t w o r z e n ia te j d e fin ic ji z r o b io n e .

A N A LIZA PRZYPADKU P r z y g lą d a ją c się in te r fe js o w i u s łu g i P r a c o w n ik , a r c h ite k c i T L S p o s t a n o w ili w p r o w a d z ić d o n ie g o d r o b n ą m o d y fik a c ję — z m ie n ili n ie c o n a z w y o p e r a c ji ( p a t r z r y s u n e k 1 5 .7 ).

Rysunek 15.7. Zrewidowane nazwy operacji usługi Pracow nik Z r e w id o w a n e d e fin ic je o p e r a c ji p r z e d s ta w ia ją się te r a z ta k , j a k n a p r z y k ła d z ie 1 5 .6 . Przykład 15 .6. Dwie konstrukcje operation, z nowymi nazwami operacji < o p e r a t i o n n a m e = " PobierzTygodniowyLin r itG od zin " 5> < in p u t m e s s a g e = "tn s :g e tW e e k ly H o u rs R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :g e tW e e k lyH o u rs R e s p o n s e M e s sa g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " Z a k tu a liz u jH is to r ie " 6> < in p u t m e s s a g e = "tn s :u p d a te H is to ry R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :u p d a te H is to ry R e s p o n s e M e s s a g e "/> < /o p e ra tio n >

P o co ta , n ib y k o s m e ty c z n a , z m ia n a ? Jak w y ja ś n im y w p u n k c ie 1 5 .5 .2 , „ S to s o w a n ie s ta n d a r ­ d ó w n a z e w n ic z y c h ” , w y k o r z y s ty w a n ie s ta n d a r d ó w n a z e w n ic z y c h d o s ta rc z a n a ty w n e g o w s p a r ­ c ia d la w b u d o w a n e j in te r o p e r a c y jn o ś c i — je d n e j z fu n d a m e n ta ln y c h c e c h w s p ó łc z e s n e j S O A .

5 W oryginale GetWeeklyHoursLimit — przyp. tłum. 6 W oryginale UpdateHistory — przyp. tłum.

450

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

K r o k 6 .: r o z s z e r z a n ie p r o j e k t u u s łu g i M o d e lo w a n ie u s łu g c z ę s to w y k a z u je t e n d e n c ję d o s k u p ia n ia się n a e w id e n t n y c h w y m a g a n ia c h b iz n e s o w y c h . M i m o iż w ie lo u ż y w a ln o ś ć je s t g e n e r a ln ie p r o p a g o w a n ą z a le tą u s łu g , n a e ta p ie p r o ­ je k t o w a n ia n a b ie r a z n a c z e n ia s z c z e g ó ln e g o . U p e w n ie n ie się, ż e w d a n ą u s łu g ę w b u d o w a n o w y ­ s ta r c z a ją c ą p o r c ję w ie lo u ż y w a ln e j fu n k c jo n a ln o ś c i, je s t s z c z e g ó ln ie is to tn e w o d n ie s ie n iu d o b i z ­ n e s o w y c h u s łu g p o d m io t o w y c h , ja k o ż e o d n ic h p o t e n c ja ln e u s łu g i- w n io s k o d a w c y o c z e k u ją k o m p le tn e g o z e s ta w u t y p o w y c h d la d a n e g o p o d m io t u o p e r a c ji. T e n k r o k to w z a s a d z ie a n a liz a s p e k u la t y w n a , d o ty c z ą c a n o w y c h c e c h f u n k c jo n a ln y c h , ja k ie d a n a u s łu g a m o g ła b y je s z c z e o f e r o w a ć w a k t u a l n y m p r e d e f in io w a n y m k o n t e k ś c ie . G e n e r a ln ie n o w ą fu n k c jo n a ln o ś ć u s łu g i im p le m e n t o w a ć m o ż n a n a d w a sp o s o b y : •

d o d a ją c n o w e o p e r a c je ,

•

d o d a ją c n o w e p a r a m e t r y d o is tn ie ją c y c h o p e r a c ji.

M i m o iż d r u g ie z w y m ie n io n y c h p o d e jś ć je s t b a r d z ie j p o ż ą d a n e z p e r s p e k ty w y e le g a n c ji i n ­ te r fe js u u s łu g i, to je d n o c z e ś n ie je s t o n o w y s o c e n ie in t u ic y jn e : u s łu g a -d o s ta r c z y c ie l z b o g a to p a r a m e t r y z o w a n y m i o p e r a c ja m i n ie je s t z b y t w y g o d n a d la p o t e n c ja ln y c h u s łu g -w n io s k o d a w c ó w , b o z m u s z a ic h d o p o s ia d a n ia z b y t o b s z e rn e j w ie d z y n a s w ó j te m a t 7. D o d a w a n ie n o w y c h o p e r a c ji je s t ju ż p o d e jś c ie m b a r d z ie j p r z e jr z y s t y m ; w ię k s z o ś ć o p e r a c ji t y ­ p o w e j u s łu g i p o d m io t o w e j m o ż n a z a z w y c z a j z a lic z y ć d o je d n e j z n a s tę p u ją c y c h k a te g o r ii: •

„ p o b ie r z - t o - i- t o ” ,

•

„ z a k tu a liz u j-to -i-to -ta k -i-ta k ”,

•

„ d o d a j to ”,

•

„ u s u ń -to -i-to ”.

B u d o w a n ie n a tę m o d łę s ta n d a r d o w e g o z e s ta w u o p e r a c ji — t r z e b a p r z y z n a ć , d y s k u s y jn e g o z p u n k t u w id z e n ia b e z p ie c z e ń s tw a — w p r o w a d z a s p ó jn y s to p ie ń in te r o p e r a c y jn o ś c i d o w a r s tw y u s łu g b iz n e s o w y c h , p r z y c z y n ia ją c się d o w ię k s z e j w ie lo u ż y w a ln o ś c i i le p s z e j k o m p o n o w a ln o ś c i u s łu g s k ła d o w y c h te j w a r s tw y .

UW AGA Niezależnie od sugerowanej konwencji nazewniczej, przy projektow aniu usług podm iotowych odzw iercie­ dlających istniejące m odele biznesowe w arto dać pierwszeństwo now ym standardom nazew nictw a, naw et jeśli w iązałoby się to z rew idow aniem istniejących nazw.

G d y d e fin io w a n e są c a łk ie m n o w e z a d a n ia , z n a jd u ją z w y k le o d z w ie r c ie d le n ie w p o s ta c i n o ­ w y c h o p e r a c ji, p r o je k t o w a n y c h w e d łu g t y c h s a m y c h s t a n d a r d ó w , co is tn ie ją c e . G d y n a to m ia s t p o ja w ia ją się n o w e w y m a g a n ia f u n k c jo n a ln e , m a ją c e z w ią z e k ta k ż e z is t n ie ją c y m i o p e r a c ja m i, p o d s t a w o w ą m e t o d ą m o d y f i k o w a n i a t y c h o p e r a c ji je s t d o d a w a n ie d o n ic h n o w y c h w a r to ś c i

7 W yposażając operację w zbyt wiele param etrów, łatwo stracić kontrolę nad znaczeniem każdego z nich, zgodnie ze znanym porzekadłem , datującym się jeszcze na epokę program ow ania proceduralnego, „jeśli twoja procedura m a dziesięć param etrów, to praw dopodobnie o którym ś zapom niałeś” — przyp. tłum.

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

451

wejściowych i wyjściowych. Pozwala to każdej z operacji na wysyłanie i odbieranie określonych kombinacji komunikatów. Należy jednak uważać, by nie przekombinować: zbyt skomplikowane operacje nie są szczególnie atrakcyjne z perspektywy wieloużywalności. Zawsze natom iast warto poddać proponow aną nową funkcjonalność osobnemu procesowi analizy. Ponadto, m imo iż zalecane i pożądane jest tworzenie usług podmiotowych jako samowystar­ czalnych w kwestii zarządzania danymi pewnej domeny, nie można zapominać o uwarunkowaniach praktycznych. Dla każdej nowo dodawanej operacji należy przecież zaprojektować i zaimple­ mentować środki, za pom ocą których realizować będzie ona swe zadanie. To z dużym prawdopo­ dobieństwem prowadzi do konieczności dodawania nowych usług aplikacyjnych lub rozszerzania istniejących i jest celowe, pod warunkiem że przysłowiowa skórka okaże się warta wyprawki. I, co zapewne skonstatowali uważni czytelnicy, dodawanie nowej funkcjonalności wymaga ponownego wykonania kroków od 1. do 5.

A N A LIZA PRZYPADKU

W TLS czas nagli, konstrukcja systemu rozliczania czasu pracy przebiega pod silną presją je­ go potencjalnych użytkowników. Architekci nie zamierzają więc obecnie poszerzać wykona­ nego projektu usług — dotychczasowe standardy projektowania zaowocowały usługami, do których będzie m ożna dodawać nowe operacje bez łamania dotychczasowych interfejsów. M imo to, niejako na wyrost, spróbujm y pospekulować, jakie rodzaje operacji m ożna by dodać do usługi P r a c o w n ik . Ponieważ reprezentuje ona dwa podm ioty biznesowe, zasługuje prawdopodobnie na obszerniejszy zestaw operacji w porów naniu z innymi usługami pod­ miotowymi. Propozycję takiego zestawu przedstawiamy na rysunku 15.8.

Rysunek 15.8. Usługa Pracownik wyposażona w pełny zestaw operacji

W przykładzie 15.7 przedstawiamy rozszerzoną konstrukcję portType uwzględniającą ten bogaty zestaw operacji (dla oszczędności miejsca pominęliśmy konstrukcję documentation).

452

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

Przykład 15 .7. Rozszerzona konstrukcja portType < p o rtT y p e n a m e = "E m p lo y e e In te rfa c e "> < o p e r a t i o n n a m e = " PobierzTygodni owyLimitGodzin " > < in p u t m e s s a g e = "tn s :g e tW e e k ly H o u rs R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :g e tW e e k lyH o u rs R e s p o n s e M e s sa g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " ZmienTygodniowyLimitGodzin " > < in p u t message= "tn s :u p d a te W e e k ly H o u rs R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :u p d a te W e e k ly H o u rs R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " P o b ie rzH is to ri e " 8> < in p u t m e s s a g e = "tn s :g e tH is to ry R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :g e tH is to ry R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " Z a k tu a liz u jH is to r ie " 9> < in p u t m e s s a g e = "tn s :u p d a te H is to ry R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :u p d a te H is to ry R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " U sunH istorie " 10> < in p u t m e s s a g e = "tn s :d e le te H is to ry R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :d e le te H is to ry R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " D od ajP ro fil " 11> < in p u t m e s s a g e = "tn s :a d d P ro file R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :a d d P ro file R e s p o n s e M e s s a g e "/> < /o p e ra tio n > 12 < o p e r a t i o n n a m e = " P o b ie rz P ro fil " > < in p u t m e s s a g e = "tn s :g e tP ro file R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :g e tP ro file R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " Z a k tu a liz u jP r o fil " 13> < in p u t m e s s a g e = "tn s :u p d a te P ro file R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :u p d a te P ro file R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a t i o n n a m e = " U s u n P ro fil " 14> < in p u t m e s s a g e = "tn s :d e le te P ro file R e q u e s tM e s s a g e "/> < o u tp u t m e s s a g e = "tn s :d e le te P ro file R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < /p o rtT yp e >

T a k r o z b u d o w a n a u s łu g a P r a c o w n ik , w y p o s a ż o n a w k o m p le t o p e r a c ji z w ią z a n y c h z p r a ­ c o w n ik ie m ja k o p o d m io t e m b iz n e s o w y m , m o ż e b y ć z p o w o d z e n ie m w y k o r z y s ty w a n a w ie lo ­ k r o t n i e w r a m a c h r ó ż n y c h r o z w ią z a ń .

8 W oryginale GetHistory — przyp. tłum. 9 W oryginale UpdateHistory — przyp. tłum. 10 W oryginale DeleteH istory — przyp. tłum. 11 W oryginale AddProfile — przyp. tłum. 12 W oryginale GetProfile — przyp. tłum. 13 W oryginale UpdateProfile — przyp. tłum. 14 W oryginale DeleteProfile — przyp. tłum.

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

453

K r o k 7 .: i d e n t y f i k o w a n i e in n y c h n ie z b ę d n y c h u s łu g W p ro c e s ie m o d e lo w a n ia u s łu g z id e n t y f ik o w a liś m y k i lk a k lu c z o w y c h u s łu g a p lik a c y jn y c h , n ie m a je d n a k p e w n o ś c i, że z d e f in io w a liś m y w s z y s tk ie p o tr z e b n e . N a le ż y d o k ła d n ie p r z e a n a liz o w a ć k a ż d ą o p e r a c ję n o w o p r o je k to w a n e j u s łu g i p o d k ą t e m w y ­ m a g a ń p r z e t w a r z a n ia , a n a s tę p n ie p r z e p r o w a d z ić r o z p o z n a n ie , c z y w y m a g a n ia te m o g ą z o s ta ć z r e a liz o w a n e z a p o m o c ą j u ż is tn ie ją c y c h u s łu g a p lik a c y jn y c h , c z y te ż p o ja w ia się k o n ie c z n o ś ć d e ­ f in io w a n ia n o w y c h (ja k o częś ci b u d o w a n e g o r o z w ią z a n ia ).

A N A LIZA PRZYPADKU P r z y jr z y jm y się o p e r a c jo m z d e f in io w a n e j w ła ś n ie u s łu g i P r a c o w n ik : •

P o b ie r z T y g o d n io w y L im itG o d z in ,

•

Z a k tu a liz u jH is to r ie .

P ie r w s z a z n ic h w y m a g a n ie w ą t p liw ie d o s tę p u d o p r o f ilu p r a c o w n ik a . W T L S in f o r m a c je z w ią z a n e z t y m p r o f ile m r o z p r o s z o n e są p o m ię d z y d w ie lo k a liz a c je : •

d a n e z w ią z a n e z r o z lic z e n ia m i z p r a c o w n ik ie m p r z e c h o w y w a n e są w r a m a c h s y s te m u fin a n s o w o -k s ię g o w e g o ;

•

d a n e o s o b o w e p r a c o w n ik a w r a z z h is t o r ią je g o p r a c y p r z e c h o w y w a n e są w r a m a c h s y s te m u z a r z ą d z a n ia z a s o b a m i l u d z k i m i ( H R ) .

G d y p o r a z p ie r w s z y im p le m e n to w a n o w T L S a r c h ite k tu r ę r e p r e z e n to w a n ia d a n y c h X M L , w y k o r z y s ta n o s c h e m a ty X S D u k ie r u n k o w a n e p o d m io to w o d o z n iw e lo w a n ia r o z b ie ż n o ś c i m ię d z y f o r m a t a m i d a n y c h p o c h o d z ą c y c h z r ó ż n y c h ź r ó d e ł. Ś w ia d o m i te g o a r c h ite k c i p r z e a n a liz o w a li w ię c s c h e m a t, k t ó r y p o s łu ż y ł ja k o p ie r w o w z ó r d la s c h e m a tu P ra c o w n ik .x s d , w c e lu z id e n t y fi­ k o w a n ia w y m a g a ń p r z e tw a r z a n ia d la o p e r a c ji P o b i e r z T y g o d n i o w y L im it G o d z i n . O k a z a ło się w ó w c z a s , ż e c h o ć s c h e m a t t e n d o k ła d n ie o d z w ie r c ie d la in f o r m a c ję o k re ś la ją c ą p r a c o w n ik a (ja k o p o d m io t b iz n e s o w y ), to in fo r m a c ja z a w a r ta w d o k u m e n c ie o p is u ją c y m p r a c o w n ik a c z e r ­ p a n a je s t z d w ó c h r ó ż n y c h ź r ó d e ł, p r z y c z y m t y g o d n io w y l i m i t g o d z in r o b o c z y c h p r a c o w n ik a p r z e c h o w y w a n y je s t w s y s te m ie fin a n s o w o -k s ię g o w y m . Z a te m w y m a g a n ia p r z e tw a r z a n ia o p e ­ r a c ji P o b i e r z T y g o d n i o w y L i m i t G o d z i n m o ż n a s f o r m u ło w a ć ja k o

f u n k c ję n a p o z io m ie u s łu g i a p lik a c y jn e j, r e a liz u ją c ą n a s tę p u ją c ą k w e re n d ę p o d a d re se m b a z y d a n y c h s y s te m u fin a n s o w o -k s ię g o w e g o : „ p o d a j ty g o d n io w y l i m i t g o d z in ro b o c z y c h d la p r a c o w n ik a id e n ty fik o w a n e g o z a p o m o c ą n u m e ru ID ja k o je d y n e g o k ry te r iu m w y s z u k iw a n ia ” . W p r z y p a d k u d r u g ie j o p e r a c ji — Z a k t u a l i z u j H i s t o r i e — s p r a w y m a ją się n ie c o p r o ś c ie j, p o n ie w a ż s c h e m a t H is to r ia P r a c o w n ik a .x s d w y w o d z i się z p o je d y n c z e g o ź r ó d ła , c z y li r e p o z y ­ t o r i u m p r o f ili p r a c o w n ic z y c h s y s te m u H R . A r c h it e k c i, s tu d iu ją c o r y g in a ln ą d o k u m e n ta c ję a n a liz y te g o s y s te m u , z id e n ty fik o w a li d o k ła d n ie p o r c ję in f o r m a c ji, k t ó r a m a b y ć a k tu a liz o w a n a p r z e z w s p o m n ia n ą o p e ra c ję . W y m a g a n ia p r z e tw a r z a n ia d la te j o p e r a c ji, w y k ra c z a ją c e t y m sa­ m y m p o z a g ra n ic e b ie ż ą c e g o r o z w ią z a n ia , s fo r m u ło w a ć m o ż n a ja k o

f u n k c ję n a p o z io m ie u s łu g i a p lik a c y jn e j, r e a liz u ją c ą z a p is ż ą d a n e j w a rto ś c i w b a z ie d a n y c h s y s te m u H R , w k o lu m n ie Comment r e k o r d u p r a c o w n ik a id e n ty fik o w a n e g o w y łą c z n ie z a p o m o c ą n u m e r u ID .

454

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

W y g lą d a w ię c n a to , że w s y s te m ie r o z lic z a n ia czas u p r a c y p o tr z e b n e są je s z c ze d w ie u s łu g i a p lik a c y jn e , re a liz u ją c e w y m o g i p r z e tw a r z a n ia u s łu g i P r a c o w n ik , co p o k a z a n o n a ro z s z e r z o n y m d ia g r a m ie w id o c z n y m n a r y s u n k u 1 5 .9 . O c z y w iś c ie , o b a z id e n t y f ik o w a n e w y m a g a n ia m u s z ą s ta ć się p r z e d m io t e m p r o c e s u m o d e lo w a n ia u s łu g , o p is y w a n e g o w r o z d z ia le 12.

Warstwa orkiestracji usług Warstwa usług biznesowych

Warstwa usług biznesowych Warstwa usług aplikacyjnych

Usługa Powiadamianie

Rysunek 15.9. Zrewidowana hierarchia kompozycji uwidaczniająca zapotrzebowanie na dwie nowe usługi aplikacyjne P o d o k ła d n e j a n a liz ie is tn ie ją c y c h u s łu g a p lik a c y jn y c h o k a z a ło się, że n a le ż y u tw o r z y ć ty lk o je d n ą n o w ą u s łu g ę — o to c z k ę s y s te m u H R , p r z y o k a z ji s p e łn ia ją c ą r ó w n ie ż w y m a g a n ia p r z e ­ tw a r z a n ia u s łu g i K a r t a c z a s u p r a c y . O d k r y to ta k ż e , iż w y m a g a n ia p r z e tw a r z a n ia u s łu g i F a k t u r a m o g ą z o s ta ć s p e łn io n e p r z e z is tn ie ją c ą u s łu g ę a p lik a c y jn ą P ła t n o ś ć n a k o n t o .

A N A LIZA PRZYPADKU (W Y N IK I PROCESU) O t o f in a ln a p o s ta ć d e f i n ic j i W S D L u s łu g i P r a c o w n i k , u w z g lę d n ia ją c a z m ia n y w n a z w a c h e le m e n t ó w i w s z y s tk ie p o p r z e d n ie p o p r a w k i. Przykład 15 .8. Finalna postać abstrakcyjnej części definicji WSDL usługi Pracownik < d e f i n i t i o n s n a m e = "P ra c o w n ik " targ etN am esp ace= "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /w s d l/ " x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o r g /w s d l/" x m ln s :a c t= " h t t p : // w w w .x m lt c . c o m / tls /e m p lo y e e /s c h e m a /a c c o u n tin g /"

1 5 .2 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG P O D M IO T O W Y C H — KROK PO KROKU

x m ln s :h r= "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /s c h e m a /h r/" x m ln s :s o a p = "h ttp : // s c h e m a s . x m ls o a p . o r g /w s d l/s o a p / " x m ln s :tn s = "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /w s d l/ " x m ln s : x s d = " h ttp ://w w w .w 3 .o r g /2 0 0 1 /X M L S c h e m a "> < x sd:sch em a targ etN am esp ace= " h t t p : / / w w w . x m l t c . c o m / t l s / e m p l o y e e / s c h e m a / "> < x s d : i m p o r t namespace= " h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /s c h e m a / a c c o u n tin g /" sc h e m a L o c a tio n = "P ra c o w n ik .x s d "/> < x s d : i m p o r t namespace= " h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /s c h e m a /h r/" s c h e m a L o c a tio n = "H is to ria P ra c o w n ik a .x s d "/> < /xs d :s c h e m a > < /typ e s > < p a r t na m e = "R e q u e stP a ra m e te r" e le m e n t= "a c t:E m p lo y e e H o u rs R e q u e s tT y p e "/> < p a r t n a m e = "R esp onse P aram eter" e le m e n t= "a ct:E m p lo y e e H o u rs R e sp o n se T yp e "/> < p a r t na m e = "R e q u e stP a ra m e te r" e le m e n t= "h r:E m p lo y e e U p d a te H is to ry R e q u e s tT y p e "/> < p a r t n a m e = "R esp onse P aram eter" e le m e n t= "h r:E m p lo y e e U p d a te H is to ry R e s p o n s e T y p e "/> < p o rtT y p e n a m e = "E m p lo y e e In te rfa c e "> < d o c u m e n ta tio n > O p e r a c ja P o b ie r z T y g o d n i o w y L im i t G o d z i n w y k o r z y s t u j e ID p r a c o w n ik a do o k r e ś l e n i a w a r t o ś c i j e g o t y g o d n i o w e g o l i m i t u g o d z i n r o b o c z y c h . O p e r a c j a Z a k t u a l i z u j H i s t o r i e z a p i s u j e n o t a t k ę o k r e ś l o n ą p r z e z Comm ent w h i s t o r i i p ra c o w n ik a o i d e n t y f i k a t o r z e ID . < /d o c u m e n ta tio n > < o p e r a tio n n a m e = "P o b ie rz T y g o d n io w y L im itG o d z in "> < in p u t message= "tn s :g e tW e e k ly H o u rs R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :g e tW e e k ly H o u rs R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e ra tio n n a m e = " Z a k tu a liz u jH is to r ie " > < in p u t message= "tn s :u p d a te H is to ry R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :u p d a te H is to ry R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < /p o rtT yp e > < /d e fin itio n s >

UW AGA Jak w idać, ograniczyliśmy się tylko do części abstrakcyjnej definicji. Całość pobrać można z serwera FTP w ydaw n ictw a Helion ftp://ftp.helion.pl/przyklady/soakon.zip..

455

456

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

P O D S U M O W A N IE •

Biznesowe usługi podm iotow e pow inny być projektow ane tak, by dokładnie określały istniejące podm ioty (encje) biznesowe, a same pozostawały agnostyczne w stosunku do procesów biznesowych.

•

Do wyposażenia usługi podm iotow ej w niezbędny zestaw generycznych operacji potrzebna jest zw ykle pew na doza analizy spekulatywnej.

1 5 .3 . P ro je k to w a n ie u sług a p lik a c y jn y c h — k ro k p o kroku U s łu g i a p lik a c y jn e są n ic z y m k o n ie c ią g n ą c e c a łą k a r o c ę S O A . S k u p io n e są w n a jn iż s z e j p o d w a r s tw ie s k o m p o n o w a n e j w a r s tw y u s łu g ( p a tr z r y s u n e k 1 5 .1 0 ) i o d p o w ia d a ją z a fiz y c z n e p r z e tw a r z a n ie i n f o r m a c ji, p o d d y k ta n d o w a r s tw y b iz n e s o w e j i w a r s tw y o r k ie s tr a c ji.

Rysunek 15.10. Usługi aplikacyjne tworzące najniższą podwarstwę warstwy usług W p r z e c iw ie ń s tw ie d o b iz n e s o w y c h u s łu g p o d m io t o w y c h , p r z y p r o je k t o w a n iu u s łu g a p lik a ­ c y jn y c h p o m o c a n a lit y k ó w b iz n e s o w y c h n ie n a w ie le się z d a . U s łu g i a p lik a c y jn e s ta n o w ią c z y s tą a b s tra k c ję fir m o w e g o ś r o d o w is k a te c h n o lo g ic z n e g o , z a te m b e z c e n n a je s t ra c z e j w ie d z a ty c h , k t ó r z y ś r o d o w is k o to d o s k o n a le z n a ją . U s łu g i a p lik a c y jn e są k a te g o r ią u s łu g n a jb a r d z ie j n ie w d z ię c z n ą i t r u d n ą d o m o d e lo w a n ia , ze w z g lę d u n a m n o g o ś ć i r ó ż n o r o d n o ś ć c z y n n ik ó w te c h n o lo g ic z n y c h , k tó r e tr z e b a b r a ć p o d u w a g ę . C z y n n ik i te są z m ie n n e i n ie p r z e w id y w a ln e , w y n ik a ją z r o z w o ju te c h n o lo g ic z n e g o , le c z ta k ż e ze z m ie n ia ją c y c h się w y m a g a ń p r z e t w a r z a n ia p ły n ą c y c h z w a r s t w w y ż s z y c h .

1 5 .3 . PRO JEK TO W A N IE USŁUG APLIKACYJNYCH — KROK PO KROKU

1 5 .3 .1 .

457

P ro c e s

N a r y s u n k u 1 5 .1 1 p r z e d s ta w io n o p r o p o n o w a n y s c e n a riu s z p r o c e s u p r o je k t o w a n ia in te r fe js u u s łu g i a p lik a c y jn e j. O d te g o m ie js c a , a ż d o k o ń c a k s ią ż k i, p o d p o ję c ie m „ u s łu g i a p lik a c y jn e j” r o z u m ie ć b ę d z ie m y „ w ie lo u ż y w a ln ą a p lik a c y jn ą u s łu g ę u ż y t k o w ą ” ; k a ż d o r a z o w o w y r a ź n ie z a z n a c z y m y s y ­ tu a c ję , g d y o m a w ia n a b ę d z ie u s łu g a h y b r y d o w a . Kroki Analiza zorientowana usługowo

f

Inwentaryzowanie istniejących usług

Komponowanie SOA

Definiowanie schematu podmiotu

Projektowanie zorientowane usługowo

f

Projektowanie biznesowych usług podmiotowych

Projektowanie usług aplikacyjnych

Projektowanie biznesowych usług zadaniowych

Administrowanie usługami

Krok 5

Standaryzowanie interfejsu usługi

Wdrażanie usług

f

Krok 4 Zastosowanie reguł orientacji na usługi

Testowanie usług

f

Krok 3 Definiowanie abstrakcyjnego interfejsu

Tworzenie usług

f

Krok 2

Projektowanie procesu biznesowego zorientowanego na usługi

Krok 6

Rozszerzanie projektu usługi

Rysunek 15.11. Proces projektowania aplikacyjnej usługi użytkowej S p o g lą d a ją c n a r y s u n e k 1 5 .1 1 , m o ż n a z a u w a ż y ć n a n i m k i lk a p o d o b ie ń s t w d o p r o c e s u p r o ­ je k t o w a n ia u s łu g i p o d m io to w e j, c z y li k ilk a k r o k ó w o id e n ty c z n y c h e ty k ie ta c h . P o d o b ie ń s tw a te w y ­ n ik a ją z e z b io r u c e c h w s p ó ln y c h : z a r ó w n o u s łu g i a p lik a c y jn e , j a k i b iz n e s o w e u s łu g i p o d m io t o w e

458

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

p r o je k t o w a n e są z m y ś lą o w ie lo u ż y w a ln o ś c i, p o n a d t o z w y k le p o d le g a ją k o m p o n o w a n iu p r z e z n a d r z ę d n y k o n t r o le r p o d p o r z ą d k o w u ją c y ic h d z ia ła n ie o k r e ś lo n e m u z a d a n iu s p e c y fic z n e m u d la p ro c e s u . Z a s a d n ic z y c h r ó ż n ic m i ę d z y p r o je k t o w a n ie m o b u t y p ó w u s łu g je s t z n a c z n ie w ię c e j n iż p o d o ­ b ie ń s tw . Z a u w a ż m y n a p r z y k ła d , iż w p o s ta c i o s o b n e g o k r o k u w y d z ie lo n e z o s ta ło p o t w ie r d z e n ie k o n t e k s t u g r u p o w a n ia o p e r a c ji. W p r z y p a d k u u s łu g a p lik a c y jn y c h je s t to z a d a n ie o z n a c z e n iu k r y t y c z n y m , w d o d a t k u z n a c z n ie m n ie j k la r o w n e n iż w p r z y p a d k u u s łu g b iz n e s o w y c h . N i e m a ta k ż e k r o k u i d e n t y f ik o w a n ia w y m a g a ń p r z e t w a r z a n ia , p o n ie w a ż u s łu g i a p lik a c y jn e s a m e są o d p o w ie d z ia ln e z a s p e łn ia n ie z id e n t y f ik o w a n y c h j u ż w y m a g a ń z e s t r o n y n a d r z ę d n y c h u s łu g b iz n e s o w y c h . N i e o z n a c z a to je d n a k , że u s łu g i a p lik a c y jn e n ie f o r m u ł u ją s w o ic h w y m a g a ń p r z e tw a r z a n ia : o w s z e m , f o r m u łu ją , ale ja k o e le m e n t w ła s n e j w e w n ę tr z n e j lo g ik i. P o n ie w a ż o b e c n ie o g r a n ic z a m y się je d y n ie d o d e fin io w a n ia in te r fe js ó w , z z a s a d y o d s e p a r o w a n y c h o d w e w n ę t r z n e j lo g ik i, w s p o m n ia n y k r o k n ie je s t u w a ż a n y z a część s c e n a r iu s z a p r o je k tu . P o ty c h n ie z b ę d n y c h w y ja ś n ie n ia c h z a jm i jm y się p r a k t y c z n y m k o n s t r u o w a n ie m in te r fe js ó w .

A N A LIZA PRZYPADKU P r z e n o s i m y s ię d o f i r m y R a il C o , g d z ie p r z y j r z y m y s ię p r o je k t o w a n iu u s łu g i n a p o d s t a w ie k a n d y d a t u r y K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h , s ta n o w ią c e j je d e n z w y n ik ó w m o d e lo ­ w a n ia o p is y w a n e g o w r o z d z ia le 12. W s p o m n ia n a k a n d y d a t u r a p r z e d s t a w io n a je s t s c h e m a ­ ty c z n ie n a r y s u n k u 1 5 .1 2 .

Rysunek 15.12. Kandydatura na usługę Konwersja dokumentów księgowych K a n d y d a t u r a ta u s ta n a w ia k o n te k s t „ k o n w e r t o w a n ia d o k u m e n t ó w ” , co u z a s a d n ia z g r u ­ p o w a n ie w je j r a m a c h d w ó c h p o d o b n y c h o p e ra c ji: •

K o n w e r tu j d o k u m e n t z f o r m a t u X M L n a f o r m a t n a ty w n y ,

•

K o n w e r t u j d o k u m e n t z n a ty w n e g o f o r m a t u n a f o r m a t X M L .

D w a p o w y ż s z e w ie r s z e te k s tu s ta n o w ią o b e c n ie b a z ę d o w y p r o w a d z e n ia d e fin ic ji f iz y c z ­ n e g o in te r fe js u u s łu g i w r a m a c h fo r m a ln e g o p r o c e s u p r o je k to w e g o .

1 5 .3 . PRO JEK TO W A N IE USŁUG APLIKACYJNYCH — KROK PO KROKU

459

K r o k 1 .: in w e n t a r y z o w a n ie is t n ie ją c y c h u s łu g U p e w n ie n ie się, ż e fu n k c jo n a ln o ś ć w y m a g a n a o d p r z y s z łe j u s łu g i n ie is tn ie je ju ż w ja k ie jś f o r m ie , je s t w p r z y p a d k u u s łu g i a p lik a c y jn e j w a ż n ie js z e n iż w p r z y p a d k u p o z o s ta ły c h t y p ó w u s łu g . P r z e d r o z p o c z ę c ie m p r o je k t o w a n ia u s łu g i a p lik a c y jn e j k o n ie c z n e je s t w ię c w y k o n a n ie in w e n t a r y z a c ji j u ż is tn ie ją c y c h u s łu g a p lik a c y jn y c h w c e lu o d k r y c ia m e c h a n iz m ó w c h o ć b y ty lk o p r z y p o m in a ją ­ c y c h te , k tó r e c h c ie lib y ś m y z a p r o je k to w a ć . P o n a d to , ja k o ż e u s łu g i a p lik a c y jn e u d o s tę p n ia ją z w y k le fu n k c jo n a ln o ś ć w y s o c e g e n e r y c z n ą , w a r t o p r z e p r o w a d z ić r o z p o z n a n ie , c z y ż ą d a n e p r z e z n a s m e c h a n iz m y n ie są ju ż d o s tę p n e w g o ­ to w e j f o r m ie — f o r m ie u s łu g i, k t ó r ą m o ż n a z a k u p ić ( lu b w y d z ie r ż a w ić ) o d t z w . f i r m t r z e c ic h . P o ­ n ie w a ż u s łu g i a p lik a c y jn e p o w in n y b y ć p r o je k to w a n e z m y ś lą o m a k s y m a ln e j w ie lo u ż y w a ln o ś c i, u s łu g i s ie c io w e p r o d u c e n t ó w t r z e c ic h ( z r e g u ły b u d o w a n e ja k o w ie lo u ż y w a ln e ) m o g ą s ta n o w ić r o z s ą d n ą a lt e r n a t y w ę d la s a m o d z ie ln e g o w y s iłk u p r o je k t o w e g o , o ile — r z e c z ja s n a — s p e łn ia ją z a k ła d a n e w y m a g a n ia ja k o ś c io w e .

A N A LIZA PRZYPADKU U s łu g a K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h p r o je k t o w a n a je s t w R a ilC o ja k o część r o z w ią ­ z a n ia m a ją c e g o z a s tą p ić o r y g in a ln e u s łu g i h y b r y d o w e W y s t a w i e n i e f a k t u r y i R e a l i z a c j a z a m ó w ie n ia . P o z o s ta je je s z c z e u s łu g a S u b s k r y p c ja T L S , s łu ż ą c a , z g o d n ie z n a z w ą , d o s u b ­ s k r y b o w a n ia ro z s z e r z e ń p u b lik o w a n y c h p r z e z T L S . B e z p r o b le m u m o ż n a s tw ie r d z ić , że f u n k ­ c jo n a ln o ś ć p la n o w a n e j u s łu g i K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h n ie je s t w ż a d n e j części r e d u n d a n tn a .

K r o k 2 .: p o t w ie r d z e n ie k o n t e k s t u W tr a k c ie a n a liz y z o r ie n to w a n e j n a u s łu g i n a p ie r w s z y p la n w y s u w a ją się ze z r o z u m ia ły c h w z g lę d ó w w y m a g a n ia b iz n e s o w e , p r z e z co tr o s k a o s p ó jn o ś ć k o n t e k s t u w y ła n ia n y c h w ó w c z a s u s łu g a p lik a ­ c y jn y c h s ta je s ię r a c z e j z a g a d n ie n ie m m n ie js z e j w a g i. C e lo w e je s t z a t e m p ó ź n ie js z e z a tr o s z c z e ­ n ie się o t ą s p ó jn o ś ć , a p r z y o k a z ji t a k ż e o w y e lim i n o w a n ie e w e n tu a ln e j r e d u n d a n c ji, p o d o b n ie j a k w k r o k u n r 1.

UW AGA Spójność kontekstu biznesowych usług podm iotowych wynika bezpośrednio z faktu, iż projektow ane są one na bazie istniejących m odeli biznesowych. D odatkow a troska, będąca istotą opisyw anego kroku, jest w ięc w ich przypadku całkow icie zbędna.

A N A LIZA PRZYPADKU P r z e g lą d is tn ie ją c y c h w R a ilC o u s łu g i ic h k o n f r o n t a c ja z p la n o w a n y m i n o w y m i u s łu g a m i p o t w i e r d z i ł y z a s a d n o ś ć z g r u p o w a n ia k a n d y d a t u r n a o p e r a c je w r a m a c h k a n d y d a t u r y n a u s łu g ę K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h .

460

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

K r o k 3 .: w y p r o w a d z e n ie p o c z ą t k o w e j p o s t a c i in t e r f e js u A n a l iz u j ą c p r o p o n o w a n e k a n d y d a t u r y n a o p e r a c je u s łu g i, p r z y s t ę p u je m y d o s k o n s tr u o w a n ia p ie r w s z e j w e r s ji je j in te r fe js u i w y k o n u je m y k o le jn o p o n iż s z e k r o k i. 1. U p e w n i a m y s ię , ż e z ia r n is to ś ć lo g i k i p r o p o n o w a n y c h o p e r a c ji s p r a w ia , ż e te o p e r a c je są w y s ta r c z a ją c o g e n e r y c z n e i w ie lo u ż y w a ln e . 2. D o k u m e n t u je m y w a rto ś c i w e jś c io w e i w y jś c io w e z w ią z a n e z k a ż d ą z p r o p o n o w a n y c h o p e ra c ji i d e fin iu je m y s tr u k t u r y o d p o w ie d n ic h k o m u n ik a t ó w , w y k o r z y s tu ją c k o n s tr u k c je s c h e m a tó w X S D (k o n k r e tn ie — k o n s tr u k c je

types w d e fin ic ji W S D L ) .

portType (a lb o interface ) operation . D o d a je m y ta k ż e w y m a g a n e k o n s tru k c je message w r a z z p o to m n y m i e le m e n ta m i part o d w o łu ją c y m i się d o o d p o w ie d n ic h ty p ó w d a n y c h .

3. U z u p e łn ia m y a b s tra k c y jn ą część d e fin ic ji W S D L , d o d a ją c k o n s tru k c ję w r a z z p o to m n y m i k o n s tr u k c ja m i

N i e z a p o m in a jm y , że u s łu g i a p lik a c y jn e ja k o g e n e r y c z n e je d n o s tk i lo g ik i p r z e t w a r z a n ia w y k o ­ r z y s ty w a n e m o g ą b y ć p r z e z u s łu g i b iz n e s o w e r ó ż n y c h ty p ó w . M o g ą w ią z a ć się z p r z e t w a r z a n ie m r ó ż n e g o t y p u d o k u m e n t ó w ( f a k t u r , z a m ó w ie ń , r e k la m a c ji i t y m p o d o b n y c h ) i ta r ó ż n o r o d n o ś ć m u s i b y ć o d z w ie r c ie d lo n a w u n iw e r s a ln o ś c i lo g i k i u s łu g i a p lik a c y jn e j. O d n a t u r y o c z e k iw a n e j in f o r m a c ji d o p r z e t w o r z e n ia z a le ż y w ie le o p c ji p r o je k t o w y c h . •

P r z y k ła d e m m o ż e b y ć u tw o r z e n ie z b io r u o p e r a c ji g e n e r y c z n y c h , le c z w c ią ż s p e c y fic z n y c h d la k o n k r e t n e g o ty p u d o k u m e n t u , c z y li z a m ia s t u n iw e r s a ln e j o p e r a c ji D o d a j b u d u je m y o s o b n e o p e r a c je D o d a j F a k t u r e , D o d a j Z l e c e n i e Z a k u p u i D o d a j R e k la m a c je .

•

D r u g i p r z y k ła d to w y p o s a ż e n ie u s łu g a p lik a c y jn y c h w m o ż liw o ś ć p r z e t w a r z a n ia z a łą c z n ik ó w S O A P , d z ię k i c z e m u g e n e r y c z n e k o m u n ik a t y S O A P g e n e r o w a n e p r z e z g e n e r y c z n e o p e ra c je p r z e s y ła ć b ę d ą s p e c y fic z n e d o k u m e n t y w p o s ta c i ty c h ż e z a łą c z n ik ó w .

A N A LIZA PRZYPADKU W

R a ilC o r o z p o c z ę to p r o je k t o w a n ie u s łu g i K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h o d z d e fi­

n io w a n ia d w ó c h o p e ra c ji, K o n w e r t u jN a F o r m a t N a t y w n y 15 i K o n w e r t u j N a F o r m a t X M L 16, o d p o ­ w ia d a ją c y c h k a n d y d a t u r o m ( k o le jn o ) k o n w e r t u j d o k u m e n t z f o r m a t u X M L n a f o r m a t n a t y w n y i k o n w e r t u j d o k u m e n t z n a ty w n e g o f o r m a t u n a f o r m a t X M L ( p a t r z r y s u n e k 1 5 .1 3 ).

Rysunek 15.13. Pierwsza wersja usługi Konwersja dokumentów księgowych

15 W oryginale TransformToNative — przyp. tłum. 16 W oryginale TransformToXML — przyp. tłum.

1 5 .3 . PRO JEK TO W A N IE USŁUG APLIKACYJNYCH — KROK PO KROKU

46 1

W k o le jn y m k r o k u z d e fin io w a n o k o m u n ik a t - ż ą d a n ie i k o m u n ik a t - o d p o w ie d ź d la o p e r a c ji K o n w e r t u jN a F o r m a t N a t y w n y . Przykład 15.9. Typy schematu XSD wymagane przez operację KonwertujNaFormatNatywny < x sd :sch e m a targ etN am esp ace= " h t t p : / / w w w . x m l t c . c o m / r a i l c o / t r a n s f o r m / s c h e m a / "> < x s d : e l e m e n t n a m e = " TransformToNativeType " > < x s d :c o m p le x T y p e > < x s d :e le m e n t na m e = "S ource P ath" ty p e = " x s d :s trin g " /> < x s d :e le m e n t n a m e = "D e s tin a tio n P a th " ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d : e l e m e n t n a m e = " TransformToNati veReturnCodeType " > < x s d :c o m p le x T y p e > < x s d : e le m e n t nam e="C ode" ty p e = "x s d :in te g e r"/> < x s d :e le m e n t nam e="M essage" ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /x s d :s c h e m a >

P o a n a liz ie o p e r a c ji K o n w e r t u j N a F o r m a t X M L s tw ie r d z o n o , że w y m a g a o n a id e n ty c z n y c h t y p ó w d a n y c h . W t a k im p r z y p a d k u a ż p r o s i się o e le g a n c k ie w s p ó łd z ie le n ie (im p o r to w a n y c h ) d e f in ic ji t y p ó w , le c z w R a ilC o z d e c y d o w a n o in a c z e j: u t w o r z o n o m i a n o w ic ie r e d u n d a n t n e d e fin ic je id e n t y c z n y c h t y p ó w , u n ie z a le ż n ia ją c w te n s p o s ó b o d s ie b ie o b ie o p e r a c je i z a p e w ­ n ia ją c p r z y s z łe ic h m o d y f ik o w a n ie b e z w z a je m n e g o w p ły w u n a s ie b ie . Przykład 15 .10 . Definicje dodatkowych typów danych dedykowanych operacji KonwertujNaFormatXML < x s d :e le m e n t na m e ="Tra nsform T oX M LType"> < x s d :c o m p le x T y p e > < x s d :e le m e n t na m e = "S ource P ath" ty p e = " x s d :s trin g " /> < x s d :e le m e n t n a m e = "D e s tin a tio n P a th " ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d :e le m e n t n a m e = "T ra nsform T oX M LR eturnC od eT yp e"> < x s d :c o m p le x T y p e > < x s d : e le m e n t nam e="C ode" ty p e = "x s d :in te g e r"/> < x s d :e le m e n t nam e="M essage" ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t>

462

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

A b s t r a k c y jn ą część d e fin ic ji W S D L d o p e łn iły n ie z b ę d n e k o n s tr u k c je

message i portType .

Przykład 15 .11 . Konstrukcje message i portType jako część abstrakcyjnej definicji usługi Konwersja dokumentów księgowych < m e s s a g e name= < p a r t name= e le m e n t= < m e s s a g e name= < p a r t name= e le m e n t= < m e s s a g e name= < p a r t name= e le m e n t= < m e s s a g e name= < p a r t name= e le m e n t=

tra n s fo rm T o N a tiv e R e q u e s tM e s s a g e "> R e q uestP aram eter" trn :T ra n s fo rm T o N a tiv e T y p e "/> tra n s fo rm T o N a tiv e R e s p o n s e M e s s a g e "> R e s ponseP aram eter" trn :T ra n s fo rm T o N a tiv e R e tu rn C o d e T y p e "/> tra n sform T o X M LR equ estM essage"> R e q uestP aram eter" trn :T ra n s fo rm T o X M L T y p e "/> transform ToX M LR esponseM essage"> R e s ponseP aram eter" trn :T ra n s fo rm T o X M L R e tu rn C o d e T y p e "/>

< p o rtT y p e n a m e = "T ra n s fo rm In te rfa c e "> < o p e r a t io n n a m e = "K o n w e rtu jN a F o rm a tN a ty w n y "> < in p u t message= "tn s :tra n s fo rm T o N a tiv e R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :tra n s fo rm T o N a tiv e R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a t io n n a m e = "K o n w e rtu jN a F o rm a tX M L "> < in p u t message= "tn s :tra n s fo rm T o X M L R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :tra n s fo rm T o X M L R e s p o n s e M e s s a g e "/> < /o p e ra tio n >

UW AGA RailCo zobow iązana została przez TLS do budowania usług zgodnych z zaleceniami W S - Basic Profile w wersji 1.1. To w ym aga od RailCo budowania interfejsów na podstawie specyfikacji WSDL 1.1. I bardzo dobrze, bo używ ane przez RailCo oprogram ow anie m iddlew are nie obsługuje wersji WSDL 2.0.

K r o k 4 .: z a s t o s o w a n ie z a s a d o r i e n t a c j i n a u s łu g i T e n k r o k d e d y k o w a n y je s t c z te r e m n ie w s p ie r a n y m p r z e z u s łu g i s ie c io w e z a s a d o m o r ie n ta c ji n a u s łu g i — w ie lo u ż y w a ln o ś c i, a u t o n o m ii, b e z s ta n o w o ś c i i w y k r y w a ln o ś c i u s łu g ; w y ja ś n ia liś m y ju ż tę k w e s tię w r o z d z ia le 8. P r o b le m w ie lo u ż y w a ln o ś c i u s łu g i b y ł j u ż d y s k u to w a n y p r z y o k a z ji p r o c e s u m o d e lo w a n ia ; p o ­ w r ó c im y d o n ie g o w k r o k u S. te g o s c e n a riu s z a , g d z ie b ę d z ie m y się s ta ra ć , b y n a s z a u s łu g a a p lik a ­ c y jn a s ta ła się p r z y d a t n a d la j a k n a js z e rs z e g o k r ę g u p o te n c ja ln y c h w n io s k o d a w c ó w . N ie z a le ż n ie o d te g o n a le ż y z w e r y f ik o w a ć is tn ie ją c e k a n d y d a t u r y n a u s łu g i p o d k ą te m te g o , c z y są z a p r o je k t o ­ w a n e ja k o g e n e r y c z n e i w ie lo u ż y w a ln e .

1 5 .3 . PRO JEK TO W A N IE USŁUG APLIKACYJNYCH — KROK PO KROKU

463

A u t o n o m ia u s łu g i a p lik a c y jn e j je s t je d n ą z je j k lu c z o w y c h c e c h , n ie z w y k le is to t n ą n a e ta p ie p r o je k to w a n ia . M u s i m y m ia n o w ic ie u p e w n ić się, ż e lo g ik a u s łu g i o d p o w ie d z ia ln a z a r e a liz o w a n ie je j o p e r a c ji n ie n a r z u c a u z a le ż n ie ń n a tę u s łu g ę lu b s a m a n ie je s t p r z e d m io t e m ty c h u z a le ż n ie ń . P u n k t e m s ta r to w y m te j w e r y f ik a c ji m o ż e b y ć in f o r m a c ja z e b r a n a w k r o k u 2. a n a liz y z o r ie n to w a ­ n e j n a u s łu g i. P o w r a c a m y d o te j k w e s tii w k r o k u 6. te g o s c e n a riu s z a , o m a w ia ją c p r z y o k a z ji je szcze in n e p r o b le m y n a t u r y te c h n o lo g ic z n e j. B e z s ta n o w o ś ć je s t w p r z y p a d k u u s łu g a p lik a c y jn y c h z n a c z n ie t r u d n ie js z a d o o s ią g n ię c ia n iż w p r z y p a d k u u s łu g b iz n e s o w y c h . P o n ie w a ż o d u s łu g a p lik a c y jn y c h w y m a g a się w s p ó łd z ia ła n ia z w ie lo m a r ó ż n y m i p la t f o r m a m i te c h n o lo g ic z n y m i, ic h d o c e lo w e w a r u n k i p r a c y o k a z u ją się m a ło p r z e w id y w a ln e . W c z e ś n ie j c z y p ó ź n ie j k a ż d a u s łu g a a p lik a c y jn a d o ś w ia d c z y ć m o ż e s k u t k ó w n ie ­ s p ó jn y c h lu b n ie r o z s ą d n y c h o g r a n ic z e ń i w y m o g ó w w z a k re s ie p r z e tw a r z a n ia (p r z e s ta rz a łe „ s p a d ­ k o w e ” s y s te m y c e lu ją w r ę c z w ta k ic h n ie s p o d z ia n k a c h ). I d la te g o je d y n ą rze c z ą , k tó r ą u c z y n ić m o ż n a d la p o p r a w y te g o s ta n u r z e c z y , je s t p r z e a n a liz o w a n ie p o te n c ja ln y c h u w a r u n k o w a ń d z ia ła n ia p r o ­ je k to w a n e j u s łu g i, z a n im je s z c z e z a b ie r z e m y się z a k o n k r e t n e je j p r o je k to w a n ie . P o d o b n ie ja k w p r z y p a d k u b iz n e s o w y c h u s łu g p o d m io t o w y c h , w y k r y w a ln o ś ć m o ż e s ta ć się w a ż n y m a s p e k te m e w o lu o w a n ia w a r s t w y u s łu g a p lik a c y jn y c h . P r z e d e w s z y s tk im d z ię k i ła t w e m u w y k r y w a n iu u s łu g ła tw ie j m o ż e m y u n ik a ć r e d u n d a n c ji, c z y li p o n o w n e g o p r o je k t o w a n ia lo g ik i ju ż e n k a p s u lo w a n e j p r z e z in n e u s łu g i — a to c z y n i z w y k r y w a ln o ś c i coś w ię c e j n iż t y lk o w y m a g a n ie in f r a s t r u k t u r a ln e s p e c y fic z n e d la d a n e j im p le m e n t a c ji S O A . N ie u m n ie js z a to je d n a k w n ic z y m z n a c z e n ia m e ta d a n y c h , w k t ó r e k a ż d a u s łu g a a p lik a c y jn a p o w in n a b y ć j a k n a jo b fic ie j w y p o s a ż o n a , o c z y m p is z e m y w p u n k c ie 1 5 .5 .1 0 , „ D o k u m e n t o w a n ie u s łu g z a p o m o c ą m e ta d a n y c h ” .

A N A LIZA PRZYPADKU P r o je k t u s łu g i K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h p o d d a n y z o s t a ł o p is a n e j w e r y f i k a c ji n a o k o lic z n o ś ć p r a w id ło w e g o u w z g lę d n ie n ia z a s a d o r ie n t a c ji n a u s łu g i. R o z p o c z ę to o d z w e r y f ik o w a n ia p o t e n c ja łu w ie lo u ż y w a ln o ś c i o b u o p e r a c ji, c z y li: •

K o n w e r tu jN a F o r m a tN a ty w n y ,

•

K o n w e r tu jN a F o r m a tX M L .

P o k r ó t k i e j d y s k u s ji d o t y c z ą c e j p r o p o z y c ji p o łą c z e n ia t y c h o p e r a c ji w je d n ą o p e r a c ję T r a n s f o r m , p o s t a n o w io n o p r o p o z y c ję tę o d r z u c ić . O b ie o p e r a c je są s a m o d o k u m e n t u ją c e , a p o n a d to z d e c y d o w a n o , iż p o z o s ta w ie n ie o b u o t w ie r a d r o g ę d o n ie z a le ż n e g o ic h r o z w ija n ia w p rz y s z ło ś c i. N a s tę p n ie p r z y s tą p io n o d o z w e r y f ik o w a n ia k w e s tii z w ią z a n y c h z a u to n o m ią i b e z s ta n o w o ś c ią . A u t o n o m ia u s łu g i je s t b e z d y s k u s y jn a , b o lo g ik a z w ią z a n a z t r a n s f o r m o w a n ie m d o ­ k u m e n t ó w z a w ie r a się c a łk o w ic ie w e w n ą t r z s a m e j u s łu g i, p o s ia d a ją c e j ( w czasie tr a n s fo r m a c ji) w y łą c z n y d o s tę p d o k o n w e r to w a n e g o d o k u m e n tu . T a k ż e b e z s ta n o w o ś ć u s łu g i je s t s p ra w ą o c z y ­ w is tą , b o k o n w e r s ja d o k u m e n t u n a s tę p u je w je d n y m ( k r ó t k im ) a k c ie , p o z a k t ó r y m n ie is tn ie je ż a d e n k o n te k s t p r z e t w a r z a n ia . P o s t a n o w io n o te ż p o le p s z y ć w y k r y w a ln o ś ć p r o je k t o w a n e j u s łu g i p o p r z e z u m ie s z c z e n ie w je j d e f in ic ji k r ó t k ie g o o p is u s p e łn ia n y c h p r z e z n ią f u n k c ji.

464

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

Przykład 15 .12 . Konstrukcja portType definicji WSDL usługi Konwersja dokumentów księgowych wyposażona w porcję metadanych dokumentujących tę usługę < p o rtT y p e n a m e = "T ra n s fo rm In te rfa c e "> < docum entation > O d b i e r a d o k u m e n t w f o r m a c i e XML i k o n w e r t u j e go na n a ty w n y f o r m a t s y s te m u f in a n s o w o - k s ię g o w e g o . < / docum entation > < o p e r a t io n n a m e = "K o n w e rtu jN a F o rm a tN a ty w n y "> < in p u t message= "tn s :tra n s fo rm T o N a tiv e R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :tra n s fo rm T o N a tiv e R e s p o n s e M e s s a g e "/> < /o p e ra tio n > < docum entation > O d c z y t u j e do kum en t w f o r m a c i e na tyw n ym d l a s y s te m u f in a n s o w o - k s ię g o w e g o i k o n w e r t u j e g o n a f o r m a t XML. < / docum entation > < o p e r a t io n n a m e = "K o n w e rtu jN a F o rm a tX M L "> < in p u t message= "tn s :tra n s fo rm T o X M L R e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :tra n s fo rm T o X M L R e s p o n s e M e s s a g e "/> < /o p e ra tio n >

K r o k 5 .: s t a n d a r y z a c ja i u d o s k o n a la n ie in t e r f e j s u u s łu g i Jeśli n a w e t r o la i p r z e z n a c z e n ie u s łu g a p lik a c y jn y c h są in n e n iż u s łu g b iz n e s o w y c h , w a ż n e je s t, b y w s z y s tk ie u s łu g i p r o je k to w a n e b y ły w e d łu g ty c h s a m y c h f u n d a m e n t a ln y c h m e t o d o lo g ii. M o ż n a z w e r y f ik o w a ć s p e łn ie n ie te g o w y m o g u p r z e z z a p e w n ie n ie , że k a ż d a w y n ik o w a d e fin ic ja W S D L u s łu g i a p lik a c y jn e j s p o r z ą d z o n a je s t w o p a r c iu o te s a m e s t a n d a r d y i k o n w e n c je , co in n e d e fin ic je . D o u z y s k a n ia s ta n d a r d o w e g o i e le g a n c k ie g o p r o je k tu d a n e j u s łu g i m o g ą p r z y c z y n ić się p o n iż s z e d z ia ła n ia . •

Z a s to s o w a n ie d o w o ln e g o is tn ie ją c e g o s ta n d a r d u p r o je k to w e g o p o z o s ta ją c e g o w z w ią z k u z in te r fe js e m te j u s łu g i (p o d k o n ie c te g o r o z d z ia łu p r z e d s ta w ia m y lis tę t a k ic h s u g e r o w a n y c h s ta n d a r d ó w ).

•

D la d o w o ln e j c e c h y c h a r a k te r y s ty k i w s p ó łc z e s n e j S O A , k t ó r a m a b y ć w s p ie r a n a p r z e z p r o je k t o w a n e u s łu g i, o c e n a , c z y m o ż liw e je s t w b u d o w a n ie te g o w s p a r c ia w p r o je k t te j k o n k r e t n e j u s łu g i.

•

O p c jo n a ln ie — z a p e w n ie n ie z g o d n o ś c i z r e g u ła m i W S - I B a s ic P r o file i i n n y m i s p r a w d z o n y m i p r a k t y k a m i, w d o w o ln y m m o ż liw y m z a k re s ie .

A N A LIZA PRZYPADKU U s łu g a K o n w e r s j a d o k u m e n t ó w k s ię g o w y c h p o n o w n ie s ta ła się o b ie k te m w e r y f ik a c ji, t y m r a z e m p o d k ą t e m o p is y w a n e j s ta n d a r y z a c ji. S t w ie r d z o n o , że o ile n a z w y o p e r a c ji p o z o s ta ją w z g o d z ie z p r z y j ę t y m i k o n w e n c j a m i , to n a z w a s a m e j u s łu g i j u ż n ie ; z d e c y d o w a n o z a t e m o z m ia n ie je j n a z w y n a K o n w e r s j a k s ię g o w a .

1 5 .3 . PRO JEK TO W A N IE USŁUG APLIKACYJNYCH — KROK PO KROKU

465

Ponieważ jednym z podstawowych celów SOA budowanej w RailCo jest m inimalizacja przyszłych wysiłków związanych z jej rozbudową, spośród wszystkich cech charakterystyki współczesnej SOA za jedną z najważniejszych przyjęto rozszerzalność usług — wsparcie dla tej rozszerzalności m a być wbudowywane w każdą projektowaną usługę, gdy tylko zidentyfi­ kowana zostanie potencjalna sposobność ku temu. W tym konkretnym przypadku zdecydo­ wano, że lepszą rozszerzalność usługi mogą zapewnić następujące zabiegi. • Ponowne skrócenie nazwy usługi — teraz nazywać się będzie bardziej ogólnie: K o n w e r s ja . • Zmiana nazw operacji na bardziej generyczne — zamiast K o n w e r t u j N a F o r m a t N a t y w n y i K o n w e r t u j N a F o r m a t X M L teraz nazywać się będą (kolejno) I m p o r t u jD o S y s t e m u K s ie g o w e g o 17 i E k s p o r t u jZ S y s t e m u K s ie g o w e g o 18. Ostateczną postać usługi m ożna zobaczyć na rysunku 15.14.

Rysunek 15.14. Finalna postać projektowanej usługi konwersyjnej

Zm iany te pow inny — oczywiście — znaleźć odzwierciedlenie w nazwach konstrukcji element i message. Przykład 15 .13 . Zrewidowana konstrukcja types < typ e s> < x sd:sch em a targ etN am esp ace= " h t t p : / / w w w . x m l t c . c o m / r a i l c o / t r a n s f o r m / s c h e m a / "> < x s d : e l e m e n t n a m e = " ForImportType " > < x sd :co m p l exType> < x s d :e le m e n t na m e = "S ource P ath" ty p e = " x s d :s trin g " /> < x s d :e le m e n t n a m e = "D e s tin a tio n P a th " ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e >

17 W oryginale ForAccountingIm port — przyp. tłum. 18 W oryginale ForAccountingExport — przyp. tłum.

466

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

< /x s d :e le m e n t> < x s d : e l e m e n t n a m e = " ForIm portR eturnC odeType " > < x s d :c o m p le x T y p e > < x s d : e le m e n t nam e="C ode" ty p e = "x s d :i n te g e r"/> < x s d :e le m e n t nam e="M essage" ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d : e l e m e n t n a m e = " ForE xportType " > < x s d :c o m p le x T y p e > < x s d :e le m e n t na m e = "S ource P ath" ty p e = " x s d :s trin g " /> < x s d :e le m e n t n a m e = "D e s tin a tio n P a th " ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d : e l e m e n t n a m e = " ForExportReturnC odeType " > < x s d :c o m p le x T y p e > < x s d : e le m e n t nam e="C ode" ty p e = "x s d :in te g e r"/> < x s d :e le m e n t nam e="M essage" ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /xs d :s ch e m a > < /typ e s >

P o w y ż s z e z m ia n y p o z y c jo n u ją p r o je k t o w a n ą u s łu g ę w r o li g e n e r y c z n e g o k o n w e r t e r a d o ­ k u m e n t ó w , o b e c n ie d z ia ła ją c e g o je d y n ie w k o n te k ś c ie s y s te m u f in a n s o w o -k s ię g o w e g o , le c z p r a w d o p o d o b n ie r o z s z e r z a n e g o w p rz y s z ło ś c i o n o w e k o n te k s t y k o n w e r s ji.

Krok 6.: rozszerzenie kandydatury o wyniki analizy spekulatywnej D a le k o w z r o c z n o ś ć je s t g e n e r a ln ie p o ż ą d a n ą p r a k t y k ą , a w ie lo u ż y w a ln o ś ć u s łu g a p lik a c y jn y c h ic h n ie z w y k le p o ż ą d a n ą z a le tą . D y s p o n u ją c z a t e m k o n k r e t n ą p o s ta c ią p r o je k t u u s łu g i, w a r to p u ś c ić w o d z e fa n ta z ji i z a s ta n o w ić się, c z y i j a k m o ż n a ( i o p ła c a się) te n p r o je k t u c z y n ić b a r d z ie j o g ó ln y m , b e z u s z c z e rb k u d la z a s p o k o je n ia b ie ż ą c y c h p o tr z e b , z a to z (p e r s p e k ty w ic z n ą ) m y ś lą o w ię k s z e j u n i­ w e rs a ln o ś c i ( c z y li — p o te n c ja ln ie w ię k s z e j w ie lo u ż y w a ln o ś c i) r z e c z o n e j u s łu g i. W p r a k ty c e m o ż e to o z n a c z a ć z a r ó w n o m o d y f ik o w a n ie is tn ie ją c y c h o p e r a c ji te j u s łu g i, j a k i d e fin io w a n ie n o w y c h . T a k ie j s p e k u la ty w n e j a n a liz ie m u s i je d n a k t o w a r z y s z y ć to , co s ta n o w i is to tę k r o k u 1., c z y li d ą ­ ż e n ie d o u n ik a n ia r e d u n d a n c ji. P o n a d t o , g d y o s ta te c z n ie z id e n t y f ik o w a n y z o s ta n ie z b ió r fa k ty c z ­ n ie p o t r z e b n y c h r o z s z e r z e ń i m o d y f ik a c ji, k o n ie c z n e je s t p o w t ó r z e n ie k r o k ó w o d 2. d o 5. w c e lu z a p e w n ie n ia , ż e in w e n c ja t w ó r c z a n ie o k a ż e się f a t a ln a w s k u tk a c h d la s ta n d a r y z a c ji i e le g a n c ji d o ty c h c z a s w y p r a c o w a n e g o in te r fe js u .

1 5 .3 . PRO JEK TO W A N IE USŁUG APLIKACYJNYCH — KROK PO KROKU

467

ANALIZA PRZYPADKU M i m o iż R a ilC o c h c ia ła b y t w o r z y ć w y s o c e w ie lo u ż y w a ln e u s łu g i a p lik a c y jn e , to o b e c n ie , p o d p r e s ją b ie ż ą c y c h p o tr z e b , n ie m o ż e s o b ie p o z w o lić n a t a k i lu k s u s . Z a p r o je k t o w a n a u s łu g a

Konwersja je s t w y s ta r c z a ją c o g e n e r y c z n a i w ie lo u ż y w a ln a , b y z a s p o k o ić p o t r z e b y p r o c e s ó w w y s ta w ia n ia f a k t u r i r e a liz a c ji z a m ó w ie ń , z a te m w R a ilC o u z n a n o , ż e s p e łn ia b ie ż ą c e w y m a ­ g a n ia . O c z y w iś c ie , n ie p r z e s z k a d z a to w je j p r z y s z ły m r o z w ija n iu , g d y p o ja w ia ć się b ę d ą n o w e p o t r z e b y w z a k r e s ie k o n w e r s ji d o k u m e n t ó w .

ANALIZA PRZYPADKU (WYNIKI PROCESU) O s ta te c z n ie d e fin ic ja W S D L u s łu g i

Konwersja , p o z m ia n ie n a z w e le m e n t ó w i p o p r z e d n ic h

r e w iz ja c h , p r z y jm u je p r z e d s ta w io n ą n iż e j p o s ta ć . Przykład 15 .14 . Finalna wersja abstrakcyjnej części definicji WSDL usługi Konwersja < d e f i n i t i o n s na m e = "K o n w e rsja " targ etN am esp ace= " h ttp ://w w w .x m ltc .c o m /ra ilc o /tra n s fo rm /w s d l/ " x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o r g /w s d l/" x m ln s :s o a p = "h ttp : // s c h e m a s . x m ls o a p . o r g /w s d l/s o a p / " x m ln s :tn s = "h ttp ://w w w .x m ltc .c o m /ra ilc o /tra n s fo rm /w s d l/" x m ln s :trn = "h ttp ://w w w .x m ltc .c o m /ra ilc o /tra n s fo rm /s c h e m a /" x m ln s : x s d = " h ttp ://w w w .w 3 .o r g /2 0 0 1 /X M L S c h e m a "> < x sd:sch em a targ etN am esp ace= " h t t p : / / w w w . x m l t c . c o m / r a i l c o / t r a n s f o r m / s c h e m a / "> < x s d :e le m e n t n a m e = "F o rIm p o rtT y p e "> < x sd :co m p l exType> < xsd:seq uen ce> < x s d :e le m e n t na m e = "S ource P ath" ty p e = " x s d :s trin g " /> < x s d :e le m e n t n a m e = "D e s tin a tio n P a th " ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d :e le m e n t n a m e = "F o rIm p o rtR e tu rn C o d e T y p e "> < x s d :c o m p le x T y p e > < xsd:seq uen ce> < x s d : e le m e n t nam e="C ode" ty p e = "x s d :in te g e r"/> < x s d :e le m e n t nam e="M essage" ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d :e le m e n t n a m e = "F orE xpo rtT yp e"> < x s d :c o m p le x T y p e > < xsd:seq uen ce> < x s d :e le m e n t na m e = "S ource P ath" ty p e = " x s d :s trin g " /> < x s d :e le m e n t n a m e = "D e s tin a tio n P a th " ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e >

468

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

< /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < x s d :e le m e n t na m e = "F o rE xp o rtR e tu rn C o d e T yp e "> < x s d :c o m p le x T y p e > < x s d : e le m e n t nam e="C ode" ty p e = "x s d :in te g e r"/> < x s d :e le m e n t nam e="M essage" ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /xs d :s c h e m a > < /typ e s > < p a r t na m e = "R e q u e stP a ra m e te r" e le m e n t= "trn :F o rIm p o rtT y p e "/> < p a r t n a m e = "R esp onse P aram eter" e le m e n t= "trn :F o rIm p o rtR e tu rn C o d e T y p e "/> < p a r t na m e = "R e q u e stP a ra m e te r" e le m e n t= "trn :F o rE x p o rtT y p e "/> < p a r t n a m e = "R esp onse P aram eter" e le m e n t= "trn :F o rE x p o rtR e tu rn C o d e T y p e "/> < p o rtT yp e n a m e = "T ra n s fo rm In te rfa c e "> < d o c u m e n ta tio n > I m p o r t u j D o S y s t e m u K s i e g o w e g o p o b i e r a d o k u m e n t w f o r m a c i e XML i k o n w e r t u je go na f o r m a t n a ty w n y d l a s y s te m u f in a n s o w o - k s ię g o w e g o . E k s p o r t u jZ S y s t e m u K s ie g o w e g o p o b i e r a d o k u m e n t w f o r m a c i e n a ty w n ym d l a s y s t e m u f i n a n s o w o - k s i ę g o w e g o i k o n w e r t u j e g o n a f o r m a t XML. < /d o c u m e n ta tio n > < o p e r a tio n na m e = "Im p o rtu jD o S y ste m u K sie g o w e g o "> < in p u t message= "tn s :F o rA c c o u n tin g Im p o rtR e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :F o rA c c o u n tin g Im p o rtR e s p o n s e M e s s a g e "/> < /o p e ra tio n > < o p e r a tio n n a m e = "E k s p o rtu jZ S y ste m u K sie g o w e g o "> < in p u t message= "tn s :F o rA c c o u n tin g E x p o rtR e q u e s tM e s s a g e "/> < o u tp u t message= "tn s :F o rA c c o u n tin g E x p o rtR e s p o n s e M e s s a g e "/> < /o p e ra tio n > < /p o rtT yp e > < /d e fin itio n s >

UWAGA Jak w idać, ograniczyliśmy się tylko do części abstrakcyjnej definicji. Całość pobrać można z serwera FTP w ydaw n ictw a Helion ftp ://ftp .h e lio n .p l/p rzy k la d y/so a k o n .z ip .

1 5 .4 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG Z A D A N IO W Y C H — KROK PO KROKU

469

PODSUMOWANIE •

Usługi aplikacyjne pow inny być projektow ane jako agnostyczne procesowo oraz im plem entujące model usługi użytkowej, dzięki czemu uzyskają wysoki stopień w ieloużywalności.

•

Analiza spekulatywna może przyczynić się do udoskonalenia projektu interfejsu usługi, ta k by eksponow ał generyczne i w ieloużyw alne operacje.

1 5 .4 . P ro je k to w a n ie b izn e s o w y c h usług z a d a n io w y c h — k ro k p o kroku P r o c e s p r o j e k t o w a n i a b iz n e s o w y c h u s łu g z a d a n io w y c h w y m a g a z r e g u ły m n ie js z e g o w y s iłk u , w p o r ó w n a n i u z u s łu g a m i p o d m i o t o w y m i i u s łu g a m i a p lik a c y jn y m i, g łó w n i e z te j p r z y c z y n y , ż e w ie lo u ż y w a ln o ś ć n ie je s t w p r z y p a d k u u s łu g z a d a n io w y c h c e c h ą p ie r w s z o r z ę d n ą . N ie tr z e b a w ię c r o z s z e r z a ć z e s ta w u o p e r a c ji p o z a t e n , k t ó r y u s ta lo n o ja k o r e z u lt a t m o d e lo w a n ia . U m i e j s c o ­ w ie n i e b iz n e s o w y c h u s łu g z a d a n io w y c h w m o d e lu lo g i k i p r z e d s ię b io r s t w a p o k a z a n o n a r y ­ s u n k u 1 5 .1 5 .

\ 0---b 1 -1 1 i

-b i T[ T ^

------------------------------------------------------------------------------

I I

£t

d

CY "Q ~~Q Q Y b
Biznesow e usługi zadaniow e y rezydujące w w arstw ie usłu g o bok usług pod m iotow ych

^

b -------- ------------------- rb

-----

---------------

nj c y'

AJ

TO

S o.

\

w

\

\

\

Rysunek 15.15. Biznesowe usługi zadaniow e tworzące wraz z usługami podmiotowymi warstw ę usług biznesowych

470

1 5 .4 .1 .

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

P ro c e s

J a k w id a ć n a r y s u n k u 1 5 .1 6 , te n p ro c e s r o z p o c z y n a się k r o k ie m n o w e g o r o d z a ju — m a p o w a n ie m lo g ik i p r z e p ły w u p r a c y . T o s p e c y fik a u s łu g z a d a n io w y c h — z n a t u r y są o n e o d p o w ie d z ia ln e z a z a ­ r z ą d z a n ie c z ę ś c ia m i p r o c e s u b iz n e s o w e g o .

Analiza zorientowana usługowo

Krok 1 if Inwentaryzowanie istniejących usług

Projektowanie zorientowane usługowo Projektowanie biznesowych usług podmiotowych

if

Tworzenie usług

Projektowanie usług aplikacyjnych

Projektowanie biznesowych usług zadaniowych

Projektowanie procesu biznesowego zorientowanego na usługi

Administrowanie usługami

Krok 3

Krok 4

>r

Zastosowanie reguł orientacji na usługi

Wdrażanie usług

f

Definiowanie schematu podmiotu

Definiowanie abstrakcyjnego interfejsu

Testowanie usług

f

Krok2____________

Krok 5

>f

Standaryzowanie interfejsu usługi

Rysunek 15.16. Proces projektowania biznesowej usługi zadaniowej

1 5 .4 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG Z A D A N IO W Y C H — KROK PO KROKU

471

Z a u w a ż m y , że w p r z e d s t a w io n y m s c e n a r iu s z u n ie m a z a c h ę ty d o p o s z u k iw a n ia m o ż liw o ś c i r o z s z e r z a n ia f u n k c jo n a ln o ś c i u s łu g i p o n a d tę , k t ó r a z d e f in io w a n a z o s ta ła n a e ta p ie m o d e lo w a n ia . J a k w c z e ś n ie j w s p o m in a liś m y , g e n e r y c z n y i w ie lo u ż y w a ln y in te r fe js n ie je s t w p r z y p a d k u u s łu g i z a d a n io w e j s p r a w ą p r io r y te to w ą . N o to z a c z y n a m y .

ANALIZA PRZYPADKU W

R a ilC o w p ro c e s ie m o d e lo w a n ia u s łu g z id e n t y f ik o w a n o z a p o tr z e b o w a n ie n a b iz n e s o w ą

u s łu g ę z a d a n io w ą , o r g a n iz u ją c ą p r z e t w a r z a n ie f a k t u r g e n e r o w a n y c h p r z e z t r a d y c y jn y s y s te m fin a n s o w o - k s ię g o w y . T a k n a r o d z iła się k a n d y d a t u r a n a u s łu g ę

Przetwarzanie faktury, s y m ­

b o lic z n ie p r z e d s t a w io n a n a r y s u n k u 1 5 .1 7 .

Rysunek 15.17. Kandydatura na usługę Przetwarzanie faktury W p ie r w s z e j c h w ili w y d a je się b y ć p o z b a w io n e s e n s u is tn ie n ie u s łu g i z p u s ty m z b io r e m o p e r a c ji, je d n a k w p r z y p a d k u u s łu g z a d a n io w y c h o m a łe j s k a li t a k a s y tu a c ja je s t z ja w is k ie m d o ś ć p o w s z e c h n y m . U s łu g a n ie p o s ia d a w ła s n y c h o p e r a c ji z te g o p r o s te g o w z g lę d u , że f u n k ­ c jo n u je w y łą c z n ie ja k o k o n t r o le r , d e d y k o w a n y k o o r d y n o w a n iu p o d p o r z ą d k o w a n e j s o b ie k o m ­ p o z y c ji in n y c h u s łu g . D l a R a ilC o o z n a c z a to b u d o w a n ie in t e r fe js u te j u s łu g i k o m p le t n ie „ o d z e r a ” w p ro c e s ie je j p r o je k to w a n ia . N a s z c z ę ś c ie , is tn ie je p e w ie n p u n k t z a c z e p ie n ia d la te j c z y n n o ś c i — je s t n ią m o d e l k o m ­ p o z y c ji z b u d o w a n y w r a m a c h k r o k u 6. p r o c e s u m o d e lo w a n ia o p is y w a n e g o w r o z d z ia le 1 2 ., a p r z e d s t a w io n y p o n o w n ie n a r y s u n k u 1 5 .1 8 . I w ś w ie tle te g o m o d e lu „ p u s t a ” u s łu g a n a g le o k a z u je się w ie lc e z a a b s o r b o w a n a , b o k o o r d y n u ją c a d z ia ła n ie a ż c z te r e c h p o d p o r z ą d k o w a ­ n y c h u s łu g , w d z ie le p r z e t w a r z a n ia d o k u m e n t u fa k t u r y .

472

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

Usługa Przetwarzanie faktury

Rysunek 15.18. Kompozycja kontrolowana przez usługę Przetwarzanie faktury

Krok 1.: definiowanie logiki przepływu pracy B iz n e s o w e u s łu g i z a d a n io w e z a w ie r a ją z w y k le w b u d o w a n ą lo g ik ę z w ią z a n ą z k o n t r o lo w a n ie m p o d ­ p o r z ą d k o w a n e j k o m p o z y c ji. P ie r w s z y m k r o k ie m d o d e fin io w a n ia te j lo g ik i p o w in n o z a te m b y ć z i­ d e n ty fik o w a n ie w s z y s tk ic h m o ż liw y c h s c e n a riu s z y in te r a k c ji, ja k ie m o ż n a so b ie w y o b ra z ić . P o le k tu r z e w s p o m n ia n e g o f r a g m e n t u w r o z d z ia le 12. m a m y ju ż p e w ie n p u n k t w y jś c ia d la te j id e n ty fik a c ji. P o n ie w a ż p r z y s tę p u je m y d o p r o je k t o w a n ia u s łu g z a d a n io w y c h p o z a p r o je k to w a n iu u s łu g p o d ­ m io t o w y c h i u s łu g a p lik a c y jn y c h , p o w in n iś m y p o n o w n ie p r z y jr z e ć się w s p o m n ia n e m u s c e n a r iu ­ s z o w i w c e lu p r z e k s z ta łc e n ia g o w k o n k r e t n e m o d e le in t e r a k c ji u s łu g . Z a d a n ie to m o ż n a w y k o n a ć p r z y u ż y c iu r ó ż n y c h t r a d y c y jn y c h t e c h n ik m o d e lo w a n ia — m y d o a n a liz y p r z y p a d k u w y k o r z y s t a m y d ia g r a m y a k ty w n o ś c i. C e le m w y k o n a n ia ta k ie g o ć w ic z e n ia je s t u d o k u m e n t o w a n ie w s z y s tk ic h m o ż liw y c h ś c ie ż e k p r z e p ły w u a k ty w n o ś c i, z u w z g lę d n ie n ie m e w e n ­ tu a ln y c h s y tu a c ji w y ją t k o w y c h . O t r z y m a n e p r z y o k a z ji d ia g r a m y p r z y d a tn e b ę d ą ta k ż e w n a s tę p ­ n y c h a n a liz a c h p r z y p a d k ó w .

UWAGA Logika usługi zadaniow ej nie znajduje odzw ierciedlenia w jej interfejsie (w yjaśnim y to za chwilę). Powodem, dla którego zajmujem y się nią w tym miejscu, jest zidentyfikowanie komunikatów wymienianych przez usługę, a w konsekwencji odnośnych typó w , operacji i form atów wspom nianych kom unikatów .

ANALIZA PRZYPADKU W

R a ilC o s p o r z ą d z o n o d ia g r a m y d la w s z y s tk ic h d a ją c y c h się p r z e w id z ie ć s c e n a r iu s z y in t e ­

r a k c ji a n g a ż u ją c y c h u s łu g ę

Przetwarzanie faktury. P r z y jr z y m y się d w ó m t a k im d ia g r a m o m .

P ie r w s z y z n ic h , w id o c z n y n a r y s u n k u 1 5 .1 9 , ilu s t r u je w a r u n k i i w y m ia n ę k o m u n ik a t ó w z w ią z a n y c h z p r z e t w a r z a n ie m i w y s ta w ia n ie m fa k tu r .

1 5 .4 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG Z A D A N IO W Y C H — KROK PO KROKU

473

E

Rysunek 15.19. Pomyślne zrealizowanie Procesu wystawiania faktury D r u g i, z r y s u n k u 1 5 .2 0 , p o k a z u je , ja k s y tu a c ja a w a ry jn a p o w o d u je z a tr z y m a n ie (p r z e r w a n ie ) p r o c e s u w t r a k c ie r e a liz a c ji. W ta k ie j s y tu a c ji, s p o w o d o w a n e j p r z y p u s z c z a ln ie b łę d n y m d o ­ k u m e n t e m , u s łu g a

Konwersja p o w in n a z a s y g n a liz o w a ć b łą d .

474

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

Rysunek 15.20. Sytuacja awaryjna spowodowana błędem na etapie konwersji dokumentu

1 5 .4 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG Z A D A N IO W Y C H — KROK PO KROKU

475

Krok 2.: wyprowadzenie początkowej postaci interfejsu S u g e r o w a n y s c e n a riu s z k o n s t r u o w a n ia in te r fe js u u s łu g i p r z e d s ta w ia się n a s tę p u ją c o . 1. W y k o r z y s t a n ie k a n d y d a t u r n a o p e r a c je u s łu g i a p lik a c y jn e j w c e lu z d e f in io w a n ia o d p o w ia ­ d a ją c y c h i m o p e r a c ji. 2 . W o d r ó ż n ie n iu o d p r o c e s ó w p r o je k t o w a n ia o p is y w a n y c h p o p r z e d n io , t y m r a z e m m a t e r ia ł ź r ó d ło w y s ta n o w ią c y p o d s ta w ę d o w y p r o w a d z a n ia in te r fe js u o b e jm u je ta k ż e d ia g r a m y a k ­ ty w n o ś c i o r a z lo g ik ę p r z e p ły w u p r a c y , k t ó r ą u d o k u m e n t o w a liś m y w k r o k u 1. In f o r m a c ja ta m o ż e s ta n o w ić d o b r ą w s k a z ó w k ę d la e w e n t u a ln y c h d o d a t k o w y c h o p e r a c ji w y m a g a n y c h p r z e z n a s z ą u s łu g ę . 3. U d o k u m e n t o w a n ie w a r to ś c i w e jś c io w y c h i w y jś c io w y c h w y m a g a n y c h d o p r z e t w a r z a n ia k a ż d e j o p e r a c ji i w y p e łn ie n ie s e k c ji ty p e s d e fin ic ja m i s c h e m a tó w X S D z w ią z a n y c h z ty m p r z e t w a r z a n ie m . 4. Z b u d o w a n ie d e fin ic ji W S D L p o p r z e z u tw o r z e n ie o b s z a ru p o r tT y p e (lu b i n t e r f a c e ) , w y p e ł­ n ie n ie g o n ie z b ę d n y m i k o n s t r u k c ja m i o p e r a t io n o r a z d o d a n ie k o n s tr u k c ji m essage, z a w ie r a ­ ją c y c h z a g n ie ż d ż o n e k o n s tr u k c je p a r t o d w o łu ją c e się d o s to s o w n y c h s c h e m a tó w X S D .

ANALIZA PRZYPADKU P o n ie w a ż k a n d y d a t u r a n a u s łu g ę

Przetwarzanie faktury n ie z a w ie r a ż a d n y c h k a n d y d a t u r n a

o p e r a c je , w R a ilC o w y k o r z y s t a n o s p o r z ą d z o n y w ła ś n ie d ia g r a m a k ty w n o ś c i d o z d e f in io w a n ia z b io r u a k c ji, k t ó r y c h w y k o n y w a n ia w y m a g a się o d w s p o m n ia n e j u s łu g i ( p a tr z r y s u n e k 1 5 .2 1 ).

Rozpoczęcie Procesu wystawiania faktury po stronie RailCo

►

Rysunek 15.21. Zidentyfikowane komunikaty żądań i odpowiedzi dla usługi Przetwarzanie faktury •

R o z p o c z ę c ie p r z e t w a r z a n ia f a k t u r y p o s tr o n ie R a ilC o — o d e b r a n ie

Obserwowanie folderu i w r e z u lta c ie u r u c h o m ie n ie Procesu wystawiania faktury .

k o m u n ik a t u - p o w ia d o m ie n ia w y s ła n e g o p r z e z u s łu g ę

•

K o n w e r to w a n ie f a k t u r y — w y s ła n ie d o u s łu g i

Konwersja ż ą d a n ia p o b r a n ia d o k u m e n tu

f a k t u r y z fo ld e r u s ie c io w e g o i s k o n w e r to w a n ie te g o d o k u m e n tu n a f o r m a t X M L . •

Z w e r y fik o w a n ie m e ta d a n y c h T L S — w y s ła n ie d o u s łu g i

Kontrola metadanych

ż ą d a n ia s p r a w d z e n ia , c z y n a d s z e d ł czas z w e r y f ik o w a n ia a k tu a ln o ś c i m e t a d a n y c h T L S ; je ś li n a d s z e d ł, p o b r a n ia r z e c z o n y c h m e ta d a n y c h i z w e r y f ik o w a n ia ic h a k tu a ln o ś c i.

476

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

•

R o z p o c z ę c ie p r z e t w a r z a n ia f a k t u r y p o s tr o n ie T L S — w y s ła n ie d o k u m e n t u f a k t u r y d o T L S , g d z ie r o z p o c z n ie się o d r ę b n y p ro c e s je j p r z e t w a r z a n ia .

W p r z y p a d k u t r z e c h o s ta t n ic h a k c ji u s łu g a p e łn ić m a r o lę w n io s k o d a w c y , in ic ju ją c e g o w y m ia n ę k o m u n ik a t ó w z in n y m i u s łu g a m i. A k c je te p o w in n y w ię c z o s ta ć z a im p le m e n to w a n e ja k o część w e w n ę t r z n e j lo g ik i u s łu g i. P ie rw s z a a k c ja — ro z p o c z ę c ie p r z e tw a r z a n ie f a k t u r y — in ic jo w a n a je s t p r z e z u s łu g ę Obser­ wowanie folderu , co o z n a c z a , że u s łu g a Przetwarzanie faktury p e łn i w t y m p r z y p a d k u r o lę d o s ta r c z y c ie la . A k c ja ta p o w in n a w ię c z o s ta ć o d z w ie r c ie d lo n a w r a m a c h in t e r fe js u u s łu g i. N a le ż y z a te m w y b r a ć s to s o w n ą n a z w ę d la n o w e j o p e r a c ji ( p a t r z r y s u n e k 1 5 .2 2 ).

Rysunek 15.22. Usługa Przetwarzanie faktury z nową operacją P o z id e n t y f ik o w a n iu o p e r a c ji i n a d a n iu je j n a z w y n a le ż y t e r a z z d e f in io w a ć s z c z e g ó ły z w ią z a n e j z n ią w y m i a n y d a n y c h . In f o r m a c j a o t r z y m a n a o d u s łu g i z a w ie r a n u m e r id e n t y f ik a c y jn y ( I D ) i lo k a liz a c ję d o k u m e n t u (u s łu g a

Obserwowanie folderu Obserwowanie folderu ,

z g o d n ie ze s w ą n a z w ą , n ie p r z e k a z u je n o w e g o d o k u m e n t u , a je d y n ie p o w ia d a m ia z a r e je s tr o ­ w a n e u s łu g i-s u b s k r y b e n tó w o fa k c ie je g o p o ja w ie n ia się w fo ld e r z e s ie c io w y m ). T e d w a e le ­ m e n t y — I D i lo k a liz a c ja d o k u m e n tu — z n a la z ły p ie rw s z e o d z w ie rc ie d le n ie w r a m a c h p o n iż s z e j k o n s tr u k c ji. Przykład 15 .15 . Konstrukcja complexType odzwierciedlająca dwa parametry informacji otrzymywanej od usługi Obserwowanie folderu < typ e s> < x sd:sch em a targ etN am esp ace= " h t t p : / / w w w . x m l t c . c o m / r a i l c o / i n v o i c e s e r v i c e / s c h e m a / "> < x s d :e le m e n t na m e = "S u b m itIn v o ice T yp e "> < x s d :c o m p le x T y p e > < x s d : e l e m e n t n a m e = " C o n te x tID " ty p e = "x s d :in te g e r"/> < x s d : e l e m e n t n a m e = " In v o ic e L o c a tio n " ty p e = " x s d :s trin g " /> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /xs d :s ch e m a > < /typ e s >

1 5 .4 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG Z A D A N IO W Y C H — KROK PO KROKU

477

K o le jn a k o n s tr u k c ja o d z w ie r c ie d la o p e ra c ję u s łu g i i o t r z y m y w a n y w je j r a m a c h k o m u n ik a t. Przykład 15 .16 . Pozostała część abstrakcyjnej definicji usługi Przetwarzanie faktury, reprezentująca operację z jednym komunikatem wejściowym < p a r t na m e = "R e q u e stP a ra m e te r" e le m e n t= "in v s :S u b m itIn v o ic e T y p e "/> < p o rtT y p e n a m e = "In v o ic e P ro c e s s in g In te rfa c e "> < o p e r a t i o n n a m e = " W y s t a w F a k t u r e " 19> < in p u t m e ss ag e="tns:receiveS ub m itInvoiceM essage" / > < /o p e ra tio n >

Z a u w a ż m y , ż e p o n ie w a ż w y m ia n a k o m u n ik a t u o d b y w a się w e d łu g je d n o k ie r u n k o w e g o

operation r e p r e z e n t u ją c a o p e r a c ję WystawFakture z a w ie r a ty lk o input i n ie z a w ie r a e le m e n t u output.

w z o r c a M E P , k o n s tr u k c ja je d e n e le m e n t

Krok 3.: zastosowanie zasad orientacji na usługi P o d o b n ie j a k w p r z y p a d k u p o p r z e d n ic h p r o c e s ó w p r o je k t o w a n ia , i t y m r a z e m , z a n im z a g łę b im y się w s z c z e g ó ły p r o je k t u u s łu g i

Przetwarzanie faktury , w a r to z a s ta n o w ić się n a d t y m , j a k m a ją się

d o b iz n e s o w y c h u s łu g z a d a n io w y c h c z te r y o m a w ia n e w r o z d z ia le 8. z a s a d y z o r ie n to w a n ia n a u s łu g i, n ie w s p ie ra n e a u to m a ty c z n ie p r z e z te c h n o lo g ie u s łu g s ie c io w y c h , c z y li w ie lo u ż y w a ln o ś ć , a u to n o m ia , b e z s ta n o w o ś ć i w y k ry w a ln o ś ć . O k a z je d o w ie lo k r o tn e g o w y k o r z y s t y w a n ia u s łu g z a d a n io w y c h są w y r a ź n ie r z a d s z e n iż u s łu g p o d m io t o w y c h i u s łu g a p lik a c y jn y c h . Jest t a k d la te g o , że u s łu g i z a d a n io w e p r z e ja w ia ją f u n k c jo ­ n a ln o ś ć z n a c z n ie m n ie j u n iw e r s a ln ą , b o o d z w ie r c ie d la ją c ą lo g ik ę p r z e p ły w u p r a c y s p e c y fic z n ą d la k o n k r e tn e g o p r o c e s u b iz n e s o w e g o . M i m o to , m o ż n a je p r o je k t o w a ć ja k o w ie lo u ż y w a ln e — w s k a ­ z ó w k i z a w a r te w p u n k t a c h 1 2 .2 .1 , „ R o z w a ż a n ie p o te n c ja ln e j w ie lo u ż y w a ln o ś c i m ię d z y p r o c e s o w e j e n k a p s u lo w a n e j lo g ik i” , i 1 2 .2 .2 , „ R o z w a ż a n ie p o te n c ja ln e j w ie lo u ż y w a ln o ś c i w e w n ą tr z p r o c e s o w e j e n k a p s u lo w a n e j lo g i k i” , p o z o s ta ją t u w p e łn i a k tu a ln e . P o n ie w a ż u s łu g a z a d a n io w a p r a w ie z a w s z e p e łn i r o lę k o n t r o le r a k o m p o z y c ji, je j a u t o n o m ia je s t g e n e r a ln ie z a le ż n a o d a u t o n o m ii u s łu g w c h o d z ą c y c h w s k ła d te j k o m p o z y c ji. U t r z y m a n i e s p ó jn e g o s ta n u a u t o n o m ii je s t w ię c w t y m p r z y p a d k u n ie la d a w y z w a n ie m . U s łu g a z a d a n io w a , ja k o k o n t r o le r k o m p o z y c ji, z a w ie r a lo g ik ę p r z e p ły w u p r a c y n a r z u c a ją c ą u z a le ż n ie n ia w z a k r e s ie p r z e t w a r z a n ia n a u s łu g i tw o r z ą c e tę k o m p o z y c ję . W ią ż e się to g e n e r a ln ie z u t r z y m y w a n ie m in f o r m a c j i o s ta n ie p r z e t w a r z a n ia , n ie m n ie j je d n a k z n a c z ą c ą część (lu b n a w e t c a ło ś ć ) te j in f o r m a c j i m o ż n a d e le g o w a ć d o k o m u n ik a t ó w S O A P w y m ie n ia n y c h m i ę d z y u s łu g a m i. W y k r y w a ln o ś ć z a w s z e je s t p o ż ą d a n ą z a le tą k a ż d e j u s łu g i, w p r z y p a d k u u s łu g i z a d a n io w e j n ie je s t je d n a k t a k is to tn a j a k w p r z y p a d k u in n y c h u s łu g , b a r d z ie j g e n e r y c z n y c h i w w ię k s z y m s to p n iu w ie lo u ż y w a ln y c h . J e d n a k n ie m a p r z e c iw w s k a z a ń , b y u s łu g a z a d a n io w a b y ła w id o c z n a d la in n y c h u s łu g i ła t w o w y k r y w a ln a . M o ż e b y ć w t y m p o m o c n e u d o k u m e n t o w a n ie u s łu g i z a p o m o c ą m e ta d a n y c h , o c z y m p is z e m y w p u n k c ie 1 5 .5 .1 0 .

19 W o r y g in a le S u b m i t I n v o i c e — przyp. tłum.

478

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

ANALIZA PRZYPADKU N i e m a s p e c ja ln e g o p o w o d u , b y u s łu g a

Przetwarzanie faktury m i a ła b y ć w ie lo u ż y w a ln a ,

p o d o b n ie je j a u to n o m ia i b e z s ta n o w o ś ć n ie są is to tn e z p u n k t u w id z e n ia a k tu a ln y c h p o tr z e b . W k w e s t ii w y k r y w a ln o ś c i p o s t a n o w io n o j e d n a k d o d a ć d o je j d e f i n ic j i p o r c ję m e t a d a n y c h , p o d o b n ie j a k u c z y n io n o to z w c z e ś n ie j z a p r o je k t o w a n ą u s łu g ą

Konwersja .

Przykład 15 .17 . Metadane dokumentujące usługę Przetwarzanie faktury < p o rtT y p e n a m e = "In v o ic e P ro c e s s in g In te rfa c e "> < docum entation > I n i c j u j e proce s w y s y ła n ia fa k tu r y . < / docum entation > < o p e r a t io n n a m e = "W y sta w F a k tu re "> < in p u t m e s s a g e = "tn s :re c e iv e S u b m itIn v o ic e M e s s a g e "/> < /o p e ra tio n >

Krok 4.: standaryzacja i udoskonalanie interfejsu usługi M i m o iż u s łu g i z a d a n io w e c e c h u ją się z w y k le w ię k s z ą k r e a ty w n o ś c ią p r o je k t a n t ó w p o d w z g lę d e m n a d a w a n ia n a z w p o s z c z e g ó ln y c h o p e r a c jo m , n ie u m n ie js z a to w n ic z y m z n a c z e n ia is tn ie ją c y c h k o n w e n c ji n a z e w n ic z y c h , k t ó r e i t y m r a z e m m u s z ą b y ć p r z e s tr z e g a n e . O t o k i lk a w s k a z ó w e k p o ­ m o c n y c h w z a c h o w a n iu s ta n d a r d o w e g o i e le g a n c k ie g o p r o je k t u in t e r fe js u u s łu g i. •

K o n ie c z n e je s t p r z e s tr z e g a n ie z d e f in io w a n y c h s ta n d a r d ó w i k o n w e n c ji p r o je k t o w y c h ( p o d k o n ie c te g o r o z d z ia łu p r z e d s ta w ia m y lis tę ta k ic h s u g e r o w a n y c h s ta n d a r d ó w ).

•

N a le ż y u p e w n ić się, że w p r o je k c ie in t e r fe js u o d z w ie r c ie d lo n e z o s ta ło w p e łn i z a ło ż o n e w s p a r c ie d la k o n k r e t n y c h c e c h w s p ó łc z e s n e j S O A .

•

Z a le c a n e je s t s k o n f r o n t o w a n ie p r o je k t u in t e r fe js u z r e g u ła m i W S -I Basic Profile i i n n y m i s p r a w d z o n y m i p r a k t y k a m i p r o je k t o w a n ia .

Jeśli zaś c h o d z i o s ta n d a r d y p r o je k to w e d o ty c z ą c e z ia r n is to ś c i (g r a n u la c ji) o p e r a c ji, to w c e lu z r e a liz o w a n ia w y m a g a n e j lo g ik i p r z e p ły w u p r a c y w b u d o w y w a n e j w u s łu g ę k o n ie c z n e je s t p e w n e o d s tę p s tw o o d t y c h s t a n d a r d ó w . P o n a d to w p r z y p a d k u u s łu g z a d a n io w y c h s z c z e g ó ln ie k o r z y s tn a o k a z u je się m o d u la r y z a c ja d e fin ic ji W S D L , z w ła s z c z a w ie lo k r o t n e w y k o r z y s ty w a n ie ty c h s a m y c h s c h e m a tó w X S D .

ANALIZA PRZYPADKU W R a ilC o je d n ą z n a jw a ż n ie js z y c h ce ch S O A , ja k a m a m ie ć o d z w ie r c ie d le n ie w p r o je k to w a n y c h u s łu g a c h , je s t ic h r o z s z e r z a ln o ś ć , b o p r o je k t a n c i n ie są p e w n i, w j a k im k ie r u n k u e w o lu o w a ć b ę d z ie z c z a s e m b u d o w a n a o b e c n ie S O A . A n a liz u ją c d o ty c h c z a s o w ą p o s ta ć p r o je k t u u s łu g i

Przetwarzanie faktury, o d k r y li je j p o d s ta w o w y m a n k a m e n t z p u n k t u w id z e n ia w s p o m n ia n e j ro z s z e r z a ln o ś c i; je s t n im p r z y s to s o w a n ie u s łu g i d o p o tr z e b p o je d y n c z e g o , k o n k r e tn e g o w n io ­ s k o d a w c y , ja k im je s t u s łu g a

Obserwowanie folderu . W d a ją c e j się p r z e w id z ie ć p rz y s z ło ś c i n ie

m o ż n a w y k lu c z y ć z m ia n , z k t ó r y m i te n d e d y k o w a n y z w ią z e k n ie d a się p o g o d z ić , n a p r z y k ła d :

1 5 .4 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG Z A D A N IO W Y C H — KROK PO KROKU

479

• wprowadzenia wymogu, by usługa Przetwarzanie faktury weryfikowała poprawność pobranego dokumentu i wstępnie go przetwarzała jako przygotowanie do właściwej konwersji na format XML, • wprowadzenia możliwości odbierania przez usługę Przetwarzanie faktury fizycznego dokumentu zamiast jedynie jego lokalizacji — co jest prawdopodobne w sytuacji wzbogacania środowiska RailCo o nowe usługi. Stosownie do tych przewidywań w RailCo poczyniono zmiany w zakresie konstrukcji ty p e s w definicji usługi. Ponieważ schemat XSD reprezentujący strukturę dokumentu faktury jest już zdefiniowany (bo utworzony został w związku z projektowaniem usługi Konwersja), po­ stanowiono włączyć go do definicji WSDL usługi Przetwarzanie faktury. Aby nie mnożyć w związku z tym redundantnych znaczników, postanowiono wyodrębnić ten schemat w po­ staci pliku F aktura.xsd i zaimportować plik za pomocą konstrukcji im p o r t . W związku z tym, że usługa Przetwarzanie faktury musi być teraz przygotowana nie tylko na komunikaty niosące informację o lokalizacji faktury, lecz także na komunikaty niosące fizyczne egzemplarze faktur, oryginalna konstrukcja c o m p le x T y p e została poszerzona o nowy element, odwołujący się do elementu In v o ic e D o c u m e n t , reprezentujący dokument-fakturę i zdefiniowany we wspomnianym pliku Faktura.xsd. Przykład 15 .18 . Zrewidowana konstrukcja types w definicji usługi Przetwarzanie faktury < typ e s> < x sd:sch em a targ etN am esp ace= " h t t p : // w w w .x m lt c . c o m / r a ilc o / in v o i c e s e rv ic e /s c h e m a /"> < x s d :im p o rt namespace=

"h ttp ://w w w .x m ltc .c o m /ra ilc o /in v o ic e /s c h e m a /" sc h em aL o c atio n = "F ak tu ra.x sd "/> < x s d :e le m e n t na m e = "S u b m itIn v o ice T yp e "> < x s d :c o m p le x T y p e > < x s d :e le m e n t n a m e = "C o n te x tID " ty p e = "x s d :in te g e r"/> < x s d :e le m e n t n a m e = "In v o ic e L o c a tio n " ty p e = " x s d :s trin g " />

< /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /xs d :s ch e m a > < /typ e s >

Jako że zmieniła się postać informacji akceptowalnej dla usługi Przetwarzanie faktury, konieczne jest odzwierciedlenie tego faktu w metadanych tej usługi. Przykład 15 .19 . Zmieniony element dokumentujący usługę Przetwarzanie faktury I n i c j u j e proces w y s y ła n ia fa k tu r y , do kum en tu f a k t u r y < /d o c u m e n ta tio n >

o c z e k u je na in f o r m a c ję o l o k a l i z a c j i

a lb o na f i z y c z n y e g z e m p la rz t e g o d o ku m e n tu .

480

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

Kolejna zmiana dotyczyła nazwy (jedynej operacji usługi): wychodząc z założenia, że związek z dokumentem faktury (invoice) znajduje już odzwierciedlenie w nazwie samej usługi, zdecydowano o skróceniu nazwy tej operacji do Wystaw 20 (patrz rysunek 15.23), by uniknąć redundantnego odzwierciedlania wspomnianego związku.

Rysunek 15.23. Zmieniona nazwa operacji

Oczywiście, to wymagało zmiany oryginalnych konstrukcji p o r tT y p e i m e s s a g e , tak jak poniżej. Przykład 15 .20 . Zrewidowane konstrukcje message i portType < m e s s a g e n a m e = " receiveSubm itM essage " > < p a r t na m e = "R e q u e stP a ra m e te r" e le m e n t= "in v s :S u b m itIn v o ic e T y p e "/> < p o rtT y p e n a m e = "In v o ic e P ro c e s s in g In te rfa c e "> < d o c u m e n ta tio n > I n i c j u j e p ro c e s w y s y ła n ia f a k t u r y , o c z e k u je na in f o r m a c ję o l o k a l i z a c j i d o ku m e n tu f a k t u r y a l b o na f i z y c z n y e g z e m p la r z t e g o d o k u m e n tu . < /d o c u m e n ta tio n > < o p e r a t i o n n a m e = " Wystaw " > < i n p u t m e s s a g e = " t n s : receiveSubm itM essage " / > < /o p e ra tio n >

Krok 5.: identyfikowanie innych niezbędnych usług Usługi zadaniowe w celu realizowania reprezentowanej logiki procesu biznesowego mogą organi­ zować kompozycje innych usług — aplikacyjnych, podmiotowych, a nawet zadaniowych. Pro­ jektując zatem interfejs usługi zadaniowej, musimy upewnić się, że warstwy, w których zlokali­ zowane są usługi uczestniczące we wspomnianych kompozycjach, pozwalają na realizowanie operacji tworzących rzeczony interfejs.

20 W o r y g in a le S u b m i t — przyp. tłum.

1 5 .4 . PRO JEK TO W A N IE B IZN ESO W YC H USŁUG Z A D A N IO W Y C H — KROK PO KROKU

481

Ponieważ jest to ostatni z trzech opisywanych procesów projektowych, należy zidentyfikować wszystkie wymagane do tego celu usługi aplikacyjne — zarówno te, które właśnie zaprojektowali­ śmy, jak i istniejące już wcześniej. Może się także okazać, że realizacja logiki projektowanej usługi zadaniowej wymaga zaprojektowania dodatkowych usług aplikacyjnych. ANALIZA PRZYPADKU Ponieważ w RailCo zaprojektowano już wymodelowane uprzednio usługi aplikacyjne, a analiza sporządzonych diagramów aktywności nie wykazała konieczności tworzenia nowych, istnie­ jący obecnie zestaw usług aplikacyjnych jest wystarczający do spełnienia wymagań ze strony usług zadaniowych i podmiotowych. Zmieniła się jednak logika usługi Przetwarzanie faktury. Uprzednio usługa ta otrzymywała lokalizację dokumentu faktury (w komunikacie wysłanym przez usługę Obserwacja folderu), pobierała oryginalny dokument z tej lokalizacji i następnie przekazywała go do usługi Konwer­ sja, która zarówno weryfikowała jego poprawność, jak i transformowała dokument na format XML. Obecnie sytuacja jest inna o tyle, że usługa Przetwarzanie faktury może odebrać fizyczny dokument faktury, ju ż zw eryfikowany i przetransform ow any na fo rm a t X M L , którego nie po­ winna przekazywać usłudze Konwersja. Opisana zmiana nie ma wpływu na inne usługi, wymaga jedynie nowego kroku przetwa­ rzania warunkowego do logiki enkapsulowanej przez usługę Przetwarzanie faktury.

ANALIZA PRZYPADKU (WYNIKI PROCESU) Oto finalna wersja definicji WSDL usługi Przetwarzanie faktury, uwzględniająca zmiany w nazewnictwie elementów i wszystkie poprzednie zmiany. Przykład 15 .21 . Finalna postać abstrakcyjnej części definicji usługi < d e f i n i t io n s n a m e = "P rz e tw a rz a n ie F a k tu ry " targ etN am esp ace= " h ttp ://w w w .x m ltc .c o m /ra ilc o /tra n s fo rm /w s d l/ " x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o r g /w s d l/" x m ln s :in v = "h ttp ://w w w .x m ltc .c o m /ra ilc o /in v o ic e /s c h e m a /" x m ln s :in v s = " h ttp ://w w w .x m ltc .c o m /r a ilc o /in v o i c e s e rv ic e /s c h e m a /" x m ln s :s o a p = "h ttp ://s c h e m a s .x m ls o a p .o r g /w s d l/ s o a p / " x m ln s :tn s = "h ttp ://w w w .x m ltc .c o m /ra ilc o /tra n s fo rm /w s d l/" x m ln s : x s d = " h ttp ://w w w .w 3 .o r g /2 0 0 1 /X M L S c h e m a "> < x sd:sch em a targ etN am esp ace= " h t t p : // w w w .x m lt c . c o m / r a ilc o / in v o i c e s e rv ic e /s c h e m a /"> < x s d : i m p o r t namespace= " h t t p : / / w w w . x m lt c . c o m / r a ilc o / in v o i ce /s ch e m a /" s c h e m a L o c a tio n = "F a k tu ra .x s d "/> < x s d :e le m e n t na m e = "S u b m itIn v o ice T yp e "> < x sd :co m p l exType> < xsd:seq uen ce> < x s d :e le m e n t n a m e = "C o n te x tID "

482

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

ty p e = "x s d :in te g e r"/> < x s d :e le m e n t n a m e = "In v o ic e L o c a tio n " ty p e = " x s d :s trin g " /> < x s d :e le m e n t n a m e = "In vo ice D o cu m e n t" ty p e = "in v :In v o ic e T y p e "/> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /xs d :s c h e m a > < /typ e s > < p a r t na m e = "R e q u e stP a ra m e te r" e le m e n t= "in v s :S u b m itIn v o i ce T yp e "/> < p o rtT yp e n a m e = "In v o ic e P ro c e s s in g In te rfa c e "> < d o c u m e n ta tio n > I n i c j u j e p ro c e s w y s y ła n ia f a k t u r y , o c z e k u je na in f o r m a c ję o l o k a l i z a c j i do kum en tu f a k t u r y a lb o na f i z y c z n y e g z e m p la rz t e g o do ku m e n tu . < /d o c u m e n ta tio n > < o p e r a t io n nam e="W ystaw "> < in p u t m e s s a g e = "tn s :re c e iv e S u b m itM e s s a g e "/> < /o p e ra tio n > < /p o rtT yp e > < /d e fin itio n s >

U w a ż n i c z y te ln ic y z a u w a ż y li z a p e w n e , że o tr z y m a n ie p r z e z u s łu g ę

Przetwarzanie faktury

lo k a liz a c ji d o k u m e n t u - f a k t u r y , a o t r z y m a n ie p r z e z n ią fiz y c z n e g o e g z e m p la r z a te g o d o k u ­ m e n t u to d w ie w y k lu c z a ją c e się m o ż liw o ś c i; ci, k t ó r z y z n a ją ję z y k X S D , z n a k o m ic ie w ie d z ą , iż ta k a s y tu a c ja k w a lif ik u je się d o r e p r e z e n t o w a n ia p r z e z k o n s tr u k c ję c h o ic e o b e jm u ją c ą e le ­ m e n t y In v o ic e L o c a t io n i In v o ic e D o c u m e n t. T o p r a w d a , je d n a k ż e z a a w a n s o w a n e e le m e n ty j ę ­ z y k a X S D — m ię d z y i n n y m i k o n s tr u k c je c h o ic e i u n io n — p o s ia d a ją o g r a n ic z o n e w s p a r c ie p r o d u c e n t ó w , g d y w y s tę p u ją w k o n te k ś c ie d e fin ic ji W S D L . Ic h u ż y w a n ie o b a r c z o n e je s t w ię c r y z y k ie m n ie k o m p a ty b iln o ś c i i w y m a g a u p e w n ie n ia się co d o s to p n ia w s p o m n ia n e g o w s p a rc ia n a k o n k r e t n e j p la t f o r m ie .

UWAGA Jak w idać, ograniczyliśmy się tylko do części abstrakcyjnej definicji. Całość pobrać można z serwera FTP w ydaw n ictw a Helion ftp ://ftp .h e lio n .p l/p rzy k la d y/so a k o n .z ip .

PODSUMOWANIE •

Podstaw ow ym w ym ogiem projektow ania biznesowej usługi zadaniow ej jest dokładne reprezentow anie logiki procesu biznesowego, realizacji którego w ym aga się od tej usługi.

•

W ieloużyw alność nie jest w przypadku usługi zadaniow ej kwestią najważniejszą, podobnie ja k analiza spekulatywna.

1 5 .5 . W YTYC ZN E DLA P R O JE K TO W A N IA USŁUG

483

1 5 .5 . W y ty c z n e d la p r o je k to w a n ia usług U w z g lę d n ie n ie z a s a d p r o je k t o w a n ia z o r ie n to w a n e g o n a u s łu g i w f o r m a ln y c h s ta n d a r d a c h d e fi­ n io w a n y c h p r z e z d a n ą f ir m ę m a z n a c z e n ie k r y t y c z n e d la p o w o d z e n ia w b u d o w a n iu S O A w te jż e f ir m i e . P o n iż e j p r z e d s t a w ia m y k i lk a w y b r a n y c h w y ty c z n y c h , k tó r e m o g ą s ta n o w ić p u n k t w y jś c ia d o w y p r a c o w a n ia w ła s n y c h s t a n d a r d ó w te j k a te g o r ii.

1 5 .5 .1 .

Id e n t y f ik o w a n ie o g r a n ic z e ń te c h n ic z n y c h

N o to m a m y j u ż p r a w ie id e a ln y in t e r fe js u s łu g i — „ p r a w ie ” , b o b r a k u je m u je d n e g o is to tn e g o e le m e n tu . O t ó ż w p r z e c iw ie ń s tw ie d o u s łu g b iz n e s o w y c h , p r o je k t u ją c u s łu g i a p lik a c y jn e , m u s im y u w z g lę d n ić n is k o p o z io m o w e r e a lia te c h n ic z n e rz e c z y w is te g o ś w ia ta , w k t ó r y c h to r e a lia c h p r z y j­ d z ie t y m u s łu g o m f u n k c jo n o w a ć . T o je d n a z t a k ic h s y tu a c ji, k ie d y „ p r a w ie ” r o b i d u ż ą r ó ż n ic ę — r ó ż n ic ę m i ę d z y p r o je k t e m a d z ia ła ją c ą u s łu g ą . B y tę r ó ż n ic ę z n iw e lo w a ć , n a le ż y d o k ła d n ie p r z e a n a liz o w a ć i u d o k u m e n t o w a ć t e c h n ic z n e w y m o g i r e a liz a c ji k a ż d e j o p e r a c ji. D la d a n e j o p e r a c ji n a le ż y p r z e d e w s z y s tk im s p o r z ą d z ić lis tę r e ­ a liz o w a n y c h p r z e z n ią fiz y c z n y c h f u n k c ji, p o c z y m d la k a ż d e j z ty c h f u n k c ji o k re ś lić r e la c ję d o is tn ie ją c e g o ś r o d o w is k a te c h n ic z n e g o , w s z c z e g ó ln o ś c i: •

p u n k t y f iz y c z n y c h p o łą c z e ń ( s k o ja r z e ń ) z d a n ą f u n k c ją — w y k o r z y s ty w a n e k o m p o n e n t y , w y w o ły w a n e fu n k c je A P I , a k ty w o w a n e a d a p te r y i t y m p o d o b n e ,

•

o g r a n ic z e n ia z w ią z a n e z z a b e z p ie c z e n ia m i d o ty c z ą c y m i r e a liz o w a n e j f u n k c ji,

•

p r z e w id y w a n y czas r e a k c ji d la w y w o ły w a n e j f u n k c ji,

•

d o s tę p n o ś ć m e c h a n iz m ó w w y k o n u ją c y c h ż ą d a n ą fu n k c ję w s y s te m ie o p e r a c y jn y m lu b in n y c h e le m e n ta c h p la t f o r m y w y k o n a w c z e j.

P o r o z p o z n a n iu c h a r a k te r y s ty k i k a ż d e j z f u n k c ji p r z e t w a r z a n ia n a le ż y s p o jr z e ć k o le k ty w n ie n a w s z y s tk ie fu n k c je d a n e j o p e r a c ji, a b y ć m o ż e ta k ż e n a z b io r y k o m p le t n y c h o p e r a c ji. Z n a ją c n a p r z y k ła d czas r e a k c ji s y s te m u d la p o s z c z e g ó ln y c h f u n k c ji d a n e j o p e r a c ji, m o ż n a p o d ją ć p r ó b ę o s z a c o w a n ia g e n e r a ln e g o o p ó ź n ie n ia o d p o w ie d z i d la te j o p e r a c ji ja k o c a ło ś c i. W t e n s p o s ó b u z y ­ s k a ć m o ż e m y a d e k w a tn y o b r a z w y m o g ó w i o g r a n ic z e ń n a r z u c a n y c h n a in te r fe js u s łu g i a p lik a c y j­ n e j p r z e z ś r o d o w is k o t e c h n ic z n e . M o ż e się w ó w c z a s o k a z a ć , iż są o n e n a ty le p o w a ż n e , iż n ie k tó r e o p e r a c je p r o je k t o w a n e j u s łu g i tr z e b a z n a c z ą c o z m o d y f ik o w a ć . N ie z a le ż n ie o d a n a liz y p o s z c z e g ó ln y c h o p e r a c ji, k o n ie c z n e je s t u w z g lę d n ie n ie u w a r u n k o w a ń z w ią z a n y c h z u s łu g ą ja k o c a ło ś c ią , m ię d z y in n y m i: •

c z y n n ik ó w ś r o d o w is k o w y c h z w ią z a n y c h z k o n k r e t n ą lo k a liz a c ją , w k t ó r e j w d r o ż o n a z o s ta n ie u s łu g a ,

•

o g r a n ic z e ń te c h n ic z n y c h w y n ik a ją c y c h z lo g ik i a p lik a c ji (s z c z e g ó ln ie is to tn y c h w p r z y p a d k u „ s p a d k o w y c h ” s y s te m ó w ),

•

w y m a g a ń a d m in is tr a c y jn y c h z a is tn ia ły c h w e fe k c ie w d r o ż e n ia u s łu g i,

•

p o te n c ja ln y c h w y m a g a ń w y n ik a ją c y c h z S L A 21.

21 SLA (Service Level Agreem ent — uzgodnienie na poziom ie usługi) to akronim oznaczający um owę między usłu­ godawcą a usługobiorcą, dotyczącą utrzym ania i doskonalenia jakości usługi — przyp. tłum.

484

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

N a d a r z a się w t y m m ie js c u o k a z ja d o p e w n e j w a ż n e j d y g r e s ji. N ie k w e s t io n o w a n e z a le ty S O A i k u s z ą c e p e r s p e k t y w y s p r a w ia ją , ż e w p r z e d s ię b io r s tw a c h w c h o d z ą c y c h n a d r o g ę t r a n s fo r m a c ji k u S O A p o ja w ia się d u c h „ to ta ln e g o z o r ie n t o w a n ia n a u s łu g i” , c z y li te n d e n c ja d o o r g a n iz o w a n ia w s z e m i w o b e c c a łe j in f r a s t r u k t u r y I T w f o r m ę k o n g lo m e r a t u u s łu g . T y m c z a s e m n ie w s z y s tk o d a je się e fe k t y w n ie w tło c z y ć w r a m y u s łu g s ie c io w y c h ; w ie le tr a d y c y jn y c h , p r z e s ta r z a ły c h a p lik a ­ c ji s ta w ia p o d t y m w z g lę d e m o p ó r — ic h p r z e s ta r z a ła lo g ik a d a le k a je s t o d s ta n d a r d ó w , o k t ó r y c h p is z e m y o d p ie r w s z y c h r o z d z ia łó w te j k s ią ż k i. W a r t o s o b ie je d n o c z e ś n ie u ś w ia d o m ić , ż e c h o ć w k s ią ż c e o g r a n ic z a m y się d o im p le m e n t o w a n ia S O A w p o s ta c i u s łu g s ie c io w y c h , to k o n c e p c y jn ie S O A je s t n ie z a le ż n y m o d k o n k r e t n e j im p le m e n t a c ji m o d e le m a r c h it e k t o n ic z n y m , a o r ie n t a c ja n a u s łu g i — n ie z a le ż n y m o d k o n k r e t n e j im p le m e n t a c ji p a r a d y g m a te m p r o je k t o w y m . Z a t e m is t n ie ­ ją c e f o r m y lo g ik i a p lik a c y jn e j n ie d o s tę p n e w p o s ta c i u s łu g s ie c io w y c h w c ią ż m o g ą b y ć m o d e lo ­ w a n e ja k o u s łu g i. F a k t te n m a s z c z e g ó ln e z n a c z e n ie w p r z y p a d k u u s łu g a p lik a c y jn y c h , p o n ie w a ż e k s p o n o w a n ie n ie k t ó r y c h r o d z a jó w lo g ik i a p lik a c y jn e j w f o r m ie u s łu g s ie c io w y c h m o ż e n ie b y ć d o b r ą d e c y z ją . Z n a c z n ie le p s z y m p o m y s łe m m o ż e b y ć n a p r z y k ł a d n a ło ż e n ie fa s a d y 22 n a k o m p o ­ n e n ty w y w o d z ą c e się z r ó ż n y c h ź r ó d e ł. T a k a fa s a d a tw o r z y z u p e łn ie n o w y k o n te k s t p r z e tw a r z a n ia , r e p r e z e n to w a n y p r z e z z b ió r w ie lo u ż y w a ln y c h f u n k c ji, z n a k o m ic ie n a d a ją c y się d o m o d e lo w a n ia u s łu g i (lu b z b io r u u s łu g ), im p le m e n t o w a n e j ja k o u s łu g a s ie c io w a .

ANALIZA PRZYPADKU O c e n ia ją c w R a ilC o p o t e n c ja ln e o g r a n ic z e n ia te c h n ic z n e u s łu g i a p lik a c y jn e j

Konwersja , o d ­

k r y t o je j w ą s k ie g a r d ło : p r z e g lą d z e b r a n y c h m e t r y k z d a w a ł s ię s u g e r o w a ć , że g d y d łu g o ś ć d o k u m e n t u f a k t u r y lu b z a m ó w ie n ia p r z e k r a c z a 2 0 w ie r s z y , c zas k o n w e r s ji g w a łt o w n ie się w y d łu ż a . W t r a k c ie p r z e t w a r z a n ia d o k u m e n t u u s łu g a s ta je się n ie d o s tę p n a d la in n y c h w n i o ­ s k o d a w c ó w , w ię c p r z e t w a r z a n ie s e r ii d łu g ic h d o k u m e n t ó w m o ż e d r a s ty c z n ie z w ię k s z y ć czas o c z e k iw a n ia n a o d p o w ie d ź z e s t r o n y u s łu g i. T o o d k r y c ie z a d a ło w ię c k ł a m o r y g in a ln e m u z a ło ż e n iu , iż z a p e w n ie n ie b e z s ta n o w o ś c i u s łu g i je s t s p r a w ą o c z y w is tą . N a s z c z ę ś c ie je d n a k , t e m p o n a p ły w a ją c y c h d o p r z e t w a r z a n ia d o k u m e n t ó w je s t n a ty le u m ia r k o w a n e , iż p r o b le m z d łu g im c z a s e m ic h p r z e t w a r z a n ia n ie w p ły w a z n a c z ą c o n a e fe k ty w n o ś ć f u n k c jo n o w a n ia c a łe g o s y s te m u . N i e m a w ię c n a g lą c e j p o ­ tr z e b y p r z e p r o je k t o w a n ia u s łu g i.

1 5 .5 .2 .

S to s o w a n ie s t a n d a r d ó w n a z e w n ic z y c h

E t y k ie t o w a n ie u s łu g to o d p o w i e d n ik e t y k ie t o w a n ia in f r a s t r u k t u r y I T . Jest n ie z m ie r n ie is to t n e , b y in te r fe js y u s łu g b y ły s p ó jn e i s a m o d o k u m e n t u ją c e t a k d a le c e , j a k to ty lk o m o ż liw e . S ta n d a r d y n a z e w n ic z e n a le ż y w ię c z d e fin io w a ć i k o n s e k w e n tn ie ic h u ż y w a ć w o d n ie s ie n iu do : •

n a z w p u n k t ó w k o ń c o w y c h u s łu g ,

•

n a z w o p e r a c ji u s łu g ,

•

w a r to ś c i p r z e k a z y w a n y c h w r a m a c h k o m u n ik a t ó w .

22 P a tr z p r z y p is n a p o c z ą t k u r o z d z ia łu — przyp. tłum.

1 5 .5 . W YTYC ZN E DLA P R O JE K TO W A N IA USŁUG

485

P r z y ję te k o n w e n c je n a z e w n ic z e są in n e w r ó ż n y c h f ir m a c h . N ie k t ó r e w z o r u ją się n a k o n w e n ­ c ja c h t y p o w y c h d la o r g a n iz a c ji o b ie k to w e j, g d z ie o b ie k t y (u s łu g i) o p a t r u je się n a z w a m i r z e c z o w ­ n ik o w y m i, zaś m e to d y (o p e ra c je u s łu g ) — n a z w a m i c z a s o w n ik o w y m i; in n e o g r a n ic z a ją się w y łą c z ­ n ie d o n a z w c z a s o w n ik o w y c h . I c h o ć w ie lc e p o ż y te c z n y o k a z a łb y się ja k iś d o s k o n a ły , u n iw e r s a ln y s t a n d a r d d la w s z y s tk ic h o r g a n iz a c ji, to z d e f in i o w a n ie t a k ie g o w y d a je się r a c z e j n ie m o ż liw e . T a k c z y in a c z e j, s p r a w ą n a jw a ż n ie js z ą je s t k o n s e k w e n tn e s to s o w a n ie i p r z e s tr z e g a n ie p r z y ję te g o s ta n ­ d a r d u — ja k im k o lw ie k b y n ie b y ł — w o d n ie s ie n iu d o w s z y s tk ic h e le m e n tó w t w o r z o n e g o r o z w ią ­ z a n ia z o r ie n t o w a n e g o n a u s łu g i. O t o k i lk a w y b r a n y c h s u g e s tii d o ty c z ą c y c h w y b o r u r z e c z o n e g o s ta n d a r d u . •

W s to s u n k u d o k a n d y d a t u r n a u s łu g i o d u ż y m p o te n c ja le w ie lo u ż y w a ln o ś c i m ię d z y a p lik a c y jn e j n a le ż y u n ik a ć n a z w k o ja r z ą c y c h się w j a k ik o lw ie k s p o s ó b z p r o c e s a m i, d la k t ó r y c h u s łu g i te z o s ta ły o r y g in a ln ie z a p r o je k to w a n e . P r z y k ła d o w o

PobierzIdentyfikatorKartyCzasuPracyDoRozliczenia n a le ż y ra c z e j u ż y ć n a z w y PobierzIdentyfikatorKartyCzasuPracy (b o „ r o z lic z e n ie ” z a w a r te je s t ju ż w n a z w ie u s łu g i) c z y n a w e t PobierzIdentyfikator ( w s z a k u s łu g a d e d y k o w a n a je s t „ r o z lic z a n iu k a r t y

z a m ia s t

czas u p r a c y ”). •

U s łu g i a p lik a c y jn e p o w in n y b y ć n a z y w a n e z g o d n ie z k o n t e k s t e m p r z e tw a r z a n ia , w e d łu g k tó r e g o p o g r u p o w a n e z o s ta ły ic h o p e r a c je . M o ż n a w t y m c e lu u ż y w a ć f o r m t y p u „ c z y n n o ś ć + r z e c z o w n ik ” a lb o ty lk o f o r m r z e c z o w n ik o w y c h . P r z y k ła d y n a z w te g o t y p u to

PobieranieDanychKlienta , RaportowanieTransakcjiSprzedaży c z y ObliczanieStatystyki. •

N a z w y o p e r a c ji u s łu g i a p lik a c y jn e j p o w in n y c z y te ln ie k o m u n ik o w a ć ic h in d y w id u a ln ą fu n k c jo n a ln o ś ć . P r z y k ła d y w ła ś c iw y c h n a z w te j k a t e g o r ii to

WykonajRaport,

PrzeliczWalute i ZweryfikujDane . •

B iz n e s o w e u s łu g i p o d m io t o w e p o w in n y p o z o s ta w a ć r e p r e z e n ta ty w n e d la m o d e li p o d m io t ó w ( e n c ji) b iz n e s o w y c h , z k t ó r y c h z o s ta ły w y p r o w a d z o n e . D o t y c z y to ta k ż e k o n w e n c ji n a z e w n ic z y c h — n a z w y t y c h u s łu g p o w in n y o d z w ie r c ie d la ć te , k t ó r e o b o w ią z u j ą w e w s p o m n ia n y c h m o d e la c h . Z w y k l e w y k o r z y s t u je s ię w t y m c e lu w y łą c z n ie f o r m y r z e c z o w n ik o w e —

•

Faktura , Klient c z y Pracownik.

O p e r a c je b iz n e s o w e j u s łu g i p o d m io t o w e j p o w in n y m ie ć f o r m ę c z a s o w n ik o w ą , n ie p o w t a r z a ją c ą n a z w y o d n o ś n e g o p o d m io t u (b o ta p o w in n a z o s ta ć o d z w ie r c ie d lo n a w n a z w ie s a m e j u s łu g i). T a k w ię c n a p r z y k ła d u s łu g a p o d m io t o w a o n a z w ie n ie p o w in n a z a w ie r a ć o p e r a c ji o n a z w ie

1 5 .5 .3 .

Faktura

DodajFakture .

D o b ó r o d p o w i e d n i e j z i a r n i s t o ś ci i n t e r f e j s u

W p r e z e n t o w a n y c h d o ty c h c z a s a n a liz a c h p r z y p a d k ó w w id z ie liś m y p r z y k ła d y o r ó ż n y m s to p n iu z ia r n is to ś c i. T e n d e n c ja d o t w o r z e n ia in te r fe js ó w u s łu g s ie c io w y c h o z ia r n is to ś c i w ię k s z e j n iż s to ­ s o w a n a t y p o w o d o k o m p o n e n t ó w k o m u n ik u ją c y c h się z g o d n ie z R P C , to p r a k t y k a z a le c a n a p r z e z d o s ta w c ó w ja k o r e m e d iu m n a p r o b le m y w y d a jn o ś c io w e p r z e t w a r z a n ia d o k u m e n t ó w X M L . O c z y w iś c ie , w y d a jn o ś ć p r z e t w a r z a n ia to c z y n n ik k r y t y c z n y d la fu n k c jo n o w a n ia i e w o lu o w a ­ n ia r o z w ią z a ń z o r ie n t o w a n y c h n a u s łu g i, ale n ie c z y n n ik je d y n y . W ię k s z a z ia r n is to ś ć o p e r a c ji to m n ie js z e t e m p o w y m i a n y k o m u n ik a t ó w m i ę d z y u s łu g a m i ( c z y li m n ie js z e o b c ią ż e n ie d la m e c h a ­ n iz m ó w k o m u n ik a c y jn y c h ) , ale ta k ż e m n ie js z y p o t e n c ja ł ty c h u s łu g w z a k r e s ie w ie lo u ż y w a ln o ś c i.

486

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

Z g r u p o w a n ie w ie lu e le m e n t a r n y c h f u n k c ji w r a m y p o je d y n c z e j o p e r a c ji m o ż e b y ć n ie k o r z y s tn e z p u n k t u w id z e n ia u s łu g i-w n io s k o d a w c y , k t ó r a c h c ia ła b y u ż y ć ty lk o je d n e j z ty c h f u n k c ji. P o n a d to n ie k t ó r e r o d z a je g r u b o z ia r n is ty c h in t e r fe js ó w m o g ą s k u tk o w a ć b e z s e n s o w n y m p r z e t w a r z a n ie m n ie p o t r z e b n y c h d a n y c h — n ie p o t r z e b n y c h z p u n k t u w id z e n ia k o n k r e t n e j a k ty w n o ś c i, a le o fe r o ­ w a n y c h p r z e z u s łu g ę n a z a s a d z ie „ s p r z e d a ż y w ią z a n e j” . D e c y z je d o ty c z ą c e z ia r n is to ś c i in te r fe js u u s łu g i to k lu c z o w e s tr a te g ic z n e d e c y z je w y m a g a ją c e s z c z e g ó ln e j u w a g i. O t o k i lk a w y ty c z n y c h p o m a g a ją c y c h w d o k o n a n iu tr a fn e g o w y b o r u . •

T r z e b a w p e łn i p o z n a ć i z r o z u m ie ć o g r a n ic z e n ia ś r o d o w is k a d o c e lo w e g o o r a z r o z p o z n a ć in n e te c h n o lo g ie w s p o m a g a ją c e ( t a k ie j a k n p . k o d o w a n e b in a r n ie r o z s z e r z e n ia o p ra c o w a n e p rze z W 3 C ).

•

N a le ż y r o z w a ż y ć o p r a c o w a n ie d la te j s a m e j u s łu g i d w ó c h d e fin ic ji W S D L — g r u b o z ia rn is te j i d r o b n o z ia r n is te j, b ą d ź te ż w y p o s a ż y ć d a n ą u s łu g ę w d w a ro d z a je o p e r a c ji — g r u b o z ia rn is te i d r o b n o z ia r n is t e . M i m o iż ta k ie r o z w ią z a n ia b u r z ą n o r m a liz a c ję k o n t r a k t u u s łu g i, m o g ą b y ć le k a r s tw e m n a p r o b le m y z w y d a jn o ś c ią p r z e t w a r z a n ia , a p o n a d to s tw a r z a ją w ię k s z e m o ż liw o ś c i w s p ó łp r a c y d la p o te n c ja ln y c h u s łu g - w n io s k o d a w c ó w .

•

In t e r fe js y g r u b o z ia r n is te b a r d z ie j n a d a ją się d la u s łu g s ta n o w ią c y c h p u n k t y k o ń c o w e r o z w ią z a ń , in te r fe js y d r o b n o z ia r n is te są n a to m ia s t b a r d z ie j o d p o w ie d n ie d la u s łu g z a m k n ię t y c h w p r e d e f in io w a n y c h g r a n ic a c h . U ja w n ia to p e w n ą s p rz e c z n o ś ć m ię d z y d w ie m a p o d s ta w o w y m i z a s a d a m i z o r ie n t o w a n ia n a u s łu g i: g r u b o z ia r n is te in t e r fe js y z r e g u ły z a p e w n ia ją le p s z ą in t e r o p e r a c y jn o ś ć , p o d c z a s g d y d r o b n o z ia r n is t e s tw a r z a ją w ię c e j o k a z ji w z a k r e s ie w ie lo u ż y w a ln o ś c i. J e d n y m z ś r o d k ó w p o g o d z e n ia te j s p rz e c z n o ś c i są s p e c y fic z n e k o m p o z y c je , w r a m a c h k t ó r y c h d r o b n o z ia r n is t e u s łu g i s k ła d o w e p o d p o r z ą d k o w a n e są g r u b o z ia r n is t e m u k o n t r o le r o w i ( i o c z y w iś c ie , d o s tę p n e ta k ż e b e z p o ś r e d n io , z p o m in ię c ie m k o n t r o le r a ) .

J a k ie g o k o lw ie k p o d e jś c ia b y n ie w y b r a ć , m u s i o n o b y ć s p ó jn e i d a w a ć p r z e w id y w a ln e r e z u l­ ta ty , t a k b y b u d o w a n a S O A „ z m ie ś c iła s ię ” w t e c h n o lo g ic z n y c h o g r a n ic z e n ia c h w y d a jn o ś c i, a je d ­ n o c z e ś n ie p o z o s ta ła z e s ta n d a r y z o w a n a .

ANALIZA PRZYPADKU Z g o d n ie z z a s a d a m i p r z y ję t y m i w T L S , u s łu g i p r z e z n a c z o n e d o u ż y t k u p r z e z k l ie n t ó w z e ­ w n ę t r z n y c h o p a tr y w a n e są in te r fe js a m i k o n s e k w e n t n ie g r u b o z ia r n is ty m i: o p e r a c je t y c h u s łu g są t a k z a p r o je k to w a n e , że p rz e s ła n ie w s z y s tk ic h d a n y c h n ie z b ę d n y c h d la o k re ś lo n e j a k ty w n o ś c i o d b y w a się w je d n y m a k c ie , a e w e n tu a ln e d a ls z e in te r a k c je m a ją ra c ję b y tu t y lk o w t e d y , g d y są b e z w z g lę d n ie w y m a g a n e lu b w y n ik a ją z w e w n ę t r z n e j p o li t y k i b e z p ie c z e ń s tw a . U s łu g i w y k o r z y s ty w a n e w e w n ę t r z n ie p r z e z T L S c h a r a k te r y z u ją się m n ie js z ą z ia r n is to ś c ią , co c z y n i je b a r d z ie j u ż y w a ln y m i d la ( w e w n ę t r z n y c h ) w n io s k o d a w c ó w . Jest to je d n o c z e ś n ie z ia r n is t o ś ć n a t y le g r u b a , b y o b c ią ż e n ie ś r o d o w is k a z e s t r o n y t y c h u s łu g n ie p r z e k r a c z a ło g r a n ic a k c e p to w a ln o ś c i.

1 5 .5 . W YTYC ZN E DLA P R O JE K TO W A N IA USŁUG

1 5 .5 .4 .

487

P r o j e k t o w a n i e o p e r a c j i u s łu g j a k o n a t u r a l n i e r o z s z e r z a ln y c h

N ie z a le ż n ie o d te g o , j a k z n a k o m ic ie z a p r o je k to w a n e z o s ta n ą u s łu g i p r z y ic h p ie r w s z y m w d r o ż e ­ n iu , n ig d y n ie b ę d ą w p e łn i p r z y g o t o w a n e n a to , c o p r z y n ie ś ć m o ż e p r z y s z ło ś ć . M o d y f ik o w a n ie p e w n y c h t y p ó w p r o c e s ó w b iz n e s o w y c h w y m a g a z m ia n w d e fin ic ja c h p o d m io t ó w b iz n e s o w y c h , co z k o le i w y m a g a m o d y f ik o w a n ia o d n o ś n y c h u s łu g p o d m io t o w y c h . P o d c z a s g d y w z g lę d y w ie lo u ż y w a ln o ś c i i k o m p o n o w a ln o ś c i u s łu g i r o z w a ż a n e są n a e ta p ie p a r t y c jo n o w a n ia lo g ik i w r a m a c h p r o c e s u m o d e lo w a n ia , to r o z s z e r z a ln o ś ć je s t ju ż g łó w n ie k w e s tią fiz y c z n e g o p r o je k t u u s łu g i. Z a le ż n ie o d n a tu r y w s p o m n ia n y c h z m ia n , r o z s z e r z a ln o ś ć u s łu g i m o ż n a o s ią g n ą ć b e z ła m a n ia je j is tn ie ją c e g o in t e r fe js u . N a le ż y w t y m c e lu p r o je k t o w a ć o p e r a c je i k o m u n ik a t y te j u s łu g i, b y b y ły ja k n a jb a r d z ie j a g n o s ty c z n e p o d w z g lę d e m a k ty w n o ś c i, w ja k ic h u s łu g a ta m a u c z e s tn ic z y ć — u ła t w i to w p r z y s z ło ś c i p r z e t w a r z a n ie n ie s p e c y fic z n y c h w a r to ś c i i f u n k c ji, k tó r e w c ią ż p o z o ­ s ta w a ć b ę d ą w r e la c ji d o g łó w n e g o p r z e z n a c z e n ia w s p o m n ia n y c h o p e r a c ji i k o m u n ik a t ó w . D o ­ b r y m z w y c z a je m je s t p o n a d t o r o z w a ż e n ie m o ż liw o ś c i z a s p o k o je n ia n o w y c h p o tr z e b b iz n e s o w y c h p r z e z s k o m p o n o w a n ie in n y c h d o s tę p n y c h u s łu g (z u w z g lę d n ie n ie m r ó w n ie ż ty c h , k t ó r e m o ż n a z a k u p ić lu b w y d z ie r ż a w ić ) —

t e n z a b ie g m o ż n a p r z e p r o w a d z ić , n ie d o ty k a ją c n a w e t in te r fe js u

w s p o m n ia n e j u s łu g i. Z a u w a ż m y , ż e r o z s z e r z a n ie is tn ie ją c e g o in te r fe js u u s łu g i m a w p ły w n a s c h e m a ty X S D z w ią z a ­ n e z t y m in t e r fe js e m — n a le ż y p o p r o s tu o p r a c o w a ć n o w e w e r s je ty c h s c h e m a tó w , s to s o w n ie d o n o w e j p o s ta c i in te r fe js u . D o te g o je d n a k k o n ie c z n e je s t w s p a r c ie ze s tr o n y d o b r e g o s y s te m u k o n ­ t r o li w e r s ji.

ANALIZA PRZYPADKU Z w a ż y w s z y n a fa k t, że T L S je s t s to s u n k o w o d u ż ą f ir m ą , p o w s z e c h n a je s t w n ie j r e k r u t a c ja w e w n ę t r z n a i a w a n s e w r a m a c h b ie ż ą c e j s t r u k t u r y o r g a n iz a c y jn e j f i r m y — p r z e s u n ię c ia p o ­ z io m e ( z m i a n a d z ia łu p r z y z a c h o w a n iu te j s a m e j r a n g i s t a n o w is k a ) o r a z p io n o w e ( c z y li a w a n s w r a m a c h te g o s a m e g o d z ia łu ) . Z w ła s z c z a te n d r u g i s c e n a riu s z s ta je się c o ra z b a r d z ie j p o w s z e c h n y z a s p ra w ą m o t t a „ p r o m o t e f r o m w it h in ” p r o p a g o w a n e g o p r z e z w ie lu d y r e k to r ó w o d d z ia łó w . G d y z m ie n ia się s ta n o w is k o lu b w y n a g r o d z e n ie p r a c o w n ik a , o d p r a c o w n ik a te g o o c z e ­ k u je się, iż s a m o d z ie ln ie u a k t u a ln i d a n e s w e g o p r o f ilu z a p o ś r e d n ic tw e m s p e c ja ln e g o f o r m u ­ la r z a w lo k a ln y m in tr a n e c ie . P o n ie w a ż g e n e r a ln ie n ie e g z e k w u je się te g o o b o w ią z k u , p o le g a ­ ją c n a d o b r e j w o li p r a c o w n ik ó w , z w y c z a jn ie w ię k s z o ś ć z n ic h z a n ie d b u je tę c z y n n o ś ć , c zeg o e fe k t je s t o c z y w is ty — k o n s e k w e n t n ie z w ię k s z a ją c a się lic z b a n ie a k t u a ln y c h p r o f ili w b a z ie H R . B y p r z e c iw d z ia ła ć te j te n d e n c ji, p o s t a n o w io n o w T L S z m ie n ić Proces rozliczania karty czasu pracy, r o z s z e r z a ją c g o o k r o k w e r y f ik a c ji p r o f ilu : p o z a im p le m e n t o w a n iu b ę d z ie p r z y ­ p o m in a ł p r a c o w n ik o w i o z w e r y f ik o w a n iu p r o f ilu , p r z e d p r z y ję c ie m je g o k a r t y p r a c y . K a r t y p r a c y n a le ż ą c e d o p r a c o w n ik ó w o n ie a k t u a ln y c h p r o f ila c h b ę d ą p o p r o s tu o d r z u c a n e . O p is a n e r o z s z e rz e n ie s y s te m u z re a liz o w a n o b e z m o d y f ik o w a n ia u s łu g i F u n k c ję p o w ie r z o n o n o w o u tw o r z o n e j u s łu d z e a p lik a c y jn e j.

Karta czasu pracy.

488

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

1 5 .5 .5 . Id e n t y f ik o w a n ie z n a n y c h i p o te n c ja ln y c h u s łu g - w n io s k o d a w c ó w P r a w ie zaw sze u s łu g i b u d o w a n e są ja k o część k o n k r e tn e g o r o z w ią z a n ia , d e d y k o w a n e g o k o n k r e tn e m u p r o b le m o w i b iz n e s o w e m u . P ro je k tu je się je w ię c z m y ś lą o z re a liz o w a n iu k o n k r e tn y c h w y m a g a ń b iz n e ­ so w ych . O g ra n ic ze n ie p ro je k tu usłu g i d o je d y n ie bieżących, d o ra ź n y c h w y m a g a ń m o ż e p o w a ż n ie u m n ie j­ szyć je j p o te n c ja ł ja k o w ie lo u ż y w a ln e j, a d a p to w a ln e j i in te r o p e r a c y jn e j je d n o s tk i lo g ik i p r z e tw a r z a n ia . W a r t o w ię c w z b o g a c ić p r o je k t o w a n ie u s łu g i o a n a liz ę s p e k u la ty w n ą , c z y li p r ó b ę p r z e w id y w a n ia , w j a k i s p o s ó b u s łu g a ta m o g ła b y b y ć w y k o r z y s ty w a n a w z a k r e s ie w y k r a c z a ją c y m p o z a p o c z ą t k o ­ w o o k r e ś lo n e z a s to s o w a n ie . I n n y m i s ło w y , u ż y te c z n e i p r a k t y c z n e m o ż e b y ć z id e n t y f ik o w a n ie p o t e n c ja ln y c h p r z y s z ły c h u s łu g -w n io s k o d a w c ó w i p r z y p u s z c z a ln y c h w y m a g a ń z ic h s t r o n y p o d a d re s e m p r o je k t o w a n e j u s łu g i-d o s ta r c z y c ie la o r a z u w z g lę d n ie n ie ty c h ż e w y m a g a ń w je j p r o je k c ie . W r e z u lta c ie t a k ie j a n a liz y m o g ą p o ja w ić się d o d a tk o w e w y m a g a n ia f u n k c jo n a ln e , k t ó r e m o g ą b y ć a lb o n ie b y ć a k c e p to w a ln e w k o n te k ś c ie z a k r e s u i b u d ż e t u a k tu a ln e g o p r o je k t u (g e n e r a ln ie in n y c h c e c h je g o s p e c y fik i). Są je d n a k i d o b r e w ia d o m o ś c i: w t e n s p o s ó b m o ż n a p r z e c ie ż w y d a tn ie p o p r a w ić ja k o ś ć p r o je k t u , b e z d r a s ty c z n e g o in g e r o w a n ia w je g o d o ty c h c z a s o w e r e z u lt a t y — n a p r z y k ła d p r z y s to s o w a ć o d p o w ie d n io z ia r n is to ś ć in t e r fe js ó w p o s z c z e g ó ln y c h u s łu g .

1 5 .5 .6 . M o d u la r y z o w a n ie d o k u m e n tó w W S D L D e f in ic je W S D L m o g ą b y ć k o n s tr u o w a n e d y n a m ic z n ie p o d c z a s w y k o n y w a n ia a p lik a c ji z a p o m o ­ c ą in s t r u k c ji im p o r t p o w o d u ją c y c h w łą c z a n ie tr e ś c i r e z y d u ją c y c h w o d d z ie ln y c h p lik a c h . D a je to m o ż liw o ś ć m o d u la r n e g o t w o r z e n ia d e fin ic ji t y p ó w , o p e r a c ji i w ią z a ń , k t ó r e to d e fin ic je m o g ą b y ć n a s tę p n ie w s p ó łd z ie lo n e p r z e z w ie le d o k u m e n t ó w W S D L . D a je to t a k ż e m o ż liw o ś ć w y k o r z y s ty w a n ia is tn ie ją c y c h ju ż s c h e m a tó w X S D , t w o r z o n y c h w c z e ś n ie j w z w ią z k u z i n n y m i p r o je k t a m i. W w ie lu f ir m a c h p r a k t y k u je się d r o b n o z ia r n is te p a r t y ­ c jo n o w a n ie ta k ic h s c h e m a tó w p o p r z e z p r z e c h o w y w a n ie k a ż d e g o z t y p ó w z ło ż o n y c h (c o m p le x T y p e ) w o d d z ie ln y m p lik u . P o w s ta je w te n s p o s ó b r e p o z y t o r iu m s c h e m a tó w , z k t ó r y c h k o m p o n o ­ w a ć m o ż n a r o z m a it e d e fin ic je d o c e lo w e i k tó r e m o ż n a d o łą c z a ć — z a p o m o c ą in s t r u k c ji im p o r t — d o d e fin ic ji ty p e s w e w n ą t r z d e fin ic ji W S D L .

UW AGA Zgodnie z w ym ogam i W S-i B asic P rofile, przy projektow aniu modularnych definicji WSDL należy używać in­ strukcji im p o r t do im portow ania innych definicji WSDL lub schem atów XSD.

A N A LIZA PRZYPADKU W T L S r o z w a ż a n o m o ż liw o ś ć im p o r to w a n ia k o n s tr u k c ji b in d in g s , p o n ie w a ż m ia ła o n a b y ć w ie ­ lo k r o tn ie w y k o r z y s ty w a n a , a n a w e t g e n e r o w a n a d y n a m ic z n ie w tra k c ie w y k o n y w a n ia a p lik a c ji. Przykład 15 .22 . Element import wykorzystywany do dołączania konstrukcji bindings rezydującej w osobnym pliku < im p o rt nam espace="h t t p : / / . . . / c o m m o n / w s d l / " lo c a tio n = "h ttp ://.../c o m m o n /w s d l/b in d in g s .w s d l"/>

O s ta te c z n ie je d n a k p o s ta n o w io n o p o z o s ta w ić w s p o m n ia n ą k o n s tr u k c ję w p o s ta c i ja w n ie w budow anej w dokum ent W S D L .

1 5 .5 . W YTYC ZN E DLA P R O JE K TO W A N IA USŁUG

1 5 .5 .7 .

489

S ta ra n n e u ż y w a n ie p rz e s trz e n i n a z w

D e f in i c ja W S D L s ta n o w i k o le k c ję e le m e n t ó w p o c h o d z ą c y c h z r ó ż n y c h ź r ó d e ł. K a ż d a d e fin ic ja o d w o łu je się z a t e m d o w ie l u r ó ż n y c h p r z e s t r z e n i n a z w . N a jc z ę ś c ie j u ż y w a n y m i p r z e s t r z e n ia m i n a z w , z w ią z a n y m i z e le m e n t a m i t y p o w y m i d la r ó ż n y c h s p e c y fik a c ji, są:

• http://schem as.xm lsoap.org/wsdl/ • http://schem as.xm lsoap.org/wsdl/soap/ • http://w w w .w 3.org/2001/X M LSchem a/ • http://schem as.xm lsoap.org/w sdl/http/ • http://schem as.xm lsoap.org/w sdl/m im e/ • http://schem as.xm lsoap.org/soap/envelope/ P r z y d y n a m ic z n y m s k ła d a n iu d e fin ic ji W S D L z m o d u łó w d o c h o d z ą je s z c z e in n e p r z e s tr z e n ie n a z w , z w ią z a n e g łó w n ie z i m p o r t o w a n y m i d e fin ic ja m i s c h e m a tó w X S D . D e f in iu ją c w ła s n e e le ­ m e n t y , m o ż e m y p o n a d t o d e f in io w a ć w ła s n e p r z e s t r z e n ie n a z w , r e p r e z e n tu ją c e s p e c y fic z n e d la a p lik a c ji c z ę ś c i d o k u m e n t u W S D L . N i e są w ię c n ic z y m n ie z w y k ły m d o k u m e n t y W S D L o d w o łu ­ ją c e się d o d z ie s ię c iu p r z e s tr z e n i n a z w i z a w ie r a ją c e k w a lif ik a t o r y r e p r e z e n tu ją c e te p r z e s tr z e n ie . B y n ie s ta ło się to p r z y c z y n k ie m d o c h a o s u , k o n ie c z n e je s t s ta r a n n e z o r g a n iz o w a n ie p r z e s tr z e n i n a z w w y k o r z y s ty w a n y c h w d a n y m d o k u m e n c ie W S D L . S p e c y fik a c ja W S-I Basic Profile w y m a g a u ż y c ia a tr y b u tu

targetNamespace w c e lu p r z y p is a n ia

d o m y ś ln e j p r z e s t r z e n i n a z w d o k u m e n t o w i W S D L ja k o c a ło ś c i. Jeśli p o n a d t o w d e fin ic ję W S D L w b u d o w a n y je s t s c h e m a t X S D , je m u ta k ż e n a le ż y ja w n ie p r z y p is a ć p r z e s tr z e ń n a z w z a p o m o c ą a try b u tu

targetNamespace (n a w e t je ś li je s t to d o m y ś ln a p r z e s tr z e ń c a łe g o d o k u m e n t u ) .

A N A LIZA PRZYPADKU N ie k t ó r e z w y m i e n io n y c h w c z e ś n ie j p o p u la r n y c h p r z e s t r z e n i n a z w n ie są w y m a g a n e p r z e z u s łu g ę T L S

Pracownik , z o s ta ły w ię c p o m in ię t e n a liś c ie a t r y b u t ó w k o n s t r u k c ji d e fin itio n s . targetNamespace w z w ią z k u z d w o m a im p o r t o w a n y m i s c h e ­

D o d a n o n a t o m ia s t a t r y b u t m a ta m i.

Przykład 15 .23 . Deklaracje przestrzeni nazw w ramach elementu definitions w pliku TLS Pracownik.wsdl < d e fin itio n s

n a m e = "P ra c o w n ik "

targetNam espace = " h t t p : / / w w w . x m l t c . c o m / t l s / e m p l o y e e / w s d l / " xm lns = " h t t p : / / s c h e m a s . x m l s o a p . o r g / w s d l / " xm lns : a c t = " h t t p : / / w w w . x m l t c . c o m / t l s / e m p l o y e e / s c h e m a / a c c o u n t i n g / " xm lns : h r = " h t t p : / / w w w . x m l t c . c o m / t l s / e m p l o y e e / s c h e m a / h r / " xm lns : s o a p = " h t t p : / / s c h e m a s . x m l s o a p . o r g / w s d l / s o a p / " xm lns : t n s = " h t t p : / / w w w . x m l t c . c o m / t l s / e m p l o y e e / w s d l / " xm lns : x s d = " h t t p : / / w w w . w 3 . o r g / 2 0 0 1 / X M L S c h e m a " > < /d e fin itio n s >

490

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

1 5 .5 .8 .

W y k o r z y s t y w a n i e l i t e r a l n y c h k o m u n i k a t ó w w s t y lu d o k u m e n t o w y m

F o r m a t ła d u n k u u ż y te c z n e g o k o m u n ik a t u S O A P o r a z s y s te m t y p ó w d a n y c h w y k o r z y s t y w a n y p r z y p r z e t w a r z a n iu te g o k o m u n ik a t u o k re ś lo n e są p r z e z d w a p o n iż s z e a tr y b u ty : •

a t r y b u t s t y l e e le m e n t u s o a p : b in d in g ,

•

a t r y b u t u s e e le m e n t u s o a p :b o d y .

O b a w y m ie n io n e e le m e n ty r e z y d u ją w e w n ą t r z k o n s t r u k c ji b in d in g d o k u m e n t u W S D L . U s t a w ie n ia w y ż e j w y m i e n io n y c h a t r y b u t ó w są o ty le is to tn e , ż e d e t e r m in u ją s t r u k t u r a liz a c ję i r e p r e z e n ta c ję tr e ś c i k o m u n ik a t u S O A P . •

A t r y b u t o w i s t y l e m o ż n a p r z y p is a ć je d n ą z d w ó c h w a r to ś c i: " d o c u m e n t" a lb o " r p c " . P ie r w s z a z n ic h u m o ż li w i a o s a d z e n ie w c ie le k o m u n ik a t u k o m p le t n e g o d o k u m e n t u , d r u g a n a to m ia s t o d z w ie r c ie d la t r a d y c y jn ą k o m u n ik a c ję w s ty lu R P C , w r a m a c h k tó r e j w k o m u n ik a t a c h p r z e k a z y w a n e są g łó w n ie p o je d y n c z e p a r a m e tr y .

•

A t r y b u t use ta k ż e m o ż e p r z y jm o w a ć je d n ą z d w ó c h w a r to ś c i: " l i t e r a l " a lb o "e n c o d e d ". O r y g in a ln ie p r o t o k ó ł S O A P w y k o r z y s t y w a ł s p e c y fic z n y d la s ie b ie s y s te m t y p ó w d a n y c h d o k o d o w a n ia tre ś c i c ia ł s w y c h k o m u n ik a t ó w ; d o p ie r o p ó ź n ie j p o ja w iło się w s p a r c ie d la t y p ó w d a n y c h ję z y k a X S D . A b y w k o m u n ik a t a c h S O A P m o ż n a b y ło w y k o r z y s ty w a ć t y p y d a n y c h X S D , a t r y b u t use m u s i m ie ć w a r to ś ć " l i t e r a l " .

D w a a t r y b u t y , z k t ó r y c h k a ż d y m o ż e n ie z a le ż n ie p r z y jm o w a ć je d n ą z d w ó c h w a r to ś c i, d a ją w s u m ie c z te r y k o m b in a c je , o k r e ś la ją c e c z te r y r ó ż n e k o n f ig u r a c je o b s łu g iw a n e p r z e z S O A P : •

s t y le :R P C + u s e :e n c o d e d ,

•

s t y le :R P C + u s e : l i t e r a l ,

•

s ty le :d o c u m e n t + u s e :e n c o d e d ,

•

s ty le :d o c u m e n t + u s e : l i t e r a l .

P r e fe r o w a n ą p r z e z S O A je s t — o c z y w iś c ie — k o m b in a c ja s ty le :d o c u m e n t

+

u s e :lite r a l,

o z n a c z a ją c a m o d e l w y m i a n y k o m u n ik a t ó w w s ty lu d o k u m e n t o w y m , k lu c z o w y d la r e a liz a c ji w ie lu s p e c y fik a c ji W S - * . P o n a d t o , z g o d n ie z w y m a g a n ia m i W S -I B a s ic P ro file , a t r y b u t use m u s i z a w s z e m ie ć w a r to ś ć " l i t e r a l " .

A N A LIZA PRZYPADKU B u d u ją c s k o n k r e ty z o w a n ą część d e fin ic ji in te r fe js u u s łu g i

Pracownik, a r c h ite k c i T L S z d e c y d o ­

w a li o u ż y c iu k o m b in a c ji s t y l e : docum ent + u s e : l i t e r a l , co p o k a z a n o n a p o n iż s z y m p r z y k ła d z ie . Przykład 15 .24 . Konstrukcja binding dokumentu TLS Pracownik.wsdl < b in d in g nam e="E m ploye eB i n d in g " ty p e = " tn s :E m p lo y e e In te rfa c e " > < s o a p : b i n d i n g s t y l e = " document " tra n s p o rt= " h ttp ://s c h e m a s .x m ls o a p .o rg /s o a p /h ttp "/> < o p e r a tio n n a m e = "P o b ie rz T y g o d n io w y L im itG o d z in "> < s o a p :o p e ra tio n s o a p A c tio n = "h ttp ://w w w .x m ltc .c o m /s o a p a c tio n " />

1 5 .5 . W YTYC ZN E DLA P R O JE K TO W A N IA USŁUG

49 1

< in p u t> < /in p u t> < o u tp u t> < /o u tp u t> < /o p e ra tio n > < o p e ra tio n n a m e = " Z a k tu a liz u jH is to r ie " > < s o a p :o p e ra tio n so a p A c tio n = "h ttp ://w w w .x m ltc .c o m /s o a p a c tio n " /> < in p u t> < /in p u t> < o u tp u t> < /o u tp u t> < /o p e ra tio n > < /b in d in g >

1 5 .5 .9 .

K o n s e k w e n tn e z a c h o w y w a n ie z g o d n o ś c i z z a le c e n ia m i W S -I

Nawet jeśli zgodność z zaleceniami WS-I nie figuruje na liście doraźnych wymagań, warto stoso­ wać się do standardów i „najlepszych praktyk” artykułowanych w dokumencie W S -I Basic Profile . Są one solidne, sprawdzone, wszechstronnie przetestowane i dlatego stanowić mogą znakomity punkt wyjścia do definiowania własnych standardów projektowych.

UWAGA Inna publikacja autorstw a WS-I — nie om aw iam y jej w tej książce — to dokum ent B asic S ecu rity P rofile, po­ święcony w ykorzystyw aniu specyfikacji związanych z bezpieczeństw em , w zw iązku z interoperacyjnością. C zytelników zainteresowanych szczegółami tego dokumentu odsyłamy do strony w w w .w s -i.o rg .

1 5 .5 .1 0 .

D o k u m e n t o w a n i e u s łu g z a p o m o c ą m e t a d a n y c h

Jak już wyjaśnialiśmy w rozdziale 7., przy okazji omawiania specyfikacji WS-Policy i W S-M etadataExchange, platforma WS-* to także propagowanie jakości i głębi opisów usług. To zadziwiające, jak wiele implementacji SOA nie wykorzystuje możliwości środowiska technicznego w zakresie interpretowania opisów usług, bo opisy te niewiele (lub wcale) wykraczają poza definicje WSDL. Szczególnie ważnym rodzajem metadanych towarzyszących usłudze są związane z nią założe­ nia polityki. Mogą one wyrażać między innymi wymogi w zakresie bezpieczeństwa, preferencje w zakresie przetwarzania czy też cechy behawioralne usługi w roli dostarczyciela. To pozwala po­ tencjalnym wnioskodawcom lepiej ocenić daną usługę i lepiej przygotować się do interakcji z nią. Założenia te są formalnie implementowane jako zbiór specyfikacji WS-* opisywany w roz­ dziale 7. Niezależnie od tego, czy w danej organizacji specyfikacje te są rzeczywiście wykorzystywane, założenia polityki związane z usługą powinny być zawsze dokumentowane jako część jej projektu. Jest to nie tylko użyteczna informacja dla projektantów potencjalnych usług-wnioskodawców dla danej usługi-dostarczyciela, lecz także przygotowanie do sytuacji, gdy założenia polityki staną się obowiązkową i powszechną częścią architektury zorientowanej na usługi.

492

R O ZD ZIA Ł 1 5 . ■ PRO JEK TO W A N IE Z O R IE N T O W A N E N A USŁUGI (CZĘŚĆ III. PRO JEKTO W ANIE USŁUG)

N ie z a le ż n ie o d te g o , j a k u n ik a t o w y c h w ła ś c iw o ś c i n ie p r z e ja w ia ła b y d a n a u s łu g a , je j c h a r a k te ­ r y s ty k a o r a z o g r a n ic z e n ia i w y m o g i z w ią z a n e z je j w y k o r z y s t y w a n ie m m u s z ą b y ć u d o k u m e n t o ­ w a n e w s p o s ó b k o m u n ik a t y w n y d la w s z y s tk ic h p o te n c ja ln y c h u ż y t k o w n ik ó w . D o k u m e n t a c ję ta k ą m o ż n a u m ie ś c ić w d e fin ic ji W S D L , w y k o r z y s tu ją c e le m e n t d o c u m e n ta tio n , m o ż n a j ą ta k ż e o p u ­ b lik o w a ć w f o r m ie o d r ę b n e g o , ła t w o d o s tę p n e g o d o k u m e n tu ; g d y w y k o r z y s t y w a n e są n a r z ę d z ia d o m o d e lo w a n ia , in f o r m a c ję tę m o ż n a z in te g r o w a ć z d ia g r a m a m i m o d e lo w a n ia . T a k c z y in a c z e j s ta n o w ić b ę d z ie o n a z n a c z ą c e w s p a r c ie d la w ie lo u ż y w a ln o ś c i i w y k r y w a ln o ś c i u s łu g i.

UWAGA Kiedy projektujemy usługę w sposób zgodny z zaleceniami W S-I, można zw iązaną z tym klauzulę dołączyć do dokumentacji tej usługi, najlepiej wyszczególniając konkretne profile zgodności; niew ątpliw ie w płynie to po­ zytyw nie na jakość opisu w spom nianej usługi. Zainteresowanych czytelników ponownie odsyłamy do strony

w w w . w s-i. org.

PODSUMOWANIE •

Projektow anie usługi jest rów nież sztuką kompromisu między realizacją w ym agań artykułowanych przez kandydaturę na usługę a ograniczeniami narzucanymi przez możliwości realizacji usługi w rzeczywistym świecie.

•

Rozpoczynanie projektow ania usługi od sporządzenia jej definicji WSDL jest zalecanym podejściem, ułatwiającym tw orzenie wysokiej jakości usług dzięki zgodności ze standardam i projektow ania ich interfejsów.

UWAGA Czytelnikom zainteresow anym szczegółam i procesów projektow ania usług i relacjam i tych procesów do ogólnego cyklu życiow ego SOA polecam y lekturę strony w w w .so a m e th o d o lo g y.co m .

Rozdział 16

Projektowanie zorientowane na usługi (Część IV. Projektowanie procesu biznesowego) 1 6 .1 . P o d s ta w y ję z y k a W S - B P E L 1 6 .2 . O s p e c y fik a c ji W S - C o o r d in a t io n o g ó ln ie 1 6 .3 . P r o je k to w a n ie p r o c e s u b iz n e s o w e g o z o r ie n to w a n e g o n a u s łu g i — k ro k po k ro k u

4 9 4 ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

Warstwa orkiestracji usług spełnia w kontekście SOA wielce użyteczną rolę: uosabia logikę procesu biznesowego i tworzy kolejną warstwę abstrakcji, dzięki czemu podporządkowane (orkiestrowane) usługi stają się wolne od uzależnienia od tejże logiki, a w konsekwencji — od wielu ograniczeń projektowych. Dzięki bowiem wyabstrahowaniu logiki biznesowej: • usługi aplikacyjne i usługi biznesowe mogą być projektowane jako agnostyczne procesowo, a zatem wieloużywalne; • usługa procesowa przejmuje na siebie znaczącą część zarządzania informacją o stanie aktywności, a więc usługi podporządkowane mogą zachowywać pełną bezstanowość; • logika procesu biznesowego zostaje skupiona w jednym miejscu, nie jest rozproszona i wbudowana „po kawałku” w wiele różnych usług. Ten rozdział poświęcony jest projektowaniu warstwy orkiestracji — wykorzystując język W S-BPEL, zbudujemy przykładową definicję procesu biznesowego.

Analizy przypadków: W tym rozdziale przykładowe analizy przypadków dotyczyć będą śro­ dowiska TLS. Opiszemy krok po kroku budowanie w języku W S-BPEL definicji Procesu roz­ liczania karty czasu pracy — tego samego, dla którego w rozdziale 12. modelowaliśmy kandy­ datury na usługi, a w rozdziale 15. zajmowaliśmy się projektowaniem konkretnych usług.

1 6 .1 . P o d s ta w y ję z y k a W S -B P E L

Na początek niezbędna dawka wiedzy na temat tego, jak można w sposób formalny wyrażać ope­ racyjną charakterystykę procesu biznesowego. W tym rozdziale używamy do tego celu języka W S-BPEL, demonstrując opisywanie logiki procesu biznesowego jako część konkretnej definicji (patrz rysunek 16.1) możliwej do implementowania i realizowania przez silniki orkiestracyjne kompatybilne ze wspomnianym językiem.

J

—

m Rysunek 16.1. Ogólna postać struktury definicji procesu w języku WS-BPEL

1 6 .1 . P O D S TA W Y JĘZYKA W S-BPEL

495

M i m o iż d e fin io w a n ie p r o c e s ó w b iz n e s o w y c h o d b y w a się r a c z e j p r z y u ż y c iu s p e c ja liz o w a n y c h n a r z ę d z i m o d e lo w a n ia , n iż p r z e z s a m o d z ie ln e tw o r z e n ie „ o d z e r a ” k o d u o d n o ś n y c h d e fin ic ji, z n a ­ jo m o ś ć s k ła d n i i s e m a n ty k i te j d e fin ic ji o k a z u je się n ie z w y k le u ż y te c z n a , a c z ę s to n a w e t n ie z b ę d n a — z w ła s z c z a g d y p r z y c h o d z i d o „ w y g ła d z a n ia ” d e ta li a u to m a ty c z n ie w y g e n e r o w a n e g o k o d u .

UWAGA Czytelnicy znający język WS-BPEL mogą pominąć poniższy fragm ent i przejść od razu do podrozdziału 16.3, „Projektow anie procesu biznesowego zorientow anego na usługi — krok po kroku".

1 6 . 1 . 1 . K r ó tk a h is to r ia B P E L 4 W S i W S -B P E L P r z e d z a g łę b ie n ie m się w s z c z e g ó ły s k ła d n i ję z y k a WS-BPEL p o ś w ię ć m y c h w ilę u w a g i je g o g e n e z ie . W lip c u 2 0 0 2 r o k u p o ja w iła się s p e c y fik a c ja BPEL4W S 1.0 ja k o o w o c w s p ó ln e g o w y s iłk u f i r m I B M , M i c r o s o f t i B E A ; n a z w a s p e c y f ik a c ji to s k r ó t o d Business Process E xecution Language fo r W eb

Services — ję z y k r e a liz a c ji p r o c e s u b iz n e s o w e g o d la u s łu g s ie c io w y c h . P r o p o n o w a n a w t y m d o ­ k u m e n c ie p o s ta ć ję z y k a in s p ir o w a n a b y ła p o p r z e d n i m i n a r z ę d z ia m i te j k a t e g o r ii, m ię d z y i n n y m i IB M - o w s k ie g o WSFL ( W eb Services Flow Language — ję z y k p r z e p ły w u [ p r a c y w r a m a c h ] u s łu g s ie c io w y c h ) i X L A N G f i r m y M ic r o s o f t. D o łą c z e n ie d o k o le k t y w u n o w y c h p a r t n e r ó w — S A P i S ie b e l S y s te m s — z a o w o c o w a ło n ie ­ s p e łn a r o k p ó ź n ie j ( w m a ju 2 0 0 3 ) n o w ą w e r s ją s p e c y fik a c ji: BPEL4W S 1.1. W e r s ja ta z y s k a ła s o b ie u z n a n ie i w s p a r c ie w ie lu p r o d u c e n t ó w , co d o p r o w a d z iło d o p o ja w ie n ia się k i lk u k o m p a t y b iln y c h z n ią s iln ik ó w o r k ie s tr a c y jn y c h . S a m a zaś s p e c y fik a c ja , je s z c z e p r z e d o p u b lik o w a n ie m , s k ie r o w a ­ n a z o s ta ła d o k o m is ji te c h n ic z n e j O A S IS w c e lu w y p r o m o w a n ia je j d o r a n g i o fic ja ln e g o , o t w a r t e ­ g o s ta n d a r d u . 1 4 w r z e ś n ia 2 0 0 4 r o k u k o m it e t t e n z a g ło s o w a ł n a d z m ia n ą n a z w y s p e c y fik a c ji n a

WS-BPEL 2 .0 ; n o w a n a z w a m i a ła w y r a ż a ć ( p o p r z e z p r z e d r o s te k W S - ) z w ią z e k s p e c y fik a c ji z u s łu ­ g a m i s ie c io w y m i, zaś n o w y n u m e r w e r s ji (2 .0 ) o d z w ie r c ie d la ć m i a ł z n a c z ą c e z m ia n y i u s p r a w n ie n ia w p o r ó w n a n iu z w e r s ja m i p o p r z e d n im i. P e łn ą w e rs ję s p e c y fik a c ji, d a to w a n ą n a 9 m a ja 2 0 0 7 r o k u , z n a le ź ć m o g ą c z y te ln ic y p o d a d re s e m https://www.oasis-open.org/committees/download.php/23964/ . W o p is ie n ie k tó r y c h e le m e n tó w z a w a r liś m y k o m e n ta r z e d o ty c z ą c e r ó ż n ic s k ła d n io w y c h m ię d z y w e r s ja m i BPEL4W S i WS-BPEL i d la p r o s to ty n ie b ę d z ie m y ju ż c z y n ić d a ls z y c h r o z r ó ż n ie ń m ię d z y n im i, u ż y w a ją c k o n s e k w e n tn ie a k r o n im u WS-BPEL . T a k ż e d la z w ię z ło ś c i b ę d z ie m y p is a ć p o p r o s tu „ u s łu g a p r o c e s o w a W S-BPEL ” i „ p ro c e s W S-BPEL ” z a m ia s t „ u s łu g a p r o c e s o w a z g o d n a z e s p e c y ­ fik a c ją W S-BPEL ” c z y „ p ro c e s d e f in io w a n y z g o d n ie z e s p e c y fik a c ją W S-BPEL”.

1 6 .1 .2 . P r z y g o to w a n ia P r z e c h o d z ą c d o s z c z e g ó łó w s a m e g o ję z y k a W S-BPEL , m u s im y n a w s tę p ie u p r z e d z ić , ż e d la z r o ­ z u m ie n ia je g o o p is u k o n ie c z n a je s t z n a jo m o ś ć t a k ic h k o n c e p c ji j a k o r k ie s tr a c ja , k o o r d y n a c ja , tr a n s a k c ja n ie p o d z ie ln a i a k ty w n o ś ć b iz n e s o w a : o m a w ia liś m y je w r o z d z ia le 6. i ta m ż e o d s y ła m y c z y te ln ik ó w , k t ó r z y le k t u r y te g o r o z d z ia łu n ie m a ją je s z c z e z a s o b ą . Z a k ła d a m y p o n a d to , że c z y ­ t e ln ic y p r z e s tu d io w a li k r ó t k i t u t o r ia l d o ty c z ą c y W S D L w r o z d z ia le 13.

4 9 6 ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

1 6 .1 .3 . E le m e n t p ro c e s s T o k o r z e ń d e f in ic ji p r o c e s u W S -B P E L . P r z y p is u je o n n a z w ę p r o c e s o w i ( p o p r z e z a t r y b u t name) i k o ja r z y z n i m o d p o w ie d n ie p r z e s t r z e n ie n a z w . Przykład 16 .1. Szkielet definicji process < process n a m e = " P r o c e s R o z l i c z a n i a K a r t y C z a s u P r a c y 1" ta rg etN am esp ace= "h t t p : // w w w .x m lt c . c o m / tls / p r o c e s s / " x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o rg /w s /2 0 0 3 /0 3 /b u s in e s s - p ro c e s s /" x m ln s :b p l= "h ttp : //w w w .x m lt c . c o m / tls / p r o c e s s / " x m ln s:e m p = "h t t p : // w w w .x m lt c . c o m / tls / e m p lo y e e / " x m ln s :in v = "h ttp ://w w w .x m ltc .c o m /tls /in v o ic e /" x m ln s :ts t= " h ttp ://w w w .x m ltc .c o m /tls /tim e s h e e t/" x m l n s : n o t = " h t t p : / / w w w . x m l t c . c o m / t l s / n o t i f i c a t i o n / "> < p a rtn e rL in k s > < /p a rtn e rL in k s > < v a ria b le s > < /v a ria b le s > < / process >

W k o n s tr u k c ji p ro c e s s z a g n ie ż d ż o n a je s t s e ria k o m p o n e n t ó w p o to m n y c h , o p is y w a n y c h w k o ­ le jn y c h p u n k ta c h .

1 6 .1 . 4 . E le m e n ty p a r tn e r L in k s i p a r t n e r L in k E le m e n t p a r t n e r L in k d e fin iu je ty p p o r t u u s łu g i ( p a r t n e r a ) u c z e s tn ic z ą c e j w r e a liz o w a n iu p r o c e s u b iz n e s o w e g o . U s łu g i p a r t n e r s k ie m o g ą f u n k c jo n o w a ć ja k o k l ie n t y p r o c e s u , o d p o w ie d z ia ln e z a w y w o ły w a n ie u s łu g i p r o c e s o w e j; s a m e te ż m o g ą b y ć w y w o ły w a n e p r z e z u s łu g ę p r o c e s o w ą . T r e ś ć (z a w a r to ś ć ) e le m e n t u p a r t n e r L in k r e p r e z e n t u je k o m u n ik a c ję m ię d z y d w o m a p a r t n e ­ r a m i — u s łu g ą p r o c e s o w ą i je d n ą z u s łu g u c z e s tn ic z ą c y c h . Z a le ż n ie o d n a t u r y te j k o m u n ik a c ji, r o la u s łu g i p r o c e s o w e j m o ż e b y ć r ó ż n a . P r z y k ła d o w o u s łu g a p r o c e s o w a w y w o ły w a n a p r z e z z e ­ w n ę t r z n ą u s łu g ę m o ż e o d g r y w a ć r o lę P ro c e s R o z l ic z a n ia K a r t y C z a s u P r a c y , g d y je d n a k ta s a m a u s łu g a p ro c e s o w a w y w o łu je z e w n ę tr z n ą u s łu g ę w c e lu z w e r y fik o w a n ia p o p r a w n o ś c i fa k tu r y , je j ro lę m o ż n a o k r e ś lić ja k o ( p o w ie d z m y ) I n v o i c e C l i e n t . E le m e n t p a r t n e r L i n k p o s ia d a w ię c a t r y b u t y m y R o le i p a r t n e r R o le , u s ta n a w ia ją c e r o lę ( o d p o w ie d n io ) u s łu g i p r o c e s o w e j i u s łu g i p a r tn e r s k ie j. In a c z e j m ó w ią c , a tr y b u t m yRole m a z n a c z e n ie , g d y u s łu g a p ro c e s o w a w y w o ły w a n a je s t p rz e z p a r t ­ n e rs k ą u s łu g ę k lie n c k ą , p o n ie w a ż w tej s y tu a c ji u s łu g a p ro c e s o w a fu n k c jo n u je ja k o u s łu g a -d o s ta rc zy c ie l. A t r y b u t p a r t n e r R o le id e n t y fik u je n a to m ia s t u s łu g ę p a rtn e r s k ą , k t ó r ą w y w o ły w a ć b ę d z ie u s łu g a p r o ­ c e s o w a (w ó w c z a s u s łu g a p a rtn e r s k a je s t u s łu g ą -d o s ta r c z y c ie le m ).

1 W o r y g in a le T im e s h e e tS u b m is s io n P r o c e s s — przyp. tłum.

1 6 .1 . P O D S TA W Y JĘZYKA W S-BPEL

497

Z a u w a ż m y , że o b a a tr y b u t y — m yR ole i p a r t n e r R o le — m o g ą w y s tą p ić w t y m s a m y m e le m e n c ie , je ż e li u s łu g a p r o c e s o w a m o ż e p e łn ić r o lę z a r ó w n o d o s ta r c z y c ie la , j a k i w n io s k o d a w c y w s to s u n k u d o tej s a m e j u s łu g i p a rtn e rs k ie j. P r z y k ła d o w o w r a m a c h a s y n c h ro n ic z n e j k o m u n ik a c ji m ię d z y u s łu g ą p ro c e s o w ą a u s łu g ą p a r tn e r s k ą w a r to ś ć a tr y b u tu myRol e w s k a z u je n a r o lę u s łu g i p ro c e s o w e j w czasie z w r o tn e g o o d w o ła n ia d o u s łu g i p a rtn e r s k ie j. Przykład 16.2. Konstrukcja partnerLinks zawierająca jeden element partnerLink reprezentujący wywołanie usługi procesowej przez zewnętrzną usługę partnerską oraz cztery elementy partnerLink reprezentujące wywoływanie usług partnerskich przez ustugę procesową < p a rtn e rL in k s > < p a rtn e r L in k n a m e = " c l i e n t " p a rtn e rL in k T y p e = "tn s :T im e s h e e tS u b m is s io n T y p e " m y R o le = "T im e s h e e tS u b m is s io n S e rv ic e P ro v id e r"/> < p a rtn e r L in k n a m e = " F a k t u r a " p a rtn e rL in k T y p e = "in v :In v o ic e T y p e " p a rtn e r R o le = "In v o ic e S e r v ic e P r o v id e r"/> < p a rtn e r L in k n a m e = " K a r t a C z a s u P r a c y " p a rtn e rL in k T y p e = "ts t:T im e s h e e tT y p e " p a rtn e rR o le = "T im e s h e e tS e rv ic e P ro v id e r"/> < p a rtn e r L in k n a m e = " P r a c o w n i k " p a rtn e rL in k T y p e = "e m p :E m p lo y e e T y p e " p a rtn e rR o le = "E m p lo y e e S e rv ic e P ro v id e r"/> < p a rtn e r L in k n a m e = " P o w i a d a m i a n i e " p a rtn e rL in k T y p e = "n o t:N o tific a tio n T y p e " p a rtn e rR o le = " N o tifi c a tio n S e rv ic e P ro v id e r"/> < / p a rtn e rL in k s >

W p o w y ż s z y m p r z y k ła d z ie k a ż d a z k o n s t r u k c ji p a r t n e r L in k p o s ia d a a t r y b u t p a r tn e r L in k T y p e . A t r y b u t te n s ta n o w i o d w o ła n ie d o k o n s tr u k c ji p a r tn e r L in k T y p e o p is y w a n e j w n a s tę p n y m p u n k c ie .

1 6 .1 .5 .

E le m e n t p a r t n e r L in k T y p e

D l a k a ż d e j u s łu g i p a r t n e r s k ie j z a d e k la r o w a n e j w c h a r a k te r z e u c z e s tn ic z k i p r o c e s u e le m e n t y p a r t ­ n e r L in k T y p e o d w o łu ją się d o e le m e n tu p o r tT y p e w s k a z y w a n e g o p r z e z e le m e n t p a r t n e r L in k w d e ­ f i n i c j i p r o c e s u . E le m e n t y p a r t n e r L in k T y p e są z w y k le w b u d o w y w a n e w d e f in ic ję W S D L d a n e j u s łu g i (d o t y c z y to ta k ż e u s łu g i p r o c e s o w e j). K o n s tr u k c ja p a r tn e r L in k T y p e z a w ie r a e le m e n t r o l e d la k a ż d e j r o li, ja k ą o d g r y w a ć m o ż e u s łu g a , z g o d n ie z d e fin ic ja m i a tr y b u tó w m yRole i p a r tn e r R o le . In a c z e j m ó w ią c , k o n s tr u k c ja p a r tn e r L in k T y p e z a w ie r a je d e n lu b d w a p o to m n e e le m e n ty r o le . Przykład 16 .3. Konstrukcja definitions definicji WSDL zawierająca konstrukcję partnerLinkType < d e f in it io n s n a m e = " P r a c o w n i k " ta rg e tN a m e s p a c e = "h t t p : // w w w .x m lt c . c o m / tls / e m p lo y e e / w s d l/ " x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o r g /w s d l/"

xm lns:p lnk= "h t tp : //s c h e m a s .x m ls o a p .o r g /w s /2 0 0 3 /0 5 /p a r tn e r -lin k /" > < p l n k : p a rtn e rL in k T y p e n a m e = " E m p l o y e e S e r v i c e T y p e " x m l n s = " h ttp ://s c h e m a s .x m ls o a p .o rg /w s /2 0 0 3 /0 5 /p a rtn e r-lin k " /> < p ln k : r o l e n a m e = "E m p lo ye e S e rvice P ro vid e r">

4 9 8 ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

< p o rtT y p e n a m e = "e m p :E m p lo y e e In te rfa c e "/> < / p l n k : r o l e> < / p l n k : p a rtn e rL in k T y p e > < / d e f i n it io n s >

Zauważmy, że do tego samego elementu p a r t n e r L in k T y p e może odwoływać się wiele kon­ strukcji p a r t n e r L i n k . Jest to użyteczne w sytuacji, gdy usługa procesowa pozostaje w identycznej relacji z wieloma usługami partnerskimi — każda z nich odwołuje się wtedy do tego samego ele­ mentu p o r tT y p e usługi procesowej.

UWAGA W wersji 2 .0 specyfikacji WS-BPEL znajduje się propozycja, by zamiast elementu p o r tT y p e (jako potom nego konstrukcji r o l e ) używać rów now ażnego atrybutu p o r tT y p e konstrukcji r o le .

1 6 .1 .6 .

E le m e n t v a r ia b le s

Usługa procesowa WS-BPEL wykorzystuje zazwyczaj konstrukcję v a r i a b l e s na potrzeby prze­ chowywania informacji związanych z aktualnym stanem przetwarzania wynikającym z logiki przepływu pracy. W ten sposób można przechowywać i później wykorzystywać w procesie złożo­ ne nawet dane — kompletne komunikaty lub zbiory danych — sformatowane w postaci typów danych XSD. Typ danych przypisywanych elementowi v a r i a b l e musi zostać zdefiniowany przy użyciu jednego z trzech atrybutów m e s s a g e T y p e , e le m e n t albo t y p e . Atrybut m e ss ag e T yp e umożliwia przypisanie zmiennej całego komunikatu (zdefiniowanego w dokumencie WSDL); atrybut e le m e n t stanowi odwołanie do konstrukcji e le m e n t , natomiast atrybut ty p e reprezentuje typ prosty XSD ( s im p le T y p e ), na przykład s t r i n g lub i n t e g e r . Przykład 16.4. Konstrukcja variables hostująca kilka potomnych elementów variable wykorzystywanych w ramach Procesu rozliczania karty czasu pracy < v a r ia b le s > < v a r ia b le n a m e: C l i e n t S u b m i s s i o n " m essageType: b p l:re c e iv e S u b m itM e s s a g e "/> < v a r ia b le n a m e: E m p l o y e e H o u r s R e q u e s t " m essageType e m p :g e tW e e k ly H o u rs R e q u e s tM e s s a g e "/> < v a r ia b le n a m e: E m p l o y e e H o u r s R e s p o n s e " m essageType e m p :g e tW e e k ly H o u rs R e s p o n s e M e s s a g e "/> < v a r ia b le n a m e: E m p l o y e e H i s t o r y R e q u e s t " m essageType e m p :u p d a te H is to ry R e q u e s tM e s s a g e "/> < v a r ia b le n a m e: E m p l o y e e H i s t o r y R e s p o n s e " messageType

e m p :u p d a te H is to ry R e s p o n s e M e s s a g e "/>

< / v a r ia b le s >

Zwykle zmienna z definiowanym atrybutem m e ss ag e T yp e definiowana jest dla każdego ko­ munikatu (wejściowego i wyjściowego) związanego z procesem. Wartość tego atrybutu jest na­ zwą komunikatu w definicji WSDL usługi partnerskiej.

1 6 .1 . P O D S TA W Y JĘZYKA W S-BPEL

499

1 6 . 1 . 7 . F u n k c je g e t V a r i a b l e P r o p e r t y i g e t V a r i a b l e D a t a J ę z y k W S -B P E L o fe r u je w b u d o w a n e fu n k c je u m o ż liw ia ją c e p r z e t w a r z a n ie w ła ś c iw o ś c i z m ie n n y c h o r a z w a r to ś c i p r z e c h o w y w a n y c h w ty c h z m ie n n y c h w czas ie r e a liz o w a n ia p r o c e s u b iz n e s o w e g o .

getVariableProperty(nazwa zmiennej, nazwa właściwości) F u n k c ja ta u m o ż liw ia o d c z y ty w a n ie p o s z c z e g ó ln y c h w ła ś c iw o ś c i z m ie n n e j. P o d a ją c n a z w ę z m ie n n e j i n a z w ę w ła ś c iw o ś c i, o t r z y m u je m y w a r to ś ć te j w ła ś c iw o ś c i.

getVariableData(nazwa zmiennej, nazwa części, lokalizacja) P o n ie w a ż z m ie n n e w y k o r z y s t y w a n e są p o w s z e c h n ie d o p r z e c h o w y w a n ia i n f o r m a c j i o s ta n ie , f u n k c ja ta u m o ż liw ia p o s z c z e g ó ln y m c z ę ś c io m p r o c e s u d o s tę p d o te j in f o r m a c ji. F u n k c ja p o s ia d a t r z y p a r a m e t r y w y w o ła n ia , z k t ó r y c h p ie r w s z y , r e p r e z e n tu ją c y n a z w ę z m ie n n e j, je s t o b o w ią z k o ­ w y ; p o z o s ta łe są o p c jo n a ln e . W p r e z e n t o w a n y c h p r z y k ła d a c h c zę s to w y k o r z y s ty w a ć b ę d z ie m y fu n k c ję g e t V a r ia b le D a t a d o o d c z y ty w a n ia d a n y c h k o m u n ik a t ó w p r z e c h o w y w a n y c h w z m ie n n y c h . Przykład 16 .5. Dwa wywołania funkcji getVariableData w celu odczytania wartości dwóch zmiennych g e tV a ria b le D a ta ( ' I n v o i c e H o u r s R e s p o n s e ' , ' R e s p o n s e P a r a m e t e r ' ) g e tV a ria b le D a ta ( ' i n p u t ' , ' p a y l o a d ' , ' / t n s : T i m e s h e e t T y p e / H o u r s / . . . ' )

1 6 .1 .8 . E le m e n t s e q u e n c e K o n s t r u k c ja s e q u e n c e u m o ż liw ia n a r z u c e n ie n a g r u p ę a k ty w n o ś c i o k re ś lo n e j k o le jn o ś c i ic h w y ­ k o n y w a n ia . J ę z y k W S -B P E L d o s ta r c z a s z e re g a k ty w n o ś c i u m o ż liw ia ją c y c h w y r a ż a n ie lo g ik i p r z e ­ p ły w u p r a c y w r a m a c h d e fin ic ji p ro c e s u . P o z o s ta łe p u n k t y 1 6 .1 .x p o ś w ię c o n e są o p is o w i f u n d a ­ m e n t a ln y c h a k ty w n o ś c i, w y k o r z y s ty w a n y c h w p ó ź n ie js z y c h a n a liz a c h p r z y p a d k ó w . Przykład 16 .6 . Szkielet konstrukcji sequence zawierającej tylko niewielki podzbiór elem entów aktywności definiowanych przez WS-BPEL < sequence > < re c e iv e > < / r e c e i ve> < a ssig n > < /a s s ig n > < in v o ke > < /in v o k e > < re p ly > < /re p ly > < / sequence >

500

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

K o n s tr u k c je s e q u e n c e m o g ą b y ć z a g n ie ż d ż a n e — m o ż liw e je s t d e fin io w a n ie s e k w e n c ji s ta n o ­ w ią c y c h e le m e n ty s e k w e n c ji w y ż s z e g o r z ę d u .

1 6 .1 .9 .

E le m e n t in v o k e

E le m e n t in v o k e id e n t y f ik u je o p e ra c ję u s łu g i p a r t n e r s k ie j, k t ó r ą u s łu g a p r o c e s o w a w y w o ły w a ć m a w z w ią z k u z r e a liz a c ją p ro c e s u . E le m e n t te n p o s ia d a p ię ć p o d s ta w o w y c h a tr y b u tó w , s p e c y fik u ją c y c h s z c z e g ó ły te g o w y w o ła n ia . O p is u je m y je w ta b e li 1 6 .1 .

Tabela 16.1. Atrybuty elementu invoke Atrybut

Znaczenie

p a rtn e rL in k

O kreśla nazw ę usługi p artnerskiej p o p rz ez odpow iadający jej elem ent p a r t n e r L i n k .

po rtT ype

W skazuje elem en t p o r t T y p e usługi p artnerskiej.

o p e ra tio n

W skazuje operację usługi partn ersk iej, do której usługa p rocesow a p o w in n a w ysłać żądanie.

in p u tV a ria b le

R eprezentuje k o m u n ik a t w ejściow y w ykorzystyw any w k o m u n ik a c ji z operacją usługi partnerskiej. Z auw ażm y, że jest to reprezentacja p o śre d n ia, czyli odw ołanie do zm iennej (e le m e n tu v a r i a b l e ) ze zdefiniow anym atry b u tem m e s s a g e T y p e .

o u tp u tV a ria b le

A try b u t ten jest używ any w tedy, gdy k o m u n ik acja z u sługą p a rtn e rsk ą odbyw a się w edług w zorca M EP „żądanie-odpow iedź”; w skazuje on z m ie n n ą rep rezentującą kom un ik at-o d p o w ied ź.

Przykład 16.7. Element invoke identyfikujący szczegóły odwołania do docelowej usługi partnerskiej 2 < invoke n a m e = " K o n f r o n t u j Z T y g o d n i o w y m L i m i t e m G o d z i n " p a rtn e rL in k = "P ra c o w n ik " p o rtT y p e = "e m p :E m p lo y e e In te rfa c e " o p e r a ti o n = "P o b ie rz T y g o d n io w y L im itG o d z in 3" i n p u t V a r i a b l e = "E m p lo y e e H o u rs R e q u e s t" o u tp u tV a ria b le = "E m p lo y e e H o u rs R e s p o n s e "/>

1 6 .1 .1 0 .

E l e m e n t r e c e iv e

E le m e n t r e c e iv e p o z w a la n a z d e f in io w a n ie in f o r m a c ji, k tó r e j u s łu g a p r o c e s o w a o c z e k u je w ż ą d a ­ n iu n a d e s ła n y m p r z e z z e w n ę tr z n ą u s łu g ę p a r tn e r s k ą . W t y m k o n te k ś c ie u s łu g a p r o c e s o w a p e łn i r o lę u s łu g i-d o s ta r c z y c ie la o c z e k u ją c e j n a w y w o ła n ie . E le m e n t r e c e iv e p o s ia d a s z e re g a tr y b u t ó w , o k re ś la ją c y c h p o s z c z e g ó ln e a s p e k ty k o m u n ik a c ji u s łu g i p r o c e s o w e j z u s łu g ą p a r tn e r s k ą . O p is u je m y je w ta b e li 1 6 .2 . E le m e n t r e c e iv e m o ż e b y ć ta k ż e w y k o r z y s ty w a n y p r z e z o d w o ła n ie z w r o tn e (c a llb a c k ) w czasie a s y n c h r o n ic z n e j w y m ia n y k o m u n ik a t ó w .

2 W oryginale ValidateW eeklyHours — przyp. tłum. 3 W oryginale GetWeeklyHoursLimit — przyp. tłum.

1 6 .1 . P O D S TA W Y JĘZYKA W S-BPEL

501

Tabela 16.2. Atrybuty elementu receive

Atrybut

Znaczenie

p a rtn e rL in k

O kreśla nazw ę klienckiej usługi partn ersk iej p o p rz ez odpow iadający jej elem ent p a rtn e rL in k .

po rtT ype

W skazuje elem en t p o r t T y p e u sługi procesow ej, oczekującej n a żądanie ze stro n y u sługi p artnerskiej.

o p e ra tio n

W skazuje operację usługi procesow ej, k tó ra p o w in n a odebrać żądanie.

v a ria b le

W skazuje k o n stru k cję v a r i a b l e w definicji p ro c e su określającą zm ienną, w której m ają zostać p rzechow ane d ane nadesłanego żądania.

c re a te In s ta n c e

G dy w artość tego a try b u tu ró w n a jest " y e s " , o debranie tego k o n k retn eg o żądania spow oduje u ru c h o m ien ie now ej instancji procesu.

Przykład 16.8. Element receive wykorzystywany w definicji Procesu rozliczania karty czasu pracy do wskazania klienckiej usługi partnerskiej odpowiedzialnej za uruchomienie procesu poprzez wysłanie dokumentu karty czasu pracy < re c e iv e n a m e = " r e c e i v e I n p u t " p a rtn e r L in k = "c lie n t" p o rtT y p e = "tn s :T im e s h e e tS u b m is s io n In te rfa c e " o p e r a t i o n = " W y s t a w 4" v a r i a b l e = "C lie n tS u b m is s io n " c re a te In s ta n c e = "y e s "/>

1 6 .1 .1 1 .

E le m e n t r e p ly

T a m g d z ie w y s tę p u je e le m e n t r e c e i v e , w p r z y p a d k u m a p o w a n i a k o m u n ik a c ji a s y n c h r o n ic z n e j w y s tę p u je t a k ż e e le m e n t r e p l y . O d p o w i e d z i a l n y je s t z a z d e f in i o w a n ie s z c z e g ó łó w w y s y ła n ia k o m u n ik a t u s ta n o w ią c e g o o d p o w ie d ź n a ż ą d a n ie n a d e s ła n e p r z e z k l ie n c k ą u s łu g ę p a r tn e r s k ą . P o n ie w a ż e le m e n t r e p l y s k o ja r z o n y je s t z t y m s a m y m e le m e n t e m p a r t n e r L in k , co o d p o w ia d a ją c y m u e le m e n t r e c e iv e , c e c h u je się p o d o b n y m z b io r e m a t r y b u t ó w , k tó r e o p is u je m y w t a b e li 1 6 .3 . Tabela 16.3. Atrybuty elementu reply

Atrybut

Znaczenie

p a rtn e rL in k

O kreśla te n sam elem en t p a r t n e r L i n k , co odpow iadający elem en t r e c e i v e .

po rtT ype

W skazuje te n sam elem en t p o r t T y p e , co odpow iadający elem en t r e c e i v e .

o p e ra tio n

W skazuje te n sam elem en t o p e r a t i o n , co odpow iadający elem en t r e c e i v e .

v a ria b le

W skazuje k o n stru k cję v a r i a b l e w definicji p ro c e su określającą k o m u n ik a t zw racany do usługi partnerskiej.

messageExchange

T en opcjo n aln y atrybut, p ro p o n o w a n y w w ersji W S-BPEL 2.0, um ożliw ia jaw ne skojarzenie z aktyw nością zd o ln ą do o d b ieran ia k o m u n ik a tó w (n a przy k ład z elem entem r e c e i v e ).

4 W o r y g in a le S u b m i t — przyp. tłum.

502

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

Przykład 16.9. Element reply, prawdopodobnie skojarzony z elementem receive z przykładu 16.8 < r e p ly p a r t n e r L i n k = " c l i e n t " p o rtT y p e = "tn s :T im e s h e e tS u b m is s io n In te rfa c e " o p e r a t i on ="W ystaw " v a r i a b le = "T im e s h e e tS u b m is s io n R e s p o n s e "/>

1 6 .1 .1 2 .

E le m e n ty s w itc h , c a s e i o t h e r w is e

T r z y w y m i e n io n e w t y t u l e e l e m e n t y s t r u k t u r a ln e u m o ż l i w i a j ą k o d o w a n ie lo g i k i w a r u n k o w e j w d e f in ic ji p ro c e s u , p o d o b n ie d o in s t r u k c ji w y b o r u c a s e lu b s w itc h w t r a d y c y jn y c h ję z y k a c h p r o ­ g r a m o w a n ia . E le m e n t s w it c h w y z n a c z a z a k re s te j lo g ik i w a r u n k o w e j, a z a g n ie ż d ż o n e w n i m k o n ­ s tr u k c je c a s e r e p r e z e n t u ją p o s z c z e g ó ln e p o r c je te j lo g ik i, u z a le ż n io n e o d w a r u n k u o k r e ś lo n e g o p r z e z a t r y b u t c o n d it io n . D o k ł a d n ie j: w p o s z c z e g ó ln y c h k o n s t r u k c ja c h c a s e , w k o le jn o ś c i ic h w y s tę p o w a n ia , e w a lu o w a n y je s t a t r y b u t c o n d it io n ; je ś li w y n ik ie m te j e w a lu a c ji je s t " t r u e " , w y k o n y w a n a je s t p o r c ja k o d u o k r e ś lo n a p r z e z d a n ą in s t r u k c ję c a s e , p o c z y m r e a liz a c ja e le m e n t u s w itc h k o ń c z y się. Jeśli w e w s z y s tk ic h k o n s tr u k c ja c h c a s e w y n ik ie m e w a lu a c ji a tr y b u tu c o n d it io n je s t " f a l s e " , w y k o n y ­ w a n a je s t p o r c ja lo g ik i o k r e ś lo n a p r z e z k o n s tr u k c ję o t h e r w is e (o ile t a k o w a w y s tę p u je w e w n ą t r z k o n s t r u k c ji s w itc h ).

Przykład 16.10. Szkielet przykładowej konstrukcji case; warunek wyrażony przez atrybut condition spełniony jest tylko wtedy, gdy wartość zmiennej EmployeeResponseMessage, odczytana za pomocą wywołania funkcji getVariableData równa jest zero < s w itc h > < case c o n d i t i o n = "g e tV a ria b le D a ta ('E m p lo y e e R e s p o n s e M e s s a g e ','R e s p o n s e P a ra m e te r')= 0 "> < / case > < o th e rw is e > < / o th e rw is e > < / s w itc h >

UWAGA Specyfikacja WS-BPEL 2 .0 zaleca używ anie elem entów i f , e l s e i f i e l s e zam iast konstrukcji s w itc h .

1 6 .1 .1 3 .

E l e m e n t y a s s ig n , c o p y , f r o m i t o

E le m e n t y te u m o ż liw ia ją k o p io w a n ie w a r to ś c i m ię d z y z m ie n n y m i p r o c e s u , co u m o ż liw ia p r z e ­ p ły w i m o d y f ik o w a n ie in f o r m a c ji p r z e tw a r z a n e j w r a m a c h te g o p ro c e s u .

1 6 .1 . P O D S TA W Y JĘZYKA W S-BPEL

503

Przykład 16.11 . W ramach konstrukcji assign komunikat stanowiący zawartość zmiennej TimesheetSubmissionFailedMessage kopiowany jest do dwóch innych zmiennych < a s s ig n > < copy > < from v a r i a b l e = " T i m e s h e e t S u b m i s s i o n F a i l e d M e s s a g e " / > < to v a r i a b l e = " E m p l o y e e N o t i f i c a t i o n M e s s a g e " / > < / copy > < copy > < from v a r i a b l e = " T i m e s h e e t S u b m i s s i o n F a i l e d M e s s a g e " / > < to v a r i a b l e = " M a n a g e r N o t i f i c a t i o n M e s s a g e " / > < / copy > < / as s ig n >

K o n s tr u k c ja copy m o ż e d o ty c z y ć r ó ż n y c h r o d z a jó w d a n y c h , n a p r z y k ła d ty lk o część ź ró d ło w e g o k o m u n ik a t u m o ż e z o s ta ć p r z e s ła n a d o z m ie n n e j d o c e lo w e j. E le m e n ty fro m i t o p o s ia d a ją o p c jo n a ln e a tr y b u ty p a r t i q u e ry u m o ż liw ia ją c e e k s tr a h o w a n ie w y b r a n y c h części z a w a r to ś c i z m ie n n y c h .

1 6 . 1 . 1 4 . E l e m e n t y f a u l t H a n d l e r s , c a t c h i c a t c h A ll W k o n s t r u k c ji f a u l t H a n d le r s m o ż n a z a g n ie ż d ż a ć w ie le e le m e n t ó w c a tc h , z k t ó r y c h k a ż d y d e d y ­ k o w a n y je s t o b s łu d z e w y ją t k u z a is tn ia łe g o w z w ią z k u z b łę d e m o k re ś lo n e g o r o d z a ju . P r z y c z y n ą w y s tą p ie n ia w y ją t k u m o ż e b y ć o d e b r a n ie k o m u n ik a t u a w a r y jn e g o (z g o d n e g o z W S D L ) a lb o j a w ­ n e u ż y c ie e le m e n t u th ro w . E le m e n t c a t c h A ll d e d y k o w a n y je s t d o m y ś ln e j o b s łu d z e w s z y s tk ic h t y c h w y ją t k ó w , k t ó r e n ie z o s ta ły o b s łu ż o n e w c z e ś n ie j w r a m a c h e le m e n t ó w c a tc h . Przyk ład 1 6 .12 . Konstrukcja faultHandlers hostująca elementy catch i catchAll < fa u ltH a n d le r s > < catch f a u l t N a m e = " S t a l o S i e C o s N i e d o b r e g o " fa u ltV a ria b le = "T im e s h e e tF a u lt"> < / c a tch > < c a tc h A ll > < / c a tc h A ll > < / fa u ltH a n d le r s >

1 6 . 1 . 1 5 . P o z o s ta łe e l e m e n t y W S -B P E L W ta b e li 1 6 .4 o p is u je m y k r ó t k o p o z o s ta łe c z ę ś c i ję z y k a WS-BPEL.

PODSUMOWANIE • Definicja procesu WS-BPEL reprezentowana jest przez usł ugę procesową w czasie realizacji tego procesu. • Usł ugi uczestniczą ce w procesach definiowanych przez WS-BPEL uważane są za usł ugi partnerskie i stanowią część definicji procesu. • Specyfikacja WS-BPEL definiuje wiele zwią zanych z aktywnościami elementów reprezentują cych róż ne aspekty logiki procesu.

504

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

Tabela 16.4. Lista referencyjna pozostałych elementów WS-BPEL (w kolejności alfabetycznej)

Element

Znaczenie

c o m p e n s a tio n H a n d le r

D efinicja p ro c e su W S-BPEL m oże specyfikow ać p ro ces k om pensacyjny, obejm ujący określoną serię aktyw ności i u ru c h a m ia n y w sytuacji w ystąpienia określonego w a ru n k u (o pro cesach k o m pensacyjnych pisaliśm y obszernie w podro zd ziale 6.5, „A ktyw ności biznesow e”). Specyfikacji tej do k o n u je się za p o m o cą ele m en tu c o m p e n s a t i o n H a n d l e r .

c o rre la tio n S e ts

W W SD L elem en t ten w ykorzystyw any jest do im p lem en to w an ia korelacji, głów nie skojarzeń k o m u n ik a tó w z in stan cjam i procesów . Z a jego p o m o cą m o żn a także definiow ać w łaściw ości k o m u n ik a tó w w d o k u m en ta ch W SDL.

em pty

Ten prosty elem ent reprezentuje aktywność pustą — używany jest do wskazywania, że w danych okolicznościach nie należy realizować żadnych aktywności.

e v e n tH a n d le rs

Ta konstrukcja umożliwia procesow i reagowanie na zdarzenia zachodzące w związku z realizacją jego logiki. W ew nątrz konstrukcji e v e n t H a n d l e r s m ogą być zagnieżdżane elem enty p o to m n e o n M e s s a g e i o n A l a r m , odpow iedzialne za w yzwalanie określonej aktyw ności w p rzypadku nadejścia k o m u n ik a tu określonego ty p u ( o n M e s s a g e ) lub upłynięciu określonego interw ału czasu ( o n A l a r m ).

e x it

P atrz opis ele m en tu t e r m i n a t e , dalej w tej tabeli.

flo w

T a k o n stru k c ja służy do definiow ania p rzepływ ów w procesie, czyli z b io ru aktyw ności realizow anych rów nolegle; przepływ uznaje się za zakończony w m o m encie, gdy zakończy się jego ostatnia aktyw ność składow a (p a trz p u n k t 6.6.4, „Sekwencje, przepływ y i złącza”). Z ależności m iędzy aktyw nościam i tw orzącym i p rzepływ definiow ane są za p o m o cą elem entów p o to m n y c h l i n k .

p ic k

To k o n stru k c ja p o d o b n a do e v e n t H a n d l e r s , rów nież zagnieżdżająca w sobie elem enty p o to m n e o n M e s s a g e i o n A l a r m w tak im sam ym znaczeniu. W o d ró ż n ie n iu o d niej używ ana jest jed n a k w o d n iesien iu do procesów zaw ieszonych w oczekiw aniu n a określone zdarzenia.

scope

Za p o m o cą tych k o n stru k c ji m o żn a w ydzielać zam knięte bloki definicji logiki. W szystkie elem enty v a r i a b l e s , f a u l t H a n d l e r s , c o r r e l a t i o n S e t s , c o m p e n s a t i o n H a n d l e r i e v e n t H a n d l e r s zdefiniow ane w ty m blo k u (czyli jako

p o to m n ie k o n stru k c ji s c o p e ) obow iązują jedynie lokalnie w ty m bloku. te rm in a te

T en elem ent p ow o d u je definityw ne zniszczenie in stan cji p rocesu, w ram ach której zostanie w ykonany. Specyfikacja W S-BPEL 2.0 zaleca je d n a k używ anie synonim icznej nazw y e x i t zam iast t e r m i n a t e .

th ro w

W y k o n an ie tego ele m en tu spow oduje zaistnienie sytuacji w yjątkow ej. W te n sposób m o żn a w sposób jaw ny generow ać w yjątki odpow iadające p ew nym um o w n y m zdarzen io m i w aru n k o m .

w a it

N ap o tk an ie tego ele m en tu spow oduje zam ierzone, tym czasow e w strzym anie realizacji p ro c esu b ąd ź to n a określony in te rw a ł czasowy, b ą d ź też do określonej daty i godziny.

w h ile

Ta konstrukcja pozw ala tworzyć pętle ze spraw dzaniem w arunku na początku, jest ona analogią pętli pow szechnie występujących p o d tą sam ą nazwą w wielu klasycznych językach program ow ania. Podporządkow ana aktywność pow tarzana jest dopóty, dopóki wartościowanie w spom nianego w arunku nie da w yniku " f a l s e " .

16.2. O SPECYFIKACJI WS-COORDINATION OGÓLNIE

505

1 6 .2 . O s p e c y fik a c ji W S - C o o r d in a t io n o g ó ln ie

UWAGA O graniczamy się tu jedynie do opisu elem entów języka W S-C oordination, bo koncepcje kryjące się za tym i elem entam i om aw ialiśm y w rozdziale 6. Lektura tego podrozdziału nie jest konieczna do zrozum ienia ciągu dalszego, zatem czytelnicy niezainteresowani szczegółami specyfikacji W S-C oordination mogą przejść od razu do podrozdziału 16 .3, „Projektow anie procesu biznesowego zorientow anego na usługi — krok po kroku".

W t y m r o z d z ia le o p is u je m y p o k r ó t c e s p e c y fik a c ję W S -C oordination , k t ó r ą w y k o r z y s t y w a ć m o ż n a n a p o t r z e b y w e w n ę t r z n y c h m e c h a n iz m ó w o r k i e s t r a c ji W S-B P E L . P r z e d s t a w i m y k i l k a e le m e n tó w d e fin io w a n y c h w te j s p e c y fik a c ji i p o k a ż e m y , j a k m o ż n a je w y k o r z y s ty w a ć d o im p le ­ m e n t o w a n ia u z u p e łn ia ją c y c h s p e c y fik a c ji p r o t o k o łó w k o o r d y n a c y jn y c h ( W S-B usinessA ctivity i W S-A tom icTransaction ). N a le ż y z a z n a c z y ć , że z n a jo m o ś ć s k ła d n i p o w y ż s z y c h ję z y k ó w n ie je s t g e n e r a ln ie k o n ie c z n a d o t w o r z e n ia d e f in ic ji p r o c e s ó w W S-BPEL . W y k o r z y s t u j e m y j ą t u g łó w n ie d o u w id o c z n ie n ia , ja k s p e c y fik a c ja W S-C oordination w p is u je się w m o d e l o r k ie s t r a c ji W S-BPEL , j a k r ó w n ie ż d o o g ó ln e ­ g o s p o jr z e n ia n a f o r m a ln ą s k ła d n ię s p e c y fik a c ji, k t ó r ą o p is a liś m y w r o z d z ia le 6. je d y n ie o d s tr o n y k o n c e p c y jn e j. O m a w ia ją c w p o d r o z d z ia le 6 .3 s p e c y fik a c ję W S-C oordination , p r z e d s t a w iliś m y p o d s ta w o w e s k ła d n ik i m e c h a n iz m u k o o r d y n a c ji, c z y li u s łu g ę a k ty w a c y jn ą , u s łu g ę re je s tra c y jn ą , k o o r d y n a to r i u s łu g i u c ze s tn ic zą c e im p le m e n tu ją c e k o n k r e tn e p r o to k o ły . Jest w ie lc e p r a w d o p o d o b n e , iż w s z y s tk ie te u s łu g i, z a rz ą d z a ją c e k o n te k s te m p r z e tw a r z a n ia , fu n k c jo n u ją p o d d y k ta n d o s iln ik a o rk ie s tr a c y jn e g o p la t ­ f o r m y , d la k tó r e j t w o r z y m y d e fin ic ję p r o c e s u WS-BPEL . N a jb a r d z ie j b o d a j in te r e s u ją c y m e le m e n te m s p e c y fik a c ji W S-C oordination i to w a r z y s z ą c y c h je j d w ó c h w y ż e j w y m i e n io n y c h d o k u m e n t ó w je s t n a g łó w e k C o o r d in a t io n C o n t e x t k o m u n ik a t u S O A P . M o ż n a n a p o t k a ć t e n n a g łó w e k w c z a s ie m o n it o r o w a n ia k o m u n ik a t ó w , m o ż n a g o ta k ż e w y k o r z y s ty w a ć d o r e a liz a c ji s p e c y fic z n e g o z a r z ą d z a n ia k o n te k s t e m k o o r d y n a c ji. I je s z c z e je d n o : c h o ć o m a w ia m y t u s p e c y fik a c ję W S-C oordination g łó w n ie w k o n te k ś c ie w a r ­ s tw y o r k ie s t r a c ji u s łu g , to n ie m o ż n a z a p o m in a ć , i ż je s t o n a s a m o d z ie ln y m r o z s z e r z e n ie m S O A , r z ą d z ą c y m się w ła s n y m i p r a w a m i. N i e je s t w ię c w ż a d e n s p o s ó b z a le ż n a a n i o d w s p o m n ia n e j w a r ­ s tw y o r k ie s tr a c ji, a n i o d s p e c y fik a c ji W S-BPEL .

1 6 .2 .1 .

E le m e n t C o o r d in a tio n C o n te x t

W t y m n a d r z ę d n y m e le m e n c ie z a g n ie ż d ż a się se rię e le m e n tó w p o t o m n y c h , z k t ó r y c h k a ż d y o d p o ­ w ie d z ia ln y je s t z a o k re ś lo n ą część in f o r m a c ji k o n te k s to w e j p r z e n o s z o n e j w n a g łó w k u k o m u n ik a tu .

Przykład 16.13. Szkielet przykładowej konstrukcji CoordinationContext < E n v e lo p e x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o r g /s o a p /e n v e lo p e /" x m ln s:w sc = " h ttp ://s c h e m a s .x m ls o a p .o rg /w s /2 0 0 2 /0 8 /w s c o o r" x m ln s :w s u = " h ttp ://s c h e m a s .x m ls o a p .o rg /w s /2 0 0 2 /0 7 /u til i ty ">

506

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

< w s c : C o o rd in a tio n C o n te x t > < w s u :Id e n tifie r> < /w s u :Id e n tifie r> < w s u :E x p ire s > < /w s u :E x p ire s > < w s c :C o o rd in a tio n T y p e > < /w s c :C o o rd in a tio n T y p e > < w s c :R e g is tra tio n S e rv ic e > < /w s c :R e g is tra tio n S e rv ic e > < / w s c : C o o rd in a tio n C o n te x t > < /H ead er> < /E n v e lo p e >

Nagłówek C o o r d in a tio n C o n te x t tworzony jest (i zwracany jako wynik) przez usługę aktywacyjną w rezultacie utworzenia nowej aktywności. Jak później wyjaśnimy, zagnieżdżona w nim konstrukcja potomna C o o r d in a tio n T y p e specyfikuje jeden z protokołów aktywności — W S-BusinessActivity albo W S-A tom icT ransaction. Dostawcy mogą definiować inne, specyficzne dla siebie elementy zagnieżdżane w konstrukcji C o o r d in a t io n C o n t e x t , reprezentujące obiekty lub wartości charakte­ rystyczne dla środowiska wykonawczego.

1 6 .2 .2 .

E l e m e n t y I d e n t i f i e r i E x p ir e s

Oba tytułowe elementy wywodzą się ze schematu użytkowego dostarczającego wieloużywalnych elementów. W S-Coordination wykorzystuje element I d e n t i f i e r do skojarzenia unikatowego iden­ tyfikatora (ID) z bieżącą aktywnością. Element E x p ir e s określa graniczną datę i godzinę możliwego czasu trwania aktywności. Przykład 1 6 .14 . Elementy Identifier i Expires zawierające wartości odnoszące się do nagłówka < E n v e lo p e x m ln s :w s u = " h ttp ://s c h e m a s .x m ls o a p .o rg /w s /2 0 0 2 /0 7 /u til i ty "> < w s u :Id e n tifie r > h ttp ://w w w .x m ltc .c o m /id s /p ro c e s s /3 3 3 4 2 < / w s u :Id e n tifie r > < w s u : E x p ire s > 2 0 08 -0 7 -3 0 T 2 4 :0 0 :0 0 .0 0 0 < / w s u : E x p ire s > < / E n v e l ope>

1 6 .2 . O SPECYFIKACJI W S -C O O R D IN A T IO N O G Ó LN IE

507

1 6 .2 .3 . E le m e n t C o o r d in a tio n T y p e E le m e n t te n o p is u je m y p o k r ó tc e w p u n k ta c h 1 6 .2 .5 i 1 6 .2 .6 p o ś w ię c o n y c h t y p o m k o o r d y n a c y jn y m

W S-BusinessActivity i W S-Atom icTransaction . 1 6 .2 . 4 . E le m e n t R e g is tr a tio n S e r v ic e E le m e n t R e g i s t r a t io n S e r v ic e o d p o w ie d z ia ln y je s t z a h o s to w a n ie a d re s u p u n k t u k o ń c o w e g o u s łu g i re je s tra c y jn e j. W y k o r z y s t u je o n e le m e n t A d d re s s d o s ta r c z a n y r ó w n ie ż p r z e z s c h e m a t u ż y tk o w y .

Przykład 16.15. Element RegistrationService zawierający URL wskazujący lokalizację usługi rejestracyjnej < w s c : R e g is tr a tio n S e r v ic e > < w s u :A d d re ss > h ttp ://w w w .x m ltc .c o m /b p e l/re g < /w su:A dd re ss> < / w s c : R e g is tr a tio n S e r v ic e >

1 6 .2 . 5 . W y b ó r t y p u k o o r d y n a c y jn e g o W S -B u s in e s s A c tiv ity K o n k r e t n y p r o t o k ó ł ( p r o t o k o ły ) u s ta n a w ia ją c y r e g u ły i o g r a n ic z e n ia a k ty w n o ś c i id e n t y f ik o w a n y je s t z a p o m o c ą e le m e n t u C o o r d in a tio n T y p e . H o s to w a n e p r z e z n ie g o w a r to ś c i U R I są p r e d e f in io ­ w a n e w s p e c y fik a c ja c h W S-B usinessActivity i W S-A tom icTransaction . W

p ie r w s z y m z p o n iż s z y c h p r z y k ła d ó w w id z im y e le m e n t C o o r d in a tio n T y p e

id e n t y f ik u ją c y

ty p k o o r d y n a c y jn y W S-BusinessActivity. O z n a c z a to , ż e a k ty w n o ś ć , w z w ią z k u z k t ó r ą n a g łó w e k k o m u n ik a t u p r z e n o s i in f o r m a c ję k o n te k s t o w ą , je s t p r z y p u s z c z a ln ie a k ty w n o ś c ią d łu g o t r w a łą .

Przykład 16.16. Element CoordinationType reprezentujący protokół WS-BusinessActivity < w s c :C o o rd in a tio n T y p e >

h ttp ://s c h e m a s .x m ls o a p .o rg /w s /2 0 0 4 /0 1 /w s b a < /w s c :C o o rd in a tio n T y p e >

1 6 .2 . 6 . W y b ó r t y p u k o o r d y n a c y jn e g o W S -A to m ic T r a n s a c tio n W d r u g im ze w s p o m n ia n y c h p r z y k ła d ó w e le m e n t C o o rd in a tio n T y p e re p r e z e n tu je ty p k o o r d y n a c y jn y

W S-AtomicTransaction , co o z n a c za , że n a g łó w e k k o m u n ik a tu p rz e n o s i in fo r m a c ję k o n te k s to w ą z w ią ­ z a n ą p r a w d o p o d o b n ie z a k ty w n o ś c ią k r ó tk o tr w a łą , w y k o n y w a n ą ja k o tra n s a k c ja n ie p o d z ie ln a .

Przykład 16.17. Element CoordinationType reprezentujący protokół WS-AtomicTransaction < w s c :C o o rd in a tio n T y p e >

h ttp ://s c h e m a s .x m ls o a p .o rg /w s /2 0 0 3 /0 9 /w s a t < /w s c :C o o rd in a tio n T y p e >

PODSUMOWANIE •

Specyfikacja WS-Coordination definiuje zaw ansow any system zarządzania kontekstem przetw arzania, m ożliw y do spożytkowania w ramach definicji WS-BPEL.

•

Specyfikacje WS-BusinessActivity i WS-AtomicTransaction definiują specyficzne protokoły jako typy koordynacyjne dla WS-Coordination.

508

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

1 6 .3 . P r o je k to w a n ie p ro c e s u —

b iz n e s o w e g o z o r ie n to w a n e g o

n a u s łu g i

k ro k p o k ro k u

Definiowanie procesu w ramach rozwiązania zorientowanego na usługi to w zasadzie prawidłowe zinterpretowanie zebranych wcześniej wymagań tego procesu i prawidłowe ich zaimplemento­ wanie. „W zasadzie”, bo przy tym wszystkim trzeba jeszcze wziąć pod uwagę wszystkie możliwe warianty przebiegu aktywności; to oznacza nie tylko konieczność zidentyfikowania, co może się popsuć w procesie, lecz także dokładne określenie, ja k proces ten reagować ma na wszelkie nie­ spodziewane lub nienormalne sytuacje. Historycznie rzecz ujmując, procesy biznesowe projektowane były przez analityków, wykorzy­ stujących narzędzie modelowania w celu sporządzenia diagramów modeli; diagramy te przeka­ zywane były następnie architektom i programistom do zaimplementowania. Diagram przepływu pracy, wraz z towarzyszącą mu dokumentacją, stanowił jedyny środek komunikowania, jak logika procesu powinna zostać zrealizowana w ramach rozwiązania automatyzacyjnego. I choć dogłębna analiza i szczegółowa dokumentacja w rękach kompetentnych ekspertów dawała dużą szansę udanej współpracy między zespołami biznesowymi a zespołami technicznymi, jednak podejście to kreowało znaczące ryzyko błędów i pomyłek. Z intencją zniwelowania opisanej luki między analitycznym a technicznym ujęciem procesu biznesowego stworzono języki do operacyjnego modelowania procesów — przykładem takiego języka jest właśnie W S-BPEL. Oparte na tych językach narzędzia modelujące pozwalają anality­ kom wyrażać w formie graficznej wymagania w zakresie logiki przepływu pracy i na żądanie (lub na bieżąco, w tle) konwertują tę formę na kod zgodny ze składnią i semantyką wspomnianego języka. Zazwyczaj warunkiem efektywnego korzystania z narzędzi tego rodzaju jest dobra znajomość języka, na którym się one opierają, choć dostępne są już narzędzia bardziej wyrafinowane, znacz­ nie ten wymóg łagodzące — analitycy nie muszą znać szczegółów języka WS-BPEL, by otrzymywać (generowane automatycznie) definicje procesów w tym języku. Graficzne ujęcie procesu przez analityka (jako „interfejs czołowy”) transformowane jest więc na wykonywalny kod („zaplecze”) nadający się do bezpośredniego wdrożenia i niepozostawiający żadnych wątpliwości czy możliwości dowolnej interpretacji. Na rysunku 16.2 przedstawiamy schematyczne ujęcie tego zjawiska. W czasie realizacji proces WS-BPEL jest urzeczywistniany przez usługę procesową egzystującą w warstwie interfejsów usług. Ta usługa procesowa faktycznie ustanawia podwarstwę orkiestracji usług odpowiedzialną za komponowanie warstw biznesowej i aplikacyjnej oraz zarządzanie nimi.

1 6 .3 .1 .

P ro c e s

Prezentowany tu krok po kroku proces projektowy, schematycznie przedstawiony na rysunku 16.3, stanowi pewną wzorcową propozycję podejścia do tworzenia definicji procesu W S-BPEL. Jest on łudząco podobny do procesu projektowania biznesowej usługi zadaniowej, opisywanego w podrozdziale 15.4, różni się jednak od niego jednym ważnym szczegółem.

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

509

Rysunek 16.2. Generowanie konkretnej definicji usługi procesowej za pomocą narzędzi modelujących

Projektując mianowicie usługę zadaniową, tworzyliśmy jej interfejs odpowiadający przewidy­ wanej wymianie przez tę usługę komunikatów z innymi usługami. Szczegóły logiki przepływu pracy nie były wówczas istotne, odkładaliśmy je do czasu projektowania i konstruowania powią­ zanej logiki aplikacyjnej. W przypadku projektowania procesu WS-BPEL logika ta jest natomiast wyrażana w formie abstrakcyjnej definicji tegoż procesu, nie można jej więc oddzielić od definio­ wania interfejsu. Przykłady, za pomocą których ilustrujemy poszczególne kroki powyższego procesu, celowo są dość proste, by ułatwić zrozumienie roli poszczególnych elementów języka WS-BPEL opisywa­ nych w poprzednich punktach. Typowe projekty usług procesowych wymagają zazwyczaj bar­ dziej szczegółowego i bardziej wymyślnego projektowania. Jak widać na rysunku 16.3, projektowanie procesu biznesowego jest ostatnim krokiem ogólnie pojętego procesu projektowania zorientowanego na usługi. Oznacza to w większości przypadków, że dysponujemy już wymodelowanymi i zaprojektowanymi usługami biznesowymi i usługami aplikacyjnymi.

510

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

Rysunek 16.3. Wysokopoziomowa struktura procesu projektowania procesu biznesowego ANALIZA PRZYPADKU W TLS na porządku dziennym jest ponownie Proces rozliczania karty czasu pracy, będący przedmiotem ćwiczeń modelowania w rozdziale 12; przedstawiliśmy jego logikę w schemacie na rysunku 12.15 i przypominamy na rysunku 16.4. Analitycy i architekci zdecydowali się ubrać tę logikę w ramy formalnego procesu WS-BPEL.

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

Rysunek 16.4. Oryginalny Proces rozliczania karty czasu pracy firmy TLS

511

512

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

Przystępując do uzupełniania poprzednich procesów projektowania usług, rozpoczęto od zinwentaryzowania projektów widocznych na rysunku 16.5. W poprzednich analizach przy­ padków przeanalizowaliśmy jedynie projektowanie usługi Pracownik; opis projektowania pozostałych odłożyliśmy do tego momentu, by na ich przykładzie zademonstrować rolę usług partnerskich WS-BPEL.

/

/

Pracownik

\

• PobierzTygodniowyLimitGodzin l

/

Karta czasu pracy

\

1 ■PobierzGodzinyAutoryzowane \

• ZaktualizujHistorie

Rysunek 16.5. Wykonane dotychczas projekty usług TLS

Architekci wzięli na tapetę także oryginalny diagram kompozycyjny, widoczny na rysunku 12.26 i reprodukowany na rysunku 16.6, ukazujący cztery wspomniane usługi jako podpo­ rządkowane Usłudze procesowej rozliczania karty czasu pracy. którą to usługę zamierzają teraz zbudować. Oczywiście, architekci wzięli także pod lupę wymodelowaną kandydaturę na tę usługę, przedstawioną na rysunkach 12.21 i 16.7. Uzbrojeni tym samym w niezbędna wiedzę architekci TLS przystąpili do projektowania procesu biznesowego.

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

513

Rysunek 16.6. Oryginalna kompozycja usług zdefiniowana na etapie modelowania usług

Rysunek 16.7. Kandydatura na Usługę procesową rozliczania karty czasu pracy

Krok 1.: identyfikowanie możliwych scenariuszy interakcji M o ż e m y z d e f in io w a ć w y m a g a n ia z w ią z a n e z w y m ia n ą k o m u n ik a t ó w p r z e z n a s z ą u s łu g ę p r o c e ­ s o w ą , w y k o r z y s tu ją c w y m ie n io n e p o n iż e j z e b r a n e d o ty c h c z a s in fo r m a c je : •

lo g ik ę p r z e p ły w u p r a c y , z d e f in io w a n ą w p ro c e s ie m o d e lo w a n ia u s łu g , o p is y w a n y m w r o z d z ia le 1 2 .,

•

k a n d y d a tu r ę n a u s łu g ę p r o c e s o w ą , w y ło n io n ą w e w s p o m n ia n y m p r o c e s ie m o d e lo w a n ia ,

•

p r o je k t y u s łu g u tw o r z o n e w r a m a c h p r o c e s ó w o p is y w a n y c h w r o z d z ia le 15.

P o w y ż s z e in f o r m a c j e p o s łu ż ą ja k o p o d s ta w a d o a n a liz y w s z y s tk ic h m o ż liw y c h s c e n a r iu s z y in t e r a k c ji m i ę d z y u s łu g ą p r o c e s o w ą a u s łu g a m i p a r t n e r s k im i. W y n i k i e m te j a n a liz y b ę d z ie s e r ia w y m a g a ń w z a k r e s ie p r z e t w a r z a n ia , s ta n o w ią c y c h m a t e r ia ł w e jś c io w y d la k r o k u 2.

514

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

ANALIZA PRZYPADKU D o z id e n ty fik o w a n ia m o ż liw y c h s c e n a riu s z y in te r a k c ji u s łu g i p ro c e s o w e j z u s łu g a m i p a r tn e r s k im i a r c h ite k c i T L S w y k o r z y s ta li d ia g r a m y a k ty w n o ś c i. P o n iż e j p r z e d s ta w ia m y d w a w y b r a n e z n ic h . N a d ia g r a m ie z r y s u n k u 1 6 .8 z ilu s t r o w a n e z o s ta ły in te r a k c je n ie z b ę d n e d la p o m y ś ln e g o w y k o n a n ia

Procesu rozliczania karty czasu pracy. Z a u w a ż m y , że w t y m s c e n a riu s z u n ie b ie r z e Powiadamianie .

u d z ia łu u s łu g a

ok

o

K

|------------------Ol

i —

j§

1 ..........................................................................................

o.

Rysunek 16.8. Pomyślne wykonanie Procesu rozliczania karty czasu pracy

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

515

D ia g r a m z r y s u n k u 1 6 .9 o d p o w ia d a n a to m ia s t s y tu a c ji, g d y d o k u m e n t k a r t y c z a s u p r a c y z o s ta je o d r z u c o n y p r z e z u s łu g ę

Karta czasu pracy, p r a w d o p o d o b n ie w s k u te k b r a k u p o p r a w n e j

a u to r y z a c ji.

Rysunek 16.9. Sytuacja wyjątkowa — przerwanie procesu spowodowane odrzuceniem autoryzacji D w a p o w y ż s z e s c e n a riu s z e p o z w a la ją z id e n t y f ik o w a ć n a s z ą u s łu g ę p ro c e s o w ą ja k o p o s ia ­ d a ją c ą p o t e n c ja ln ie je d n e g o k lie n t a w ś r ó d u s łu g p a r tn e r s k ic h i w y k o r z y s tu ją c ą p ię ć o p e r a c ji c z te re c h u s łu g p a r tn e r s k ic h , w o b e c k tó r y c h to u s łu g s a m a p e łn i r o lę k lie n t a (c o p r z e d s ta w io n o n a r y s u n k u 1 6 .1 0 ).

516

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

Rysunek 16.10. Przychodzące i wychodzące komunikaty-żądania oczekiwane przez Usługę procesową rozliczania karty czasu pracy

Krok 2.: projektowanie interfejsu usługi procesowej P o r o z p o z n a n iu r e p e r t u a r u m o ż liw y c h k o m u n ik a t ó w m o ż e m y p r z y s tą p ić d o b u d o w a n ia d e fin ic ji W S D L u s łu g i p r o c e s o w e j. N a r z ę d z ia d o m o d e lo w a n ia u m o ż li w i a ją a u to m a t y c z n e g e n e r o w a n ie ta k ic h d e fin ic ji, z w y k le je d n a k w y m a g a ją o n e p o p r a w e k i u z u p e łn ie ń . T a k c z y in a c z e j, k o n ie c z n e je s t p r z y n a jm n ie j z a p o z n a n ie się z k o d e m d e fin ic ji, z a k t ó r ą b ie r z e m y p r z e c ie ż o d p o w ie d z ia ln o ś ć — o to k ilk a w s k a z ó w e k d o ty c z ą c y c h s a m o d z ie ln e g o tw o r z e n ia d e fin ic ji i o p ty m a liz o w a n ia d e fin ic ji w y g e n e r o w a n y c h a u to m a ty c z n ie . •

U d o k u m e n t u j w e jś c io w e i w y jś c io w e w a r to ś c i w y m a g a n e d o p r z e t w a r z a n ia k a ż d e j o p e r a c ji, w y p e łn ij k o n s t r u k c je ty p e s w s c h e m a ta c h X S D d e f in ic ja m i t y p ó w d a n y c h b io r ą c y c h u d z ia ł w t y m p r z e t w a r z a n iu . W y o d r ę b n i j d e fin ic je s c h e m a tó w X S D w p o s ta c i o s o b n y c h p li k ó w w s z ę d z ie t a m , g d z ie je s t to u z a s a d n io n e .

•

R o z p o c z n ij b u d o w a n ie d e f i n ic j i W S D L o d k o n s t r u k c ji p o r tT y p e ( lu b i n t e r f a c e ) , z a g n ie ż d ż a ją c w n ie j k o n s t r u k c je o p e r a t io n d la k a ż d e j z id e n t y f ik o w a n e j o p e r a c ji. N a s t ę p n ie d o d a j n ie z b ę d n e k o n s t r u k c je m e ss ag e z z a g n ie ż d ż o n y m i e le m e n t a m i p a r t o d w o łu ją c y m i się d o o d p o w ie d n ic h t y p ó w X S D . U ż y w a j p r z y t y m k o n w e n c ji n a z e w n ic z y c h z g o d n y c h z t y m i, k t ó r e s to s o w a łe ś p r z y t w o r z e n iu in n y c h d e fin ic ji W S D L .

•

D o d a j r e p r e z e n t a t y w n ą m e t a in f o r m a c ję w p o s ta c i e le m e n tu d o c u m e n ta tio n .

•

Z a s to s u j e w e n tu a ln e in n e s ta n d a r d y p r o je k to w e , s p e c y fic z n e d la w y k o r z y s ty w a n e g o n a r z ę d z ia m o d e lu ją c e g o .

P o d c z a s p r o je k t o w a n ia u s łu g i p r o c e s o w e j o k a z je d o z a s to s o w a n ia i n n y c h k r o k ó w o p is y w a ­ n y c h w r o z d z ia le 1 5 . są r a c z e j n ik łe ; t r u d n o n a p r z y k ł a d s tw o r z y ć u s łu g ę p r o c e s o w ą ja k o b e z s ta n o w ą , s k o r o to w ła ś n ie o n a w y r ę c z a u s łu g i p a r tn e r s k ie o d k o n ie c z n o ś c i u t r z y m y w a n ia in f o r ­ m a c ji o s ta n ie a k ty w n o ś c i.

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

517

ANALIZA PRZYPADKU W y g lą d a n a to , ż e

Usługa procesowa rozliczania karty czasu pracy n ie je s t s z c z e g ó ln ie

s k o m p l ik o w a n a — o b e jm u je t y lk o je d n ą o p e r a c ję ( p a t r z r y s u n e k 1 6 .1 1 ) , k t ó r ą p a r t n e r s k a u s łu g a k lie n c k a w y w o łu je w c e lu z a in ic jo w a n ia p ro c e s u .

Rysunek 16.11. Projekt Usługi procesowej rozliczania karty czasu pracy I w t y m k s z ta łc ie je s t o n a z d e f in io w a n a t a k , j a k w p r z y k ła d z ie 1 6 .1 8 . Przykład 16 .18 . Abstrakcyjna część definicji WSDL Usługi procesowej rozliczania karty czasu pracy < d e f i n i t i o n s n a m e = "R o z lic z e n ie K a rty C z a s u P ra c y 5" targ etN am esp ace= "h t t p : / / w w w .x m lt c . c o m / tls / p r o c e s s / w s d l/ " x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o r g /w s d l/" x m ln s :ts = "h ttp ://w w w .x m ltc .c o m /tls /tim e s h e e t/s c h e m a /" x m ln s :ts d = "h ttp ://w w w .x m ltc .c o m /tls /tim e s h e e ts e rv ic e /s c h e m a /" x m ln s :s o a p = "h ttp : // s c h e m a s . x m ls o a p . o r g /w s d l/s o a p / " x m ln s :tn s = "h ttp ://w w w .x m ltc .c o m /tls /tim e s h e e t/w s d l/"

x m ln s :p ln k = llh t tp : //s c h e m a s .x m ls o a p .o r g /w s /2 0 0 3 /0 5 /p a r tn e r -lin k /ll> < x sd:sch em a x m ln s :x s d = " h ttp ://w w w .w 3 .o rg /2 0 0 1 /X M L S c h e m a " targ etN am esp ace= " h ttp ://w w w .x m ltc .c o m /tls /tim e s h e e ts u b m is s io n s e r v ic e /s c h e m a "/> < x s d :im p o rt nam espace="h t t p : // w w w .x m lt c . c o m / tls / t im e s h e e t/ s c h e m a / " s c h e m a L o c a tio n = "T im e s h e e t.x s d "/> < x s d : e le m e n t nam e="W ystaw "> < x s d :c o m p le x T y p e > < x s d :e le m e n t n a m e = "C o n te x tID " t y p e = " x s d : in t e g e r " / > < x s d : e le m e n t n a m e = "T im e sh e e tD o cu m e n t" ty p e = "ts :T im e s h e e tT y p e "/> < /x s d :s e q u e n c e > < /xs d :c o m p le xT yp e > < /x s d :e le m e n t> < /xs d :s c h e m a > < /typ e s >

5 W o r y g in a le T im e s h e e t S u b m is s io n — przyp. tłum.

518

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

< p a r t n a m e = "P a ylo a d " e le m e n t= " t s d :T im e s h e e t T y p e " /> < p o rtT yp e n a m e = "T im e s h e e tS u b m is s io n In te rfa c e "> < d o c u m e n ta tio n > I n i c j u j e proce s r o z lic z a n ia k a rty czasu p ra c y . < /d o c u m e n ta tio n > < o p e r a t io n nam e="W ystaw "> < in p u t m e s s a g e = "tn s :re c e iv e S u b m itM e s s a g e "/> < /o p e ra tio n > < /p o rtT yp e >

< p ln k :p a rtn e rL in k T y p e name="TimesheetSubm issionType"> < p ln k :r o le nam e="Tim esheetSubm issionService"> < p ln k :p o rtT y p e n a m e = "tn s:T im esh eetS u b m is sio n In terfac e"/> < /p ln k :r o le > < /p ln k :p a rtn e rL in k T y p e > < /d e fin itio n s >

Wyróżniliśmy konstrukcję p a r t n e r L in k T y p e — będzie ona dodawana do każdej usługi partnerskiej.

Krok 3.: formalizowanie konwersacji z usługami partnerskimi Zaczynamy tworzenie definicji naszego procesu WS-BPEL od ustanowienia szczegółów interakcji usługi procesowej z usługami partnerskimi. Oto sugerowany plan postępowania. 1. Zdefiniuj usługi partnerskie uczestniczące w procesie i każdej z nich przypisz rolę, jaką odgrywać będzie w konkretnej wymianie komunikatów. 2. Dodaj odpowiednie konstrukcje p a r t n e r L in k T y p e na końcu definicji WSDL każdej usługi partnerskiej. 3. W definicji procesu utwórz konstrukcje p a r t n e r L in k T y p e dla każdej usługi partnerskiej. 4. Zdefiniuj elementy v a r ia b l es reprezentujące komunikaty odbierane i wysyłane przez usługę procesową w ramach jej komunikacji z usługami partnerskimi. Powyższe informacje dokumentują zasadniczo możliwe przebiegi konwersacji w ramach reali­ zowanego procesu. Zależnie od konkretnego narzędzia modelującego, ich zebranie i udokumento­ wanie może wymagać różnego stopnia interakcji z użytkownikiem. ANALIZA PRZYPADKU Po zdefiniowaniu interfejsu Usługi procesowej rozliczania karty czasu pracy architekci TLS mogą rozpocząć definiowanie procesu, na podstawie informacji zebranej w kroku 1. Jak pa­ miętamy, ustalili oni dla usługi procesowej jedną partnerską usługę kliencką i cztery usługi partnerskie, dla których ta usługa procesowa sama pełni rolę klienta. Każdej z usług partnerskich przypisane zostaną teraz role, etykietowane stosownie do re­ lacji, w jakiej dana usługa pozostaje z usługą procesową. Role te zostaną następnie formalnie zapisane przez dołączenie odpowiednich konstrukcji p a r t n e r L in k T y p e na końcu definicji WSDL każdej z usług partnerskich. Na przykładzie 16.19 widzimy uzupełnioną w ten sposób usługę Pracownik (na podstawie pierwowzoru zaprojektowanego w rozdziale 15.) — zwróćmy uwagę na definicję przestrzeni nazw dla konstrukcji p a r t n e r L in k T y p e .

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

519

Przykład 16 .19 . Zrewidowana konstrukcja définitions usługi Pracownik < d e fin itio n s n a m e = "P ra c o w n ik " ta rg e tN a m e s p a c e = "h t t p : / / w w w . x m l t c . c o m / t l s/e m p l o y e e / w s d l/ " x m ln s = "h ttp ://s c h e m a s .x m ls o a p .o r g /w s d l/" x m ln s :a c t= " h t t p : // w w w .x m lt c . c o m / tls /e m p lo y e e /s c h e m a /a c c o u n tin g /" x m ln s :h r= "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /s c h e m a /h r/" x m ln s :s o a p = "h ttp : // s c h e m a s . x m ls o a p . o r g /w s d l/s o a p / " x m ln s :tn s = "h ttp ://w w w .x m ltc .c o m /tls /e m p lo y e e /w s d l/ "

xm lns:p lnk= "h ttp ://s c h e m a s .x m ls o a p .o r g /w s /2 0 0 3 /0 5 /p a r tn e r -lin k /"> < p ln k :p a rtn e rL in k T y p e name="EmployeeType"> < p ln k :r o le name="Em ployeeService"> < p ln k :p o rtT y p e n a m e = "tn s :E m p lo y e e In te rfa c e "/> < /p ln k :r o le > < /p ln k :p a rtn e rL in k T y p e > < /d e fin itio n s >

W r a m a c h d e fin ic ji p r o c e s u z w ią z k i u s łu g i p r o c e s o w e j z u s łu g a m i p a r t n e r s k im i u w id o c z ­ n io n e są w s e rii k o n s tr u k c ji p a r t n e r L in k z a g n ie ż d ż o n y c h w r a m a c h k o n s t r u k c ji p a r t n e r L in k s (k o n s tr u k c je te z o s ta ły p o p r o s tu s k o p io w a n e z a p o m o c ą „ p rz e c ią g a n ia i u p u s z c z a n ia ” o b ie k tó w z d e fin ic ji w s p o m n ia n y c h u s łu g , p r z y u ż y c iu n a r z ę d z ia m o d e lu ją c e g o ). Przykład 16 .20 . Konstrukcja partnerLinks usługi procesowej zagnieżdżająca elementy partnerLink dla każdej usługi partnerskiej < p a rtn e rL in k s > < p a rtn e r L in k n a m e = " c l i e n t " p a rtn e rL in k T y p e = "b p l:T im e s h e e tS u b m is s io n P ro c e s s T y p e " m y R o le = "T im e s h e e tS u b m is s io n P ro c e s s S e rv ic e P ro v id e r"/> < p a rtn e r L in k n a m e = " F a k t u r a " p a rtn e rL in k T y p e = "in v :In v o ic e T y p e " p a rtn e rR o le = "In v o ic e S e rv ic e P ro v id e r"/> < p a rtn e r L in k n a m e = " K a r t a C z a s u P r a c y " p a rtn e rL in k T y p e = "ts t:T im e s h e e tT y p e " p a rtn e rR o le = "T im e s h e e tS e rv ic e P ro v id e r"/> < p a rtn e r L in k n a m e = " P r a c o w n i k " p a rtn e rL in k T y p e = "e m p :E m p lo y e e T y p e " p a rtn e rR o le = "E m p lo y e e S e rv ic e P ro v id e r"/> < p a rtn e r L in k n a m e = " P o w i a d a m i a n i e " p a rtn e rL in k T y p e = "n o t:N o tific a tio n T y p e " p a rtn e rR o le = " N o tifi c a tio n S e rv ic e P ro v id e r"/> < / p a rtn e rL in k s >

T e r a z czas n a p r z y p o r z ą d k o w a n ie k o m u n ik a t ó w w e jś c io w y c h i w y jś c io w y c h k a ż d e j z u s łu g p a r t n e r s k ic h d o p o s z c z e g ó ln y c h z m ie n n y c h , r e p r e z e n to w a n y c h p r z e z e le m e n t y v a r i a b l e z a ­ g n ie ż d ż o n e w k o n s tr u k c ji v a r ia b l e s . D o d a n y z o s ta n ie ta k ż e e le m e n t v a r i a b l e r e p r e z e n tu ją c y o p e r a c ję

Wystaw u s łu g i p ro c e s o w e j, w y w o ły w a n ą p r z e z a p lik a c ję k lie n c k ą H R w c e lu z a in i­

c jo w a n ia p ro c e s u .

520

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

Przykład 16 .21 . Konstrukcja variables zagnieżdżająca elementy variable reprezentujące komunikaty wejściowe i wyjściowe usług partnerskich oraz samej usługi procesowej < v a r ia b le s > < v a r ia b le name= m essageType= < v a r ia b le name= messageType= < v a r ia b le name= messageType= < v a r ia b le name= messageType= < v a r ia b le name= messageType= < v a r ia b le name= messageType= < v a r ia b le name= messageType= < v a r ia b le name= messageType= < v a r ia b le name= messageType= < v a r ia b le name= messageType= < / v a r ia b le s >

C lie n tS u b m is s io n " b p l:re c e iv e S u b m itM e s s a g e "/> E m p lo ye e H o u rsR e q u e s t" e m p :g e tW e e k ly H o u rs R e q u e s tM e s s a g e "/> E m ploye eH ou rsR e spon se" e m p :g e tW e e k ly H o u rs R e s p o n s e M e s s a g e "/> E m p lo ye e H isto ry R e q u e st" e m p :u p d a te H is to ry R e q u e s tM e s s a g e "/> E m p lo y e e H is to ry R e s p o n s e " e m p :u p d a te H is to ry R e s p o n s e M e s s a g e "/> In v o ic e H o u rs R e q u e s t" in v :g e tB ille d H o u rs R e q u e s tM e s s a g e "/> In v o ic e H o u rs R e s p o n s e " in v :g e tB ille d H o u rs R e s p o n s e M e s s a g e "/> T im e s h e e tA u th o riz a tio n R e q u e s t" ts t:g e tA u th o riz e d H o u rs R e q u e s tM e s s a g e "/> T im e s h e e tA u th o riz a tio n R e s p o n s e " ts t:g e tA u th o riz e d H o u rs R e s p o n s e M e s s a g e "/> N o tific a tio n R e q u e s t" n o t:s e n d M e s s a g e "/>

Gdy spojrzymy na definicję usługi Pracownik (patrz przykład 15.8), zauważymy w niej obecność konstrukcji m essage o nazwach (atrybut name ) tożsamych z wartościami przypisy­ wanymi atrybutowi m e ss ag e T yp e poszczególnych zmiennych z powyższej konstrukcji. Krok 4.: definiowanie logiki procesu Dysponujemy już zatem wszystkim, co niezbędne do skompletowania definicji procesu. Notabene ten krok sam w sobie jest złożonym procesem transformowania i implementowania zebranej wie­ dzy w formie definicji WS-BPEL . ANALIZA PRZYPADKU Zespół TLS przystępuje więc do tworzenia definicji procesu, wyrażającej oryginalną logikę przepływu pracy oraz wymagania przetwarzania i uwzględniającej dwa przedstawione wcze­ śniej scenariusze interakcji. Pozostała część tej analizy przypadku poświęcona jest wybranym szczegółom tworzonej definicji. Wizualna reprezentacja logiki definiowanego procesu, wyrażona w kategoriach składni języka WS-BPEL, przedstawiona jest na rysunku 16.12; odpowiada ona pierwszemu ze wspo­ mnianych scenariuszy, czyli pomyślnemu zakończeniu procesu. UWAGA Kompletna definicja WS-BPEL Procesu rozliczania karty czasu pracy jest kilkustronicowym dokum en­ tem , nie będziemy jej w ięc prezentować tu w całości; zainteresow ani czytelnicy mogą pobrać ją z ser­ w era FTP w ydaw n ictw a Helion ftp ://ftp .h e lio n .p l/p rzy k la d y/so a k o n .z ip . W tym miejscu ograniczymy się do wybranych jej fragm entów , związanych głów nie z aktywnościam i i obsługą sytuacji w yjątkow ych.

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

521

522

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

N a j p i e r w u s ta n a w ia n y je s t e le m e n t r e c e iv e , o fe r u ją c y o p e ra c ję Wystaw z Usługi proce­ sowej rozliczania karty czasu pracy; z e w n ę t r z n y k l ie n t H R , w y w o łu ją c y tę o p e r a c ję , in ic ju je w t e n s p o s ó b c a ły p ro c e s . Przykład 16 .22 . Element receive dostarczający punkt wejścia do zainicjowania procesu < re c e iv e x m l n s = " h ttp ://s c h e m a s .x m ls o a p .o rg /w s /2 0 0 3 /0 3 /b u s in e s s -p ro c e s s /" n a m e = "re c e iv e In p u t" p a rtn e rL in k = "c lie n t" p o rtT y p e = "tn s :T im e s h e e tS u b m is s io n In te rfa c e " o p e ra tio n = "W y s ta w " v a r i a b l e = "C lie n tS u b m is s io n " c re a te In s ta n c e = "y e s "/>

C a ły p ro c e s r o z p o c z y n a się o d o d e b r a n ia p r z e z u s łu g ę p r o c e s o w ą k o m u n ik a t u w y s ła n e g o p r z e z k lie n t a H R . P o r ó w n u ją c w a r to ś ć a tr y b u tu o p e r a t io n e le m e n tu r e c e iv e z d e fin ic ją W S D L

Usługi procesowej rozliczania karty czasu pracy, s tw ie r d z a m y , że w e w s p o m n ia n y m k o ­ m u n ik a c ie z a w a r t y je s t k o m p le t n y d o k u m e n t - k a r t a c z a s u p r a c y , k tó r e g o d e f in ic ja z n a jd u je się w o s o b n y m s c h e m a c ie X S D . T e n k o m p le t n y d o k u m e n t z a p is a n y z o s ta je w z m ie n n e j o n a z w ie C lie n tS u b m is s io n . P o d o b n ie ja k w p r z y p a d k u lo g ik i in t e r a k c ji z p ie r w s z e g o d ia g r a m u ( w k r o k u 1 .), p ie r w s z ą a k ty w n o ś c ią w y k o n y w a n ą p r z e z u s łu g ę p ro c e s o w ą je s t p o r ó w n a n ie lic z b y g o d z in d e k la ro w a n e j p r z e z k lie n t a n a k a r c ie c z a s u p r a c y z lic z b ą g o d z in w y s z c z e g ó ln io n ą n a f a k tu r z e . W y o d r ę b ­ n ie n ie lic z b y g o d z in z f a k t u r y w y k o n u je u s łu g a

Faktura — n ie d o k o n u je o n a w s p o m n ia n e g o

p o r ó w n a n ia , le c z n a p o d s ta w ie I D f a k t u r y e k s tr a h u je z n ie j je d y n ie w a r to ś ć (lic z b ę g o d z in ) ja k o a r g u m e n t te g o p o r ó w n a n ia . D a n y m i w e jś c io w y m i d o u s łu g i

Faktura są I D k lie n t a o r a z d a ta w y k o n a n ia p r a c y . Z o s ta ją

o n e w y o d r ę b n io n e z e z m ie n n e j C lie n tS u b m is s io n (d o k ła d n ie j — je j e le m e n tu B i l l i n g I n f o ) i s k o p io w a n e d o z m ie n n e j In v o ic e H o u r s R e q u e s t ja k o p a r a m e tr y ż ą d a n ia (R e q u e s tP a ra m e te r ) k o m u n ik a t u p r z e z n a c z o n e g o d o w y s ła n ia . Przykład 16 .23 . Kopiowanie niezbędnych danych z karty pracy (zmienna ClientSubmission) do zmiennej zawierającej parametry wywołania usługi Faktura (InvoiceHoursRequest) < assig n n a m e = " G e t I n v o i c e I D " > < copy > < from v a r i a b l e = " C l i e n t S u b m i s s i o n " p a r t = " p a y l o a d " q u e ry = "/T im e s h e e tT y p e /B illin g In fo "/> < to v a r i a b l e = " I n v o i c e H o u r s R e q u e s t " p a rt= "R e q u e s tP a ra m e te r"/> < / copy > < / as s ig n >

P a r a m e t r y w y w o ła n ia są p r z y g o t o w a n e , w y w o łu je m y z a t e m o p e ra c ję

Naliczone 6 u s łu g i Faktura, w y k o r z y s tu ją c k o n s tr u k c ję in v o k e .

6 W o r y g in a le G e t B il l e d H o u r s — przyp. tłum.

PobierzGodziny-

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

523

Przykład 16 .24 . Element invoke posiadający szereg atrybutów, które dostarczają usłudze procesowej informacje niezbędne do odnalezienia usługi Faktura i utworzenia jej instancji < invoke n a m e = " W e r y f i k u j G o d z i n y N a F a k t u r z e " p a rtn e rL in k = "F a k tu ra " o p e ra tio n = "P o b ie rz G o d z in y N a lic z o n e " in p u tV a r ia b le = "In v o ic e H o u rs R e q u e s t" o u tp u tV a ria b le = "In v o ic e H o u rs R e s p o n s e " p o rtT y p e = "in v :In v o i c e In te rfa c e "/>

W y w o ł a n a o p e r a c ja

PobierzGodzinyNaliczone u s łu g i Faktura o d s y ła z w r o t n y k o m u n i-

k a t - o d p o w ie d ź . Z g o d n ie z w a r to ś c ią a t r y b u t u o u t p u t V a r ia b l e e le m e n t u in v o k e , k o m u n ik a t te n z a p a m ię t a n y z o s ta je w z m ie n n e j In v o ic e H o u rs R e s p o n s e . D y s p o n u je m y ju ż w ię c o b y d w o m a a r g u m e n ta m i d o p o r ó w n a n ia : lic z b ą g o d z in d e k la ro w a n ą p r z e z p r a c o w n ik a n a k a rc ie czasu p ra c y (m o ż n a ją w y e k s tra h o w a ć ze z m ie n n e j C lie n tS u b m is s io n ) i lic z b ą g o d z in f ig u r u ją c ą n a f a k tu r z e (d o s tę p n ą ja k o część z m ie n n e j In v o ic e H o u r s R e s p o n s e ). P o r ó w n u je m y o b ie lic z b y g o d z in i w p r z y p a d k u n ie r ó w n o ś c i g e n e r u je m y w y ją t e k — w y k o ­ rz y s tu ją c e le m e n t w a r u n k o w y s w itc h . Przykład 16 .25 . Konstrukcja switch zawierająca element case odpowiedzialny za wygenerowanie wyjątku w przypadku stwierdzenia nierówności porównywanych liczb godzin < sw itch n a m e = " B i l l e d H o u r s M a t c h " > < case c o n d i t i o n = " g e t V a r i a b l e D a t a ( ' I n v o i c e H o u r s R e s p o n s e ' , ' R e s p o n s e P a r a m e t e r ' ) != g e t V a r i a b l e D a t a ( ' i n p u t l , l p a y l o a d ' , l / t n s : T i m e s h e e t T y p e / H o u r s / . . . 1) " > < th ro w n a m e = " V a lid a tio n F a ile d " fa u ltN a m e = " V a lid a te In v o ic e H o u rs F a ile d "/> < / case > < / sw itc h >

Jeśli w a r u n e k n ie je s t s p e łn io n y (p o r ó w n y w a n e lic z b y g o d z in są id e n ty c z n e ), d o k u m e n t- k a r ta czasu p r a c y u w a ż a n y je s t z a p o p r a w n y i p ro c e s p r z e c h o d z i d o n a s tę p n e g o k r o k u . Jeśli w a r u n e k je s t s p e łn io n y , d o g ło s u d o c h o d z i e le m e n t th r o w i g e n e r o w a n y je s t w y ją te k . C a ła a k ty w n o ś ć b iz n e s o w a p r z e n o s i się n a o b s z a r k o n s t r u k c ji f a u l t H a n d le r s , r e z y d u ją c e j p o ­ z a p r z e p ły w e m g łó w n e g o p ro c e s u . O d p o w ia d a to d r u g ie m u z e s c e n a r iu s z y p r e z e n to w a n y c h w k r o k u 1. (d o k tó r e g o je s z c z e p ó ź n ie j p o w r ó c im y ) . R e z u lta te m d o ty c h c z a s o w y c h d z ia ła ń je s t w z o r z e c s k ła d a ją c y się z n a s tę p u ją c y c h k r o k ó w . 1.

W y k o r z y s t a n ie e le m e n t ó w a s s ig n , co p y, fro m i t o d o p o b r a n ia d a n y c h ze z m ie n n e j C lie n tS u b m is s io n i s k o p io w a n ie ic h d o z m ie n n e j r e p r e z e n tu ją c e j k o m u n ik a t w y jś c io w y .

2.

U ż y c ie e le m e n t u in v o k e d o w y w o ła n ia u s łu g i p a r t n e r s k ie j, c z y li w y s ła n ia d o n ie j k o m u n ik a t u - ż ą d a n ia i o d e b r a n ia k o m u n ik a t u - o d p o w ie d z i.

3.

U ż y c ie e le m e n tó w s w itc h i case d o o d c zy tu d a n y c h z o d eb ran e g o k o m u n ik a tu i ic h w alid a c ji.

4.

U ż y c ie e le m e n tu th ro w d o w y g e n e r o w a n ia w y ją tk u , g d y w a lid a c ja d a je n e g a ty w n y w y n ik .

7 W oryginale ValidateInvoiceHours — przyp. tłum. 8 W oryginale GetAuthorizedHours — przyp. tłum. 9 W oryginale UpdateHistory — przyp. tłum. 10 W oryginale SendNotification — przyp. tłum. 11 W oryginale SendMessage — przyp. tłum.

524

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

P o w y żs z y w z o rz e c je s t w d u że j części p o w ie la n y w d a ls zy m c ią g u d e fin ic ji, co s tw ie rd z ić m o ż n a , s p o g lą d a ją c p o n o w n ie n a ry s u n e k 1 6 .1 2 . T ę część p ro c e s u m o ż n a p o k ró tc e p o d s u ­ m o w a ć n as tęp u jąco . •

Z a p o m o c ą k o n s tru k c ji a ssig n w artość T im esheetID , stanow iąca id e n ty fik a to r k a rty p racy, ko p io w a n a jest ze zm ie n n e j C lientS ubm ission do zm ie n n e j Tim esheetA uthorizationR equest; ta ostatnia w ykorzystyw ana jest p rz y o d w o ła n iu do operacji P o b ie rz G o d z in y A u to ry z o w a n e 8 usłu g i K a r ta czasu p ra c y . K o m u n ik a t z w r o tn y z a w ie ra w y n ik s p ra w d z e n ia a u to ry za c ji; k o m u n ik a t te n po w y e k s tra h o w a n iu ze z m ie n n e j, w k tó re j jest p rz e c h o w y w a n y , p o d le g a w e ry fik a c ji w ra m a c h k o n s tru k c ji s w itc h . Jeśli a utoryzacja została p o tw ie rd zo n a , n ie dzieje się n ic szczególnego, w p rz e c iw n y m razie użycie e le m e n tu throw p o w o d u je w y g e n e ro w a n ie w y ją tk u — sterow anie p rze c h o d zi do k o n s tru k c ji fa u ltH a n d le rs .

•

Z a p o m o c ą k o n s tru k c ji a s s ig n w a rto ś ć E m ployeeID , s ta n o w ią c a id e n ty fik a to r p r a c o w n ik a , k o p io w a n a je s t ze z m ie n n e j Cl ie n tS u b m is s io n do z m ie n n e j Em ployeeH oursR equest; ta o s ta tn ia w y k o rz y s ty w a n a je s t p r z y o d w o ła n iu do o p e ra c ji P o b ie r z T y g o d n io w y L im it G o d z in u s łu g i P r a c o w n ik . K o m u n ik a t z w r o tn y z a w ie ra w a rto ś ć ty g o d n io w e g o lim it u g o d z in ro b o c z y c h d la p ra c o w n ik a ; z tą w a rto ś c ią zostaje s k o n fro n to w a n a lic z b a g o d z in d e k la ro w a n a p rz e z p ra c o w n ik a n a k a rc ie p ra c y i je ż e li p rz e k ra c z a o n a w s p o m n ia n y lim it , u ż y w a n y je s t e le m e n t th ro w do w y g e n e ro w a n ia w y ją tk u — s te ro w a n ie p rz e c h o d z i do k o n s tru k c ji fa u lt H a n d le r s .

T a k w zarysie p rz e d s ta w ia się p o d s ta w o w a lo g ik a p rz e tw a rz a n ia P ro c e s u r o z lic z a n ia k a r t y cza su p ra c y — lo g ik a sukcesu, c zy li p o m y ś ln e g o z re a liz o w a n ia całego procesu. I choć a k tu a ln y z e s ta w w y m a g a ń tego n ie a rty k u łu je , w s k a za n e je s t d o d a tk o w o p rz e k a z a n ie e le m e n tu r e p ly w k o m u n ik a c ie s ta n o w ią c y m o d p o w ie d ź n a in ic ju ją c e proces ż ą d a n ie k lie n ta . P o ra w ię c z w ró c ić u w a g ę n a lo g ik ę a w a ry jn ą , o d p o w ia d a ją c ą d r u g ie m u ze s c e n a riu s z y p re z e n to w a n y c h w k r o k u 1. Jak p rz e d c h w ilą p is a liś m y , w p rz y p a d k u p o ja w ie n ia się w y ją tk u s te ro w a n ie p ro ces u p rz e c h o d z i do k o n s tru k c ji f a u lt H a n d le r s , k tó re j a rc h ite k c i T L S z a m ie ­ rz a ją n a d a ć fo rm ę ta k ą , ja k w p rz y k ła d z ie 1 6.26. Przykład 16.26. Konstrukcja faultHandlers w definicji procesu < fa u ltH a n d le rs > < c a tc h A ll> < /c a tc h A ll> < / fa u ltH a n d le rs >

M im o iż g e n e ra ln ie za le c a n e je s t k ie ro w a n ie p o s z c z e g ó ln y c h w y ją tk ó w do o s o b n y c h k o n ­ stru kc ji catch , arc h ite k c i p o s ta w ili ty m ra z e m n a obsługę h u rto w ą , k ie ru ją c w szystkie trz y m o ż li­ w e w y ją tk i do k o n s tru k c ji c a tc h A ll. O b s łu g a w y ją tk ó w została z a te m z u n ifik o w a n a i o b e jm u je t r z y p o n iż s ze z a d a n ia : 1. A k tu a liz a c ję h is to r ii w p r o filu p ra c o w n ik a . 2. W y s ła n ie p o w ia d o m ie n ia do k ie ro w n ik a . 3. W y s ła n ie p o w ia d o m ie n ia do p ra c o w n ik a .

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

525

Do ich zaimplementowania użyto znanych już elementów assign i invoke. Zarys logiki obsługi sytuacji wyjątkowych widoczny jest na diagramie z rysunku 16.13.

Rysunek 16.13. Wizualna reprezentacja logiki konstrukcji faultHandlers

526

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

P re z e n to w a n e p o n iż e j fra g m e n ty k o d u u ję te są w fo r m ę s e k w e n c ji ( sequence ) z a g n ie ż ­ d ż o n e j w m a c ie rz y s te j k o n s tru k c ji faultH andlers . N a p o c z ą te k z a d a n ie n r 1 — a k tu a liz a c ja h is to r ii w p r o filu p o d a tn ik a . Przykład 16.27. Dwa elementy copy przygotowujące komunikat-żądanie < a s s ig n n a m e = "S etE m ploye eM ess age"> < copy>
.../>

< to v a ria b le = "E m p lo y e e H is to ry R e q u e s t" < / copy> < copy> < to v a ria b le = "E m p lo y e e H is to ry R e q u e s t"

.../>

.../>

< / copy> < /a s s ig n > < in v o k e n a m e = " Z a k tu a liz u jH is t o r ie 9" p a rtn e rL in k = "P ra c o w n ik " p o rtT y p e = "e m p :E m p lo y e e In te rfa c e " o p e ra tio n = " Z a k tu a liz u jH is to rie " i n p u t V a r i a b l e = "E m p lo y e e H is to r y R e q u e s t" o u tp u tV a ria b le = "E m p lo y e e H is to ry R e s p o n s e "/>

W celu za k tu a lizo w a n ia h is to rii p ra c o w n ik a p ro c e d u ra obsługująca sytuację w y ją tk o w ą w y k o ­ rzystuje konstrukcję assign zaw ierającą dw ie k onstrukcje copy. Pierw sza z k o n s tru k c ji copy ko p iu je I D p ra c o w n ik a ( EmployeeID) ze zm ie n n e j Cl ientSubmission do zm ie n n e j EmployeeHistoryRequest, d ru g a dodaje do zm ie n n e j EmployeeHistoryRequest statyczny k o m e n ta rz. K o n s tru k c ja invoke w y w o łu je usługę P r a c o w n ik (k tó re j p o p rz e d n io u ż y w a liś m y do p o b ra n ia tyg o d n io w eg o lim itu g o d zin , za p o m o c ą operacji P o b ie r z T y g o d n io w y L im itG o d z in ), w ysyłając k o m u n ik a t z a p is a n y w z m ie n n e j EmployeeHistoryRequest do o p e ra c ji Z a k t u a liz u jH is t o r ie te jże u słu g i. N a s tę p n a p o rc ja k o d u z w ią z a n a jest z d w o m a p o w ia d o m ie n ia m i, w y s y ła n y m i (o d p o w ie d n io ) do k ie ro w n ik a i p ra c o w n ik a za p o ś re d n ic tw e m usługi P o w ia d a m ia n ie . Przykład 16.28. Powiadomienia wysyłane przez proces < a s s ig n n a m e ="G etM a nag erID "> < to v a ria b le = "N o tific a tio n R e q u e s t" . . . / > < /a s s ig n > < i n v o k e n a m e = " W y s l i j P o w i a d o m i e n i e 10" p a rtn e rL in k = "P o w ia d a m ia n ie " p o rtT y p e = " n o t:N o tific a tio n In te rfa c e " o p e r a t i o n = " W y s l i j K o m u n i k a t 11" in p u tV a ria b le = "N o ti fic a tio n R e q u e s t" /> < a s s ig n n a m e = "G e tE m p lo ye e ID ">

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

< to v a ria b le = "N o tific a tio n R e q u e s t"

527

.../>

< /a s s ig n > < in v o k e n a m e = "W y s lijP o w ia d o m ie n ie " p a rtn e rL in k = "P o w ia d a m ia n ie " p o rtT y p e = " n o t:N o tific a tio n In te rfa c e " o p e ra tio n = " W y s lijK o m u n ik a t" in p u tV a ria b le = "N o ti fic a tio n R e q u e s t" /> < t e r m in a t e n a m e = "E n d T im e s h e e tS u b m is s io n P ro c e s s "/>

O b ie p a ry k o n s tru k c ji assign + invoke o d p o w ie d z ia ln e są z a w y w o ła n ie u s łu g i P o w ia d a ­ m ia n ie w celu w y s ła n ia p o w ia d o m ie n ia e -m a il do adresata określo n eg o p rz e z id e n ty fik a to r o s o b isty ( I D ) . W p ie rw s z y m p rz y p a d k u je s t to I D p rz e ło ż o n e g o , w d r u g im — I D p ra c o w n ik a , o b a o d c z y ta n e zo s ta ją ze z m ie n n e j ClientSubmission p rz e c h o w u ją c e j k a rtę czasu p ra c y . O s ta tn i z e le m e n tó w — term inate — o d p o w ie d z ia ln y je s t z a z a k o ń c z e n ie p rz e tw a rz a n ia w ra m a c h p rocesu.

K r o k 5. (o p c jo n a ln y ): d o s to s o w y w a n ie s c e n a riu s zy in te r a k c ji i o p ty m a liz o w a n ie d e fin ic ji p ro c e s u O s ta tn i, o p c jo n a ln y k r o k d e fin io w a n ia p ro c e s u o b e jm u je d w a z a d a n ia : z re w id o w a n ie s c e n a riu s zy z id e n ty fik o w a n y c h w k r o k u 1. i s p ra w d z e n ie d e fin ic ji W S -B P E L p o d k ą te m p o te n c ja ln y c h o p ty ­ m a liz a c ji. R o z p o c z n ijm y o d scenariuszy. D o sto so w u jąc je do ostatecznej d e fin ic ji W S -B P E L (d la k tó re j speł­ n iły ro lę m a te ria łu ź ró d ło w e g o ), o siągam y k ilk a k o rzyści W ś ró d n ic h w y m ie n ić n a le ży następujące. •

O d w z o ro w a n ia in te r a k c ji u s łu g , c zy to w fo r m ie d ia g ra m ó w , c zy ja k ie jk o lw ie k in n e j, r ó w n ie c z y te ln e j, s ta n o w ią is to tn ą część d o k u m e n ta c ji b u d o w a n e g o r o z w ią z a n ia , m a ją w ię c d u ż e z n a c z e n ie z p e rs p e k ty w y je g o p rz y s z łe g o ro z w o ju .

•

S cen ariu sze in te r a k c ji s ta n o w ią ce n n e ź ró d ło d la te s te ró w o p ra c o w u ją c y c h p rz y p a d k i testo w e, b o u w a ln ia ją ic h o d k o n ie c z n o ś c i p rz e p ro w a d z a n ia a n a liz y s p e k u la ty w n e j.

•

Im p le m e n to w a n ie o ry g in a ln e j lo g ik i p rz e p ły w u p ra c y ja k o s e rii a k ty w n o ś c i W S -B P E L m o ż e o b ja w ić k o n ie c zn o ś ć p o s z e rz e n ia lu b z m o d y fik o w a n ia tej lo g ik i. P o ró w n y w a n ie ty c h a k ty w n o ś c i z p ie r w o w z o r a m i, ja k im i są p rz e d m io to w e s c e n a riu s ze , m o ż e w y k a z a ć k o n ie c zn o ś ć z d e fin io w a n ia n o w y c h in te r a k c ji m ię d z y u s łu g a m i, co z k o le i p ro w a d z i do z id e n ty fik o w a n ia n o w y c h ty p ó w s y tu a c ji a w a ry jn y c h , o k tó r y c h obsługę w z b o g a c ić n a le ż y is tn ie ją c ą d e fin ic ję p rocesu .

W S -B P E L je s t ję z y k ie m b o g a ty m w m o ż liw o ś c i o p ty m a liz a c ji d e fin ic ji p ro c e s u , d z ię k i te m u te sam e o g ó ln e a k ty w n o ś c i m o ż n a s tru k tu ra liz o w a ć z a p o m o c ą ró ż n y c h podejść. D o s k o n a lą c d e fin ic ję p ro c e s u , m o ż e m y : •

o siągnąć z n a c z n ą p o p ra w ę w y d a jn o ś c i p o p rz e z k o n s o lid a c ję lu b re s tru k tu ry z a c ję z d e fin io w a n y c h a k ty w n o ś c i,

•

p o p ra w ić c zyte ln o ś ć i k la ro w n o ś ć k o d u ź ró d ło w e g o , k tó r y sta n ie się ła tw ie js z y w u trz y m a n iu ,

•

o d k ry ć d o d a tk o w e cec h y i m o ż liw o ś c i, k tó r y c h w c ze ś n ie j n ie b r a liś m y p o d u w ag ę.

528

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZO R IEN TO W A N E N A USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

ANALIZA PRZYPADKU A n a lity c y i a rc h ite k c i T L S , w e ry fik u ją c o ry g in a ln e d ia g ra m y a k ty w n o ś c i, s tw ie r d z ili, że o d ­ z w ie rc ie d la ją one d o k ła d n ie sposób w y m o d e lo w a n ia d e fin ic ji p rocesu w ję z y k u W S -B P E L i n ie m a k o n ie c z n o ś c i ic h m o d y fik o w a n ia . A n a liz a ta u w id o c z n iła je d n a k o k a zję do p e w n e j o p ty ­ m a liz a c ji, k tó ra zn aczą c o p o p ra w ić m o ż e w y d a jn o ś ć i s k ró c ić czas re a liz a c ji całego pro c e s u . Jak p a m ię ta m y , tr z e m a p o d s ta w o w y m i z a d a n ia m i P ro c e s u r o z lic z a n ia k a r t y c z a s u p ra c y są tr z y n as tęp u ją ce w e ry fik a c je : 1. p o ró w n a n ie lic z b y g o d z in n a fa k tu rz e i n a k a rc ie p ra c y , 2. s p ra w d z e n ie a u to ry z a c ji k a r ty czasu p ra c y , 3. s k o n fro n to w a n ie lic z b y g o d z in n a k a rc ie czasu p ra c y z ty g o d n io w y m lim it e m g o d z in d la p ra c o w n ik a . Jak p o k a z a n o n a ry s u n k u 1 6 .1 4 , w o b ecn ej im p le m e n ta c ji p ro c e s u z a d a n ia te w y k o n y w a ­ n e są s e k w e n c y jn ie , je d n o p o d ru g im — k o le jn e z a d a n ie n ie m o ż e się ro z p o c z ą ć p rz e d z a k o ń ­ c z e n ie m p o p rz e d n ie g o .

Rysunek 16.14. Sekwencyjna, synchroniczna realizacja aktywności procesu Sekw encyjne w y k o n y w a n ie za d a ń k o n ieczn e jest w ów czas, g d y m ię d z y za d a n ia m i w ystępują pew n e uzależnien ia. W naszym p rz y p a d k u u zależn ien ia takie n ie w ystępują, w ięc trz y w s p o m n ia n e za d a n ia m o ż n a zrealizow ać ró w no legle, ta k ja k n a ry s u n k u 16.15. Poszczególne zad an ia n ie m uszą n a siebie czekać, je d y n ie dalsza realizacja procesu m u s i poczekać, aż zakończą się wszystkie.

1 6 .3 . PRO JEK TO W A N IE PROCESU B IZN ESO W EG O Z O R IE N T O W A N E G O N A USŁUGI — KROK PO KROKU

529

Rysunek 16.15. Równoległa realizacja zadań w ramach przepływu

W języku WS-BPEL przepływ reprezentow any jest przez konstrukcję flow, stanowiącą kontrast dla elem entu sequence reprezentującego sekwencję. Dalsza analiza kodu procesu wykazała, iż podobne zrównoleglenie m ożna zastosować w odniesieniu do obsługi trzech różnych sytuacji wyjątkowych, jako że obsługa ta jest dla każdej sytuacji niezależna od pozostałych. Wreszcie, ponieważ dwa powiadamiania — kierownika i pracownika — są wywołaniami tej samej usługi P o w ia d a m ia n ie , można je zastąpić pętlą zagnieżdżającą element invoke.

PODSUMOW ANIE •

Projektow anie usługi procesowej to projektow anie jej interfejsu i definicji procesu.

•

D efiniow anie procesu w ykonyw ane jest zw ykle przy użyciu specjalizowanych narzędzi, mimo to znajom ość języka WS-BPEL jest pożądaną (a często konieczną) umiejętnością.

•

Definicje procesów WS-BPEL mogą być doskonalone i optym alizow ane na różne sposoby.

530

ROZDZIAŁ 16. ■ PROJEKTOWANIE ZORIENTOWANE NA USŁUGI (CZĘŚĆ IV. PROJEKTOWANIE PROCESU BIZNESOWEGO)

Rozdział 17

Podstawowe rozszerzenia WS-* 1 7.1. P o d s ta w y ję z y k a W S -A d d re s s in g 1 7.2. P o d s ta w y ję z y k a W S -R e lia b le M e s s a g in g 1 7.3. P o d s ta w y ję z y k a W S -P o lic y 1 7.4. P o d s ta w y ję z y k a W S -M e ta d a ta E x c h a n g e 1 7.5. P o d s ta w y ję z y k a W S -S e c u r ity

532

RO ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

P o z n a liś m y ju ż p o d s ta w o w e w a rs tw y i p o d w a rs tw y u s łu g ś ro d o w is k a z o rie n to w a n e g o n a u s łu g i, czas z a te m p rz y jrz e ć się d o d a tk o w y m ś ro d k o m w z b o g a c a n ia re p e rtu a ru cech S O A . W ty m r o z ­ d z ia le p rz e d s ta w ia m y p o d s ta w o w y , u k ie r u n k o w a n y s y n ta k ty c z n ie p r z e g lą d n a s tę p u ją c y c h k lu ­ c z o w y c h cech ro z s z e rz e ń W S -* : •

W S -A d d re s s in g ,

•

W S -R e lia b le M e s s a g in g ,

•

fra m e w o rk u W S -P o lic y ,

•

W S -M e ta d a ta E x c h a n g e ,

•

fra m e w o rk u W S -S e c u rity .

R o z d z ia ł te n je s t n ie ja k o b liź n ia c z y w s to s u n k u do r o z d z ia łu 7., b o o m a w ia n e ta m k o n c e p c je r o z p a try w a ć b ę d z ie m y te ra z w k a te g o ria c h im p le m e n ta c ji w r ó ż n y c h ję z y k a c h z n a c z n ik o w y c h , d e fin io w a n y c h p rz e z p o s zc zeg ó ln e s p ecyfikacje. m u s tU n d e r s t a n d G d y w ro z d z ia le 12. o p is y w a liś m y p o d s ta w o w e e le m e n ty p r o to k o łu S O A P , z w ró c iliś m y uw a g ę n a z n a c z e n ie a try b u tu m u s tU n d e rs ta n d . W ty m m ie js c u w a rto z a z n a c z y ć , że a tr y b u tu te g o m o ż n a u ż y w a ć w n a g łó w k a c h o p is y w a n y c h w ty m ro z d z ia le d la z a p e w n ie n ia , że o d u s łu g i o d b ie ra ją c e j k o m u n ik a t w y m a g a się p o tw ie r d z e n ia i p r z e tw o r z e n ia k lu c z o w y c h e le m e n tó w n a g łó w k a .

A n a liz y p rz y p a d k ó w : W ty m ro z d z ia le p r e z e n tu je m y szereg p rz y k ła d ó w k o d u ź ró d ło w e g o , o d p o w ia d a ją c e g o a n a liz o m p rz y p a d k ó w z r o z d z ia łu 7 ., z p o d r o z d z ia łó w 7 .1 , „ A d re s o w a n ie ”, 7 .2 , „ N ie z a w o d n e k o m u n ik o w a n ie ”, 7 .4 , „ Z a ło ż e n ia p o lit y k i” , 7 .5 , „ W y m ia n a m e ta d a n y c h ” i 7 .6 , „ B e zp ie cze ń s tw o ”. Z a s a d n ic zo , to co p o z n a w a liś m y w ro z d z ia le 7. o d s tro n y k o n c e p c y jn e j, w ty m ro z d z ia le oglądać b ę d z ie m y w p rz e ło ż e n iu n a k o n k re tn y k o d z n a c z n ik o w y .

17.1. Podstaw y języka W S-Addressing UW AGA

W tym rozdziale prezentujemy jedynie opisy elementów języka WS-Addressing, bo koncepcje kryjące się za tymi elementami omówiliśmy już w rozdziale 7.

W ię k s z o ś ć z n a n y c h im p le m e n ta c ji s p e c y fik a c ji W S -A d d re s s in g w y k o n u je s ta n d a ry z a c ję w o b ­ szarze lo k a liz a c ji p u n k tó w k o ń c o w y c h u sług i u n ik a to w y c h id e n ty fik a to r ó w k o re la c ji w ią żą c y c h p a ry o d p o w ia d a ją c y c h sobie k o m u n ik a tó w „ ż ą d a n ie -o d p o w ie d ź ”. D o s tę p n e są je d n a k ta k że in n e cechy u ła tw ia ją c e p ro je k to w a n ie w ysoce s a m o w y s ta rc za ln y c h k o m u n ik a tó w S O A P , m ię d z y in n y m i p u n k ty k o ń c o w e o d n o szące się do k o n k r e tn y c h in s ta n c ji usłu g s ie c io w y c h o ra z n a g łó w k i M I o p i­ sy w an e w p u n k c ie 7 .1 .2 .

1 7 .1 . P O D S TA W Y JĘZYKA W S -A D D R E S S IN G

533

W S -A d d re s s in g to je d n o z p o d s ta w o w y c h r o z s z e r z e ń W S - * d o s ta rc z a ją c e m e c h a n iz m ó w , w y ­ k o r z y s ty w a n y c h p r z e z in n e r o z s z e r z e n ia lu b p o z o s ta ją c y c h z z w ią z k u z t y m i r o z s z e r z e n ia m i. Jego p o w ią z a n ia z i n n y m i r o z s z e r z e n ia m i p r z e d s ta w iliś m y n a r y s u n k u 1 7 .1 .

Rysunek 17.1. Związek WS-Addressing z innymi rozszerzeniami WS-* opisywanymi w tym rozdziale

17.1.1. Element EndpointReference E le m e n t E n d p o in tR e fe r e n c e w y k o r z y s ty w a n y je s t p r z e z e le m e n ty From, R e p ly T o i F a u ltT o o p is y ­ w a n e w p u n k c ie 1 7 .1 .2 p o ś w ię c o n y m n a g łó w k o m M I . M o ż e z a g n ie ż d ż a ć g r u p ę e le m e n t ó w u d o ­ s tę p n ia ją c y c h in f o r m a c ję o in t e r fe js ie u s łu g i ( i u z u p e łn ia ją c y c h m e t a d a n y c h ) o r a z u m o ż li w i a ją ­ c y c h id e n t y f ik o w a n ie p o s z c z e g ó ln y c h in s ta n c ji u s łu g . W t a b e li 1 7 .1 p r z e d s t a w ia m y o p is y e le m e n t ó w W S -A d d re s s in g , k t ó r e m o g ą b y ć k o ja r z o n e z k o n s t r u k c ją E n d p o in tR e fe r e n c e .

534

R O ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

Tabela 17.1. Elementy WS-Addressing związane z odwoływaniem się do punktów końcowych E le m en t Address

Znaczenie Standardow y elem ent W S-Addressing używ any do specyfikowania adresu usługi. Jest to jedyny obow iązkow y elem ent p o to m n y konstrukcji EndpointReference.

R e fere n ce P ro p e rtie s

K onstrukcja m ogąca zagnieżdżać szereg elem en tó w p o to m n y c h reprezentujących szczegóły w łaściw ości zw iązanych z instancją usługi.

R eferenceParam eters

K onstrukcja m ogąca zagnieżdżać szereg elem en tó w p o to m n y c h reprezentujących w artości p a ram etró w w k o m u n ik acji z instancją usługi.

PortType

N azw a ele m en tu portType w definicji usługi.

ServiceName i PortName

N azw y elem entów (odpow iednio) se rv i ce i p o rt w k o n stru k c ji d e f i n i t i ons w definicji W SD L u sługi docelowej.

Poli cy

T en elem en t um ożliw ia w iązanie z p o d m io ta m i asercji p olityki WS-Policy.

A N A LIZA PRZYPADKU O t o p r o s ta k o n s t r u k c ja E n d p o in tR e fe r e n c e w y r a ż a ją c a in f o r m a c ję s p e c y fic z n ą d la k o n k r e t n e j in s ta n c ji u s łu g i P ła tn o ś ć n a k o n t o f i r m y R a ilC o . Z w r ó ć m y u w a g ę n a s p e c y fic z n e d la a p lik a c ji e le m e n t y p o t o m n e w r a m a c h k o n s t r u k c ji R e f e r e n c e P r o p e r t ie s i R e fe r e n c e P a r a m e te r s . Przykład 17.1. Przykładowa konstrukcja EndpointReference, wyodrębniona z nagłówka SOAP h ttp ://w w w .x m ltc .c o m /ra ilc Q /. . . < /w sa: Address > unn:AFJK323llws < /app:id> < /w sa : ReferenceProperties > 22322447 < /app:sesno> < /w sa : ReferenceParameters > < /w sa : EndpointReference > U m ie js c o w ie n ie p o w y ż s z e j k o n s tr u k c ji w n a g łó w k u S O A P p o k a ż e m y w n a s tę p n y m p r z y k ła d z ie .

17.1.2. Elementy nagłówka reprezentujące informację o komunikatach (MI) E le m e n ty z k o le k c ji M I (o p is y w a n e j w p u n k c ie 7 .1 .2 ) m o g ą b y ć w y k o r z y s t y w a n e n a w ie le r ó ż n y c h s p o s o b ó w d o w y p o s a ż a n ia n a g łó w k ó w S O A P w o b s z e rn e m e ta d a n e . W t a b e li 1 7 .2 z a m ie s z c z a m y k r ó t k i o p is ty c h e le m e n tó w .

1 7 .1 . P O D S TA W Y JĘZYKA W S -A D D R E S S IN G

535

Tabela 17.2. Elementy grupy MI specyfikacji WS-Addressing E le m en t

Znaczenie

MessageID

Przechow uje u n ik ato w y id en ty fik ato r k o m u n ik a tu , najczęściej n a p o trze b y korelacji. E lem ent te n jest w ym agany, jeżeli w n agłów ku używ ane są elem enty ReplyTo lub FaultTo.

R elatesTo

E lem ent korelacyjny, jaw nie w iążący bieżący k o m u n ik a t z in n y m ko m u n ik atem . Jego obecność jest obow iązkow a w k o m u n ik acie stanow iącym odpow iedź n a żądanie.

ReplyTo

R eprezentuje p u n k t k o ńcow y (jako odw ołanie do ele m en tu E ndpointReference), do k tórego należy w ysłać k o m u n ik a t stanow iący odpow iedź n a otrzym ane żądanie. T en elem en t w ym aga obecności ele m en tu MessageID w nagłów ku.

From

R eprezentuje źródłow y p u n k t k o ńcow y (jako odw ołanie do ele m en tu E ndpointReference) p rzenoszący w k o m u n ik acie adres tego p u n k tu .

Faul tTo

R eprezentuje p u n k t k o ńcow y (jako odw ołanie do ele m en tu E ndpointReference) w ykorzystyw any do w skazania, do którego p u n k tu końcow ego należy w ysłać k o m u n ik a t stanow iący pow iad o m ien ie o sytuacji aw aryjnej. T en elem en t w ym aga obecności ele m en tu MessageID w nagłów ku.

To

W skazuje adres p u n k tu końcow ego, do którego należy dostarczyć bieżący k o m u n ik at.

Acti on

Z aw iera URI reprezentujący akcję, jaką należy w ykonać w zw iązku z przetw arzan iem nagłów ka M I.

W p o n iż s ze j a n a liz ie p rz y p a d k u w id z im y p r z y k ła d k o p e r ty S O A P z a w ie ra ją c e j b lo k n a g łó w ­ k o w y z ło ż o n y z d w ó c h e le m e n tó w M I .

A N A LIZA PRZYPADKU

N a ry s u n k u 7 .6 , w p u n k c ie 7 .1 .4 p rz e d s ta w iliś m y p rz y k ła d w y m ia n y k o m u n ik a tó w m ię d z y in s ta n c ja m i u słu g T L S P ła tn o ś ć n a k o n t o i P r o f ile d o s ta w c ó w z u ż y c ie m p u l u sług. P o n iż e j p rz e d s ta w ia m y p ró b k ę je d n e g o z ta k ic h k o m u n ik a tó w — e le m e n ty From, R eplyTo i F a u ltT o z a w ie ra ją o d w o ła n ia do p u n k tó w k o ń c o w y c h o ró ż n y c h adresach. Przykład 17.2. Nagłówek SOAP zawierający elementy grupy MI, z których trzy zawierają odwołania do punktów końcowych

h ttp ://w w w .x m ltc.c o m /tls/v p /su b m it < /w sa: A ction > h ttp ://w w w .x m ltc .c o m /tls /v p /. . . < /w sa: To>
536

RO ZD ZIAŁ 1 7 . a P O D S T A W O W E ROZSZERZENIA W S -*

< w sa:R eferenceP roperties> unn:AFJK323llws < /app:id> < /w sa:R eferen ceP ro p erties> 22322447 < /app:sesno> < /w sa : From> uuid:243234234-43gf433 < /w sa: MessageID> h ttp ://w w w .x m ltc .c o m /ra ilc o /a p 2 / < w sa:R eferenceP roperties> unn:AFJK323llws < /app:id> < /w sa:R eferen ceP ro p erties> 22322447 < /app:sesno> < /w sa : ReplyTo > h ttp ://w w w .x m ltc .c o m /ra ilc o /a p - e r r / < w sa:R eferenceP roperties> unn:AFJK323llws < /app:id> < /w sa:R eferen ceP ro p erties> 22322447 < /app:sesno> < /w sa : FaultTo >

U ż y ty w p o w yższy m p rz y k ła d z ie e le m e n t Address w y w o d z i się ze specyfikacji W S -A d d re s s in g (p a trz tabela 7 .1 ), n ie ze schem atu u żytko w eg o specyfikacji W S -C o o rd in a tio n , w yko rzystyw an eg o w p rz y k ła d a c h ro z d z ia łu 16.

1 7 .1 . P O D S TA W Y JĘZYKA W S -A D D R E S S IN G

537

17.1.3. Wielokrotne wykorzystywanie WS-Addressing M e c h a n iz m y id e n ty f ik o w a n ia p u n k t ó w k o ń c o w y c h i tr a s o w a n ia k o m u n ik a t ó w d e fin io w a n e w sp ecyfikacji W S -A d d re s s in g tw o rz ą g e n e ry c z n y z b ió r ro zs ze rze ń u ż y te c z n y c h n ie ty lk o d la n o w o tw o rz o n y c h ro z w ią z a ń , lecz ta k że d la w ie lu in n y c h specy fik a c ji W S - * . S p ecyfikacja W S -A d d re s s in g m o ż e w ię c b y ć u w a ż a n a z a ró w n o z a spe c y fik a c ję w ie lo u ż y w a ln ą , ja k i spe c y fik a c ję u ż y tk o w ą sta­ n o w ią c ą w s p a rc ie d la k o m p o n o w a ln o ś c i n a g ru n c ie S O A . C h o c ia ż w ty m ro zd zia le n ie b ę d z ie m y o m a w ia ć szczegółów ję z y k ó w specyfikacji W S -N o tific a tio n a n i W S -E v e n tin g , p rz e d s ta w im y p ro s te p r z y k ła d y za s to s o w a n ia ic h b lo k ó w n a g łó w k o w y c h w celu ilu s tra c ji, ja k e le m e n ty ję z y k a W S -A d d re s s in g d o s ta rc za ją w s p a rc ia d la in n y c h ro z s ze rz e ń W S - * .

ANALIZA PRZYPADKU

N a ry s u n k u 7.42, w ra m a c h a n a liz y p rz y p a d k u , w id z im y realizację m o d e lu p u b lik u j-s u b s k ry b u j, g d zie usługa R a ilC o S u b s k ry p c ja T L S jest a b o n e n te m s u b s k ry p c ji o rg a n iz o w a n e j p rz e z usługę T L S P o w ia d a m ia n ie n a b a z ie s p e c y fik a c ji W S - N o tific a tio n . K o n s tru k c ja H eader ja k o fiz y c z n a re p re z e n ta c ja n a g łó w k a S O A P k o m u n ik a tu - p o w ia d o m ie n ia m o g ła b y m ie ć p o s ta ć ta k ą , ja k w p r z y k ła d z ie 17.3. Przykład 17.3. Prosty nagłówek komunikatu-powiadomienia SOAP zgodnego z WS-Notification

http://w w w .ibm .com /xm lns/stdw ip/w eb-services/W S-B aseN otifi c a tio n /N o tify < /w sa: Action > h ttp ://w w w .x m ltc.c o m /tls/e n d p o in t1 < /w sa: To>

. . . Szczegóły su b sk ry p cji i powiadomienia . . .

G d y b y w y b ra n o W S - E v e n tin g ja k o fr a m e w o r k k o m u n ik a c y jn y , n a g łó w e k k o m u n ik a tu p o w ia d o m ie n ia w y g lą d a łb y p ra w d o p o d o b n ie ta k , ja k p o n iż e j. Przykład 17.4. Prosty nagłówek komunikatu-powiadomienia SOAP zgodnego z WS-Eventing

http://w w w .exam ple.org/oceanw atch/2003/W indR eport < /w sa: Action > uuid:568b4ff2-5bc1-4512-957c-0fa545fd8d7f < /w sa: MessageID > http://w w w .other.exam ple.com /O nStorm W arning < /w sa: To> . . . Sczegóły su b sk ry p cji . . .

...



Szc zegóły powiadomienia . . .

538

RO ZD ZIAŁ 1 7 . a P O D S T A W O W E ROZSZERZENIA W S -*

W o b u p rz y k ła d a c h w y r ó ż n iliś m y e le m e n ty z a c z e rp n ię te ze s p e c y fik a c ji W S -A d d re s s in g . Z a u w a ż m y , że w k o m u n ik a c ie z g o d n y m z fr a m e w o r k ie m W S - E v e n tin g in fo r m a c ja o s u b ­ s k ry p c ji lo k o w a n a jest w n a g łó w k u , a treść p o w ia d o m ie n ia — w ciele tego k o m u n ik a tu . W k o ­ m u n ik a c ie zaś z g o d n y m z fr a m e w o r k ie m W S - N o tific a tio n o b ie te p o rc je in fo r m a c ji u m ie s z ­ czan e są w ciele.

P rz y k ła d y 17.3 i 17.4 s ta n o w ią św ia d e c tw o tego, że specyfikacje W S - N o tific a tio n i W S -E v e n tin g , u s ta n a w ia ją c e w zasad zie te n s a m m o d e l k o m u n ik a c ji p r z y u ż y c iu d w ó c h ró ż n y c h po d ejść, b a z u ją n a s p e c y fik a c ji W S - A d d r e s s in g w k w e s tii s tr u k tu r a liz a c ji n a g łó w k ó w S O A P . S ta n o w i to k o le jn y p rz e ja w d ą ż e ń do w y k o rz y s ty w a n ia s ta n d a rd ó w o tw a rty c h i p o w s z e c h n ie a k c e p to w a n y c h . Z re s z tą — k a ż d a z p o z o s ta ły c h s p e c y fik a c ji o p is y w a n y c h w ty m r o z d z ia le ta k ż e w y k o rz y s tu je e le m e n ty n a g łó w k a S O A P u s ta n a w ia n e p rz e z s p e c y fik a c ję W S -A d d re s s in g . P O D S U M O W A N IE

•

Język WS-Addressing oferuje kolekcję elementów nagłówka SOAP uzupełniających jego treść o rozmaite metadane, związane przeważnie z trasowaniem.

•

Specyfikacja WS-Addressing definiuje zbiór wieloużywalnych rozszerzeń, stanowiących organiczne elementy innych specyfikacji WS-*.

•

Warto zapamiętać, że niektóre z elementów MI nagłówka SOAP, definiowane przez WS-Addressing, zawierają de facto odwołania do punktów końcowych w postaci elementu E n d p o in tR e fe re n c e , mogą więc także zawierać rozmaite metadane związane z poszczególnymi punktami końcowymi.

17.2. Podstaw y języka W S-ReliableM essaging UW AGA

W tym rozdziale prezentujemy jedynie opisy elementów języka WS-ReliableMessaging, bo koncepcje kryjące się za tymi elementami omówiliśmy już w rozdziale 7.

S p e c y fik a c ja W S -R e lia b le M e s s a g in g k re u je w a ż n ą cechę, k ry ty c z n ą d la ja k o ś c i u s łu g — g w a ­ ra n c ję alb o d o s ta rc z e n ia k o m u n ik a tu do m ie js c a p rz e z n a c z e n ia , alb o p o w ia d o m ie n ia n a d a w c y , że o k a za ło się to n ie m o ż liw e . C e c h a ta p o z y c jo n u je W S -R e lia b le M e s s a g in g w g ro n ie fu n d a m e n ta ln y c h ro z s z e rz e ń W S - * , co p o k a z a liś m y ju ż n a r y s u n k u 17.2. G d y w y m ia n a k o m u n ik a tó w o d b y w a się n a g ru n c ie fr a m e w o r k u k o m u n ik a c y jn e g o zg o d n e g o z W S -R e lia b le M e s s a g in g , k o n c e p c je s e k w e n c jo n o w a n ia i p o tw ie r d z a n ia n a b ie ra ją d o n io s łe g o z n a ­ c ze n ia d la k a żd e g o tra n s m ito w a n e g o k o m u n ik a tu . W k o le jn y c h p u n k ta c h o p is z e m y za c h w ilę n a s tę p u ją ce k lu c z o w e e le m e n ty ję z y k a W S -R e lia b le ^ M e s s a g in g : •

Sequence,

•

M essageN um ber ,

1 7 .2 . P O D S TA W Y JĘZYKA W S-R ELIA B LEM ESSA G IN G

539

Rysunek 17.2. Relacje specyfikacji WS-ReliableMessaging z innymi rozszerzeniami WS-* opisywanymi w tym rozdziale •

L a s tM e s s a g e ,

•

S e q u e n c e A c k n o w le d g e m e n t,

•

A ck n o w led g em e n tR an g e ,

•

N ac k ,

•

A c k R e q u e s te d .

U z u p e łn i e n ie m te g o o p is u b ę d z ie k r ó t k a lis ta r e fe r e n c y jn a n a s tę p u ją c y c h e le m e n t ó w i a s e rc ji: S eq u e n c e R e f, A c k n o w le d g e m e n tIn te r v a l, B a s e R e tr a n s m is s io n In t e r v a l, I n a c t iv it y T i m e o u t , E x p ir e s i S e q u e n c e C r e a tio n .

17.2.1. Elementy Sequence, MessageNumber i LastMessage J a k ju ż w y ja ś n ia liś m y w r o z d z ia le 7 ., f r a m e w o r k W S -R e lia b le M e s s a g in g g w a r a n tu je d o s ta r c z e n ie k o m u n i k a t ó w w o k r e ś lo n e j, p r e d e f in io w a n e j k o le jn o ś c i. K o n s t r u k c ja S e q u e n c e r e z y d u je w n a ­ g łó w k u k o m u n ik a t u S O A P , r e p r e z e n tu ją c lo k a liz a c ję b ie ż ą c e g o k o m u n ik a t u w r e la c ji d o c a łe j se­ k w e n c ji, k tó r e j k o m u n ik a t t e n je s t czę ś c ią .

540

RO ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

D o s p e łn ie n ia s w e j f u n k c ji k o n s t r u k c ja S eq u en c e w y k o r z y s tu je s z e re g z a g n ie ż d ż o n y c h e le ­ m e n t ó w p o to m n y c h — e le m e n t I d e n t i f i e r p rz e c h o w u je w a rto ś ć id e n ty fik a to r a ( I D ) ca łej s e k w e n c ji, p o d c z a s g d y e le m e n t M essageN um ber z a w ie r a lic z b ę o k re ś la ją c ą p o z y c ję k o m u n ik a t u w s e k w e n c ji. O b e c n o ś ć e le m e n tu L a s tM e s s a g e w e w n ą t r z k o n s t r u k c ji S eq u en c e o z n a c z a , że b ie ż ą c y k o m u n ik a t je s t o s ta tn i w s e k w e n c ji.

ANALIZA PRZYPADKU P o d k o n ie c p o d r o z d z ia łu 7 .2 w r a m a c h a n a liz y p r z y p a d k u ( p a t r z r y s u n e k 7 .1 7 ) o p is y w a liś m y s y tu a c ję , k ie d y T L S z a ż ą d a ła o d R a ilC o d o s ta r c z a n ia f a k t u r w tr y b ie w s a d o w y m , w p o s ta c i s e k w e n c ji z g o d n y c h ze s p e c y fik a c ją W S -R e lia b le M e s s a g in g . P r e z e n t o w a n y p o n iż e j p r a w d o p o d o b n y k o m u n ik a t S O A P b ę d ą c y c z ę ś c ią te j w y m i a n y z a w ie r a n a g łó w e k in f o r m u ją c y o t y m , iż je s t o s ta t n im k o m u n ik a t e m w s e k w e n c ji. Przykład 17.5. Konstrukcja Sequence zawierająca element LastMessage wskazujący, iż bieżący komunikat jest ostatni w sekwencji

< w su :Id e n tifie r> h ttp ://w w w .x m ltc .c o m /ra ilco/seq22231 < /w s u :Id e n tifie r> 12

17.2.2. Elementy SequenceAcknowledgement i AcknowledgementRange P o o d e b r a n iu je d n e g o lu b w ie lu k o m u n ik a t ó w w c h o d z ą c y c h w s k ła d s e k w e n c ji u s łu g a -o d b io r c a m o ż e w y s ła ć k o m u n ik a t z a w ie r a ją c y w n a g łó w k u k o n s tr u k c ję S eq uenceA cknow ledg em ent w c e lu p o ­ in f o r m o w a n ia n a d a w c y , że d o s ta r c z e n ie o k re ś lo n e j s e r ii k o m u n ik a t ó w się p o w io d ło . K o n s tr u k c ja t a z a w ie r a e le m e n t I d e n t i f i e r id e n t y f ik u ją c y s e k w e n c ję o r a z e le m e n ty o k re ś la ją c e , k tó r y c h k o ­ m u n ik a t ó w p o t w ie r d z e n ie d o ty c z y . T ę d r u g ą ro lę p e łn ią e le m e n ty Acknow ledgem entR ange; k a ż d y z n ic h o k re ś la za k re s n u m e r ó w k o ­ m u n ik a t ó w w r a m a c h s e k w e n c ji: w a rto ś c i a t r y b u tó w Low er i U pper o k re ś la ją ( o d p o w ie d n io ) n a jm n ie j­ s z y i n a jw ię k s z y ze w s p o m n ia n y c h n u m e r ó w . U ż y w a ją c k i lk u e le m e n t ó w A ck n o w led g em e n tR an g e , m o ż e m y s p e c y fik o w a ć z b ió r n u m e r ó w s ta n o w ią c y s u m ę ( te o r io m n o g o ś c io w ą ) k i lk u z a k r e s ó w . N u m e r y n ie n a le ż ą c e d o te g o z b io r u id e n t y f ik u ją k o m u n ik a t y , k t ó r e n ie z o s ta ją p o tw ie r d z o n e .

1 7 .2 . P O D S TA W Y JĘZYKA W S -R ELIA B LEM E SSA G IN G

541

Je śli je s t to n ie c o s k o m p l ik o w a n e , z p e w n o ś c ią s ta n ie s ię ja s n e p o p r z e s t u d io w a n iu p r z y ­ k ł a d u 1 7 .6 .

ANALIZA PRZYPADKU P o n iż s z y p r z y k ła d p r z e d s ta w ia n a g łó w e k k o m u n ik a t u , w y s ła n e g o p r z e z T L S d o R a ilC o ja k o p o t w ie r d z e n ie d o ty c z ą c e tr a n s m is ji s e r ii f a k t u r ( w k o m u n ik a t a c h t w o r z ą c y c h s e k w e n c ję ). Przykład 17.6. Konstrukcja SequenceAcknowledgement potwierdzająca odebranie 11 spośród 15 komunikatów

< w su :Id e n tifie r> http://w w w .x m ltc.co m /tls/seq 2 2 2 3 1 < /w s u :Id e n tifie r>

N ie w ą t p liw ie s e r y jn a tr a n s m is ja n ie w y p a d ła z b y t d o b r z e : z a m ia s t 15 w y s ła n y c h k o m u n i ­ k a t ó w d o T L S d o ta r ło t y lk o 11 — z w y s ła n e g o p r z e z T L S p o t w ie r d z e n ia w y n ik a , iż są to k o ­ m u n ik a t y o n u m e r a c h z z a k r e s ó w •

1 - 4,

•

6 - 8,

•

11 - 12 ,

•

1 4 - 15 ,

a z a t e m k o m u n ik a t y o n u m e r a c h 5, 9 , 10 i 13 n ie d o t a r ły d o T L S .

17.2.3. Element Nack N ie d o s ta r c z e n ie k o m u n ik a t u m o ż e z o s ta ć z a s y g n a liz o w a n e ta k ż e w i n n y s p o s ó b — z a p o m o c ą e le m e n tu N ack (to s k r ó t o d n e g a tiv e a c k n o w le d g e m e n t — p o t w ie r d z e n ie n e g a t y w n e ) . E le m e n t te n s p e c y fik u je p o je d y n c z y n u m e r k o m u n ik a t u , s y g n a liz u ją c z a g u b ie n ie te g o k o m u n ik a t u .

542

RO ZD ZIAŁ 1 7 . a P O D S T A W O W E ROZSZERZENIA W S -*

A N A LIZA PRZYPADKU

P o n iż s z y p r z y k ła d ilu s tru je s y g n a liza c ję p rz e z T L S n ie o tr z y m a n ia k o m u n ik a tu o n u m e rz e 5. Przykład 17.7. Konstrukcja SequenceAcknowledgement zawierająca element Nack sygnalizujący nieotrzymanie 5. komunikatu

< w su :Id e n tifie r> http://w w w .x m ltc.co m /tls/seq 2 2 2 3 1 < /w s u :Id e n tifie r> 5

17.2.4. Element AckRequested P rz e z n a c z e n ie R M (p a tr z p u n k t 7 .2 .1 ) w y s y ła z w y k le k o m u n ik a ty S O A P z n a g łó w k ie m S e q u e n c e A ck n o w led g em e n t w p re d e fin io w a n y c h m o m e n ta c h , n a p r z y k ła d po o d e b ra n iu k o m u n ik a tu z a w ie ­

ra ją c e g o e le m e n t L a s tM e s s a g e . Ź r ó d ło R M m o ż e je d n a k ż ą d a ć o d p rz e z n a c z e n ia R M d o d a tk o ­ w y c h p o tw ie rd z e ń , w y s y ła ją c k o m u n ik a t z k o n s tru k c ją A c k R e q u e s te d w n a g łó w k u . K o n s tru k c ja ta z a w ie r a p o p ro s tu e le m e n t I d e n t i f i e r id e n ty fik u ją c y s e k w e n c ję , w s to s u n k u do k tó re j ż ą d a się p o tw ie r d z e n ia . M o ż e o n a ta k ż e z a w ie ra ć e le m e n t M e ssag eN u m b er w s k a z u ją c y n u m e r k o m u n ik a tu , k tó re g o d o s ta rc z e n ie m ź r ó d ło R M je s t z a in te re s o w a n e n a jb a rd z ie j.

A N A LIZA PRZYPADKU

R a ilC o p o n ie z b y t u d a n e j p r ó b ie s e ry jn e j tr a n s m is ji fa k tu r p o s ta n o w iło ty m ra z e m ż ą d a ć p o tw ie rd z e n ia o d T L S p rz e d w y s ła n ie m o s ta tn ie g o k o m u n ik a tu z s e k w e n c ji, a k o n k r e tn ie — w ys y łać ż ą d a n ie p o tw ie r d z a n ia co d ru g ie g o k o m u n ik a tu z fa k tu rą . Przykład 17.8. Konstrukcja AckRequested sygnalizująca żądanie przez źródło RM potwierdzenia otrzymania przez przeznaczenie RM wysłanych dotychczas komunikatów

1 7 .2 . P O D S TA W Y JĘZYKA W S-R ELIA B LEM ESSA G IN G

543

< w su :Id e n tifie r> http://w w w .x m ltc.co m /tls/seq 2 2 2 3 2 < /w s u :Id e n tifie r>

17.2.5. Pozostałe elementy WS-ReliableMessaging W ta b e li 17.3 p rz e d s ta w ia m y k r ó t k i o p is in n y c h e le m e n tó w ję z y k a W S -R e lia b le M e s s a g in g . Tabela 17.3. Dodatkowe elementy języka WS-ReliableMessaging E le m en t

Znaczenie

SequenceRef

U m ożliw ia pow iązanie asercji polityki z sekwencją, co daje m ożliw ość definiow ania dodatkow ych reguł dostarczania k om u n ik ató w , n a p rzy k ład zapew nień dostarczenia opisyw anych w p u n k c ie 7.2.4.

AcknowledgementInterval

Specyfikuje odstęp czasow y określający częstotliw ość autom atycznego w ysyłania p o tw ierd z eń p rz ez przeznaczenie RM.

B aseR etransm issionInterval

O dstęp czasowy, po k tó ry m ź ródło RM w ykonyw ać będzie retransm isję ko m u n ik ató w , k tó ry ch dostarczenie nie zostało potw ierdzone.

In a ctiv ity T im eo u t

O kreśla długość m aksym alnej przerw y m iędzy tran sm isją dw óch kolejnych k o m u n ik a tó w w sekwencji; p o p rzek ro c ze n iu tej długości sekw encja zostaje u z n an a za nieaktualną.

E xpires

O kreśla gran iczn ą datę i czas, p o której sekw encja u z n an a zostanie za n ieaktualną.

SequenceC reation

Sekw encje g eneralnie k reow ane są p rz ez ź ró d ła RM, jednakże p rzeznaczenie RM m oże w ykorzystyw ać ten elem en t do generow ania w łasnych sekwencji.

P O D S U M O W A N IE

•

W S-ReliableMessaging w prow adza szereg elem entów zarządzających sekwencjami komunikatów i potwierdzeniami ich dostarczania.

•

W S-R eiiabieM essaging implementuje koncepcję sekwencji komunikatów w postaci konstrukcji S eq u en ce. Konstrukcja ta reprezentuje grupę komunikatów, w stosunku do których określane są dodatkow e reguły dostarczania.

•

W S-R eliableM essagingim plem entuje koncepcję potwierdzenia dostarczenia komunikatów lub ich niedostarczenia za pomocą elem entów S equenceA ckow ledgem ent i Nack, realizując w ten sposób wymóg powiadam iania nadawcy o losach wysyłanych komunikatów.

544

RO ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

17.3. Podstaw y języka W S-Policy UWAGA

W tym rozdziale prezentujemy jedynie opisy elementów języka WS-Policy, bo koncepcje kryjące się za tymi elementami omówiliśmy już w rozdziale 7.

F ra m e w o rk W S -P o lic y d o s ta rc za ś ro d k i do w y ra ż a n ia m e ta d a n y c h w z a k re s ie w y k ra c z a ją c y m p o z a m o ż liw o ś c i d e fin ic ji W S D L . U m o ż liw ia u s łu g o m k o m u n ik o w a n ie re g u ł i p re fe re n c ji d o ty ­ czących b e z p ie c z e ń s tw a , p rz e tw a rz a n ia i tre ś c i k o m u n ik a tó w . R e g u ły (z w a n e p o p u la rn ie p o lit y ­ k a m i lu b z a ło ż e n ia m i p o lit y k i — p o lic ie s ) m o g ą b y ć s to so w an e do w ie lu ró ż n y c h z a s o b ó w sieci W W W , co p o z y c jo n u je specyfikację W S -P o lic y ja k o k o le jn ą fu n d a m e n ta ln ą część ro zs ze rze ń W S - * d y s k u to w a n y c h w ty m ro z d z ia le (p a trz ry s u n e k 17.3).

WS-Reliable Messaging

WS-Addressing

Określają zapewnienia dostarczenia dla sekwencji definiowanych przez

Umożliwiają specyfikowanie zapewi dla punktów końcowy definiowanych prze

Umożliwiają wyrażanie wymagań bezpieczeństwa i innych reguł dla

Usługi sieciowe

WS-Metadata Exchange

Umożliwiają wyszukiwanie założeń polityki definiowanych przez

WS-Security

Dostarcza frameworku asercji polityki dla*

Umożliwiają definiowanie wym agań dla żądań

Komunikaty SOAP

* Oddzielna specyfikacja WS-SecurityPolicy dostarcza zbioru predefiniowanych asercji polityki dla WS-Security

Rysunek 17.3. Związek WS-Policy z innymi rozszerzeniami WS-* opisywanymi w tym rozdziale

1 7 .3 . P O D S TA W Y JĘZYKA W S-PO LIC Y

545

F r a m e w o r k W S -P o lic y s k ła d a się z t r z e c h n a s tę p u ją c y c h s p e c y fik a c ji: •

W S -P o lic y ,

•

W S -P o lic y A s s e rtio n s ,

•

W S - P o lic y A tta c h m e n ts .

W y m ie n io n e s p e c y fik a c je d e f in iu ją e le m e n t y o p is y w a n e w t y m p o d r o z d z ia le . P o k a ż e m y , ja k z a ło ż e n ia p o lit y k i są f o r m u ło w a n e i d o łą c z a n e n a p o z io m ie e le m e n tó w lu b d o k u m e n t ó w , ta k ic h ja k : •

e le m e n t P o lic y ,

•

a s e rc je T e x tE n c o d in g , L an g u ag e, S p e c V e rs io n i M e s s a g e P r e d ic a te ,

•

e le m e n t E x a c tly O n e ,

•

e le m e n t A l l ,

•

a t r y b u t y U sage i P r e fe r e n c e ,

•

e le m e n t P o lic y R e f e r e n c e ,

•

a t r y b u t P o lic y U R Is ,

•

e le m e n t P o lic y A tt a c h m e n t.

17.3.1. Element Policy i podstawowe asercje polityki E le m e n t P o li c y to k o n s tr u k c ja n a jw y ż s z e g o p o z io m u ( „ k o r z e ń ” ) h o s tu ją c a r o z m a it e a s e rc je p o ­ lit y k i s k ła d a ją c e się o g ó ln ie n a z a ło ż e n ia p o lit y k i. S p e c y fik a c ja W S -P o lic y A s s e rtio n s o fe r u je z b ió r n a s tę p u ją c y c h p r e d e f in io w a n y c h e le m e n t ó w a s e rc ji: •

T e x tE n c o d in g — w y m u s z a u ż y c ie s p e c y fic z n e g o f o r m a t u k o d o w a n ia te k s tu ,

•

Languag e — w y r a ż a w y m a g a n ia lu b p r e fe r e n c je z w ią z a n e z k o n k r e t n y m ję z y k ie m ,

•

S p e c V e rs io n — k o m u n ik u je z a p o tr z e b o w a n ie n a k o n k r e t n ą w e r s ję s p e c y fik a c ji,

•

M e s s a g e P r e d ic a te — o k re ś la r e g u ły p r z e t w a r z a n ia k o m u n ik a t u z a p o m o c ą in s t r u k c ji

X P a th . P o w y ż s z e e le m e n t y r e p r e z e n tu ją a s e rc je u m o ż liw ia ją c e s tr u k tu r a liz a c ję p o d s ta w o w y c h z a ło ­ ż e ń p o li t y k i d o ty c z ą c y c h p o w s z e c h n y c h w y m a g a ń . Z a ło ż e n ia p o li t y k i m o g ą b y ć ta k ż e k o n f ig u r o ­ w a n e , p o n a d to in n e s p e c y fik a c je W S - * m o g ą d o s ta r c z a ć d o d a tk o w e a s e rc je . D la k a ż d e j a s e rc ji m o ż liw e je s t o k re ś le n ie , c z y je s t b e z w z g lę d n ie o b o w ią z u ją c a , c z y te ż o p c jo ­ n a ln a : s łu ż y d o te g o a t r y b u t U sage — w a r to ś ć " R e q u ir e d " o z n a c z a b e z w z g lę d n y w y m ó g . P o n a d to a tr y b u t P r e fe r e n c e u m o ż liw ia o k re ś le n ie w z g lę d n e g o p o z io m u is to tn o ś c i d a n e j a s e rc ji w s to s u n k u d o in n y c h a s e rc ji te g o s a m e g o ty p u . W k o le jn y c h p u n k t a c h p r z e d s t a w im y p r z y k ła d y r ó ż n y c h a s e rc ji p o lit y k i.

17.3.2. Element ExactlyOne W te j k o n s t r u k c ji m o ż n a z a g n ie ź d z ić s z e re g a s e rc ji, a je j z a s to s o w a n ie o z n a c z a w y m ó g d o k o n a n ia w y b o r u d o k ła d n ie je d n e j z n ic h .

546

RO ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

ANALIZA PRZYPADKU

Jak w y ja ś n ia liś m y w a n a liz ie p rz y p a d k u w ie ń c zą c e j p o d r o z d z ia ł 7 .4 , w f ir m ie T L S o p ra c o w a ­ n o z a ło ż e n ia p o lity k i d ające p a rtn e rs k im u s łu g o m -w n io s k o d a w c o m w y b ó r m ię d z y d w ie m a w e rs ja m i s p e c y fik a c ji W S -R e lia b le M e s s a g in g ja k o ś ro d k ie m re a liz a c ji n ie z a w o d n e g o k o m u n i­ k o w a n ia z w ią z a n e g o z s e ry jn y m p rz e s y ła n ie m fa k tu r. W s p o m n ia n e z a ło ż e n ia p o lity k i z a im p le m e n to w a n o w p o s ta c i k o n s tru k c ji E x a c tly O n e z a ­ g n ie żd ża ją c e j d w a e le m e n ty re p re z e n tu ją c e p o s zc zeg ó ln e w ersje s p e c y fik a c ji, ta k ja k n a p o ­ n iż s z y m p rz y k ła d z ie . Przykład 17.9. Konstrukcja ExactlyOne umożliwiająca wybór dokładnie jednej spośród dwu alternatywnych asercji < /w sp: ExactlyOne > < /w sp:Policy>

17.3.3. Element All E le m e n t A l l re p re z e n tu je w y m ó g za s to s o w a n ia w s z y s tk ic h je g o p o to m n y c h asercji. E le m e n t te n m o że b yć łą c zo n y z e le m e n te m E x a c tly O n e , co daje w efekcie k o n s tru k c ję repre ze n tu ją c ą w y b ó r m ię ­ d z y d w ie m a g r u p a m i asercji, z o b o w ią z k ie m za s to s o w a n ia w s z y s tk ic h asercji z w y b ra n e j g ru p y .

ANALIZA PRZYPADKU

F ir m a T L S p o s z e rz y ła z a ło ż e n ia sw ej p o lity k i o w y m ó g s ta n d a rd o w e g o k o d o w a n ia te k s tó w . D o ka żd e j z m o ż liw y c h do w y b o ru asercji S p e c V e rs io n d o łą c zo n a zo stała o d p o w ie d n ia asercja T e x tE n c o d in g , w s k u te k czego w y b ó r m ię d z y d w ie m a p o je d y n c z y m i a s e rc ja m i p r z e o b r a z ił się

w w y b ó r m ię d z y d w ie m a g r u p a m i asercji. Przykład 17.10. Połączenie konstrukcji All i ExactlyOne reprezentujące wybór między dwiema grupami asercji

1 7 .3 . P O D S TA W Y JĘZYKA W S-PO LIC Y

547

< /w sp: ExactlyOne > < /w sp:Policy>

Is tn ie je k o n s tru k c ja w y b o ru p o ś re d n ia m ię d z y s k ra jn o ś c ia m i E x a c tly O n e a A l l : jest n ią k o n s tru k c ja O neO rM ore re p re z e n tu ją c a w y m ó g co n a jm n ie j je d n e j z p o to m n y c h asercji.

17.3.4. Atrybut Usage W p re z e n to w a n y c h p r z y k ła d a c h w ie lo k r o tn ie w id z ie liś m y u ż y c ie a tr y b u tu U sag e d e c y d u ją c e g o o ty m , c z y d a n a a s erc ja p o lit y k i je s t w y m a g a n a . A t r y b u t te n je s t k lu c z o w ą częścią fr a m e w o r k u , ja k o że jeg o w a rto ś c i w p o s z c z e g ó ln y c h a sercjach w p ły w a ją n a c a ło k s zta łt re g u ł p o lity k i. W ta b e li 17.4 o p is u je m y zn a c ze n ie m o ż liw y c h w a rto ś c i tego a try b u tu . Tabela 17.4. Możliwe wartości atrybutu Usage W arto ść

Znaczenie

Required

W ym agania asercji m uszą zostać spełnione, w przeciw nym razie sygnalizow any będzie błąd.

Optional

W ym agania asercji m ogą, lecz nie m uszą zostać spełnione.

R ejected

A sercja nie jest obsługiw ana.

Observed

A sercja stosuje się do w szystkich p o d m io tó w polityki.

Ignored

A sercję należy celowo zignorow ać.

17.3.5. Atrybut Preference A t r y b u t te n u m o ż liw ia ró ż n ic o w a n ie r a n g i (is to tn o ś c i) p o s z c z e g ó ln y c h a s e rc ji w d a n e j g ru p ie . P rz y d a je się to s zc ze g ó ln ie w te d y , g d y d o s ta w c a u s łu g i je s t d o s ta te c z n ie e la s ty c z n y , b y o fe ro w a ć w ie le w a ria n tó w z a ło ż e ń p o lity k i d la p o te n c ja ln y c h u s łu g -w n io s k o d a w c ó w . W a rto ś c ią a try b u tu jest liczba c ałko w ita: im w iększa, ty m w iększa ra n g a danej asercji. Jeśli a try b u t n ie w ystępuje ja w n ie w d e fin ic ji asercji, p rz y jm u je się d o m y ś ln ie jego w artość 0 d la tej asercji.

17.3.6. Element PolicyReference D o tej p o ry o m a w ia liś m y w y łą c zn ie tw o rz e n ie d o k u m e n tó w p o lity k i, n ie w s p o m in a liś m y n a to m ia s t o ty m , ja k k o ja rz y ć z a ło ż e n ia p o lity k i z p o d m io ta m i, k tó r y c h d o ty c zą . E le m e n t P o lic y R e f e r e n c e to je d e n ze ś ro d k ó w s k o ja rz e n ia p o d m io tu z je d n y m lu b k ilk o m a z a ło ż e n ia m i p o lity k i. K a ż d y e le m e n t P o lic y R e fe r e n c e p o siad a a try b u t URI w s k a zu ją c y d o k u m e n t p o lity k i lu b k o n k re tn ą asercję tego d o k u m e n tu (w ty m d r u g im p rz y p a d k u id e n ty fik a to r [ ID ] asercji lu b k o n s tru k c ji g ru p u ją c e j d o łą c z a n y je s t do U R I d o k u m e n tu i o d d z ie la n y z n a k ie m # ). Jeśli z d a n y m p o d m io te m sko jarzon o k ilk a asercji (p rze z użycie k ilk u e le m e n tó w P o lic y R e fe r e n c e ), w czasie w y k o n a n ia poszczególne d o k u m e n ty p o lity k i są ze sobą łączone.

548

RO ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

UW AGA Elementy P o lic y R e f e r e n c e mogą rezydować wew nątrz konstrukcji P o lic y , dzięki czemu można tworzyć wieloużywalne moduły polityki.

A N A LIZA PRZYPADKU

Jeśli T L S p o s ta n o w i w y d z ie lić w fo r m ie o d rę b n e j d e fin ic ji z a ło ż e n ia p o lity k i d o ty c zą ce u s łu g i P r a c o w n ik , m o ż e to z ro b ić w n a s tę p u ją c y sposób. Przykład 17.11. Oddzielne elementy PolicyReference odwołujące się do asercji w dwóch różnych dokumentach (zwróćmy uwagę na znak # oddzielający URI dokumentu od identyfikatora asercji)

17.3.7. Atrybut PolicyURIs In n y m sp o s o b em s k o ja rz e n ia p o d m io tu z je d n y m lu b k ilk o m a d o k u m e n ta m i p o lity k i je s t a try b u t P o lic y U R Is . A tr y b u t te n d o d a w a n y je s t do d e fin ic ji p o d m io tu , a je g o w a rto ś c ią m o ż e b y ć p o je ­

d y n c z y id e n ty fik a to r U R I lu b z b ió r ta k ic h id e n ty fik a to r ó w — w ty m d r u g im p r z y p a d k u w szy s tk ie sp e cyfiko w an e d o k u m e n ty (lu b asercje) są łą c zo n e w czasie w y k o n a n ia , p o d o b n ie ja k w p rz y p a d k u e le m e n tó w P o l i c y R e f e r e n c e .

A N A LIZA PRZYPADKU

In n y m sposobem p rzy p is a n ia usłudze P ra c o w n ik d w ó c h d o k u m e n tó w p o lity k i m o że by ć użycie a try b u tu Pol icyU R Is . Przykład 17.12. Atrybut PolicyURIs wskazujący dwie asercje w dwóch różnych dokumentach (zwróćmy uwagę na znak # oddzielający URI dokumentu od identyfikatora asercji)

17.3.8. Element PolicyAttachment Jeszcze in n y sposób s k o ja rz e n ia z a ło ż e ń p o lity k i z p o d m io te m u d o s tę p n ia k o n s tru k c ja P o lic y A tta c h m e n t . Z a g n ie ż d ż o n e w n ie j e le m e n ty p o to m n e A p p lie s T o są je d n o c z e ś n ie n a d rz ę d n e w s to ­

s u n k u do e le m e n tó w re p re z e n tu ją c y c h d o c e lo w e p o d m io ty . N a r ó w n i z k o n s tru k c ją (k o n s tr u k ­ c ja m i A p p lie s T o ) w y s tę p u je z n a jo m y e le m e n t P o l i c y R e f e r e n c e id e n ty fik u ją c y asercję p o lity k i s to s o w a n ą do w s p o m n ia n y c h p o d m io tó w .

1 7 .3 . P O D S TA W Y JĘZYKA W S-PO LIC Y

549

ANALIZA PRZYPADKU

O to k o le jn y w a r ia n t s k o ja rz e n ia asercji p o lity k i z u s łu g ą P r a c o w n ik , id e n ty fik o w a n ą za p o ­ m o c ą p u n k tu k o ń c o w e g o (E n d p o in tR e fe re n c e ). T y m ra z e m s k o ja rz e n ie re a liz o w a n e je s t p r z y u ż y c iu k o n s tru k c ji P o lic y A tta c h m e n t i A p p lie s T o . Przykład 17.13. Konstrukcja PolicyAttachment wykorzystująca potomną konstrukcję AppliesTo w celu skojarzenia asercji polityki z punktem końcowym reprezentowanym przez element WS-Addressing EndpointReference h ttp ://w w w .x m ltc.c o m /tls/e p 1 em p:Em ployeeInterface emp:Pracownik < /w sp: Po1icyAttachment >

17.3.9. Inne typy asercji polityki W a r to w ty m m ie js c u z a zn a c zy ć , że asercje p o lity k i m o g ą b y ć u ż y w a n e i k o n fig u ro w a n e n a ró ż n e sposoby, w y kra czając e p o za k o n w e n c je p rz e d s ta w io n e w d o ty c h c za s o w y c h a n a liza c h p rz y p a d k ó w . O t o k ilk a p rz y k ła d ó w . •

A s ercje p o lity k i m o g ą b y ć w łą c za n e b e z p o ś re d n io do d e fin ic ji W S D L p r z y u ż y c iu sp ecjaln eg o ro d z a ju e le m e n tó w p o d m io to w y c h o d w o łu ją c y c h się do k o n k re tn y c h części s tru k tu ry d e fin ic ji. W s z y s tk o to m o ż liw e je s t d z ię k i s p e c ja ln e m u ro z s z e rz e n iu W S D L , ja k im je s t e le m e n t U s in g P o lic y .

•

F ra m e w o rk W S -R e lia b le M e s s a g in g d e fin iu je sp e c y fic zn e asercje W S -P o lic y ( i je s t o d n ic h z a le ż n y ) w c elu w y m u s z e n ia o k re ś lo n y c h re g u ł z w ią z a n y c h z d o s ta rc z a n ie m k o m u n ik a tó w i p o tw ie rd z a n ie m ic h d o s ta rc z a n ia .

•

Z a p o m o c ą asercji W S -P o lic y k o ja rz o n y c h z u s łu g ą s ie c io w ą m o ż n a w y ra ż a ć z d o ln o ś ć tej

•

Z a p o m o c ą asercji p o lity k i m o ż n a ta k że w y ra ż a ć w y m a g a n ia p rz e tw a rz a n ia d a n e j u s łu g i

u s łu g i do u c z e s tn ic z e n ia w o k re ś lo n e j a k ty w n o ś c i b izn e s o w e j lu b tra n s a k c ji n ie p o d z ie ln e j.

w re la c ji do in n y c h s p e c y fik a c ji W S - * . •

A s e rc je W S -P o lic y są p o w s z e c h n ie w y k o rz y s ty w a n e w ra m a c h fr a m e w o r k u W S -S e c u rity do w y ra ż a n ia w y m a g a ń w z a k re s ie b e zp ie c ze ń s tw a .

550

RO ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

PODSUMOWANIE

•

Specyfikacja W S-Policyustanawia rozszerzalny framework definiowania założeń polityki, umożliwiający wzbogacenie SOA o warstwę integralności komunikatów.

•

Założenia polityki mogą zawierać jedną lub więcej asercji polityki, które można grupować w kontekście różnych wariantów stosowania przy użyciu konstrukcji E xa c tly O n e , A ll i OneOrMore.

•

Istnieje kilka sposobów kojarzenia założeń polityki z podmiotami, do których się odnoszą. Służą do tego między innymi konstrukcje P o lic y A tta c h m e n t i P o lic y R e fe re n c e oraz atrybut P o lic y U R Is .

17.4. Podstaw y języka W S-M etadataExchange UWAGA

W tym rozdziale prezentujemy jedynie opisy elementów języka W S-M etadataExchange— koncepcje kryjące się za tymi elementami omówiliśmy już w rozdziale 7.

S p e c y fik a c ja W S -M e ta d a ta E x c h a n g e o fe ru je s ta n d a rd o w e ś r o d k i do ż ą d a n ia i d o s ta rc z a n ia d o k u m e n tó w o p isó w usług. D e fin iu je o n a z b ió r cech stanow iących w sparcie d la c h a rakterystyki S O A , g łó w n ie w z a kresie in te ro p e ra c y jn o ś c i i ja k o ś c i u s łu g (p a tr z ry s u n e k 1 7 .4 ).

Rysunek 17.4. Związek WS-MetadataExchange z innymi rozszerzeniami WS-* opisywanymi w tym rozdziale

1 7 .4 . P O D S TA W Y JĘZYKA W S -M E T A D A T A E X C H A N G E

551

W p o r ó w n a n iu z in n y m i s p e c y fik a c ja m i W S - * , ję z y k W S -M e ta d a ta E x c h a n g e je s t w y ra ź n ie s k ro m n ie js z y . Jak p is a liś m y w ro z d z ia le 7 ., is tn ie ją ty lk o d w a s ta n d a rd o w e ż ą d a n ia m e ta d a n y c h : •

G e tM e ta d a ta ,

•

Get.

N iż e j o p is u je m y po d staw o w e e le m e n ty o rganizujące w y m ia n ę m e ta d a n y c h w ra m a c h ty c h d w ó c h k o m u n ik a tó w .

17.4.1. Element GetMetadata E le m e n t te n m o ż e w ystę p o w a ć z a ró w n o w p ro stej postaci, ja k i w postaci ro z b u d o w a n e j k o m p o z y c ji z a g n ie ż d ż a ją c e j e le m e n ty p o to m n e D ia le c t i I d e n t i f i e r . W o b u p rz y p a d k a c h re z y d u je w e w n ą trz k o n s tru k c ji Body.

ANALIZA PRZYPADKU

W scenariuszu o p is y w a n y m ja k o część a n a liz y p rz y p a d k u w ieńczącej p o d ro z d z ia ł 7.5, „ W y m ia n a m e ta d a n y c h ”, w R a ilC o z a p ro je k to w a n o usługę P r z e t w a r z a n ie f a k t u r y w ta k i sposób, że p e ­ rio d y c z n ie k o n tro lu je o n a stan m e ta d a n y c h to w a rz y s z ą c y c h u s łu d ze T L S P ła tn o ś ć n a k o n to . O to p rz y k ła d p ie rw s ze j w e rs ji k o m u n ik a tu -ż ą d a n ia G e tM e ta d a ta w y s ła n e g o p rz e z R a ilC o . Przykład 17.14. Komunikat-żądanie SOAP zawierający element GetMetadata wewnątrz konstrukcji Body. Zauważmy obecność bloku z grupy MI w nagłówku SOAP

http://schem as.xm 1soap.org/w s/2004/09/m ex/G etM etadata/Request h ttp ://w w w .x m ltc .c o m /tls /a p 1 / uuid:23492372938 h ttp ://w w w .x m ltc .c o m /ra ilc o /in v 1 /

552

RO ZD ZIAŁ 1 7 . a P O D S T A W O W E ROZSZERZENIA W S -*

17.4.2. Element Dialect T e n e le m e n t p re c y z u je ty p i w e rs ję ż ą d a n y c h m e ta d a n y c h ; je g o u ży c ie g w a ra n tu je , że m e ta d a n e d o s ta rc z o n e u s łu d z e -w n io s k o d a w c y b ę d ą d la n ie j z ro z u m ia łe .

A N A LIZA PRZYPADKU

W R a ilC o u d o s k o n a lo n o o ry g in a ln ą w ersję k o m u n ik a tu -ż ą d a n ia m e ta d a n y c h , d o d a ją c e le m e n t D ia l e c t in fo rm u ją c y , że d o starczo n e m e ta d a n e m u s zą b y ć zg o d n e ze specyfikacją X S D w w e rs ji

z ro k u 20 0 1 . Przykład 17.15. Element Dialect wskazujący wymaganie dostarczenia metadanych w postaci zgodnej z wersją 1.0 XML Schema Definition Language http://www.w3.org/2001/XMLSchema < /w sx: D ia le c t >

17.4.3. Element Identifier P o d czas g d y e le m e n t D i a l e c t s p e c y fik u je ty p ż ą d a n y c h m e ta d a n y c h , e le m e n t I d e n t i f i e r za w ę ża ż ą d a n ie do o k re ś lo n e j części m e ta d a n y c h .

A N A LIZA PRZYPADKU

W R a ilC o po ra z k o le jn y z m ie n io n o k o m u n ik a t-ż ą d a n ie m e ta d a n y ch , dodając do niego ele m e n t I d e n t i f i e r d o k ła d n ie o k re ś la ją c y , k tó r y s c h e m a t X S D p o w in ie n zostać p rz e s ła n y z T L S . Przykład 17.16. Element Identifier specyfikujący docelową przestrzeń nazw żądanego schematu XSD http://www.w3.org/2001/XMLSchema < /w sx:D ialect> http://w w w .w w w .xm ltc.com /tls/schem as/ap1/schem as < /w sx: Id e n t i f ie r >

17.4.4. Elementy Metadata, MetadataSection i MetadataReference T r z y ty tu ło w e e le m e n ty służą o rg a n iz o w a n iu treści k o m u n ik a tu -o d p o w ie d z i n a żąd an ie G e tM e ta d a ta . N a d rz ę d n a k o n s tru k c ja M e ta d a ta , re z y d u ją c a w e w n ą trz k o n s tru k c ji Body k o m u n ik a tu S O A P , z a ­ g n ie ż d ż a w sobie je d n ą lu b w ię c e j k o n s tru k c ji M e t a d a t a S e c t io n , re p re z e n tu ją c y c h p o s zc zeg ó ln e części p rz e s ła n y c h m e ta d a n y c h .

1 7 .4 . P O D S TA W Y JĘZYKA W S -M E T A D A T A E X C H A N G E

553

Jeśli część m e ta d a n y c h je s t k o p ią o ry g in a ln y c h tre ś c i, k o p ia ta lo k o w a n a je s t w p ro s t w e w n ą trz k o n s tru k c ji M e t a d a t a S e c t io n ; je ż e li n a to m ia s t z w r a c a n y je s t w s k a ź n ik do d o k u m e n tu , je s t o n r e p re z e n to w a n y p rz e z e le m e n t M e ta d a ta R e fe r e n c e z a g n ie ż d ż o n y w e w n ą tr z k o n s tr u k c ji M e ta d a ta S e c tio n .

ANALIZA PRZYPADKU

W o d p o w ie d z i n a w y s ła n e p rz e z R a ilC o ż ą d a n ie G e tM e ta d a ta z T L S n a d s z e d ł n a s tę p u ją c y k o m u n ik a t-o d p o w ie d ź , z a w ie ra ją c y k o p ię d e fin ic ji W S D L usłu g i P ła tn o ś ć n a k o n to i w s k a ź n ik d o o d n o ś n e g o s c h e m a tu X S D . Przykład 17.17. Odpowiedź na żądanie GetMetadata

http://schem as.xm lsoap.org/w s/2004/09/m ex/G etM etadata/R esponse 23492372938 http ://w w w .x m ltc.c o m /railco /in v 1

< w sd l:d e fin itio n s> . . . kompletna d e f in i c j a WSDL . . . < /w s d l:d e fin itio n s > http://w w w .w w w .xm ltc.com /tls/ap1/schem as

E le m e n t M e t a d a ta S e c tio n m o ż e p o s ia d a ć a try b u ty D i a l e c t i I d e n t i f i e r , o d p o w ia d a ją c e o p i­ s y w a n y m w cze śn ie j a n a lo g ic z n y m e le m e n to m .

554

RO ZD ZIAŁ 1 7 . a P O D S T A W O W E ROZSZERZENIA W S -*

17.4.5. Komunikat Get Jak w id z ie liś m y n a p rz y k ła d z ie 17.17, o d p o w ie d ź n a ż ą d a n ie G e tM e ta d a ta m o że z a w ie ra ć w s k a ź n ik i do d o k u m e n tó w z a m ia s t k o p ii ty c h d o k u m e n tó w . A b y u zy s k a ć k o p ie , n a le ż y w y s ła ć o d d z ie ln y k o m u n ik a t G e t . N ie is tn ie je e le m e n t G e t , sam k o m u n ik a t je s t n a to m ia s t s ta n d a rd o w y m k o m u n ik a te m S O A P z a w ie ra ją c y m s to s o w n y n a g łó w e k , co z ilu s tr u je m y n a k o n k r e tn y m p rz y k ła d z ie .

ANALIZA PRZYPADKU

W R a ilC o n ie lu b ią ry z y k a , usługa P r z e tw a r z a n ie f a k t u r y zo stała w ię c ostatecznie ta k z a p ro ­ je k to w a n a , że całość ż ą d a n y c h m e ta d a n y c h p o z y s k iw a n a jest w fo r m ie k o p ii o d n o ś n y c h d o ­ k u m e n tó w . P o n iż e j p rz e d s ta w ia m y w y s y ła n y p rz e z tę usługę k o m u n ik a t-ż ą d a n ie G et w celu p o b ra n ia fiz y c zn e g o e g z e m p la rz a s c h e m a tu X S D id e n ty fik o w a n e g o p rz e z w s k a ź n ik w p r z y ­ k ła d z ie 17.17. Przykład 17.18. Nagłówek SOAP komunikatu-żądania Get; funkcja komunikatu identyfikowana jest w ramach elementu Action, wskaźnik do żądanego zasobu znajduje się wewnątrz elementu To

http://schem as.xm lsoap.org/w s/2004/09/m ex/G et/R equest 23492372938 h ttp ://w w w .x m ltc.c o m /railco /su b 1

http://w w w .w w w .xm ltc.com /tls/schem as/not1

PODSUMOWANIE

•

Język W S-M etadataExchangezawiera konstrukcję G e tM e ta d a ta zagnieżdżającą elementy specyfikujące szczegóły metadanych żądanych od usługi-dostarczyciela.

•

Elementy D i a l e c t i I d e n t i f i e r umożliwiają dodatkowe sprecyzowanie szczegółów żądania.

•

Komunikat stanowiący odpowiedź na żądanie G e tM e ta d a ta zawiera metadane zorganizowane za pomocą elementów M e ta d a ta , M e t a d a t a S e c tio n i M e ta d a ta R e fe r e n c e .

17.5. PODSTAWY JĘZYKA WS-SECURITY

555

17.5. Podstaw y języka W S-Security UWAGA

W tym rozdziale prezentujemy jedynie opisy elementów języka W S-Security— koncepcje kryjące się za tymi elementami omówiliśmy już w rozdziale 7.

F ra m e w o rk W S -S e c u rity o fe ru je ro z s z e rz e n ia do im p le m e n to w a n ia ś ro d k ó w b e z p ie c z e ń s tw a n a p o z io m ie k o m u n ik a tó w . Z a p e w n ia ją one k o m u n ik a to m b ezp ie c ze ń s tw o z a ró w n o podczas tra n s ­ p o rtu , ja k i p o d czas p rz e tw a rz a n ia p rz e z u s łu g i p o ś re d n ic zą c e . D o d a tk o w e ro z s z e rz e n ia im p le ­ m e n tu ją k o n tro lę u w ie r z y te ln ia n ia i a u to ry z a c ji, c h ro n ią c u s łu g i p rz e d d o s tę p e m ze s tro n y n ie p o ­ ż ą d a n y c h w n io s k o d a w c ó w . F r a m e w o r k W S -S e c u rity z a p r o je k to w a n o do w s p ó łp ra c y z in n y m i ro z s z e rz e n ia m i W S - * o m a w ia n y m i w ty m ro z d z ia le — jeg o re la c ję do ty c h ro z s ze rz e ń p rz e d s ta ­ w ia m y n a ry s u n k u 17.5.

ł Oddzielna specyfikacja WS-SecurityPolicy dostarcza zbioru predefiniowanych asercji polityki dla WS-Security

Rysunek 17.5. Związek WS-Security z innymi rozszerzeniami WS-* opisywanymi w tym rozdziale

556

RO ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

F ra m e w o rk W S -S e c u rity składa się z w ie lu specyfikacji o ró ż n y m s to p n iu d o jrzałości i akceptacji. W tej książce p o ś w ię c im y szc ze g ó ln ą uw a g ę tr z e m n a jb a rd z ie j u s ta b iliz o w a n y m , a m ia n o w ic ie : •

W S -S e c u rity ,

•

X M L - E n c r y p tio n ,

•

X M L - S ig n a tu r e .

W S -S e c u rity to n ie ty lk o fr a m e w o r k , to ta k że s p e c y fik a c ja d e fin iu ją c a e le m e n ty ję z y k a . P o n ie ­ w a ż o p is y w a n e p o n iż e j e le m e n ty w y w o d z ą się z trz e c h ró ż n y c h ź ró d e ł, d la k a żd e g o z n ic h w s k a ­ z y w a ć b ę d z ie m y p o c h o d z e n ie . W p u n k c ie 7 .6 .2 , „ J e d n o k ro tn e lo g o w a n ie ”, p r z y o k a z ji o m a w ia n ia k o n c e p c ji b e z p ie c z e ń s tw a u słu g s ie c io w y c h , z a trz y m a liś m y się p rz e z c h w ilę n a s p e c y fik a c ji S A M L , d e fin iu ją c e j c e n tra liza c ję u w ie rz y te ln ia n ia i a u to ry z a c ji. Jako że te m a ty k a ję z y k ó w z w ią z a n y c h z je d n o k ro tn y m lo g o w a n ie m w y k ra c z a p o z a r a m y tej k s ią ż k i, n ie b ę d z ie m y o p is y w a ć e le m e n tó w ję z y k a S A M L (p rz e d s ta w im y je d n a k p rz y k ła d z a s to s o w a n ia b lo k u n a g łó w k o w e g o S A M L w k o m u n ik a c ie S O A P ).

17.5.1. Element Security T o fu n d a m e n ta ln y b lo k n a g łó w k o w y d o s ta rc z a n y p rz e z W S -S e c u rity . M o ż e z a g n ie ż d ż a ć w sobie ró ż n e e le m e n ty p o to m n e , m ię d z y in n y m i X M L -E n c ry p tio n i X M L -S ig n a tu re , o ra z e le m e n ty to k e n ó w d e fin io w a n y c h w sam e j s p e c y fik a c ji W S -S e c u rity . E le m e n t S e c u r i t y m o ż e p o s ia d a ć a tr y b u t a c t o r , o d p o w ia d a ją c y r o lo m a k t o r ó w S O A P . U m o ż liw ia to d o d a n ie d o k o m u n ik a tu S O A P w ie lu b lo k ó w S e c u r i t y , p rz e z n a c z o n y c h d la r ó ż ­ n y c h o d b io rc ó w .

17.5.2. Elementy UsernameToken, Username i Password (WS-Security) E le m e n t U sern am eToken to k o n s tru k c ja h o s tu ją c a in fo rm a c ję to k e n o w ą p rz e z n a c z o n ą d la u w ie ­ rz y te ln ia n ia i a u to ry za c ji. T y p o w y m i e le m e n ta m i p o to m n y m i tej k o n s tru k c ji są Usernam e i Passw ord , choć m o ż liw e je s t u ży c ie w tej r o li jeszcze in n y c h e le m e n tó w .

17.5.3. Element BinarySecurityToken (WS-Security) E le m e n t te n s łu ż y d o r e p r e z e n to w a n ia to k e n ó w z a w ie ra ją c y c h s z y fro w a n ą in fo r m a c ję b in a r n ą , n a p r z y k ła d c e rty fik a ty .

17.5.4. Element SecurityTokenReference (WS-Security) E le m e n t te n z a w ie ra w s k a ź n ik do to k e n u z lo k a liz o w a n e g o p o z a d o k u m e n te m k o m u n ik a tu S O A P .

1 7 .5 . P O D S TA W Y JĘZYKA W S-SEC U R ITY

557

A N A LIZA PRZYPADKU

D la k a ż d e j fa k tu r y g e n e ro w a n e j w R a ilC o p rz e z usługę W y s ta w ie n ie f a k t u r y k o n ie c z n e je s t u m ie szczen ie w n a g łó w k u S O A P to k e n u zaw ie ra ją c e g o n a zw ę u ż y tk o w n ik a i hasło, re p re z e n ­ to w a n e p rz e z e le m e n ty (o d p o w ie d n io ) Username i Password, ta k ja k w p o n iż s z y m p rz y k ła d z ie . Przykład 17.19. Nagłówek SOAP Security wykorzystywany w RailCo do dostarczenia nazwy użytkownika i hasła

rco-3342 < /w sse : Username> < w sse: Password Type="wsse:PasswordDigest"> 93292348347 < /w sse : Password> < /w sse : UsernameToken> < /w sse: S e c u rity >

17.5.5. Komponowanie zawarto ś ci elementu Security (WS-Security) Jak ju ż w s p o m in a liś m y , s p e c y fik a c ja W S -S e c u rity p o z y c jo n u je e le m e n t S e c u r it y w r o li s ta n d a r­ dow eg o k o n te n e ra d la b lo k ó w n a g łó w k o w y c h w y w o d zą c y c h się z in n y c h ro zszerzeń bezpieczeństw a. P o n iż s z y p r z y k ła d ilu s tru je te n fa k t, p o k a z u ją c z a g n ie ż d ż e n ie w e le m e n c ie S e c u r it y b lo k u S A M L (k tó re g o s zc ze g ó łó w , z g o d n ie z z a p o w ie d z ią , n ie b ę d z ie m y tu w y ja ś n ia ć ).

A N A LIZA PRZYPADKU

G d y u słu g a R a ilC o W y s ta w ie n ie f a k t u r y z o s ta n ie ju ż u w ie rz y te ln io n a i a u to ry z o w a n a p rz e z usługę T L S P ła tn o ś ć n a k o n t o , d z ia ła ją c ą ja k o o rg a n w y d a ją c y (is s u in g a u th o r it y ) , u zy s k u je p ra w o d o s tęp u do in n y c h u s łu g T L S b e z p o n o w n e g o u w ie r z y te ln ia n ia i a u to ry z a c ji. K ie d y u słu g a W y s ta w ie n ie f a k t u r y zechce p ó ź n ie j w y s tą p ić w r o li w n io s k o d a w c y w s to ­ s u n k u do k tó re jk o lw ie k u s łu g i T L S , u s łu g a ta n ie z a żą d a o d n ie j p o n o w n ie u w ie rz y te ln ie n ia , lecz w yśle z w ią z a n e z ty m za p y ta n ie do o rg a n u w yd ająceg o i o trz y m a w o d p o w ie d z i k o m u n ik a t p o d o b n y do p o n iżs ze g o .

558

RO ZD ZIAŁ 1 7 . ■ P O D S T A W O W E ROZSZERZENIA W S -*

Przykład 17.20. Nagłówek SOAP WS-Security zagnieżdżający asercję autoryzacyjną SAML

< sam l:A ssertion xmln s : s a m l = " ..." ...> < sam l:C onditions . . . > < sam l:A uthorizationD ecisionS tatem ent D ecision="Perm it" Resource="h ttp ://w w w .x m ltc .c o m /tls /. .. " > Wykonaj < /sam l:A ction> < /sam l:A ctions> < /sam l:A u th o rizatio n D ecisio n S tatem en t> < /w sse: S ec u rity >

17.5.6. Element EncryptedData (XML-Encryption) T o n a d rz ę d n a k o n s tru k c ja h o s tu ją c a s z y fro w a n ą p o rc ję d o k u m e n tu X M L . G d y k o n s tru k c ja ta jest k o rz e n ie m ( ro o t) w d o k u m e n c ie , c a ły te n d o k u m e n t p o d le g a s z y fro w a n iu . A tr y b u t Type e le m e n tu E n c ry p te d D a ta s zc ze g ó ło w o o k re ś la g ra n ic e s z y fro w a n e j p o rc ji i ta k n a p r z y k ła d w a rto ś ć h t t p : / / w w w . w 3 . o r g / 2 0 0 1 / 0 4 / x m l e n c # o z n a c z a s z y fro w a n ie c ałeg o w y b ra n e g o e le m e n tu , n a to m ia s t w a rto ś ć h t t p : // w w w .w 3 .O r g /2 0 0 1 /0 4 /x m le n c # C o n t e n t o z n a c z a s z y fro w a n ie w y łą c z n ie treści w y b ra n e g o e le m e n tu , b e z o g ra n ic z a ją c y c h tę treść z n a c z n ik ó w .

17.5.7. Elementy CipherData, CipherValue i CipherReference (XML-Encryption) K o n s tr u k c ja C ip h e r D a t a je s t o b o w ią z k o w a i m u s i z a g n ie ż d ż a ć b ą d ź to e le m e n t C ip h e r V a lu e h o s tu ją c y w y n ik s z y fro w a n ia (s z y fr o g ra m ), b ą d ź e le m e n t C ip h e r R e f e r e n c e h o s tu ją c y w s k a ź n ik d o s z y fro g ra m u .

ANALIZA PRZYPADKU

W ro z d z ia le 15. o p is y w a liś m y p ro je k to w a n ie w T L S b izneso w ej u sługi za d a n io w e j, w y k o rz y s tu ­ jącej schem at X S D do re p re z e n to w a n ia n ie w ie lk ie g o d o k u m e n tu -fa k tu ry , w chod zącego w skład k o m u n ik a tu . O to p rz y k ła d ta k ie g o d o k u m e n tu :

1 7 .5 . P O D S TA W Y JĘZYKA W S-SEC U R ITY

559

2322 $32,322.73 < /T otal> 07.16.05 < /In v o i ceType> Z g o d n ie z w y m a g a n ia m i b e z p ie c z e ń s tw a ze s tr o n y f i r m y T L S , w k o m u n ik a ta c h w y s y ła n y c h d o je j s y s te m u B 2 B w s z y s tk ie k w o t y p ie n ię ż n e m u s z ą b y ć z a s z y fro w a n e . E le m e n t T o ta l n ie m o ż e w ię c p o z o s ta ć w „ o t w a r t e j” p o s ta c i — p o je g o z a s z y f r o w a n iu ( r a z e m z g r a n ic z n y m i z n a c z n i­ k a m i < T o t a l > i < / T o t a l > ) i u ję c iu s z y fr o g r a m u w r a m y e le m e n tu C ip h e r V a lu e o t r z y m u je m y p o s ta ć p r z e s y ła n e j f a k t u r y , ta k ą ja k w p r z y k ła d z ie 1 7 .2 1 .

Przykład 17.21. Dokument XML w komunikacie SOAP, zawierający szyfrowany element 2322 R5J7UUI78 < / CipherValue > < / CipherData > < / EncryptedData > 07.16.05 < /In v o i ceType> W a r t o ś ć a t r y b u t u T y p e = "h ttp ://w w w .w 3 .o r g /2 0 0 1 /0 4 /x m le n c # E le m e n t" o z n a c z a s z y fr o w a ­ n ie c a łe g o e le m e n t u T o ta l w r a z z je g o g r a n ic z n y m i z n a c z n ik a m i.

17.5.8. Elementy XML-Signature P o d p is c y fr o w y to in f o r m a c ja o s k o m p lik o w a n e j s tr u k tu r z e , k tó r e j k o n k r e tn e e le m e n ty r e p r e z e n tu ją p o s z c z e g ó ln e a s p e k ty p o d p is y w a n e g o d o k u m e n t u . N i c w ię c d z iw n e g o , ż e w im p le m e n t a c ję p o d ­ p is y w a n ia d o k u m e n tu z a a n g a ż o w a n y c h je s t w ie le e le m e n tó w , o d z w ie rc ie d la ją c y c h z ło ż o n ą s tr u k tu r ę s a m e g o p o d p is u . W y b r a n e z t y c h e le m e n t ó w o p is a liś m y z w ię ź le w ta b e li 1 7 .5 .

ROZDZIAŁ 17. ■ PODSTAWOWE ROZSZERZENIA WS-*

560

Tabela 17.5. Ważniejsze elementy XML-Signature E le m en t

Znaczenie

C anonicalizationM ethod

E le m e n t iden ty fik u je typ a lg o ry tm u sp ro w ad z an ia d o k u m e n tu (p rz e d szyfrow aniem ) do tzw. po staci k anonicznej („kanonikalizacji”) — dokum enty, k tó ry ch treści ró żn ią się tylko d ro b n y m i szczegółam i (m ięd zy in n y m i użyciem „białych” znaków ), sprow adzane są do tej sam ej „zn orm alizow anej” p o sta c i1.

DigestMethod

E le m en t iden ty fik u je a lgorytm uży ty do sp o rz ąd z a n ia w yciągu (digest) d o k u m e n tu .

DigestV alue

E lem ent identyfikuje w yciąg d o k u m e n tu uzyskany w rezultacie zastosow ania a lgorytm u określonego p rzez DigestMethod.

KeyInfo

E lem ent opcjonalny, zaw ierający klucz p ubliczn y n adaw cy k o m u n ik a tu .

S ig n a tu re

E lem ent najw yższego p o z io m u (root) h o stu jąc y całość in fo rm acji związanej z p o d p isem elektronicznym .

SignatureM ethod

A lgorytm używ any do tw o rzen ia p o d p isu elektronicznego, stanow iący p ołączenie a lgorytm u kanonikalizacji i a lgorytm u tw o rzen ia wyciągu.

SignatureV alue SignedInfo

O stateczna p o stać p o d p isu elektronicznego. K onstrukcja hostująca elem enty zawierające inform ację zw iązaną z elem entem SignatureV alue, lecz rezydującą poza m acierzystą stru k tu rą Si gnature.

Reference

K ażdy d o k u m e n t sygnow any ty m sam ym p o d p isem cyfrow ym jest re p re z en to w a n y p rzez k o n stru k c ję Reference, h o stu jącą w yciąg i inne szczegóły tran sfo rm a cji d okum entu.

ANALIZA PRZYPADKU

Jak p a m ię ta m y z p o p rz e d n ic h ro z d z ia łó w , z g o d n ie z w y m o g a m i T L S k a ż d a fa k tu ra o w a rto ś c i przekraczającej 30 000 U S D m u s i być po d p isan a cyfrow o. R a ilC o dołącza w ięc do n a g łó w k a S O A P k o m u n ik a tó w n io sących ta k ie fa k tu r y b lo k p o d p is u c y fro w e g o zg o d n eg o z X M L -S ig n a tu r e , ta k ja k w p o n iż s z y m p rz y k ła d z ie . Przykład 17.22. Nagłówek SOAP zawierający podpis cyfrowy

< w sse:S ecu rity xmlns:wsse= "h ttp ://s c h e m a s .x m ls o a p .o rg /w s/2 0 0 2 /1 2 /s e c e x t">

1 Czytelnikom zainteresowanych szczegółami tego procesu, zwanego z angielska canonicalization lub swojsko d 4 n , i jego znaczeniem z perspektywy podpisu cyfrowego polecam lekturę podrozdziału 5.2, „S/MIME”, książki W illiam a Stallingsa Kryptografia i bezpieczeństwo sieci komputerowych. Koncepcje i metody bezpiecznej kom uni­ kacji, wyd. Helion 2012, http://helion.pl/ksiazki/krybek.htm — przyp. tłum.

1 7 .5 . P O D S TA W Y JĘZYKA W S-SEC U R ITY

561

< Reference URI= "http://w w w .w 3.org/TR/2000/REC-xhtm l1-20000126/"> LLSFK032093548= < / DigestValue > < / Reference > < / S ignedInfo > 9879DFSS3= < / SignatureValue > < / KeyInfo > < / Signature > < /w sse:S ecu rity >

. . . D okum ent-faktura o w arto ści p rz e k ra c z a ją c e j 30 000 USD . . .

P O D S U M O W A N IE

•

Specyfikacja WS-Security definiuje standardowy nagłówek SOAP S e c u r i t y jako kontener dla tokenów bezpieczeństwa lub bloków bezpieczeństwa definiowanych przez inne specyfikacje.

•

Język XM L-Encryption dostarcza konstrukcję zastępującą wybrany element dokumentu jego zaszyfrowaną wersją.

•

Specyfikacja X M L-Signature definiuje blok nagłówkowy S ig n a t u r e zawierający identyfikacje algorytmów i inne dane związane z podpisem elektronicznym, między innymi samą wartość podpisu.

562

ROZDZIAŁ 17. a PODSTAWOWE ROZSZERZENIA WS-*

Rozdział 18

Platformy SOA 1 8.1. P la tfo r m y S O A 1 8.2. S O A n a p la tfo r m ie J2EE 1 8.3. S O A n a p la tfo r m ie .N E T 1 8.4. W z g lę d y in te g ra c y jn e

564

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

O m a w ia n e d o tą d w tej książce k o n c e p c je , o tw a rte te c h n o lo g ie i spe c y fik a c je p o z o s ta ły b y je d y n ie p ię k n ą te o rią , g d y b y n ie p la tfo r m y u m o ż liw ia ją c e b u d o w a n ie w p e łn i fu n k c jo n a ln e j a r c h ite k tu ry z o rie n to w a n e j n a u s łu g i. W ty m , o s ta tn im ju ż , ro z d z ia le p r z y jr z y m y się w ię c te c h n o lo g io m ofe­ ro w a n y m p rze z d w ie p o p u la rn e p la tfo rm y p ro g ra m is ty c zn o -w y k o n a w c ze , w y k o rzy s ty w a n e o d w ie lu lat do tw o rz e n ia tra d y c y jn y c h ro z w ią z a ń ro z p ro s z o n y c h , a o b ecn ie ta k że m o d e li p ie rw o tn e j i w s p ó ł­ czesnej S O A . R o z p o c z y n a m y te n ro z d z ia ł o d o m ó w ie n ia n a jw a żn ie js z y c h w y m a g a ń s ta w ia n y c h p rz e d w s p o ­ m n ia n y m i p la tfo r m a m i, w y m a g a ń o d z w ie rc ie d la n y c h w ic h lo g ic z n e j s tru k tu rz e . A b s tra h u ją c p o ­ c z ą tk o w o o d k o n k r e tn e j p la tfo r m y , p r z e c h o d z im y n a s tę p n ie do p r o b le m a ty k i w s p a rc ia S O A n a p la tfo rm a c h J2EE i .N E T . Jak c z y te ln ic y z a u w a ż ą , p o d ro z d z ia ły 1 8 .2 i 18.3 m a ją id e n ty c z n ą s tru k tu rę — n ie je s t to p r z y ­ p a d e k , lecz z a m ie rz o n e d z ia ła n ie p o m y ś la n e z in te n c ją u ła tw ie n ia p o r ó w n a ń p o s z c z e g ó ln y c h cech o p is y w a n y c h p la tfo rm . U p r z e d z a m y je d n o c z e ś n ie , iż n ie je s t c e le m tego r o z d z ia łu d o k o n y w a n ie g e n e ra ln y c h p o ró w n a ń m ię d z y J2EE a .N E T — in te re s u ją nas one w y łą c zn ie z p e rs p e k ty w y w s p a rc ia d la S O A .

UW AGA Zarówno J2EE, jak i .NET sprzyjają podejściu projektowemu „najpierw WSDL", bo umożliwiają importowanie definicji WSDL i autom atyczne generow anie klas na ich podstawie. Jednak pobieżny choćby opis języka Java czy któregoś z języków w wersji dla .NET wykraczałby poza ramy książki, dlatego treść tego rozdziału nie będzie ilustrowana przykładami kodu źródłowego. Czytelnicy zainteresowani praktycznym tworzeniem usług siecio­ wych znaleźć mogą wiele rekomendowanych pozycji o tej tem atyce pod adresem w w w .serviceoriented.w s.

A n a liz y p rz y p a d k ó w : P o c z ą tk o w o w R a ilC o p la tfo r m ą p ro g r a m is ty c z n ą d la t w o r z o n y c h u s łu g b y ł fr a m e w o r k .N E T , zaś w T L S p o c z ą tk o w y z b ió r u s łu g ( i c a ły system B 2 B ) s tw o rz o n y zo s tał za p o m o c ą J2EE. Z p o w o d ó w , k tó re zo s ta n ą d o k ła d n ie j opisane w a n a liz a c h p rz y p a d k ó w w dalszej części ro z d z ia łu , ob ie f ir m y n a p e w n y m e ta p ie sw ej in fr a s tr u k tu r y I T p o s ta n o w iły sięg nąć p o p la tfo r m y k o n k u re n c y jn e , o d p o w ie d n io J2EE i .N E T .

18.1. Platform y SOA Z a n im z a jm ie m y się sp e c y fik ą p la tfo r m J2EE i .N E T , z a s ta n ó w m y się n a d p o d s ta w o w y m i aspek­ ta m i ś ro d o w is k a p ro g ra m is ty c z n o -w y k o n a w c z e g o , u m o ż liw ia ją c e g o b u d o w a n ie i im p le m e n to w a n ie u s łu g z g o d n y c h z z a s a d a m i S O A .

18.1.1. Podstawowe bloki konstrukcyjne platformy SOA Z a p o m n ijm y n a c h w ilę o S O A i z d e fin iu jm y e le m e n ta rn e b lo k i k o n s tru k c y jn e d o w o ln e j p la tfo rm y p ro g ra m is ty c z n e j. A b y s tw o rzy ć i u ru c h o m ić p ro g ra m , p o trz e b u je m y :

1 8 .1 . PLA TFO R M Y SOA

•

565

ś ro d o w is k a , z a p o m o c ą k tó re g o u tw o r z y m y k o d ź r ó d ło w y naszego p ro g r a m u , ś ro d o w is k o to p o w in n o u d o s tę p n ia ć n a rz ę d z ia p ro g ra m is ty c z n e p rz y s to s o w a n e do k o n k re tn e g o ję z y k a p ro g ra m o w a n ia ;

•

b ib lio te k , k tó re n a rz e c z p r o g r a m u s p e łn ia ć b ę d ą fu n k c je sp e c y fic zn e d la d o c e lo w e g o ś ro d o w is k a , p o d k ą te m k tó re g o p ro je k tu je m y n a s z p ro g ra m ;

•

in te rfe js ó w A P I e k s p o n u ją c y c h fu n k c jo n a ln o ś ć w s p o m n ia n y c h b ib lio te k i u m o ż liw ia ją c y c h p r o g r a m o m in te ra k c ję z e le m e n ta m i te j fu n k c jo n a ln o ś c i;

•

sy ste m u o p e ra c y jn e g o , p o d k o n tr o lą k tó re g o d z ia ła ć b ę d z ie n a s z p ro g ra m ; system o p e ra c y jn y s ta n o w i w a rs tw ę p o ś re d n ic z ą c ą m ię d z y p r o g r a m a m i a in fr a s tru k tu r ą s p rz ę to w ą i często o fe ru je d o d a tk o w e u s łu g i za p o ś re d n ic tw e m o d rę b n e g o A P I.

W y m ie n io n e e le m e n ty tw o rz ą p o d s ta w o w y m o d e l a r c h ite k to n ic z n y o s tru k tu rz e w a rs tw o w e j, p rz e d s ta w io n e j n a ry s u n k u 18.1.

Rysunek 18.1. Fundamentalne warstwy architektury środowiska programistycznego

18.1.2. Główne warstwy platformy SOA Jak w ie lo k ro tn ie p is a liś m y , w s p ó łc ze s n a S O A to w isto cie ro z p ro s z o n y m o d e l a rc h ite k to n ic z n y , z b u d o w a n y z u ż y c ie m u s łu g s ie c io w y c h . Ś ro d o w is k o p ro g ra m is ty c z n o -w y k o n a w c z e d la p o trz e b S O A p o w in n o w ię c być u k ie ru n k o w a n e n a ro z p ro s z o n ą a rc h ite k tu rę p ro g ra m is ty c z n ą dostarczającą w s p a rc ie d la te c h n o lo g ii u s łu g s ie c io w y c h . Staje się to ź r ó d łe m d w ó c h n o w y c h w y m a g a ń : •

z d o ln o ś c i do p a rty c jo n o w a n ia tw o rz o n e g o p ro g r a m u n a s a m o w y s ta rc za ln e i k o m p o n o w a ln e je d n o s tk i lo g ik i p r z e tw a r z a n ia (k o m p o n e n ty ) z d o ln e do w z a je m n e g o k o m u n ik o w a n ia się ze sobą, w ra m a c h te j sam ej in s ta n c ji p r o g r a m u i m ię d z y r ó ż n y m i in s ta n c ja m i;

•

z d o ln o ś c i do e n k a p s u lo w a n ia i e k s p o n o w a n ia lo g ik i a p lik a c ji z g o d n ie ze s ta n d a rd a m i te c h n o lo g ii u sług s ie c io w y c h .

O z n a c z a to w z b o g a c e n ie naszego p o d s ta w o w e g o m o d e lu o n o w e w a rs tw y w y n ik a ją c e z p o ­ w y ż s z y c h w y m a g a ń , co p o k a z a n o n a ry s u n k u 18.2.

566

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Rysunek 18.2. Podstawowe warstwy środowiska programistyczno-wykonawczego zdolnego do budowania SOA

18.1.3. Warstwy SOA a technologie W p ro w a d z a ją c k o m p o n e n ty i u s łu g i s iecio w e do n aszego m o d e lu a rc h ite k to n ic z n e g o , s p o w o d o ­ w a liś m y z a is tn ie n ie w ty m m o d e lu r o z m a ity c h re la c ji m ię d z y je g o f u n d a m e n ta ln y m i w a r s tw a m i a te c h n o lo g ia m i w p ro w a d z a n y m i p rz e z fr a m e w o r k u s łu g s ie c io w y c h , ta k im i ja k W S D L , S O A P , U D D I i ro z s z e rz e n ia W S - * . B y le p ie j z ro z u m ie ć tę d y n a m ik ę naszego m o d e lu , p rz e a n a liz u jm y p o k ró tc e w y m a g a n ia k ry ją c e się za p o s z c z e g ó ln y m i je g o re la c ja m i. •

W a r s tw a te c h n o lo g ii w e b o w y c h p o w in n a d o s ta rc za ć w s p a rc ie d la te c h n o lo g ii p ie rw s ze j g e n e ra c ji u słu g s ie c io w y c h , u m o ż liw ia ją c y c h b u d o w a n ie p ie rw o tn e j S O A .

•

W a r s tw a te c h n o lo g ii w e b o w y c h p o w in n a d o s ta rc za ć w s p a rc ie d la s p e c y fik a c ji W S - * , k o n ie c z n e d la re a liz a c ji w y b ra n y c h cech w s p ó łc ze s n e j S O A .

•

W a r s tw a te c h n o lo g ii w e b o w y c h p o w in n a d o s ta rc za ć ś ro d k i do z e s ta w ia n ia i im p le m e n to w a n ia s w y c h e le m e n tó w w s p a rc ia d la te c h n o lo g ii u s łu g s ie c io w y c h .

•

W a r s tw a te c h n o lo g ii k o m p o n e n to w y c h p o w in n a u m o ż liw ia ć e n k a p s u lo w a n ie lo g ik i w p o staci u słu g sie c io w y c h .

•

W a rs tw a m e c h a n iz m ó w w y k o n a w c z y c h p o w in n a b y ć z d o ln a do h o s to w a n ia k o m p o n e n tó w i u słu g sie cio w yc h .

•

W a rs tw a m e c h a n iz m ó w w y k o n a w c z y c h p o w in n a d o s ta rc za ć in te rfe js y A P I n a u ż y te k k o m p o n e n tó w i u s łu g s ie c io w y c h .

•

W a r s tw a in te rfe js ó w A P I p o w in n a d o s ta rc za ć fu n k c je u m o ż liw ia ją c e tw o rz e n ie i p rz e tw a rz a n ie k o m p o n e n tó w i u s łu g s ie c io w y c h .

G ra fic z n e p rz e d s ta w ie n ie p o w y ż s z y c h re la c ji w id o c z n e je s t n a r y s u n k u 18.3.

1 8 .1 . PLA TFO R M Y SOA

567

Rysunek 18.3. Struktura zależności między rdzennymi częściami architektury zorientowanej na usługi

18.1.4. Fundamentalna architektura technologiczna usług Z id e n ty fik o w a liś m y ju ż p o d s ta w o w e e le m e n ty skła d a ją c e się n a fu n d a m e n ta ln ą a b s tra k c y jn ą a r ­ c h ite k tu rę z o rie n to w a n ą n a u s łu g i; ty m je d n a k , co d la nas s zc ze g ó ln ie in te re s u ją c e , jest sp e c y fik a re lacji m ię d z y w a rs tw a m i te c h n o lo g ii w e b o w y c h i te c h n o lo g ii k o m p o n e n to w y c h . S tu d iu jąc tę relację, m o ż e m y n au czy ć się w ie le w k w e s tii p ro je k to w a n ia u s łu g -w n io s k o d a w c ó w i u s łu g -d o s ta rc zy c ie li, co p o z w o li n a z d e fin io w a n ie a rc h ite k tu r y n a p o z io m ie usług. Z a d a n ia w y k o n y w a n e p r z e z u s łu g i Jak w ie m y z le k tu r y p o p rz e d n ic h r o z d z ia łó w , o d u s łu g i-d o s ta rc z y c ie la o c z e k u je się w y k o n y w a n ia n a s tę p u ją c y c h zad ań : •

d o s ta rc z e n ia p u b lic z n e g o in te rfe js u (w p o s ta c i d e fin ic ji W S D L ) za p e w n ia ją c e g o o d n a jd y w a n ie u s łu g i i w y w o ły w a n ie je j p rz e z p o te n c ja ln e u s łu g i-w n io s k o d a w c ó w ,

•

o d b ie ra n ia k o m u n ik a tó w S O A P w y s y ła n y c h do u s łu g i p rz e z w n io s k o d a w c ó w ,

568

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

•

p rz e tw a rz a n ia b lo k ó w n a g łó w k o w y c h k o m u n ik a tó w S O A P ,

•

w e ry fik o w a n ia i p r z e tw a r z a n ia ła d u n k u u ży te c zn e g o o trz y m y w a n y c h k o m u n ik a tó w S O A P ,

•

k o n w e rto w a n ia tre ś c i ła d u n k u u ży te c zn e g o k o m u n ik a tó w n a in n e fo rm a ty ,

•

e n k a p s u lo w a n ia b izn e s o w e j lo g ik i p rz e tw a rz a n ia tre ś c i ła d u n k u u ży te c zn e g o k o m u n ik a tó w ,

•

k o n s tru o w a n ia k o m u n ik a tó w S O A P z a w ie ra ją c y c h o d p o w ie d z i n a k o m u n ik a ty -ż ą d a n ia o trz y m y w a n e o d u s łu g -w n io s k o d a w c ó w ,

•

p rz y w ra c a n ia tre ś c io m k o m u n ik a tó w o ry g in a ln e g o fo r m a tu , w y m a g a n e g o p rz e z u s łu g i-w n io s k o d a w c ó w ,

•

w y s y ła n ia k o m u n ik a tó w o d p o w ie d z i do u s łu g -w n io s k o d a w c ó w .

U s łu g i-d o s ta rc z y c ie le is tn ie ją p o to , b y r e a liz o w a ć ż ą d a n ia u s łu g -w n io s k o d a w c ó w ; u s łu g ą -w n io s k o d a w c ą m o ż e w ię c b y ć d o w o ln a p o rc ja o p r o g ra m o w a n ia z d o ln a do k o m u n ik o w a n ia się z usługam i-dostarczycielam i. T yp o w e zadania, realizacji k tó ry c h oczekuje się od usługi-w nioskodaw cy, to: •

e n k a p s u lo w a n ie lo g ik i b izn e s o w e j z w ią z a n e j z w y w o ły w a n ie m u s łu g i-d o s ta rc z y c ie la w o k re ś lo n y m celu,

• •

in terp re to w a n ie (ew entualnie po u p rz e d n im odn alezien iu ) d efin icji W S D L usługi-dostarczyciela, k o n s tru o w a n ie k o m u n ik a tó w -ż ą d a ń S O A P (w ra z w y m a g a n y m i n a g łó w k a m i) z g o d n ie z d e fin ic ją W S D L u s łu g i-d o s ta rc z y c ie la ,

•

tra n s fo rm o w a n ie tre ś c i k o m u n ik a tó w -ż ą d a ń S O A P n a fo r m a t z g o d n y z o c z e k iw a n ia m i

•

w y s y ła n ie k o m u n ik a tó w -ż ą d a ń S O A P do u s łu g -d o s ta rc z y c ie li,

•

o trz y m y w a n ie k o m u n ik a tó w -o d p o w ie d z i S O A P o d u s łu g -d o s ta rc z y c ie li,

•

w e ry fik o w a n ie i p rz e tw a rz a n ie ła d u n k u u ży te c zn e g o k o m u n ik a tó w -o d p o w ie d z i S O A P

u s łu g -d o s ta rc z y c ie li,

o trz y m y w a n y c h o d u s łu g -d o s ta rc zy c ie li, •

k o n w e rto w a n ie ła d u n k u u ż y te c z n e g o k o m u n ik a tó w S O A P n a in n e fo rm a ty ,

•

p rz e tw a rz a n ie b lo k ó w n a g łó w k ó w S O A P z a w a rty c h w k o m u n ik a ta c h .

W e w n ę t r z n a lo g ik a u s łu g i S poglądając n a pow yższą listę za d a ń , m o ż n a zauw ażyć, że p ra w ie w szystkie w y k o rzy s tu ją technologie u słu g s ie c io w y c h — „ p ra w ie ” , b o je d n o z n ic h ( w k a ż d e j g ru p ie ) je s t w ty m w z g lę d zie w y ją tk ie m . T o p rz e tw a rz a n ie lo g ik i b iz n e s o w e j, c z y li w y k o rz y s ty w a n ie tre ś c i ż ą d a n ia S O A P do w y k o n a n ia p e w n e j fu n k c ji i z w ra c a n ie o d p o w ie d z i zale żn e j o d re z u lta tó w tego w y k o n a n ia . P o g ru p u jm y z a te m w y m ie n io n e w c ze ś n ie j z a d a n ia o b u r o d z a jó w u s łu g — d o s ta rc z y c ie la i w n io s k o d a w c y — n a d w ie n a s tę p u ją ce k a te g o rie . •

L o g ik a p r z e tw a r z a n ia k o m u n ik a tó w — to część u s łu g i sieciow ej i otaczającego ją ś ro d o w is k a , o d p o w ie d z ia ln a za w y k o n y w a n ie ro z m a ity c h z a d a ń z w ią z a n y c h z p rz e tw a rz a n ie m k o m u n ik a tó w S O A P . L o g ik a p r z e tw a r z a n ia k o m u n ik a tó w r e a liz o w a n a je s t p rz e z k o m b in a c je u słu g w e w n ę trz n y c h , a g e n tó w usłu g , ja k r ó w n ie ż lo g ik i u s łu g i z w ią z a n e j z p rz e tw a rz a n ie m d e fin ic ji W S D L .

1 8 .1 . PLA TFO R M Y SOA

•

569

L o g ik a b iz n e so w a — to zaplecze usługi, w y k o n u ją c e za d a n ia stanow iące reakcję n a o trzy m a n ie k o m u n ik a tu S O A P . L o g ik a bizn e s o w a jest specyficzna d la a p lik a c ji i m o że m ie ć z ró żn ic o w a n y zakres, z a le ż n ie o d fu n k c jo n a ln o ś c i e k s p o n o w a n e j p rz e z d e fin ic ję W S D L . M o ż e w ię c b y ć n a p r z y k ła d s k u p io n a w je d n y m k o m p o n e n c ie , r e a liz u ją c y m fu n k c ję s p e c y fic z n ą d la u s łu g i, lecz ró w n ie d o b rz e m o ż e m ie ć r o z m ia r k o m p le tn e j tra d y c y jn e j a p lik a c ji, o fe ru ją c e j n ie k tó re swe fu n k c je p o p rz e z usługę s ie c io w ą .

UWAGA Nie należy mylić „logiki biznesowej" z „usługą biznesową". Każda usługa, zarówno biznesowa, jak i aplikacyjna, posiada wewnętrzną logikę biznesową.

S p o g ląd ając z tej p e rs p e k ty w y n a u s łu g ę -d o s ta rc z y c ie la , m o ż e m y p o d z ie lić je j lo g ik ę w sposób p o k a z a n y n a ry s u n k u 18.4. Komunikatżądanie SOAP

H * —

M~ Komunikatod powiedz SOAP Usługa-dostarczyciel

Rysunek 18.4. Usługa-dostarczyciel jako zespól przetwarzania komunikatów i logiki biznesowej

Z a p re z e n to w a n ą w c ze ś n ie j listę z a d a ń u s łu g i-d o s ta rc z y c ie la m o ż e m y w ię c p o d z ie lić w sposób p rz e d s ta w io n y w ta b e li 18.1. Tabela 18.1. Kategoryzacja logiki usługi-dostarczyciela Logika p rz etw a rza n ia k o m u n ik ató w

Logika biznesow a

O db ieran ie i w ysyłanie k o m u n ik a tó w SO AP

Specyficzna dla aplikacji logika biznesow a

Przetw arzanie nagłów ka k o m u n ik a tu SOAP W eryfikacja i p rzetw arzanie nagłów ków SOAP K onw ertow anie ła d u n k u u żytecznego k o m u n ik a tu SOAP

K a te g o rie te u w z g lę d n ia ją je d y n ie lo g ik ę , w ty m lo g ik ę z w ią z a n ą z p r z e tw a r z a n ie m d e fin ic ji W S D L — ale co z s a m ą d e fin ic ją W S D L ? P rze c ie ż te n k ry ty c z n y e le m e n t k a ż d e j u s łu g i m u s i b yć w y ra ź n ie id e n ty fik o w a n y , ja k o że m a z n a c zą c y w p ły w n a lo g ik ę p rz e tw a rz a n ia p rz e z n ią o d b ie ra ­ n y c h i w y s y ła n y c h k o m u n ik a tó w . A b y s p ra w ę u p ro ś c ić , p o łą c z y m y d e fin ic ję W S D L z in n y m i d o ­ k u m e n ta m i m e ta d a n y c h — m ię d z y in n y m i z a ło ż e n ia m i p o lity k i i s c h e m a ta m i X S D — w p o je ­ d y n c z y o b ie k t z w a n y p u n k te m k o ń c o w y m ( e n d p o in t) .

570

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

UWAGA Pojęcie „punktu końcowego" jest odmiennie rozumiane przez różnych dostaw ców platform. W tej książce za „punkt końcowy" uważać będziemy implementację metadanych stanowiącą techniczny kontrakt usługi. Samo pojęcie punktu końcowego wiążemy przy tym jedynie z usługami-dostarczycielami; w odniesieniu do usług-wnioskodawców jest ono znacznie mniej interesujące — i to niezależnie od faktu, że usługa-wnioskodawca może być pełnopraw ną usługą sieciową, czyli w innych warunkach w ystępow ać może w roli dostarczyciela.

L o g ic z n e u m ie js c o w ie n ie p u n k tu k o ń c o w e g o u s łu g i p rz e d s ta w io n o n a ry s u n k u 18.5. Jak w i ­ dać, n ie p la s u je się o n n a czele lo g ik i p r z e tw a r z a n ia , le c z u m o c o w a n y je s t g d zie ś w je j w n ę trz u ; jest ta k d la te g o , że n ie k tó re z k o m p o n e n tó w z a a n g a żo w a n e w lo g ik ę p rz e tw a rz a n ia k o m u n ik a tó w m o g ą b y ć a k ty w o w a n e w c z e ś n ie j, z a n im jeszcze n a d c h o d z ą c y k o m u n ik a t u zy s k a k o n ta k t z p u n k ­ te m k o ń c o w y m u s łu g i (czego p rz y k ła d p rz e d s ta w im y d a le j w ty m p o d ro z d z ia le , p r z y o m a w ia n iu a g e n tó w u s łu g ).

Komunikatżądanie SOAP

M <

—

M Komunikatod powiedź SOAP Usluga-dostarczyciel Rysunek 18.5. Zrewidowany model usługi-dostarczyciela, uwzględniający punkt końcowy wewnątrz logiki przetwarzania komunikatów

Z o b a c z m y te ra z , ja k się s p ra w y m a ją w p r z y p a d k u u s łu g i-w n io s k o d a w c y . Jak w y n ik a z r y s u n ­ k u 1 8.6, z a s a d n ic z ą cechą, k tó r a o d ró ż n ia ją o d u s łu g i-d o s ta rc z y c ie la , je s t ro la lo g ik i b izn e s o w e j: lo g ik a b izn e s o w a u s łu g i-w n io s k o d a w c y o d p o w ie d z ia ln a jest za z a in ic jo w a n ie a k ty w n o ś c i (i z w ią z a ­ nej z n ią w y m ia n y k o m u n ik a tó w S O A P ), p o d c za s g d y ro lą lo g ik i b izn e s o w e j u s łu g i-d o s ta rc z y c ie la jest re a g o w a n ie n a a k ty w n o ś ć j u ż z a in ic jo w a n ą . W ta b e li 18.2 p o n o w n ie p r z e d s ta w ia m y z a d a n ia u s łu g i-w n io s k o d a w c y , ty m ra z e m w fo r m ie s k ró c o n e j i w p o d z ia le n a d w ie k a te g o rie . L o g ik a p r z e tw a r z a n ia k o m u n ik a t ó w P rz y jrz y jm y się te ra z ty p o w e j p o staci lo g ik i p rz e tw a rz a n ia k o m u n ik a tó w w u s łu d z e -d o s ta rc z y c ie lu i u s łu d z e -w n io s k o d a w c y . N a lo g ik ę tę s k ła d a ją się z a d a n ia w y k o n y w a n e p rz e z k o m b in a c je u sług w e w n ę trz n y c h i ro z s ze rz e ń s p e c y fic z n y c h d la a p lik a c ji, n ie m o ż n a w ię c w y ra ź n ie w y o d rę b n ić e le m e n tó w n a le żą c y c h w y łą c z n ie do sam ej u sługi.

1 8 .1 . PLA TFO R M Y SOA

571

Usługa-dostarczyciel

Rysunek 18.6. Usługa-wnioskodawca w podziale na logikę biznesową i logikę przetwarzania komunikatów Tabela 18.2. Kategoryzacja logiki usługi-wnioskodawcy Logika p rz e tw a rz a n ia k o m u n ik a tó w

Logika b izn es o w a

In terp re to w an ie definicji W SD L

Specyficzna dla aplikacji logika biznesow a

(po ew entualnym u p rz ed n im jej odnalezieniu) O db ieran ie i w ysyłanie k o m u n ik a tó w SOAP P rzetw arzanie nagłów ka k o m u n ik a tu SO A P W eryfikacja i p rzetw arzanie nagłów ków SOAP K onw ertow anie ła d u n k u u żytecznego k o m u n ik a tu SOAP

W p rz y k ła d z ie p rz e d s ta w io n y m n a ry s u n k u 18.7 p rz e d s ta w iliś m y lo g ik ę p rz e tw a rz a n ia k o ­ m u n ik a tó w p rz e z u s łu g ę -d o s ta rc z y c ie la w p o d z ia le w a rs tw o w y m . Są w ś ró d ty c h w a rs tw z a d a n ia o c h a ra k te rz e g e n e ry c z n y m , id e n ty c z n e d la w s z y s tk ic h u s łu g -d o s ta rc z y c ie li — n a p rz y k ła d p rz e ­ tw a rz a n ia n a g łó w k a k o m u n ik a tu . D la o d m ia n y , w a lid a c ja i k o n w e rto w a n ie d a n y c h m ię d z y fo r­ m a ta m i to za d a n ia specyficzne d la k o n k re tn e j usługi, obejm u jące (n a p rz y k ła d ) specyficzne schem aty X S D i specyficzne arkusze s ty ló w X S L T (je ż e li n a w e t w s p o m n ia n e z a d a n ia w a lid a c ji i tra n s fo rm a c ji w y k o n y w a n e są p rz e z g en eryczn e p ro c e s o ry ).

572

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Rysunek 18.7. Przykład różnych typów funkcji składających się na logikę przetwarzania komunikatów w usłudze

M im o iż w o b u ty p a c h usług — d o starczyciela i w n io s k o d a w c y — lo g ik a p rz e tw a rz a n ia k o m u n i­ k a tó w w yg lą d a p o d o b n ie , p o ja w ia ją się ró żn ic e n a p o z io m ie je j im p le m e n ta c ji. U s łu g a-d o starczyciel u d o s tę p n ia p u n k t k o ń c o w y , w y ra ż a ją c y in te rfe js usłu g i o ra z zw ią z a n e z n ią o g ra n ic ze n ia , do k tó ry c h stosow ać się m u s zą w szyscy p o te n c ja ln i w n io s k o d a w c y . D o s ta w c y p la tfo r m o d z w ie rc ie d la ją te n fa k t w p o s ta c i w s p a rc ia d la tw o r z e n ia k o m p o n e n tó w p ro x y . K o m p o n e n ty te s ta n o w ią część lo g ik i p rz e tw a rz a n ia k o m u n ik a tó w (ta k ja k n a ry s u n k u 18.8) i z a zw y c z a j g e n e ro w a n e są a u to m a ty c z n ie n a p o d s ta w ie d e fin ic ji W S D L (i to w a rz y s z ą c y c h je j d o ­ k u m e n tó w ). Są o n e k o ń c o w ą częścią p ro g ra m is ty c z n e g o in te rfe js u o d z w ie rc ie d la ją c e g o d e fin ic ję W S D L i je d n o c z e ś n ie zg o d n e g o z n a ty w n y m ś ro d o w is k ie m d o staw cy. K o m p o n e n ty p ro x y o d b ie ra ją w y w o ła n ia s w y c h m e to d p o c h o d zą c e z in n y c h k o m p o n e n tó w p la tfo rm y , re a liz u ją c y c h lo g ik ę b izn e s o w ą usług. N a s tę p n ie w y k o rz y s tu ją usłu g i w e w n ę trz n e p la t­ fo rm y do tra n s la c ji ty c h w y w o ła ń (i to w a rz y s z ą c y c h im p a r a m e tr ó w ) n a k o m u n ik a ty S O A P . G d y n a d e jd z ie k o m u n ik a t-o d p o w ie d ź , k o m p o n e n ty p r o x y o d b ie ra ją go i p o d d a ją tra n s la c ji w o d w r o t­ n y m k ie ru n k u .

UWAGA Komponenty proxy mogą mieć charakter statyczny lub mogą być tworzone dynamicznie. W podrozdziałach poświęconych platformom J2EE i .NET omówimy szczegółowo komponenty proxy charakterystyczne dla tych platform.

1 8 .1 . PLA TFO R M Y SOA

573

Rysunek 18.8. Część logiki przetwarzania komunikatów obejmująca komponent proxy

L o g ik a b iz n e s o w a Jak w c ze ś n ie j w y ja ś n ia liś m y , lo g ik a b iz n e s o w a m o ż e is tn ie ć w p o s ta c i s a m o d z ie ln e g o k o m p o ­ n e n tu , p o s iad a jąceg o in te lig e n c ję w y m a g a n ą do w y w o ły w a n ia ( w ra m a c h a k ty w n o ś c i b iz n e s o w e j) u s łu g i-d o s ta rc z y c ie la i (lu b ) re a g o w a n ia n a w y w o ła n ia ze s tro n y u s łu g -w n io s k o d a w c ó w u c z e s tn i­ cząc ych w ta k ie j a k ty w n o ś c i. L o g ik a b iz n e s o w a , ja k o n ie z a le ż n a je d n o s tk a , m o ż e w c ie la ć się w ró ż n e ro le . W p r z y k ła d z ie n a ry s u n k u 1 8 .9 p o k a z a n o ta k ą je d n o s tk ę p a r ty c y p u ją c ą z a r ó w n o w u s łu d z e -w n io s k o d a w c y , ja k i u s łu d z e -d o s ta rc z y c ie lu . Usługa-wnioskodawca

L o g ik a b iz n e s o w a

Usługa-dostarczyciel

L o g ik a p rz e tw a rz a n ia k o m u n ik a tó w

L o g ik a b iz n e s o w a

Usługa-dostarczyciel

Usługa-wnioskodawca

Rysunek 18.9. Jednostka logiki biznesowej partycypującą w dwu usługach — dostarczycielu i wnioskodawcy

574

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

G d y je d n o s tk i lo g ik i b iz n e s o w e j is tn ie ją w p o s ta c i o d d z ie ln y c h k o m p o n e n tó w , ta s a m a je d ­ n o s tk a m o ż e b y ć e n k a p s u lo w a n a p r z e z w ie le u s łu g -d o s ta rc z y c ie li, czego p r z y k ła d p o k a z a n o n a ry s u n k u 18 .1 0 .

Usługa-wnioskodawca

Usługa-wnioskodawca

Rysunek 18.10. Jednostka logiki biznesowej enkapsulowana przez dwie usługi-dostarczycieli

P o n ie w a ż je d n o s tk i lo g ik i b iz n e s o w e j m o g ą is tn ie ć w p o s ta c i k o m p o n e n tó w r o z p ro s z o n y c h w n a ty w n y m fo rm a c ie , m o g ą o n e n a w ią z y w a ć in te ra k c je z in n y m i k o m p o n e n ta m i, k tó re n ie k o ­ n ie c z n ie m u s z ą b y ć częścią S O A — s y m b o lic z n ie p o k a z a n o to n a ry s u n k u 1 8 .1 1 . F a k ty c z n ie , to m o d e l ro z p o w s z e c h n io n y w ty c h ś ro d o w is k a c h ro z p ro s z o n y c h , g d zie k o m p o n e n ty (a n ie u s łu g i) k o m p o n o w a n e są w celu re a liz a c ji o k re ś lo n y c h z a d a ń w im ie n iu u s łu g i-d o s ta rc z y c ie la . Usługa-wnioskodawca

________________________

.

K om unikat-

Usługa-dostarczyciel

______________ ______________ ______________ ______________ ______

Rysunek 18.11. Jednostka logiki biznesowej enkapsulowana przez usługę-dostarczyciela i jednocześnie współdziałająca z niezależnym komponentem

1 8 .1 . PLA TFO R M Y SOA

575

Z a u w a ż m y , że w p r z y k ła d z ie z r y s u n k u 1 8 .1 1 lo g ik a b iz n e s o w a u s łu g i m o ż e w s p ó łd z ia ła ć z o s o b n y m n a ty w n y m k o m p o n e n te m w celu re a liz a c ji p rz e tw a rz a n ia w y m a g a n e g o p rz e z u s łu g ę w n io s k o d a w c ę . W ty m p rz y p a d k u n a ty w n y k o m p o n e n t m o ż e b y ć u w a ż a n y za część o g ó ln e j lo g ik i a u to m a ty z a c ji e n k a p s u lo w a n e j p rz e z u s łu g ę -w n io s k o d a w c ę . A g e n t y u s łu g P o w s ze c h n ie s p o ty k a n y m ty p e m o p ro g ra m o w a n ia z a a n g a ż o w a n y m w lo g ik ę p rz e tw a rz a n ia k o ­ m u n ik a tó w n a p la tfo rm a c h S O A są a g e n ty u s łu g (se rv ice a g e n ts ). P o d s ta w o w y m z a d a n ie m ta k ie g o a g en ta je s t w y k o n a n ie p e w n e j f o r m y z a u to m a ty z o w a n e g o p rz e tw a rz a n ia tu ż p rz e d w y s ła n ie m lu b n a ty c h m ia s t p o o d e b ra n iu k o m u n ik a tu S O A P . A g e n t u s łu g i je s t w ię c p e w n ą fo r m ą u s łu g i p o ­ śred n iczącej. W p r z y p a d k u u s łu g i- w n io s k o d a w c y je j a g e n t p r z e jm u je k o m u n ik a t - ż ą d a n ie b e z p o ś r e d ­ n io p o w y s ła n iu go p r z e z u s łu g ę , le c z je s z c z e p r z e d je g o f iz y c z n y m p r z e tr a n s m ito w a n ie m do u s łu g i-d o s ta rc z y c ie la . G d y n a d c h o d z i k o m u n ik a t-o d p o w ie d ź , a g e n t p r z e jm u je go p rz e d p r z e ­ k a z a n ie m sw ej u s łu d z e . A n a lo g ic z n ie m a się rzecz w p rz y p a d k u agenta usługi-dostarczyciela: je j agent p rz e jm u je n a d c h o ­ d zący k o m u n ik a t-ż ą d a n ie p rze d p rz e k a za n ie m go u słudze, p o d o b n ie w y s ła n y p rze z usługę k o m u n ik a t-o d p o w ie d ź p rz e jm o w a n y jest p rze z agenta p rze d fiz y c zn y m o d esłan iem do usłu g i-w n io s k o d a w c y . A g e n ty u s łu g w y m y ś lo n o ja k o g e n e ry c z n y ś ro d e k u w a ln ia n ia s a m y c h u s łu g s ie c io w y c h o d ro z w ią z y w a n ia n ie ty p o w y c h p r o b le m ó w o ra z o d w y k o n y w a n ia p e w n y c h p o p u la r n y c h z a d a ń , m ię d z y in n y m i: •

p rz e tw a rz a n ia n a g łó w k ó w S O A P (p a tr z ry s u n e k 1 8 .1 2 ),

•

f iltr o w a n ia (b a zu ją c e g o n a n a g łó w k u S O A P lu b tre ś c i ła d u n k u u ż y te c z n e g o ),

•

u w ie rz y te ln ia n ia i w a lid a c ji w o p a rc iu o treść k o m u n ik a tu ,

•

re je s tro w a n ia z d a rz e ń i a u d y tu ,

•

tra s o w a n ia .

P ro g ra m -a g e n t je s t n ajczęściej s k ro m n ą a p lik a c ją o n ie w ie lk ic h w y m a g a n ia c h p a m ię c io w y c h . D o s ta rc z a n y je s t z w y k le ja k o część ś ro d o w is k a w y k o n a w c z e g o , le c z — o c zy w iś c ie — m o ż e te ż b yć s k o n s tru o w a n y ad h o c w z w ią z k u z b ie ż ą c y m i p o trz e b a m i.

UW AGA Skoro więc zarówno agent usługi, jak i pośrednicząca usługa sieciowa spełniają to samo zadanie, jaka jest między nimi różnica? Podstawowym czynnikiem rozstrzygającym w tej kwestii jest zwykle dostępność punktu końcowego WSDL: agenty usług zwykle takow ego nie posiadają, bo zaprojektowano je do przechwytywania komunikatów w sposób samoczynny i automatyczny. Oczywiście, może być i tak, że pełnoprawna usługa sieciowa, z w łasną publiczną definicją WSDL (stanowiącą punkt końcowy) spełnia rolę agenta innej usługi (jako jedną z kilku swoich ról) — wów czas agent usługi widoczny jest jako jawny punkt końcowy na trasie komunikatu.

576

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Rysunek 18.12. Agenty usług wykonujące przetwarzanie nagłówków SOAP w odbieranych i wysyłanych komunikatach

18.1.5. Platformy dostawców P rz e c h o d z im y te ra z do p rz e g lą d u w s p a rc ia d la S O A n a d w ó c h w y m ie n ia n y c h ju ż w ie lo k ro tn ie p la tfo rm a c h — J2EE i .N E T . W d w ó c h n a s tę p n y c h p o d ro z d z ia ła c h o p is u je m y k o le jn o następujące asp e k ty k a ż d e j z n ic h : •

k o m p o n e n ty a rc h ite k tu ry ,

•

ś ro d o w is k o w y k o n a w c z e ,

•

d o stęp n e ję z y k i p ro g r a m o w a n ia ,

•

in te rfe js y A P I,

•

u s łu g i-d o s ta rc z y c ie li,

•

u s łu g i-w n io s k o d a w c ó w ,

•

a g e n ty usług,

•

ro z s z e rz e n ia p la tfo rm y .

1 8 .2 . SO A N A PLA TFO R M IE J2EE

577

P o n ie w a ż s zczeg ó ły w y m ie n io n y c h p la tfo r m e k s p lo ro w a ć b ę d z ie m y z p e rs p e k ty w y z a ró w n o s ta n d a rd ó w , ja k i te c h n o lo g ii p o s z c z e g ó ln y c h d o s ta w c ó w im p le m e n tu ją c y c h te s ta n d a rd y , w tr e ­ ści r o z d z ia łu p o ja w ią się n a z w y p rz y k ła d o w y c h p r o d u k tó w w y k o rz y s ty w a n y c h do re a liz a c ji o k re ­ ś lo n y c h e le m e n tó w fu n k c jo n a ln y c h d a n e j p la tfo rm y . C h o ć d o ło ży liśm y w szelkich starań, b y o b ie k ty w n ie i sp raw ied liw ie ro zp a try w a ć do k u m e n ta c ję obu p la tfo rm , to je d n a k ob ie d o k u m e n ta c je n a le ż y p o tra k to w a ć o d m ie n n ie z p o d s ta w o w e j p rz y c z y n y — zró żn ic o w a n e g o w s p arc ia dostaw ców : J2EE je s t p la tfo rm ą w s p ie ra n ą p rz e z w ie lu d o s ta w c ó w , w y ­ m ie n ia m y w ięc p rz y k ła d o w e p ro d u k ty w ie lu dostaw ców , w p rz y p a d k u .N E T dostaw ca jest ty lk o je d e n .

18.2. SOA na platform ie J2EE J2EE — J a v a 2 P la tfo r m E n te rp ris e E d itio n — je s t je d n ą z d w ó c h g łó w n y c h p la tfo r m w y k o rz y s ty ­ w a n y c h o b e c n ie d o tw o r z e n ia r o z w ią z a ń k la s y e n te rp ris e z u ż y c ie m u s łu g s ie c io w y c h . W ty m p o d ro z d z ia le o p is u je m y n a jp ie r w p o k ró tc e te e le m e n ty J2EE , k tó re p o z o s ta ją w ja k ie jś re la c ji do S O A , nas tęp n ie p o w ra c a m y do d y s k u to w a n y c h ju ż w ie lo k ro tn ie zasad z o rie n to w a n ia n a u sługi o ra z cech p ie rw o tn e j i w sp ó łc ze s n e j S O A , ro z w a ż a ją c m o ż liw o ś c i ic h re a liz a c ji p r z y u ż y c iu w s p o m n ia ­ n y c h e le m e n tó w . N ie d o k o n u je m y tu b y n a jm n ie j ja k ie g o ś s y s te m a ty c zn e g o p rz e g lą d u m o ż liw o ś c i J2EE. N ie z a jm u je m y się te ż tw o r z e n ie m u s łu g s ie c io w y c h w ję z y k u Java — te j c ie k a w e j te m a ty c e p o ś w ię c o ­ n y c h zo s ta ło w ie le k s ią ż e k (n ie k tó re z n ic h r e k o m e n d u je m y n a s tro n ie w w w .s e rv ic e o rie n te d .w s ). N a s z y m c e lem je s t w y łą c z n ie e k s p lo ra c ja m o ż liw o ś c i re a liz a c ji S O A i z te j w ła ś n ie p e rs p e k ty w y s p o g lą d a m y n a J2EE.

18.2.1. Ogólnie o platformie J2EE to n a rz ę d z ie p ro g ra m is ty c z n e i p la tfo r m a u r u c h o m ie n io w a b a z u ją c e n a ję z y k u Java. Jest to p la tfo rm a z e s ta n d a ry z o w a n a , w s p ie ra n a p rz e z w ie lu p r o d u c e n tó w n a rz ę d z i p ro g ra m is ty c z n y c h , s e rw e ró w e k s p lo a ta c y jn y c h i o p ro g ra m o w a n ia m id d le w a r e p rz e zn a c z o n e g o do tw o r z e n ia i w d r a ­ ż a n ia ro z w ią z a ń b u d o w a n y c h w Javie. Java 2 P la tfo r m to w isto cie ze s p ó ł trz e c h p la tfo r m p r o g r a m is ty c z n o -u ru c h o m ie n io w y c h , de­ d y k o w a n y c h ro z w ią z a n io m ró ż n y c h ty p ó w . J a v a 2 P la tfo r m S ta n d a r d E d itio n (J2SE) to n a rz ę d z ie do tw o rz e n ia a p lik a c ji d e s k to p o w y c h , p odczas g d y J a v a 2 P la tf o r m M ic r o E d itio n (J 2 M E ) u k ie ru n ­ k o w a n e jest n a tw o rz e n ie a p lik a c ji m o b iln y c h . J a v a 2 P la tfo r m E n te rp ris e E d itio n (J2E E ) to z a a w a n ­ sow ane ś ro d o w is k o do tw o rz e n ia w ie lk o s k a lo w y c h ro z w ią z a ń ro z p ro s z o n y c h — w c ią g u p o n a d p ię c iu la t swego is tn ie n ia 1 w y k o rzy s ty w a n e b y ło do b u d o w a n ia tra d y c y jn y c h a p lik a c ji n -w a rs tw o w y c h z a ró w n o z u życie m te ch n o lo g ii w e b o w yc h , ja k i b ez ic h udziału .

1 Pierwsza wersja J2EE — 1.2 — ujrzała światło dzienne w grudniu 1999 roku, zatem jak widać prezentow any tu przez autora m ateriał daleki jest już od aktualności. Twórca „Javy korporacyjnej” (bo tak nazywa się linia zapo­ czątkowanych wówczas produktów ) firm a Sun M icrosystems wykupiona została przez firm ę Oracle i zmieniła się również nazwa platform y — następca J2E E 1.4 oznaczony został akronim em Java E E 5, a najnowszym w tej chwili (lato 2013) wcieleniem wspom nianej platform y jest Java E E 7 . W śród wielu oferowanych nowości nie mogło — oczywiście — zabraknąć także znaczącego rozwoju wsparcia dla technologii usług sieciowych, Z ainte­ resowanym czytelnikom chciałbym więc polecić uzupełnienie lektury tego rozdziału o napisaną przez ekspertów z firm y Oracle książkę Java E E 6. Przewodnik. W ydanie I V , której polskie wydanie ukazało się jesienią 2012 roku nakładem w ydawnictwa Helion (http://helion.pl/ksiazki/jave64.htm) — przyp. tłum.

578

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

J2EE to ta k n a p ra w d ę k o m p o z y c ja w ie lu s k ła d n ik ó w , z u ży c ie m k tó ry c h b u d o w a ć m o ż n a w p e łn i fu n k c jo n a ln e ro z w ią z a n ia w e b o w e ; p r z y jr z y jm y się b liż e j ty m z n ic h , k tó re szczeg ó ln ie z w ią z a n e są z u s łu g a m i s ie c io w y m i. R y s u n e k 18.3 n ie je s t ilu s tra c ją re la c ji m ię d z y k o m p o n e n ta m i p la tfo r m y J2EE , p rz e d s ta w io n o n a n im je d y n ie w e w n ę trz n e w a rs tw y tej p la tfo rm y z a p e w n ia ją c e w sparcie d la tw o rz e n ia ro z w ią z a ń z o rie n to w a n y c h n a u s łu g i.

Rysunek 18.13. Wybrane warstwy platformy J2EE pozostające w relacji do SOA

P o tra k to w a n e łą c zn ie w a rs tw y s e rw le tó w , z ia re n EJB, k o n te n e ra EJB i J A X -R P C R u n tim e s u m a ­ ryczn ie o d p o w ia d a ją w a rs tw o m te c h n o lo g ii w e b o w y c h i te c h n o lo g ii k o m p o n e n to w y c h z ry s u n k u 18.2 — „ s u m a ry c z n ie ” , b o tr u d n o u s ta lić tu g ra n ic ę m ię d z y te c h n o lo g ia m i w e b o w y m i a k o m p o n e n to ­ w y m i — g ra n ic a ta z a le ż n a je s t o d s posob u, w ja k i k o n k r e tn y d o s ta w c a z re a liz o w a ł w s p o m n ia n e te c h n o lo g ie n a sw ej p la tfo r m ie J2EE. E le m e n ty w id o c z n e n a r y s u n k u 1 8 .1 3 p o w ią z a n e są ze sobą i in n y m i c z ę ś c ia m i ś ro d o w is k a J2EE w sposób p rz e d s ta w io n y n a ry s u n k u 1 8 .1 4 , tw o rz ą c ty m s a m y m p la tfo rm ę z d o ln ą d o r e a li­ z a c ji S O A . Z a n im p rz e jd z ie m y do o m a w ia n ia p o s z c z e g ó ln y c h k o m p o n e n tó w , w y m ie ń m y n a jp ie r w k ilk a k lu c zo w y c h specyfikacji J2EE. F irm a S un M ic ro s y s tem s o p u b lik o w a ła w ie le s ta n d a rd ó w o pisujących po szczeg ó ln e e le m e n ty J2EE , d o k tó ry c h to s ta n d a rd ó w m u s z ą stosow ać się p ro d u c e n c i im p le ­ m e n tu ją c y i b u d u ją c y p r o d u k ty z w ią z a n e z ty m ś ro d o w is k ie m . O to t r z y n a jw a ż n ie js z e s p o ś ró d w s p o m n ia n y c h s p e c y fik a c ji, o d n o szące się do S O A . •

J a v a 2 P la tf o r m E n te rp ris e E d itio n S p e c ific a tio n — ta w a ż n a s p e c y fik a c ja d e fin iu je ro z p ro s z o n ą a rc h ite k tu rę k o m p o n e n tó w J2EE o ra z fu n d a m e n ta ln e s ta n d a rd y , k tó ry c h re s p e k to w a n ie je s t d la d o s ta w c ó w k o n ie c z n e do re k la m o w a n ia s w y c h p r o d u k tó w ja k o „ z g o d n y c h z J 2E E ”.

1 8 .2 . SO A N A PLA TFO R M IE J2EE

579

Rysunek 18.14. Wzajemne powiązania części środowiska J2EE

•

J a v a A P I f o r X M L -b a s e d R P C (J A X -R P C ) — w ty m d o k u m e n c ie d e fin io w a n e jest ś ro d o w is k o J A X -R P C i z w ią z a n e z n im rd z e n n e in te rfe js y A P I. D e fin io w a n y je s t ta k że m o d e l p u n k tó w k o ń c o w y c h (S e rv ic e E n d p o in t M o d e l) w y k o rz y s ty w a n y do re a liz a c ji p u n k tu k o ń c o w e g o J A X -R P C ( J A X -R P C S e rv ic e E n d p o in t) — je d n e g o z p o d s ta w o w y c h ty p ó w u s łu g s ie c io w y c h J2EE (co w y ja ś n ia m y d a le j w ty m p o d ro z d z ia le ).

580

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

•

W e b S ervices f o r J 2 E E — ta s p e c y fik a c ja d e fin iu je p o d s ta w o w ą a rc h ite k tu rę u s łu g i J2EE, d o k o n u je w y ra ź n e g o je j p o d z ia łu n a e le m e n ty tw o rz o n e p rz e z p ro je k ta n ta o ra z im p le m e n to w a n e w sposób s p e c y fic z n y d la d o s ta w c y , a ta k ż e w y s z c z e g ó ln ia te je j e le m e n ty , k tó re m u s z ą c z y n ić za d o ś ć s ta n d a rd o m J2EE.

S p e c y fik a c ja ta d e fin iu je ta k ż e P o r t C o m p o n e n t M o d e l, k t ó r y m z a jm ie m y się w p o d p u n k c ie p o ś w ię c o n y m u s łu g o m -d o s ta rc z y c ie lo m . K o m p o n e n t y a r c h ite k to n ic z n e R o z w ią z a n ia tw o rz o n e za p o m o c ą J2EE są z n a tu r y ro z p ro s z o n e , m a ją w ię c s tru k tu rę k o m p o ­ n e n to w ą . D o b u d o w a n ia a p lik a c ji w e b o w y c h w y k o rz y s ty w a n e są n a s tę p u ją ce k o m p o n e n ty . •

J a v a S e rv e r P age s (JSPs) — g e n e ro w a n e d y n a m ic z n ie s tr o n y W W W h o s to w a n e n a s e rw e rz e W W W . M a ją fo r m ę p lik ó w te k s to w y c h z a w ie ra ją c y c h k o d Javy p r z e p la ta n y z n a c z n ik a m i H T M L .

•

S tr u ts — ro z s z e rz e n ie J2EE u m o ż liw ia ją c e tw o r z e n ie a p lik a c ji w e b o w y c h z w y r a fin o w a n y m i in te r fe js a m i u ż y tk o w n ik a i z a a w a n s o w a n ą n a w ig a c ją .

•

J a v a S erv le ts — s e rw le ty Javy, ró w n ie ż re z y d u ją c e n a s e rw e rze W W W , w y k o rz y s ty w a n e do p rz e tw a rz a n ia ż ą d a ń H T T P i g e n e ro w a n ia o d p o w ie d z i. W o d ró ż n ie n iu o d JSP m a ją postać s k o m p ilo w a n y c h p r o g ra m ó w .

•

E n te rp ris e J a v a B e a n s (EJB s) — k o m p o n e n ty b izn e s o w e w y k o n u ją c e w ię k s zą część p rz e tw a rz a n ia w ś ro d o w is k u k o rp o ra c y jn y m . W d r a ż a n e są n a d e d y k o w a n y c h s e rw e ra c h a p lik a c ji i o fe ru ją w ie le m e c h a n iz m ó w z k a te g o rii m id d le w a r e , m ię d z y in n y m i obsługę tra n s a k c ji.

K o m p o n e n ty d w ó c h p ie rw s z y c h z w y m ie n io n y c h g ru p o d p o w ie d z ia ln e są rac ze j za w a rs tw ę p re z e n ta c ji ro z w ią z a n ia z o rie n to w a n e g o n a u s łu g i, d w ie n a s tę p n e g ru p y w y k o rz y s ty w a n e są n a ­ to m ia s t do re a liz a c ji u sług s ie c io w y c h . Ś ro d o w is k o u r u c h o m ie n io w e Ś ro d o w is k o J2EE o p ie ra się n a s ta n d a rd o w y m ś ro d o w is k u u r u c h o m ie n io w y m Javy ( fo u n d a tio n J a v a r u n tim e ) do p r z e tw a rz a n ia k lu c z o w y c h części Javy d o w o ln e g o r o z w ią z a n ia J2EE. W c h a ra k ­ te rz e w s p a rc ia d la u słu g s ie c io w y c h J2EE u d o s tę p n ia d o d a tk o w e w a rs tw y w y k o n a w c z e i z w ią z a n e z n i m i in te r fe js y A P I (c o w y ja ś n ia m y d a le j w ty m p o d r o z d z ia le ); n a jb a r d z ie j w a r tą u w a g i je s t J A X -R P C r u n t im e , u s ta n a w ia ją c a fu n d a m e n ta ln e u s łu g i, w ty m w s p a rc ie d la k o m u n ik a c ji S O A P i p rz e tw a rz a n ia W S D L . P o n a d to im p le m e n ta c je J2EE o fe ru ją d w a n a s tę p u ją ce ty p y k o n te n e ró w , d o s ta rc z a ją c y c h ś ro ­ d o w is k a d la h o s to w a n ia a p lik a c ji u k ie ru n k o w a n y c h n a u s łu g i s iecio w e i b a z u ją c y c h g e n e ra ln ie n a EJB i s erw le tach . •

K o n te n e r EJB — z a p ro je k to w a n y s p e c ja ln ie do h o s to w a n ia k o m p o n e n tó w EJB, o fe ru ją c y szereg u s łu g n a p o z io m ie e n te rp ris e . U s łu g i te m o g ą b y ć w y k o rz y s ty w a n e p rz e z z ia rn a EJB u czestn iczące w ro z p ro s z o n y m w y k o n y w a n iu z a d a ń b izn e s o w y c h . W ś r ó d ty c h u sług w y m ie n ić m o ż n a p rz e d e w s z y s tk im za rzą d z a n ie tra n s a k c ja m i, z a rzą d z a n ie w s p ó łb ieżn o ś c ią , b e z p ie c z e ń s tw o n a p o z io m ie o p e ra c ji i z a rz ą d z a n ie p u la m i o b ie k tó w .

1 8 .2 . SO A N A PLA TFO R M IE J2EE

•

581

K o n te n e r w e b o w y — m o ż e b y ć u w a ż a n y z a ro z s ze rz e n ie s e rw e ra W W W ; w y k o rz y s ty w a n y je s t do h o s to w a n ia a p lik a c ji w e b o w y c h Javy, z a w ie ra ją c y c h k o m p o n e n ty JSP lu b s e rw le tó w . D o s ta rc z a u s łu g i w y k o n y w a ln e u k ie ru n k o w a n e n a p rz e tw a rz a n ie ż ą d a ń JSP i in s ta n c ji s e rw le tó w .

Jak w y ja ś n ia m y w p o d p u n k c ie p o ś w ię c o n y m u s łu g o m -d o s ta rc z y c ie lo m , o b a opisane k o n te n e ry m o g ą h o sto w ać u s łu g i sieciow e b azujące n a EJB lu b serw letach. W y k o n y w a n ie ty c h u sług w s p ie ra n e je s t p rz e z J A X -R P C . W e w n ę tr z n a lo g ik a k o n te n e ra , d e te rm in u ją c a k s z ta łt i fo rm ę lo g ik i p r z e tw a ­ rz a n ia k o m u n ik a tó w n a p o z io m ie sy s te m u , je s t s p e c y fic zn a d la k o n k re tn e g o d o staw cy.

UWAGA Dostawcy J2EE oferują kontenery jako integralną część swoich produktów serwerowych, tak więc kontenery te ustanawiają środowisko wykonawcze hostujące instancje oprogramowania serwerowego swych dostawców. Wśród dostępnych na rynku kontenerów wymienić należy serwer aplikacji ONE (Open Network Environment — otwarte środowisko sieciowe) firmy Sun, W ebsphere firmy IBM i OC4J (Oracle Application Server Containers for J2EE) firmy Oracle.

J ę z y k i p r o g r a m o w a n ia Z g o d n ie z n a z w ą , Java 2 P la tfo r m E n te rp ris e E d itio n o p ie ra się n a ję z y k u Java2. R ó ż n i d o s ta w c y o fe ru ją o d m ie n n e ś ro d o w is k a p ro g r a m is ty c z n e , u m o ż liw ia ją c e w y k o rz y s ty w a n ie te g o ję z y k a do tw o rz e n ia u słu g siec io w y c h .

UWAGA Przykładami wspom nianych narzędzi są Rational Application Developer firmy IBM, Java Studio firmy Sun Microsystems i JDeveloper firmy Oracle.

In te r f e js y A P I J2EE o fe ru je k ilk a A P I u d o s tę p n ia ją c y c h fu n k c je p rz y d a tn e do tw o r z e n ia u sług s ie c io w y c h . K la s y re a liz u ją c e te fu n k c je p o g ru p o w a n e są w f o r m y p a k ie tó w (p a c k a g e s ). P o n iż e j p rz e d s ta w ia m y k ilk a w y b ra n y c h A P I s zcze g ó ln ie z w ią z a n y c h z b u d o w a n ie m S O A . •

J a v a A P I f o r X M L P ro c e s s in g (J A X P ) — je s t w y k o rz y s ty w a n e do p rz e tw a rz a n ia treści d o k u m e n tó w X M L p r z y u ż y c iu k ilk u d o s tę p n y c h p a rs e ró w . W s p ie ra n e są z a ró w n o o b a ty p y m o d e li, c z y li D O M ( D o c u m e n t O b je c t M o d e l) i S A X (S im p le A P I f o r X M L ) , ja k i tra n s fo rm a c ja o ra z w a lid a c ja d o k u m e n tó w X M L za p o m o c ą a rk u s z y s ty ló w X S L T i s c h e m a tó w X S D . W ś r ó d p a k ie tó w klas s k ry w a ją c y c h się za ty m A P I z n a jd u ją się m ię d z y in n y m i:

2 Obecnie nie jest to już w całości prawdą: w irtualna m aszyna Javy (JVM) wykonywać m oże kod bajtowy p ro d u ­ kowany przez kom pilatory wielu innych języków (m iędzy innym i języków Scala i Groovy) — przyp. red.

582

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

•

j a v a x . x m l . p a r s e r s — z a w ie ra ją c y k la s y o fe ru ją c e p a rs e ry D O M i S A X spec y fic zn e

d la ró ż n y c h p ro d u c e n tó w ; •

o rg .w 3 c .d o m i o r g .x m l .s a x — e k s p o n u ją c e s ta n d a rd o w e m o d e le d o k u m e n to w e D O M

i SAX; • •

ja v a x .x m l .t r a n s f o r m — d o s ta rc za ją c y kla s y eks p o n u ją c e fu n k c je tra n s fo rm a c y jn e X S L T .

Java A P I fo r XM L-based RPC (J A X -R P C ) — n a jb a rd z ie j p o p u la rn e i u z n a n e A P I z w ią z a n e z p ro to k o łe m S O A P , w sp ierające o b a ty p y k o m u n ik a tó w lite ra ln y c h — R P C i d o k u m e n to w y — u c ze s tn ic zą c y ch z a ró w n o w tra n s a k c ja c h „ ż ą d a n ie -o d p o w ie d ź ”, ja k i tra n s m is ja c h je d n o s tro n n y c h . K ry ją c e się za n im p a k ie ty to: •

j a v a x .x m l .r p c i j a v a x . x m l . r p c . s e r v e r — z a w ie ra ją c e szereg k lu c z o w y c h fu n k c ji

A P I J A X -R P C ; •

ja v a x .x m l.r p c .h a n d le r i ja v a x .x m l.r p c .h a n d le r .s o a p

— z a w ie ra ją c e klasy,

k tó re d o s ta rc z a ją h a n d le r y do o b s łu g i k o m u n ik a tó w (h a n d le r y o p is u je m y p o k ró tc e w p o d p u n k c ie p o ś w ię c o n y m a g e n to m u s łu g ); •

j a v a x .x m l .s o a p i j a v a x .x m l .r p c .s o a p — u d o s tę p n ia ją c e fu n k c je z w ią z a n e

z p r z e tw a rz a n ie m treści i k o m u n ik a tó w S O A P i ic h w ią z a n ia m i. •

Java A P I fo r X M L Registries (J A X R ) — to A P I je s t s ta n d a rd o w y m in te rfe js e m d o s tę p o w y m do re je s tró w usług. O p ra c o w a n e o ry g in a ln ie d la ebXM L, o b e c n ie o fe ru je w s p a rc ie ta k ż e d la U D D I , re a liz o w a n e p rz e z n a s tę p u ją ce p a k ie ty : •

j a v a x . x m l . r e g i s t r y — o fe ru ją c y serię fu n k c ji d o s tę p u do re je s tró w usług;

•

j a v a x . x m l . r e g i s t r y . i n f o m o d e l — z a w ie ra ją c y k la s y r e p re z e n tu ją c e o b ie k ty w e w n ą trz

re je s tru U D D I . •

Java A P I fo r X M L M essaging ( J A X M ) — A P I d la a s y n c h ro n ic z n e j w y m ia n y k o m u n ik a tó w S O A P w stylu d o k u m e n to w y m , g łó w n ie w ra m a c h ro z g ła s z a n ia i in n y c h f o r m tra n s m is ji je d n o k ie ru n k o w y c h (c h o ć k o m u n ik a c ja s y n c h ro n ic z n a o b s łu g iw a n a je s t r ó w n ie d o b rz e ).

•

SO AP w ith A tta c h m en ts A P I fo r Java (S A A J ) — A P I d e d y k o w a n e z a rz ą d z a n iu k o m u n ik a ta m i S O A P z a w ie r a ją c y m i z a łą c z n ik i; s ta n o w i im p le m e n ta c ję s p e c y fik a c ji

SO AP w ith A tta c h m en ts (S w A ). •

Java Architecture fo r X M L B inding A P I (J A X B ) — A P I u m o ż liw ia ją c e a u to m a ty c z n e g e n e ro w a n ie d e fin ic ji klas Javy n a p o d s ta w ie s c h e m a tó w X S D , co p rz y d a je d o d a tk o w e j a b s tra k c ji p ro je k to w a n iu b a z u ją c e m u n a s ta n d a rd a c h X M L .

•

Java Message Service A P I (J M S ) — o p a rty n a Javie p ro to k ó ł k o m u n ik a c y jn y w y k o rz y s ty w a n y d la ro z w ią z a ń sto s u ją c y c h tra d y c y jn e o p ro g ra m o w a n ie k o m u n ik a c y jn e m iddlew are , o fe ru ją c y m e c h a n iz m y n ie z a w o d n e g o d o s ta rc z a n ia k o m u n ik a tó w , n ie s p o ty k a n e w ty p o w e j k o m u n ik a c ji H T T P .

S pośród w y m ie n io n y c h in te rfe js ó w A P I d w a u ż y w a n e najczęściej n a p o trz e b y S O A to J A X -R P C z w ią z a n y z k o m u n ik a ta m i S O A P i J A X P o rg a n iz u ją c y p rz e tw a rz a n ie d o k u m e n tó w X M L . D w a in n e p a k ie ty w y k o rz y s ty w a n e d o b u d o w a n ia lo g ik i b iz n e s o w e j u s łu g s ie c io w y c h J2EE to j a v a x . e j b i j a v a x . s e r v l e t , do starc za ją c e fu n d a m e n ta ln y c h A P I d la tw o r z e n ia z ia re n EJB i s e rw le tó w . N a ty m k o ń c z y m y o m a w ia n ie A P I J2EE, w y m ie n iliś m y je tu g łó w n ie po to , b y za d e m o n s tro w a ć g ru p o w a n ie fu n k c ji A P I w p a k ie ty .

1 8 .2 . SO A N A PLA TFO R M IE J2EE

583

Usługi-dostarczyciele Jak wspominaliśmy, usługi sieciowe J2EE implementowane są zwykle jako serwlety lub kompo­ nenty EJB. Każda z tych opcji jest przydatna do realizacji innych wymagań i wiąże się z inną kon­ figuracją wdrażania. • P u n k t końcow y JAX-RPC — usługi sieciowe do użytku wewnątrz kontenerów webowych budowane są zwykle jako punkty końcowe JAX-RPC i implementowane jako serwlety przez wewnętrzną logikę tych kontenerów. Serwlety stanowią typowe wcielenia usług sieciowych wewnątrz J2EE i są najlepiej przystosowane do usług niewymagających funkcjonalności kontenera EJB. • P u n k t końcow y EJB — alternatywą dla JAX-RPC jest eksponowanie ziaren EJB jako usług sieciowych, za pomocą punktów końcowych EJB. To podejście jest odpowiednie w sytuacji enkapsulowania logiki starszych aplikacji lub gdy wymagane są funkcje wykonywalne dostępne wyłącznie w kontenerze EJB. Ziarno EJB eksponowane jako usługa sieciowa musi być specjalnym typem EJB, zwanym bezstanowym kom ponentem sesji (Stateless Session Bean). Niezależnie od konkretnej platformy, oba opisane typy usług sieciowych zależne są od bibliotek wykonywalnych JAX-RPC i związanych z nimi API.

UWAGA Punkty końcowe JAX-RPC mylone są często z bibliotekami wykonywalnymi JAX-RPC — wielu mylnie sądzi, że biblioteki te skojarzone są wyłącznie z punktami końcowymi JAX-RPC i kontenerami webowymi. Tymczasem, jako że JAX-RPC ustanaw ia standardow ą w arstw ę przetwarzania usługi, rozciągającą się na oba typy konte­ nerów, czyli w ebow y i EJB, biblioteki wykonywalne JAX-RPC wykorzystywane są przez oba typy punktów końcowych — JAX-RPC i EJB.

Ponadto kluczową częścią każdej architektury usług jest wewnętrzny model definiujący im ­ plementację tej architektury, zwany P ort C om ponent M odel. Zgodnie z opisem w specyfikacji W eb Services fo r J2EE , model ten obejmuje serię komponentów składającą się na implementację usługi-dostarczyciela J2EE. Oto one (między innymi). • Interfejs p u n k tu końcowego (SEI — Service E ndpoint Interface) — stanowi opartą na Javie interpretację definicji WSDL, zgodną z regułami mapowania JAX-RPC WSDL-to-Java w celu zapewnienia spójnej reprezentacji. • Ziarno im plem entacyjne usługi (Service Im plem entation Bean) — klasa definiowana przez programistę, enkapsulująca specyficzną logikę biznesową usługi sieciowej. Implementowane bądź to jako punkt końcowy EJB (bezstanowy komponent sesji), bądź to jako punkt końcowy JAX-RPC (serwlet). W pierwszym przypadku nazywane jest zia rn em EJB im plem entującym usługę i rezyduje wewnątrz kontenera EJB; w drugim przypadku nosi nazwę ziarna JA X -R P C im plem entującego usługę i umieszczane jest w kontenerze webowym. Na rysunku 18.15 pokazano, jak kom ponenty J2EE wpisują się w znajomy model usługi-dostarczyciela.

584

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Usługa-wnioskodawca

Rysunek 18.15. Typowa usługa-dostarczyciel J2EE

Usługi-wnioskodawcy Na bazie JAX-RPC API można także tworzyć usługi-wnioskodawców, bo umożliwia ono kreowanie trzech następujących typów klienckich proxy. • A a utom atycznie generowanego stubu3 (lub po prostu — stubu) —najpopularniejszej formy usługi-klienta. Generowanie wykonywane jest przez kompilator JAX-RPC (na etapie projektowania) na podstawie definicji WSDL docelowej usługi-dostarczyciela, a jego wynikiem jest komponent proxy odzwierciedlający tę definicję w kategoriach języka Java; dokładniej — kompilator produkuje zdalny interfejs Javy dla każdego elementu p o rtT y p e ze wspomnianej definicji WSDL, eksponując w ten sposób metody odpowiadające poszczególnym operacjom. Generowany jest także stub w oparciu o konstrukcje p o r t i b in d in g . W rezultacie otrzymujemy 3 N a z y w a n e g o ta k ż e „ p n ie m ” lu b „ n a m ia s tk ą ” . — przyp. tłum.

1 8 .2 . SO A N A PLA TFO R M IE J2EE

585

komponent proxy, który może być wywoływany przez inne komponenty Javy. JAX-RPC przejmuje także zadanie organizowania komunikacji między tym komponentem proxy a komponentem zawierającym logikę biznesową związaną z żądaniem — komunikacja ta realizowana jest za pomocą komunikatów SOAP wysyłanych do i odbieranych od docelowej usługi-dostarczyciela, zgodnie z jej definicją WSDL. • dynam icznego p ro xy — koncepcyjnie podobnego do generowanego stubu, jednak w przeciwieństwie do niego generowanego dopiero w momencie wywoływania metody. • interfejsu dynam icznych wyw ołań (dynam ic invocation interface) — zapewniającego w pełni dynamiczną interakcję między komponentem Javy a definicją WSDL w czasie wykonywania aplikacji, bez potrzeby generowania fizycznego stubu. Dwie ostatnie opcje są przydatne w sytuacjach, gdy interfejs docelowej usługi-dostarczyciela może się często zmieniać bądź gdy konkretna usługa-dostarczyciel nie jest znana a priori, lecz determinowana dynamicznie w czasie wykonywania aplikacji. Ponieważ generowany stub (pierwsza opcja) charakteryzuje się statycznym interfejsem proxy, staje się bezużyteczny w momencie, gdy zmienia się definicja WSDL docelowej usługi. Na rysunku 18.16 pokazaliśmy, jak komponenty J2EE wpisują się w znajomy model usługi-wnioskodawcy.

Rysunek 18.16. Typowa usługa-wnioskodawca J2EE

586

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Agenty usług Platformy implementujące J2EE wykorzystują zazwyczaj wielu agentów usług, wykonujących roz­ maite zadania związane z filtrowaniem, przetwarzaniem danych i trasowaniem. Typowym przy­ kładem takiego zadania jest przetwarzanie nagłówków SOAP. Aby ułatwić przetwarzanie nagłówków SOAP, JAX-RPC API umożliwia tworzenie specjalizo­ wanych agentów usług zwanych handlerami (handlers). Są to filtry, stanowiące rozszerzenie środo­ wiska kontenerów J2EE, przechwytujące komunikaty wysyłane przez usługi-wnioskodawców J2EE oraz komunikaty odbierane przez punkty końcowe EJB i punkty końcowe JAX-RPC; celem tego prze­ chwytywania jest właśnie przetwarzanie nagłówków SOAP. Umiejscowienie handlerów w komu­ nikacji między usługą-wnioskodawcą a usługą-dostarczycielem przedstawiono na rysunku 18.17.

Usługa-wnioskodawca

Rysunek 18.17. Handlery J2EE jako agenty usług

Ten sam komunikat może być obiektem przetwarzania ze strony wielu handlerów, z których każdy operuje na innym bloku nagłówkowym SOAP. W takim przypadku handlery połączone są w określoną a priori sekwencję zwaną łańcuchem handlerów (handler chain). Rozszerzenia platformy Jest rzeczą naturalną, że dostawcy implementacji popularnych środowisk, zachowując zgodność z obowiązującymi standardami, wyposażają te implementacje w specyficzne dla siebie rozszerzenia. Nie inaczej jest w przypadku J2EE, gdzie producenci obdarowują programistów rozmaitymi pa­ kietami narzędziowymi SDK (Software D evelopm ent K its — zestaw narzędziowy do tworzenia oprogramowania). Dzięki udostępnianym technologiom pakiety te — gdy są wystarczająco doj­ rzałe — stanowią kolejny przyczynek do wsparcia współczesnej SOA ze strony J2EE. Oto dwa przykłady dostępnych aktualnie rozszerzeń tej kategorii, ściśle związanych z SOA.

1 8 .2 . SO A N A PLA TFO R M IE J2EE

587

• IB M Em erging Technologies T oo lkit — to właściwie kolekcja rozszerzeń, oferujących prototypowe implementacje wielu fundamentalnych rozszerzeń WS-*, między innymi specyfikacji W S-Addressing, W S-ReliableM essaging i W S-M etadataExchange oraz frameworku WS-Resource. • Java W eb Services Developer Pack — zestaw narzędziowy, obejmujący zarówno wsparcie dla rozszerzeń WS-* (między innymi W S-Security wraz z podpisem cyfrowym XML oraz W S-A ttachm ents), jak i nowe API dla Javy.

UWAGA Framework WS-Resource to kolekcja specyfikacji ( WS-ResourceProperties, WS-ResourceLifetime, WS-BaseFaults i WS-ServiceGroup definiujących mechanizmy zarządzania informacją o stanie aktywności usług sieciowych. Zainteresowanych czytelników odsyłamy do strony www.specifications.ws.

ANALIZA PRZYPADKU

Jak pamiętamy, w firmie RailCo opracowano zestaw usług sieciowych — było to konieczne, by RailCo mogła być dostawcą online dla firmy TLS. Ostatnie zmiany w zakresie wewnętrznej strategii biznesowej spowodowały konieczność poszerzenia zakresu i potencjału usług sie­ ciowych firmy, tak by możliwe było osiągnięcie dwóch następujących celów: • pozyskiwania nowych partnerów online bez każdorazowego ingerowania w infrastrukturę usług, • osiągnięcia pełnej zgodności z SOA przez architekturę hostującą usługi. Początkowy zestaw usług sieciowych zrealizowany został przy użyciu frameworku .NET i w RailCo postanowiono użyć tego właśnie frameworku do zmodyfikowania istniejących usług i opracowania nowych. Niestety, ostatnie zmiany organizacyjne ograniczyły budżet IT, wskutek czego niemożliwe stało się odnowienie kontraktu z czteroosobowym zespołem pro­ jektantów .NET, którzy ten pierwotny zestaw usług zrealizowali. Trzeba więc było poradzić sobie własnymi siłami. Wybór padł na małą grupę programi­ stów Javy zajmujących się konserwacją systemu finansowo-księgowego. Ponieważ nie mieli oni doświadczenia w pracy z jakimkolwiek API Javy związanym z usługami sieciowymi, ko­ nieczne stało się ich przeszkolenie w zakresie wykorzystywania JAX-RPC i JAXP. I chociaż spowolniło to realizację oryginalnego planu, ostatecznie jednak założone cele zostały zrealizowane — aplikacje implementujące usługi Przetwarzanie faktury i Realizacja zamówienia zostały zbudowane jako rozwiązania J2EE, zawierające zbiór punktów końco­ wych JAX-RPC.

18.2.2. Wsparcie dla pierwotnej SOA Platforma J2EE to środowisko programistyczne i wykonawcze, w którym realizowane są wszyst­ kie cechy pierwotnej SOA — co poniżej postaramy się udowodnić.

588

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Enkapsulacja usług Rozproszona natura platformy J2EE umożliwia tworzenie niezależnych jednostek logiki przetwa­ rzania w postaci ziaren EJB lub serwletów — mogą one zawierać różne porcje tej logiki, mogą też być komponowane w celu realizacji specyficznych zadań biznesowych, a nawet kompletnych rozwiązań. Zarówno ziarna EJB, jak i serwlety mogą być enkapsulowane jako usługi sieciowe, stają się wtedy punktami końcowymi tych usług. Wewnętrzna logika punktu końcowego może angażować inne komponenty EJB lub serwlety, niekoniecznie będące punktami końcowymi. W rezultacie za pomocą J2EE można tworzyć pełnoprawne usługi. Luźne powiązanie Wykorzystywanie interfejsów na platformie J2EE umożliwia abstrahowanie metadanych z logiki komponentów. W połączeniu z odpowiednimi technologiami komunikacyjnymi — otwartymi lub własnościowymi — umożliwia to realizację luźnego powiązania. Ponadto punkty końcowe EJB i JAX-RPC ustanawiają standardową definicję WSDL, obsługiwaną przez usługi wewnętrzne J2EE HTTP i SOAP. Zatem luźne powiązanie także możliwe jest do osiągnięcia na gruncie J2EE. Komunikowanie Przed rozpowszechnieniem się usług sieciowych wymiana komunikatów między komponentami EJB i serwletami odbywała się zgodnie ze standardem JMS. Obecnie JAX-RPC API dostarcza środki do wymiany komunikatów SOAP, z wykorzystaniem HTTP jako protokołu transportowego. Warto w tym miejscu zaznaczyć, że komunikaty SOAP mogą być także wymieniane przy uży­ ciu protokołu JMS (jako alternatywy dla HTTP), co — oczywiście — pozwala na spożytkowanie podstawowej zalety frameworku JMS, czyli niezawodności. Tak czy inaczej, platforma J2EE za­ pewnia niezbędne środki do wymiany komunikatów wymaganych przez pierwotną SOA.

18.2.3. Wsparcie dla zasad zorientowania na usługi Skoro przekonaliśmy się, że platforma J2EE wspiera i implementuje technologie pierwszej gene­ racji usług sieciowych, zobaczmy teraz, jak przedstawia się kwestia wsparcia z jej strony dla tych czterech zasad zorientowania na usługi, dla których brakuje automatycznego wsparcia ze strony usług sieciowych. Autonom ia Autonomia usługi to możliwość sprawowania pełnej kontroli nad swą wewnętrzną logiką. Wysoki stopień autonomii łatwiej osiągnąć w tych usługach sieciowych, które nie mają związku z enkapsulowaniem logiki tradycyjnych aplikacji. Punkty końcowe usług JAX-RPC egzystują jako samo­ dzielne serwlety umieszczone w kontenerze webowym i generalnie budowane są przy wsparciu nowych środowisk SOA. Nie jest więc trudne osiągnięcie pełnej autonomii punktu końcowego JAX-RPC szczególnie wtedy, gdy powierzono mu przetwarzanie niewielkiej porcji logiki biznesowej. Z kolei punkty końcowe EJB muszą mieć postać bezstanowych ziaren sesji, co sprzyja ich autonomii; ponieważ jednak w ich przypadku bardziej prawdopodobne jest reprezentowanie tradycyjnej logiki (lub kombinacji tradycyjnych i nowych komponentów EJB), osiągnięcie dużego stopnia autonomii może być nie lada wyzwaniem.

1 8 .2 . SO A N A PLA TFO R M IE J2EE

589

Wieloużywalność Pojawienie się EJB w epoce popularności aplikacji rozproszonych w ostatnim dziesięcioleciu przyczyniło się do ukształtowania modelu komponentowego projektu aplikacji, który w połącze­ niu z językiem Java stanowił naturalne wsparcie dla orientacji obiektowej. Poszczególne kompo­ nenty stały się wieloużywalnymi cegiełkami do budowy złożonych aplikacji. Ponieważ usługa może enkapsulować jeden lub więcej komponentów EJB, jej wieloużywalność staje się kwestią odpowiedniego zaprojektowania logiki biznesowej, reprezentowanej przez te komponenty, oraz punktu końcowego. Bezstanowość Punkty końcowe JAX-RPC mogą być projektowane jako bezstanowe serwlety, lecz JAX-RPC do­ starcza serwletom środki do zarządzania informacją o stanie za pomocą obiektu HTTPSession. Jest więc sprawą projektanta usługi zapewnienie, iż informacja o stanie aktywności sprowadzona zo­ staje do niezbędnego minimum i zarządzana jest wyłącznie w opisany sposób. Jak już wspominaliśmy, warunkiem koniecznym adaptacji komponentu EJB jako punktu końcowego usługi jest jego całkowita bezstanowość — musi on być bezstanowym komponentem sesji. Nie może zatem samodzielnie zarządzać informacją o stanie, ale może tę funkcję delegować do komponentów EJB innego typu — stanowych komponentów sesji (Stateful Session Beans) lub ziaren encji (E ntity Beans). Wykrywalność Podobnie jak wieloużywalność, także wykrywalność usługi J2EE jest sprawą rozważnego pro­ jektowania. Usługę łatwo wykryć (odnaleźć), jeśli jej punkt końcowy ma charakter intuicyjny i opisowy. Wykrywalność usługi jako element SOA na gruncie J2EE wspierana jest bezpośrednio przez JAXR za pomocą dwóch API zapewniających obsługę rejestrów zgodnych ze standardem XML, czyli między innymi repozytoriów UDDI. Jedno z tych API dedykowane jest publikowaniu in­ formacji w rejestrze, drugie — jej wyszukiwaniu. Mimo iż JAXR zapewnia obsługę rejestrów UDDI, eksponowany przezeń interfejs różni się nieco od oryginalnego UDDI API: przykładowo zamiast BusinessEntity mamy Organization, a zamiast BusinessService — Service.

18.2.4. Wsparcie dla współczesnej SOA Rozszerzanie SOA poza jej pierwotne granice wymaga odpowiedniego projektu oraz technologii zdolnych ten projekt urzeczywistnić. Ponieważ specyfikacje J2EE nie standaryzują rozszerzeń WS-* w sposób neutralny, czyli niezależny od konkretnej implementacji, wspomniane urzeczywistnienie wymaga użycia narzędzi i mechanizmów specyficznych dla konkretnego dostawcy. Powróćmy teraz do wybranych cech współczesnej SOA, omawianych w rozdziale 9., i zo­ baczmy, w jakim zakresie są one automatycznie wspierane przez standardy J2EE, a w jakim wsparcie to wymaga zastosowania technologii towarzyszących tym standardom.

590

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Bazowanie na otwartych standardach W aspekcie usług sieciowych platforma J2EE jest w pełni zgodna ze standardowymi specyfika­ cjami, takimi jak WSDL, SOAP i UDDI; jak wyjaśnimy w podpunkcie „Naturalna interoperacyjność”, jest ona zgodna także z wytycznymi W S-I Basic Profile. Co więcej, specyfikacje API składające się na platformę J2EE same są otwartymi standardami, co sprzyja zróżnicowaniu dostawców (piszemy o tym w następnym podpunkcie).

UWAGA Warto w tym miejscu wspomnieć, że niektórzy dostawcy J2EE posiadają znaczący wkład w rozwój specyfikacji związanych z usługami sieciowymi.

Zróżnicowanie dostawców Zgodność produktów z podstawowymi standardami J2EE API otworzyła dostawcom tych pro­ duktów wrota rynku, a klientom stworzyła możliwość wyboru i różnicowania tychże dostawców. W rezultacie projekt aplikacji w Javie, opracowywany za pomocą jednego narzędzia, może być z łatwością przenoszony do innego, a komponenty Javy mogą być projektowane jako przenaszalne między różnymi produktami serwerowymi J2EE. Ponadto projektując usługi w sposób zgodny z wytycznymi W S -I Basic Profile , poszerzamy możliwość wyboru dostawców poza granice J2EE — organizacja, która dotąd budowała swoją SOA za pomocą J2EE, może z powodzeniem kontynuować swój pochód w stronę SOA przy użyciu frame­ worku .NET (i vice versa). Usługi zbudowane w jednym środowisku mogą współdziałać z usługami stworzonymi w innym, o ile obie grupy usług zgodne są z tymi samymi otwartymi standardami. Naturalna interoperacyjność Interoperacyjność usługi jest w znaczącej mierze wynikiem odpowiedniego jej zaprojektowania. Niezależnie od charakterystyki interfejsu usługi, krytycznym czynnikiem zapewnienia interoperacyjności jest zgodność z przemysłowymi standardami usług sieciowych, zwłaszcza gdy intero­ peracyjność ta ma realizować się na obszarze przekraczającym granice poszczególnych domen przedsiębiorstwa. JAX-RPC API w wersji 1.1 umożliwia tworzenie usług w pełni zgodnych z wytycznymi W S-I Basic Profile, co w znacznym stopniu przyczynia się do wbudowywania w te usługi cech interoperacyjności. Należy jednak zachować ostrożność podczas stosowania handlerów, ponieważ wyko­ nywane przez nie akcje mogą tę interoperacyjność narazić na szwank.

UWAGA Rational Application Developer firmy IBM dostarcza w budow ane wsparcie dla opracowywania usług siecio­ wych zgodnych z wytycznymi WS-i Basic Profile, a narzędzie o nazwie Wscompile, stanow iące część SDK do­ starczanego przez firmę Sun Microsystems4, umożliwia autom atyczne generow anie definicji WSDL zgodnych z tymi wytycznymi.

4 O b e c n ie J D K je s t w ła s n o ś c ią f i r m y O r a c le — przyp. tłum.

1 8 .2 . SO A N A PLA TFO R M IE J2EE

591

Federacyjność Strategicznie umiejscowione usługi, w połączeniu z adapterami eksponującymi logikę starszych aplikacji, mogą ustanawiać wysoki poziom federacyjności. Budowanie architektury integracyjnej w postaci specjalizowanych usług biznesowych oraz usług-otoczek dla starszych aplikacji jest możliwe przy użyciu podstawowych API i mechanizmów J2EE. Gdy uzupełnimy tę architekturę o serwer orkiestracyjny (i związaną z nim warstwę orkiestracji), dodatkowo powiększymy możliwo­ ści ujednolicania i standaryzowania integrowanej logiki (piszemy o tym również w podpunkcie „Modelowanie biznesowe zorientowane usługowo”). Wartą wzmianki w tym kontekście jest J2EE Connector A rchitecture (JCA) — strukturalizowana, ukierunkowana na adaptery architektura integracyjna, w ramach której adaptery zasobów (resource adapters) pełnią rolę pomostów między platformami J2EE a innymi środowiskami. Co prawda JCA, podobnie jak JMS, jest produktem o charakterze własnościowym, bo bazuje na wła­ snościowych protokołach komunikacyjnych i adapterach specyficznych dla konkretnej platformy, ostatnio jednak wprowadzono doń elementy obsługi komunikacji asynchronicznej i komunika­ tów SOAP. Udostępniono ponadto adaptery usługowe umożliwiające integrowanie JCA z rozwią­ zaniami zorientowanymi na usługi. Implementację ogólnie pojętej koncepcji federacyjności w skali całego przedsiębiorstwa umoż­ liwiają liczne serwerowe platformy integracyjne. Zależnie od konkretnej architektury, integracja zorientowana na usługi realizowana jest albo w oparciu o serwery orkiestracji, albo o szyny usług, albo z wykorzystaniem obu tych możliwości.

UWAGA Przykładem implementacji JCA umożliwiającej tw orzenie warstw y komunikatów SOAP jest ONE Connector Builder firmy Sun Microsystems. Wielu dostaw ców J2EE oferuje ponadto serwery orkiestracyjne z natywnym wsparciem dla WS-BPEL — wymienić tu należy przede wszystkim W ebSphere Business Integration Server Foundation firmy IBM i BPEL Process M anager firmy Oracle.

Komponowalność architektoniczna Ze względu na modularną naturę kryjących się za API pakietów i klas, a także wybór kontenerów specyficznych dla usług, platformę J2EE można uważać za organicznie komponowalną. W prak­ tyce oznacza to, że projektanci rozwiązań mogą wybierać spośród składników platformy tylko te, które są im rzeczywiście potrzebne. Przykładowo jest mało prawdopodobne, by rozwiązanie ba­ zujące na usługach sieciowych, zawierające wyłącznie punkty końcowe JAX-RPC, potrzebowało pakietów z klasami JMS; podobnie SOA niewykorzystująca rejestru usług nie będzie raczej im ­ plementować jakiejkolwiek części JAXR API. Niestety, w swym aktualnym wcieleniu platforma J2EE nie dostarcza natywnego wsparcia dla specyfikacji WS-*: wsparcie to zapewniane jest przez dostawców, którzy implementują stosowne rozszerzenia z własnej inicjatywy, oczywiście, w zgodzie ze standardami J2EE. Oznacza to, że w za­ kresie rozszerzeń WS-* komponowalność na platformie J2EE jest sprawą specyficzną dla produ­ centa tej platformy.

592

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Rozszerzalność Jak wszystkie rozwiązania zorientowane na usługi, także i te bazujące na platformie J2EE powin­ ny być budowane z udziałem usług projektowanych z myślą o przyszłej rozszerzalności. Oznacza to powrót do źródeł, czyli projektowanie usługi z zachowaniem struktury i konwencji dotyczących jej interfejsu. Jako że środowiska J2EE implementowane są przez różnych dostawców, względy rozszerzalno­ ści prowadzą czasem do używania rozszerzeń specyficznych dla konkretnego dostawcy. Wówczas, mimo iż postulat rozszerzalności daje się z powodzeniem zrealizować na konkretnej implementacji platformy J2EE, odbywa się to być może ze szkodą dla przenośności i otwartości rozwiązania — cech tak charakterystycznych dla środowisk Javy. M odelowanie biznesowe zorientowane usługowo Jeśli chodzi o modelowanie usług, to poza ogólnie obowiązującą zasadą stosowania spójnych i stan­ daryzowanych podejść do budowania usług aplikacyjnych, podmiotowych i zadaniowych (o czym pisaliśmy w poprzednich rozdziałach) projektanci nie otrzymują od J2EE nic nowego w postaci natywnych mechanizmów; jakiekolwiek wsparcie w tym względzie zapewnione jest wyłącznie przez narzędzia specyficzne dla producenta danej platformy. Jest tak przede wszystkim dlatego, że koncepcja orkiestracji nie jest natywną częścią platform J2EE. Wynikającą stąd lukę w kwestii wsparcia dla modelowania z jednej strony, a serwerów orkiestracyjnych z drugiej, ochoczo wypełniają producenci platform J2EE; oczywiście, każdy na swój sposób. Zatem dostępne w środowisku J2EE wsparcie dla modelowania usług może mieć różne oblicza w różnych implementacjach tego środowiska. Tworzenie warstw abstrakcji Punkty końcowe JAX-RPC i EJB mogą być projektowane jako składniki warstw abstrahujących logikę specyficzną dla aplikacji lub wieloużywalną. Co więcej, usługi takie mogą eksponować nawet kompletne rozwiązania J2EE. Zależnie od konkretnej platformy serwerowej, można napotkać pewne ograniczenia przy bu­ dowaniu kompozycji usług wymagających zabezpieczeń na poziomie komunikatów. Konsekwencją tych ograniczeń mogą być utrudnienia w realizacji opisanej abstrakcji. Zwinność organizacyjna i luźne powiązanie w skali przedsiębiorstwa W poprzednich rozdziałach pokazywaliśmy wielokrotnie, jak abstrahowanie logiki w postaci warstw usług przyczynia się do zwiększenia zwinności organizacyjnej firmy. W jednym z poprzednich podpunktów wyjaśniliśmy też, że wyodrębnienie tych warstw może być ułatwione dzięki serwe­ rowi orkiestracyjnemu. Mimo iż jest on specyficzny dla konkretnej implementacji J2EE, to fakt, że inne usługi sieciowe są standardowe dla J2EE, sprzyja tej zwinności poprzez możliwość wyboru dostawców.

1 8 .3 . SO A N A PLA TFO R M IE .NET

593

Jeżeli konkretna platforma serwerowa nie jest w stanie sprostać bieżącym wymaganiom bizne­ sowym i musi zostać wymieniona na inną, to podporządkowane (orkiestrowane) usługi aplikacyjne, podmiotowe i zadaniowe powinny być na tyle mobilne, iż w nowych warunkach funkcjonować będą równie niezawodnie jak dotychczas. Jeśli chodzi o samą logikę orkiestracyjną, to prawdopo­ dobnie również będzie ona przenośna, jeśli na obu platformach (dotychczasowej i nowej) wyra­ żona będzie w standardowym języku orkiestracji, na przykład W S-B P E L . Osiągnięcie stanu, w którym domena biznesowa i domena technologiczna firmy są luźno powią­ zane, czyli stanu dwukierunkowej zwinności organizacyjnej, wymaga zrealizowania cech charak­ terystyki współczesnej SOA, zidentyfikowanych w poprzednich rozdziałach tej książki. Platforma J2EE dostarcza fundamenty dla budowania standaryzowanej i rozszerzalnej SOA, a rozszerzenia tej platformy, specyficzne dla konkretnych dostawców, umożliwiają budowanie na tych fundamentach nowych warstw, upowszechniających orientację na usługi w skali całego przedsiębiorstwa. PODSUMOWANIE •

Platforma J2EE oferuje wiele interfejsów API (JAXP, JAX-RPC, JAXR i podobnych) umożliwiających tw orzenie dwóch podstawowych typów usług-dostarczycieli: punktów końcowych JAX-RPC i punktów końcowych EJB, oraz trzech typów proxy usług-wnioskodawców: generow anego stubu, dynamicznego proxy i interfejsu dynamicznych wywołań.

•

J2EE zapewnia natyw ne wsparcie dla kreowania pierwotnej SOA.

•

Wszystkie cztery cechy współczesnej SOA nieznajdujące autom atycznego wsparcia ze strony technologii pierwszej generacji usług sieciowych mogą być realizowane na gruncie J2EE poprzez odpowiednie projektowanie i wykorzystywanie właściwych API.

•

Niektóre cechy współczesnej SOA w spierane są przez natyw ne cechy platformy J2EE, inne natom iast uzyskują wsparcie ze strony rozszerzeń charakterystycznych dla konkretnych implementacji tej platformy. Fakt, że J2EE ułatwia tworzenie usług zgodnych z wytycznymi WS-i Basic Profile, przyczynia się do propagow ania kluczowych cech współczesnej SOA: w budow anej interoperacyjności, federacyjności, zgodności z otwartymi standardam i i możliwości różnicowania dostawców.

•

Podobnie jak św iat specyfikacji związanych z usługami sieciowymi, tak technologie tworzące platformę J2EE opierają się na otwartych standardach. Dostawcom platform J2EE umożliwia to budowanie specyficznych narzędzi i platform serwerowych na standardowych fundam entach, zaś klientom daje możliwość wyboru dostaw ców i produktów.

18.3. SOA na platform ie .NET Framework .NET to druga z platform, w kontekście której omawiamy problematykę wsparcia dla budowania SOA. Podobnie jak w poprzednim podrozdziale, rozpoczniemy od przedstawienia pod­ stawowych składników platformy .NET, po czym zajmiemy się szczegółowo jej relacjami do zna­ jomych zagadnień: charakterystyki pierwotnej SOA, zasad zorientowania na usługi i charakterystyki współczesnej SOA; dla każdej z nich wskażemy te elementy platformy, które zapewniają wsparcie o charakterze bezpośrednim i pośrednim.

594

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

I tak samo jak poprzednio, nie dokonujemy w tym miejscu przeglądu możliwości platformy .NET, bo interesuje nas ona jedynie z perspektywy SOA. Ponownie odsyłamy do strony www.serviceoriented.ws czytelników, którzy o platformie .NET chcieliby dowiedzieć się czegoś więcej.

18.3.1. Ogólnie o platformie Framework .NET to platforma programistyczna opracowana przez firmę Microsoft, przeznaczo­ na do użytku w systemach operacyjnych grupy Windows i produktach serwerowych tej grupy. Umożliwia tworzenie aplikacji różnych typów, od prostych aplikacji desktopowych, poprzez sys­ temy mobilne, po rozproszone rozwiązania webowe i usługi sieciowe. Podstawowym składnikiem platformy .NET pozostającym w związku z SOA jest środowisko ASP.N ET, wraz z uzupełnieniem o rozszerzenie dla usług sieciowych (WSE — Web Services E nhan­ cement), odpowiadające w przybliżeniu warstwie technologii webowych z rysunku 18.2.

UWAGA W wersji 2.0 frameworku pojawiły się nowe elementy oraz zmiany niektórych aspektów architektury ASP.NET — uwzględniamy to w poniższym opisie.

Na rysunku 18.18 nie przedstawiono ogólnej struktury frameworku .NET, a jedynie uwzględ­ niono warstwy typowe dla budowania na jego gruncie rozwiązań zorientowanych na usługi. Suma­ rycznie warstwa A SP .N E T + W SE oraz warstwa zestawów (w oryginale zwanych assemblies) odpo­ wiadają kombinacji warstw technologii webowych i technologii komponentowych „neutralnego” modelu przedstawionego na rysunku 18.2. Jak pokazano na rysunku 18.19, te i inne elementy platformy .NET powiązane są w rozmaity sposób, tworząc platformę zdolną do realizacji SOA.

Rysunek 18.18. Wybrane warstwy platformy .NET pozostające w relacji do SOA

1 8 .3 . SO A N A PLA TFO R M IE .NET

Rysunek 18.19. Wzajemne powiązania części frameworku .NET

595

596

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Komponenty architektoniczne Framework .NET oferuje środowisko zaprojektowane do budowania różnych typów rozwiązań rozproszonych; z tworzeniem aplikacji webowych szczególnie związane są następujące komponenty. • F orm ularze webowe A SP .N E T — budowane dynamicznie strony WWW rezydujące na serwerze WWW, umożliwiające tworzenie interaktywnych formularzy online przy użyciu kontrolek odpowiedzialnych za autogenerację zawartości stron WWW. •

Usługi sieciowe A SP .N E T — aplikacja ASP.NET zaprojektowana jako usługa-dostarczyciel, również rezydująca na serwerze WWW.

• Zestaw y (assemblies) — standardowe jednostki logiki przetwarzania w środowisku .NET. Każdy zestaw może zawierać wiele klas, partycjonujących kod wspomnianej logiki zgodnie z zasadami orientacji obiektowej. Logika aplikacji będącej usługą sieciową .NET rezyduje zwykle (choć niekoniecznie) w jednym zestawie. Formularze webowe ASP.NET wykorzystywane są zwykle do tworzenia warstwy prezentacyjnej rozwiązania, podczas gdy dwa pozostałe komponenty związane są bezpośrednio z budowaniem usług sieciowych. Środowisko uruchomieniowe Opisane komponenty architektury zależne są od środowiska uruchomieniowego (C om m on L a n ­ guage R untim e, w skrócie CLR). Dostarcza ono kolekcję agentów udostępniających usługi zarzą­ dzania aplikacjami .NET w zakresie lokalizowania typów .NET, ich wczytywania i zarządzania nimi, a także zarządzania pamięcią i cyklem życiowym poszczególnych obiektów. Na warstwę CLR nałożonych jest kilka innych warstw wykonywalnych. Samo ASP.NET do­ starcza szereg usług wykonywalnych ustanawiających potok H T T P (H TTP Pipeline) — środowisko złożone z agentów usług systemowych, zawierających moduły HTTP i handlery HTTP (o handle­ rach pisaliśmy w punkcie 18.2.1). Dodatkowo, środowisko COM+ dostarcza aplikacjom .NET dodatkowy zbiór usług związanych między innymi z pulami obiektów, transakcjami, kolejkowa­ niem komponentów i doraźną aktywacją (just-in-tim e activation). Języki programowania Framework .NET zapewnia zunifikowaną obsługę blisko 50 języków programowania — są wśród nich Visual Basic, C++, Delphi (od wersji 8.), Fortran, Lisp, Perl, Python i Smalltalk, a z now­ szych C# i J#. Wersje tych języków dla .NET zgodne są z wymogami środowiska uruchomienio­ wego CLR: kod programu w języku źródłowym kompilowany jest do postaci uniwersalnego języ­ ka pośredniego MSIL5 (M icrosoft Interm ediate Language), który następnie wykonywany jest przez procesor CLR.

UWAGA Sztandarowym produktem programistycznym Microfostu dla platformy .NET jest Visual Studio, umożliwiające tworzenie aplikacji w różnych językach program owania.

5 Obecnie język ten nosi nazwę CIL (Com m on Interm ediate Language — wspólny język pośredni). — przyp. tłum.

1 8 .3 . SO A N A PLA TFO R M IE .NET

597

Interfejsy API F ra m e w o rk .N E T u m o ż liw ia p ro g ra m o w y dostęp do w ie lu fu n k c ji system ow ych za p o m o c ą biblioteki

klas ( .N E T Class Library ) — jest to o b s ze rn y z b ió r in te rfe js ó w A P I z o rg a n iz o w a n y c h w p rze s trze n ie n a z w . K a ż d a z ty c h p rz e s trz e n i m u s i b yć ja w n ie id e n ty fik o w a n a w k o d z ie ź ró d ło w y m a p lik a c ji. O to w a ż n ie js ze p rz e s trz e n ie n a z w u d o s tę p n ia ją c y c h A P I z w ią z a n e z tw o r z e n ie m u s łu g s ie c io w y c h . •

System .Xm l z w ią z a n a z fu n k c ja m i p a rs o w a n ia i p r z e tw a rz a n ia d o k u m e n tó w X M L ; fu n k c je te u d o s tę p n ia n e są p rz e z w ie le klas, m ię d z y in n y m i: • •

Xm lReader i XmlWri t e r (o d p o w ie d n io ) in te rp re tu ją c a i g e n e ru ją c a treść d o k u m e n tó w X M L ;

d ro b n o z ia rn is te k la s y re p re z e n tu ją c e p o s zc zeg ó ln e części d o k u m e n tu X M L , w ś ró d n ic h XmlNode , X m lElem ent i X m lA ttr ib u te .

•

System.W eb.Services z a w ie ra ją c a ro d z in ę klas d e d y k o w a n y c h p rz e tw a r z a n iu ro z m a ity c h d o k u m e n tó w i p r o to k o łó w z w ią z a n y c h z in te rfe js a m i i in te r a k c ja m i u s łu g s ie c io w y c h , m ię d z y in n y m i: •

k la s y re p re z e n tu ją c e d o k u m e n ty W S D L , n a le żą c e do p rz e s trz e n i n a z w S y s t e m .W e b .S e r v i c e s .D e s c r i p t io n ;

•

k la s y z w ią z a n e z fu n k c jo n a ln o ś c ią p r o to k o łó w k o m u n ik a c y jn y c h ( w ty m d o k u m e n tó w S O A P ), z lo k a liz o w a n e w p rz e s trz e n i n a z w S y s t e m .W e b .S e r v i c e s .P r o t o c o l s ;

•

n a d rz ę d n ą klasę S y s te m .W e b .S e rv ic e s u s ta n a w ia ją c ą p rz e s trz e ń n a z w n a jw y żs ze g o p o z io m u ; kla s a ta je s t m a c ie rz y s ta d la z b io r u klas re p re z e n tu ją c y c h p o d s ta w o w e części o b ie k tu u s łu g i s ie c io w e j A S P .N E T (z klasą S y s te m .W e b .S e rv ic e s .W e b S e rv ic e n a czele);

•

w a r tą ta k ż e w z m ia n k i klasę S o a p H e a d e r n a le ż ą c ą do p r z e s trz e n i n a z w S y s t e m .W e b .S e r v i c e s .P r o t o c o l s , d e d y k o w a n ą p r z e tw a rz a n iu s ta n d a rd o w y c h

b lo k ó w n a g łó w k a S O A P . W s p a rc ia d la usług sie c io w y c h i p o w ią z a n e g o p rz e tw a rz a n ia d o k u m e n tó w X M L u d z ie la ją ta k że in n e p rze s trze n ie n a z w o feru jące r o d z in y klas. O to o n e (m ię d z y in n y m i). •

S y ste m .X m l.X sl — z b ió r klas e k s p o n u ją c y c h fu n k c jo n a ln o ś ć X S L T , u ła tw ia ją c y c h

tra n s fo rm o w a n ie d o k u m e n tó w . •

S ystem .X m l.S chem a — z b ió r k las re p re z e n tu ją c y c h s c h e m a ty X S D i ic h p rz e tw a rz a n ie .

•

S y s te m .W e b .S e r v ic e s .D is c o v e r y — z b ió r klas u m o ż liw ia ją c y c h p r o g ra m o w e o d n a jd y w a n ie

m e ta d a n y c h u s łu g sie c io w y c h . N ie b ę d z ie m y za g łę b ia ć się w szczeg ó ły w y m ie n io n y c h klas i p rz e s trz e n i n a z w ; p rz y w o ła liś m y je tu ta j w y łą c z n ie d la z ilu s tro w a n ia o rg a n iz a c ji .N E T A P I w p o s ta c i h ie ra r c h ii klas.

Usługi-dostarczyciele U s łu g a -d o s ta rc z y c ie l .N E T to u s łu g a s ie c io w a is tn ie ją c a w p o s ta c i sp e c ja ln e j o d m ia n y a p lik a c ji A S P .N E T , zw a n e j usługą sieciową A SP .N ET (A SP .N E T Web Service). U R L w s k a zu ją c y n a usługę sie­ c io w ą A S P .N E T ro z p o z n a ć m o ż n a po ro zs ze rze n iu .asmx id e n ty fik u ją c y m część usługi fu n k c jo n u ją c ą ja k o jej p u n k t k o ń c o w y . F izy c z n ie usługa sieciow a .N E T m o że m ie ć postać n ie za le żn e g o p lik u .asmx zaw ierająceg o k o d inline i to w arzyszące m u d y re k ty w y , częściej je d n a k jest ro z d z ie la n a n a p u n k t k o ń c o w y i s k o m p ilo w a n y ze s ta w re a liz u ją c y je j lo g ik ę b izn e s o w ą . U m ie js c o w ie n ie e le m e n tó w usługi siec io w ej .N E T w „ n e u tr a ln y m ” m o d e lu u s łu g i-d o s ta rc z y c ie la p rz e d s ta w io n o n a ry s u n k u 18.20.

598

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Usługa-wnioskodawca

Rysunek 18.20. Typowa usługa-dostarczyciel .NET

Usługi-wnioskodawcy Do tworzenia usług-wnioskodawców framework .NET oferuje klasę proxy, reprezentującą logikę biznesową usługi-wnioskodawcy i jednocześnie dublującą interfejs usługi-dostarczyciela. Dzięki temu usługa-wnioskodawca może współdziałać lokalnie ze wspomnianą klasą proxy, pozo­ stawiając w jej gestii wszelką logikę wynikającą z aktywności związanej ze zdalną komunikacją i marshalowaniem danych. Wspomniana klasa proxy wykonuje translację wywołań metod na żądania HTTP oraz transla­ cję przychodzących odpowiedzi HTTP na natywne wywołania metod. Kod klasy proxy może być automatycznie generowany za pomocą Visual Studio albo progra­ mu W SDL.exe wywoływanego z wiersza poleceń. W obu przypadkach materiałem źródłowym jest definicja WSDL usługi-dostarczyciela, a wynikiem skompilowana biblioteka DLL. Umiejscowienie opisanego mechanizmu w neutralnym modelu usługi-wnioskodawcy przed­ stawiamy na rysunku 18.21.

1 8 .3 . SO A N A PLA TFO R M IE .NET

599

Rysunek 18.21. Typowa usługa-wnioskodawca .NET

Agenty usług ASP.NET wykorzystuje liczne agenty systemowe rozmaicie przetwarzające komunikaty. Jak wcze­ śniej wspominaliśmy, ASP.NET formuje potok HTTP z szeregu m odułów H T T P (patrz rysunek 18.22); moduły te są agentami wykonującymi powszechne zadania systemowe — uwierzytelnia­ nie, autoryzację i zarządzanie informacją o stanie aktywności. Możliwe jest tworzenie dodatko­ wych modułów, wykonujących rozmaite zadania towarzyszące kontaktowi komunikatu z punktem końcowym. Warto także wspomnieć w tym miejscu o handlerach H T T P (H T TP handlers), odpowiedzial­ nych głównie za symulowanie punktów końcowych i wykonywanie w ten sposób dodatkowego przetwarzania komunikatów, stosownie do ich typu. (Potok HTTP może zawierać jeszcze dodat­ kowe komponenty, między innymi H T T P C ontext, H T T P R u n tim e i H T T P A pplication, jednak nie będziemy ich tu opisywać). Innym przykładem agentów usług .NET są filtry dostarczane przez WSE, używane do przetwarza­ nia nagłówków SOAP i zwane oficjalnie filtram i WSE. Repertuar mechanizmów oferowanych przez WSE omówimy w następnym podpunkcie, tutaj ograniczamy się tylko do ich roli jako agentów usług.

600

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Usługa-wnioskodawca

Rysunek 18.22. Typowy agent usługi .NET

WSE dostarcza szereg rozszerzeń wykonujących przetwarzanie nagłówków SOAP, rozszerze­ nia te mogą być więc wykorzystywane jako filtry wejściowe i wyjściowe odpowiedzialne za od­ czytywanie i zapisywanie nagłówków SOAP w kontekście określonych proxy i usług ASP.NET. Zgodnie z tym, co pisaliśmy o agentach usług w punkcie 18.1.4, filtry WSE przechwytują komu­ nikaty SOAP bezpośrednio przed ich kontaktem z usługą-dostarczycielem i bezpośrednio po opuszczeniu usługi-wnioskodawcy. Rozszerzenia platformy Rozszerzenie .NET dla usług sieciowych (WSE — W eb Services E nhancem ent) to zestaw narzę­ dziowy rozszerzający framework .NET o zbiór dodatkowych klas ukierunkowanych specjalnie na implementację rozszerzeń WS-*. WSE zaprojektowane zostało do użytku w ramach Visual Studio i obecnie oferuje wsparcie dla następujących specyfikacji: W S-Addressing, WS-Policy, W S-Security (w tym W S-SecurityPolicy, W S-SecureC onversation i W S -T ru st), W S-Referral, W S -A tta ch m en ts i DIME (D irect Internet Message Encapsulation ).

UWAGA Nie będziemy om aw iać w tej książce specyfikacji WS-Referral ani WS-Attachments. Pierwsza z nich, autor­ stwa Microsoftu, dedykowana jest zarządzaniu routerami SOAP. Druga definiuje wykorzystywanie formatu DIME do kodowania załączników przesyłanych w komunikatach SOAP. Czytelników zainteresowanych wy­ mienionymi specyfikacjami odsyłamy do strony ww w .specifications.ws.

1 8 .3 . SO A N A PLA TFO R M IE .NET

601

ANALIZA PRZYPADKU

Wiele systemów webowych firmy TLS stworzono w języku Java, między inny przywoływany wielokrotnie w tej książce system B2B tej firmy zrealizowany został jako szereg punktów końcowych EJB. Gdy wykrystalizowała się potrzeba stworzenia nowego projektu — rozliczania kart czasu pracy — początkowo zamierzano zrealizować go także na platformie J2EE, jednakże główny architekt, odpowiedzialny za nadzór nad projektem, postanowił wykorzystać swą znajomość z czteroosobowym zespołem konsultantów wyspecjalizowanych w dostarczaniu usług sie­ ciowych tworzonych na platformie .NET. Po konsultacjach zdecydowano więc, że nowy projekt zrealizowany zostanie przez wspo­ mniany zespół jako rozwiązanie .NET. Na podjęciu tej decyzji zaważyły przede wszystkich dwa poniższe względy. • Chęć porównania. Konfrontacja różnorodnych parametrów nowego systemu — głównie wydajności, stabilności i rozszerzalności — stworzonego z udziałem usług sieciowych ASP.NET z analogicznymi parametrami istniejącego systemu B2B utworzonego w technologii J2EE stanowić będzie pouczające doświadczenie, stanowiące podstawę przyszłych decyzji dotyczących wyboru dostawców dla nowo tworzonych projektów. Ciekawość deweloperów i architektów zdecydowanie poszła więc w parze z wymiernymi korzyściami ekonomicznymi. • W TLS dołożono wszelkich starań, by usługi tworzące system B2B były w pełni zgodne z wytycznymi W S-I Basic Profile — zgodność ta została w pełni potwierdzona przez zautomatyzowane narzędzia testujące. Nie ma jednak pewności w kwestii zgodności z rzeczywistym światem usług spełniających jedynie wewnętrzne zadania; usługi publiczne, między innymi Płatność na konto, wywoływane są codziennie przez różnych wnioskodawców, co potwierdza ich międzyplatformową interoperacyjność. Budując we własnym zakresie usługi sieciowe ASP.NET, firma TLS zyskała okazję do przetestowania stopnia interoperacyjności usług obu rozwiązań. I choć nie jest to może argument decydujący, opisana korzyść jest z pewnością znacząca. Mając możliwość wyboru dostawców, TLS może teraz bezpiecznie inwestować w aplikacje bazujące na różnych platformach technologicznych, bo jest pewna w kwestii ich współdziałania (pewność ta potęgowana jest faktem, że przy konstruowaniu nowego systemu zastosowano to samo podejście projektowe, co w przypadku B2B). Od strony technicznej wszystko wygląda więc optymistycznie, natomiast pojawia się pro­ blem zwiększonego wysiłku administracyjnego — wszak na utrzymaniu są teraz aplikacje należące do dwóch różnych platform. Mimo wszystko warto podjąć to ryzyko z podstawowego powodu — doskonalenia umiejętności związanych z platformą .NET. Środowisko firmy jest niestabilne, dynamicznie się rozrasta i eksperci z tej dziedziny — obok ekspertów od J2EE — prawdopodobnie okażą się niezbędni w związku ze zmianami technologicznymi związanymi z przyszłymi (ewentualnymi) fuzjami i przejęciami innych firm.

602

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

18.3.2. Wsparcie dla pierwotnej SOA Jak wykazujemy poniżej, framework .NET zapewnia natywne wsparcie dla wszystkich cech pier­ wotnej SOA poprzez swe środowisko uruchomieniowe i narzędzia programistyczne. Enkapsulacja usług Poprzez tworzenie niezależnych zestawów i aplikacji ASP.NET framework .NET realizuje kon­ cepcję partycjonowania logiki aplikacji na niepodzielne jednostki. Stanowi to promocję komponentyzacji rozwiązań — w swoim czasie kamienia milowego projektowania aplikacji rozproszonych. Ponadto dzięki wsparciu dla usług sieciowych zestawy .NET mogą być komponowane i enkapsulowane przez usługi sieciowe ASP.NET. Możliwość kreowania niezależnych usług spełnia więc postulat enkapsulacji. Luźne powiązanie Środowisko .NET umożliwia komponentom publikowanie interfejsów, które mogą być odnajdy­ wane i wykorzystywane przez potencjalnych klientów. W połączeniu z frameworkiem komunika­ cyjnym, na przykład tym dostarczanym przez MSMQ (patrz poniżej), daje to sposobność do zre­ alizowania koncepcji luźnego powiązania. Co więcej, usługi sieciowe ASP.NET ustanawiają interfejsy reprezentowane jako opisy WSDL, które w połączeniu z frameworkiem komunikacyjnym SOAP wprost realizują luźne powiązanie na gruncie SOA. Komunikowanie Gdy framework .NET ujrzał światło dzienne, praktycznie usunął w cień poprzednią platformę apli­ kacji rozproszonych znaną pod nazwą D istributed interN et A rchitecture (DNA). Na gruncie obu tych platform wymiana komunikatów między komponentami odbywała się za pośrednictwem frameworku MSMQ (Microsoft Messaging Queue — kolejkowany system komunikatów Microsoftu) i stowarzyszonych z nim API. MSMQ stanowi własnościową alternatywę dla natywnego mechanizmu SOAP dostarczanego przez framework .NET, jednak to SOAP jest podstawowym formatem komunikatów współcze­ snej SOA na gruncie .NET, jako że środowisko ASP.NET i wspierające go biblioteki klas .NET ukierunkowane są na wymianę i przetwarzanie komunikatów w tym formacie.

18.3.3. Wsparcie dla zasad zorientowania na usługi Treść tego punktu związana jest z czterema zasadami zorientowania na usługi, które w rozdziale 9. zidentyfikowaliśmy jako pozbawione bezpośredniego wsparcia ze strony technologii pierwszej generacji usług sieciowych — zajmiemy się ich bezpośrednim lub pośrednim wsparciem ze strony frameworku .NET. Autonom ia Na gruncie frameworku .NET usługi sieciowe zachowują autonomię w takim stopniu, na jaki po­ zwala ich wewnętrzna logika. Gdy od usługi sieciowej wymaga się enkapsulowania logiki trady­ cyjnej aplikacji, rezydującej w istniejących komponentach COM (lub zestawach), wyraźne wyzna­ czenie granic funkcjonalności i samowystarczalności może okazać się bardzo trudne.

1 8 .3 . SO A N A PLA TFO R M IE .NET

603

Autonomię usług sieciowych ASP.NET można jednak łatwo osiągnąć, gdy projektowane są „od zera”, bo jest ona wtedy sprawą jedynie ich wewnętrznej logiki. Samodzielne usługi ASP.NET, niewspółdzielące logiki przetwarzania z innymi zestawami, są z natury autonomiczne, bo pod ich pełną kontrolą pozostaje zarówno ta logika, jak i sposób wykorzystywania środowiska urucho­ mieniowego. Wieloużywalność Podobnie jak autonomię, wieloużywalność usług sieciowych ASP.NET łatwiej osiągnąć wówczas, gdy są one projektowane „od zera”, jako elementy nowych rozwiązań. Usługa enkapsulująca „spadkową” logikę czy nawet eksponująca poprzez swój interfejs kompletną „spadkową” aplikację jest wieloużywalna w takim stopniu, jak „spadkowa” logika czy aplikacja. Bezstanowość Usługi sieciowe ASP.NET są domyślnie bezstanowe, lecz możliwe jest tworzenie ich „stanowych” odmian: w wyniku ustawienia atrybutu Enabl e S e s s io n operacji usługi (określanej jako W ebM ethod) w momencie wywoływania tej operacji proces roboczy ASP.NET tworzy obiekt sesji H ttp S e s s io n S ta te , utrzymujący informację o stanie aktywności w ramach sesji między usługami. Ponieważ bezsta­ nowość jest generalnie cenną zaletą usług sieciowych, projektantom tych usług zaleca się reduko­ wanie wykorzystywania tej możliwości do absolutnego minimum. Wykrywalność 0 stopniu wykrywalności usługi decyduje w głównej mierze sposób zaprojektowania jej punktu końcowego. Ponieważ definicje WSDL mogą być wykorzystywane jako punkty wyjścia do two­ rzenia usług sieciowych ASP.NET, wykrywalność usług może być urzeczywistniana na kilka róż­ nych sposobów. • Klasy rezydujące w przestrzeni nazw S y s te m .W e b .S e r v ic e s .D is c o v e r y umożliwiają programowe odnajdywanie opisów usług i schematów XSD. Ponadto framework .NET udostępnia w tym celu osobny UDDI SDK. • Z publikowaną usługą może być skojarzony oddzielny plik, zawierający wskaźnik na jej metadane, kodowany w specyficznym formacie DISCO. To podejście do wykrywalności wspomagane jest przez uruchamiany z wiersza poleceń program disco.exe , wykorzystywany zwykle do lokalizowania i odnajdywania usług w środowisku serwera. • Nowsze edycje produktów grupy Windows Server zawierają rozszerzenie U sługi U D D I , umożliwiające tworzenie prywatnych rejestrów usług. • Warto również nadmienić, że Visual Studio zawiera wbudowaną obsługę UDDI, wykorzystywaną głównie na potrzeby dodawania usług do projektów programistycznych.

18.3.4. Wsparcie dla współczesnej SOA Jak pamiętamy z rozdziału 3., jedną z cech charakterystycznych współczesnej SOA jest jej nie­ ustanne ewoluowanie. Poniżej omawiamy inne wybrane jej cechy w relacji do technologii .NET 1 mechanizmów frameworku .NET.

604

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

Bazowanie na otwartych standardach Biblioteka klas .NET, stanowiąca znaczący składnik frameworku .NET, oferuje kilka przestrzeni nazw, zawierających kolekcje klas zgodnych z przemysłowym standardem pierwszej generacji usług sieciowych. Rozszerzenie WSE dostarcza natomiast wsparcie dla wybranych specyfikacji WS-*. Wreszcie — wersja 2.0 frameworku .NET i Visual Studio oferują natywne wsparcie dla zgodności z wytycznymi W S-IB asic Profile (piszemy o tym w jednym z następnych podpunktów). Warto również pamiętać, że firma Microsoft — twórca platformy .NET — wniosła znaczący wkład w opracowywanie kilku kluczowych otwartych specyfikacji usług sieciowych. Zróżnicowanie dostawców Ponieważ usługi sieciowe ASP.NET tworzone są w zgodzie ze standardami przemysłowymi, ich wykorzystywanie sprzyja różnicowaniu dostawców w skali całego przedsiębiorstwa. Możliwa jest współpraca usług sieciowych ASP.NET z usługami stanowiącymi elementy SOA budowanej z użyciem innej platformy, o ile wszystkie eksponowane usługi sieciowe zgodne są z powszechnie przyjętymi standardami (na przykład wytycznymi W S-I Basic Profile). Jako że framework .NET jest dziełem jednego dostawcy, trudno mówić o różnicowaniu do­ stawców w kontekście jego implementacji czy rozwijania. Niezależnie jednak od tego faktu istnieje rynek tzw. dostawców trzecich, oferujących produkty i narzędzia uzupełniające standardową funk­ cjonalność .NET, a rozmaite produkty serwerowe spoza Microsoftu dają możliwość wdrażania i hostowania usług sieciowych i zestawów .NET. Naturalna interoperacyjność Framework .NET w wersji 2.0, wraz z Visual Studio 2005, dostarczają natywne wsparcie dla zgod­ ności tworzonych usług sieciowych z wytycznymi W S -I Basic Profile. Dotychczas osiągnięcie tej zgodności wymagało specjalnych zabiegów, zaś jej testowanie — niezależnych zewnętrznych na­ rzędzi, obecnie jest ona natomiast zapewniana domyślnie. Ponadto za cenę dodatkowego wysiłku projektowego można zwiększyć generyczną interoperacyjność tworzonych usług, wykorzystując standardowe mechanizmy .NET związane z charakterystyką usług sieciowych pierwszej generacji. Federacyjność Platforma serwerowa BizTalk, mimo iż nie stanowi części frameworku .NET, może być uważana za jego rozszerzenie wykorzystywane do osiągnięcia sfederowania odmiennych środowisk. Plat­ forma ta dostarcza szereg natywnych adapterów, a oferta jest uzupełniana przez adaptery nieza­ leżnych producentów. BizTalk udostępnia również silnik orkiestracyjny z możliwością importo­ wania i eksportowania definicji procesów w języku WS-BPEL. Komponowalność architektoniczna Biblioteka klas .NET to przykład komponowanego modelu programistycznego: jest on granulowany funkcjonalnie — poszczególne klasy odpowiadają pojedynczym funkcjom. Do logiki biznesowej tworzonej usługi importowane mogą więc być tylko te klasy, które są rzeczywiście niezbędne. Podobnie komponowalne jest rozszerzenie WSE, oferujące własną bibliotekę klas odpowia­ dających poszczególnym specyfikacjom WS-*; pozwala to uniknąć włączania do tworzonego roz­ wiązania zbędnych klas tej grupy.

1 8 .3 . SO A N A PLA TFO R M IE .NET

605

Rozszerzalność Usługi sieciowe ASP.NET tworzone za pomocą zalecanych praktyk i zgodnie ze standardami projektowania charakteryzują się rozszerzalnym interfejsem i rozszerzalną logiką aplikacyjną (implementowaną na bazie zestawów zawierających klasy zorientowane na usługi). Rozszerzal­ ność jest więc raczej kwestią odpowiedniego podejścia do wykorzystywania technologii .NET niż naturalną cechą frameworku .NET. Funkcjonalną rozszerzalność rozwiązań można uzyskiwać także za pomocą niezależnych pro­ duktów uzupełniających platformę .NET, na przykład wspomnianego wcześniej serwera BizTalk. Modelowanie biznesowe zorientowane usługowo Koncepcje modelowania zorientowanego na usługi mogą być implementowane na platformie .NET poprzez tworzenie standardowych warstw usług — aplikacyjnych, podmiotowych i zada­ niowych, opisywanych wcześniej w tej książce. Warstwa orkiestracji wymaga użycia silnika orkiestracyjnego, zdolnego do interpretowania definicji procesu centralizującej logikę przepływu pracy. Mechanizmy orkiestracji nie są natywną częścią frameworku .NET, można je jednak implementować przy użyciu produktów rozszerzają­ cych ten framework, między innymi wymienianego wcześniej serwera BizTalk. Tworzenie warstw abstrakcji Na gruncie .NET SOA usługi sieciowe ASP.NET i ich warstwy mogą abstrahować logikę na róż­ nych poziomach. Logika aplikacji, zarówno tych tradycyjnych, jak i nowo tworzonych, może być enkapsulowana i w pełni abstrahowana poprzez prawidłowo zaprojektowane interfejsy. Wyko­ rzystywanie specyficznych nagłówków SOAP i identyfikatorów korelacji umożliwia budowanie kompozycji usług, czemu dodatkowo sprzyja rozszerzenie WSE implementujące między innymi specyfikacje W S-Addressing i WS-Referral. (WSE dostarcza także fundamentalne wsparcie dla bez­ pieczeństwa na poziomie komunikatów, poprzez implementację części frameworku W S-Security ). Zwinność organizacyjna i luźne powiązanie w skali przedsiębiorstwa Ponieważ framework .NET wspomaga tworzenie usług sieciowych zgodnych ze standardami przemysłowymi, właściwe konstruowanie i umiejscawianie warstw usług umożliwia abstrahowa­ nie logiki, bezpośrednio sprzyjające fundamentalnej zwinności organizacyjnej. Obecność warstwy orkiestracji powiększa tę zwinność poprzez uwalnianie orkiestrowanych usług od przetwarzania specyficznego dla logiki procesu i redukowanie wykorzystywania usług zadaniowych. Pożądanym stanem docelowym przedsiębiorstwa zorientowanego na usługi jest dwukierunkowa zwinność organizacyjna, czyli wzajemne odseparowanie domeny biznesowej i domeny technolo­ gicznej. Stan ten można osiągnąć z wykorzystaniem współczesnej SOA, a dokładniej — dzięki pełnej realizacji jej wybranych cech. Framework .NET dostarcza fundamenty dla SOA, umożliwia­ jąc pełne manifestowanie charakterystyki pierwotnej SOA i częściową realizację cech współczesnej SOA. Wykorzystując rozszerzenia platformy .NET — produkcji zarówno Microsoftu, jak i nieza­ leżnych dostawców — można implementować koncepcję luźnego powiązania w skali przedsię­ biorstwa i czerpać korzyści z wynikającej stąd zwinności organizacyjnej.

606

RO ZDZIAŁ 1 8 . ■ PLA TFO RM Y SOA

PODSUMOWANIE •

•

Budowanie rozwiązań zorientowanych na usługi na platformie .NET obejmuje zazwyczaj tworzenie usług-dostarczycieli jako usług sieciowych ASP.NET (o logice komponentów biznesowych implementowanej w postaci zestawów) oraz usług-wnioskodawców (implementowanych za pomocą generowanych autom atycznie klas proxy). Środowisko uruchomieniowe (CLR — Common Language R untim ^ i biblioteka klas .NET to kamienie w ęgielne frameworku .NET.

•

Framework .NET dostarcza środowisko i narzędzia wystarczające do budowania pierwotnej SOA.

•

Cztery zasady orientacji na usługi niew spierane przez usługi sieciowe mogą być na platformie .NET urzeczywistnione przez zastosow anie odpowiednich konwencji projektowych do tworzonych usług sieciowych ASP.NET. Autonomia i wieloużywalność dają się łatwo realizować w przypadku usług projektowanych „od zera" (w przeciwieństwie do usług enkapsulujących i eksponujących logikę „spadkow ych" aplikacji), natom iast uczynienie usługi łatw o wykrywalną w ym aga specjalnych zabiegów projektowych.

•

Niektóre cechy współczesnej SOA znajdują na platform ie .NET w sparcie bezpośrednie, urzeczywistnienie innych jest możliwe przy użyciu różnorodnych rozszerzeń.

•

Framework .NET ułatwia tworzenie usług sieciowych w zgodzie ze standardami przemysłowymi i wytycznymi WS-i Basic Profile. Rozszerzenie WSE dostarcza także ograniczone implementacje specyfikacji WS-*.

18.4. W zględy integracyjne Każde rozwiązanie automatyzacyjne, niezależnie od platformy, reprezentuje kolekcję cech i funkcji zaprojektowanych w celu realizacji pewnej formy procesu biznesowego, związanego z realizacją jednego lub kilku powiązanych zadań. Wymagania dla budowanego systemu są zazwyczaj dobrze zdefiniowane i adekwatne do rzeczywistości w czasie budowania tegoż systemu, jednak — jak to w życiu bywa — prędzej czy później pojawiają się okoliczności rodzące nowe wymagania i sam system staje się obiektem nieuchronnych zmian. Wspomniane „nowe okoliczności” mogą generalnie oznaczać wiele różnych rzeczy, najczę­ ściej jednak jest to jedno z opisanych niżej wydarzeń. • Poszerzenie zakresu działalności biznesowej firm y . Gdy firma przeżywa okres rozkwitu, poszerza zwykle obszar swych zainteresowań biznesowych. W przełożeniu na automatyzację biznesu oznaczać to może jej poszerzenie o nowe operacje, lecz może także wiązać się z dalece posuniętą asymilacją do nowych warunków. Niekonieczne musi to być zbieżne z pierwszorzędnymi celami działalności firmy, za to prawie na pewno oznacza konieczność ingerencji w jej infrastrukturę technologiczną odpowiedzialną za automatyzację oryginalnego procesu biznesowego. • Zaw ężenie zakresu działalności biznesowej firm y . Konieczność redukcji zakresu aktywności firmy może wynikać z ogólnego klimatu ekonomicznego, zdarzeń związanych bezpośrednio z firmą lub branżą (takich jak utrata znaczącego klienta, pojawienie się nowego konkurenta i podobne) lub też zamiaru skupienia się na węższej dziedzinie działalności i wyspecjalizowaniu się w niej — nie zawsze zawężenie biznesu musi być synonimem redukcji rozmiaru firmy. Tak czy inaczej wymaga to znaczącej adjustacji istniejących procesów biznesowych, a w konsekwencji — znaczących zmian w logice automatyzacji tych procesów.

1 8 .4 . W ZG LĘ D Y INTEGRACYJNE

607

• Przejęcie firm y. Wiąże się z szeregiem problemów, bo wcielenie zasobów innej firmy do własnego środowiska wymaga integracji skoordynowanej na wielu poziomach. Istniejące procesy biznesowe ulegają bądź to poszerzeniu, bądź też muszą zostać gruntownie przemodelowane, podobnie jak wspomagająca je logika automatyzacyjna. Z reguły największe problemy takiej integracji wynikają z niezgodności modeli danych pod względem projektu i zawartości. • Połączenie fir m . Ta sytuacja rodzi inne zgoła wymagania integracyjne niż przejęcie firmy. Relacje między łączącymi się firmami nie zawsze są jasne i oczywiste, w rezultacie każda z nich musi zaakceptować pewną formę porozumienia operacyjnego. Integracja rozwiązań automatyzacyjnych może mieć charakter bezpośredni, może być dokonana drogą przystosowania jednego do wymogów drugiego bądź też może obejmować pewną formę pomostu między obydwoma rozwiązaniami. W miarę postępującej globalizacji biznesu powyższe zdarzenia stają się coraz bardziej po­ wszechne. Nie jest dziś już sensowne pytanie, czy firma stanie w obliczu koniecznych zmian, ale kiedy one nastąpią; to jeszcze bardziej zwiększa znaczenie zwinności organizacyjnej. Skoro więc dynamika zmian jest tak znacząca, iż obejmuje wiele procesów i środowisk aplikacyj­ nych, staje się ona dla firmy testem zdolności adaptacyjnych w różnych aspektach, między innymi: • interoperacyjności międzyplaformowej, czyli zdolności do integrowania samodzielnych dotychczas aplikacji z innymi aplikacjami opracowanymi i rezydującymi na platformach innych dostawców; • elastyczności interoperacyjności m iędzyplaform ow ej, czyli zdolności do poszerzenia lub całkowitego zastąpienia istniejących kanałów integracyjnych w odpowiedzi na zmiany biznesowe lub technologiczne; • abstrakcyjności logiki aplikacji, czyli zdolności do zmodyfikowania lub nawet całkowitego zastąpienia logiki aplikacji (często przy użyciu nowych technologii). Nadzieja na zwinność organizacyjną, którą daje współczesna SOA, może zostać spełniona przez tworzenie architektur integracyjnych. Opisane w tej książce cechy charakterystyczne SOA i płynące z nich pożytki dają firmom silny oręż do walki z trudnościami i wyzwaniami, jakie wciąż pojawiają się w dynamicznie zmieniającej się rzeczywistości biznesowej; integracja zorientowana na usługi stwarza możliwość skutecznego stawiania czoła owym wyzwaniom — na usługowym fundamencie SOA.

Rysunek 18.23. Testament SOA — odmienne rozwiązania swobodnie wymieniające informację za pośrednictwem otwartej platformy komunikacyjnej

60S

ROZDZIAŁ 18. a PLATFORMY SOA

D odatek A

Analizy przypadków — konkluzja A.1. RailCo Ltd. A.2. Transit Line Systems Inc. (TLS) A.3. Myjnia samochodów W3C Oasis

610

D O D A TE K A ■ A N A L IZ Y P R ZYPA D K Ó W — KONKLUZJA

A .1 . R ailC o Ltd. Pierwotnie głównymi celami unowocześniania systemów automatyzacji w RailCo były chęć utrzy­ mania konkurencyjności i odzyskanie dominującej pozycji w relacjach z głównym klientem — TLS. Firma RailCo utraciła tę pozycję, gdy na rynku pojawił się konkurencyjny producent części oferujący niższe ceny i zdolny do współpracy online z systemem B2B firmy TLS. Zbudowanie przez RailCo dwóch usług sieciowych —Wystawienie faktury i Realizacja zamówienia — współdziałających ze wspomnianym systemem, pozwoliło na przywrócenie relacji handlowych z TLS. (Nieco później dodano jeszcze jedną usługę — Subskrypcja TLS — współdziałającą z usługą TLS Powiadamianie). Przywrócenie relacji handlowych z TLS nie oznaczało jednak dla RailCo odzyskania dawnej, dominującej pozycji: z TLS współpracował już konkurencyjny dostawca, z którym RailCo rywali­ zować musiała o niemal każde zamówienie. Aby zrekompensować sobie znaczącą utratę zysków i powstrzymać pogarszającą się kondycję finansową, RailCo zmuszona została do poszukiwania nowych klientów — kompanii transporto­ wych — zdolnych do współpracy w trybie online. Oczywiście zbiór usług, jakim dysponowała firma RailCo, był do tego celu niewystarczający, bo usługi stworzone zostały pod kątem wymagań pojedynczego partnera — TLS. RailCo stanęła więc w obliczu strategicznego wyboru — wyboru między opracowywaniem specyficznego zestawu usług dla każdego nowego klienta a stworzeniem od podstaw jednego, uniwersalnego zestawu zdolnego do obsługi wielu klientów. Ostatecznie wy­ brany został drugi wariant: zdecydowano jednocześnie, że tworzenie nowego systemu odbędzie się zgodnie z zasadami i duchem SOA. Dotychczas w RailCo realizowane były dwa główne procesy biznesowe: • Proces realizacji zamówienia, przyjmujący od klienta i przetwarzający zlecenia zakupu, • Proces wystawiania faktury, wysyłający klientowi fakturę. Modernizację istniejących rozwiązań rozpoczęto od analizy zorientowanej na usługi, której rezultatem było wyłonienie szeregu kandydatur na usługi. Ujawniło to konieczność skonstru­ owania następujących potencjalnych usług i ich warstw: • warstwy usług biznesowych zawierającej dwie usługi zadaniowe, • warstwy usług aplikacyjnych składającej się z czterech usług aplikacyjnych. Posiadane zasoby technologiczne i ograniczony budżet nie pozwoliły RailCo na zainwestowa­ nie w oprogramowanie middleware realizujące orkiestrację; z konieczności zrezygnowano więc z warstwy orkiestracji centralizującej logikę biznesową. Ostatecznie wymodelowano i zaprojektowano dwie usługi zadaniowe: • Przetwarzanie faktury, • Przetwarzanie zamówienia, i cztery aplikacyjne: • Tradycyjny System, • Obserwowanie folderu, • Konwersja, • Kontrola metadanych.

D O D A TE K A ■ A N A L IZ Y P R ZYPA D K Ó W — KONKLUZJA

611

Wieloużywalność i rozszerzalność to dwie cechy, które miały być najważniejsze w odniesieniu do projektowanych usług aplikacyjnych. Projektowano te usługi, myśląc o spełnieniu bieżących wymagań biznesowych i o przyszłej rozszerzalności, by przystosować je do nowych wymagań za cenę jak najmniejszego wysiłku. Dla realizacji Procesu wystawiania faktury skomponowano wymienione usługi w dwupo­ ziomową hierarchię, w ramach której usługa zadaniowa Przetwarzanie faktury koordynuje wy­ konywanie podporządkowanych jej usług aplikacyjnych (patrz rysunek A.1).

Warstwa usług biznesowych Warstwa usług aplikacyjnych

Rysunek A.1. Kompozycja usług RailCo automatyzująca Proces wystawiania faktury Podobnie Proces realizacji zamówienia zautomatyzowany został przez usługę Realizacja zamó­ wienia z wykorzystaniem dwóch spośród wymienionych usług aplikacyjnych (patrz rysunek A.2).

Warstwa usług biznesowych Warstwa usług aplikacyjnych

Rysunek A.2. Proces realizacji zamówienia automatyzowany przez usługę Realizacja zamówienia, komponującą dwie wieloużywalne usługi aplikacyjne

612

D O D A TE K A ■ A N A L IZ Y P R ZYPA D K Ó W — KONKLUZJA

Zdecydowanie złą wiadomością dla RailCo okazał się fakt, że ograniczony budżet nie pozwala na ponowne zatrudnienie zespołu specjalistów platformy .NET, który zaprojektował i zrealizował pierwotny zestaw usług. Firma postanowiła więc kontynuować rozbudowę systemu własnymi siłami, tym razem z użyciem platformy J2EE, wykorzystując umiejętności swych programistów, którzy w języku Java skonstruowali tradycyjny system finansowo-księgowy. W rezultacie firmie udało się zrealizować założone cele: powstała SOA obejmująca dwa roz­ wiązania zorientowane na usługi. RailCo może teraz kontynuować swe relacje biznesowe z TLS i poszukiwać nowych kontrahentów. Wynikająca z SOA elastyczność daje podstawy do oczeki­ wań, że ewentualne nowe wymagania ze strony klientów dadzą się zrealizować stosunkowo pro­ sto, bez większej ingerencji w stabilną strukturę działającego systemu. Zestandaryzowana warstwa wieloużywalnych usług aplikacyjnych powinna umożliwiać spełnienie tych wymagań bez ingero­ wania w te usługi — a gdyby nawet taka ingerencja była potrzebna, to funkcjonalne poszerzenie tej warstwy nie powinno wiązać się ze znaczącymi zmianami zaimplementowanych już usług. Kiedy w przyszłości RailCo zdecyduje się na zastąpienie obecnych usług zadaniowych przez warstwę orkiestracji, abstrakcja realizowana przez warstwę usług aplikacyjnych pozwoli na unik­ nięcie kosztownego przeprojektowywania tych usług. Po zakończeniu projektu odkryto w RailCo korzystny efekt uboczny dokonanych zmian. Otóż tworząc usługę Tradycyjny system, będącą de facto otoczką dla tradycyjnego systemu finansowoksięgowego, utworzono punkt końcowy eksponujący ten system w formie usługi, czyli otwierający możliwości jego integracji ze środowiskiem zorientowanym na usługi. Szczególnie korzystna oka­ zała się w tym kontekście integracja z systemem komunikacji z menedżerami (patrz punkt 2.2.3). Umożliwienie wymiany danych między dwoma wymienionymi systemami RailCo pozwoliło na znacznie efektywniejszą obsługę klientów, bo skoordynowano tę obsługę z profilami historii finan­ sowych i innymi danymi administracyjnymi.

A .2 . T ra n s it Line S ystem s Inc. (TLS) Gdy po raz pierwszy zawitaliśmy do firmy TLS, funkcjonowało już w niej rozwiązanie zoriento­ wane na usługi w postaci systemu B2B z powodzeniem realizującego transakcje online z licznymi kontrahentami. Na system ten składały się warstwy następujących usług biznesowych i aplikacyjnych: • Płatność na konto, • Zlecenie zakupu, • Profile dostawców, • Rejestr księgi głównej, • Równoważenie obciążenia, • Polityka wewnętrzna, i dodana później usługa • Powiadamianie. Jak pamiętamy, nie było konieczności wykorzystywania usług zadaniowych ani usługi proce­ sowej, bo usługi Płatność na konto i Zlecenie zakupu zawierały całość logiki biznesowej nie­ zbędnej do wysyłania zleceń zakupu i odbierania faktur.

D O D A TE K A ■ A N A L IZ Y P R ZYPA D K Ó W — KONKLUZJA

613

W TLS postanowiono inwestować w rozwój SOA, kierując się głównie dwiema następującymi przesłankami: • środowisko IT firmy powinno być wystarczająco elastyczne, by można je było łatwo przystosowywać do zmian w modelach biznesowych — zmian zachodzących stosunkowo często; • wiele funkcjonujących samodzielnie systemów, stanowiących rezultat fuzji i przejęć innych firm, powinno zostać sfederowanych w pojedyncze, spójne środowisko. W ramach tej inicjatywy informatycy TLS przystąpili do tworzenia kolejnego rozwiązania — automatyzacji i walidacji kart czasu pracy. Nowy projekt obejmował analizę uwzględniającą między innymi możliwość zmiany dotychczasowej konfiguracji warstwy usług. Dzięki postępowi technologicznemu firma zyskała teraz okazję do rozpatrzenia opcji, które nie były dla niej dostępne w czasie, gdy budowane były początkowe rozwiązania. Rezultatem przeprowadzonej wnikliwej analizy zorientowanej na usługi stało się wymodelo­ wanie szeregu kandydatur na usługi, reprezentujących łącznie logikę projektowanego Procesu rozliczania karty czasu pracy. Po szczegółowym porównaniu trzech proponowanych konfiguracji warstw usług zdecydowano o wyborze konfiguracji następującej hierarchii warstw: • warstwa orkiestracji zawierająca pojedynczą usługę procesową, • warstwa usług biznesowych, zawierająca trzy usługi podmiotowe, • warstwa usług aplikacyjnych, zawierająca jedną usługę (później rozszerzono tę warstwę o dwie kolejne usługi). Warstwa orkiestracji byłą dla firmy nowością, bo poprzednio wykorzystywana przez TLS platforma nie oferowała wsparcia dla silnika orkiestracyjnego. W rezultacie procesu projekto­ wania zorientowanego na usługi sformułowano definicje interfejsów następujących usług pod­ miotowych: • Pracownik, • Karta czasu pracy, • Faktura, i dwóch następujących usług aplikacyjnych: • Powiadamianie, • Zasoby ludzkie (HR). Przy okazji odkryto, że istniejąca usługa Płatność na konto, stanowiąca część istniejącego systemu B2B, może być zdolna do wykonywania przetwarzania na rzecz usługi Faktura. Oczywi­ ście, ten ewidentny przejaw wieloużywalności skwapliwie wykorzystano. Kolejnym krokiem było ujęcie istniejącej logiki przepływu pracy w formalne ramy projekto­ wania procesu biznesowego, czego efektem było powstanie definicji Procesu rozliczania karty czasu pracy w języku WS-BPEL. Definicja ta ostatecznie koordynowała funkcjonowanie wszyst­ kich usług, wraz z zaplanowaną usługą orkiestracyjną (patrz rysunek A.3).

614

D O D A TE K A ■ A N A L IZ Y P R ZYPA D K Ó W — KONKLUZJA

Warstwa orkiestracji usług Warstwa usług biznesowych

Rysunek A.3. Warstwy usług nowego rozwiązania SOAw firmie TLS Jednocześnie w TLS postanowiono, że nowe rozwiązanie — System rozliczania karty czasu pracy — tworzone będzie nie na platformie J2EE, jak poprzedni system, lecz z użyciem platformy .NET. Zdecydowało o tym kilka przyczyn, między innymi dostępność zespołu konsultantów-ekspertów tej platformy, ale przede wszystkim chęć poszerzenia własnych doświadczeń i przetestowanie usług na obu platformach pod kątem współdziałania (interoperacyjności). Budując swe drugie rozwiązanie zorientowane na usługi, firma TLS uczyniła niewielki wpraw­ dzie, ale znaczący, krok w kierunku realizacji swych pierwotnych celów. • Stworzoną warstwę orkiestracji usług można będzie z powodzeniem wykorzystywać w przyszłych rozwiązaniach; pojawiła się ona na wczesnym stadium rozwoju SOA, zatem będzie można za jej pomocą centralizować abstrakcje procesów biznesowych bez znaczącego rewidowania projektów istniejących usług. • Poszerzając pierwotny repertuar swych usług podmiotowych, TLS przyczyniła się do zwiększenia własnej zwinności organizacyjnej. Warstwa orkiestracji usług w połączeniu z warstwą biznesowych usług podmiotowych tworzą solidny fundament do abstrahowania logiki biznesowej, a luźne powiązanie warstw usług biznesowych i aplikacyjnych uchroni przed pogarszaniem wydajności systemu w miarę rozrastania się tych warstw. • Eksponując logikę swych tradycyjnych systemów HR i rozliczania czasu pracy oraz abstrahując kolejne części tradycyjnego systemu finansowo-księgowego, TLS przyczyniła się do zwiększenia stopnia sfederowania swego środowiska. Oczekuje się, że sfederowanie aplikacji obniży koszty przyszłych projektów integracyjnych.

D O D A TE K A ■ A N A L IZ Y P R ZYPA D K Ó W — KONKLUZJA

615

Sprecyzowane na posiedzeniu zarządu strategiczne plany TLS przewidują przejęcie firmy bę­ dącej producentem części i podzespołów; pozwoli to firmie zarówno na pozyskiwanie niezbędnego asortymentu po znacznie niższych cenach, jak i występowanie na rynku w nowej roli — dostawcy tychże części. Wśród upatrzonych kandydatów do przejęcia znajduje się między innymi firma RailCo Ltd. Jednym z jej atutów na liście ewaluacyjnej jest dysponowanie rozwiązaniem automatyzacyjnym zawierającym zestandaryzowane aplikacje zorientowane na usługi oraz punkty końcowe ekspo­ nujące logikę starszych aplikacji. Menedżerowie IT TLS, zainspirowani sukcesem nowego rozwiązania zorientowanego na usługi, poprosili architektów o ocenę możliwości współpracy online z każdym z potencjalnych kandy­ datów do przejęcia; preferowani mają być kandydaci dysponujący zestandaryzowanymi środowi­ skami zorientowanymi na usługi. RailCo prezentuje się w tym rankingu wyjątkowo korzystnie, ze względu na pożytki płynące z jej SOA i przewidywane wyjątkowo niskie koszty i wysiłki in­ tegracyjne.

A .3 . M y jn ia s a m o c h o d ó w W 3 C O asis Dawno nie pisaliśmy o losach naszego wspólnego przedsięwzięcia. Krótko po tym, jak uzyskali­ śmy koncesję na prowadzenie naszej działalności, spotkaliśmy się z Ronem — właścicielem zaprzyjaźnionej myjni, od której dzierżawiliśmy zasoby w godzinach szczytu. Ron przedstawił ofertę kupna naszej firmy, którą to ofertę, po krótkiej dyskusji, zdecydowaliśmy się zaakceptować. Bob, Jim i ja zostawiliśmy nasze wiadra, gąbki, mydliny i zaczęliśmy szukać nowych okazji do po­ żytecznej i opłacalnej działalności. Chuck natomiast skorzystał z propozycji Rona i zajął się sprawami administracyjnymi w jego nowym nabytku. Ron dostrzegł w nim wartościowy zasób z perspektywy planowanej fuzji obu firm w pojedyncze (zorientowane na usługi, nomen omen) przedsiębiorstwo kompleksowej higieny motoryzacyjnej.

616

DODATEKA ■ ANALIZY PRZYPADKÓW— KONKLUZJA

D odatek B

Modele usług — lista referencyjna

Usługi klasyfikować można zarówno na podstawie natury enkapsulowanej przez nie logiki, jak i na podstawie typowego sposobu ich wykorzystywania na gruncie SOA. W treści tej książki wie­ lokrotnie pojawiają się odniesienia do tej klasyfikacji, a jej rezultaty nazywane są modelami usług. Ponieważ odwołania do modeli usług są z konieczności rozproszone po całej książce, posta­ nowiliśmy zebrać je tutaj w postaci krótkiej listy referencyjnej. Należy pamiętać, że ze względu na sposób dokonywania wspomnianej klasyfikacji konkretna usługa może kwalifikować się w kate­ goriach więcej niż jednego modelu.

618

D O D A TE K B ■ M O D ELE USŁUG — LISTA REFERENCYJNA

Tabela B.1. Przegląd modeli usług Model usługi U sługa aplikacyjna

Opis

Odwołania w rozdziałach

G eneryczna k ategoria rep rezen tu jąca usługi

9., 11., 12. i 15.

zaw ierające logikę w yw odzącą się z kon k retn eg o rozw iązania lub p latfo rm y technologicznej. G eneralnie u sługi w yróżniane są jako aplikacyjne p rz y tw o rz en iu w arstw abstrakcji usług. U sługa biznesow a

G eneryczna k ateg o ria rep rezen tu jąca usługi

5., 9., 11., 12. i 15.

zaw ierające logikę p rocesów biznesow ych. Przy defin io w an iu specjalizow anych w arstw usług u sługi plasujące się w w arstw ie u słu g biznesow ych o kreślane są w spólnie jako usługi biznesow e. Indyw idualnie n a to m iast każda usługa biznesow a m oże kw alifikow ać się jako usługa p o d m io to w a albo zadaniow a. U sługa h ybrydow a

U sługa zaw ierająca logikę zarów no biznesow ą, jak

9.

i aplikacyjną. D o tej k a tegorii n ależy w iększość u słu g tw orzonych jako części tradycyjnych rozw iązań. W kontekście organizow ania usług w w arstw y u sługi hybrydow e zalicza się do w arstw y u słu g aplikacyjnych. U sługa użytkow a

U sługa oferująca w ieloużyw alną logikę. K ategoria ta

5. i 9.

zdefiniow ana została p rzed e w szystkim z m yślą o klasyfikacji u słu g aplikacyjnych nieśw iadom ych k o n k retn eg o rozw iązania, lecz m oże być stosow ana także w o d n iesien iu do w ieloużyw alnych usług biznesow ych. U sługa k o n tro le r

U sługa k o m p o n u ją c a in n e usługi. W yró żn ia się k ilka o d m ian tej kategorii, zależnie od um iejscow ienia k o n tro le ra w ogólnej h iera rch ii kom pozycji. K o n tro ler n a najw yższym sto p n iu h iera rch ii nazyw any jest k o n tro le re m głów nym (m aster), usługa k o m p o n u ją c a frag m en t p o d z b io ru kom pozycji określana jest m ian em subkontrolera.

5.

D O D A TE K B ■ M O D ELE USŁUG — LISTA REFERENCYJNA

619

Tabela B.1. Przegląd modeli usług — ciąg dalszy Model usługi

Opis

Odwołania w rozdziałach

U sługa k o o rd y n a to r

Z k o n cep cji koo rd y n acji w yw odzą się trz y m odele

6.

usług: k o o rd y n a to r, k o o rd y n a to r transakcji niepodzielnej i k o o rd y n a to r aktyw ności biznesow ej — w szystkie definiow ane w specyfikacji W S-C oordination i zw iązanych z n ią pro to k o łach . U sługa p rocesow a

U sługa rep rezen tu jąca p ro ces biznesow y jako

6., 9., 11., 12. i 16.

zaim p lem en to w an y n a p latfo rm ie orkiestracyjnej i opisany w kateg o riach form alnej definicji procesu. U sługi procesow e rezydują w w arstw ie orkiestracji usług. B iznesow a usługa

A gnostyczna p rocesow o o d m ia n a usługi biznesow ej

p o d m io to w a

rep rezen tu jąca jed en lub więcej pow iązanych

9., 11., 12. i 15.

p o d m io tó w (en cji) biznesow ych. T en typ usługi w y różniany jest w zw iązku z definiow aniem w arstw y usłu g biznesow ych. B iznesow a usługa

Specyficzna dla p ro c esu o d m ia n a usługi biznesow ej,

zadaniow a

rep rezen tu jąca niep o d zieln ą jed n o stk ę logiki

9., 11., 12. i 15.

przetw arzania. U sługi zadaniow e tym się ró ż n ią od u słu g procesow ych, że ich logika p rzetw arzan ia jest ich w ew nętrzną spraw ą, a n ie w ynika z zew nętrznej definicji procesu. U sługa integracyjna

U sługa aplikacyjna funk cjo n u jąca rów nież

9.

jako p u n k t k o ńcow y w środow isku integrującym dw ie aplikacje lub wiele aplikacji. U sługa-otoczka

O d m ia n a usługi integracyjnej, enkapsulująca i eksponująca logikę rezydującą w ew nątrz tradycyjnego („spadkow ego”) system u. U sługi-otoczki d o starczane są zazwyczaj p rzez p ro d u c e n tó w w sp o m n ian y ch system ów i jako takie przew ażnie cechują się niestan d ard o w y m i interfejsam i.

9.

620

DODATEKB■ MODELE USŁUG— LISTAREFERENCYJNA

O autorze

Thomas Erl jest autorem serii książek poświęconych tematyce SOA, ukazujących się w serii Prentice Hall Service-Oriented C om puting Series fro m Thom as Erl. Jest także redaktorem „SOA Magazine”. Jego książki, w nakładzie ponad 80 000 egzemplarzy, stały się światowymi bestsellerami i zy­ skały formalne poparcie specjalistów największych firm programistycznych, takich jak IBM, Microsoft, Oracle, BEA, Sun, Intel, SAP i HP. Najnowsze pozycje w tej serii to Principles o f Service Design i SOA Design Patterns (prezentowane, wraz z wieloma innymi, na stronie www.soabooks.com). Jest także założycielem firmy SOA Systems Inc. (w w w .soasystem s.com ) specjalizującej się w konsultingu i szkoleniach dotyczących SOA w ujęciu niezależnym od dostawców. Przez swą współpracę z organizacjami standaryzacyjnymi oraz dzięki własnym pracom badawczym ma swój znaczący wkład w przemysł SOA, głównie w obszarze zorientowania na usługi oraz metodologii SOA. Jest wykładowcą i instruktorem na wielu publicznych i prywatnych przedsięwzięciach oraz organizatorem niezliczonych warsztatów i prelekcji. Opracował przemysłowy program szkoleniowo-certyfikacyjny z zakresu SOA (www.soaschool.com i www.soatraining.com ). Jego artykuły publikowane są na łamach światowych pism fachowych oraz w witrynach WWW; udziela licznych wywiadów, między innymi dla „Wall Street Journal”, często dostępny jest także na czacie. Autor zaprasza na swą prywatną stronę w w w.thom aserl.com .

622

O AUTORZE

O fotografiach

Mam nadzieję, że spodoba się czytelnikom kolekcja fotografii na okładce i winietach tytułowych rozdziałów. Wykonałem je niedawno w różnych miejscach świata, między innymi w Bratysławie, Pradze, Wiedniu i Waszyngtonie. Niektóre z nich wprowadzają elementy symbolizmu związane z konkretną tematyką, inne pozostają z tą tematyką w raczej luźnym związku. Niewątpliwie jednak wszystkie w sposób niepowtarzalny wyodrębniają fragmenty rzeczywistego świata — podobnie jak usługi.

62 4

O FOTOGRAFIACH

Skorowidz

.NET, 606 agenty usług, 599 federacyjność, 604 interfejsy API, 597 języki program ow ania, 596 kom ponenty architektoniczne, 596, 604 luźne powiązanie, 605 m odelow anie biznesowe, 605 n aturalna interoperacyjność, 604 rozszerzalność, 605 rozszerzenia, 600 środowisko uruchom ieniow e, 596 usługa-dostarczyciel, 597 usługa-wnioskodawca, 598 warstwy abstrakcji, 605 wsparcie dla pierwotnej SOA, 602 współczesnej SOA, 603 zasad zorientow ania n a usługi, 602 zwinność organizacyjna, 605 .NET Passport, 232

A abstrakcyjność, 49, 60 ACID, 175 adm inistrow anie, 97, 104 adm inistrow anie usługami, 317 adresowanie, 199, 204 agent dostawcy usługi, 116 wnioskodawcy usługi, 117 agenty usług, 116, 575, 586 aktywne przepytywanie, 107 aktywności biznesowe, 179, 182, 185, 375 niepodzielne, 376 podstawowe, 188

procesowe, 376 proste, 164 prym itywne, 165 strukturalne, 188 usług, 163, 165 złożone, 164, 166, 173 alokowanie zasobów, 371 analiza przypadków, 36, 609 spekulatywna, 466, 469 wymagań aplikacyjnych, 363 zorientow ana na usługi, 329-332, 349, 459 identyfikacja systemów automatyzacji, 333 modelowanie kandydatur, 334 zakres analizy, 333 zorientowanej n a usługi, 315, 418 zstępująca, 325 anulowanie transakcji, 177 aplikacje zorientow ane na usługi, 66 klient-serwer, 96 aplikacyjne usługi użytkowe, 307 architektura aplikacji, 91 enterprise, 92 hybrydowa usług sieciowych, 106 integracyjna zorientow ana na usługi, 69 internetow a rozproszona, 98, 100, 110 klient-serwer, 93 dwuwarstwowa, 94 jednowarstwowa, 94 wielowarstwowa, 99 pow iadom ień, 240 technologiczna usług, 567 usług sieciowych, 84 zorientowana na usługi, 92, 253, 257

asercja, 233 asercja polityki, 219 ASP.NET, 602, 603 asynchroniczne przerwania, 107 atrybut PolicyURIs, 548 Preference, 547 Usage, 547 atrybuty elem entu invoke, 500 receive, 501 reply, 501 autom atyczne generowanie interfejsów, 412, 414 kodu XML, 421 autonom ia, 49 n a poziom ie usług, 271 zupełna, 271 autoryzacja, authorization, 232

B bezpieczeństwo, 96, 104, 229, 236 n a poziom ie kom unikatów , 234 n a poziom ie transportu, 234 usług sieciowych, 76 bezstanowość, 50 bierna usługa pośrednicząca, 120 bloki konstrukcyjne m odelowania, 375 nagłówka, 140 BPEL4WS, 495 BPM, Business Process M anagem ent, 83, 340 broker powiadam iania, 241 budow a usług, 50

626

S K O R O W ID Z

C cechy niewspierane, 293 SOA, 50, 64, 293 cele biznesowe, 37, 40 m odelowania, 370 charakterystyka SOA, 65 charakterystyka współczesnej SOA, 291 choreografie, 191, 194-196 ciało, body, 139 ciało kom unikatu SOAP, 410 cykl życiowy SOA, 314, 318 czas trw ania prostych aktywności, 167

D definicja SOA, 64 WSDL, 131, 137 procesu, 187 dekom pozycja procesu, 351 deszyfrowanie, 236 diagram opisowy logiki procesu, 521 DNA, D istributed interN et Architecture, 602 d o kum ent XML: bazujący na danych, 141 bazujący na dokum encie, 141 dokum entow anie usług, 491 dostaw cy SOA, 88

E EDI, Electronic D ata Interchange, 82 EJB, 588 elem ent AcknowledgementRange, 540 AckRequested, 542 Address, 535 All, 546 assign, 502 BinarySecurityToken, 556 binding, 405 Body, 410 catch, 503 catchAll, 503 CipherData, 558 CipherReference, 558 CipherValue, 558 complexType, 399 C oordinationC ontext, 505 C oordinationType, 507

copy, 502 definitions, 402 Dialect, 552 docum entation, 408 elem ent, 399 EncryptedData, 558 endpoint, 407 E ndpointReference, 533 Envelope, 409 ExactlyOne, 545 Expires, 506 Fault, 411 faultH andlers, 503, 521 from , 503 GetM etadata, 551 H eader, 409 Identifier, 506, 552 im port, 400, 407 include, 400 input, 405, 406 interface, 404 invoke, 500, 521 LastMessage, 539 message, 403 M essageNum ber, 539 M etadata, 552 M etadataReference, 552 M etadataSection, 552 Nack, 541 operation, 404, 406 otherwise, 502 output, 405, 406 part, 404 partnerLink, 496 partnerLinkType, 497 Password, 556 Policy, 545 PolicyAttachm ent, 548 PolicyReference, 547 port, 407 portType, 404 receive, 500 RegistrationService, 507 reply, 501 schema, 399 Security, 556, 557 SecurityTokenReference, 556 sequence, 499 Sequence, 539 SequenceAcknowledgem ent, 540 service, 407 simpleType, 400 switch, 502 throw, 521 types, 402

Usernam e, 556 U sernam eToken, 556 variables, 498 elem enty grupy MI, 535 W S-Addressing, 534 WS-BPEL, 504 W S-ReliableMessaging, 543 XM L-Signature, 559 em ulowanie usług procesowych, 370 encje biznesowe, 136 enkapsulacja usług, 588 ewolucja SOA, 63, 79

F farm a serwerowa, 104 fazy cyklu życiowego SOA, 314, 318 federacyjność, 57 filtry subskrypcji, 242 finalizowanie transakcji, 177 form at kom unikatów , 82 fram ew ork .NET, 594 JMS, 588 kom unikacyjny, 48 kom unikacyjny SOAP, 148 usług sieciowych, 112, 253 W S-Notification, 239, 245 WS-Policy, 219, 222, 237, 544 WS-Security, 104, 236, 555 funkcja getVariableData, 499 getVariableProperty, 499

G generowanie interfejsów, 412 kodu XML, 421 granulacja interfejsu usługi, 424 grupowanie aktywności biznesowych, 377 kandydatur na operacje, 365 GUI, Graphical User Interfaces, 413

I identyfikacja, 231 identyfikowanie logicznych jednostek pracy, 369 informacje o kom unikatach, 534 o usługach-dostarczycielach, 223

SK O R O W ID Z

627

in frastruktura kom unikacyjna, 71 integralność, integrity, 233 interakcje, 193 interfejs, 132 abstrakcyjny usługi, 445 publiczny, 81 p u n k tu końcowego, 583 usługi, 412, 442, 449 interfejsy API, 581 izolacja, isolation, 175

J J2EE, Java 2 Platform Enterprise Edition, 577-579, 593 agenty usług, 586 autonom ia usług, 588 bezstanowość, 589 enkapsulacja usług, 588 federacyjność, 591 interfejsy API, 581 języki program ow ania, 581 komponenty architektoniczne, 580 kom ponow alność architektoniczna, 591 kom unikow anie, 588 luźne powiązanie, 588 m odelow anie biznesowe, 592 rozszerzalność, 592 rozszerzenia, 586 środowisko uruchom ieniow e, 580 typy klienckich proxy, 584 usługi sieciowe, 583 warstwy abstrakcji, 592 wieloużywalność, 589 wsparcie dla orientacji n a usługi, 588 wsparcie dla współczesnej SOA, 589 wykrywalność, 589 zwinność organizacyjna, 592 jakość usług, 53 JAXB, 582 JAXM, 582 JAXP, 581 JAXR, 582 JAX-RPC, 579, 582, 584 JAX-RPC API, 588, 590 jednokrotne logowanie, 230, 232 jednostka logiczna, 109 logiki biznesowej, 573, 574 pracy, 193 język HTML, 80 SAML, 87, 232

SGML, 80 SOAP, 138, 408 UDDI, 136 W S-Addressing, 532 WS-BPEL, 303, 494 WSDL, 81, 82, 128, 298, 401 W S-M etadataExchange, 550 WS-Policy, 544 W S-ReliableMessaging, 538 WS-Security, 555 XACML, 87, 232 XML, 71, 80 XSD, 80, 397 XSLT, 80 języki orkiestracji, 302 program ow ania J2EE, 581

K kanały, 193 kandydatury na kompozycje, 365 na operacje, 350 na operacje usług, 364 na usługi, 350, 359 agnostyczne, 355 aplikacyjne, 364, 368 zadaniowe, 366, 367, 370 klasyfikacja logiki m odelu usług, 371, 373 perm anentna, 125 tymczasowa., 125 klient cienki, 100 gruby, 100 prym itywny, 100 kom pensacja, com pensation, 180 kom ponenty architektoniczne J2EE, 580 COM, 602 EJB, 589 SOA, 256, 257, 416 kom ponow alność, 50, 193 kom ponow alność architektoniczna, 57 kom ponow anie SOA, 416, 417, 420 kompozycja usługi, 123, 362 usługi koordynacyjnej, 168, 170 kom unikacja asynchroniczna, 96 m iędzy usługami, 84 RPC, 106, 421 skrośna, 260 synchroniczna, 93, 96

kom unikat, 106 Get, 554 Get M etadata request, 224 Get M etadata response, 225 Get request, 226 kom unikaty odpowiedzi, 224 powiadamiające, 239, 242 SOAP, 104, 139, 201, 421, 425 subskrypcji, 242 w stylu dokum entow ym , 84, 141 w stylu RPC, 141 zakończenia subskrypcji, 242 żądania, 224 koncepcje węzłów, 144 konfiguracja warstwy usług, 305, 420 konsorcjum W 3C, 80, 86, 90 konstrukcje, 398 konsum enci pow iadom ień, 240 kontekst koordynacji, 169 kontraktowość, 49 kontrakty usług, 133, 262 koordynacja, 167-172 koordynator, 169 aktywności biznesowych, 181 transakcji niepodzielnej, 175 koperta, envelope, 139 korelacje, 214 jako abstrakcja, 215 w adresowaniu, 216 w aktywnościach, 216 w koordynacji, 216 w niezaw odnym kom unikow aniu, 217 w orkiestracji, 216 we wzorcach MEP, 216

L logiczne jednostki pracy, 369 logika aplikacyjna, 95, 101, 250, 294 autom atyzacji, 254, 255 biznesowa, 60, 250, 295, 569, 573 konstrukcji faultH andlers, 521 m odelu usług, 373 przepływu pracy, 472 przetw arzania kom unikatów, 568-571 przetw arzania zorientow ana na usługi, 49 luźne powiązanie, 48, 61, 588, 592

628

S K O R O W ID Z

Ł ładunek użyteczny, payload, 139 łącza partnerskie, 187 łączenie usług, 388

M m enedżer rejestracji publikatora, 241 subskrypcji, 241 m etadane, 133, 223, 491 selektywne pobieranie, 226 wymiana, 227, 229 m odel biznesowy przedsiębiorstwa, 374 pierwotnej SOA, 83 SOE, 373 wymiany komunikatów SOAP, 421 m odele BPM, 340 podm iotów biznesowych, 342 przypadków użycia, 345 usług, 125, 617 usług przedsiębiorstwa, 331 modelow anie biznesowe zorientow ane usługowo, 60, 592, 605 logiczne, 253 logiki biznesowej, 337 usług, 349, 366, 377 aplikacyjnych, 321 biznesowych, 337 wieloużywalności międzyaplikacyjnej, 368 m odularne definicje usług, 424 m odularność, 193 M O M , M essaging-Oriented M iddleware, 82 MSMQ, 602

N nadawca k om unikatu żądania, 117 początkowy, 121 nagłówek, header, 139 inform acyjny, 202, 206, 537 MI, 202, 203 SOAP, 102, 425 narzędzia m odelowania, 414 projektowe, 412 naturalne współdziałanie, 56

niepodzielność, atom icity, 175 niezaprzeczalność, 235 niezawodne kom unikowanie, 206, 212

O OASIS, 86 odbiorca końcowy, 121 OOP, Object Oriented Programming, 98 opakowywanie funkcjonalności, 102 operacje, 253, 446 opis abstrakcyjny, 131 skonkretyzowany, 132 opisy procesów, 436 semantyczne, 134 usług, 48, 128, 131, 135, 137 oprogram ow anie typu m iddleware, 55 optymalizowanie definicji procesu, 527 organizacja standaryzacyjna, 85 OASIS, 86, 90 W 3C, 86, 90 WS-I, 87, 91 orientacja na obiekty, 108, 284 na usługi, 46, 108, 250, 258, 284, 508 orkiestracje, 185, 189-194, 295, 302, 347 orkiestrow ana usługa zadaniowa, 303 oświadczenie, claim, 231 otoczki kom ponentów , 106

P pełzanie granic, 369 pierw otna SOA, 50, 83, 111, 428 pierw otne aktywności biznesowe, 375 MEP, 156 usługi biznesowe, 377 pierw otny proces biznesowy, 377 plan transform acji, 74 planow anie architektury, 418 platform a .NET, 564, 576, 593, 606 J2EE, 564, 576, 593 zorientow ana na usługi, 53 platform y SOA, 563, 564 pobieranie m etadanych, 226 podm iot wnioskodawca usługi, 117 podpis cyfrowy, 235 podzespół usługowy, 123

polityki, policies, 218 asercje, 220 podm ioty, 220 słowniki, 220 w choreografiach, 221 w koordynacji, 221 w niezaw odnym kom unikow aniu, 221 w orkiestracji, 221 wyrażenia, 221 zakresy, 220 załączniki, 221 połączenia dedykowane, 104 popraw a wydajności, 70 port, 132 pośrednik, 119 bierny, 119 czynny, 121 potwierdzenie, 213 negatywne, 208, 210 sekwencji, 208 poufność, confidentiality, 233 powiadam ianie, 238, 244 powiadam ianie systemowe, 244 powiązania fram ew orku .NET, 595 kom ponentów , 102, 257 m iędzy usługami, 48 środowiska J2EE, 579 procedury składowane, stored procedures, 95 proces m odelow ania usług, 351 predefiniowany, 376 realizacji zamówienia, 342, 351, 362 rozliczania karty, 377, 384, 510 WS-BPEL, 508, 509 wystawiania faktur, 228, 341, 472 producenci pow iadom ień, 240 prognozow anie wymagań dekom pozycyjnych, 368 program ow anie zorientow ane obiektowo, 98 projektowanie biznesowej usługi zadaniowej, 470, 482 projektowanie biznesowych usług, 438 biznesowych usług zadaniowych, 469 interfejsu usługi, 412, 442 interfejsu usługi procesowej, 516 operacji usług, 487 procesu biznesowego, 396, 493, 508, 510

SK O R O W ID Z

629

usług, 49, 109, 396, 433, 483, 492 aplikacyjnych, 456, 458 biznesowych, 419 procesowych, 529 zorientow ane n a usługi, 49, 315, 393, 415 protokoły aktywności biznesowych, 181 biznesowe, 187 koordynacyjne, 169 transakcji niepodzielnych, 175 protokół HTTP, 104 SOAP, 81 XML-RPC, 81 prym ityw ne MEP, 156 przedsiębiorstw o zorientow ane na usługi, 63 przepływ, flow, 188 przerw anie procesu, 514 przestrzenie nazw, 423, 426, 489 przetw arzanie aplikacyjne, 95, 102 rozproszone, 67 zam ówienia, 357 przeznaczenie aplikacyjne, 208 RM, 208 przypadek RailCo Ltd., 37 T ransit Line Systems Inc, 39 publiczna w spółpraca, 191 publikatory, 240 pułapki, 73 p unkty końcowe, 201, 569 JAX-RPC, 589 usług, 131

Q QoS, Quality o f Service, 53

R referencje punktów końcowych, 201, 205 rejestr usług prywatny, 135 publiczny, 135 relacje, 193 m iędzy podm iotam i, 343 W S-Addressing, 533 W S-M etadataExchange, 550 WS-Policy, 544 W S-ReliableMessaging, 539 WS-Security, 555

relacyjna baza danych, 93 ręczne kodowanie, 413, 414 ROI, R eturn O f Investm ent, 335 rola, 193 dostarczyciela, 115 pośrednika, 118 wnioskodawcy, 116 role usług, 115 rozproszenie logiki aplikacji, 99 rozszerzalność, 59 rozszerzenia, 85 platform y J2EE, 586 WS-*, 149, 218, 531 rozszerzenie .NET, 600 rów noważenie obciążenia, 120 RPC, Remote Procedure Calls, 99, 110

S SAAJ, 582 SAML, Security A ssertion M arkup Language, 87, 232 scenariusze interakcji, 513, 527 schem at XSD, 398, 424, 443, 460, 569 SEI, Service E ndpoint Interface, 583 sekcja tM odel, 136 sekwencja, sequence, 188, 208 selekcja charakterystyki SOAP, 428 specyfikacji WS-*, 429 składnik kompozycji, 123 słowniki polityki, 220 SOA, Service-Oriented Architecture, 20 SOAP, Simple Object Access Protocol, 81, 138, 425 SOE, Service O riented Enterprise, 63 SOI, Service-O riented Integration, 69 specyfikacja, 85 SOAP, 138 WS-*, 150 W S-Addressing, 203, 206, 537 WS-BPEL, 86 WS-CDL, 86 W S-C oordination, 172, 173, 505 WSDL, 161 W S-Eventing, 242, 245 W S-I Basic Profile, 413 W S-M etadataExchange, 224, 227, 550 W S-ReliableMessaging, 206, 207, 214, 538 WS-Security, 230 WS-SecurityPolicy, 219 XM L-Encryption, 234 XM L-Signature, 234

spójność, consistency, 175 SSL, Secure Sockect Layer, 234 standard, 85 de facto, 85 JMS, 588 SOAP, 84, 161 UDDI, 81, 82, 84 WSDL, 84 standardy m odelow ania usług, 372 projektowe, 394, 423, 435 przemysłowe, 394, 420 standaryzacja, 74 stany aktywności biznesowej, 181 strategia w drożeniow a SOA, 317 wstępująca, 321 zstępująca, 318 zwinna, 324 strategie realizacji SOA, 313 struktura definicji WSDL, 401 dokum entu komunikatu SOAP, 409 kom unikatu SOAP, 139 procesu projektowania, 510 style kom unikatów , 141 subskrybenci, 240, 242 subskrybent, subscriber, 159 system typów, 55 szablony wiązań, 136 szyfrowanie, 234, 236

Ś ścieżka kom unikatu SOAP, 146 ścisłe powiązanie, tight coupling, 102 środowisko uruchomieniowe J2EE, 580

T technologia CORBA, 99 DCOM , 99 testowanie usług, 315 token, 231 transakcje ACID, 175 transakcje niepodzielne, 173, 176, 183 trwałość, durability, 175 tworzenie obiektów, 109 usług, 315 warstw abstrakcji, 592, 605 typ portu, 132 typy asercji polityki, 220, 549 kom unikatów , 224

630

S K O R O W ID Z

typy koordynacyjne, 169 schem atu XSD, 460 usług biznesowych, 307, 348 węzłów, 144, 146 w yodrębnianych usług biznesowych, 344

U uczestnicy, 193 UD DI, 81, 136, 426 ujście zdarzeń, 242 usługa, 132 aktywacyjna, 169, 170 biznesowa, 125 Faktura, 521 Karta czasu pracy, 514 K ontrola m etadanych, 356, 359 kontroler, 126, 618 Konwersja, 472 Konwersja dokum entów księgowych, 464 konwersyjna, 464 Obserwow anie folderu, 475, 478 Płatność n a konto, 117, 124, 127, 141 Polityka wew nętrzna, 121 Pow iadam ianie, 160, 521 Pracownik, 443, 454, 510, 518 procesowa, 308 proxy, 298 Przetwarzanie faktury, 359, 472, 475, 481 Realizacja zam ówienia, 268, 342 rejestracyjna, 169 trasowania, 118 usługa-broker, 238 usługa-dostarczyciel, 130, 569, 574 usługa-dostarczyciel .NET, 598 usługa-dostarczyciel J2EE, 584 usługa-kontroler, 370 usługa-koordynator, 181, 619 usługa-otoczka, 619 usługa-subskrybent, 238, 244 usługa-wnioskodawca, 117, 130, 488 usługa-wnioskodawca .NET, 599 usługa-wnioskodawca J2EE, 585 usługa-wydawca, 238 użytkowa, 125 W ystawienie faktury, 120, 142 Zlecenie zakupu, 117, 130 usługi, 47 abstrakcyjność, 277, 278, 280 adm inistrow anie, 317

agnostyczne, 303, 304, 357 aplikacyjne, 304, 337, 436, 456, 469, 618 analiza spekulatywna, 466 autonom iczność, 270, 277, 281 bezstanowość, 273, 277, 282 biznesowe, 126, 136, 300, 336, 347, 376, 618 biznesowe podm iotowe, 308, 345, 438, 619 biznesowe zadaniowe, 308, 344, 469, 619 dokum entow anie, 491 enkapsulujące, 102 hybrydowe, 298, 301, 305, 309, 618 integracyjne, 619 interfejs, 460 interfejs abstrakcyjny, 445 interfejs standardowy, 449 interoperacyjność, 590 inwentaryzowanie, 441, 459 kom ponow alność, 268, 277-280 kom unikacja, 48 kontraktowość, 278 kontrakty, 262 koordynacja, 172 luźne powiązanie, 264, 277-279 ograniczenia techniczne, 483 partnerskie, 187, 518 podm iotowe, 436, 442, 456 pośredniczące, 119 potw ierdzenie kontekstu, 459 powiązania, 48 procesowe, 187, 509, 516, 619 referencje punktów końcowych, 205 rejestr, 135 rozszerzanie projektu, 450 sieciowe, 68, 81, 111, 153, 197, 286 sieciowe ASP.NET, 602, 604 sieciowe J2EE, 583 sieciowe jako otoczki kom ponentów , 106 sieciowe w ram ach SOA, 107 specyficzne dla protokołów , 169 standardy nazewnicze, 484 standardy projektowania., 419 strategicznie umiejscowione, 591 testowanie, 315 użytkowe, 306, 618 użytkowe aplikacyjne, 306, 308 warstwy, 294, 418 w drażanie, 316, 419 wersjonowanie, 419 w ew nętrzna logika, 265, 568 wieloużywalne, 260, 276, 366

wydajność kompozycji, 419 wykonywane zadania, 567 wykrywalność, 274, 277, 283 zadaniowe, 306, 436 usługowe warstwy abstrakcji, 294 ustanawianie standardów , 420 uwierzytelnienie, authentication, 231

W W3C, W orld Wide W eb Consortium, 86 warstwa interfejsów usług, 253 orkiestracji usług, 296, 302, 307 usług, 62, 418 usług aplikacyjnych, 297, 299 usług biznesowych, 296, 300, 339 usług użytkowych, 298 warstwy abstrakcji, 294 architektury środowiska program istycznego, 565 platform y .NET, 594 platform y J2EE, 578 SOA, 565, 566 wdrażanie usług, 316 w ew nętrzna logika usługi, 568 węzły SOAP, 143 wiązanie, 132 wieloużywalność, 50, 58, 70, 193 WS-Addressing, 199, 200, 203, 206, 532 W S-A tom icTransaction, 173, 178, 184, 507 WS-BPEL, 154, 186, 429, 494, 505, 509 W S-BusinessActivity, 154, 173, 184, 190, 507 W S-CDL, 154, 191 W S-C oordination, 154, 172, 181, 505 W S-Eventing, 199, 242, 245 WS-I, 87 W S-I Basic Profile, 413, 422, 464 W S-M etadataExchange, 199, 224, 227, 550 W S-Notification, 199, 239, 241, 245 WS-Policy, 199, 219, 222, 544 WS-ReliableMessaging, 199, 206, 214, 538 WS-Security, 199, 230, 555 WSDL, 131, 161, 423, 488 WSDL, W eb Services D escription Language, 81, 401 WSE, W eb Services Enhancement, 600 współczesna SOA, 52-64, 84, 112, 153, 197, 290 współpraca, 192

SK O R O W ID Z

wybór organizacji standaryzacyjnej, 90 rozszerzeń SOA, 418, 428 typu koordynacyjnego, 507 warstw usług, 417, 418 wydawca, publisher, 159 wykonywanie zadań równoległe, 529 sekwencyjne, 528 wykrywalność, 50 wykrywalność usługi J2EE, 589 w ym iana kom unikatów , 156, 157 kom unikatów w stylu dokum entow ym , 490 m etadanych, 223, 226, 227, 229 w yodrębnianie usług biznesowych, 339 hybrydowych, 377 wyzwalacze, triggers, 95, 106 wzorce dostarczania kom unikatów , 210 MEP, 156, 161, 163 MEP złożone, 159 wym iany kom unikatów , 155, 162 wzorzec AtLeastOnce, 211 A tM ostOnce, 210 ExactlyOnce, 211 in-only, 162 in-optional-out, 162

631

InO rder, 212 in-out, 162 out-in, 162 out-only, 162 out-optional-in, 162 odpal i zapom nij, 158 publikuj-subskrybuj, 159, 238 robust in-only, 162 robust out-only, 162 wym iany kom unikatów , 132 żądanie-odpowiedź, 157, 162

X XACML, extensible Access C ontrol M arkup Language, 87, 232 XML, Extensible M arkup Language, 80, 421 XM L-Encryption, 234 XM L-Signature, 234 XML Schema, 424 XSD, XML Schema Definition Language, 80, 397, 569 XSLT, XSL T ransform ation Language, 80

Z zadania wykonywane przez usługi, 567 zakończenie koordynacji, 171 zakres logiki biznesowej, 340

założenia polityki, 218 zapewnienie dostarczenia, 210 zarządzanie aktywnościam i, 173 zasady zorientow ania n a usługi, 249, 258, 276, 358, 447, 477 obiektowego, 284 zastosowanie usług biznesowych, 338 zdalne wywoływanie procedur, RPC, 99, 110 zdarzeniowanie, 238, 244 ziarnistość interfejsu, 485 ziarno im plem entacyjne usługi, 583 złącza, links, 188 zorientow anie na usługi, 46, 108, 250, 258, 284, 508 zróżnicowanie dostawców, 55 zwinność organizacyjna, 61, 72, 592

Ź źródło aplikacyjne, 208 RM, 208 zdarzeń, 242

Ż żądanie potwierdzenia, 209 żądanie wym iany m etadanych, 224