Глава 11. Среда беспроводного Интернета

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

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

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

Термины беспроводный Web и беспроводный Интернет относятся к среде, в которой беспроводные радиоустройства могут получать доступ к World Wide Web и Интернету. Эти термины являются чем-то абстрактным по той причине, что они не несут информации об архитектуре или физической природе среды. Беспроводной Интернет, как и Интернет, является сетевым комплексом, объединением сетей. Однако, в отличие от Интернета, это объединение беспроводных и проводных сетей.

Беспроводные сети связываются с проводными сетями — и с Интернетом — посредством шлюза беспроводного Интернета (wireless Internet gateway (WIG)), шлюзом, состоящим из аппаратного и программного обеспечения, который соединяет беспроводную сеть транспортировщика с его собственной проводной сетью intranet. Шлюзы беспроводного доступа в Интернет обычно состоят из принадлежащего провайдерам программного и аппаратного обеспечения, которое позволяет взаимодействовать с мобильными центрами коммутации (mobile switching center (MSC)). Вместе все эти компоненты реализуют определенные типы систем беспроводных коммуникаций. Например, многие из производителей мобильных телефонов предлагают свои собственные WIG. Они работают только с определенными системами беспроводных коммуникаций и с определенными базовыми станциями и телефонами.

На рисунке 11.1 показана схематичная логическая диаграмма, которая представляет связи между компонентами беспроводной сети, шлюзами WIG и сетями intranet транспортировщика. WIG дает беспроводной сети — и беспроводным устройствам — доступ в Интернет посредством проводной сети intranet поставщика беспроводной связи. Intranet беспроводного транспортировщика соединяется с проводными сетями или сетевыми комплексами, которые дают ему доступ к Интернету.

Рисунок 11.1. Беспроводные устройства получают доступ к службам Интернета через WIG и сеть транспортировщика. Беспроводная сеть, WIG и проводная сеть транспортировщика работают совместно для создания инфраструктуры абстракций, которые пытаются сделать беспроводную сеть похожей на проводную сеть, связанную с мобильными приложениями

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

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

Беспроводные порталы поддерживают многие из тех же приложений, что и интернет-порталы. Они предоставляют службы обмена сообщениями, которые включают электронную почту, мгновенный обмен сообщениями (instant messaging (IM)), интегрированную систему обработки сообщений (unified messaging (UM)), наряду с календарем, утилитами книги записи деловых встреч и адресной книги и так далее. Разработчики i приложений создают приложения портала, которые взаимодействуют с этими службами портала посредством программных интерфейсов приложений, определенными службами порталов.

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

Например, беспроводные системы по всему миру используют службу Short Message Service (SMS) для реализации мгновенного обмена сообщениями между мобильными устройствами. Реализации транспортного протокола 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, потребовалось бы создание структуры дополнительных служб платформы или инфраструктуры приложений. При разработке приложения пришлось бы учитывать возможности платформы телефона, механизмы транспортировки, производительность и так далее.

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

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

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

В других ракурсах описываются другие части системы. Например, системы имеют модели состояний, модели обработки транзакций и так далее, которые не могут быть в достаточной мере описаны с помощью диаграммы, представленной на рисунке 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, Интернет и пользовательскими объектами.

Беспроводная сеть, однако, ставит некоторые уникальные проблемы. Беспроводные сети используют сложные наборы собственных протоколов, которые представляют собой решения практических проблем реализации организации межсетевого обмена между беспроводными интерфейсами. Эти собственные наборы развиваются параллельно совершенствованию беспроводных систем и их продвижению к поддержке TCP/IP на телефонных трубках в системах третьего поколения (3G). Тем не менее, уровни, лежащие под сетевым уровнем, все еще очень отличаются от уровней, расположенных в проводных сетевых комплексах.

Рисунок 11.2. Интерфейсы и транспортные механизмы среды беспроводного Интернета влияют на выбор разработчиками технологий и осуществимость определенных программных разработок

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

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

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

