Термин «Сервис-ориентированная архитектура» стал бессмысленным жаргоном? [закрыто]

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

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

Кажется, что почти любое приложение может быть определено как SOA, особенно веб-приложение. Попал ли этот термин в ловушку «Web 2.0» и стал ли он термином, означающим то, что вы хотите, чтобы он значил?

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

Я полагаю, что первоначальный смысл SOA был основан на сервисах с четко определенными интерфейсами, которые можно использовать программно . Основное внимание было уделено интерфейсам обслуживания, а не терминалам пользовательского интерфейса, коммуникациям или базам данных. Ключевой частью были услуги, потребляющие другие услуги. Служба A может позвонить в Службу B, получить результат и позвонить в Службу C или D. Вы можете иметь набор специализированных служб и разработать из них решение, комбинируя их таким образом, чтобы решить проблему клиента.

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

Термин определенно потерял часть своего значения. В организации, где я работаю, термин SOA часто используется взаимозаменяемо с SaaS и относится к команде ИТ-специалистов ( информационных технологий, а не разработчиков программных продуктов ), которые настраивают серверы и маршрутизаторы и устанавливают программные продукты для работы на них. Некоторые из них имеют названия, такие как «SOA Architect», но ни один из них не имеет ничего общего с архитектурой, проектированием, внедрением или тестированием программного обеспечения.

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

1. Обнаруживаемая безголовая программа ...
2. Это использует подключение без сохранения состояния (аля HTTP) ...
3. Общение в независимых от платформы форматах

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

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

Строгие определения SOA далеко за пределами линии затрат / выгод, во многих случаях являются теоретическими.

Если ваш продукт не является самими услугами, вам часто нужна другая точка зрения.

ПОЛЕЗНОЕ определение SOA означает, что ваша общая архитектура удобна для обслуживания. Система, построенная полностью из атомарных сервисов, обычно не является правильным планом, и некоторые сервисы будут организованы функционально, в то время как другие будут нести единоличную ответственность. У меня могут быть черные ящики, у меня могут быть автономные процессы, но если есть обнаруживаемая коллекция служб, с помощью которых я могу получить значительный объем выполненной работы, что является моим минимальным определением.

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

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

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

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

Но руководство хочет "SOA" !!! Таким образом, они купили действительно дорогие серверы у какой-то крупной компании, на которой поверх предыдущих наклеек «Веб-сервис» были нанесены наклейки «SOA», которые наносились поверх предыдущих наклеек «JEE», которые наносились поверх .... вы поняли. И как результат, мы, как разработчики, бездельничаем перетаскиванием крошечных значков вокруг экрана, чтобы создать «СОА» «КОМПОНЕНТЫ», которые работают наполовину так же, как если бы мы делали это с помощью чего-то простого, такого как bean-компоненты EBJ3, компоненты Spring и т. Д. ,

Так что мой совет: если вас спросят о SOA, скажите: «Да, я сделал SOA, я написал много систем, которые используют сервис-ориентированную архитектуру для выполнения задач. О какой технологии SOA вы спрашиваете?». И если они начинают говорить с горящими глазами и задумчивым взглядом о SOA-компонентах, DRAG AND DROP и о том, как это облегчает разработку. Медленно отступайте и избегайте зрительного контакта!

Я думаю, что это может иметь смысл: во-первых, когда у вас есть «ведомые» модули, вызываемые по мере необходимости, а во-вторых, когда у вас есть процессы service / daemon, работающие независимо и отвечающие на ваши запросы, возможно, общающиеся друг с другом, живущие своими собственная жизнь другими словами. При таком подходе вы можете получить огромную, масштабируемую, физически распределенную систему. Например, я видел кое-кого в области мобильной телефонии. Но это всего лишь предположение.

(Теперь давайте посмотрим, что Википедия говорит о SOA ... Вау.)