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

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

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

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

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

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

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

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