"Платформа J2Me" - читать интересную книгу автора (неизвестен Автор)

Глава 10. Инициализация приложений

Теперь вы знаете, как разрабатывать приложения MIDP и выполнять их с помощью эмулятора. Однако на самом деле вам нужно установить ваши приложения на реальные мобильные устройства. Мобильные устройства должны поддерживать установку приложений пользователями. Процесс, который поддерживает этот вид динамической установки приложений на портативные устройства, называется инициализацией приложений. Системы, которые поддерживают этот процесс, называются системами инициализации.

В контексте данной главы или книги термин инициализация относится к поставке программных приложений на мобильные устройства. Для беспроводных транспортировщиков и фирм-производителей (называемых OpCos), инициализация имеет совершенно другое значение, а именно, настройка атрибутов устройства и модуля идентификации станции (station identification module (SIM)) для голоса, данных и других традиционных служб.

Эта глава знакомит вас с системами инициализации приложений. Ее цель — познакомить разработчиков с понятиями, связанными с инициализацией приложений, и описать вопросы, связанные с подготовкой приложений к размещению на системах инициализации.

В этой главе вы не узнаете, как создавать или проектировать системы инициализации приложений. Системы инициализации являются комплексными корпоративными приложениями, и описание их разработки или создания лежит за пределами темы данной книги.

Производители обычно устанавливают программное обеспечение, которое вы видите на мобильных устройствах, перед тем как устройства покидают завод. Но предварительная заводская установка всего этого программного обеспечения становится все менее и менее осуществимой для производителей. Устройства не имеют достаточно ресурсов памяти для хранения и увеличения количества разнообразных приложений, которые могут потребоваться пользователям. Более того, предварительно установленные приложения никогда не смогут удовлетворить требования всех пользователей. Поэтому пользователям необходимо иметь возможность устанавливать программное обеспечение на свои мобильные устройства, как они делают это на персональных компьютерах. Эта возможность позволяет пользователям изменять имеющийся у них набор приложений в любое время, удаляя некоторые приложения и устанавливая новые для того, чтобы обойти ограниченные возможности хранения устройства.

Для того чтобы инициализировать приложения на своих устройствах, пользователям нужна возможность обнаружения, выбора, покупки, загрузки и установки приложений с помощью своих мобильных устройств. Поскольку мобильные устройства не всегда имеют возможность соединения с какой-либо сетью или другим устройством посредством каких-либо способов, за исключением радиоинтерфейса, поддерживаемого беспроводной сетью, транспортировщики должны поддерживать установку приложений MIDP «по воздуху» (over-the-air (OTA)). Во время написания данной книги инициализация ОТА являлась краеугольным камнем инициализации приложений для мобильных устройств.

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

Беспроводные транспортировщики и другие поставщики услуг, поддерживающие инициализацию приложений для своих пользователей, предоставляют системы инициализации, с которыми их пользователи могут взаимодействовать. Эти системы инициализации поддерживают инициализацию ОТА для М9бильных устройств, связанную с беспроводной сетью транспортировщика и шлюзом беспроводного Интернета (wireless Internet gateway (WIG)). На рисунке 10.1 показана одна из возможных схематичных логических диаграмм, которая отражает роль системы инициализации в сетевой инфраструктуре транспортировщика.

Инициализация ОТА требует установления «телефонного звонка», или соединения для передачи данных в сетях передачи данных, таких, как 2.5G или 3G — для соединения мобильного устройства, которое является клиентом, с инициализирующим сервером. Со стороны сервера диспетчер инициализации теоретически представляет основной компонент системы инициализации, который управляет различными стадиями процесса инициализации. Эти стадии включают динамическое обнаружение, представление описаний содержимого, поставку, фиксацию транзакции и создание счета.

