приложение полностью SOA?

Question

Разумно ли создавать большие приложения, полностью основанные на SOA?Или только некоторые порции?Вход в учетную запись пользователя, учет, ГИС, продажи и т. Д.?

Другими словами, было бы разумно создать графический интерфейс для такого приложения в HTML и Javascript, который выполняет все свои обмены через ajax с веб-службами .NET на серверной части?

Не вижу смысла терять все функции .net .aspx, такие как проверка подлинности форм, состояние просмотра и т. Д. Но мой коллега говорит, что если мы собираемся перейти на SOA, в этом нет необходимости.NET на переднем конце.Но я думаю, что должен быть какой-то баланс.Где вы проводите черту?Должны ли все обращения к базе данных проходить через веб-сервисы?

Answer 1

Я просто хочу сказать, что «с SOA мы строим для перемен, в то время как с традиционной системной инженерией мы строим для стабильности».

Проблема со стабильностью, конечно же, заключается в том, что дело идет только до бизнеса - если организации требуется гибкость бизнеса, тогда им гораздо лучше внедрить SOA.

Итак, это зависит только от того, чего вы хотите достичь, именно вы должны провести границу.

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

---

EDIT:

Тем временем я наткнулся на эту статью и подумал поделиться с вами. Это видео объясняет текущий сценарий SOA и его взгляды разных людей.

Answer 2

Это сервис-ориентированная архитектура, а не архитектура, исключающая сервис.

Логика представления и слесарное дело должны где-то жить;все зависит от того, где он имеет смысл.

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

Если вы используете состояние сеанса (или период веб-служб), вы, по сути, все равно используете ASP.Net.Попробуйте удалить его и посмотрите, работают ли ваши веб-службы.

Если логика представления должна работать на стороне сервера, лучше использовать среду, предназначенную для представления, а не веб-службу, IMO.Если вы еще не смотрели MVC 2, сделайте это.Это невероятно упрощает настройку приложения, которое поддерживает браузер и серверный пользовательский интерфейс (например, средства проверки jQuery, поддерживаемые проверкой на стороне сервера).

И наоборот, веб-браузер предоставляет выразительную платформу.Предполагая поддержку браузера и командное знание, архитектура AJAX / SOA, которую вы описываете, является хорошей.Я использую его все больше и больше и пытаюсь сделать свои страницы сервера чище и проще, но у меня нет планов исключать ASP.Net из моего набора инструментов в ближайшее время.

Answer 3

Мне вспоминаются слова песни «Если бы у меня был молот». SOA - это архитектурный подход для разработки программного обеспечения как серии сервисов.На мой взгляд, это лучше всего для систем, которые имеют меньшую задержку и ограниченную пропускную способность, а также высокую стоимость доступа и т. Д. (Все они, очевидно, очень субъективны).Вам не нужна полная SOA, просто ослабьте связь между компонентами, и я бы сказал, что это хорошая цель для достижения.

Вызовы БД могут проходить через службу, например, использовать службы данных ADO.NET, однако вам действительно нужно взвесить, с какой услугой она должна работать.Возьми кеширование.Приличный подход к SOA учитывает необходимость кэширования данных для снижения нагрузки на сервис.Так могут ли ваши данные устареть в пользовательском интерфейсе?Вы разрешаете этот вариант использования?Правильно, если информация для входа устарела (грубый пример, который я знаю, но, возможно, нужно обратиться к ).

В общем, все зависит.Я думаю, что некоторые вещи хорошо поддаются SOA.Если вы используете подход DDD , то сервисы, представляющие домены, вероятно, сделают это.Таким образом, ваш пользовательский интерфейс взаимодействует с доменными службами, а не со строками в таблице, поскольку БД абстрагируется от доменных служб.

Не используйте одну методологию для решения всех проблем.

См. Этот ТАК вопрос тоже

Answer 4

Реализация клиента должна быть полностью отключена от внутреннего веб-сервиса в SOA.Услуга должна быть в состоянии потребляться любым клиентом.Если вы используете .NET на внутреннем и внешнем интерфейсах, потому что они могут быть закодированы для прямой связи, то вы упускаете суть, потому что теперь они тесно связаны, и теперь у вас есть приложение печной трубы.Клиент не должен иметь представления о том, как реализована серверная часть - не должно иметь значения, построен ли внутренний веб-сервис с использованием .NET, Java или чего-либо еще.

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

Звучит так, будто вы действительно спрашиваете, как создать одно приложение.Смысл SOA заключается в предоставлении стандартных наборов данных через интерфейсы многократного использования, которые не имеют в виду конкретного приложения или реализации.Начать создание единого приложения со всем бэкэндом, состоящим из сервисов SOA, было бы огромным делом.В уме MY каждая внутренняя служба должна быть построена из-за ее внутренней ценности и предоставлена ​​всему SOA-домену.Затем, когда вы или я решите сделать клиента, который выполняет X, Y и Z, мы можем просто найти эти возможности в SOA и нанести им вред.