Более интересен для разработчиков MIDP набор протоколов над транспортным уровнем. Существует два основных небора. Первый использует протокол WAP, использование которого горячо отстаивается во многих современных беспроводных Web-системах. По причинам, связанным с практической разработкой, WAP транспортирует содержимое, форматированное на языке разметки для беспроводных систем (wireless markup language (WML)). Второй подход, который, вероятно, будет принят в системах 3G, транспортирует XHTML/XML через HTTP. Кроме того, протоколы уровня приложений могут быть туннелированы с помощью HTTP.

В этом разделе кратко описываются типы приложений и служб приложений, которые обычно доступны на порталах беспроводного Интернета. Мы не будем обсуждать здесь разработку этих служб, потому что они могут включать комплексные архитектуры, которые требуют Web-серверов, серверов приложений и других компонентов системного уровня. Цель данного раздела — дать вступительное теоретическое описание среды беспроводного приложения и побудить разработчиков начать думать о том, как разрабатывать приложения для данной среды.

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

Теоретически существует, грубо говоря, три типа обмена сообщениями в беспроводных средах:

— мгновенный обмен сообщениями;

— электронная почта;

— интегрированная система обработки сообщений.

Точные определения этих типов обмена сообщениями являются чем-то неопределенным, потому что они зависят от характеристик конкретной реализации. Например, насколько «мгновенны» мгновенные сообщения? Тем не менее, существуют общепринятые трактовки этих терминов.

В беспроводных средах мгновенный обмен сообщениями обычно означает обмен SMS-сообщениями, поскольку системы каналов передачи SMS обычно используются для реализации службы IM. Адреса сообщений состоят из MSN. Каналы передачи SMS предоставляют мгновенный обмен сообщениями в пределах того, что сообщения посылаются «немедленно». Конечно, получается ли сообщение немедленно, зависит от нагрузки системы, управления потоком, ограничений полосы пропускания и так далее, что может привести к задержкам, которые будут выше, чем в технологиях мгновенной передачи сообщений проводных сетей.

Электронная почта (e-mail) — это передача сообщений произвольной длины с помощью модели с промежуточным хранением. Термин электронная почта подразумевает использование схемы адресации, сходной со схемой e-mail Интернета, пример которой показан ниже:

user@some-host.com

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

Интегрированная система обработки сообщений — это понятие единого механизма, который интегрирует другие системы обработки сообщений и дает пользователям единую точку доступа ко всем службам обработки сообщений. Интегрированная система обработки сообщений может иметь пользовательский интерфейс как для Web-доступа, так и доступа с устройств с беспроводной связью. Коммерческие поставщики предлагают интегрированные системы обработки сообщений, которые обычно включают API для интерфейсов приложений. Например, приложение MIDP может взаимодействовать с системой через внешний API и представлять пользователю интегрированное отображение SMS и электронной почты. Этот сценарий работает только на телефонах, которые его поддерживают? Смысл в том, что интегрированные системы обработки сообщений извлекают подробную информацию о взаимодействии с отдельными системами обработки сообщений, такими, как серверы электронной почты или серверы SMS.

Приложения личной информационной системы (Personal information management (PIM)) включают такие приложения, как календари с возможностью напоминания о событиях, адресную книгу, записную книжку и так далее. Все это — стандартные утилиты сайтов порталов Интернета. Проблема беспроводных сред заключается в поддержке: пользовательскогр интерфейса для этих приложений.

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

Протокол доступа к сообщениям в Интернете (The Internet mail application protocol (IMAP)) и почтовый протокол (post office protocol (POP)) являются двумя наиболее распространенными протоколами, поддерживаемыми почтовыми серверами. Беспроводные сети будут либо поддерживать эти протоколы на телефонах, либо реализовывать собственные.

