Какую роль должны играть веб-сервисы на веб-сайте?

Question

Я создаю веб-сайт, который включает в себя элемент управления, который будет использовать много данных.Поэтому я подумал сделать это через веб-сервис, чтобы улучшить масштабируемость - так я смогу использовать другой сервер для этой цели.Это хорошая идея?Если так, где это останавливается?Почему бы не иметь веб-сервисы вокруг и очень «тонкий» веб-сайт?Какие плюсы.и минусытого, что?Я не понимаю цель веб-сервисов?

Answer 1

Богатые Интернет / интранет-приложения, работающие в браузере, с красивыми виджетами для презентаций, сегодня довольно распространены. Большинство серьезных компаний, с которыми я сталкиваюсь, по крайней мере, хотят получить некоторую степень RIA в своем веб-присутствии.

Итак, AJAX, Flash и т. Д. Очень широко используются. Такие приложения должны получать данные, которые они отображают, откуда-то, и обычно это фоновый (часто используемый термин асинхронный) сервисный вызов. Часто это вызов службы REST, но это также может быть и традиционный вызов службы на основе WSDL.

Так что я бы сказал:

1. Логическое разделение логики представления и бизнес-логики - это хорошо.
2. В случае с RIA совершенно естественно отделить бизнес-логику от уровня, отличного от представления, когда последний находится в браузере.
3. Аргумент масштабируемости, который вы приводите, - одно из преимуществ этой архитектуры. В мире приложений Java EE такое масштабирование выполняется вполне естественно.
4. В тех случаях, когда вход в презентацию выполняется на том же уровне, что и бизнес-логика, вы можете обнаружить, что затраты на сериализацию веб-служб весьма заметны, и, следовательно, вы можете вместо этого использовать простые вызовы процедур.

Answer 2

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

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

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

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