🚀 go-pugleaf

W moim rozumieniu SOA zakłada, że praktycznie cała komunikacja między 
systemami przechodzi za pośrednictwem publicznych usług.
Zastanawiam się, jak się ta idea ma do praktyki, w szczególności do procesów 
ETL. Widzę trzy rozwiązania:

a) skrajność pierwsza: procesy ETL tworzą oddzielny podsystem. oddzielnie 
budowany, opisywany i monitorowany, który z SOA nie ma nic wspólnego.
Czyli generalnie budując złożony system już na wejściu łamiemy zasady SOA.

b) skrajność druga: procesy ETL przestają istnieć w niskopoziomowej postaci. 
Wszystko co do tej pory było jakimś procesem wsadowym pracującym
"na tyłach" baz danych zostaje sformułowane w postaci usługi. Wiąże się to 
także z faktem, że wszelkie dane przenoszone z bazy do bazy są przepychane 
przez
warstwę usług. Powstaje więc szereg wątpliwości: co z wydajnością - jeśli 
np. wziąć pod uwagę, że dane te są(mogą być) obudowywane po drodze xml'em.
Co z narzędziami typu DTS itp - do kosza ?

c) jakiś kompromis: wszelkie procesy ETL są wystawiane jako usługi, ale dane 
nie przechodzą przez interfejs. Czyli usługi dają jedynie interfejs do 
sterowania
(uruchamiania/przerywania/badania postępu...) pracującymi za ich plecami 
procesami niskopoziomowymi, które już typowo dla siebie samodzielnie łączą 
się
z bazami danych i przerzucają co trzeba. To rozwiązanie ma zalety 
organizacyjne, ale IMHO dalej poważnie łamie ideę czystej SOA (chyba, że 
przeinterpretowałem).

Jak Wy widzicie ten temat ? ieliście może podobne dylematy ? Osobiście 
skłaniam się albo za punktem a (niezależny podsystem procesów ETL)
lub c (ETL sterowane przez usługi).

Króciótko o pojęciach, którymi się posługuję:

ETL (extract-transform-load) - procesy niskopoziomowego przenoszenia danych 
między bazami danych: replikacja danych między różnymi systemami, zasilanie 
hurtowni danych itp. Np. na bazie SQL Server do budowania i organizacji 
takich procesów służy DTS (data transformation services).

SOA (service oriented architecture) - idea budowania systemów 
informatycznych na bazie silnej warstwy publicznych, wysokopoziomowych 
(najlepiej jeśli odzwierciedlających pojęcia biznesu, nie informatyki) 
usług,
za pomocą których różne systemy komunikją się ze sobą. Na bazie silnie 
zarysowanej warstwy usług można
budować aplikacje całkowicie oderwane od systemów pierwotnych 
(dostarczających usługi) - tzw. aplikacje kompozytowe - np. portale dające 
użytkownikom dostęp do usług (danych, funkcji ...) "w jednym miejscu".
Przy idei SOA ugruntowują sobie stałe miejsce nowe pojęcia, np. ESB - szyna 
usług centralizująca zarządzanie,
monitorowanie itp do usług wielu systemów.

To tak w skrócie i bardzo ogólnie, być może z drobnymi nieścisłościami ...

-- 
Filip Sielimowicz