Z Davidem A. Chappellem, wiceprezesem Sonic Software, rozmawia Tomasz Marcinek.

Zewsząd słychać, że SOA rozwiąże jeden z podstawowych problemów informatyki, jakim jest integracja. Skąd to przekonanie?

Koncepcja SOA nie powstała z dnia na dzień - to efekt wieloletniego myślenia o podejściu do integracji. Wcześniej było wiele różnych rzeczy, CORBA, COM itd. Pierwsza sprawa związana z architekturą SOA to wprowadzenie granularności, czyli rozdzielności usług. Z tego wynika podstawowa korzyść, polegająca na elastyczności i możliwości niezależnej konfiguracji usług. Gdy warunki biznesowe się zmieniają, zmienia się nie usługa, lecz jej reprezentacja i sposób interakcji z resztą środowiska.

Czy CORBA nie zapewniała tego samego? Mam wrażenie, że branża poszukuje sposobu, aby sprzedać klientom nową ideę, która jest de facto starą ideą w nowym opakowaniu...

Podstawową lekcją, którą wyciągnęliśmy z architektury CORBA, jest utrzymanie luźnych powiązań pomiędzy usługami. CORBA była piękną abstrakcją, ale wymagała, by każda usługa dokładnie "wiedziała" jak wygląda architektura całego środowiska, za co odpowiada, jak się komunikuje. To byłoby świetne w środowisku, które się rzadko zmienia, ale problemem jest przecież owa zmienność - zbyt częsta, jak na możliwości CORBA. W SOA możemy zmieniać poszczególne usługi nie dotykając pozostałych - w ogóle nie modyfikując architektury.

Czym w takim razie zgrzeszyły brokery komunikatów, że muszą być zastąpione przez środowiska zgodne z koncepcją SOA? Jeszcze chwilę temu brokery komunikatów były przedstawiane jako doskonałe rozwiązania...

Brokery komunikatów to bardzo dobra technologia, tylko w praktyce niezbyt skalowalna. To się objawia w dużych środowiskach integracyjnych, ale fakt jest faktem, bo coraz więcej z naszych dużych, międzynarodowych klientów ma z tym problem. U kilku z nich nasze produkty Sonic ESB spełniają rolę rozwiązania integrującego wiele brokerów komunikatów.

A może to jest właśnie ta właściwa rola dla architektury SOA - pośredniczenie w komunikacji między środowiskami integracyjnymi?

W wielu przypadkach to naturalna kolej rzeczy, bo przecież integracja nie zakłada wyrzucania wszystkiego, co istniało do tej pory, ale właśnie uzupełnianie, wypełnianie. Nie jestem jednak przekonany, że to jest właściwy model postępowania dla firmy, która ma możliwość budowania architektury SOA bez pośpiechu.

Nawet jeżeli SOA - przynajmniej w teorii - rozwiązuje problem granularności i niezależności usług, nie rozwiązuje jednak kwestii skomplikowania infrastruktury informatycznej. Nie obawia się Pan, że implementacje SOA stworzą z czasem swój własny świat, którego skomplikowanie pochłonie korzyści wynikające z eleganckiej architektury?

Na dziś korzyści z uelastycznienia infrastruktury wydają się większe, niż jakiekolwiek bariery stwarzane przez technologie wykorzystywane do realizacji architektur SOA. Jak będzie w przyszłości - zobaczymy. Zawsze było tak, że po uproszczeniu jednej warstwy następował gwałtowny rozwój, po czym pojawiała się kolejna potrzeba uproszczenia. Jeśli więc tak się stanie, nie będzie w tym nic nadzwyczajnego.

Decydując się na budowę architektury SOA, firmy napotykają obecnie odwieczny problem - brak standardów. Jak można budować architekturę integracyjną bez standardów? To rodzi ryzyko, że trzeba będzie korzystać wyłącznie z rozwiązań jednego dostawcy, a to przecież burzy cały sens integracji...

Pewien stopień otwartości jest zachowany. Firmy współpracują ze sobą i łączą się. Na dłuższą metę dostawcy muszą zapewnić pewien poziom kompatybilności, aby w ogóle móc sprzedawać swoje rozwiązania dużym, wymagającym klientom.