На устройстве программное обеспечение агента пользователя взаимодействует с диспетчером инициализации. Программное обеспечение агента пользователя должно быть совместимо с механизмом взаимодействия, определяемым диспетчером инициализации. Возможны две схемы: обнаружение протокола Wireless Application Protocol (WAP) с HTTP-пересылкой и обнаружение WAP с сегментацией и повторным ассемблированием (SAR) WAP. Беспроводные транспортировщики на определенных рынках, особенно в Японии, создают инфраструктуры, которые поддерживают TCP/IP к телефонной трубке. Эти инфраструктуры способны поддерживать передачу HTML (XHTML) телефонной трубке посредством HTTP-транспортировки, перемещая WAP. Когда эта модель станет более распространенной в реализациях сетей 2.5G и 3G, интерфейсы диспетчера инициализации изменятся соответственно.

Рисунок 10.1. Система инициализации приложений связывается со шлюзом беспроводного Интернета транспортировщика для того, чтобы иметь возможность взаимодействовать с мобильными устройствами, которые она обслуживает

AMS устройства может иметь возможность действовать в качестве программного обеспечения агента пользователя, или, по крайней мере, быть близко связанной с микробраузером устройства. В качестве альтернативы устройства могут содержать специализированное программное обеспечение обнаружения приложений (discovery application (DA)), чья работа заключается в идентификации наборов MID-летов для пользовательской загрузки. Помимо других обязанностей, программное обеспечение DA должно быть способно размещать инициализированные приложения в месте, доступном AMS. Термин диспетчер приложения Java (Java application manager (JAM)) используется для описания AMS системам, которые поддерживают инициализацию приложений Java.

Программное обеспечение агента пользователя на устройствах-клиентах должно работать совместно с системой инициализации, чтобы иметь возможность взаимодействовать с помощью четко определенных интерфейсов через общедоступный механизм взаимодействия. Обычно беспроводные сети используют HTTP через некоторый транспортный протокол для того, чтобы устанавливать коммуникации уровня приложений с мобильными устройствами. В действительности документ «Over The Air User Initiated Provisioning Recommended Practice, Addendum to the Mobile Information Device Profile» требует, чтобы инициализация OTA поддерживала протокол HTTP. HTTP является единственным протоколом, который должен поддерживаться обязательно. Вы можете найти эту спецификацию по адресу http://java.sun.com/products/midp/. Между прочим, возможно, что рекомендации данного документа станут частью спецификации MIDP-NG (следующее поколение).

Существует три причины инициализации приложений:

для автоматизации процесса определения совместимости приложений и сред, в которые они загружаются, для предоставления возможности доставки приложений на устройства, для поддержки микромодели работы со счетами, привлекательной для разработчиков приложений MIDP при продаже ими своих продуктов.

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

Процесс инициализации основан на обмене информацией между клиентом и сервером. Программное обеспечение клиентского агента получает доступ к информации о среде клиента и передает ее диспетчеру инициализации. Программное обеспечение диспетчера инициализации представляет информацию о зарегистрированных приложениях на мобильном устройстве. Оно получает эту информацию из своего хранилища зарегистрированных приложений. Система инициализации получает доступ к определяемой приложением информации, такой, как информация, содержащаяся в файле JAD приложения или файле манифеста. Вместе клиент и сервер обмениваются информацией, договариваются о правах, привилегиях и обязанностях и сотрудничают для доставки приложений на мобильные устройства. Диспетчеры инициализации, которые контролируются OpCos, также имеют доступ к пользовательской информации, такой, как профили и настройки пользователя.

Приложения могут быть отдельными клиентскими приложениями, распределенными приложениями или приложениями клиент-сервер, которые требуют клиентской части и серверной части (компонент сетевой службы). Например, приложение может состоять из компонента, который выполняется на мобильном устройстве и взаимодействует с серверным, который запущен на сервере в сети транспортировщика или в сети поставщика услуг (например, сеть корпоративного покупателя). Дескриптором приложения может оговариваться, что серверный компонент должен быть установлен до того, как клиентский компонент будет инициализирован на устройствах. Система инициализации может определять, способна ли сетевая среда поддерживать требования приложения. Другие задачи включают определение того, как и где серверные компоненты должны быть установлены или запущены, или может ли сеть поддерживать постоянную доступность компонентов.

