Temat: SOA - EDA - CEP ???

Zaczęły się pojawiać kolejne ciekawostki uzupełniające dotychczasowe "trendy" w architekturze systemów informatycznych. Są to między innymi:
CEP – Complex Event processing
EDA – Event Driven Architecture
SOA – Service Oriented Architecture

Wypisano je od najmłodszego terminu. Oogólnie idea SOA na bazie tak zwanych webserwisów i usług wyszukiwawczych (ESB, UDDI itp.) ulega dewaluacji, technologia ta jest kosztowna i trudna do oceny rentowności i nie znalazła na rynku masowego odzewu. Z SOA pozostaje tylko wzorzec projektowy.

Jakie są Wasze opinie na temat "dalszej drogi"? Wzorce projektowe czy technologia?

Temat: SOA - EDA - CEP ???

Dla mnie SOA to w zasadzie filozofia tworzenia architektury, a więc można powiedzieć że wzorzec. Nie znalazła masowego odzewu na rynku, ponieważ za krótko na nim istnieje. Zmiana architektury w istniejących już systemach, czy tworzenie ich od podstaw to lata. Niestety w tak szybko zmieniającym się świecie technologii lata to wieczność więc nim SOA na dobre się urodziła technologicznie, już ją pochowano. Myślę, że błąd polegał przede wszystkim na tym, że próbowano z SOA od razu zrobić technologie - tak powstało Service Oriented Application. Wielu utożsamia jedno z drugim.
Wydaje mi się, że obecnie technologicznie jesteśmy przygotowani na wszystko co się nowego w filozofii architektury pojawi. CEP, EDA tak samo jak SOA jesteśmy w stanie zrealizować w każdej chwili tym co mamy. Pod warunkiem, że ktoś znów nie połączy na siłę aplikacji sterowanej zdarzeniami z architekturą sterowaną zdarzeniami.

Chciałbym, żeby rozwijały się wzorce swoją drogą a technologia swoją.

Temat: SOA - EDA - CEP ???

Edward Weinert:
Chciałbym, żeby rozwijały się wzorce swoją drogą a technologia swoją.

:), z ust mi to wyjąłeś... moim zdaniem chyba najwięcej napsuły duże firmy (np. IBM i nie tylko) oferując swoje "SOA, ESB, UDDI" itp. za ciężkie miliony... w efekcie powstał na rynku wizerunek SOA=majątek czyż nie?

Temat: SOA - EDA - CEP ???

Moim zdaniem kierunek wyznaczą korporacje typu Oracle, IBM.
Cel właściwie mają jeden: nazwać produkt niejednoznacznie, aby uzyskać możliwość "upchania" jak największej ilości swoich usług do środka - EaaS (Everything As A Service), i na jak najdłużej związać klienta ze swoją technologią ...

Inaczej brzmi wdrożenie SOA w zakresie ..., a inaczej uwspólnienie systemu poczty elektronicznej w ramach (kilkuset-oddziałowej) korporacji, jest więc też dobrze brzmiące uzasadnienie kikudziesięciu milionów na realizację projektu.

Ot i cała filozofia ;)
A

Temat: SOA - EDA - CEP ???

Jeśli chodzi o trendy to polecam ostatni raport Gartnera dotyczący nowych technologii ;)
http://www.cmswire.com/cms/enterprise-20/get-in-on-the...

Sądzę, że SOA ma najlepsze lata jeszcze przed sobą, zarówno w sferze dojrzałości jako wzorca jak i wspierających ją technologii. W oparciu o doświadczenia z ubiegłych lat wiadomo już co robić a czego unikać aby wdrożenie SOA zakończyło się sukcesem. Czysto technologiczne podejście do tematu zawsze kończy się porażką, ale przecież nie ma w tym nic dziwnego, że najważniejszy jest biznes a nie IT ;)
SOA dotyczy systemu systemów i próba jej zastosowania w ramach jednej aplikacji/systemu jest pomyłką (tutaj bardziej pasuje SCA, OSGi itp). Oczywiście aplikacja może udostępniać usługi innym aplikacjom i vice versa, ale jeśli chodzi o komunikację między poszczególnymi modułami to już dawno wymyślona wydajniejsze metody niż webserwisy.
Jeśli chodzi o EDA i CEP, to są one ortogonalne do SOA i mogą być stosowane razem.

