Что такое SOA «на простом английском»? [закрыто]

Может ли кто-нибудь объяснить на простом английском, что такое SOA ? Я слышу SOA здесь, SOA там, но я не могу точно понять, что это такое и для чего используется. Была ли это какая-то простая концепция, которая позже превратилась во что-то огромное, или что?

Все документы, в том числе вики, немного абстрактны, а может я идиот и не понимаю. Есть ли на это руководство для идиотов?

Что именно стоит за этими тремя буквами?

Вы можете найти эту статью (Что такое SOA? - Объяснение SOA и веб-служб) .

Небольшой тизер:

• SOA - это стиль проектирования приложений таким образом, что они состоят из дискретных программных агентов, которые имеют простые, четко определенные интерфейсы и организованы посредством слабой связи для выполнения необходимой функции.

• В SOA есть 2 роли - поставщик услуг и потребитель услуг. Программный агент может играть обе роли. SOA не является полностью новой концепцией, однако в этой статье основное внимание уделяется SOA, реализованной с помощью веб-сервисов.

SOA - это новый значок для некоторых очень старых идей:

• Разделите свой код на модули многократного использования.

• Инкапсулируйте в модуле любое проектное решение, которое может измениться.

• Создавайте модули таким образом, чтобы их можно было комбинировать по-разному (иногда это называется «семейство» или «линейка продуктов»).

Все это основные принципы разработки программного обеспечения, многие из которых впервые сформулировал Дэвид Парнас.

Что нового в SOA:

• Вы делаете это в сети.

• Модули обмениваются данными, отправляя сообщения друг другу по сети, а не с помощью более традиционных механизмов языка программирования, таких как вызовы процедур. В частности, в сервис-ориентированной архитектуре части обычно не разделяют изменяемое состояние (глобальные переменные в традиционной программе). Или, если они действительно разделяют состояние, это состояние тщательно фиксируется в базе данных, которая сама является агентом и может легко управлять несколькими одновременно работающими клиентами.

Я вижу много ответов, объясняющих сервис-ориентированную архитектуру (SOA) с использованием еще более сложных слов и технических терминов. Я хотел бы попытаться объяснить это неспециалисту, используя аналогию на простом английском языке.

Но сначала описание SOA
SOA можно описать на трех уровнях, как показано на рисунке ниже. С одной стороны у нас есть провайдер, а с другой - потребитель , разделенный мостом, по которому две стороны общаются.

Потребитель использует ряд приложений, необходимых для его бизнеса, а провайдер использует компоненты, которые предоставляют этим приложениям информацию. Они общаются через набор Сервисов с использованием общей архитектуры.

Аналогия.
Представьте себе дом в сельской местности, который во многих смыслах является частью более крупного сообщества, такого как город или поселок. В городе есть собственные комплексные системы для обеспечения водой и электричеством, канализации, обеспечения транспорта и других коммунальных услуг. В этой модели дом является потребителем, город (или сообщество) - поставщиком, а трубы, канализация, линии электропередач, оптические волокна и т. Д. - это инфраструктура, в которой они общаются.

Эту модель можно условно сравнить с SOA. Люди в доме используют несколько различных «приложений», таких как радиаторы, компьютеры, туалеты, лампы, полы с подогревом, ванны и т. Д. Эти приложения не заботятся о том, как город производит воду, производит электричество или обрабатывает отходы, пока как это работает. Составные части города - генераторы, водяные насосы и санитарные зоны. Он обеспечивает дом всеми этими потребностями, но дом может использовать его так, как он считает нужным.

Я надеюсь, что это дало хоть кому-то лучшее представление о SOA.

Предположим, у вас четыре повара. В SOA вы предполагаете, что они ненавидят друг друга, поэтому стараетесь позволить им как можно меньше разговаривать друг с другом.

Как ты это делаешь? Итак, сначала вы определите роли и интерфейс - повар 1 приготовит салат, повар 2 приготовит суп, повар 3 приготовит стейк и т. Д. Затем вы разместите хорошо организованные блюда на столе (так что это интерфейсов) и скажите: «Всем, пожалуйста, поместите свое творение в назначенные вам блюда. Не заботьтесь ни о ком другом».