Приложения инициализации также включают анализ времени жизни приложения и реверсирование процесса инициализации. Некоторые приложения могут оговаривать выполнение пользователем заданное число раз или использование в течение определенного периода времени. Это может применяться для пробного программного обеспечения или для определенных типов лицензий на программное обеспечение. Приложения могут также оговаривать то, что они не должны находиться на устройствах постоянно, а вместо этого загружаться каждый раз с сервера инициализации. Сервер может проверять истечение срока использования определенными пользователями или даже определенными устройствами.

Процесс инициализации может включать выборочное удаление приложений для освобождения места под новые приложения. Поддержка этого свойства требует согласования программного обеспечения агента пользователя устройства и программного обеспечения диспетчера инициализации. Удаление приложений потребует извещения пользователя.

В настоящее время системы инициализации приложений предлагают несколько коммерческих производителей. Многие из их свойств созданы специально для поддержки инициализации приложений J2ME. То есть многие из свойств этих систем связаны с проблемами инициализации в беспроводных средах.

На практике процесс инициализации включает две основных фазы:

— регистрация приложений;

— инициализация зарегистрированных приложений на устройствах.

Первый этап, регистрация, делает приложение доступным для инициализации. Второй этап, инициализирующий зарегистрированные приложения, состоит из всех этапов, которые требуются для осуществления установки приложения на мобильном устройстве. Задачи, формирующие вторую фазу, иногда группируются в следующие три категории:

обнаружение — поиск приложения; посредничество — предоставление пользователям информации о приложении, согласование лицензии программного обеспечения, подтверждение покупки, выполнение обязательств по покупке;

загрузка — аутентификация использования, загрузка приложения, установка приложения на устройстве, подтверждение установки, удаление установленных приложений, установка ресурсов сервера, операции по выдаче счетов.

В остальной части данного раздела я просто познакомлю вас с отдельными задачами без ссылки на эти три категории.

Перед тем как приложения получат возможность инициализации на устройствах, они должны быть зарегистрированы в системе инициализации. Зарегистрированное приложение — это то, что известно системе инициализации и может быть переслано на устройство.

Процесс регистрации приложения обычно инициирует человек или организация, которая разрабатывает приложение. Однако прежде, чем разработчик сможет зарегистрировать приложение, он или она должен обычно зарегистрироваться в качестве пользователя системы инициализации транспортировщика или члена программы разработчиков транспортировщика. Система инициализации может поддерживать регистрацию разработчиков через Web с использованием Web-интерфейса, основанного на HTML. После пользовательской регистрации разработчик может загружать приложения в систему.

Обычно системы инициализации поддерживают два основных механизма управления зарегистрированными приложениями. С помощью первого подхода разработчик загружает файлы JAR, JAD и манифеста приложения, как указано системой инициализации. Система инициализации физически содержит эти элементы в своем хранилище. С помощью второго подхода разработчик просто регистрирует URL и файл JAD (или метаданные, необходимые для создания файла JAD), которые показывают местонахождение, из которого диспетчер инициализации может извлекать приложение, необходимое во время инициализации. Разработчик или даже другой поставщик может фактически хранить файл JAR приложения.

Не все системы инициализации могут поддерживать как возможность внутреннего постоянного хранения файлов JAR, так и возможность ссылки на внешние файлы JAR. Как разработчик, вы должны предусмотреть, какие схемы приемлемы и какие, по вашему мнению, соответствуют сценариям использования ваших приложений. Возникают вопросы нетехнического плана — такие, как правовые вопросы обеспечения защиты от несанкционированного доступа к вашему приложению, которое может содержать ценную интеллектуальную собственность, или соглашения служебного уровня (service-level agreement (SLA)) с покупателем или транспортировщиком.

