Очень часто становление того или иного подхода сопровождается появлением неверных или ошибочных трактовок, как это было, например, с концепцией . Не миновала "сия чаша" и сервис-ориентированную архитектуру. Так, по крайне мере, считает представитель компании BEA Джерими Уэстерман (Jeremy Westerman). Именно поэтому в одной из своих статей, посвященных SOA, он специально останавливается на "проблемных местах" и приводит подробные пояснения:
Джерими Уэстерман дает следующее определение SOA: это парадигма, предназначенная для проектирования, разработки и управления дискретных единиц логики (сервисов) в вычислительной среде. Применение этого подхода требует от разработчиков проектирования приложений как набора сервисов, даже если преимущества такого решения сразу неочевидны. Разработчики должны "выйти за границы" своих приложений и подумать, как воспользоваться уже существующими сервисами, или изучить, как их сервисы могут быть использованы их коллегами.
SOA "подталкивает" к использованию альтернативных технологий и подходов (таких как обмен сообщениями) для построения приложений посредством связывания сервисов, а не посредством написания нового программного кода. В этом случае, при надлежащем проектировании, применение сообщений позволяет компаниям своевременно реагировать на изменение рыночных условий - "настраивать" процесс обмена сообщениями, а не разрабатывать новые приложения.
Слова Джерими Уэстермана в определенной степени перекликаются с точкой зрения Клива Финкельштейна. "Родоначальник инфотехники" сетует, что до недавних пор термин "сервис-ориентированная архитектура" был синонимом "Web-сервис".
Клив Финкельштейн определяет SOA следующим образом - вызов Web-сервисов с помощью средств и языков управления бизнес-процессами. Он считает, что SOA - это термин, который появился для описания исполняемых компонентов - таких как Web-сервисы - которые могут вызываться другими программами, выступающими в качестве клиентов или потребителей этих сервисов. Эти сервисы могут быть полностью современными - или даже устаревшими - прикладными программами, которые можно активизировать как черный ящик. От разработчика не требуется знать, как работает программа, необходимо лишь понимать, какие входные и выходные данных нужны, и как вызываются эти программы для исполнения.
В самом общем виде SOA предполагает наличие трех основных участников: поставщика сервиса, потребителя сервиса и реестра сервисов (см. рис. 1). Взаимодействие участников выглядит достаточно просто: поставщик сервиса регистрирует свои сервисы в реестре, а потребитель обращается к реестру с запросом.
