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

В принципе, оба эти подхода аналогичны разработке ISAPI-фильтра для сервера Internet Information Server; могут выполняться одновременно несколько фильтров, и запрос дескриптора передается первому из фильтров, критерии которого согласуются с поступающими запросами. (Например, в случае ISAPI-фильтров запросы Web-страницы *.ASP маршрутизируются на один дескриптор, а запросы Web-страницы *.ASPX — на другой, исходя из расширения файла.) Создание ISAPI-фильтра для Internet Information Server — задача нелегкая, требующая тщательного проектирования и тестирования. Точно так же как почти никому из Web-разработчиков не требуется использование собственных ISAPI-фильтров, создание собственных SMS-поставщиков или компонентов IMailRuleClient может понадобиться разработчикам мобильных приложений лишь в редких случаях. Тем не менее, если на первый план выходит гибкость, ее необходимо обеспечивать именно таким способом.

• SMS-поставщики 

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

Более подробную информацию относительно создания SMS-поставщиков вы сможете найти в справочной документации по Smartphone SDK, проведя поиск по термину "SMS Provider" или просмотрев раздел "Short Message Service" комплекта справочной документации "Smartphone Adaptation Kit for Mobile Operators".

• IMailRuleClient

Для устройств Smartphone 2003 и более поздних моделей можно реализовать и зарегистрировать компонент, реализующий интерфейс IMailRuleClient. Этому высокоуровневому, по сравнению с созданием SMS-поставщика, подходу следует отдавать предпочтение, поскольку он ориентирован на разработчиков приложений, а не на операторов сетей мобильной связи, выпускающих телефоны.

Интерфейс IMailRuleClient позволяет компоненту проверять входящие SMS-сообщения и отвечать на них. Такой подход может оказаться более легким в реализации по сравнению с написанием кода собственного SMS-поставщика, но для этого необходимо еще, чтобы компонент был подписан разрешенным криптографическим ключом, если этого требует изготовитель телефона. Более подробную информацию относительно интерфейса IMailRuleClient вы сможете найти, проведя в оперативной справочной документации MSDN поиск по ключевым словам "IMailRuleClient" или "CEMAPI". 

2. Использование CEMAPI для высокоуровневого доступа к SMS-сообщениям

Интерфейс CEMAPI предлагает высокоуровневый механизм доступа к текстовым SMS- сообщениям, которые были маршрутизированы на почтовый ящик смартфона. CEMAPI предлагает набор интерфейсов для навигации по хранилищу сообщений устройства, а также создания и просмотра сообщений. Ваше мобильное приложение может периодически опрашивать папку входящих сообщений устройства с целью проверки того, не поступили ли новые сообщения, предназначенные для этого приложения. Для получения более подробной информации относительно порядка работы с папкой входящих сообщений Pocket PC или смартфона выполните в комплекте справочной документации Smartphone SDK поиск по ключевому слову "CEMAPI".

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-служб будут интенсивно расширяться и развиваться. Инструментальные средства программирования и каркасы, использующие все преимущества этих стандартов, будут, как правило, отставать от вновь возникающих стандартов примерно на несколько лет.