Текст книги "Платформа J2Me"

Автор книги: Автор Неизвестен

сообщить о нарушении

Текущая страница: 18 (всего у книги 21 страниц)

Глава 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. Система инициализации использует эту информацию при поиске совместимых приложений.

Подтверждение пoкyпки и соблюдение обязательных условий

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

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

Аутентификация пользователей

Аутентификация пользователей – это просто процесс подтверждения через агента пользователя того, что пользователь является тем, кем себя заявляет. Аутентификация пользователя требует, чтобы агент пользователя передавал информацию о пользователе диспетчеру инициализации. Обычно агент пользователя передает эту информацию диспетчеру инициализации в форме 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, который он установил для отслеживания установок.