Службы календаря обычно определяют свои собственные API и интерфейсы, которые настроены как для Web-доступа, так и для доступа приложений. Некоторые системы определяют один интерфейс HTML-через-НТТР. Клиентскому приложению календаря, которое использует сервер, на котором находится серверный компонент календаря, пришлось бы создавать запросы HTTP в соответствии с API, определенным сервером. Календарное уведомление может использовать SMS для посылки уведомлений клиентам. Приложениям MIDP, например, может понадобиться наличие некоторого способа взаимодействия с родным программным обеспечением обработки сообщений на телефоне. Во время написания данной книги спецификация MIDP не связывала интерфейсы с программным обеспечением родной системы. Ожидается, что спецификация MIDP-NG (следующее поколение) будет связывать интерфейсы родного устройства с приложениями MIDP.

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

— информация о предпочтениях предоставления — настройки того, как информация представляется пользователю;

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

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

Большинство систем использует механизмы персонализации сторонних разработчиков. Как и большинство предназначенного для Web программного обеспечения, большая часть служб персонализации поддерживает API HTML-через-НТТР.

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

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

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

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

Глобальная система местоопределения (Global positioning system (GPS)) — мобильные устройства содержат полностью основанные на технологии GPS приемные устройства.

Сетевое местоопределение — технология и обработка местоопределения расположены отдельно в беспроводной сети.

Полуавтоматическая GPS — телефон и сеть работают совместно для предоставления полной информации о местоположении.

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

Локальная информация, создаваемая сетевыми системами, менее точна, чем информация, создаваемая системами GPS. В основанных на сети системах беспроводная сеть сама определяет положение мобильного устройства. Мобильный центр коммутации (mobile switching center (MSC)) должен содержать программное обеспечение, которое может пересылать эту информацию службам приложения. Поскольку MSC обычно прозрачен для приложений, транспортировщик должен создавать объединение между MSC и службами приложения. То есть эти системы должны быть приспособлены друг к другу.

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

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

Построение архитектуры приложения — это искусство и наука. По существу, имеется много определений архитектуры приложения, каждое из них ожесточенно отстаивается своими сторонниками. Разумным определением кажется то, что предоставлено институтом разработки программного обеспечения Университета Carnegie-Mellon University (http://www.sei.cmu.edu):

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

Буч, Рамбаут и Якобсен приводят классическое определение архитектуры в своей книге «Руководство пользователя по языку моделирования UML» («UML Modeling Language User Guidz»), которое приведено ниже:

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

Архитектура создает артефакты, которые описывают систему. Важным аспектом архитектуры является то, что она включает использование процессов, которые выражаются в создании этих артефактов. Архитектурная методология (architectural methodology (AM)) — это набор действий, которые управляют использованием набора процессов. Сообщество разработчиков программного обеспечения определяет много методологий, каждая из которых отражает свою собственную философию, процессы и артефакты. Одна из таких архитектурных методологий — SunTone AM, которая была разработана в корпорации «§un Microsystems» и является дополнением к Rational Unified Process (RUP).

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

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

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

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

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

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

SunTone AM предлагает структуру, чьи основные характеристики включают:

— сконцентрированная на случаях использования — подчеркивает, что начинать надо со сбора требований;

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

— управляемая системными качествами — обращение к системным качествам на всех этапах разработки;

— архитектурно-ориентированная — твердая приверженность архитектурным принципам;

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

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

Полное описание или объяснение даже одного из этих принципов лежит за пределами возможностей данной книги. Краткое описание, предоставляемое здесь, тем не менее, предназначено для ознакомления вас с понятиями, связанными с этими архитектурными принципами, и дает вам, разработчику приложений J2ME, понятие о том, как получить преимущества от искусства и науки построения архитектуры. Для более тесного знакомства с архитектурой и архитектурной методологией SunTone AM смотрите книгу "Dot-Corn & Beyond".

Первый элемент структуры SunTone AM, случай использования, — это описание системного требования. Случаи использования собирают и документируют системные требования в читабельной для человека форме. Невозможно преувеличить значение того, что разработка будет отвечать требованиям системы. Процесс сбора требований является деятельностью, дополняющей построение архитектуры. Существует несколько хороших книг, которые объясняют случаи использования в полном объеме, такие, как книга Элистера Кокбарна (Alistair Cockburn) «Writing Effective Use Cases», которая указана в разделе «Справочная литература» в конце данной книги.

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

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

Сбор требований — указание новых требований и детализирование существующих требований.

Построение архитектуры — описание разработки системы.

Разработка — например, объектно-ориентированный анализ и проектирование.

Реализация — создание работающей системы с некоторым увеличивающимся набором функциональных возможностей.

Тестирование — тестирование функциональной возможности, встроенной на данном этапе.

Отладка — выявление, локализация и исправление ошибок.

SunTone AM объединяет эти этапы в повторяемые циклы, каждый раз улучшая свою реализацию до тех пор, пока все требования не будут соблюдены. Например, при разработке IMAP-почтового клиента для платформы MIDP разработчик может понять, что определенную архитектуру нелегко реализовать из-за ограничений доступных библиотек. Разработчик понимает это после прохождения через'первый цикл вышеуказанных этапов разработки. После завершения первоначального прототипа становится ясно, что некоторую часть логической схемы сложно реализовать.

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

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

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

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

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

— нефункциональные требования описывают системные характеристики или качества системы.

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

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

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

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

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

В контексте системной архитектуры системные качества включают следующие категории:

— качества пользовательского уровня — практичность, доступность;

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

— качества стратегического уровня — расширяемость, гибкость;

— качества системного уровня — безопасность, управляемость, восстанавливаемость.

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

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

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

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

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

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

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

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

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

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

Гибкость — это измерение того, насколько легко приложение может приспособиться или объединиться с новыми или измененными службами. Например, разработчик нашего почтового клиента MIDP может захотеть предугадать необходимость соединения с обоими почтовыми серверами РОРЗ или ШАР. Это решение может подтвердить реали- } зацию образца разработки, который спрячет подробности механизма соединения от большинства приложений, делая легким добавление поддержки для новых почтовых протоколов программного уровня.

