Платформа J2Me
Шрифт:
Хотя многие из приложений, находящиеся в мирах беспроводных и интернет-порталов, сходны, в беспроводных и проводных сетях используются различные технологии, предписывая то, что приложения должны быть реализованы по-разному. Эти различия реализации часто проявляются на каждом уровне платформной инфраструктуры и отражаются на построении архитектуры и проектировании приложения.
Например, беспроводные системы по всему миру используют службу Short Message Service (SMS) для реализации мгновенного обмена сообщениями между мобильными устройствами. Реализации транспортного протокола SMS и формата сообщений используют технологию, в значительной степени отличающуюся от технологии, используемой для реализации мгновенного обмена сообщениями в средах интернет-порталов.
Аналогичным образом характеристики службы SMS влияют на проектирование и реализацию приложений IM, реализованных поверх инфраструктуры SMS. Например, SMS использует номера мобильного терминала (мобильного телефона) для представления адреса посылающей и принимающей сторон. Это практический выбор разработки, который отражает информацию, доступную службе SMS.
Можно реализовать систему IM, которая позволяет пользователям указывать пользовательский ID получателей сообщения. Однако, поскольку беспроводные системы указывают мобильные терминалы с помощью их MSN, инфраструктуре приложения обмена сообщениями придется преобразовать пользовательский ID в MSN. Хотя это осуществимо, этот подход вызывает трудности при разработке, и, как обычно, компромиссы в сложности, цене, инфраструктуре, производительности и так далее.
J2ME и MIDP делают подобные интернетовским IM для мобильных устройств более осуществимыми. Теоретически приложения MIDP могут реализовать клиента ICQ или IRC или клиента, который совместим с IM протоколом одного из основных коммерческих порталов. Этот подход может быть даже легче, чем реализация традиционного мобильного IM (SMS), поскольку программные интерфейсы SMS доступны только через расширения собственной платформы.
Другим примером того, как базовая технология влияет на разработку приложений, является ограничение длины сообщений SMS. Протокол SMS ограничивает сообщения до 128 байтов. Приложения могут избежать этого ограничения, разделяя длинные сообщения на несколько 128-байтовых сообщений. Пользовательский агент получателя собирает все сообщение вместе. По крайней мере, один беспроводный транспортировщик в Японии предлагает обмен сообщениями SMS, длина которых превышает 128 байтов. Для реализации этой возможности требуется несколько уровней абстракции.
Использование протокола беспроводного приложения (wireless application protocol (WAP)) в средах беспроводного Интернета представляет собой другой пример. Описание протокола WAP и всех более низких уровней протоколов, которые поддерживают WAP, отражает ограничения и трудности транспортировки данных в беспроводных сетях первого поколения. Протокол WAP был предназначен для транспортировки содержимого, созданного на языке разметки беспроводных систем (wireless markup language (WML)). Системы, которые реализуют эту службу, имеют высокоинтегрированные платформенные уровни. Чтобы поддерживать другие комбинации, такие, как транспортировка HTML через WAP, потребовалось бы создание структуры дополнительных служб платформы или инфраструктуры приложений. При разработке приложения пришлось бы учитывать возможности платформы телефона, механизмы транспортировки, производительность и так далее.
Понятие виртуального портала иллюстрирует эту мысль. Виртуальный беспроводной портал — это портал, который не связан физически с беспроводной сетью. То есть он является просто интернет-порталом, который поддерживает службы, совместимые с технологией беспроводных устройств, и к которым беспроводные устройства могут получать доступ посредством механизма связи транспортировщика с интернетом. Беспроводные устройства с возможностью связи с беспроводным Интернетом могут получать доступ к любому интернет-порталу, но с учетом ограничивающей политики, навязываемой беспроводным транспортировщиком. Разработчики приложений портала, которые находятся на интернет-порталах, вероятнее
Разработчики приложений для мобильных устройств должны знать контекст мобильной среды. Ограничения и сдерживающие факторы, налагаемые ее технологией и характеристиками, влияют на тип приложений и разработок, которые осуществимы. Разработчик должен учитывать то. насколько совместима каждая разработка со службами, программными интерфейсами приложений, интерфейсами и механизмами транспортировки, доступными на платформе беспроводного Интернета.
На уровне приложений внешние интерфейсы, программные интерфейсы и транспортные механизмы представляют один из видов описания системы. В подобном ракурсе рассмотрения заинтересованы разработчики приложений, которые должны знать, как получать доступ и как взаимодействовать со службами программного обеспечения системы.
В других ракурсах описываются другие части системы. Например, системы имеют модели состояний, модели обработки транзакций и так далее, которые не могут быть в достаточной мере описаны с помощью диаграммы, представленной на рисунке 11.1. На некотором этапе процесса разработки приложения разработчикам необходимо знать эти характеристики систем, с которыми они взаимодействуют.
На рисунке 11.2 представлена схематичная логическая диаграмма, на которой показаны типичные компоненты системного уровня, находящиеся в системах беспроводного Интернета. На диаграмме представлены некоторые из наиболее часто используемых механизмов транспортировки, которые соединяют компоненты между собой. Цель данной диаграммы — дать разработчикам некоторый ракурс рассмотрения типов сред, которые поддерживают беспроводные приложения.
Среда, показанная на рисунке 11.2, является той, в которой беспроводные приложения устанавливаются и запускаются. Эти приложения включают не только приложения телефонов — такие, как приложения МID, — но также серверные компоненты, которые поддерживают службы, используемые приложениями на телефоне.
Серверные беспроводные приложения будут находиться внутри сети intranet транспортировщика. Они обычно состоят из нескольких систем аппаратных и программных компонентов, каждая из которых предоставляет собой одну или несколько служб приложений. Некоторые из этих служб приложений будут вести себя как стандартные основанные на Web приложения и предоставлять HTML-интерфейс, который требует браузера с клиентской стороны.
Платформа J2ME, и MIDP в частности, создают платформу, которая поддерживает так называемых интеллектуальных клиентов. Они могут быть приблизительно определены как приложения, которые выполняют значительно больший объем обработки на клиенте, чем Web-приложения. Огромное количество приложений MIDP будет приложениями клиент-сервер или распределенными приложениями, взаимодействующими с компонентами клиент-сервер. Эти приложения M1DP будут взаимодействовать с системами, которые находятся в сети intranet беспроводного транспортировщика.
Например, приложениям MIDP клиент-сервер или распределенным требуются возможности организации сети и коммуникаций для того, чтобы получать доступ к серверным компонентам в сети intranet транспортировщика. Хотя платформа MIDP скрывает подробности абстракций и реализации механизмов коммуникации, о которых вы узнали в главе 8, полезно иметь представление о том, как системы поддерживают различные службы.
Большая часть Интернета стандартизирована на HTTP как на основном транспортном механизме сеансового уровня. Протоколы уровня приложений туннелируются при помощи HTTP, что связано с вопросами безопасности. Рисунок 11.2 отражает эту архитектуру между intranet, Интернет и пользовательскими объектами.