Architektura ukierunkowana na usługi to standaryzowana metodologia organizacji i projektowania, wiążąca ściśle IT z procesami biznesowymi. Zaczyna się ona i kończy na procesach biznesowych, organizując do realizacji wspólnego celu rozproszony zestaw technologii.

SOA (Sernice Ońented Architecture) to oparta na standardach struktura, w której są budowane, wdrażane, zarządzane i aranżowane usługi, mające zapewnić sprawniejszą infrastrukturę IT, szybko reagującą na zmieniające się wymagania biznesu. W architekturze ukierunkowanej na usługi informacje i procesy - niegdyś przypisane do aplikacji stworzonych do realizacji jednego konkretnego celu - stają się elementami zbioru szeroko dostępnych i elastycznych usług programowych, które można integrować i wielokrotnie wykorzystywać.

Celem architektury ukierunkowanej na usługi jest stworzenie w przedsiębiorstwie elastycznej i trwałej infrastruktury, która ułatwi połączenie dowolnego zbioru aplikacji w dowolnym czasie, tak aby możliwe było sprostanie wyzwaniom rynkowym. Architektura SOA musi umożliwiać dynamiczne dodawanie i konfigurowanie usług na bieżąco, a także modyfikowanie przepływów logicznych między nimi, dopasowując sposób działania systemu do zmian w procesach biznesowych.

Rozmach tej wizji czyni z SOA koncepcję dość ogólnikową. Jednak potencjalne korzyści upatrywane w obniżce kosztów IT oraz większej sprawności biznesowej zachęcają wiele organizacji do podjęcia trudu wdrożenia tej architektury. Jednym z motywów takich decyzji jest też to, że SOA może przynosić "efekt transformacji" w obrębie całego przedsiębiorstwa, przy zachowaniu większości aplikacji i infrastruktury już wdrożonej.

U podstaw SOA stoją trzy podstawowe koncepcje: wirtualizacja usług, usługi wielokrotnego użytku i brokery usług.

Wirtualizacja ustug

Usługa jest kawałkiem kodu, który może być wywołany przez innego programistę za pośrednictwem publikowanego interfejsu metadanych, określanego jako "kontrakt usługowy".

SOA wymaga zdefiniowania usług wielokrotnego użytku na wysokim poziomie, bez wikłania w to kodu aplikacyjnego. W ramach SOA każda usługa powinna mieć rozpoznawalne funkcje biznesowe, które odgrywają jasno określoną rolę dla wielu aplikacji. Przykładem takich usług biznesowych wielokrotnego użytku jest np.: weryfikacja tożsamości, przechowanie danych adresowych, wyliczenie wynagrodzenia itp.

Inną zasadą SOA jest to, że usługa powinna być stabilna, ze ściśle określonymi zakresami funkcjonalności, tak aby zmiany w implementacji usługi nie zrywały możliwości współdziałania z istniejącymi użytkownikami tej usługi.

SOA jest pewnym podejściem w definiowaniu wyraźnych rozgraniczeń pomiędzy procesami biznesowymi i usługami technicznymi. Kontrakty usługowe nie są zbyt szczegółowe, co oznacza, że opisują one interfejsy do całych procesów biznesowych lub istotnych podprocesów, zamiast do szczegółów platformowych modeli obiektowych, klas i API.

W wielu przypadkach SOA jest głównie zabezpieczeniem racjonalnej struktury połączeń pomiędzy poszczególnymi, rozproszonymi serwerami aplikacyjnymi. W kontekście integracji technicznej "biznes z biznesem" praktykuje się więc rozszczepianie logiki integracyjnej metodą połączenia ośrodków webowych partnerów biznesowych.

Istotnym aspektem SOA jest wyrażenie wspólnych abstraktów (użytkowników, klientów firmy, wiadomości, licencji, serwerów informacyjnych itp.) w jednolity sposób.

Ustuga wielokrotnego użytku

Możliwość wielokrotnego używania usługi, to istotna obniżka kosztów. Podstawową zasadą przy wdrażaniu SOA jest zachęcanie programistów do użytkowania istniejących usług - niezależnie kto je zaprojektował - w jak największym, możliwym zakresie.

Programiści, przy konstruowaniu nowych aplikacji, powinni tworzyć jak najmniej nowego kodu. Nowy kod powinien jedynie ulepszać aranżację nowych wzorców interakcji między istniejącymi usługami.

Większy zakres ponownego wykorzystaniu kodów przekłada się na niższe koszty i skraca cykle projektowe. W praktyce cecha ta w dużej mierze zależy od warstwy pośredniczącej, która pozwala na współdziałanie usług za pośrednictwem sieci. W coraz większym zakresie wybieraną dla SOA strukturą pośrednicząca są środowiska web services, wykorzystujące WSDL (Web Services Desciption Language), SOAP (Simple Object Access Protocol) i inne standardy WS-. Jednak w wielu implementacjach SOA usługi są współdzielone, aranżowane i wywoływane w tradycyjnych środowiskach pośredniczących, które współdziałają na różne sposoby.

Dla ekspozycji interfejsów aplikacyjnych w środowisku SOA można zamiast web services wybrać też XML, który jest transportowany protokołem HTTP lub transferu plików

Brokery ustug