Temat: SOA - EDA - CEP ???

między poszczególnymi modułami to już dawno wymyślona wydajniejsze metody niż webserwisy.

mam wrażenie że największym złem i błędem jest forsowanie tezy:
SOA = webserwisy

jeżeli postawię na nogi np. portal CMS i mały workflow, który będzie integrował różne aplikacje komunikując się (wymieniając lub udostępniając dane) z nimi poprzez RCP, ODBC itp. to także będzie SOA ....

Temat: SOA - EDA - CEP ???

Na marginesie jeśli chodzi o śmierć SOA - przed chwilą przeczytałem:
http://weblog.infoworld.com/realworldsoa/archives/2008...

Jarek Żeliński:

między poszczególnymi modułami to już dawno wymyślona wydajniejsze metody niż webserwisy.

mam wrażenie że największym złem i błędem jest forsowanie tezy:
SOA = webserwisy

Jeśli wszędzie będziemy mieli webserwisy to niekoniecznie oznacza, że jest to SOA. Trudno mi jednak sobie wyobrazić SOA bez (web)serwisów.
Inaczej mówiąc, webserwisy to technologia umożliwiająca realizację SOA:
1. Potrzebny jest spójny sposób opisu serwisów, mamy do tego WSDL -po co tworzyć coś nowego ?
2. Potrzebny jest protokół do wywoływania usług. Standardy to opisują (nie musi to być koniecznie HTTP)
3. Serwisy muszą działać w środowiskach heterogenicznych.

Oczywiście gdy pracujemy w ramach jednej platformy (dostawcy), nie planujemy zmian, integracji z innymi platformami, to powyższe argumenty tracą na znaczeniu. Niestety życie nie jest takie proste.

jeżeli postawię na nogi np. portal CMS i mały workflow, który będzie integrował różne aplikacje komunikując się (wymieniając lub udostępniając dane) z nimi poprzez RCP, ODBC itp. to także będzie SOA ....

Dlaczego SOA a nie po prostu aplikacja zintegrowana z innymi ? W opisanym przez Ciebie przypadku mamy do czynienia z ściśle z sobą powiązanymi aplikacjami, a w SOA zaleca się aby te więzy były bardziej luźne. Gdyby np. tam gdzie używasz ODBC były webserwisy jako fasada to wówczas łatwiej byłoby wymienić docelową aplikację na inną.

Temat: SOA - EDA - CEP ???

Jan B.:
Trudno mi jednak sobie wyobrazić SOA bez (web)serwisów.

A mi łatwo, przypadek opisany powyzej (RCP, ODPB itp...) dlaczego nie? Mamy architekturę zorientowana na usługi...

Inaczej mówiąc, webserwisy to technologia umożliwiająca realizację SOA:
1. Potrzebny jest spójny sposób opisu serwisów, mamy do tego WSDL -po co tworzyć coś nowego ?

Nic nei tworzymi, RCP czy SOAP, COM+ ... są już od dawna

2. Potrzebny jest protokół do wywoływania usług. Standardy to opisują (nie musi to być koniecznie HTTP)

Jest tego co nie miara..

3. Serwisy muszą działać w środowiskach heterogenicznych.

Od lat to robią...

jeżeli postawię na nogi np. portal CMS i mały workflow, który będzie integrował różne aplikacje komunikując się (wymieniając lub udostępniając dane) z nimi poprzez RCP, ODBC itp. to także będzie SOA ....

Dlaczego SOA a nie po prostu aplikacja zintegrowana z innymi ?

A czym innym jest SOA???

Mamy dedykowane usługowe serwisy (aplikacje) więc??

W opisanym przez Ciebie przypadku mamy do czynienia z ściśle z sobą powiązanymi aplikacjami, a w SOA zaleca się aby te więzy były bardziej luźne.
Gdyby np. tam gdzie używasz ODBC były webserwisy jako fasada to wówczas łatwiej byłoby wymienić docelową aplikację na inną.

Ja dodamy każdej aplikacje interfejs to mamy SOA, to już się dzieje... wymiana oprogramowania do fakturowania zajmie godzinę bez potrzeby tykania pozostałych

