Веб-служба против обмена сообщениями для получения данных представления - PullRequest
1 голос
/ 29 декабря 2011

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

Я могу добиться этого, создав простой веб-сервис, например, с использованием REST или SOAP, возвращая внешнийДанные приложения в представлении путем доступа к базе данных внешнего приложения.

Я могу добиться этого также с помощью обмена сообщениями с шаблоном запрос-ответ.

Это то, что я до сих пор собирал с учетомвопросов масштабируемости и доступности.Пожалуйста, исправьте меня, если я ошибаюсь.

С подходом RESTful:

  1. Я могу себе представить, что архитектура REST без сохранения состояния легко масштабируется так же, как веб-серверы, которые можно кластеризовать,чьей пропускной способностью можно управлять (например, сколько потоков обслуживать и т. д.), но я думаю, что узким местом станет доступ к базе данных.

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

С подходом обмена сообщениями:

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

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

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

Пожалуйста, поделитесь своими мыслями.Спасибо!

1 Ответ

0 голосов
/ 07 января 2014

http://blogs.msdn.com/b/nickmalik/archive/2005/04/14/408328.aspx

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

...