В обязанности разработчика входит поставка всей информации в форме, требуемой системой инициализации. Во время регистрации разработчик должен предоставить всю информацию, которая необходима во время процесса инициализации. По самой меньшей мере вам нужно предоставить JAD приложения и файлы манифеста, которые содержат информацию о платформе приложения, устройстве и требованиях ресурсов исполнения. Кроме того, система инициализации может поддерживать загрузку одного или нескольких собственных файлов с целью предоставления дополнительной информации о приложении. Например, вы имеете возможность предоставить файл XML, который описывает ваши предпочтения в лицензировании, оплате покупки, методах подтверждения покупки и так далее. Можно, конечно, определить атрибуты в файле JAD приложения, который описывает эти области. Это хороший пример, который демонстрирует, почему разработчики должны знать о возможностях системы инициализации или систем, которые они используют.

Поиск приложений — это процесс, с помощью которого пользователи обнаруживают интересующие их приложения. Это первый этап процесса инициализации, в который вовлечен конечный пользователь. Большинство систем инициализации обычно предоставляют пользователям какой-либо WML-интерфейс (или XHTML) для обнаружения приложений с помощью мобильных устройств. Мобильные устройства, которые предназначены для загрузки ОТА, имеют НТТР-микробраузер, который, наиболее вероятно, будет интегрирован до некоторой степени в программное ббеспечение пользовательского агента устройства.

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

Как вы узнали в предыдущем разделе, одной из основных целей инициализации является содействие обнаружению приложений, которые совместимы со средой мобильного устройства. Диспетчер инициализации сравнивает атрибуты среды устройства с набором атрибутов приложения. Он может гарантировать, что несовместимые приложения никогда не загрузятся на устройство. При определении совместимости сред приложений и устройств среда мобильного устройства делится на следующие четыре контекста:

— пользовательский контекст;

— контекст устройства;

— контекст среды платформы J2ME;

— требования приложения.

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

При анализе контекста устройства, однако, более важно должное техническое функционирование приложений. Системы инициализации требуют информации о контексте устройства, например, о том, как много у него памяти, каковы его рабочие ресурсы и так далее. Например, если в устройстве недостаточно общей памяти для хранения набора приложений, диспетчер инициализации должен запрещать его загрузку. Если недостаточно свободного места, AMS (JAM) уведомит пользователей, что они должны освободить место для приложения, удалив какое-либо другое содержимое.

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

Анализ среды J2ME, необходимой приложению, так же важен, как и анализ родной среды устройства. Приложения, возможно, потребуют, чтобы устройство поддерживало определенную версию MIDP или CLDC. Обычно это MIDP и CLDC, под которыми приложение было разработано. Какими бы ни были определенные характеристики клиентской среды, они переносятся на сервер инициализации, чтобы использоваться в качестве параметров поиска. Система инициализации сопоставляет эти характеристики с поисковыми категориями, которые она поддерживает. Системы инициализации варьируются в своей сложности и в своей возможности использовать определенные поисковые категории.

Результаты поиска представляют собой отфильтрованное подмножество приложений, зарегистрированных в системе инициализации. Они должны содержать только те приложения, которые совместимы с контекстом клиента. По самой меньшей мере системы инициализации будут ограничивать результаты поиска в соответствии с критериями пользователя, устройства и платформы J2ME. Некоторые системы инициализации могут также поддерживать более продвинутый поиск, такой, как возможность соотносить информацию о местоположении устройства с приложениями, которые подходят для этого региона, основываясь на выполняемых функциях, наличии локализации и так далее.

Информация о среде клиента обычно посылается как HTTP-заголовки HTTP-запроса из браузера устройства диспетчеру инициализации. Агент пользователя и браузер взаимодействуют для создания HTTP-запроса, который связывается с поисковой функцией инициализирующего сервера.

В менее автоматизированных системах инициализации пользователям может понадобиться ввести значения для поисковых категорий в браузере их устройства. Система инициализации может предоставлять HTTP-интерфейс, который позволяет пользователям указывать характеристики поиска.

