Temat: Co po SOA nastąpi?

Tu pewne ciekawe dywagacje, będzie poważne Enterprice Architecture...

http://www.infoq.com/news/2010/10/WhatsNextSOA

Temat: Co po SOA nastąpi?

Jarek Żeliński:
Tu pewne ciekawe dywagacje, będzie poważne Enterprice Architecture...

http://www.infoq.com/news/2010/10/WhatsNextSOA

Powodem powstania SOA była między innymi lepsza integracja aplikacji.

Wystarczy więc, że zmieni się model integracji, czyli zniknie stary problem i pojawi się nowy (ten sam, ale w innym miejscu). Na przykład SaaS i chmury integruje się inaczej.

Edit: dużą zmianą byłoby już wywalenie jednej wspólnej szyny, niech każda domena sama zarządza swoimi usługami.Przemek Wiśniewski edytował(a) ten post dnia 14.10.10 o godzinie 23:01

Temat: Co po SOA nastąpi?

Przemek Wiśniewski:
Edit: dużą zmianą byłoby już wywalenie jednej wspólnej szyny, niech każda domena sama zarządza swoimi usługami.

nie ukrywam, że moje myślenie i "przewidywania" także idą dokładnie w tym kierunku :), jedynie mam dylemat gdy firma ma dziesiątki (a nie kilka) aplikacji (np. banki nie tylko) - i albo jest to błąd planowania rozwoju systemu IT albo jednak potrzebna jest aplikacja, której domeną jest "wiedzieć gdzie się co dzieje"....

Temat: Co po SOA nastąpi?

Jarek Żeliński:

Przemek Wiśniewski:
Edit: dużą zmianą byłoby już wywalenie jednej wspólnej szyny, niech każda domena sama zarządza swoimi usługami.

nie ukrywam, że moje myślenie i "przewidywania" także idą dokładnie w tym kierunku :), jedynie mam dylemat gdy firma ma dziesiątki (a nie kilka) aplikacji (np. banki nie tylko) - i albo jest to błąd planowania rozwoju systemu IT albo jednak potrzebna jest aplikacja, której domeną jest "wiedzieć gdzie się co dzieje"....

Nie do końca zrozumiałem powyższego, ale naszło mnie co innego.

Jak wchodziło SOA to firma X SA miała kilkanaście luźnych aplikacji. Niektóre stare, inne nowe. Niektóre funkcje były wspólne, inne unikalne dla danej aplikacji. Niektóre ważne, inne nie. I tak dalej, jakiś tam mały bałagan.

Problemem była komunikacja między tymi aplikacjami - zastąpić interfejs białkowy interfejsem sieciowym. Czyli zintegrować to co jest zamiast kupować kolejny jeszcze większy silos.

Jak weszło SOA to się okazało, że:

1. Wydajność i stabilność usług na szynie jest problemem

2. Jak szyna jest jedna i powszechna to usługa też będzie jedna i powszechna - trzeba ją specjalnie zaprojektować, żeby była odpowiednio ogólna

3. Nie wszystkie informacje biznesowe mają postać silnie typowanych struktur danych, czasami są to strumienie bajtów lub nawet nieokreślone pliki

4. Szyna sama w sobie mimo, że nie dostarcza żadnej funkcji biznesowej, jest drogim w utrzymaniu systemem, który się rozwija i pielęgnuje podobnie jak inne aplikacje

5. Vendor lock-in - szyna jest w zasadzie niewymienialna mimo istnienia otwartych standardów

Temat: Co po SOA nastąpi?

Przemek Wiśniewski:

nie ukrywam, że moje myślenie i "przewidywania" także idą dokładnie w tym kierunku :), jedynie mam dylemat gdy firma ma dziesiątki (a nie kilka) aplikacji (np. banki nie tylko) - i albo jest to błąd planowania rozwoju systemu IT albo jednak potrzebna jest aplikacja, której domeną jest "wiedzieć gdzie się co dzieje"....

Nie do końca zrozumiałem powyższego, ale naszło mnie co innego.

mam na myśli "stary dobry middleware" :)

Jak weszło SOA to się okazało, że:

1. Wydajność i stabilność usług na szynie jest problemem

problem niestety znany, potwierdzam

2. Jak szyna jest jedna i powszechna to usługa też będzie jedna i powszechna - trzeba ją specjalnie zaprojektować, żeby była odpowiednio ogólna

kanoniczny model danych musi być, niestety albo stety

3. Nie wszystkie informacje biznesowe mają postać silnie typowanych struktur danych, czasami są to strumienie bajtów lub nawet nieokreślone pliki

bo w tego typu projektach moim zdaniem, struktury danych (relacyjne) się raczej nie sprawdzają... lepsze są obiektowe modele z redundancją, nie istnieją "nieokreślone pliki", wszystko jest jakimś obiektem - w skrajnym przypadku "jakiś innym plikiem" z nazwą i metadanymi.

4. Szyna sama w sobie mimo, że nie dostarcza żadnej funkcji biznesowej, jest drogim w utrzymaniu systemem, który się rozwija i pielęgnuje podobnie jak inne aplikacje

jak to szyna nie dostarcza funkcji biznesowej :), ilu ludzi (jak sam wskazałeś: interfejs białkowy) zastępuje a człowiek to biznes :)

5. Vendor lock-in - szyna jest w zasadzie niewymienialna mimo istnienia otwartych standardów

i tu masz 100% racji....

