Соображения по поводу проектирования

Главный фактор, который влияет на производительность системы — это время ожидания при передаче по сети. Отсюда следует, что число запросов, передаваемых Web-службе или базе данных по сети, должно быть минимальным. В случае Web-службы Но-telBroker информация о резервировании для клиента хранится в наборе данных, который используется в качестве кэша, так что запрос к базе данных понадобится лишь в случае модификации базы данных. Та же ситуация реализуется и при отслеживании гостиниц и городов. Но есть и некоторые отличия, поскольку администратор может добавить новую гостиницу. Маловероятно, что это произойдет именно в тот непродолжительный промежуток времени, на протяжении которого выполняется резервирование для клиента. Конечно, такие типы данных можно кэшировать внутри самой Web-формы. А тогда вызывать Web-службу нет необходимости.
Протокол передачи гипертекстовых файлов HTTP не сохраняет информацию о состоянии сеанса (и приложения). Следовательно, не сохраняет эту информацию и протокол SOAP. Чтобы ваши приложения и Web-службы более просто масштабировались, хранимая информация о состоянии должна быть минимальной. Ведь именно в этом случае объекты (например сеансы с базой данных) можно легче объединить в пул и использовать повторно, — так что необходим меньший объем памяти, вследствие чего доступно больше ресурсов, которые могут обрабатывать большее количество запросов. Это означает, что Web-службы выступают уже не в роли полноценных объектов, а как конечные точки передачи данных. Рассматривая конкретный пример, мы еще этого не ощутили. И не удивительно, поскольку нам нужно было проиллюстрировать использование определенных технологий и способы правильного распределения функциональных возможностей, а это зависит от особенностей используемого приложения и времени ожидания при передаче по сети.
Чтобы избежать непроизводительных издержек, связанных с сетью, для кэширования информации можно использовать свойство Cache Duration Web-метода или свойство Cache класса HttpContext.