Таким образом, четыре повара должны как можно меньше разговаривать друг с другом, что очень хорошо в разработке программного обеспечения - не обязательно потому, что они ненавидят друг друга, но по другим причинам, таким как физическое местоположение, эффективность при принятии решений и т. Д.

Это также означает, что вы можете комбинировать блюда (услуги) по своему усмотрению. Например, вы можете использовать десерт для обслуживания кафе, или просто взять суп и смешать его с хлебом, купленным у другой компании, чтобы обеспечить более дешевое меню, или позволить другим ресторанам использовать ваши салаты в сочетании со своими блюдами и т. Д. .

Одна из самых успешных реализаций SOA была на Amazon. Благодаря своей конструкции они могли переупаковать всю свою инфраструктуру и продавать ее как Amazon Web Service.

* Это только один аспект SOA.

SOA - это архитектурный стиль, но также и видение того, как разнородные приложения должны разрабатываться и интегрироваться. Основная цель SOA - отказаться от монолитных приложений и вместо этого иметь набор повторно используемых сервисов, которые можно составлять для создания приложений.

IMHO, SOA имеет смысл только на уровне предприятия и ничего не значит для отдельного приложения.

На многих предприятиях каждый отдел имел собственный набор корпоративных приложений, что предполагало

1. Подобная функция реализовывалась несколько раз

2. Данные (например, данные о клиентах или сотрудниках) должны использоваться несколькими приложениями.

3. Приложения были ориентированы на отдел.

Идея SOA состоит в том, чтобы сделать повторно используемые сервисы доступными в масштабах всего предприятия, чтобы на их основе можно было создавать и составлять приложения. Обещания SOA:

1. Нет необходимости повторно реализовывать аналогичные функции снова и снова (например, предоставлять услуги клиентам или сотрудникам)

2. Облегчает интеграцию приложений вместе и доступ к общим данным или функциям

3. Разработка, ориентированная на предприятие.

Видение SOA требует как технологического, так и организационного сдвига. Хотя он решает некоторые проблемы, он также вводит другие, например, безопасность намного сложнее с SOA, чем с монолитным приложением. Таким образом, SOA является предметом обсуждения, работает она или нет.

Это 1000-футовый вид SOA. Однако на этом все не заканчивается. Существуют и другие концепции, дополняющие SOA, такие как оркестровка бизнес-процессов (BPM), служебная шина предприятия (ESB), комплексная обработка событий (CEP) и т. Д. Все они решают проблему согласования ИТ / бизнеса , то есть как получить ИТ уметь эффективно поддерживать бизнес.

SOA - это аббревиатура от Service Oriented Architecture.

SOA проектирует и пишет программные приложения таким образом, чтобы отдельные программные модули можно было легко интегрировать с высокой степенью повторного использования.

Большинство людей ограничивают SOA написанием программных веб-сервисов клиент / сервер. Но это слишком маленький контекст SOA. SOA намного шире, чем это, и за последние несколько лет веб-сервисы были основным средством общения, что, вероятно, является причиной того, что люди думают о SOA как о веб-сервисах в целом, ограничивающих границы и значение SOA.

Вы можете подумать о написании модуля доступа к базе данных, который был бы настолько независимым, что он мог бы работать самостоятельно, без каких-либо зависимостей. Этот модуль может предоставлять классы, которые могут использоваться любым программным обеспечением хоста, которому требуется доступ к базе данных. В хост-приложении нет стартовой конфигурации. Все, что необходимо или требуется, передается через классы, предоставляемые модулем доступа к базе данных. Мы можем называть эти классы службами и рассматривать модуль как поддерживающий службы.

Практика SOA обеспечивает высокую степень повторного использования за счет применения DRY [Не повторяйте себя], что приводит к созданию программного обеспечения с высокой степенью поддержки. Ремонтопригодность - это первое, о чем думает любая программная архитектура - SOA дает вам это.

Насколько я понимаю, основная концепция заключается в том, что вы создаете небольшие «сервисы», которые предоставляют что-то полезное для других систем, и избегаете создания больших систем, которые, как правило, делают все внутри системы.