В более автоматизированных системах система инициализации извлекает информацию о предпочтениях пользователя из сети транспортировщика. Агент пользователя может пересылать идентификационный номер мобильной станции (MSISDN или MSN) на сервер инициализации. Если сервер инициализации поддерживает интеграцию с внешними системами, такими, как серверы каталогов, он может получать пользовательскую информацию с сервера каталогов транспортировщика. Для того чтобы этот подход работал, транспортировщик должен предоставлять пользователям возможность вносить в пользовательские записи свои предпочтения при поиске для инициализации.

Чем выше уровень автоматизации, тем более эффективным становится процесс поиска, и тем менее вероятно, что он сделает ошибку. Это важно учитывать как пользователям, так и транспортировщикам. Просмотр вручную занимает много времени и часто приводит к появлению ошибок. Вероятно, можно с уверенностью сказать, что навигация вручную и серфинг по WML-страницам (или XHTML в развивающихся в настоящее время системах) требует длительных соединений. Это следует из больших затрат на время передачи в сетях с коммутацией каналов (сети 2G) и высоких издержек при передаче пакетов в сетях с коммутацией пакетов (сети 2.5G и 3G), которые нежелательны для пользователей. Это также занимает полосу пропускания, что нежелательно для транспортировщиков.

В процессе поиска система инициализации выводит результаты поиска в список для пользователя. Система может систематизировать результаты по группам, типам устройств, поддерживаемой платформе J2ME, типу лицензии программного обеспечения, цене покупки программного обеспечения или некоторым другим категориям. Некоторые системы могут поддерживать многоуровневую сортировку, так что пользователи могут проранжировать приложения и задать организацию результатов поиска в соответствии с несколькими критериями.

В общем, важно, чтобы разработчики приложений знали о свойствах, поддерживаемых системой инициализации. Знакомство с возможностями систем инициализации дает разработчикам возможность извлекать выгоду из свойств системы.

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

Подтверждение совместимости — это процесс подтверждения совместимости приложения на основе контекстов устройства, пользователя и платформы J2ME. Все инициализирующие системы не должны позволять загрузку или даже обнаружение несовместимых приложений.

Диспетчер инициализации может проверять совместимость приложения с указанным устройством, сравнивая метаинформацию устройства и приложения. Все системы инициализации должны запрещать загрузку наборов приложений, которые несовместимы со средой указанного устройства.

В действительности проблема подтверждения совместимости является одной из причин, по которым атрибутам MicroEdition-Configuration и MicroEdition-Profile требуются атрибуты файла JAD. Система инициализации использует эту информацию при поиске совместимых приложений.

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

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

Аутентификация пользователей — это просто процесс подтверждения через агента пользователя того, что пользователь является тем, кем себя заявляет. Аутентификация пользователя требует, чтобы агент пользователя передавал информацию о пользователе диспетчеру инициализации. Обычно агент пользователя передает эту информацию диспетчеру инициализации в форме HTTP-заголовков HTTP-запроса браузера устройства. Запрос скорее всего также использует поле заголовка HTTP-запроса агента пользователя для идентификации агента пользователя.

Существуют некоторые беспроводные системы, которые не хранят много пользовательской информации на мобильных устройствах. В таких случаях сервер должен связывать пользовательскую информацию с информацией устройства — MSN устройства, например. Как описывалось ранее, системы инициализации могут взаимодействовать с другими системами транспортировщика, такими, как серверы аутентификации, серверами облегченного протокола службы каталогов (Lightweight Directory Access Protocol (LDAP)) или серверами шлюза беспроводного Интернета (WIG) для получения остальной необходимой пользовательской информации.

Процесс согласования лицензии на программное обеспечение включает предоставление пользователю условий лицензирования и подтверждение пользователем его принятия условий. Этот этап осуществляется перед загрузкой приложения. Этот этап может быть выполнен на персональном компьютере вместо мобильного устройства.

