Wprawdzie nic nie stoi na przeszkodzie, by z usług Web korzystać jak z mechanizmu zdalnego wywołania procedur, ale wówczas okaże się, że cała technologia (kodowanie do XML itd.) będzie tylko spowalniać pracę aplikacji. Jeżeli jednak projektant stosujący się do wytycznych SOA odpowiednio wpasuje warstwę usług do swojej aplikacji, zdefiniuje kontrakty i zasady kooperacji usług, to powinno okazać się, że zalety XML kompensują niedogodności związane z kosztem transmisji. Niestety, na razie nie ma narzędzi, które pozwoliłyby coś takiego symulować. Na razie to, czy komunikaty zostaną optymalnie dobrane, zależy od wyczucia analityka i projektanta.

Kolejny problem wiąże się z definicją kontraktu - czyli określeniem, czego usługa oczekuje i jak będzie działać. O ile w przypadku tradycyjnych obiektów kontrakt był definiowany za pośrednictwem klas i funkcji publicznych czy interfejsu, o tyle w SOA jest znacznie bardziej rozbudowany i musi obejmować pełne informacje potrzebne do wykonania operacji. Dodatkowo utrudnia sprawę fakt, że pisząc usługę Web, należy liczyć się z tym, że jej funkcjonalność powinna być też dostępna w tradycyjny sposób, bez konieczności przechodzenia przez cały stos SOA.

Projektanci aplikacji stają przed dylematem - usługa z jednej strony powinna być prosta, z drugiej - ma realizować funkcjonalność biznesową, nie zaś być zwykłym wywołaniem funkcji. Nie powstanie aplikacja SOA, jeżeli po prostu opakujemy interfejs atrybutami, które zmienią je w usługę Web. Ponadto przy takim wywołaniu nie ma możliwości przekazywania kontekstu - zostałyby złamane zasady SOA. Jednak na marginesie warto dodać, że Microsoft pracuje nad pewnego rodzaju schematem postępowania, który pozwoli przeprowadzić konwersację z ciągiem usług Web. W ten sposób można symulować sesję.

Komunikat ma być oddzielony od implementacji, która posługuje się innym modelem abstrakcyjnym. Pomysł, by w ramach komunikatu przekazywać referencję (ewentualnie schemat) wewnętrznej klasy implementacyjnej powoduje, że w przypadku zmiany implementacji trzeba poinformować o modyfikacji wszystkich konsumentów usługi. Tymczasem w przypadku SOA należy założyć, że każda usługa jest autonomiczna. Autor traci nad nią kontrolę, gdy tylko opublikuje schemat. Nie ma technicznych możliwości, by powiadomić odbiorcę "że coś uległo zmianie" - po prostu aplikacja, która korzysta z usługi, przestanie działać... Konieczne jest takie planowanie, by od razu uwzględnić zarządzanie wersjami i zmianami.

Bardzo istotna jest kwestia bezpieczeństwa. Ponieważ praktycznie każde żądanie jest oddzielnym bytem, należy wymagać, by pakiet był podpisany cyfrowo i zaszyfrowany. Jeżeli coś się nie zgadza, usługa powinna odmówić wykonania operacji (należy pamiętać o atakach typu DoS). Każda usługa, otrzymując komunikat, musi sprawdzać jego poprawność. Co prawda schemat WSDL pozwala opisać parametry i typy, ale już nie związki wewnętrzne w komunikacie.

Dużym problemem jest określenie zasad funkcjonowania usługi (zarówno w rozumieniu sprostania umowom SLA, jak i zachowania w niestandardowych sytuacjach). Mechanizm WS-Policy pozwala opisać niemal każde działanie usługi, ale bez gwarancji, że zasady te zostaną poprawnie odczytane przez drugą stronę. Na stworzenie uniwersalnych zasad opisu trzeba jeszcze poczekać (dobrze, że udaje się opisywać wymagania bezpieczeństwa).

Kwestią otwartą jest testowanie i obsługa błędów w całej infrastrukturze SOA. Z punktu widzenia klienta usługa albo działa, albo nie. Nie rozstrzygnięto na razie, jaki przyjąć sposób postępowania w sytuacji, gdy dana usługa jest realizowana przy użyciu innych usług, z których jedna zawiedzie.

