Когда использовать SOA [закрытая] (Сервис-ориентированная архитектура)
Стоит отметить, что выживание моделей ввода vi отчасти обусловлено его принятием в стандарте POSIX, поэтому, потратив время на обучение, вы гарантированно сможете работать в любой системе, соответствующей этим стандартам. Так что, как и в английском, есть власть в повсеместном распространении.
Что касается альтернатив, я сомневаюсь, что редактор альтернативной модели переживет 30-дневный бесплатный пробный период, поэтому это та же самая причина, по которой больше людей управляют автоматикой, чем мухами.
9 ответов
Мы предоставляем сервисы нашим клиентам, потому что они не должны иметь возможность напрямую подключаться к источнику данных.
Мы предоставляем сервисы самим себе, потому что их легче распределить по различным технологиям с помощью WCF.
Мы предоставляем сервисы, потому что у нас разные пользовательские интерфейсы для одного и того же источника данных. А когда мы пользуемся услугами, мы экономим треть работы.
И не только из-за асинхронных действий.
Другой случай использования сервисов - это когда вы хотите интегрировать гетерогенный технологический стек.
Другими словами, если ваша БД - это postgres, но у вас есть код на Java, Perl, Python и C ++, вы можете писать хранимые процедуры и каждый язык программирования вызывать их. Если вы работаете с БД, в которой нет сохраненных процессов, или вы хотите иметь возможность их отключить - или вы просто хотите запустить порт 80, вы можете обернуть вызовы SQL в сервис-ориентированный уровень (представьте себе веб-сферу), который теперь может быть вызван кем угодно - плюс вы можете поместить логику аутентификации и авторизации (подключиться к LDAP, что угодно) на уровне SOA.
Вы можете также используйте этот уровень SOA, чтобы, скажем, создать логическую процедуру для «работы» с этим старым ящиком COBOL в углу, который управляет счетами или создает отчеты для клиентов.
Итак, если у вас есть несколько устаревших систем, вы хотите соединить - скажем, систему продаж с системой складирования и системами прогнозирования заказов - SOA может быть одним из способов достижения этой цели. (Вы также можете использовать «служебную шину» для создания системы, управляемой событиями, чтобы лучше организовать изменения.)
Говорю только я.
что угодно) на уровне SOA.Вы также можете использовать этот уровень SOA, чтобы, скажем, создать логическую процедуру для «чего-то» с этим старым ящиком COBOL в углу, который управляет счетами или создает отчеты для клиентов.
Итак, если у вас есть несколько устаревших систем, которые вы хотите соединить, - скажем, систему продаж, систему складирования и системы прогнозирования заказов, - SOA может быть одним из способов достижения этой цели. (Вы также можете использовать «служебную шину» для создания системы, управляемой событиями, чтобы лучше организовать изменения.)
Говорю только я.
что угодно) на уровне SOA.Вы также можете использовать этот уровень SOA, чтобы, скажем, создать логическую процедуру для «чего-то» с этим старым ящиком COBOL в углу, который управляет счетами или создает отчеты для клиентов.
Итак, если у вас есть несколько устаревших систем, которые вы хотите соединить, - скажем, систему продаж, систему складирования и системы прогнозирования заказов, - SOA может быть одним из способов достижения этой цели. (Вы также можете использовать «служебную шину» для создания системы, управляемой событиями, чтобы лучше организовать изменения.)
Говорю только я.
У вас есть ряд унаследованных систем, которые вы хотите соединить - скажем, систему продаж, систему складирования, систему прогнозирования заказов - SOA может быть одним из способов достижения этой цели. (Вы также можете использовать «служебную шину» для создания системы, управляемой событиями, чтобы лучше организовать изменения.)Говорю только я.
У вас есть ряд унаследованных систем, которые вы хотите соединить - скажем, систему продаж, систему складирования, систему прогнозирования заказов - SOA может быть одним из способов достижения этой цели. (Вы также можете использовать «служебную шину» для создания системы, управляемой событиями, чтобы лучше организовать изменения.)Говорю только я.
SOA можно использовать как способ скрыть детали реализации ваших подсистем. Например, если вашим клиентам нужна информация о продукте, вероятно, неплохо было бы объединить базу данных продуктов или подсистему инвентаризации в общую услугу и предоставить только часть функций и данных, которые нужны вашим клиентам. Затем, если вам когда-либо понадобится заменить или обновить эту подсистему, вы сможете сделать эти изменения прозрачными для ваших пользователей и вашего программного интерфейса, ориентированного на клиента.
Другим сценарием может быть сценарий интеграции, когда вы хотите, чтобы многие отдельные компоненты или системы взаимодействовали друг с другом.
для интеграции различных технологий с доступом к одним и тем же ресурсам; для достижения определенного уровня изолированности транзакций от этих различных технологий; чтобы одна бизнес-логика была записана в одном месте (чтобы не было ночных кошмаров при изменении этой логики) ...
Существует множество сценариев, в которых вы бы выиграли от использования служб. Некоторые из этих сценариев были систематизированы отраслевыми гуру (например, Томасом Эрлом, известным в области SOA).
Я бы сказал, что вы хотите найти:
- Повторное использование устаревшего приложения
- Повторное использование бизнес-процессов ( несколько вариантов использования одного и того же процесса)
- Абстракция реализации (платформа, язык, абстракция персистентности)
Ваш коллега прав, когда проявляет осторожность. С внедрением веб-служб появилось множество переменных развертывания и поддержки.
Смысл SOA, который телекоммуникационные компании (ИМХО), похоже, воспринимают как спасательный круг, заключается в том, что системы с поддержкой SOA позволяют вам использовать унаследованные и укоренившиеся технологии и представлять их как согласованные, управляемый API, который позволяет вашим бизнес-пользователям разрабатывать новые и ранее не продуманные идеи без необходимости перестраивать все в компании.
Имея унифицированный язык (WSDL) в качестве интерфейса, вы можете подготовить свои технологические разрозненные хранилища для взаимодействие. Внедряя SOA сейчас, вместо прямого обращения к источнику данных, вы автоматически делаете свои источники данных потребляемыми сторонами и потребностями бизнеса, о которых вы никогда не задумывались.
Наконец-то WSDL - это работающая Корба.
WSDL и SOAP обычно страдают от той же проблемы, что и CORBA и DCOM: управление версиями контрактов - это кошмар. Это не такая большая проблема в случае дегенерации, когда у вас есть полный контроль над всеми клиентами и серверами, но это становится некрасивым, когда вы начинаете объединять системы, тем более, когда вы переходите на межкорпоративный уровень.
мы почти вынуждены использовать какой-то подход к архитектуре, управляемой событиями, вместо типичной модели взаимодействия SOAP-as-RPC. Это не обязательно означает использование ESB, но просмотр соединений между предприятиями как соединений между ESB очень полезен.
Даже тогда полагаться на SOAP как на транспорт становится некрасиво. Вам не только необходимо обеспечить двунаправленное взаимодействие с использованием противоположных веб-служб, но вы все еще столкнетесь с проблемой управления версиями. Часто методы SOAP сводятся к банальным оболочкам вокруг «блобов», определенных иначе (например, отдельные схемы XML).
Есть ответы, но они никогда не просты. Лучшие практики управления версиями Web-сервисов обсуждают некоторые из них.
Но SOA вообще не предполагает асинхронности. Это просто разумный способ реализации SOA. SOA - это слабая связь. Подмножество SOA EDA посвящено разъединению, которое идет дальше.
Я бы использовал SOA в системе, которая будет расширена во времени внутри организации и, возможно, в других организациях.
Для продуктов, которые могут измениться, тоже неплохо, вы можете заменить маленькие части.
В конце вы получите множество лего-кирпичей, которые вы объедините вместе.