Uściślijmy pojęcia

Service Oriented Architecture - architektura zorientowana na usługi. Wzorzec architektoniczny/projektowy, który zakłada, że mamy zestaw atomowych (realizujących minimalną niepodzielną funkcjonalność) serwisów, na podstawie których budujemy dalsze serwisy wyższego poziomu (Composite Applications). W pewnym momencie (kiedy mamy już wystarczającą ilość atomowych serwisów) możemy za pomocą paru kliknięć tworzyć nowe serwisy kompozytowe realizujące nową funkcjonalność biznesową. Dzięki dobrze zaprojektowanej i wdrożonej architekturze SOA firma może być agilna (Enterprise 2.0). SOA nie da się kupić (samo kupienie platformy integracyjnej nie jest kupieniem SOA), SOA trzeba zaprojektować. Można mieć platformę integracyjną i źle zaprojektowane środowisko i w rezultacie nie mieć SOA. Pomocą w implementacji SOA może być ESB.

ESB - Kolejny koncept/wzorzec architektoniczny/projektowy, który mówi, że do platformy integracyjnej za pomocą rozmaitych adapterów/klientów może podłączyć się dowolny system i platforma może podłączyć się do dowolnego systemu, natomiast usługi wewnątrz platformy (szyny) używają komunikacji natywnej (historycznie jest to JMS). Usługi wewnątrz platformy integracyjnej są niezależne od transportu. ESB ustandaryzował Sun wprowadzając JBI i wydzielając:

• Service Engine (usługa typu adapterowego udostępniana przez oprogramowanie ESB)
• Binding Component (usługa tłumacząca dane między różnymi transportami/formatami z którą komunikuje się Normalized Message Router).

ESB przydaje się w heterogenicznych środowiskach, w których naprawdę mamy wiele różnych systemów i technologii (Oracle, MSSQL, EJB, JMS, WS). ESB to nie SOA (ESB może być tylko sposobem na wdrożenie SOA).