Z Rafałem Łukawieckim, partnerem w firmie Project Botticelli LTD, rozmawia Tomasz Marcinek.

Na warszawskiej konferencji MSDN mówił Pan o architekturach systemów informatycznych zorientowanych na usługi. Czym w praktyce różnią się one od architektur tworzonych dziś przez większość programistów?

Żeby to zrozumieć, trzeba spojrzeć za siebie. Znana z systemów typu mainframe architektura strukturalna była w swoim czasie dużym przełomem: wyraźnie oddzielała funkcje od danych i pozwalała na ponowne użycie już stworzonego kodu. Niestety, tylko w swoim naturalnym środowisku. Poza tym nie nadawała się do tworzenia rozwiązań bardzo skomplikowanych, a takich z biegiem czasu pojawiało się coraz więcej.

Architektury obiektowe poszły znacznie dalej - nie tylko pozwalały na ponowne wykorzystanie kodu, ale znacznie ułatwiały proces tworzenia i utrzymania oprogramowania. Wizualne narzędzia RAD usprawniły najbardziej żmudną dotychczas część pracy programisty - pozwoliły na łatwe tworzenie bogatych funkcjonalnie interfejsów użytkownika. Tak powstała potęga architektury klient/serwer. Jednak i ona ma swoje wady - wciąż silne uzależnienie od platformy, monolityczna struktura aplikacji, wydajność i skalowalność ograniczona mocą obliczeniową serwera fizycznego.

Ten etap mamy już chyba za sobą...

Naturalnie, bo programiści zaczęli wykorzystywać architektury komponentowe. Elastyczne dzięki wielowarstwowości, bez mała dowolnie skalowalne, umożliwiające łatwą integrację pomiędzy aplikacjami i przynajmniej nominalnie niezależne od platformy i implementacji - wszystko to sprawia, że architektury komponentowe są znacznie bardziej atrakcyjne niż wszystko, co wymyślono dotychczas. Ale czy programiści są z nich zadowoleni? Nie sądzę, a w każdym razie na pewno nie wszyscy.

Dotychczasowe architektury, w tym także architektury oparte na komponentach, są pochodną określonych paradygmatów programowania, które skupiają się na tym, jak pisać kod, a nie jak projektować architekturę systemu. Dostosowywanie architektury do stylu programowania doprowadziło do wynaturzeń - bo choć koncepcja abstrakcyjna systemu jest uniwersalna, implementacja wymaga ustępstw wynikających z meandrów i ograniczeń poszczególnych języków programowania, architektur komponentowych, np. COM czy CORBA, a nawet środowisk wykonawczych, takich jak maszyny wirtualne czy serwery aplikacji. W ten sposób wracamy do starego problemu: braku przenośności kodu.

Skoro wszystkie dotychczasowe modele architektury systemów miały oprócz zalet także istotne wady, można zakładać, że podobnie będzie z architekturami opartymi na usługach. Nie ma Pan wrażenia, że nowa koncepcja może rozbudzić oczekiwania, których nie będzie w stanie zaspokoić?

Jestem zdania, że architektury usługowe stanowią zasadniczy przełom, z punktu widzenia analityka/programisty biznesowego znika bowiem konieczność kodowania w tradycyjnym ujęciu. Usługa abstrahuje od kodu, a zamiast niego posługuje się pojęciem komunikatu. Komunikat nie jest kodem do wykonania ani wywołaniem zdalnej funkcji. To wiadomość, dokument. Usługa zaś jest czymś, co komunikaty generuje lub odbiera, a następnie przetwarza. Usługa może być nadawcą lub odbiorcą komunikatu, może być infrastrukturą czy mechanizmem do ich przetwarzania lub przesyłania. Dla programisty usługa to nie obiekt ani komponent, tylko pewna jasno zdefiniowana funkcjonalność. Usługą może być uwierzytelnianie, nadzór nad transakcjami, monitorowanie i raportowanie, a w sensie biznesowym np. obsługa zamówienia lub rozliczenie płatności. To, jak usługa jest zorganizowana wewnętrznie, nie ma z jego punktu widzenia żadnego znaczenia.

Programowanie usług nie ma nic wspólnego z typem komunikacji, adresem czy ścieżką. Nie wymaga pojęcia sesji. Komunikat jest wysyłany przez usługę do usługi lub ewentualnie do klasy usług. Do przesyłania komunikatów służą tzw. rurociągi (pipelines), będące de facto szeregami usług przetwarzającymi kolejno wysyłane komunikaty. Na swojej drodze pomiędzy usługą wysyłającą a docelową komunikat najpierw rośnie w objętość - zbiera dane o lokalnym kontekście, np. identyfikacji, ustawieniach, czasie itd. W miarę zbliżania się do celu komunikat "chudnie", przekazując kolejne parametry właściwym usługom, dostarczając do celu jedynie właściwą treść.

Programista potrzebuje dziś możliwości ponownego wykorzystania tego samego kodu w wielu aplikacjach, uruchamiania go w dowolnej warstwie architektury oraz rzeczywistej niezależności od języka programowania i platformy. Ponadto chce skupić się na rozwiązaniu jasno zdefiniowanego problemu, a nie na tworzeniu i obsłudze funkcji przynależnych infrastrukturze, jak kontrola praw dostępu, wyszukiwanie informacji, zapewnienie niezawodności itd. Architektura oparta na usługach pozwala zrealizować wszystkie te cele jednocześnie. I nawet jeżeli z biegiem czasu okaże się, że ma ona pewne istotne wady, to korzyści, jakie przynosi, są nie do pogardzenia.