Недавно я поговорил с одним из наших архитекторов, и он подвел итоги использования SOA как "Единственный раз, когда мы будем использовать сервисы, - это когда нам нужны асинхронные действия, иначе мы будем использовать прямое обращение к хранилищу данных"
Я думал об этом утверждении, и кажется довольно логичным, поскольку службы хорошо работают в модели публикации подписки, но мне было интересно, в каких других сценариях вы должны искать SOA?
Мы предоставляем услуги нашим клиентам, потому что они не должны напрямую подключаться к источнику данных.
Мы предоставляем услуги самим себе, потому что проще распространять их по различным технологиям с использованием WCF.
Мы предоставляем услуги, потому что у нас есть разные пользовательские интерфейсы для одного и того же источника данных. И когда мы используем услуги, мы сохраняем треть работы.
Это происходит не только из-за асинхронных действий.
Другим примером использования сервисов является интеграция гетерогенного стека технологий.
Другими словами, если ваша БД является postgres, но у вас есть код в Java, Perl, Python и С++, вы можете писать хранимые процедуры и каждый язык программирования называть их. Если вы работаете с БД, которая не хранила procs, или вы хотите иметь возможность отключить их - или вы просто хотите запустить через порт 80, вы можете обернуть вызовы SQL в сервис-ориентированный уровень ( think websphere), который теперь может быть вызван кем угодно - плюс вы можете поместить логику аутентификации и авторизации (подключиться к LDAP, что угодно) на уровне SOA.
Вы также можете использовать этот SOA-слой, например, создать логическую подпрограмму, чтобы сделать "материал" с этим старым полем COBOL в углу, который управляет счетами или создает заявления для клиентов.
Итак, если у вас есть несколько устаревших систем, которые вы хотите подключить, скажем, система продаж системы складирования в системах прогнозирования заказов - SOA может быть одним из способов достижения этой цели. (Вы также можете использовать "служебную шину", чтобы создать управляемую событиями систему как лучший способ упорядочивания изменений.)
Просто я поговорю.
Существует много сценариев, в которых вы могли бы воспользоваться услугами. Некоторые из этих сценариев были кодифицированы отраслевыми гуру (такими как Томас Эрл из славы SOA).
Я бы сказал, что вы хотите найти:
Ваш коллега прав, чтобы быть осторожным. При внедрении веб-сервисов имеется множество переменных развертывания и поддержки.
Другим сценарием может быть сценарий интеграции, где вы хотите, чтобы многие отдельные компоненты или системы взаимодействовали друг с другом.
SOA может использоваться как способ скрыть детали реализации ваших подсистем. Например, если ваши клиенты нуждаются в информации о продуктах, вероятно, хорошей идеей является обернуть вашу базу данных продуктов или подсистемы инвентаризации в общую службу и выставить только часть функциональности и данных, которые нужны вашим клиентам. Затем, если вам когда-либо понадобится заменить или обновить эту подсистему, вы сможете сделать эти изменения прозрачными для своих пользователей и клиентский интерфейс программного обеспечения.
Точка SOA, которую Телекоммуникации (IMHO), похоже, хватают за жизненный путь, заключается в том, что системы с поддержкой SOA позволяют использовать устаревшие и укоренившиеся технологии и представлять их как совместимый управляемый API, который позволяет вашим бизнес-пользователям разрабатывать новые и ранее не продуманные идеи без необходимости перепроектировать все в компании.
Имея в качестве интерфейса унифицированный язык (WSDL), вы можете подготовить свои технологические силосы для взаимодействия. Внедряя SOA сейчас, вместо того, чтобы делать прямой источник данных, вы автоматически делаете свои источники данных потребляемыми сторонами и бизнес-потребностями, которые вы никогда не рассматривали.
WSDL - это, наконец, Corba-that-works.
WSDL и SOAP обычно страдают от той же проблемы, что и CORBA и DCOM: контрактное управление версиями - это кошмар. Это не такая уж большая проблема в случае с дегенератором, где у вас есть полный контроль над всеми клиентами и серверами, но он становится уродливым, когда вы начинаете федеративные системы, тем более, когда вы идете на межпредприятие.
В этот момент вы почти вынуждены использовать какой-то подход, основанный на событиях, вместо типичной модели взаимодействия SOAP-RPC. Это не означает использование ESB, но просмотр связей между предприятиями, поскольку соединения между ESB очень полезны.
Даже тогда, полагаясь на SOAP, транспорт становится уродливым. Вам не только нужно поддерживать двунаправленное взаимодействие с помощью противоположных веб-сервисов, вы все еще сталкиваетесь с проблемой управления версиями. Часто методы SOAP переносят тривиальные обертки вокруг "блобов", определенных иначе (например, отдельные схемы XML).
Есть ответы, но они никогда не просты. Рекомендации по управлению версиями веб-сервисов обсуждают пару из них.
Но SOA не подразумевает ничего асинхронного. Это просто умный способ реализации SOA. SOA - это развязка. Подмножество EDA SOA относится к де-мутации, которая идет дальше.
Существует еще одна школа смежных мыслей, которая называется SOAD (Service Orientated Application Design), каждый компонент системы является сервисом. Это должно использовать преимущества, предлагаемые средой, с которой они построены (EJB, WCF), то есть вы получаете много бесплатной сантехники.
Еще один ресурс на этом
для интеграции различных технологий, получающих доступ к тем же ресурсам; для достижения определенного уровня транзакционной изоляции над этими различными технологиями; чтобы одна бизнес-логика была написана в одном месте (так что не было бы нигтямов, когда эта логика должна быть изменена)...
Я бы использовал SOA в системе, которая будет расширена за время внутри организации и, возможно, в других организациях.
Для продуктов, которые могут измениться, тоже приятно, вы можете заменить небольшие части.
В конце у вас будет много кирпичей lego, с которыми вы будете вместе.