Temat: SOA - EDA - CEP ???

Jarek Żeliński:

Jan B.:
Inaczej mówiąc, webserwisy to technologia umożliwiająca realizację SOA:
1. Potrzebny jest spójny sposób opisu serwisów, mamy do tego WSDL -po co tworzyć coś nowego ?

Nic nei tworzymi, RCP czy SOAP, COM+ ... są już od dawna

A jak opisać zarówno SOAP jak i COM+ ? Jaką wartość mają usługi wystawione przez COM+ jeśli chcemy je wywoływać np. z UNIX'a ? W przypadku webserwisów interfejs mogę zaimplementować w dowolnej technologi.

jeżeli postawię na nogi np. portal CMS i mały workflow, który będzie integrował różne aplikacje komunikując się (wymieniając lub udostępniając dane) z nimi poprzez RCP, ODBC itp. to także będzie SOA ....

Dlaczego SOA a nie po prostu aplikacja zintegrowana z innymi ?

A czym innym jest SOA???

Mamy dedykowane usługowe serwisy (aplikacje) więc??

Jeśli mamy aplikacje zintegrowanymi z innymi w stylu Point-To-Point - to nie jest to SOA.

W opisanym przez Ciebie przypadku mamy do czynienia z ściśle z sobą powiązanymi aplikacjami, a w SOA zaleca się aby te więzy były bardziej luźne.
Gdyby np. tam gdzie używasz ODBC były webserwisy jako fasada to wówczas łatwiej byłoby wymienić docelową aplikację na inną.

Ja dodamy każdej aplikacje interfejs to mamy SOA, to już się dzieje... wymiana oprogramowania do fakturowania zajmie godzinę bez potrzeby tykania pozostałych

Dodanie każdej aplikacji interfejsu nie koniecznie może oznaczać, że będzie to SOA. Każdy serwis musi być tworzony w kontekście aplikacji, które będą z niego korzystać. Może okazać się, że każda aplikacja ma jakiś interfejs, z którego prawie nikt nie korzysta.
Z drugiej strony jeśli wiemy, że np. dwie aplikacje muszą być z sobą zintegrowane, ale żaden inny system nie będzie korzystać z tych usług to możemy zrobić integracje tak jak nam jest najwygodniej np. przez ODBC czy COM+.
W pewnej firmie była działająca integracja między paroma systemami. Niezbyt skomplikowana, jeden główny system, który wymieniał informacje z innymi. Postanowiono wdrożyć tam SOA i zamieniono to co już działało na webserwisy, wprowadzono parę dodatkowych warstw itp itd, ale każdego serwisu używała tylko jedna aplikacja. Dla mnie to przerost formy nad treścią, a dla innych modelowe wdrożenie SOA ....

Temat: SOA - EDA - CEP ???

Jan B.:

Nic nei tworzymi, RCP czy SOAP, COM+ ... są już od dawna

A jak opisać zarówno SOAP jak i COM+ ? Jaką wartość mają usługi wystawione przez COM+ jeśli chcemy je wywoływać np. z UNIX'a ? W przypadku webserwisów interfejs mogę zaimplementować w dowolnej technologi.

Jeżeli spojrzymy na SOA jak na wzorzec, to implementacja ma znaczenie drugorzędne... ważny chyba by aplikacja usługowa miała jakikolwiek interfejs

Dlaczego SOA a nie po prostu aplikacja zintegrowana z innymi ?

A czym innym jest SOA???

Mamy dedykowane usługowe serwisy (aplikacje) więc??

Jeśli mamy aplikacje zintegrowanymi z innymi w stylu Point-To-Point - to nie jest to SOA.

Jak to nie: wybieramy jedną aplikacją jako fasadę (np. system BPM co często ma miejsce) i udostępniamy jej inne aplikacje jako usługi, dostęp do tych usług zależy tylko od tego jaki dana aplaikcja udostęnia interfejs, wazne by system BPM był elastyczny,

... przecież SOA to nic innego jak architektura gwiazdy gdzie centralnym elementem jest fasada (aplikacja pełniąca role fasady).. jak już wspominałem nie prawdę jest, że SOA=webserwisy...