Итак, вы определяете протокол, который будете использовать для взаимодействия (скажем, это могут быть веб-службы SOAP), и позволяете вашей «системе, которая выполняет какую-то бизнес-работу», взаимодействовать с небольшими службами для достижения вашей «большой цели». .

Я бы посоветовал вам прочитать статьи Томаса Эрла и Роджера Сешнса, это даст вам твердое представление о том, что такое SOA. Это также хорошие ресурсы, посмотрите на SOA, объясненную для вашего начальника, для объяснения непрофессионала.

Создание SOA

Шаблон проектирования SOA

Достижение целостности в SOA

Почему ваша SOA должна быть похожа на VW Beetle

SOA объяснил вашему боссу

Производительность службы WCF

то, что обычно происходит в крупных организациях, - это то, что со временем все становится либо монолитными, либо разрозненными системами повсюду, либо немного того и другого. В конце концов кто-то входит и говорит, что у нас беспорядок. Теперь вы хотите перепроектировать (деньги кому-то), чтобы все было ориентировано на своего рода монотлит, в зависимости от того, кому вы платите, парадигму, но в то же время у вас есть возможность добавлять части и части независимо от мастера / монолита.

Итак, вы покупаете SOA от Oracle, и Oracle становится начальником всех ваших частей. Все остальные игроки должны работать с SOA через службу (веб-службу или что-то еще). Монолит Oracle позаботится обо всем (монолит не означает унизительный). Ах да, у вас есть ASP.NET MVC спереди или что-то еще.

Главное - перемещать элементы в систему и извлекать из нее без каких-либо последствий, а поставщик Oracle SOA, Microsoft WCF, остается мозгом всего этого. все в порядке, плавно, вещи движутся туда-сюда практически без последствий, даже человеческие услуги, а не только компьютеры.

Для меня это просто набор веб-сервисов (или как мы их называем в будущем) с хорошим интерфейсом. А если у вас есть база данных, просто нажмите на нее и не беспокойтесь о модных словах. все нормально.

Только одно предложение: -

Прочтите « Концепции, технологии и дизайн SOA » Томаса Эрла.

В нем очень красиво представлены подробности о SOA на простом английском языке и с примерами из практики.

Ну, вы понимаете ... SOA означает сервисно-ориентированную архитектуру .... Проще говоря, вы пишете фрагмент кода, который является очень общим, т.е. он делает что-то, что может использоваться во многих приложениях ... может быть что-то вроде адресная книга или может быть калькулятор. и вы запускаете этот код в IIS. Таким образом, вы предоставляете услугу через свой код. Итак, вы поставщик услуг. Теперь кто-то хочет использовать аналогичный код, тогда ему не нужно писать код снова. Он просто использует ваш код, возможно, через веб-службу. Следовательно, он становится потребителем услуг. Следовательно, создание программы с использованием таких сервисов называется SOA. И существует слабая связь, поскольку поставщик услуг и потребитель могут взаимодействовать, даже если они используют языки программирования diff. Надеюсь, вы понимаете.

из блогов ittoolbox.

Ниже описаны сходства и различия с прошлыми методами проектирования:

• SOA против структурированного программирования o Сходства: больше всего похоже на вызовы подпрограмм, в которых передаются параметры, а работа функции абстрагируется от вызывающей стороны - например, соединение и выполнение CICS и зарезервированное слово COBOL CALL. Тетради используются для определения структуры данных, которая обычно определяется как схема XML для услуг. o Различия: SOA слабо связана, что означает, что изменения в сервисе меньше влияют на потребителя («вызывающая» программа), а сервисы совместимы на разных языках и платформах.

• SOA против OOA / OOD o Сходства: инкапсуляция, абстракция и определенные интерфейсы o Различия: SOA слабо связана без иерархии классов или наследования, низкоуровневые абстракции - уровень класса по сравнению с бизнес-сервисом

