Если SOA мертв, что заменить его?

Пожалуйста, простите меня, если этот вопрос плотный.

Справочная информация. У нас есть несколько внутренних приложений, которые интегрируются в базу данных. Мы смотрим, как это сломать, и похоже, что переход к архитектуре, где каждое приложение раскрывает свои функции через службы, а не вызывает другие базы данных приложений, имеет наибольший смысл. Для меня это похоже на сервис-ориентированную архитектуру. Когда я просматриваю информацию о начале работы с сервис-ориентированной архитектурой, я вижу много разговоров по этой статье: SOA Is Dead; Long Live Services. И я также вижу это от Мартина Фаулера и Джима Уэббера: Неужели мой автобус выглядит большим в этом?.

Вопрос:

Является ли SOA мертвым или просто шум вокруг него?
Каков наилучший способ начать работу с сервис-ориентированной архитектурой, чтобы она оставалась максимально тонкой и простой?

Ответ 1

SOA - это умная идея, но огромная шумиха вокруг нее заставила людей писать "SOA NOW DEAD". Это неверно, так же, как предложение "Структурное программирование мертво, все делают ООП сейчас!" также не всегда верно: иногда структурный код является единственным вариантом, но решение должно приниматься при оценке, а не в рекламе. То же самое можно сказать и о SOA: иногда вам понадобится SOA, иногда вам понадобятся услуги.

Ответ 2

Я ничего не знаю о SOA, но обычно вижу, что эти технологии проходят цикл:

Технология выходит.
Технология настолько проклята, что все рекомендуют ее всем для всего.
Люди пытаются использовать эту технологию для всего.
Когда люди понимают, что они не могут сделать все, они злятся и публикуют, что они мертвы для своих блогов.

Я предполагаю, что SOA - это еще одна из этих технологий.

Ответ 3

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

Нынешняя реклама - облачные вычисления. Поместите все в облако.

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

Ответ 4

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

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

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

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

Ответ 5

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

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

Не кажется ли подозрительным, что одна архитектура может охватывать все потребности интеграции всего программного обеспечения на предприятии?

Ответ 6

Большинство SOA пытались тривиализировать процесс, лучше обслуживаемый менее используемым подмножеством SOA, известным как управляемая событиями архитектура (EDA).

Проблема заключается в том, что SOA была популяризирована как нечто построенное из Web-сервисов, которое может быть сложным выбором базовой технологии для внедрения SOA в первую очередь. SOAP не обязательно должен быть, но обычно используется как механизм RPC с повышенной связностью. Это не очень хорошо масштабируется даже во внутренних системах, не говоря уже о каких-либо перекрестках систем или, что еще хуже, предприятиях.

Вы можете создать EDA поверх SOAP, но обычно вы в конечном итоге получаете некоторый захват мешка специальных технологий. Асинхронные операции и веб-службы входят в некоторые возможные хаки.

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

Вы все еще можете использовать XML-полезные нагрузки и схемы, но SOAP сам по себе превращается в довольно тупую транспортную оболочку вокруг этой полезной нагрузки "blob", полностью определенной вне WSDL.

StackOverflow - это основное изолированное веб-приложение. Самым близким к SOAish может быть механизм OpenId, который он использует. Это простой клиент-сервер, а не SOA. Вы думаете слишком мало.

Ответ 7

Да, SOA мертв, но он был воскрешен, чтобы стать чем-то эфемерным - http://www.soa-manifesto.org/. Теперь все могут сказать, что они делают SOA независимо от того, что они делают, до тех пор, пока они могут провозгласить, что следуют 6 заповедям (или принципам):

Бизнес-ценность над технической стратегией
Стратегические цели по конкретным проектам.
Внутренняя совместимость с пользовательской интеграцией
Общие службы по реализации конкретных целей
Гибкость по оптимизации
Эволюционная утонченность в стремлении к первоначальному совершенству

Это для меня больше похоже на то, что любая компания, которая тратит немного больше времени и денег, делает "будущие" ИТ-решения, может заявить, что делает SOA. Это действительно хорошо.

Ответ 8

вместо SOA, почему бы не пойти на модульный дизайн, демонстрирующий функциональность через интерфейсы?

это то же самое, только менее нежелательное.

Ответ 9

"Лучший" пример SOA - это приключение BusinessByDesign от SAP. Провел много времени и ресурсов, даже начал продавать его, прежде чем заставить его работать правильно, а затем попытаться исправить/выключить его.

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

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

Ответ 10

Если вы собираетесь работать с внутренними корпоративными приложениями, их можно реализовать с помощью SOA. Если вы создаете приложение, ориентированное на веб-интерфейс (я имею в виду приложение, которое хорошо сочетается с новым открытым стеком oAuth, OpenID и т.д.), Затем замените SOA на WOA. Stackoverflow.com - пример такого зверя.

Ответ 11

Пока существуют предприятия, они будут иметь потребности в интеграции, системы всегда будут говорить. SOA представляется мудрым способом решения таких распространенных вопросов. Но, к сожалению, он игнорирует проблемы производительности. Чтобы предложить одно из возможных решений, я опубликовал статью о "Fluid Services" для использования parallelism между клиентами и серверами, используя потоковое взаимодействие как альтернативу коммуникациям, ориентированным на сообщения.

В этой статье о SOA Maganizine описывается концепция: http://www.soamag.com/I41/0710-2.php Это более практичная статья, которая также включает пример кода WCF в CodeProject: "Эксперимент по обслуживанию жидкостей для высокочувствительных, масштабируемых и многоразовых SOA-сервисов", (Извините, не могу поместить ссылку)

Ответ 12

SOA - это архитектуры, которые по своей природе распределяются. Если вы говорите только о подходе к программированию на основе интерфейса, тогда вы направляетесь к технологии на основе компонентов, например COM +, CORBA. Или что-то вроде .NET Remoting. Но если вы говорите о разработке на основе контрактов в распределенной среде, которая эволюционирует со временем и разрабатывается несколькими независимыми группами, то вы находитесь в парадигме SOA. Эти услуги должны быть распределены. Но я не говорю, что концепции SOA не могут использоваться для локальной обработки. Я говорю, что там, где он действительно нацелен, где никто другой не делает. Но опять же, SOA не заботится о таких вещах, как производительность, которая прискорбно. Потому что там, где он терпит неудачу.