Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

2. Может потребоваться поиск адреса Web-службы. Например, если вызывается Web- служба по адресу www.myWebService.com, то для обнаружения местонахождения сервера этот адрес должен быть преобразован в IP-адрес (например, 200.134.81.26). Для нахождения этого адреса DNS-серверу направляется запрос на преобразование Web-адреса в IP-адрес. Выполнение этой операции требует определенного времени; запрос необходимо упаковать и переслать на DNS- сервер, после чего ваше мобильное приложение должно дождаться ответа и лишь после этого сможет установить фактическую связь с сервером, который предоставляет вызываемую вами Web-службу. Большинству мобильных устройств приходится локально кэшировать этот адрес, чтобы последующие запросы, направляемые на Web-сервер, не требовали повторного проведения поиска соответствующего имени сервером DNS. Выполнение процедуры разрешения имен требует заметного времени и может стать основной причиной задержки при первоначальном вызове Web-службы. Как правило, поиск локального сетевого имени (например, //myLocalServer) происходит быстрее, чем поиск имени во всемирной сети (например, www.myWebServer.com).

При измерении времени отклика Web-служб полезно определять две разновидности этой характеристики: 1) время отклика при выполнении первого вызова, и 2) среднее время отклика для последующих вызовов Web-службы.

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

Хотя и можно передать Web-службе массив, состоящий из 2000 целых чисел, или загрузить с Web-службы массив данных этого же типа, никто этого не делает. Web- службы оптимизированы для обеспечения максимальной гибкости и дружественности к протоколу HTTP. По этой причине для передачи информации Web-службы используют большие объемы связанных с этой информацией текстовых данных.

Например, число 32 можно представить в виде одного байта данных 00100000. Для передачи целого числа 32 в XML-формате его необходимо представить, скажем, как 32, для чего требуется уже 14 байт данных, то же самое относится и к другим типам данных. Те самые свойства, благодаря которым Web-службы и XML обретают гибкость, делают их неэффективными в смысле объема передаваемых данных.

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

Хотя Web-служба и может возвратить изображение в виде массива байтов или целых чисел в кодировке XML, гораздо эффективнее возвратить строку с URL-адресом, указывающим на двоичный файл (например, //somewebserver/someshare/somedir/somefile.jpg), который может быть загружен мобильным приложением. Именно так действуют Web-браузеры; они загружают текст в удобочитаемой форме и компонуют информацию в виде HTML-документа, содержащего ссылки на двоичные файлы изображения, которые должны быть встроены в макет. Очень важно тщательно продумывать, в каком виде следует перемещать данные, и оптимизировать этот процесс, если объемы данных велики.

Каждый запрос, посланный на сервер, означает необходимость начала, проведения и завершения диалога с сервером; следовательно, этот процесс сопровождается дополнительными накладными расходами по организации связи. Пять отдельных вызовов Web-служб, каждый из которых требует передачи одного параметра, гораздо менее эффективны, чем один запрос, содержащий пять параметров. Кроме того, учитывая прерывистый характер сеансов мобильной связи, использование пяти мелких запросов вместо одного более крупного повышает вероятность сбоя в процессе диалога между устройством и сервером. Это означает необходимость написания сложной логики, позволяющей выполнять необходимые восстановительные операции, если посередине такого диалога что-то пойдет не так. Применение одиночных вызовов Web-служб позволяет уменьшить вероятность сбоев и упростить логику восстановления связи в подобных случаях.