Текст книги "Программирование мобильных устройств на платформе .NET Compact Framework"
Автор книги: Иво Салмре
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 58 (всего у книги 69 страниц)
Web-службы
Промышленная поддержка Web-служб настолько обширна, что эту технологию просто невозможно игнорировать. Подобно технологиям, основанным на HTML, Web-службы создают оболочки вокруг коммерческих источников информации и предоставляют интерфейсы для доступа к ним со стороны других приложений-Web– службы позволяют приложениям обмениваться информацией с использованием общего высокоуровневого стандартизированного языка, основанного на XML.
Первоначальная задача HTML заключалась в том, чтобы обеспечить возможность связывания текстовых документов между собой в сети взаимными ссылками. Эта идея оказалась настолько плодотворной, что поверх модели представления документов были построены программные модели, сделавшие возможной динамическую генерацию документов; HTML вышел далеко за рамки первоначально отведенных для него границ. Сначала Web-службы предназначались для того, чтобы позволить различным серверам общаться друг с другом с использованием стандартного коммуникационного протокола на основе XML. Точно так же как и HTML, технологии Web-служб вышли далеко за первоначально запланированные рамки, и в настоящее время широко применяются также для связывания клиентских и серверных приложений между собой.
Вызов Web-службы приложением, развернутым на настольном компьютере, – довольно тривиальная задача. Современные настольные компьютеры большую часть времени работают, будучи подключенными к сети, и в настоящее время имеются все возможности доступа к быстродействующим сетям, обеспечивающим связь с высокой пропускной способностью и малыми временами задержек. Сфера применения Web-служб значительно расширяется за счет использования мобильных устройств, но для того, чтобы работа с Web-службами могла вестись эффективно, разработчики, настраивая мобильное приложение соответствующим образом для взаимодействия с Web-службами, должны учитывать различия в способах установки соединений, ширине полосы пропускания и временах задержки.
Очень краткое описание Web-службВ настоящее время доступен огромный объем литературы, посвященной описанию технологий Web-служб. Эта информация представлена как в виде оперативной справочной документации, так и в виде книг. Для подробного ознакомления с Web– службами я рекомендую начать с комплекта оперативной справочной документации MSDN. Вместе с тем, с целью создания определенной методологической основы для последующего обсуждения методов вызова Web-служб с мобильных устройств вашему вниманию предлагается очень краткое описание Web-служб.
Web-службы используют специальным образом форматированные XML-сообщения для передачи и получения запросов, связанных с предоставлением определенных услуг вычислительного характера. "Вызов" Web-службы – это направляемый одним вычислительным устройством другому запрос выполнения определенного вида обработки, завершение которой обычно сопровождается возвращением результата. Web– службы характеризуются следующими признаками:
■ Использование протокола SOAP. SOAP – это простой протокол доступа к объектам (Simple Object Access Protocol), являющийся диалектом XML. Наиболее распространенная сфера применения SOAP – вызов методов на сервере и получение ответных результатов. SOAP упаковывает имя затребованного метода вместе с параметрами в XML и доставляет эти XML-данные на сервер для обработки. Сервер получает запрос SOAP в форме XML, анализирует его для извлечения имени и параметров метода, после чего вызывает этот метод. По завершении обработки метода сервером результат SOAP возвращается клиенту в виде XML. Клиент анализирует возвращенные XML-данные, извлекает результаты и предоставляет их вызывающей программе.
■ Использование WSDL-документов. WSDL – это язык описания Web-служб (Web Service Description Language). WSDL-документ – это диалект XML, предназначенный для описания служб. WSDL-документ детализирует, какими методами располагает Web-служба, какие параметры принимает каждый из методов, и что собой представляют возвращаемые методами значения. В типичных случаях WSDL-документы генерируются машиной и возвращаются по запросу от сервера Web-служб. Инструментальные программные средства разработки загружают WSDL-документы с серверов Web-служб и генерируют код на стороне клиента, позволяющий упростить вызов описанных Web-служб на этих серверах. С каждой Web-службой связан ее собственный WSDL-документ.
■ Возможное использование коммуникационных протоколов HTTP и HTTPS для генерации запросов и получения ответов. Хотя с теоретической точки зрения Web-службы могут выполняться с использованием самых различных коммуникационных транспортных средств, включая простой протокол электронной почты SMTP, на практике большинство запросов Web-служб пересылаются посредством протоколов HTTP или HTTPS. Это означает, что большинство Web-служб выполняются на Web-серверов тех же видов, которые обслуживают приложения на основе HTML. Это обстоятельство особенно полезно по той причине, что запросы HTTP и HTTPS обычно пропускаются брандмауэрами, благодаря чему доступ к Web-службам оказывается столь же простым, что и доступ к Web– страницам. Если данный Web-сервер доступен вашему мобильному приложению, то возможен и доступ к Web-службам, выполняющимся на этом сервере.
В дополнение к этим базовым характеристикам Web-служб разрабатываются дополнительные слои технологии, располагающиеся поверх SOAP и WSDL, которые позволят удовлетворить запросы более сложной природы. Например, такие спецификации, как WS-Reliability и WS-Security, обеспечивают потребности в надежной доставке информации и встроенных средствах безопасности. Постоянно создаются, обсуждаются, развиваются и стандартизируются и другие спецификации. На протяжении ближайших 10 лет технологии Web-служб будут интенсивно расширяться и развиваться. Инструментальные средства программирования и каркасы, использующие все преимущества этих стандартов, будут, как правило, отставать от вновь возникающих стандартов примерно на несколько лет.
Вызов Web-служб с мобильного устройстваСпособность мобильных устройств взаимодействовать с теми же типами Web– серверов, с которыми могут взаимодействовать приложения настольных компьютеров и серверов, – это великое благо для разработчиков мобильных приложений. Любое устройство, которое может получать доступ к Web-страницам, располагает встроенными возможностями установки соединений, необходимыми для вызова Web-служб.
Одно дело – иметь возможность вызывать Web-службы, и совершенно другое – иметь возможность делать это легко. Обращаясь к аналогии, можно заметить, что загрузка HTML-документа не составляет труда, однако для визуального представления информации в виде, приемлемом для конечного пользователя, необходимо выполнить значительный объем работы по преобразованию HTML-документа. В связи с этим для облегчения работы с Web-службами предусмотрены программные библиотеки различных уровней. В порядке повышения уровня абстракции этими уровнями являются следующие:
■ Возможность выполнять HTTP/HTTPS-запросы. Теоретически, если ваше мобильное приложение способно направлять запросы Web-серверу, то оно способно также вызывать Web-службы.
■ Возможность генерировать и анализировать XML-документы. Поскольку языком общения с Web-службами является XML, способность генерировать и анализировать XML-документы значительно упрощает работу с Web-службами.
■ Возможность генерировать и анализировать сообщения SOAP. Сообщения SOAP представляют собой специальные грамматические конструкции, построенные поверх XML. Гораздо легче использовать библиотеку программ, которая позволяет вашему приложению работать на концептуальном уровне запросов и ответов SOAP, чем вручную создавать запросы и интерпретировать ответы, поступающие в виде XML.
■ Возможность автоматически генерировать прокси-код для приложений-клиентов Web-служб. Некоторые средства разработки программного обеспечения обеспечивают загрузку WSDL-документов, описывающих Web-службы, и автоматическую генерацию кода клиента Web службы, необходимого для создания запросов SOAP и анализа возвращенных ответов SOAP. Автоматическая генерация кода клиентов Web-служб упрощает вызов этих служб. Вместо того чтобы писать код для построения SOAP-запросов вручную, отправки этих запросов на серверы и анализа возвращаемых результатов, разработчики могут рассматривать запросы Web-служб как обычные вызовы методов. Например, Web-службу, осуществляющую сложение двух чисел, можно просто вызвать следующим образом:
MyWebService myWS = new MyWebService();
int result = myWS.AddTwoNumbers(2, 8);
Вся логика, необходимая для создания запросов SOAP, отправки их на сервер и анализа ответа SOAP, содержится в прокси-классе с именем MyWebService на стороне клиента Web-служб.
Все вышеописанные уровни абстракции поддерживаются в .NET Compact Framework в той же мере, что и в версии .NET Framework для настольных компьютеров и серверов. Во время написания данной книги некоторые из вышеперечисленных верхних уровней абстракции другими технологиями (например, J2ME, собственные коды) не поддерживались, но значение технологии Web-служб настолько велико, что простые процедуры вызова Web-служб, по всей видимости, будут предусмотрены почти во всех версиях программных каркасов для мобильных устройств. Вместе с тем, на развертывание сред выполнения для мобильных устройств должно уйти некоторое время (во многих случаях развертывание новых сред выполнения и библиотек должно сопровождаться внедрением нового оборудования), и если вы работаете с программными технологиями для мобильных устройств, которые в настоящее время встроенной поддержки Web-служб не имеют, то должны быть готовы к написанию дополнительного низкоуровневого кода, обеспечивающего генерацию запросов и анализ ответов.
Создание Web-службы с использованием .NET
Чтобы создать Web-службу для целей тестирования, вы должны запустить сервер Internet Information Server (IIS) либо на собственном локальном настольном компьютере, либо на сервере, доступном для тестируемого мобильного устройства. Для инсталляции IIS потребуется также наличие соответствующих серверных расширений, обеспечивающих функционирование вашего средства разработки; в конфигурировании этих расширений на IIS вам поможет инсталлятор Visual Studio .NET.
Для создания Web-службы необходимо выполнить следующие действия:
1. Запустите Visual Studio .NET и создайте новый проект C# ASP.NET Web service. Средство разработки попросит вас указать местоположение Web-службы. Указав, например, адрес http://localhost/WebService1, вы coздaдитe Web-cлyжбy на локальном компьютере, тогда как указание адреса http://MyWebServer/WebService1 приведет к созданию Web-службы с именем WebService1 на сервере с именем MyWebServer.
Результат: будет создан класс Service1, а на указанном вами Web-сервере будет развернут файл Service1.asmx.
2. Создайте в классе Service1 общедоступный Web-метод. Приведенный в листинге 15.6 код соответствует простому методу, предоставляющему себя в качестве Web-службы. Введите код в класс Service1, созданный вами на шаге 1.
3. Чтобы развернуть и запустить на выполнение проект Web-службы, нажмите клавишу
Листинг 15.6. Простая Web-служба
//Этот код следует вставить в класс Service1, содержащийся //в файле "Service1.asmx". //
//"[WebMethod]" – это атрибут метаданных, который указывает механизму Web– // службы на то, что данный метод должен быть доступным через Web
[WebMethod]
public int AddTwoNumbers(int x,int у) {
return x + у;
}
Вызов Web-службы с устройства средствами .NET Compact Framework
НА ЗАМЕТКУ
Для выполнения кода на физическом или эмулированном устройстве используется логическая машина отличная от машины разработки, даже если эмулятор и выполняется на той же физической машине, что и ваш Web-сервер, имена соответствующих машин будут разными. Вследствие этого вы не можете использовать URL //localhost/WebService1, чтобы задать с устройства местоположение Web-службы; вы должны использовать фактическое имя хост-машины (например, //myDevMachine1/WebService) так, как вызывали бы Web-службу с другого ПК.
Вызов Web-службы с устройства работает почти точно так же, как и вызов, выполняемый с настольного компьютера или сервера. Чтобы вызвать Web-службу с мобильного устройства, потребуется выполнить следующие действия:
1. Запустите Visual Studio .NET и создайте проект C# Smart Device Application.
2. Выберите в меню Project (Проект) пункт Add Web Reference (Добавить Web– ссылку). В результате этого на экране отобразится диалоговое окно, где вы можете найти Web-службу, на которую хотите сослаться. Введите URL-адрес Web– службы, которую вы создали перед этим (например, http://MyWebServer/ WebService1/Service1.asmx).
3. Перейдя в диалоговое окно Add Web Reference, введите в текстовом окне Web Reference Name (Имя Web-ссылки) текст MyTestWebService, а затем щелкните на кнопке Add Reference (Добавить ссылку). В результате этого будет загружен WSDL-документ, описывающий Web-службу, а в вашем проекте создан локальный прокси-класс, благодаря чему вы сможете легко вызвать Web-службу.
4. Поместите на форму вашего приложения кнопку и дважды щелкните на ней. В результате этого фокус ввода переместится в код обработчика событий кнопки.
5. Введите следующий код:
//Создать экземпляр локального прокси-объекта
MyTestWebService.Service1 myWebService;
myWebService = new MyTestWebService.Service1();
//Указать локальному прокси-объекту на необходимость вызова Web-службы
int sum = myWebService.AddTwoNumbers(2, 3);
//Отобразить результат вызова Web-службы!
System.Windows.Forms.MessageBox.Show(sum.ToString());
6. Запустите приложение и вызовите Web-службу.
Предыдущий пример соответствует тестированию синхронного вызова Web-служ– бы. Синхронные вызовы легко тестировать и отлаживать, но в реальных сценариях мы почти всегда предпочитаем вызывать Web-службу в асинхронном режиме. Автоматически сгенерированный класс обладает встроенными возможностями, которые позволяют это сделать. Для вызова Web-службы в асинхронном режиме следует вызвать метод myWebService.BeginAddTwoNumbers(…параметры…). Для каждого метода Web-службы в локальном прокси-классе предусмотрен метод Begin*, предназначенный для асинхронного вызова Web-службы, и метод End*, предназначенный для получения результатов этого вызова.
Трудности, связанные с использованием Web-служб на мобильных устройствахНесмотря на то что использование Web-служб на мобильных устройствах во многом напоминает использование Web-служб на настольных компьютерах и серверах, между этими двумя случаями имеются важные различия. Описанию трудностей, которые либо являются специфичными, либо проявляются в более заметной степени в случае мобильных устройств, посвящен следующий раздел.
Требуются различные варианты поддержки cookie-файлов
Cookie-файл – это порция локальных клиентских данных устройства, принадлежащая определенному Web-сайту и управляемая им. "Принадлежащие" Web-сайту данные, которые содержатся в cookie-файле, передаются на сервер вместе с остальной частью HTTP-запроса. Например, каждый из серверов www.Mywebaddress.com и www.Yourwebaddress.com может поддерживать свой cookie-файл на машине-клиенте, осуществляющей доступ к этим Web-сайтам. Если вычислительное устройство и приложение поддерживают cookie-файлы на стороне клиента, то всякий раз, когда по Web– адресу или его подадресу (например, www.Mywebaddress.com/somepath/somepath1) высылается HTTP-запрос, вместе с ним на сервер передаются и данные, содержащиеся в соответствующем cookie-файле.
Cookie-файлы часто применяются для хранения информации о предпочтительных установках каждого из клиентов Web-сайтов. Передаваемая вместе с каждым запросом информация из cookie-файла представляет интерес для сервера постольку, поскольку она избавляет сервер (или совместно действующую группу серверов) от необходимости поддерживать "состояние сеанса" на стороне сервера и облегчает масштабирование Web-приложения, позволяя ему не сохранять информацию о состоянии в промежутках времени между запросами.
Не исключено, что Web-сайт, предоставляющий информацию о погоде в вашем городе или ваши четыре излюбленные биржевые сводки, использует cookie-файлы на стороне клиента либо для хранения информации об этом в явном виде, либо для хранения уникальных идентификаторов, позволяющих серверу находить соответствующую информацию в базе данных сервера. Cookie-файлы могут быть использованы для хранения как кратковременных данных рабочего сеанса, например, "списка покупок" в Web– магазине, так и долговременных данных, которые хранятся на протяжении нескольких различных сеансов, например, информации о наиболее часто посещаемых вами Web– страницах, посвященных биржевым сводкам или прогнозу погоды. Вместе с тем, использованию клиентских cookie-файлов свойственны некоторые серьезные ограничения.
■ Cookie-файлы являются специфическими для клиента и машины. Если Web-приложение использует cookie-файлы на стороне клиента, то при доступе пользователя к данному Web-приложению с другой машины они должны создаваться заново. Это означает, что информация о предпочтениях пользователя, хранящаяся в cookie-файлах, не переходит вместе с пользователем на другую машину.
■ Использовать cookie-файлы не всегда безопасно. Web-приложения не должны хранить в cookie-файлах ценную информацию, поскольку она будет пересылаться в обоих направлениях при каждом вызове, а ее копия будет сохраняться на клиентской машине, где она становится доступной для злонамеренных хакеров через точки уязвимости на стороне клиента. Критически важная информация должна надежно храниться на сервере и передаваться в другие места лишь по мере необходимости.
■ Передаваемые cookie-файлы дополнительно занимают часть полосы пропускания. Поскольку cookie-файлы передаются с каждым Web-запросом, они используют часть полосы пропускания канала связи. При передаче по сетям мобильной телефонной связи эта дополнительная нагрузка приводит к увеличению длительности и стоимости передачи. Чем больше размер cookie-файла, тем большая часть полосы пропускания тратится понапрасну.
■ Cookie-файлы имеют ограниченные размеры. Существуют определенные ограничения в отношении объема данных, которые могут храниться в cookie-файлах.
Кроме вышеперечисленных ограничений общего характера, использование cookie– файлов при работе с Web-службами характеризуется еще одним недостатком – сложностью. Сеанс связи с Web-службой можно рассматривать как последовательность определенных запросов, передаваемых между клиентом и сервером. Часто эти запросы можно рассматривать как вызовы методов с передачей параметров и последующим получением возвращаемых результатов. Использование cookie-файлов при вызове Web-служб представляет собой второй скрытый канал связи между клиентом и сервером, и это может приводить к некоторой путанице. В листинге 15.7 продемонстрирован вызов Web-службы без использования cookie-файлов, тогда как листинг 15.8 соответствует тому же примеру, в котором вместо передачи некоторых параметров используются cookie-файлы.
Листинг 15.7. Вызовы Web-служб с передачей параметров только явным образом
//0. Установить связь
int sessionID = someWebService.LogOn(userCredentials);
//
//...Выполнение другого многострочного кода...
//
//1. Вызвать Web-службу и создать новый заказ
int orderID = someWebService.CreateNewOrder(sessionID, userInfo, productInfo);
//
//...Выполнение другого многострочного кода...
//
//2. Подтвердить заказ серверу
someWebService.ConfirmPayment(sessionID, orderID, paymentInfo);
//
//...Выполнение другого многострочного кода...
//
//3. Подтвердить адрес доставки
someWebService.ConfirmShipping(sessionID, orderID, shippingAddress);
//
//...Выполнение другого многострочного кода...
//
//4. Завершить оформление заказа someWebService.FinalizeOrder(sessionID, orderID);
Анализ этого кода не должен вызвать у вас особых затруднений. На шаге 1 создается новый заказ и возвращается новый идентификатор заказа (orderID), который будет использоваться в последующих вызовах. Этот номер заказа передается в каждый последующий запрос, поэтому вам должно быть ясно, что каждый из вызовов Web-служб может идентифицировать обрабатываемый заказ при помощи переданного ему параметра orderID.
Вместо использования явного параметра orderID эту информацию можно передавать Web-службе при помощи cookie-файла, хранящегося на стороне клиента. В этом случае клиентский код должен выглядеть примерно так, как показано в листинге 15.8.
Листинг 15.8. Вызов Web-служб путем неявной передачи параметров посредством cookie-файлов
//0. Установить связь
//Хотя этого и не видно, с сервера будет передан клиентский cookie-файл!
int sessionID = someWebService.LogOn(userCredentials);
//1. Вызвать Web-службу и создать новый заказ
//Хотя этого и не видно, на сервер будет передан клиентский cookie-файл!
//Хотя этого и не видно, с сервера будет передан клиентский cookie-файл!
someWebService.CreateNewOrder(userInfo, productInfo);
//
//...Выполнение другого многострочного кода...
//
//2. Подтвердить заказ серверу
//Хотя этого и не видно, на сервер передается клиентский
//cookie-файл, содержащий "orderID". Лихо!
someWebService.ConfirmPayment(paymentInfo);
//
//...Выполнение другого многострочного кода...
//
//3. Подтвердить адрес доставки
//Хотя этого и не видно, на сервер передается клиентский
//cookie-файл, содержащий "orderID". Лихо!
someWebService.ConfirmShipping(shippingAddress);
//
//...Выполнение другого многострочного кода...
//
//4. Завершить оформление заказа
//Хотя этого и не видно, на сервер передается клиентский
//cookie-файл, содержащий "orderID". Лихо!
someWebService.FinalizeOrder();
Приведенный выше код довольно прост, однако, о чем говорится в комментариях, имеется и второй канал связи, скрытый от программиста. Скрытые параметры передаются в обоих направлениях между клиентом и сервером посредством cookie-файлов. Этот факт является убедительным аргументом в пользу того, чтобы не использовать cookie-файлы на стороне клиента при проектировании Web-служб. Гораздо лучше передавать все параметры, требуемые для запроса Web-службы, явным образом, чем использовать для хранения этой информации непрозрачный второй канал.
Многие платформы мобильных устройств либо вообще не поддерживают клиентские cookie-файлы, либо эта поддержка существенно отличается от той, которая предлагается программными каркасами на настольных компьютерах. В частности, в .NET Compact Framework, выполняющейся на устройствах Smartphone, Pocket PC и Windows СЕ, автоматическая передача cookie-файлов вместе с запросами Web-служб не поддерживается. Если вы хотите, чтобы некоторые cookie-файлы были переданы сервером на устройство и возвращены на сервер вместе с последующим запросом, то вы должны написать код для чтения содержимого cookie-файлов из заголовков одного из ответов HTTPWebResponse и записи содержимого cookie-файлов в заголовки последующего запроса HTTPWebRequest. Для этого в случае вызова Web-служб вы должны просмотреть и изменить прокси-код Web службы на стороне клиента, автоматически сгенерированный для вас Visual Studio .NET. Эта задача ни в коей мере не является неразрешимой, но потребует от вас выполнения дополнительной работы, к чему вы должны быть готовы. В этом и состоит важное отличие в поддержке Web-служб программными каркасами на устройствах и настольных компьютерах.
Несмотря на тот факт, что использовать cookie-файлы на стороне клиента при создании Web-служб не рекомендуется, они могут использоваться некоторыми службами, например для хранения информации о входе пользователя в систему. Если Web– служба работает нормально, если вызывается на настольном компьютере, но ее вызовы с мобильного устройства заканчиваются непонятными сбоями, то не исключено, что виновником этих сбоев являются cookie-файлы. Если есть такая возможность, уточните у автора Web-службы, используются ли в ней cookie-файлы; это всегда проще, чем пытаться самостоятельно восстановить причину происходящего. Если получить эту информацию от автора Web-службы не удается, вы можете попытаться исследовать ситуацию эмпирически путем изменения политики обработки cookie-файлов на настольном компьютере; соответствующие изменения можно задать в обозревателе Internet Explorer, выбрав в меню Tools (Сервис) пункт Options (Свойства обозревателя) и перейдя в открывшемся диалоговом окне на вкладку Privacy (Конфиденциальность). Кроме того, если у вас есть желание окунуться в разработку низкоуровневого кода клиентов Web-служб, вы можете изучить набор клиентских cookie-файлов, возвращенный вместе с ответом HTTPWebResponse на Web-запрос. Если в зависимостях клиентских cookie-файлов имеются ошибки, то вы можете действовать трояким образом: 1) обеспечить поддержку Web-службой модели доступа, не требующей использования cookie-файлов, что неплохо сделать в любом случае, 2) создать Web-службу в виде оболочки на стороне сервера, которая играет роль посредника между мобильными устройствами и проблематичной Web-службой, или 3) написать для устройства собственный код, который явным образом осуществляет сборку cookie-файлов, возвращенных вместе с ответами любой Web-службы, и упаковывает их в последующие Web-запросы.
Первый вызов Web-службы часто характеризуется увеличенным временем задержки
Во время первого обращения мобильного приложения к Web-службе часто выполняется значительный объем дополнительной работы, что проявляется в увеличении времени задержки. При первом вызове Web-службы должна быть выполнена следующая работа:
1. Может потребоваться загрузка кода. Если XML, Web-служба, сеть и другие классы на стороне клиента еще не были загружены в память, то не исключено, что их необходимо будет загрузить и компилировать, прежде чем они смогут быть использованы для вызова Web-служб. Для этого потребуется определенное время которое может исчисляться несколькими секундами.
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-служб неэффективна
Хотя и можно передать Web-службе массив, состоящий из 2000 целых чисел, или загрузить с Web-службы массив данных этого же типа, никто этого не делает. Web– службы оптимизированы для обеспечения максимальной гибкости и дружественности к протоколу HTTP. По этой причине для передачи информации Web-службы используют большие объемы связанных с этой информацией текстовых данных.
Например, число 32 можно представить в виде одного байта данных 00100000. Для передачи целого числа 32 в XML-формате его необходимо представить, скажем, как
Если Web-служба должна передавать приложению большие объемы данных, то лучше всего организовать это так, чтобы она возвращала указатель на файл с двоичными данными, а не поток данных в виде XML. В качестве показательного примера можно привести Web-службу, возвращающую фотографические изображения.
Хотя Web-служба и может возвратить изображение в виде массива байтов или целых чисел в кодировке XML, гораздо эффективнее возвратить строку с URL-адресом, указывающим на двоичный файл (например, //somewebserver/someshare/somedir/somefile.jpg), который может быть загружен мобильным приложением. Именно так действуют Web-браузеры; они загружают текст в удобочитаемой форме и компонуют информацию в виде HTML-документа, содержащего ссылки на двоичные файлы изображения, которые должны быть встроены в макет. Очень важно тщательно продумывать, в каком виде следует перемещать данные, и оптимизировать этот процесс, если объемы данных велики.
