🚀 go-pugleaf

generalie w soa akcentuje sie enkapsulacje szczeguluw implementacji na rzecz 
upubliczniania tego co stanowi "wspulny mianownik" konsumenta i dostawcy 
serwisu

w standardowym przypadku takimi "szczegulami implementacji" sa raw dane z 
bazy danyh czy nawet raw obiekty logiki biznesowej

w przypadku etl sytuacja jest nieco inna. tutaj "kontraktem" uslugi sa 
wlasnie raw data. to jest klu serwisu i nie ma co go enkapsulowac :O)

czyli formalnie (z punktu widzenia soa mindset) mozna z etl zrobic soa nie 
lamiac soa mindset

oczywiste ejst ze przepuszczanie wszystkiego przez xml (bdw moze byc soa bez 
xml ;p) to duza strata wydajnosci. co wiecej - nie wszystko sie latwo i 
sensownie do xml'a pakuje.

z praktyki moge powiedziec ze webservices sa strasznie wolne w poruwniau do 
takiej np. corby

co innego ze np. w sql server wbudowane sa mehanizmy wystawiania bazy przez 
websercvice i podejrzewam ze performacne bylo czyms o czym mysleli autorzy 
:O) nie sprawdzalem sam wiec sie nie wypowiadam

wracajac do Twoih punktuw.

a jest ok i nie musi lamac "soa mindset" - wszystko jest kwestia tego gdzie 
postawi sie granice miedzy "systemami" ;p

b moze byc wolny ale podejrzewam ze w niekturyh sytuacjah da sie 
zoptymalizwowac. pytanie tylko czy to nie jest na sile zabawa

c ma pewne zalety ale jednak lamie w dosc oczywsity sposub enkapsulacyjna 
moc soa (co zauwaza Filip)

jak zwykle generalnej zasady nie hce podawac w oderwaniu od konkretnyh 
przypadkuw. powiem tak: tam gdzie sie zdecydowalem wykorzystac websevices - 
sprawdzaly sie i nie bylo wiekszyh problemuw. tyle ze nie phalem ih wszedzie 
gdzie sie da