Как на самом деле должна быть реализована архитектура SOA?

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

Я согласен с @ewernli
Что такое SOA на простом английском языке?< /а>

Я согласен, что это неправильный подход. Вызов собственной базы данных через веб-службу должен вызвать подозрение при анализе проекта, поэтому лучше использовать простой DAO (принцип KISS).

Теперь, если это данные, которыми действительно необходимо обмениваться в вашей компании (учетные записи, выставление счетов и т. д.), ТОГДА пришло время рассмотреть более мощное решение, такое как SOAP или REST. Но ваша команда все еще может получить к нему прямой доступ, что будет быстрее.

У моей команды было то же самое с веб-службой, которую мы хотели вызвать в пакетном режиме. Вместо того, чтобы вызывать нашу собственную конечную точку SOAP, мы вместо этого настроили ее для вызова интерфейса POJO (обычный старый объект Java). Нет никаких преобразований XML или дополнительных сетевых переходов через устройство SOA.

Было бы излишним помещать интерфейс XML между уровнями MVC, когда ваша команда владеет всем приложением. Это может быть не традиционная SOA... но ИМО - это традиционный здравый смысл. ;)

Следовательно, мы вынуждены вызывать внешние веб-сервисы для доступа к данным в нашей собственной базе данных.

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

Когда вы приравниваете SOA к веб-службам, существует риск замены существующих API-интерфейсов веб-службами без надлежащей архитектуры. Это приведет к выявлению многих услуг, которые не ориентированы на бизнес.

Кроме того, ориентация на сервисы — это способ интеграции бизнеса в группу связанных сервисов. Поэтому спросите себя, использует ли организация эти атомарные сервисы для получения дополнительных преимуществ?

Поищите в Google антишаблоны SOA, и вы обнаружите, как можно получить кучу веб-сервисов вместо SOA.

SOA... SOA... проклятие моего существования именно по этой причине. Что или что не составляет SOA? Я поддерживаю продукты SOA в своей повседневной работе, и некоторые люди понимают это, а некоторые нет. SOA.. SOA — это обертывание дискретных бизнес-сервисов в XML. Службы проверки ZIP+4. Платежные шлюзы. Обмен сообщениями B2B.

SOA МОЖЕТ использоваться для отделения настольных приложений от серверных баз данных. Иногда это не имеет смысла, иногда имеет. Что почти НИКОГДА не имеет смысла, так это логика с малой задержкой и большим количеством запросов. Если вам когда-нибудь придется использовать приложение во Франции, напрямую подключенное к базе данных в Калифорнии, вы поймете, что я имею в виду. SOA в значительной степени заставляет вас разумно подходить к тому, как вы моделируете и возвращаете свои данные (посмотрите на SDO — Service Data Objects). Хотя дьявол кроется в деталях. Маршалинг данных в/из XML может быть дорогостоящим.

Хороший дизайн SOA основан на разделении поведения и данных. Я повторяю, что поведение и данные должны быть отдельными, иначе у вас будет много проблем, будь то вызовы CORBA/SOAP/REST/XMLRPC или даже старые простые вызовы в том же JVM-методе.

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

Если вы занимаетесь Java, это очень просто. Создайте POJO для объектов домена без странного поведения состояния и без странных соавторов, а затем создайте классы обслуживания с поведением. Чаще всего вы можете просто использовать свой DAO в качестве службы (я имею в виду, что у вас должен быть тонкий слой над DAO, но если он вам не нужен....).

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

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

Как вы думаете, какая часть неверна? Часть, с которой вы должны обращаться к веб-сервису, или часть, с которой вы напрямую обращаетесь к базе данных?

SOA — это скорее руководство по проектированию API, а не методология разработки. Это не просто реализовать, но награда за повторное использование часто того стоит.

См. Сервисно-ориентированная архитектура расширяет представление о веб-службах или любых технических книга по SOA. Простое объединение вызовов функций с веб-вызовом не делает его сервис-ориентированной архитектурой. Идея SOA заключается в создании повторно используемых сервисов, а затем вы создаете сервисы более высокого уровня (например, веб-сайты) путем компоновки или оркестровки базовых низкоуровневых сервисов. На самом низком уровне вы должны сосредоточиться на таких вещах, как безгражданство, слабая связанность и детализация. Современные фреймворки, такие как Microsoft WCF, поддерживают протоколы проводки, такие как SOAP, REST и более быстрые двоичные файлы.

Если ваше приложение предназначено для работы в Интернете, вам следует помнить о проблемах с задержкой в ​​сети. В традиционном клиент-серверном приложении, развернутом в локальной сети, поскольку задержка составляет менее 10 мс, вы можете обращаться к базе данных каждый раз, когда вам нужны данные, не прерывая работу пользователя. Однако в Интернете нередко бывает задержка в 200 мс, если вы используете прокси-серверы или океаны. Если вы нажмете на базу данных 100 раз, это добавит до 20 секунд паузы. В SOA вы попытаетесь упаковать все это в один документ и обмениваться документами туда и обратно, подобно тому, как налоговая подается с использованием формы 1040, если вы живете в США.

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