Kolejny problem jest związany z konstrukcją "fasady usługowej". W przypadku metodologii obiektowej istnieje np. rozbudowana biblioteka wzorców projektowych, która dokładnie pokazuje, w jaki sposób można rozwiązywać typowe problemy. W przypadku SOA takie wzorce dopiero powstają - Microsoft ma zamiar opublikować zestaw gotowych do użycia wzorców pokazujących praktyczne użycie SOA. Firma zaproponowała także schemat dekompozycji usług na tzw. mapę modułów, gdzie zasady biznesowe (i struktura przedsiębiorstwa) są rozkładane na części. Wewnątrz przedsiębiorstwa wyodrębniane są obszary: usług, tworzenia żądań, spełniania wymagań, zarządzania czy współpracy. Otoczone są one zewnętrznymi mechanizmami - dostawcami, klientami, partnerami logistycznymi czy finansowymi itp. Taki diagram jest coraz bardziej uszczegóławiany, by wyodrębnić możliwie wiele operacji biznesowych i zachodzących między nimi zależności.

W pakiecie Visual Studio 2005 będzie dostępny specjalny komponent (Whitehorse), który umożliwi modelowanie powiązań pomiędzy usługami a konkretnymi elementami infrastruktury informatycznej. Już w BizTalk 2004 jest narzędzie, które pozwala graficznie połączyć usługi w działający system (schemat jest zapisywany w języku BPEL). Warto tu dodać, że tradycyjne języki modelowania (np. UML) nadają się tylko do przedstawienia podstawowej interakcji z usługami i zaprojektowania "wnętrza" realizującego usługę. Jednak by modelować cały system oparty na SOA, potrzebne są narzędzia nowej klasy.

Należy podkreślić, że SOA nie jest programowaniem rozproszonym, metodą wyrównania obciążeń czy podnoszenia niezawodności, choć pewne elementy, jak chociażby WS-Addressing, pozwalają taką funkcjonalność osiągnąć. W SOA chodzi "tylko" o dostęp do pewnych funkcjonalności.

Jak pracować?

Niemal w każdym środowisku deweloperskim można już w miarę łatwo udostępnić funkcję w formie usługi Web - czy to dodając atrybut (jak w .Net, a niedługo także w Javie), czy też generując "pośrednika" za pomocą kreatora, który zrozumie i przetłumaczy żądanie na język Web Services. W przypadku .Net bardziej rozbudowane mechanizmy (w tym WS-Security) są opakowywane w tzw. Web Service Enhancement (obecnie dostępne są wersje: 1.0 SP1 i 2.0). Zdaniem Microsoftu są one przeznaczone dla early adopters.

Należy podkreślić, że architektura SOA z założenia jest niezależna od warstwy transportowej. Ze względu na łatwość komunikacji SOA jest zwykle kojarzona z usługami Web, ale nie jest to warunek bezwzględny. Idea SOA sprowadza się do koncepcji kontraktu i komunikatu, który może być realizowany przy użyciu dowolnego medium. Można stworzyć aplikację zgodną z SOA, która wewnątrz będzie używać wywołań opartych na MSMQ lub po prostu lokalnego wywoływania funkcji. Warto odnotować, że ze względu na fakt, iż implementacja WS-Transaction rodzi obecnie największe problemy, może się okazać, że jeszcze przez jakiś czas komunikaty będą przesyłane transakcyjną kolejką, a w przyszłości nastąpi przejście na "czyste" usługi Web.

Dla popularyzacji SOA ważnym wydarzeniem będzie pojawienie się Indigo, podsystemu komunikacyjnego Longhorn (prawdopodobnie Indigo pojawi się wcześniej jako samodzielna biblioteka). Indigo będzie realizować warstwę odpowiedzialną za transakcje i pewność dostarczenia komunikatu. Ponadto uprości tworzenie infrastruktury, z której korzystają usługi. Jednak już teraz, na długo przed pojawieniem się Indigo, opracowano referencyjną architekturę ShadowFax, która jest pewnego rodzaju frameworkiem do tworzenia systemów opartych na SOA, a przy okazji doskonale udokumentowaną implementacją referencyjną. W realizację tego projektu był zaangażowany Wojciech Kozaczyński, jeden z Polaków pracujących w Microsoft, architekt odpowiedzialny za tworzenie "wzorców" do budowy aplikacji. Z tą infrastrukturą można zapoznać się na stronie:http://www.gotdotnet.com .