Ja dodamy każdej aplikacje interfejs to mamy SOA, to już się dzieje... wymiana oprogramowania do fakturowania zajmie godzinę bez potrzeby tykania pozostałych

Dodanie każdej aplikacji interfejsu nie koniecznie może oznaczać, że będzie to SOA. Każdy serwis musi być tworzony w kontekście aplikacji, które będą z niego korzystać.

Nic innego nie napisałem ... patrz poprzednie uwagi...

Z drugiej strony jeśli wiemy, że np. dwie aplikacje muszą być z sobą zintegrowane, ale żaden inny system nie będzie korzystać z tych usług to możemy zrobić integracje tak jak nam jest najwygodniej np. przez ODBC czy COM+.

Ale właśnie o tym pisałem: cechą SOA nie jest integracja wszystkiego ze wszystkim a wybranie jednego oprogramowania (lub stworzenie go) do pełnienia roli fasady i tylko to oprogramowanie kontaktuje się z podległymi programami usługowymi...

W pewnej firmie była działająca integracja między paroma systemami. Niezbyt skomplikowana, jeden główny system, który wymieniał informacje z innymi. Postanowiono wdrożyć tam SOA i zamieniono to co już działało na webserwisy, wprowadzono parę dodatkowych warstw itp itd, ale każdego serwisu używała tylko jedna aplikacja. Dla mnie to przerost formy nad treścią, a dla innych modelowe wdrożenie SOA ....

Dla mnie także jest to przerost.. i to duuuuuuuuży :)

Temat: SOA - EDA - CEP ???

Jarek Żeliński:
Jak to nie: wybieramy jedną aplikacją jako fasadę (np. system BPM co często ma miejsce) i udostępniamy jej inne aplikacje jako usługi, dostęp do tych usług zależy tylko od tego jaki dana aplaikcja udostęnia interfejs, wazne by system BPM był elastyczny,

... przecież SOA to nic innego jak architektura gwiazdy gdzie centralnym elementem jest fasada (aplikacja pełniąca role fasady).. jak już wspominałem nie prawdę jest, że SOA=webserwisy...

W referencyjnej architekturze SOA wg IBM taką fasadą jest ESB (Enterprise Service Bus), a BPM jest jednym z systemów korzystających z tej fasady w celu dostępu do innych aplikacji.
Aby łatwo można było skorzystać z ESB usługi mają domyślnie interfejs w postaci webserwisów - oczywiście od tego są możliwe wyjątki gdy jakaś aplikacja nie jest w stanie skorzystać z tego interfejsu.
Rozwiązaniem, które może nas pogodzić w tym rozumowaniu może być WebSphere Process Server (przykład, który znam). WPS to typowy system BPM. Zawiera on w sobie WebSphere ESB, a całość jest spięta z użyciem SCA (Service Component Architecture).
- dla każdej aplikacji(serwisu) tworzymy odpowiednie komponenty SCA (nazwijmy je adapterami i mogą one komunikować się z aplikacją w dowolny sposób)
- komponent możemy potem wykorzystać w procesie biznesowym albo udostępnić innym aplikacjom.

Jeśli tylko procesy będą używać adapterów - to będziemy mieli do czynienia z sytuacją opisaną przez Ciebie (i tutaj rzeczywiście może nie być webserwisów). Jeśli pozwolimy innym aplikacjom na korzystanie z komponentów (adapterów czy też procesów, które w SCA też są komponentami) , zbliżamy się do takiej implementacji SOA, w której webserwisy są już w mniejszym lub większym stopniu potrzebne.

Temat: SOA - EDA - CEP ???

Jan B.:

Jarek Żeliński:
Jak to nie: wybieramy jedną aplikacją jako fasadę (np. system BPM co często ma miejsce) i udostępniamy jej inne aplikacje jako usługi, dostęp do tych usług zależy tylko od tego jaki dana aplaikcja udostęnia interfejs, wazne by system BPM był elastyczny,

... przecież SOA to nic innego jak architektura gwiazdy gdzie centralnym elementem jest fasada (aplikacja pełniąca role fasady).. jak już wspominałem nie prawdę jest, że SOA=webserwisy...

