Pull to refresh

Comments 6

Конечно есть альтернатива в виде
перечень потеряли.
Если про SOA через SOAP WebServices

> Трудно реализовать асинхронное взаимодействие между сервисами

поясните в чем трудность?
можно делать через Callback WSDL а можно (и более правильно) через очередь + ESB

> Сложно и трудоемко реализовать ответы в «реальном времени», потому что XML дает надежность, а не скорость.

Смотря что подразумевать под «реальным временем». Если говорить про Java то проекты Axis2, Apache CXF добавляют довольно небольшие накладные расходы связанные с SOAP. Конечно все относительно и зависит от требований.

Если про REST

Проблема с REST в том что нет стандартизированного (= общепринятого) способа описания сервисов (аналога WSDL)
Кто во что горазд (например есть «раздутый» Swagger). Нет возможности создать быстро клиента на основе опубликованного сервиса.
Для каждого REST API надо писать своего клиента.

Модернизация старых решений

По моему мнению правильным является сделать так 1) «обернуть» Legacy систему в SOA 2) сделать чтобы все взаимодействие с ней было через SOA 3) заменить или переписать систему не трогая сервисы т.о. связанные системы затронуты не будут.
Перед глазами такая вот Legacy корпорация, чего там только нет — начиная от Кобола и заканчивая Hadoop. Да, SOA тоже есть, но подавляющее большинство приложений написано 15+ лет назад и заняты тем, что пишут файлы друг другу. Работа, конечно, идет, но конца и краю этому не видно — лет на 20 еще хватит (а тогда уже и SOA устареет)
SOA как таковая вообще бесполезна. Есть база данных или даже несколько. Базы данных — это наше все. Как они соединены через скольких посредников — это уже тема интеграторов. Многие вообще используют DBLink и радуются. Многие обмениваются файлами, обычно ночью.

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

Технологии и их интеграция — не проблема. Webservices — не единственная кроссплатформенная технология. Есть CORBA, к базе данных есть коннекторы практически к любой платформе. Передать и получить данные не пробема — хоть через MQ, хоть через Socket, хоть через email. Нет коннектора — сделай shared directory. Файлы умеют читать все.

Подталкивает к слабосвязанным системам, помогает работать со старыми системами.

Сомнительная помощь, просто еще один посреднеческий уровень. Системы среднесвязаны на уровне контракта. SOAP/Http еще и подталкивает к сильной связанности, т.к. binding и адрес сервиса жестко прописывается в самом WSDL. Конечно, это можно (и нужно) обойти, но есть кадры, которые для этого меняют IP в hosts, а для импорта WSDL требуют задеплоить и запустить сервис.

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

Теория. На практике каждый WSDL делается и затачивается практически для одного потребителя.

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

Опять теория. Для доступа к базе данных между разными вызовами WS отсутствует целостность (кто-нибудь пробовал поднять транзакционный WS? это адище!). Фактически в большинстве случаев компоновка продьюсер-консумер 1:1. Особенно, если вы используете очереди JMS.

Делает возможным сокращение расходов, связанных с поддержкой решения.

Ложь и провокация! Придется оплачивать недешевый дополнительный уровень с комадной бестолковых бездельников. Использование SOA само по себе создает новые проблемы, которых бы не было без нее, начиная от постоянных ошибок в меппинге данных и кончая сложными отказами SOA-продуктов, за которыми приходится стучаться в службу поддержки. Один из недостатков SOA — огромные ресурсозатраты при сомнительном выигрыше. Решения SOA стоят занебесных цен (Oracle SOA Suite, IBM Websphere Business Integration). Специалисты по этим системам стоят дороже, нежели core-разработчики. Разработка, как ни странно, усложняется в разы, а тестирование систем — в десятки раз. Плюс, все решения глючные, неповоротливые и черезмерно навороченные.

Можно разработать стандартный протокол общения между системами.

Есть такой велосипед. Обычно добавляют хидеры для роутинга сообщения и адрес для callback. Однако всегда есть очень дорогой и понтовый «legacy систем», который будет класть на весь ваш SOA и протокол общения.

Доступ к данным не зависит от географии пользователя, можно использовать мобильные средства связи

SOA не предназначена для фронтендов. Это корпоративная архитектура. Для фронтендов обычно делают легкий бекенд.

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

Вырезка из PowerPoint презентации… Что мешает делать это без SOA?
SOA не предназначена для фронтендов. Это корпоративная архитектура. Для фронтендов обычно делают легкий бекенд.


Можно поподробнее??? Как быть если фронт системка должна данные получать из других систем/пинать их?

С остальным более-менее согласен… Вот только базы данных это некая условность… А dblink и ему подобные вообще не поддерживаемое решение.
Обычно для фронтенда (под ним мы понимаем удаленного пользовательского клиента) делают бекенд, с которым он будет эксклюзивно общаться по специально заточенному для этого клиента интерфейсу. А уже бекенд в свою очередь разруливает запросы по корпоративным системам. Более того, чтобы ускорить работу и не напрягать системы бесполезными запросами, (коих больше 95%) зачастую бекенд содержит кеш всех требуемых клиентом данных, который обновляется асинхронно через месседжи. То есть по сути бекенд содержит копию данных корпоративных систем, зачастую в денормализированном виде.

Клиенты, которые сами ломятся в несколько корпоративных систем за данными, могут быть использованы только внутри корпоративной сети, и то редкость. Выставлять «наружу» пол корпорации чревато проблемами security.
Sign up to leave a comment.