Wyobraź sobie, że wdrażasz system CRM w dużej firmie telekomunikacyjnej. Jesteś na spotkaniu z klientem omawiając wymagania do modułu zarządzania kontem. Klient chciałby, żeby pod informacjami dotyczącymi konta była możliwość łatwego przeglądania listy faktur wraz z kwotą do zapłaty i datą wystawienia faktury. Dodatkowo widok listy faktur powinien umożliwiać otwarcie dokumentu faktury.
Architektura zorientowana na usługi (SOA) kojarzy się z zastosowaniem oprogramowania pośredniczącego nazywanego potocznie międzymordziem (ang. middleware). W poprzednim wpisie na temat SOA próbowałem na przykładzie opisać czym jest SOA w scenariusze z i bez ESB. W tym wpisie postaram się wyjaśnić jak middleware może pomóc przy budowaniu architektury zorientowanej na usługi.
Zdarza się, że przedsiębiorstwa inwestują w narzędzia middleware nie do końca wiedząc do czego i kiedy warto je stosować. Wiąże się to z kilkoma problemami: wiedza na temat integracji jest dosyć mało rozpowszechnioną dziedziną, a produkty oznaczone plakietką SOA oferują bardzo specyficzne metody według własnej filozofii. Temat SOA również rozumiany w środowisku informatycznym bywa w rożny sposób.
Architektura zorientowana na usługi (ang. service oriented architecture), SOA stała się popularnym terminem pojawiającym się na wszelkich etykietach dostępnego oprogramowania klasy enterprise. Praktycznie każdy dostawca chwali się, że dostarcza produkty “zgodne z SOA”. Wiele firm dało się skusić na kupienie produktu oznaczonego znaczkiem SOA z myślą, że zainstalują taki produkt i będą od tego momentu “robić SOA”… No cóż, SOA to nie systemy, a podejście, które trzeba wdrożyć by czerpać z niego korzyści.