W jaki sposób należałoby zabrać się do budowy architektury SOA? Czy jest jakaś uniwersalna praktyka w tej dziedzinie?

Pierwszy etap powinien polegać na zdefiniowaniu usług. To jest o tyle trudne, że wiele aplikacji nie oferuje dobrego interfejsu, za pomocą którego można by się z nimi komunikować. Na tym etapie rozstrzyga się sprawa granularności usług i trzeba się dobrze zastanowić, jak potrzeby mogą wyglądać w przyszłości.

Drugi etap powinien polegać na definiowaniu procesów, które obejmują komunikację między dwiema lub więcej usługami. Tu problemem jest często otwartość organizacji, a raczej jej brak, zwłaszcza w sytuacji gdy łączą się firmy i gdy procesy mają obejmować systemy dwóch różnych dotychczas organizacji. Problem, co oczywiste, leży w ludziach i komunikacji, a nie w technologii. Dopiero po tych dwóch etapach można zająć się doborem odpowiednich technologii i metodyki wdrożenia.

Czy Sonic ma jakieś pomysły w dziedzinie metodyki wdrażania architektury SOA?

W przypadku Sonic Software mamy do czynienia z technologią całkowicie rozproszoną, bez centralnego repozytorium czy centralnej kontroli zdarzeń. Zaletą takiego podejścia jest przede wszystkim to, że wdrażanie SOA może odbywać się drobnymi krokami, pozwalającymi zapoznać się z materią, a przy okazji bez ponoszenia wysokich kosztów budowy środowiska integracyjnego.

Decentralizacja ma także kapitalne znaczenie dla skalowalności, bo przetwarzanie polegające np. na przekształceniu komunikatu z jednego formatu na inny odbywa się w wydzielonej aplikacji na serwerze źródłowym, z wykorzystaniem jego mocy obliczeniowej. Do aplikacji docelowej wysyłany jest komunikat we właściwym formacie. I tylko do niego - nie ma żadnego elementu pośredniczącego.

SOA w naszym wydaniu ma także tę zaletę, że usługi z definicji są tworami wirtualnymi, które mogą być realizowane przez wiele instancji aplikacji. Każda usługa wie o środowisku, w którym działa, tyle ile musi wiedzieć, by poprawnie działać, co z punktu widzenia bezpieczeństwa jest zaletą, a nie wadą.

Jeśli chodzi o kontrolę, to Sonic przejął niedawno firmę Actional, która specjalizuje się w rozwiązaniach do zarządzania środowiskami SOA. Czy takie zarządzanie nie przeczy idei decentralizacji?

Kupiliśmy Actional właśnie dlatego, że jej rozwiązanie pozwala na rozproszoną kontrolę i daje dużą elastyczność. Oprogramowanie zarządzające Actional opiera się na agentach, które śledzą lokalne transakcje SOA i porównują je z zapisanymi we własnych repozytoriach regułami. Reguły są definiowane centralnie, a następnie aktualizowane poprzez wysyłanie odpowiednich komunikatów do agentów ze stacji zarządzającej.

W wielu firmach słowo bezpieczeństwo jednoznacznie kojarzy się z centralizacją. Czy zabezpieczenie środowiska SOA nie będzie wymagać centralizacji - przynajmniej w pewnej płaszczyźnie?

Gdyby w architekturze rozproszonej zaistniała potrzeba centralizacji, choćby częściowej, zawsze można do tego pomysłu wrócić, choć nie sądzę, aby było to rozsądne. Rozproszenie daje zbyt wiele korzyści. W moim odczuciu bezpieczeństwo nie jest koniecznie powiązane z centralizacją architektury. Centralne zarządzanie to nic innego jak centralne ustalanie reguł, a pilnowanie ich realizacji nie musi odbywać się centralnie. Zresztą teraz, gdy rozwiązania sieciowe są coraz bardziej świadome tego, co dzieje się w warstwach aplikacyjnych, nie będzie to chyba potrzebne. Wiele mechanizmów bezpieczeństwa - tak jak dotychczas - będzie działać na przełącznikach i routerach.