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

Question

Мой проект - преобразование устаревшего настольного приложения толстого клиента в Интернет. База данных не изменяется в результате. Следовательно, мы вынуждены вызывать внешние веб-сервисы для доступа к данным в нашей собственной базе данных. Сопоставьте это с тем фактом, что некоторым частям нашего приложения разрешен доступ к базе данных напрямую через DAO (это намного быстрее и проще). Функциональность, для которой мы должны вызывать веб-сервисы, - это то, что считается необходимым для нисходящих зависимых систем.

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

Answer 1

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

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

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

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

Answer 2

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

Я согласен с @ ewernli
Что такое SOA "на простом английском"?

ИМХО, SOA имеет смысл только на уровне предприятия и ничего не значит для одного приложения.

Если я правильно читаю ваш вопрос, ваши веб-сервисы предназначены для данных C / R / U / D в базу данных. Если это так, , предоставляющее сервисы C / R / U / D непосредственно базе данных и ее таблицам, вероятно, слишком низкий уровень для сервисов SOA.

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

Answer 3

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

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

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

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

Выполните в Google поиск анти-паттернов SOA, и вы найдете различные способы получить кучу веб-сервисов вместо SOA.

Answer 4

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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