Temat: SOA, a może jednak inaczej...

od dawna zastanawiam się na ile moja "lekka" niechęć do SOA w rozumieniu "szyna ESB" jest fobią a na ile projektowym uzasadnieniem kłopotów, wydajnościowych i projektowych (i kosztowych!). Jak trafia mnie projekt czy to integracyjny czy to ERP czy podobny bazuje na domenie jak głównym wyznaczniku wszelkich podziałów na podsystemy.

Niedawno popełniłem projekt, w którym zasugerowałem klientowi pięć dedykowanych dziedzinowych podsystemów (komponentów itp..) w tym portal firmowy i mimo, że klient uważał, że "nikt tak nie robi" (znaczy się informatyk klienta...) to każda próba pójścia drogą proponowana przez tego informatyka była kosztowniejsza, mój projekt bazował właśnie na obsłudze zdarzeń generowanych przez portal użytkownika, projekt informatyka to "typowe" SOA z ESB itp...

a to proszę: trafiam na taki referat i wiele się wyjaśnia, nie ja jeden jestem nawiedzony z moją dziedzinowo-"iwentową" strategią projektowania.... nie tylko oprogramowania ale w ogóle procesów także, "event driven architecture/development" dotyczy całego systemu (czyli także organizacji firmy) nie tylko oprogramowania, ale tu o SOA i event coś tam :), uwazam, że warto posłuchać

http://www.infoq.com/presentations/Domain-Event-Driven...

Temat: SOA, a może jednak inaczej...

Jarosławie, czy nie jest to jakaś droga wyjścia z tego, co uważam za błąd w opisie procesów w konwencji BPML, polegający na pojmowaniu zdarzeń jako składnika procesów?

Przypomnę, że mój zarzut opieram na tym, iż proces to processing czyli przetwarzanie (materiału, dokumentu, "sprawy do załatwienia" i innego "tworzywa"). Natomiast zdarzenia niczego nie przetwarzają, nie dotyczą bezpośrednio tworzywa - zdarzenia należą nie do warstwy procesu, lecz do warstwy sterowania procesem.

Tak jak zdarzenie polegające na otrzymaniu karty kanban uruchamia proces przetwarzania materiału. Jak zdarzenie polegające na wejściu osoby obcej na teren chroniony "uruchamia" proces autentykacji tej osoby i dalsze czynności. Jak zdarzenie polegające na przekroczeniu zakresu dopuszczalnego przez wartość jakiegoś parametru uruchamia procedurę sterowania przywracającą stabilność przepływu czegoś tam. Itd.

To tyle na uzasadnienie mojego sprzeciwu wobec traktowaniu zdarzeń jako składnika procesów (proces to nie jest bieg zdarzeń, lecz operacji).

No i to co tu napisałeś i co mówi ów mówca (nie dosłuchałem do końca, za długie) wygląda mi na to, że zdarzenia wreszcie potraktowano jako warstwę sterowania. Czy tak właśnie postąpiłeś w projekcie procesów sterowanych zdarzeniami w portalu?

Temat: SOA, a może jednak inaczej...

Andrzej Góralczyk:
Jarosławie, czy nie jest to jakaś droga wyjścia z tego, co uważam za błąd w opisie procesów w konwencji BPML, polegający na pojmowaniu zdarzeń jako składnika procesów?

Hm... moim zdaniem to nie tyle błąd co pewien przyjęty formalizm. Modelowanie, jeśli traktujemy model jako jakiś kompletny system opisu, to proces formalny (w przeciwnym wypadku diagram jest tylko "jakimś" opisem).

Uznawanie zdarzeń za składnik procesu ma swoje źródło w uznaniu (definicja procesu: proces ma produkt), że praca z dokumentem może tworzyć decyzje - zmianę stanu dokumentu czyli jego status (z "napisany" na "zatwierdzony"). Zdarzenie w prostszych notacjach jest "zastępowane" np. "odnotowaniem" (być może w dzienniku korespondencji) nadejścia korespondencji.

W Notacji BPMN zdarzenie jako inny byt od procesu zostało wprowadzone z następującego powodu: (1) proces trwa w czasie, zdarzenie zaś nie trwa w czasie (to jest "moment" zaistnienia czego), (2) zdarzenia nie mają wykonawcy ale mogą być skutkiem procesu, jego produktem (a proces musi mieć wykonawcę). Typowym przykładem zdarzenia są: "stan zapasu spadł poniżej ..., lub "jak wybije godzina ... to...".