Jak dla mnie lepsza drogą jest sprowadzenie liczby aplikacji do kilku, maks kilkunastu i integracji jak w przypadków typowych komponentów z interfejsami. Unikamy zbędnego bytu po środku, zmuszamy się do zastanowienia czy zanim napiszemy kolejną "fajną apliakcyjkę" nie warto nowej funkcjonalności "umieścić" w jakimś istniejącym już podsystemie. Czy to jest zawsze możliwe, kto to wie...:) ale nie raz jak widzę gdzieś dziesiątki programików to okazuje się, że spokojnie mogły by być pogrupowane dziedzinowo w kilka "grubszych" podsystemach.

Temat: Co po SOA nastąpi?

Jarek Żeliński:

Przemek Wiśniewski:

>

2. Jak szyna jest jedna i powszechna to usługa też będzie jedna i powszechna - trzeba ją specjalnie zaprojektować, żeby była odpowiednio ogólna

kanoniczny model danych musi być, niestety albo stety

Dobrze byłoby mieć tutaj pewną dowolność i elastyczność, czyli móc zrobić coś szybko, bez konieczności opracowywania zmiany modelu kanonicznego.

Edit: definicja interfejsu to jedno, ale jest też przecież logika. Piękna katastrofa jest wtedy kiedy masz usługę, która przez lata obrosła w 100 maleńkich dodatkowych wariantów dla każdej aplikacji z osobna i ciągle dochodzą nowe modyfikacje.

3. Nie wszystkie informacje biznesowe mają postać silnie typowanych struktur danych, czasami są to strumienie bajtów lub nawet nieokreślone pliki

bo w tego typu projektach moim zdaniem, struktury danych (relacyjne) się raczej nie sprawdzają... lepsze są obiektowe modele z redundancją, nie istnieją "nieokreślone pliki", wszystko jest jakimś obiektem - w skrajnym przypadku "jakiś innym plikiem" z nazwą i metadanymi.

Obraz i dźwięk to też mogą być informacje biznesowe. Mimo, że istnieje wspaniała SOA to nadal w użyciu jest FTP :-)

4. Szyna sama w sobie mimo, że nie dostarcza żadnej funkcji biznesowej, jest drogim w utrzymaniu systemem, który się rozwija i pielęgnuje podobnie jak inne aplikacje

jak to szyna nie dostarcza funkcji biznesowej :), ilu ludzi (jak sam wskazałeś: interfejs białkowy) zastępuje a człowiek to biznes :)

Biznes sprzedaje produkty i usługi przy pomocy swoich aplikacji (nie szyny), a człowiek to przecież nie biznes tylko koszt :-)

Jak dla mnie lepsza drogą jest sprowadzenie liczby aplikacji do kilku, maks kilkunastu i integracji jak w przypadków typowych komponentów z interfejsami. Unikamy zbędnego bytu po środku, zmuszamy się do zastanowienia czy zanim napiszemy kolejną "fajną apliakcyjkę" nie warto nowej funkcjonalności "umieścić" w jakimś istniejącym już podsystemie. Czy to jest zawsze możliwe, kto to wie...:) ale nie raz jak widzę gdzieś dziesiątki programików to okazuje się, że spokojnie mogły by być pogrupowane dziedzinowo w kilka "grubszych" podsystemach.

Czyli mówisz, że trzeba zarządzać katalogiem serwisów zamiast aplikacji? Co zatem wyznaczać ma granice między aplikacjami?Przemek Wiśniewski edytował(a) ten post dnia 15.10.10 o godzinie 17:05

Temat: Co po SOA nastąpi?

Przemek Wiśniewski:
Czyli mówisz, że trzeba zarządzać katalogiem serwisów zamiast aplikacji? Co zatem wyznaczać ma granice między aplikacjami?

interfejsy, tak sądzę...

chyba w tym kierunku chyba to idzie, co ciekawe jak ktoś sobie wdroży jakiś sensowny "workflow engine" to on doskonale załatwia przy okazji sprawę integracji... i szyna SOA staje "zbędnym ogniwem".... w tym łańcuchu pokarmowym...:)

moim daniem wracają jak bumerang do łask komponentowe metody projektowania i projektowanie zorientowane na odpowiedzialność obiektów (komponentów) ... czyli usługi i interfejsy, obawiam się, ze SOA w obecnej postaci odejdzie do lamusa...

Temat: Co po SOA nastąpi?

Jarek Żeliński:

Przemek Wiśniewski:
Czyli mówisz, że trzeba zarządzać katalogiem serwisów zamiast aplikacji? Co zatem wyznaczać ma granice między aplikacjami?

interfejsy, tak sądzę...

chyba w tym kierunku chyba to idzie, co ciekawe jak ktoś sobie wdroży jakiś sensowny "workflow engine" to on doskonale załatwia przy okazji sprawę integracji... i szyna SOA staje "zbędnym ogniwem".... w tym łańcuchu pokarmowym...:)

A to dobre jest. I już nawet można zaobserwować w przyrodzie.

moim daniem wracają jak bumerang do łask komponentowe metody projektowania i projektowanie zorientowane na odpowiedzialność obiektów (komponentów) ... czyli usługi i interfejsy, obawiam się, ze SOA w obecnej postaci odejdzie do lamusa...

Też mnie się tak wydaje.

Temat: Co po SOA nastąpi?

troszkę z boku, "prasa donosi"

MDM isn't a technology solution its a simple business solution, the problem is that IT people tend to make it a complex IT solution because they can't make it a simple business solution.

http://service-architecture.blogspot.com/2010/10/mdm-m...