Brokery usług pozwalają programistom na deklarowanie swoich programowych "kontraktów usług" i innych metadanych opisujących - we współdzielonym rejestrze online, repozytorium czy katalogu.

Infrastruktura brokerów usług przybiera wiele form i są one często specyficzne dla poszczególnych środowisk pośredniczących i platformowych. Standard UDDI (Universal Desciption, Discovery and Integration) definiuje środowisko brokerów usług dla web services.

UDDI jest elementem świata web services. Inne popularne środowiska brokerów usług obejmują: Common Object Request Broker Architecture Naming Service, Distributed Computing Environment Cali Directory Service, Windows NT Registry, Java Remote Method Invocation Registry i repozytoria Electronic Business XML.

W charakterze węzłów brokerów usług SOA można też wykorzystywać systemy zarządzania bazą danych.

Istotą prawdziwego środowiska SOA jest niezależność od platformy, zarówno operacyjnej, jak i aplikacyjnej. Tak więc przy każdej implementacji należy dbać o to, aby nie wprowadzać specyficznych zależności od WSDL, SOAP, UDDI i innych standardów czy specyfikacji web services. Budując SOA, usługi webowe iinne środowiska projektowe, współdziałania czy operacyjne, powinno się traktować jak szczegół implementacyjny.

SOA jest ciągle jeszcze w fazie rozwojowej. W rzeczywistości jest stanem docelowym, do którego wiele organizacji może się zbliżyć, ale nigdy nie osiągnie w pełni. Sprowadza się to do maksymalizacji wykorzystania usług i minimalizacji ich redundancji, w złożonych, wieloplatformowych środowiskach rozproszonych.

SOA a stopa zwrotu z inwestycji

SOA jest metodologią projektowania, która zakłada współdzielenie funkcji aplikacyjnych wywoływanych w sieci. Jest to sposób na zrobienie więcej mniej szym wysiłkiem. Aplikacje mają być budowane szybciej, w sposób przyrostowy, z niewielką liczbą nowych wierszy kodu.

Potencjał SOA tkwi w tym, że niewielkie koszty budowy nowych aplikacji ulegają dalszemu zmniejszeniu w miarę zwiększania stopnia wykorzystania usług. Trudność polega jednak na tym, że adaptacja SOA wymaga zmiany tradycyjnego myślenia o: modelowaniu, projektowaniu, integracji, wdrożeniu i zarządzaniu aplikacjami.

Wiele z oszczędności, jakie daje SOA, ma swoje źródło w zdolności konsolidowania, w ramach całej organizacji, tzw silosów nadmiarowej funkcjonalności aplikacyjnej i danych.

Mniej wydatków na licencje oprogramowania i serwery przekłada się na oszczędności budżetowe. Mniejsza redundancja komponentów oprogramowania przekłada się na mniejsze potrzeby w zakresie prac programistycznych. Konsolidacja aplikacji z kilku platform zmniejsza koszty cyklu życia oprogramowania, które według badań Gartnera mogą być nieraz kilkakrotnie większe niż koszty licencji. Chociaż SOA wymaga znaczących inwestycji na starcie.

Według analiz Forrester Research, projektowanie oparte na SOA może być początkowo nawet droższe od tradycyjnego podejścia, gdy poszczególne etapy rozpatruje się oddzielnie, z uwzględnieniem budowania poszczególnych komponentów aplikacji. Jednak gdy te aplikacyjne komponenty zaczynają być w coraz szerszym zakresie używane wielokrotnie, SOA staje się podejściem bardziej efektywnym niż podejście tradycyjne.

Szybsze projektowanie aplikacji w ramach SOA przekładać się może także na zwiększenie konkurencyjności firmy - nowe funkcjonalności, np. w zakresie marketingu i planowania produkcji, mogą pojawić się w systemach produkcyjnych znacznie szybciej. Nowa architektura pozwoli firmom reagować elastyczniej na nowe wyzwania rynkowe, umożliwiając szybszą reorganizację, dostosowaną do nowych celów.

Istnieją też oszczędności trudne do kwantyfikowania, takie jak lepsza adaptowalność biznesu, czy też ulepszona aplikacja. Także zmniejszenie ryzyka zakłóceń w codziennym działaniu, wynikających ze zmian wprowadzanych w kodach aplikacyjnych, jest nie bez znaczenia.

SOA jest jednak nadal koncepcją dość mglistą dla wielu specjalistów IT i w mniemaniu wielu osób rozciąga się na szeroki krąg luźno związanych ze sobą technologii i podejść.

Według badań IDG Research Service Group, specjaliści IT w Stanach Zjednoczonych są podzieleni prawie po równo na tych, którzy są obeznani z SOA (52%) i tych, którzy deklarują, iż nie mają o niej pojęcia (48%).

Z kolei jednak badania Forrester Research, przeprowadzone wśród największych firm w Stanach Zjednoczonych, wykazały, że 70% respondentów już zaimplementowało SOA. W tym samym raporcie stwierdzono, że do końca roku 2005 aż 51% firm średnich i 46% małych będzie wdrażać SOA.

Problem takich badań polega jednak na tym, że tak naprawdę nie bardzo wiadomo, czy osoby biorące udział w ankiecie wiedzą dokładnie, co to jest SOA, a także w jakim znajdują się miejscu na długiej drodze do wdrożenia SOA.