Owszem można nie używać pojęcia zdarzenie w modelach procesów, jednak wtedy wtedy pewne elementy semantyki będą albo niemożliwe do zamodelowania albo model będzie nieco "fałszywy" w rozumieniu nie będzie zawierał "znaczników czasu.

Przypomnę, że mój zarzut opieram na tym, iż proces to processing czyli przetwarzanie (materiału, dokumentu, "sprawy do załatwienia" i innego "tworzywa"). Natomiast zdarzenia niczego nie przetwarzają, nie dotyczą bezpośrednio tworzywa - zdarzenia należą nie do warstwy procesu, lecz do warstwy sterowania procesem.

To prawda, proces ze swej natury przetwarza, jednak model procesów poza nimi samymi zawiera (w zasadzie musi dla oddania rzeczywistości) kontekst, w szczególności dokumentu - na mapach procesów umieszczamy "to co przetwarzane i skutki tego przetwarzania". Tak więc dokument także nie jest procesem ale umieszczamy je na mapach procesów.

Są metody modelowania procesów polegające na umieszczaniu na diagramach wyłącznie "pracy" i w wielu przypadkach taki model wystarczy. Rzecz w tym, że implementacja przepływu pracy w jakimkolwiek systemie IT wymaga dwóch dodatkowych elementów": dane przetwarzane i tak zwane "wyzwalacze". Pierwsze to dokumenty drugie to właśnie zdarzenia. Faktycznie zdarzenia sterują procesem jednak np. notacja BPMN sama z siebie (bo "zdarzeń można nie używać na modelach) może (nie ma obowiązku) pokazać na jednym diagramie nie tylko sam proces ale także jego sterowanie oraz przepływ danych.

Syntaktyka (składnia) BPMN dopuszcza użycie wyłącznie czynności i procesów na diagramach, jednak często proces pozbawiony "sterowania i danych" traci kontekst.

To tyle na uzasadnienie mojego sprzeciwu wobec traktowaniu zdarzeń jako składnika procesów (proces to nie jest bieg zdarzeń, lecz operacji).

Wydaje mi się, że to wyłącznie kwestia tego jakiej definicji użyjemy jako kontekstu modelowania. Można użyć tej - chyba - najprostszej: proces to czynność lub logicznie powiązany ciąg czynności przetwarzający stan wejścia w stan wyjścia (w kategoriach biznesowych należy dodać: tworzący wartość dodaną).

W takim przypadku pozostaje uznać np. zdarzenie "stan gwoździ w magazynie spadł poniżej poziomu minimalnego" za stan wejściowy "procesu uzupełniania stanów magazynowych" kończącego się protokołem przyjęcia na magazyn tychże gwoździ. Owszem można przejść ze zdarzeń na dokumenty (zamówienie itp.) jednak coraz częściej pewnych "zdarzeń" nie formalizujemy dokumentem jednak obsługujemy je (zresztą fakty te i tak są zapisywane w systemach ;)).

Swego czasu stosowałem własną notację, która wymagała zawsze jakiegoś dokumentu na wejściu i wyjściu procesu jednak okazywało się często zbyt dużym uproszczeniem.

No i to co tu napisałeś i co mówi ów mówca (nie dosłuchałem do końca, za długie) wygląda mi na to, że zdarzenia wreszcie potraktowano jako warstwę sterowania. Czy tak właśnie postąpiłeś w projekcie procesów sterowanych zdarzeniami w portalu?

Generalnie jest to kwestia umowy. Owszem zdarzenie jest "sterowaniem" ale jest także elementem "całości" wiec jeżeli podejmiemy umowę, że model procesu zawiera poza procesami także elementy sterowania i przepływu danych to mamy model BPMN w "pełnej wersji", jeżeli z powodu braku takiej potrzeby pominiemy np. zdarzenia na modelu nie będzie to błąd, po protu nie będzie tam tej informacji - to decyzja, ilość informacji na modelu, analityka "modelarza".

Analizując firmę w kontekście specyfikowania potrzeb na jakiekolwiek oprogramowanie należy przekazać wykonawcy dwie kluczowe informacje: dane przetwarzane oraz zdarzenia jakie należy obsługiwać. Model procesów przenosi tu wyłącznie kontekst (proces nie jest programowany). Typowym przykładem jest portal: system w odpowiedzi na nasze zachowania (zdarzenia) wyświetla nam coś a ekranie (dane), my jakoś na nie reagujemy itp.

