SOA Reinvented

Data: 2017-11-21
Autor: Sebastian Konkol
SOA Reinvented

No dobrze, może trochę przesadziłem z tym odkrywaniem. Ale tylko trochę. Prowadziłem niedawno kilka wystąpień o tematyce nawiązującej do zwinności w architekturze. Poza innymi ciekawymi dyskusjami często wracaliśmy także do zagadnień SOA. Kilka myśli cieszyło się szczególnym powodzeniem.

„Śmierć systemom zintegrowanym”. Ta myśl wywoływała zadziwiająco zbieżne poparcie – pośród analityków, architektów, programistów. Wszyscy podzielali doświadczenia z systemami zintegrowanymi, głównie polegające na tym, że każdy wymaga jakichś dostosowań (tzw. kastomizacji) oraz że system uzależnia firmę od jego dostawcy. W pewnym momencie to nie firma posiada system – system zaczyna posiadać firmę, a im większy system, tym szybciej. Zarządzanie aktywami informatyki powinno opierać się na tych samych zasadach, co innymi aktywami – „wszystkie jajka w jednym koszyku” to zawsze ryzykowna strategia. Nadzieja w dekompozycji i minimalizacji wpływu pojedynczego dostawcy oraz integracji na bazie SOA. To właśnie SOA stanowi podstawę strategicznego zarządzania dostawcami IT.

Dekompozycja to taktyka obecna na każdym poziomie tworzenia systemów informatycznych – od kodu i inżynierii oprogramowania po architekturę rozwiązań i korporacyjną. Myślenie systemowe zostało już wyparte przez myślenie komponentowe. Komponenty powinny świadczyć atomowe usługi – tak małe, jak to ma jeszcze sens, jednocześnie realizujące operacje o dobrze określonym biznesowym znaczeniu. Wartość informatyki nie leży w tym, jak skonstruowany jest komponent, ale jak sprawnie moglibyśmy go wykorzystać w inny sposób. Ale to przecież już wiadomo.

Wbrew praktyce i marketingowi dostawców poważnych rozwiązań informatycznych, SOA nie potrzebuje żadnej platformy integracyjnej, a implementacja platformy integracyjnej wcale nie daje SOA. Platforma integracyjna i SOA mogą sobie bardzo pomóc. Usługi SOA powinny być tworzone poza platformą integracyjną – sama platforma powinna zapewniać usługi dostępowe, dla kanałów dostępu do usług. To na poziomie usług kanałowych powinny być egzekwowane kontrakty usług, zapewniana spójność znaczeniowa usług i zdarzeń, czy właściwa dystrybucja zdarzeń. Nie próbujcie zmuszać platform integracyjnych do „robienia SOA”. Tak samo, jak egzekwowanie kontraktu SOA nie jest częścią usługi biznesowej, tak samo nie są nią kontrola dostępu do usługi czy stosowanie polityk dostępu. W świecie usług funkcje te powinny być wyłączone na zewnątrz i zunifikowane w oderwaniu od logiki usług – nie powinniśmy musieć zmieniać logiki usługi tylko dlatego, że przyszły nam do głowy nowe reguły określania dostępu do niej w poszczególnych kanałach.

Zwinność aplikacji opartych o SOA może być naprawdę duża. Każdą usługę SOA, będącą prawdziwie biznesową, można obudować domyślną prezentacją w postaci aplikacji WWW organizującej podstawową interakcję z tą usługą – zbieranie wartości parametrów określonych przez interfejs usługi i przekazanie ich do wywołania usługi, a także prezentacja wyników jej działania – wszystko za pośrednictwem domyślnej usługi kanałowej dla WWW z egzekwowaniem kontraktu usługi i polityki dostępu. Taka usługa może być wykorzystana w dowolnym kontekście procesu, co czyni ją zwinną usługą SOA. W praktycznych warunkach typowej firmy, jest jednak jedna aplikacja o jeszcze bardziej powszechnym zastosowaniu. Używają jej wszyscy w każdym możliwym kontekście – notatnika, prezentacji, zbierania danych i bazy danych. Już wiecie, prawda? Tak, to arkusz kalkulacyjny pewnej znanej firmy. Wyobraźcie sobie mechanizmy dostępu do usług z poziomu formuły parametrów z komórek arkusza (credits: Mateusz Ziółkowski) – nieograniczone możliwości używania usług SOA w narzędziu, którego nikomu z biznesu nie trzeba przedstawiać w sposób znany dla każdego przedstawiciela biznesu. The Ulitimate SOA Agility!

SOA to dojrzała filozofia, z której można czerpać inspiracje wykraczające znacznie poza świat SOA. W warunkach cyfrowych transformacji trzeba szukać nowych sposobów na rozwiązywanie tych samych problemów – to właśnie usługi i ich zwinność będą tworzyć podstawę dla wykonalności stosowania tych sposobów.

Pozostaw komentarz