Приложения, которые оговаривают требование покупки лицензии, должны предоставлять всю информацию, требуемую для процесса согласования лицензии. Эта информация должна быть доступна системе инициализации. Зависящая от приложения информация, такая, как тип лицензии, условия лицензирования и так далее, должна быть включена в файл JAD приложения.

Загрузка приложения — это процесс физической отправки приложения на мобильное устройство. Обычно этот процесс использует HTTP-механизм загрузки и браузер устройства для получения программного обеспечения.

Более совершенные системы будут поддерживать возможность контроля загрузки пользователем. Одним из примеров пользовательского контроля является возможность перезапуска прерванной загрузки пользователем. Прерывание загрузки может случиться, например, если вызов или данные соединения не прошли. Во время написания данной книги лучшим, на что мы могли надеяться, было то, что устройство выполняет частичные загрузки.

Некоторые системы поддерживают лишь возможность перезапустить загрузку с начала. Даже в этом случае пользователю не придется проходить вновь через весь цикл обнаружения, аутентификации и покупки. Система инициализации должна поддерживать достаточную информацию о состоянии операции, чтобы позволить пользователю перейти непосредственно к этапу загрузки.

Более совершенные системы дадут пользователю возможность перезапускать загрузку из точки, на которой произошло прерывание. Это свойство предпочтительно, поскольку оно сокращает продолжительность передачи и уменьшает использование полосы пропускания. Более совершенные системы также поддерживают как небезопасную (HTTP), так и безопасную (HTTPS/SSL) загрузку приложений.

Установка приложения — это процесс установки программного обеспечения, которое уже находится на устройстве. После загрузки приложения браузер должен начать взаимодействие с AMS устройства, которая является компонентом, сохраняющим приложение на устройстве. AMS отвечает за установку программного обеспечения. Пользователь, однако, инициирует установку программного обеспечения посредством взаимодействия с AMS. AMS хранит приложения в определяемом устройством месте, но не в RMS MIDP, о которой вы узнали в главе 7.

Спецификация CLDC не требует того, чтобы AMS устройства хранила приложения MIDP, поскольку не все мобильные устройства поддерживают механизм постоянного хранения, такой, как файловая система. Альтернативным механизмом для AMS будет поддержка загрузки классификационных файлов с системы инициализации, необходимых для выполнения приложения. Виртуальная машина Java просто загружает классификационные файлы Java по мере их пересылки, выполняет приложение, а затем отбрасывает классификационные файлы, когда процесс установки завершен.

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

Информация дескриптора приложения должна включать информацию о том, как и когда должны быть установлены серверные компоненты. Например, дескриптор приложения должен показывать, должны ли серверные компоненты устанавливаться при первом использовании клиентского приложения или во время первой загрузки клиентских ресурсов. На сегодняшний день реальность заключается в том, что серверные компоненты должны быть установлены, сконфигурированы и протестированы до того, как клиенты начнут попытки получения доступа к ним.

Подтверждение установки включает информирование диспетчера инициализации об успешной установке. Уведомление об установке важно, поскольку пользователи обычно получают счета после того, как они установили приложение. Атрибут MIDlet-Install-Notify предоставляет способ для разработчиков приложений указывать URL, к которому должна быть послана HTTP-команда POST при успешной установке. Разработчики могут задавать значение этого атрибута. Иногда это значение будет задавать инициализирующее программное обеспечение, поскольку диспетчер инициализации лучше знает URL, который он установил для отслеживания установок.

Успешная установка подразумевает успешную загрузку. Когда установка завершена, пользователи могут выполнить приложение. Поэтому уместно потребовать оплату с пользователей за программное обеспечение при подтверждении установки. Конечно, некоторые приложения могут оплачиваться пользователями после первого использования, независимо от того, когда приложение было загружено. Здесь важно отметить, что устройство, а не приложение, чаще всего должно выполнять подобное подтверждение.

После уведомления система инициализации может генерировать событие создания счета. Обратите внимание, что подтверждение установки отличается от подтверждения покупки.