W referencyjnej architekturze SOA wg IBM taką fasadą jest ESB (Enterprise Service Bus), a BPM jest jednym z systemów korzystających z tej fasady w celu dostępu do innych aplikacji.

No i tu (chyba) dotykamy tego, że dla mnie SOA to wzorzec, a dla IBM to już elementy oferowanej technologii (czyli konkretna implementacja).

Aby łatwo można było skorzystać z ESB usługi mają domyślnie interfejs w postaci webserwisów - oczywiście od tego są możliwe wyjątki gdy jakaś aplikacja nie jest w stanie skorzystać z tego interfejsu.

Czyli implementacja.

Rozwiązaniem, które może nas pogodzić w tym rozumowaniu może być WebSphere Process Server (przykład, który znam). WPS to typowy system BPM. Zawiera on w sobie WebSphere ESB, a całość jest spięta z użyciem SCA (Service Component Architecture).

Ale zamiast WebSphere ESB można użyć także IBM produkt (kupiony niedawno) FileNet czyli systemy typu BPM mogący bez żadnego WebSphere stanowić taka fasadę.

- dla każdej aplikacji(serwisu) tworzymy odpowiednie komponenty SCA (nazwijmy je adapterami i mogą one komunikować się z aplikacją w dowolny sposób)
- komponent możemy potem wykorzystać w procesie biznesowym albo udostępnić innym aplikacjom.

I powyższe staje się zbędne...

Jeśli tylko procesy będą używać adapterów - to będziemy mieli do czynienia z sytuacją opisaną przez Ciebie (i tutaj rzeczywiście może nie być webserwisów). Jeśli pozwolimy innym aplikacjom na korzystanie z komponentów (adapterów czy też procesów, które w SCA też są komponentami) , zbliżamy się do takiej implementacji SOA, w której webserwisy są już w mniejszym lub większym stopniu potrzebne.

Owszem, jeśli wykluczymy połączenia inne niż SpecjalizowanyProram-Fasada to webserwisy nie są niezbedne.

:)

Temat: SOA - EDA - CEP ???

W moim rozwiązaniu otwieram strony aplikacji webowej z konkretną funkcjonalnością i też traktuje to jako udostępnione usługi, więc SOA != webservice'y. :)
Zresztą każda funkcjonalność może być usługą: od wydruku na drukarce po czynności wykonywane przez ludzi - wszystko można wystawić jako usługę i narzucić kontrakt. Z informatycznego punktu widzenia kolejki MQSeries czy MSMQ są tak samo dobre jak webservice'y. :) Bazę danych SQL też można potraktować jak usługę. :)

Więc dołączam do głosów dla których SOA to filozofia/wzorzec, nie rozwiązanie stricte informatyczne.

pozdr. ediEdward Weinert edytował(a) ten post dnia 25.11.08 o godzinie 19:43

Temat: SOA - EDA - CEP ???

widzę, że znowu rozgorzała ciekawa dyskusja :) zawsze jednak w takiego rodzaju wątkach interesujące są wypowiedzi przedstawicieli firm/dostawców oferujących rozwiązania w danej kategorii...
nie dziwi mnie zatem subkietywne malowanie rzeczywistości czy "podpinanie" się pod bardziej marketingowe, nowsze i bardziej "trendy" terminy czy filozofie.
ktoś zadał pytanie jaki jest najlepszy system do branży budowlanej (bodajże na forum GL) :) a tu zaraz posiało się wypowiedziami handlowców z wielu różnych firm o wyższości systemu N nad systemem Z. no cóż, biznes to biznes :)

co do głównego tematu wątku - SOA i coraz to nowszych nazw, terminów etc... bez dwóch zdań, patrzenie na SOA przez pryzmat jednej technologii, aplikacji jest błędem absolutnym. padły już stwierdzenia w tym wątku czym jest SOA (wzorzec, filozofia, koncepcja etc.) i nie ma sensu tego rozwijać. jest to oczywiste.

