Web-служба Hotel Broker (Брокер гостиницы). Соображения по поводу проектирования. Резюме.
В случае Web-службы Hotel Broker (Брокер гостиницы), сборка Hotel (Гостиница) была модифицирована таким образом, что теперь она сама играет роль Web-службы. В файле HotelWebService.asmx должна присутствовать ссылка только на класс Hotel-Broker, который реализован в сборке Hotel (Гостиница).
<%@ WebService class = "01. NetCpp.Acme.HotelBrokerWebService, Hotel" %>
В данном примере код ничем не отличается от кода предыдущей версии компонента, за одним исключением. В коде дополнительно присутствуют атрибуты, которые указывают, что его нужно преобразовать в Web-службу. Имена Web-служб должны быть уникальными. Поэтому, чтобы присвоить уникальное имя одному из перегружаемых методов GetHotels, следует использовать свойство MessageName атрибута WebMethod. Ниже приведен код, который содержится в файле Hotel.h, расположенном в каталоге CaseStudy\HotelBrokerWebServiсе.
[WebMethod(MessageName="GetAllHotels")]
[Xmllnclude(_typeof(HotelListltem))]
ArrayList *GetHotels()
{
…
}
Соображения по поводу проектирования
Главный фактор, который влияет на производительность системы – это время ожидания при передаче по сети. Отсюда следует, что число запросов, передаваемых Web-службе или базе данных по сети, должно быть минимальным. В случае Web-службы НоtelBroker информация о резервировании для клиента хранится в наборе данных, который используется в качестве кэша, так что запрос к базе данных понадобится лишь в случае модификации базы данных. Та же ситуация реализуется и при отслеживании гостиниц и городов.
Но есть и некоторые отличия, поскольку администратор может добавить новую гостиницу. Маловероятно, что это произойдет именно в тот непродолжительный промежуток времени, на протяжении которого выполняется резервирование для клиента. Конечно, такие типы данных можно кэшировать внутри самой Web-формы. А тогда вызывать Web-службу нет необходимости.
Протокол передачи гипертекстовых файлов HTTP не сохраняет информацию о состоянии сеанса (и приложения). Следовательно, не сохраняет эту информацию и протокол SOAP. Чтобы ваши приложения и Web-службы более просто масштабировались, хранимая информация о состоянии должна быть минимальной. Ведь именно в этом случае объекты (например сеансы с базой данных) можно легче объединить в пул и использовать повторно, – так что необходим меньший объем памяти, вследствие чего доступно больше ресурсов, которые могут обрабатывать большее количество запросов.
Это означает, что Web-службы выступают уже не в роли полноценных объектов, а как конечные точки передачи данных. Рассматривая конкретный пример, мы еще этого не ощутили. И не удивительно, поскольку нам нужно было проиллюстрировать использование определенных технологий и способы правильного распределения функциональных возможностей, а это зависит от особенностей используемого приложения и времени ожидания при передаче по сети.
Чтобы избежать непроизводительных издержек, связанных с сетью, для кэширования информации можно использовать свойство Cache Duration Web-метода или свойство Cache класса HttpContext.
Резюме
Web-службы предоставляют средства, расширяющие функциональные, возможности компонентов за счет предоставления к ним доступа из любого места сети, объединяющей различные платформы и языки программирования, разработанные различными производителями. Однако в отличие от удаленной обработки данных в среде .NET, количество типов данных, используемых Web-службами, значительно меньше.
Тем не менее, если при проектировании приложения с самого начала учитывать Схему XML (XML Schema), а затем создать свой язык WSDL и классы Web-служб, то вероятность того, что созданное приложение сможет взаимодействовать с другими, значительно возрастает.