Пользователи должны оплачивать использование услуг. Счет — это список всех расходов, который представляется потребителю к оплате. Событие выдачи счета — это уведомление о необходимости произведения оплаты.

Успешная загрузка может представлять собой событие, подлежащее оплате за программное обеспечение, которое необходимо купить за плату. При выполнении и уведомлении об успешной загрузке приложения пользователем система инициализации генерирует событие выдачи счета. Событие выдачи счета пересылается системой организации счетов. Система организации счетов обычно представляет собой независимую систему, управляемую транспортировщиком, с которым взаимодействует система инициализации.

Системы инициализации поддерживают различные модели формирования счетов. Разнообразные модели генерируют различные типы информации о событиях выдачи счетов, которая представляет собой разные схемы оплаты. В следующем списке представлены некоторые возможные схемы оплаты:

— оплата за загрузку приложения; оплата за установку;

— оплата за запуск приложения; оплата за определенное время использования;

— оплата за определенное количество раз использования.

Как разработчик вы должны предусмотреть, какие схемы оплаты предпочтительнее для вас — и какие из них представлены на рынке. Информация дескриптора вашего приложения должна отражать ваши предпочтения в формировании счетов и оплате в виде информации, которую вы поставляете во время регистрации приложения.

Системы инициализации используют различные схемы для пересылки информации о событии выдачи счета системам организации счетов. Одна из схем заключается в пересылке каждого события при его осуществлении. Другой метод — сбор групп событий выдачи счетов и пересылки их как пакета для групповой обработки системой организации счетов. Групповая обработка счетов может выполняться периодически тем же образом, как обычно поставщики услуг осуществляют работу со счетами.

Обновление приложения — это процесс обновления приложения, которое уже находится на устройстве, на более новую версию. В соответствии с приложением «Инициированная пользователем беспроводная инициализация» (Over the Air User Initiated

Provisioning) спецификации MIDP для поддерживания обновлений уже установленных на устройства приложений требуется система инициализации ОТА. Вы найдете ссылку на этот документ в разделе «Ссылки» в конце данной книги.

Программное обеспечение пользовательского агента устройства и программное обеспечение диспетчера инициализации использует обязательный атрибут MIDlet-Version файла JAD приложения для согласования обновления приложения. Кроме того, дескриптор приложения должен однозначно идентифицировать набор МГО-летов, который должен быть загружен, так чтобы устройство могло определять, должно ли оно выполнять обновление или новую установку. Разработчики должны убедиться, что они поставляют правильную информацию о версии MID-лета и идентификации набора MID-летов.

С точки зрения диспетчера инициализации, удаление приложения — это процесс получения уведомления о том, что приложение было удалено с устройства. AMS устройства заботится о самом удалении наборов приложений с устройства самостоятельно.

Разработчикам не нужно предусматривать уведомление сервера об удалении приложения. В этот процесс вовлечены только агент пользователя и сервер. Разработчики должны, однако, предусмотреть вероятность необходимого удаления приложения на клиенте при подготовке файла JAD приложения. Атрибут MIDlet-Delete-Conf irm является необязательным атрибутом файла JAD. Цель — предоставить AMS текстовое сообщение, предоставляемое пользователю для подтверждения удаления связанного набора MID-летов.

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

Подготовка приложений к использованию в системах инициализации заключается в предоставлении всех обязательных файлов приложения и обеспечении того, что они содержат информацию, требуемую в процессе инициализации. Основная задача этой подготовки — этв правильное создание файла дескриптора приложения (JAD) и файла приложения JAR.

Файл JAD является основным механизмом предоставления определяемой приложением информации как клиенту, так и серверу. Файл JAD может сопровождать каждый файл JAR приложения. Система инициализации извлекает и использует информацию из этого файла во время различных этапов процесса инициализации. Файл JAD может быть сохранен как часть файла JAR приложения, или он может быть сохранен отдельно для более легкого извлечения. Одно основное преимущество поставки файла JAD отдельно от файла JAR заключается в том, что диспетчер инициализации может получать атрибуты приложения без открытия файла JAR. В таблице 10.1 перечислены все атрибуты MID-лета, относящиеся к инициализации.