WebSphere, BizTalk czy oferta TIBCO to nic innego jak technologie, platformy komunikacyjne oferujące szereg możliwości ułatwiających implementację SOA. Produkty te różnią się ceną, ilością i jakością adapterów, interfejsów, supportem protokołów, kanałów komunikacyjnych, wsparciem dla WS* etc. Mogą zostać nazwane jako "fasada" (:P), core, czy Service Bus ale nie zmienia to ich roli w architekturze. są jednym z wielu komponentów, które można zastąpić innym. są częścią składową kompletnej architektury - którą można zbudować np. zgodnie z zasadami SOA :). Jeśli ktoś nie widzi tutaj różnicy - polemizować nie warto. Jest to różnica mniej więcej tego samego kalibru co różnica pomiędzy paradygmatami programowania obiektowego a językiem programowania obiektowego... (koncepcja jest tylko jedna - a każdy z języków może posiadać innę semantykę, syntaktykę..).

Point-To-Point to podejści do integracji aplikacji i jak najbardziej można to zrobić zgodnie z filozofią SOA :). Udostępniane usługi czy ich konsumpcja to nie wyłączność "middleware'ów". Nie jest to idealne podejście ale racjonalne i słuszne dla niektórych (mniejszych) organizacji...

pozdrawiam!
RF

Temat: SOA - EDA - CEP ???

Jarek Żeliński:
Zaczęły się pojawiać kolejne ciekawostki uzupełniające dotychczasowe "trendy" w architekturze systemów informatycznych. Są to między innymi:
CEP – Complex Event processing
EDA – Event Driven Architecture
SOA – Service Oriented Architecture

panie Jarosławie, dorzuciłbym jeszcze do tego jeden 3 literowy skrót :), bardzo istotny z punktu widzenia architektury opartej na usługach.

SOP - Service Oriented Process - takie zamodelowanie procesów, gdzie łatwo można "czytać" jaki jest stan i jakie zapotrzebowanie na usługi w systemie;

co do Pana pytania, meritum - wzorzec vs technologia.

wg mnie nie powinno się burzyć następującej sekwencji:

1. Analiza biznesowa + Inwentaryzacja IT
2. Wzorzec + Architektura
3. Technologia (będąca świadomym wyborem i wynikiem p. 1 i 2)

Nie rozdzielałbym tak bardzo technologii od wzorców i standardów gdyż są one ścisle ze sobą powiązane. Decyzją producenta jest jakie zdolności adaptacyjne posiadać będzie nowy produkt - i zazwyczaj oparte to jest na znanych (lub "trendy" lub marketingowych) wzorcach :) i jest ich dobrem komplementarnym lub conajmniej ułatwiającym wdrożenie w życie :)

pozdrawiam
RFRoman Frania edytował(a) ten post dnia 27.11.08 o godzinie 13:16

Temat: SOA - EDA - CEP ???

dorzuciłbym jeszcze do tego jeden 3 literowy skrót :), bardzo istotny z punktu widzenia architektury opartej na usługach.

SOP - Service Oriented Process - takie zamodelowanie procesów, gdzie łatwo można "czytać" jaki jest stan i jakie zapotrzebowanie na usługi w systemie;

Tu troszkę się zakręciłem ;) ... w pewnym sensie proces i usługa to to samo bo np. proces naliczania VAT jest realizowany przez jakiś byt realizujący usługę naliczania VAT)???

Temat: SOA - EDA - CEP ???

Jarek Żeliński:

W referencyjnej architekturze SOA wg IBM taką fasadą jest ESB (Enterprise Service Bus), a BPM jest jednym z systemów korzystających z tej fasady w celu dostępu do innych aplikacji.

No i tu (chyba) dotykamy tego, że dla mnie SOA to wzorzec, a dla IBM to już elementy oferowanej technologii (czyli konkretna implementacja).

Parę słów wyjaśnienia.
IBM kładzie nacisk na to, że SOA to nie tylko technologia:
[link]http://download.boulder.ibm.com/ibmdl/pub/software/dw/...[/link] (punkt 1.2)
Jeśli chodzi o referencyjną architekturę SOA - to jest to koncepcja na mniejszym poziomie abstrakcji niż SOA, ale wciąż jest neutralna technologicznie.
Podobnie z terminem ESB, który również jest koncepcją ale może być zrealizowany z użyciem WebSphere ESB (produktu) lub też jakiegokolwiek innego o podobnej funkcjonalności (np. Apache ServiceMix, żeby nikt mnie nie posądził o reklamowanie innych firm ;) ).