Другим примером является гибкость, с которой клиент может анализировать новые протоколы программного уровня или форматы данных; полученных из служб. Поставщики служб беспроводного Интернета могут периодически переконструировать свои службы. Гибкость вашего приложения MIDP может сохранить вам много времени и усилий, так что вы можете избежать переконструирования вашего приложения для приспособления к изменениям в сетевых службах и серверных компонентах. Взгляд на службу беспроводного Интернета с точки зрения архитектора позволит вам предвосхитить такого рода проблемы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Повышение производительности может быть также достигнуто посредством использования дейтаграмм для определенных сетевых коммуникаций. Если приложения могут быть к нему приспособлены, использование UDP вместо HTTP или сокетов (то есть, даже если реализация MIDP поддерживает сокеты) может привести к резкому повышению сетевой производительности, поскольку реализации UDP не создают соединений на транспортном уровне.

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

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

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

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

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

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

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

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

Это некоторые из причин, почему беспроводные сети имеют более ограниченную среду сетевой передачи данных, чем среды проводных сетевых комплексов. Разработчики MIDP должны учитывать ограничения сети при разработке приложений. С принятием IPv6 будет достаточно адресов для того, чтобы присвоить каждой телефонной трубке статический IP-адрес. Тем не менее, безопасность, производительность и расширяемость останутся важными вопросами.

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

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

Основанная на Java технология платформы J2ME значительно увеличивает способ ность мобильных устройств использовать преимущества интернет-приложений. Он помогает скрывать от приложений различия в технологии и службах беспроводной CCTI и Интернета.

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

Архитектура — это набор понятий и действий, которые поддерживают проектирова ние и описание системы. Методология построения архитектуры — это порядок примене ния архитектурных понятий и действий. Методология построения архитектуры SunTom — это дополнение к процессу Rational Unified Process.

Методологию построения архитектуры дополняет сбор требований. Разработчи! должен согласовать архитектуру с объявленными требованиями системы. Методологи: построения архитектуры SunTone подчеркивает важность определения нефункциональ ных или системных качеств системы и использования их для установления соответстви: системы объявленным требованиям.

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