Co ciekawe, paradoksalnie, programistów nie interesuję żadne procesy (one są tak na prawdę bytem abstrakcyjnym) bo oni ich nie implementują :), programista potrzebuje tak zwane "przypadku użycia" a te właśnie są charakteryzowane przez stan początkowy, stan końcowy oraz dane jakie należy przetworzyć (i jak to należy zrobić). Jeżeli więc opracowujemy model procesów w kontekście analizy wymagań na jakiekolwiek oprogramowanie te informacje (zdarzenia i dane) muszą zostać "zidentyfikowane" i opisane.

Inny przykład to edytor tekstu: wymagania użytkownika odzwierciedla meny tego narzędzia, jednak edytor nie ma "wbudowanego" procesu pisania notatki służbowej czy opinii prawnej a mimo to jest do tych procesów wykorzystywany.

Chyba się rozpisałem. W każdym razie model procesu, bez kontekstu jego tworzenia, trudno ocenić choć na pewno wiadomo, że proces to "przetwarzanie-przekształcanie". Z tego właśnie powodu przestrzegam w swoich projektach zasady: model musi mieć zdefiniowany kontekst a do niego pragmatykę. Z niej może np. wynikać, że danym przypadku modelujemy scenariusz realizacji jakiejś pracy i na modelu nie umieszczamy ani zdarzeń ani nawet dokumentów (danych) ale za to dokładnie opisujemy czynności. I taki model spokojnie można utworzyć notacją BPMN ale już nie można notacją eEPC, bo ta nie dopuszcza konstrukcji pozbawionej zdarzeń :).Jarek Żeliński edytował(a) ten post dnia 05.09.10 o godzinie 09:59

Temat: SOA, a może jednak inaczej...

Jarek Żeliński:
Analizując firmę w kontekście specyfikowania potrzeb na jakiekolwiek oprogramowanie należy przekazać wykonawcy dwie kluczowe informacje: dane przetwarzane oraz zdarzenia jakie należy obsługiwać. Model procesów przenosi tu wyłącznie kontekst (proces nie jest programowany). Typowym przykładem jest portal: system w odpowiedzi na nasze zachowania (zdarzenia) wyświetla nam coś a ekranie (dane), my jakoś na nie reagujemy itp.

Co ciekawe, paradoksalnie, programistów nie interesuję żadne procesy (one są tak na prawdę bytem abstrakcyjnym) bo oni ich nie implementują :), programista potrzebuje tak zwane "przypadku użycia" a te właśnie są charakteryzowane przez stan początkowy, stan końcowy oraz dane jakie należy przetworzyć (i jak to należy zrobić). Jeżeli więc opracowujemy model procesów w kontekście analizy wymagań na jakiekolwiek oprogramowanie te informacje (zdarzenia i dane) muszą zostać "zidentyfikowane" i opisane.

Obawiam się Jarku, że pozwoliłeś sobie na zbytnie uproszczenie tego tematu. Nie mogę zgodzić się ze stwierdzeniem, że programistów nie interesują procesy i że ich nie implementują. Tak się często dzieje, gdy procesy wykonują ludzie, maszyny ale istnieją procesy realizowane przez system. Podam kilka przykładów.

"tworzenie zamówienia" - w systemie, który korzystając z metod numerycznych wylicza na podstawie danych historycznych o rotacji pozycji na magazynie sam dynamicznie ustala warunki brzegowe dla generowania zamówienia (stany minimalne i optymalne).

W systemach przetwarzania języka (mowy, pisma), zaawansowane algorytmy analizy leksemów jak najbardziej wykonują procesy, a więc programista jak najbardziej musi wiedzieć jak je wykonać - znać algorytm.

Tak jak piszesz dzieje się w systemach, które zarządzają danymi tworzonymi i edytowanymi przez użytkowników (ludzi, lub inne systemy np. czujniki). Czasem jednak systemy same tworzą dane i wtedy konieczna jest znajomość przebiegu procesu - zwykle opis algorytmu.

Temat: SOA, a może jednak inaczej...

Mateusz Kurleto:
Obawiam się Jarku, że pozwoliłeś sobie na zbytnie uproszczenie tego tematu. Nie mogę zgodzić się ze stwierdzeniem, że programistów nie interesują procesy i że ich nie implementują. Tak się często dzieje, gdy procesy wykonują ludzie, maszyny ale istnieją procesy realizowane przez system.

Masz rację, przyznaję się do uproszczenia.Miałem na myśli to, ze proces to także czynności poza systemowe np. w procesie odbioru korespondencji mamy np.: przyjęcie listonosza, sprawdzenie czy ma ważną legitymację, podpisanie w jego książce odebrania poczty, rozpakowanie każdego listu, skanowanie każdego pisma do systemu i opisanie go. z całego tego procesu w zasadzie interesuje się Use Case "wskanowanie i opisanie", co najwyżej dostęp do do opisu całego procesu da Ci kontekst tej pracy jeśli będzie Ci potrzebny,