Jeśli chodzi o SOP - to pierwsze słyszę, Każdy proces (usługę) można monitorować (czy o to chodzi w określeniu '"czytać" jaki jest stan' ?) i nie za bardzo rozumiem w jaki sposób modelowanie mogłoby to ułatwić.

Temat: SOA - EDA - CEP ???

Jeśli chodzi o SOP - to pierwsze słyszę, Każdy proces (usługę) można monitorować (czy o to chodzi w określeniu '"czytać" jaki jest stan' ?) i nie za bardzo rozumiem w jaki sposób modelowanie mogłoby to ułatwić.

kilka słów wyjaśnienia - SOP - to nie monitorowanie ani nie czytanie stanu procesu czy usługi. "Proces zorientowany na serwisy" - bo tak w bezpośrednim tłumaczeniu to miałoby brzmieć - to proces "rozłożony" na aktywności (czynności). to zbiór zadań, powiązanych ze sobą ale do wykonania których wymagane jest wykorzystanie tego, co udostępniają usługi... różne usługi... mowa o podejściu do analizy i projektowania, które ma wskazać z jakich warstw systemu (lub komponentów) powinniśmy czy możemy skorzystać w celu poprawnego wykonania się i zakończenia procesu... sprawę ułatwią dobrej jakości diagramy sekwencji i aktywności ;)

jest to podejście do analizy i projektowania, którę są kluczem do dokonania właściwych wyborów, co do wzorców czy technologii.

pozdrawiam,
RF

Temat: SOA - EDA - CEP ???

Roman Frania:
kilka słów wyjaśnienia - SOP - to nie monitorowanie ani nie czytanie stanu procesu czy usługi. "Proces zorientowany na serwisy" - bo tak w bezpośrednim tłumaczeniu to miałoby brzmieć - to proces "rozłożony" na aktywności (czynności). to zbiór zadań, powiązanych ze sobą ale do wykonania których wymagane jest wykorzystanie tego, co udostępniają usługi... różne usługi... mowa o podejściu do analizy i projektowania, które ma wskazać z jakich warstw systemu (lub komponentów) powinniśmy czy możemy skorzystać w celu poprawnego wykonania się i zakończenia procesu... sprawę ułatwią dobrej jakości diagramy sekwencji i aktywności ;)

jest to podejście do analizy i projektowania, którę są kluczem do dokonania właściwych wyborów, co do wzorców czy technologii.

Jako "modelarz" (nie tylko procesów) powiem tak: mając model procesów kolejny stopień dekompozycji to rozpisanie procesu na łańcuchy czynności (scenariusz realizacji procesu, procedura albo inna nazwa jak kto lubi). Mogą to być czynności dające się lub nie automatyzować.

Ten poziom modelowania nie ma jeszcze nic wspólnego z oprogramowaniem, bo to nadal tylko model rzeczywistości danej organizacji.

Jak dojdziemy do etapu opisu planowanego do wykonania oprogramowania to na podstawie modelu procesów biznesowych i produktów tych procesów (np. dokumenty, dane itp.) tworzony jest model dziedziny systemu a po określeniu zakresu projektu specyfikowane są przypadki użycia.

Jak już mam model dziedziny (diagram klas) to:
- projektuję podział na komponenty i wydzielam interfejsy (tu stosuję wzorzec MVC)
- diagramy czynności opisują algorytmy metod klas
- diagramy sekwencji opisują:
-- komunikacje pomiędzy komponentami
-- komunikacje pomiędzy klasami wewnątrz podsystemów realizujących interfejsy

Teraz zapadają decyzje co potraktować jako pojedynczą aplikacje realizującą usługi biznesowe (SOA).

Dlatego mam wrażenie, że opisany tu SOP to jakaś nowa nazwa do tego co już od dawna jest ...Jarek Żeliński edytował(a) ten post dnia 28.11.08 o godzinie 08:37

Temat: SOA - EDA - CEP ???

fakt, troszkę poszedłem na skróty :) ale w 99% się zgadzam :) życzyłbym sobie aby to było tak oczywiste dla wszystkich;

pozdr.
RF