Сервис-ориентированная архитектура, похоже, все больше и больше является горячей цитатой в наши дни, но, спросив вокруг офиса, я обнаружил, что, похоже, у меня есть много разных определений. Как вы, ребята, определяете SOA? Что бы вы считали официальным определением?
Как говорит Мартин Фаулер, это разные вещи для разных людей. Его статья по теме довольно хороша, хотя это не совсем определение.
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
Это может объяснить, что трудность возникает с конкретным определением.
Википедия: "SOA - это программная архитектура, которая использует слабо связанные программные сервисы для поддержки требований бизнес-процессов и пользователей программного обеспечения. Ресурсы в сети в среде SOA становятся доступными как независимые сервисы, к которым можно получить доступ без знания их базовая платформа."
SOA не так уж и нова, но у нее есть потенциал для достижения некоторых удивительных вещей. Но организация должна быть готова к этому: бизнес должен думать в процессах и что большая проблема
Я бы пошел с:
Определение серии безстоящих, клиентских агностические бизнес-операции для использования в нескольких приложения.
Конструкция SOA включает в себя компоненты (то есть услуги), которые могут использоваться кодом независимо от реализации (то есть любой ОС или langauge). Один экземпляр службы также может использоваться несколькими приложениями, тогда как, например, DLL нужно будет дублировать для каждого приложения и использовать ту же технологию внедрения, что и приложение для связывания.
Услуги в дизайне SOA обычно реализуются как совместимые веб-службы.
Нет официального определения, как упоминал Райан. Тем не менее, я считаю, что Томас Эрль рассматривает всю служебную ориентацию, достаточно хорошо структурированную и актуальную. Вот определение SOA из его SOA Glossary (больше):
Сервисно-ориентированная архитектура представляет собой архитектурную модель, которая направлена на повышение гибкости и экономической эффективности предприятия, одновременно снижая общую нагрузку ИТ на организацию.
Thomas Erl является автором многих названий SOA, большинство из которых получают одобрение от поставщиков SOA, включая IBM, Oracle и Microsoft. Хорошая вещь о его книгах заключается в том, что они как независимый поставщик SOA, насколько это возможно. Это означает, что вы больше узнаете о самой сервис-ориентированности и о каком-то промежуточном ПО поставщика, поддерживающем SOA.
Я согласен со всеми людьми, которые указывают вам на Фаулера. В основном это работает следующим образом: сервис-ориентированная архитектура получила репутацию хорошей, поэтому все, что люди хотят ассоциировать с хорошим, они называют SOA. На самом деле в нем много недостатков и может создать ориентированный на обслуживание Gridlock или зависимую архитектуру.
Вот мой вариант: Сервис-ориентированная архитектура - это подход к системной интеграции и повторному использованию кода, где приложения зависят от подключения к службам, предоставляемым другими работающими приложениями по всей сети. Это отличается от архитектур компонентов, где программные компоненты совместно используются между приложениями в виде библиотек или SDK, например.
Прояснение здесь - "Сервис-ориентированная архитектура - это системная интеграция и метод повторного использования кода, где приложения зависят от подключения к службам, предоставляемым другими запущенными приложениями по сети."
У меня есть сценарий, в котором два приложения j2ee были интегрированы с использованием сообщений, управляемых событиями. Здесь хорошо соблюдаются приведенные выше фразы системной интеграции и подключения к сервисам, предоставляемым другими запущенными приложениями по сети. Могу ли я назвать эту SOA?
Следующие принципы будут хорошими здесь 1) безгражданство 2) ориентированный на сообщения - слабосвязанный дефект 3) расширяемый.
Однако не применяются следующие 1) независимость от платформы - ни одна из интегрированных приложений не предназначена для работы на другой платформе. 2) Приложения представляют собой простые приложения j2ee, которые не были разработаны со всеми концепциями soa.
Я попытался определить SOA в одном из моих сообщений в блоге. Вот выдержка...
В течение многих лет стандартная практика заключалась в том, чтобы разделить функциональность на функции, классы и модули. Идея всегда заключалась в том, что эти более мелкие узкоспециализированные компоненты легче разделять и поддерживать, чем монолитные блоки кода.
Функционально, SOA не сильно отличается. Цели те же - повторное использование и простота обслуживания. Самая большая разница - в случае SOA веб-сервиса - заключается в том, что разделяемая библиотека, включенная в ваше приложение, заменена HTTP-вызовом.
Вот определение для вас:
SOA - программное обеспечение по архитектуре. Включение бессмысленной, чрезмерно раздутой функциональной инфраструктуры интерфейса, называемой архитектурой на симпатичном веб-сайте с трехмерной графической папкой, движущейся с одной стороны на другую, где "dir/s > a.txt | ftp -s: upload.ftp" выполнил эту работу.
Компоненты программного обеспечения не являются кирпичами, не могут быть обобщены с помощью общих функциональных шаблонов, и архитектура возникает на предприятии с хорошей практикой, а не с хорошим дизайном. Программное обеспечение не архивировано, оно спроектировано.
SCRUM ON!