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