• SOA против устаревшей разработки на основе компонентов (CBD) - например, CORBA, DCOM, EJB o Сходства: повторное использование посредством сборки компонентов, интерфейсов, удаленных вызовов o Различия: широкое принятие стандартов, схемы XML по сравнению с маршалированными объектами, оркестровка сервисов, проектирование для повторного использования проще, услуги ориентированы на бизнес, а не на ИТ, бизнес-услуги различаются по размеру (широкий охват)

• SOA (для интеграции) по сравнению с интеграцией корпоративных приложений (EAI) o Сходства: лучшие практики (четко определенные интерфейсы, стандартизированные схемы, архитектура, управляемая событиями), многоразовые интерфейсы, общие схемы o Различия: стандарты, внедрение и улучшенные инструменты

Читая ответы выше, мне кажется, что SOA - это то, чем разработчики (по крайней мере, хорошие) делали с первого дня.

Это также может означать «Структура массивов» (в отличие от «Массив структур»), которая является распространенной темой в параллельном (особенно SIMD) программировании, но я предполагаю, что вы имеете в виду не это!

SOA - это модное слово, которое было изобретено поставщиками технологий, чтобы помочь продавать свои технологии, связанные с Enterprise Service Bus. Идея состоит в том, что вы делаете свои маленькие островные приложения на предприятии (например, система бухгалтерского учета, система управления запасами и т. Д.), Все предоставляющие услуги, чтобы их можно было гибко организовать в `` приложения '' или, скорее, стать частью совокупного бизнеса в масштабах предприятия. логика.

По сути, это куча старых болтунов, которые почти никогда не работают, потому что упускают из виду тот факт, что причины того, почему технология является такой, какой она есть в организации, сводятся к культуре, эволюции, истории фирмы, а привязка настолько высока, что любая попытка реструктуризации технологии обречена на провал.

Послушайте выпуск подкаста Floss Weekly на этой неделе , который посвящен SOA. Описания довольно высокого уровня и не вникают в слишком много технических деталей (хотя были бы полезны более конкретные и узнаваемые примеры проектов SOA.

Традиционная архитектура приложения:

• Пользовательский интерфейс
• Неопределенный материал (реализация), инкапсулированный / скрытый за пользовательским интерфейсом

Если вы хотите получить доступ к данным программным способом, вам может потребоваться очистка экрана.

Мне кажется, что SOA - это архитектура, которая фокусируется на предоставлении машиночитаемых данных и / или API, а не на раскрытии пользовательских интерфейсов.

SOA или сервис-ориентированная архитектура - это шаблон архитектуры программного обеспечения, в котором приложения или системы создаются из базовых (и обычно распределенных) программных сервисов, которые соответствуют определенному набору характеристик, а именно:

1. Интерфейс, политика и договор на основе
2. Прозрачность местоположения
3. Автономный
4. Аннотация
5. многоразовый
6. наборный
7. Stateless
8. Видимый
9. растяжимый
10. Слабо связанный

Основная цель SOA - гибкость разработки программного обеспечения, то есть возможность легко и дешево реагировать на изменения, что позволяет предприятиям быстро реагировать на меняющиеся рынки.

Сервисы обычно (но ни в коем случае не исключительно) реализуются как веб-сервисы, т. Е. Они работают по широко распространенному веб-протоколу HTTP и реализуются либо с использованием протокола SOAP на основе XML, либо с использованием облегченной (и более популярной) парадигмы REST.

Зависит от того, кто ты!

Если вы владелец бизнеса, SOA - это решение для увеличения ваших доходов и гибкости бизнеса. Если вы архитектор промышленного предприятия, SOA - это способ нарисовать красивую и чистую программу на чистом холсте. Если вы архитектор, SOA - это решение для разработки слабосвязанных сервисов на платформе интеграции, чтобы просто подключить сервисы к розеткам. Если вы являетесь разработчиком, SOA - это парадигма программирования, в которой служба находится в центре дизайна и кода.

Вы должны прочитать 100 вопросов по SOA» [pdf]

ура

Сервисно-ориентированная архитектура (SOA) - это стиль архитектуры программного обеспечения, в котором приложения создаются как набор подключаемых частей, каждая из которых может быть повторно использована другими приложениями.