Podam kilka przykładów.
"tworzenie zamówienia" - w systemie, który korzystając z metod numerycznych wylicza na podstawie danych historycznych o rotacji pozycji na magazynie sam dynamicznie ustala warunki brzegowe dla generowania zamówienia (stany minimalne i optymalne).

W systemach przetwarzania języka (mowy, pisma), zaawansowane algorytmy analizy leksemów jak najbardziej wykonują procesy, a więc programista jak najbardziej musi wiedzieć jak je wykonać - znać algorytm.

święte słowa, to są te elementy które opisuje "metodę" realizacji danego zadania. Tu celowo nie użyłem słowa "proces" zastępując go słowem "metoda" gdyż te elementy to (tu mnie ewentualnie popraw) "metody" klas dziedziny systemu, które jak najbardziej analityk projektant powinien albo zaprojektować albo powołać się na wzorce i lub opisane w literaturze "opracowane" algorytmy. Słowo "proces" zarezerwowałem dla bardziej abstrakcyjnego terminu jakim jest "proces biznesowy".

Tak jak piszesz dzieje się w systemach, które zarządzają danymi tworzonymi i edytowanymi przez użytkowników (ludzi, lub inne systemy np. czujniki). Czasem jednak systemy same tworzą dane i wtedy konieczna jest znajomość przebiegu procesu - zwykle opis algorytmu.

Dokładnie tak i tu przepraszam wszystkich za uproszczenie :).

Temat: SOA, a może jednak inaczej...

Jarek Żeliński:
święte słowa, to są te elementy które opisuje "metodę" realizacji danego zadania. Tu celowo nie użyłem słowa "proces" zastępując go słowem "metoda" gdyż te elementy to (tu mnie ewentualnie popraw) "metody" klas dziedziny systemu, które jak najbardziej analityk projektant powinien albo zaprojektować albo powołać się na wzorce i lub opisane w literaturze "opracowane" algorytmy. Słowo "proces" zarezerwowałem dla bardziej abstrakcyjnego terminu jakim jest "proces biznesowy".

Nie zawsze dzieje się to w obrębie pojedynczej metody. Modelujemy przecież zwykle oprogramowanie obiektowo, korzystamy ze wzorców architektury (MVC i inne "bajery"). Zwykle realizacja algorytmu korzysta z wielu metod wielu obiektów.
Nawet na poziomie biznesowym możemy sobie wyobrazić algorytm działający na dynamicznych danych, który do swojej pracy musi odpytać różne obiekty tej samej klasy. Np. algorytm obliczający czas przybycia autobusu na przystanek na podstawie aktualnej pozycji GPS i danych historycznych musi przecież odpytywać autobus.
Dlatego pozostałbym przy określeniu proces, bo ten może być zarówno trywialny, realizowany w obrębie jednej metody - jak nietrywialny - polegający na komunikacji między wieloma obiektami.

Temat: SOA, a może jednak inaczej...

Mateusz Kurleto:
Dlatego pozostałbym przy określeniu proces, bo ten może być zarówno trywialny, realizowany w obrębie jednej metody - jak nietrywialny - polegający na komunikacji między wieloma obiektami.

to prawda, algorytm złożony może złożeniem prostszych, ja w twoim przykładzie z autobusem użyłbym pojęcia "sekwencja" a nie proces (zresztą zgodnie z UML opisze to diagram sekwencji :)), bo ta opisuje jak komunikują się obiekty (jakie wzajemnie wywołują metody) by zrealizować zadanie: czas przybycia autobusu.

ważne jest by w jednej dokumentacji znaczenia pojęć nie nakładały się i dlatego każda szanująca się dokumentacja ma słownik pojęć na początku, czego niestety ;) nie mają wątki dyskusji :D

Temat: SOA, a może jednak inaczej...

Jarek Żeliński:

ważne jest by w jednej dokumentacji znaczenia pojęć nie nakładały się i dlatego każda szanująca się dokumentacja ma słownik pojęć na początku, czego niestety ;) nie mają wątki dyskusji :D

i tym sposobem uzgodniliśmy stanowisko; żałuję, że tak niewiele osób udziela się merytorycznie; to wielka szkoda, że z goldenline robi się powoli słup ogłoszeniowy szkoleń, konferencji i obchodzenia GLowych zakazów rekrutacji

Temat: SOA, a może jednak inaczej...

Mateusz Kurleto:

Jarek Żeliński:

ważne jest by w jednej dokumentacji znaczenia pojęć nie nakładały się i dlatego każda szanująca się dokumentacja ma słownik pojęć na początku, czego niestety ;) nie mają wątki dyskusji :D

i tym sposobem uzgodniliśmy stanowisko; żałuję, że tak niewiele osób udziela się merytorycznie; to wielka szkoda, że z goldenline robi się powoli słup ogłoszeniowy szkoleń, konferencji i obchodzenia GLowych zakazów rekrutacji

są dwie wersje przyczyn:
- kryją się
- nie potrafią

każdy sam sobie odpowie...

Temat: SOA, a może jednak inaczej...

Jarek Żeliński:

Mateusz Kurleto:

Jarek Żeliński:

ważne jest by w jednej dokumentacji znaczenia pojęć nie nakładały się i dlatego każda szanująca się dokumentacja ma słownik pojęć na początku, czego niestety ;) nie mają wątki dyskusji :D

i tym sposobem uzgodniliśmy stanowisko; żałuję, że tak niewiele osób udziela się merytorycznie; to wielka szkoda, że z goldenline robi się powoli słup ogłoszeniowy szkoleń, konferencji i obchodzenia GLowych zakazów rekrutacji

są dwie wersje przyczyn:
- kryją się
- nie potrafią

każdy sam sobie odpowie...

Albo nie mają czasu.

W moim przekonaniu najważniejszym zdaniem z całej dyskusji jest "zdarzenia wreszcie potraktowano jako warstwę sterowania" przytoczone przez p. Góralczyka.

Nie przepadam za oprogramowaniem (i programistami / developerami / analitykami) którzy upierają się przy SOA, głównie dlatego, że jeszcze nie widziałem systemu opartego na SOA, który charakteryzowałby się wysoka niezawodnością (z różnych przyczyn).

Temat: SOA, a może jednak inaczej...

Rafał Krawczyk:
W moim przekonaniu najważniejszym zdaniem z całej dyskusji jest "zdarzenia wreszcie potraktowano jako warstwę sterowania" przytoczone przez p. Góralczyka.

pojęcie warstwy także warto zdefiniować, bo czym jest zdarzenie "upłynęło 7 dni na zgłaszanie uwag" w środku procesu przekazywania produktów analiz klientom.

Nie przepadam za oprogramowaniem (i programistami / developerami / analitykami) którzy upierają się przy SOA, głównie dlatego, że jeszcze nie widziałem systemu opartego na SOA, który charakteryzowałby się wysoka niezawodnością (z różnych przyczyn).

SOA jak oprogramowanie czy SOA jako architektura systemu?

Temat: SOA, a może jednak inaczej...

Jarek Żeliński:

Rafał Krawczyk:
Nie przepadam za oprogramowaniem (i programistami / developerami / analitykami) którzy upierają się przy SOA, głównie dlatego, że jeszcze nie widziałem systemu opartego na SOA, który charakteryzowałby się wysoka niezawodnością (z różnych przyczyn).

SOA jak oprogramowanie czy SOA jako architektura systemu?

Jako oprogramowanie.
Może inaczej - te systemy, z którymi ja osobiście miałem styczność były zaprojektowane / zaprogramowane jak "tradycyjne" oprogramowanie bez uwzględnienia wszystkich (a nawet części!) wymagań i charakterystycznych dla SOA problemów, które mogłyby wystąpić - z tego powodu powstawały błędy i z tego też powodu nie jestem wielkim zwolennikiem SOA - zapewnienie poprawności działania oprogramowania w pełni implementującego SOA od strony programistycznej zwielokrotnia koszt powstawanie oprogramowania, nie mówiąc już o trudnościach w testowaniu tego typu oprogramowania.

Dlatego Pana propozycje o budowie pięciu oddzielnych dedykowanych rozwiązań były jak najbardziej uzasadnione, i zapewne same, bez większego trudu się obroniły.

Temat: SOA, a może jednak inaczej...

Rafał Krawczyk:

Jarek Żeliński:

Rafał Krawczyk:
Nie przepadam za oprogramowaniem (i programistami / developerami / analitykami) którzy upierają się przy SOA,

SOA jak oprogramowanie czy SOA jako architektura systemu?

Jako oprogramowanie.

no to jesteśmy zgodni...;)

Dlatego Pana propozycje o budowie pięciu oddzielnych dedykowanych rozwiązań były jak najbardziej uzasadnione, i zapewne same, bez większego trudu się obroniły.

bez oprogramowania SOA w nazwie a jedynie jako odpowiednia architektura... :)