Podobne cele przyświecały twórcom standardu CORBA przed kilkunastu laty. Jednak tamto podejście skończyło się właściwie porażką. CORBA nie spełniła pokładanych w niej nadziei, przede wszystkim ze względu na wymaganie bardzo ścisłego powiązania między metodami lokalnymi i zdalnymi oraz bardzo dużą granularność operacji. Z tego powodu typowy scenariusz komunikacji w CORBA wymagał bardzo wielu zdalnych, często rekurencyjnych, odwołań w jedną i w drugą stronę. Na to wszystko nałożyły się jeszcze problemy z brakiem zgodności różnych implementacji standardu, wsparciem tylko wybranych języków programowania i trudności z komunikacją poza sieć lokalną. Wydaje się, że twórcy standardu WebServices wyciągnęli wnioski z tej lekcji, gdyż specyfikacje WS-* opisujące poszczególne elementy usług sieciowych zdają się nie powielać błędów CORBA.

Z pojęciem WebServices wiążą się pojęcia konsumenta (ang. consumer) i dostawcy (ang. provider) usług. Dostawcą jest system czy środowisko udostępniające usługę sieciową. Konsumentem jest dowolny użytkownik usługi, który może być inną usługą lub systemem.

WebServices opierają się na specyfikacjach opracowanych przez konsorcjum W3C, które zostały dobrze przyjęte i szeroko zaakceptowane na rynku informatycznym. Dzięki temu, doczekały się wsparcia w większości dostępnych na rynku środowisk do budowy oprogramowania i w wielu gotowych systemach.

Do definicji interfejsu usług udostępnianych jako WebServices służy WSDL (WebServices Description Language). Oprócz WSDL powstało wiele innych standardów wspierających budowę rozwiązań opartych o WebServices. Do najpopularniejszych z nich należą:

- UDDI (Universal Description, Discovery and Integration) - pozwalający na wyszukiwanie informacji o dostępnych usługach sieciowych;

-SOAP (Simple Object Access Protocol) - protokół do zdalnego wywoływania usług, m.in. typu WebServices.

Oprócz standardów wymienionych powyżej, dostępny jest także szereg innych, wspierających różne aspekty wykorzystywania usług sieciowych, takie jak: bezpieczeństwo, transakcyjność, obsługa zdarzeń itd. Większość z tych standardów opiera się na języku XML, który służy zarówno do definicji usług (WSDL), jak też wywoływania usług (SOAP) czy przenoszenia danych wejściowych i wyjściowych (czysty XML). Dzięki takiemu podejściu, zyskujemy czytelność przesyłanych komunikatów zarówno dla systemów informatycznych, jak i dla ludzi.

Jak widać, WebServices to technologia, która może pomóc w realizacji architektury zgodnej z SOA. Jednak ani ta, ani żadna inna technologia nie jest wymagana do stworzenia architektury usługowej. Podejście SOA można zrealizować korzystając niemal z dowolnej technologii, mimo że niektóre nadają się do tego bardziej, a inne mniej. Można to także z powodzeniem wykonać w środowiskach heterogenicznych, zbudowanych przy wykorzystaniu wielu różnych technologii. SOA nie wymaga unifikacji technologicznej, a wręcz promuje wykorzystanie istniejących technologii i sprawdzonych funkcjonalności istniejących systemów poprzez dopisanie do nich interfejsu usługowego, dostępnego dla wszystkich zainteresowanych konsumentów usług.

Z drugiej strony, zastosowanie technologii WebServices nie gwarantuje, że to co powstanie przy jej udziale, będzie zgodne z SOA. WebServices, podobnie jak każdą inną technologię, można źle wykorzystać, na przykład poprzez zbyt wysoką granularność i brak luźnego powiązania usług.