Таблица 10.1. Атрибуты MID-лета, связанные с инициализацией приложения

Название атрибута MID-лета — Описание — Наличие

Как среда клиента, так и среда сервера используют файл JAD. Диспетчер инициализации использует его во время инициализации, а клиент использует во время установки и исполнения приложения. Во время инициализации сервер инициализации посылает файл JAD на устройство, где программное обеспечение агента пользователя использует его для подтверждения того, что набор MID-летов совместим с устройством, до загрузки файла JAR всего набора MID-летов. Во время исполнения, как вы узнали из главы 3, AMS использует информацию, представленную в файле JAD, для управления жизненным циклом приложения. Кроме того, AMS делает информацию файла JAD доступной MID-летам набора MID-летов для использования во время выполнения МЮ-лета.

Атрибут MIDlet-Install-Notify является необязательным атрибутом файлов JAD и manifest, который используется для инициализации. Его цель — дать программному обеспечению агента пользователя стандартный механизм передачи состояния установки в службу, предоставляющую набор MID-летов.

Значение атрибута MIDlet-Install-Notify должно описывать URL, на который агент пользователя посылает HTTP-запрос POST, содержащий информацию о состоянии установки. Посылать полный запрос POST в соответствии с рекомендациями приложения «Инициированная пользователем беспроводная инициализация» (Over the Air User Initiated Provisioning) спецификации MIDP входит в обязанности агента пользователя. То есть агенту пользователя необходимо получить некоторую информацию о приложении от AMS и включить ее — возможно, как параметры HTTP, — в запрос POST.

URL предоставляют некоторые программы систем инициализации, за исключением URL для определяемых приложением параметров, которые может предоставлять только AMS. Основная причина такой политики заключается в том, что программное обеспечение инициализации знает URL, который оно использует для сбора информации об установке, и оно может облегчить ношу разработчика, которому приходится разыскивать и предоставлять строку URL в каждом файле JAD. Разработчики должны знать о том, записывает ли система инициализации этот атрибут в файл JAD набора MID-летов. Если нет, разработчик должен включить этот атрибут в файл JAD.

Хорошей идеей является обеспечение того, что дескрипторы вашего приложения определяют значение атрибута MIDlet-Install-Notify, чтобы агент пользователя мог выдать состояние установки даже в случаях, когда набор MID-летов не был извлечен. Например, возможно, что URL, который определяет местоположение файла JAR и является значением атрибута MIDlet-Jar-URL, неправилен.

Инициализация приложений — это процесс поставки программного обеспечения на устройства. Инициализация не ограничивается беспроводными сетями, J2ME или даже приложениями Java. Тем не менее, системы инициализации стали важным компонентом, поддерживающим установку приложений J2ME, особенно в сфере инициализации ОТА приложений MIDP.

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

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

Системы инициализации являются комплексными корпоративными приложениями, которые обычно интегрируются в сеть беспроводного транспортировщика. Они предоставляют услуги инициализации для беспроводных подписчиков. Ключевым моментом для разработчиков приложений является подготовка своих приложений MIDP для использования в системах инициализации, поддерживаемых транспортировщиками, у которых их приложения будут зарегистрированы. Понимание сущности интерфейсов, свойств и возможностей системы инициализации, с которой вы будете взаимодействовать, важно. Как разработчик приложения, вы должны быть способны предоставить всю информацию, необходимую системе инициализации, для того чтобы вы могли извлечь из нее максимально возможные преимущества.

Системы инициализации поддерживают многие другие свойства, которые не были обсуждены в данной главе. Многие из этих свойств прозрачны для разработчика приложений, в том смысле, что разработчику не приходится ничего делать для регулировки этих аспектов работы системы инициализации. Многие из них не влияют на приложение. Или они просто обращаются к функциям, которые не зависят от вопросов разработки, конфигурирования или установки приложения.