Несмотря на название схожее с J2EE или J2SE вряд ли Вы где-нибудь найдете JDK для J2ME [1] или что-либо подобное. Дело в том, что J2ME объединяет под своим названием множество технологий, каждая из которых решает свою конкретную задачу. А именно, спецификация J2ME определяет так называемые конфигурации (configuration). Каждая конфигурация описывает среду выполнения J2ME приложения (JVM, набор доступных классов, некоторые правила функционирования приложений). Для конфигурации в свою очередь может быть определено несколько профилей (profile), каждый из которых ‘уточняет’ среду выполнения, добавляя или запрещая использование каких-либо классов, определяя новые правила функционирования приложения.

В данной далее статье речь пойдет о конфигурации CLDC [2] (Connected, Limited Device Configuration) и одном из ее профилей - MIDP [3] (Mobile Information Device Profile).

CLDC

Полное подробное описание данной конфигурации можно найти в [2]. Я же здесь хочу отметить только некоторые основные моменты, которые отличают среду выполнения CLDC J2ME от, например, среды выполнения J2SE:

• Для CLDC была разработана своя JVM, в реализации Sun она называется KVM (Kilo VM). Она не имеет операций с плавающей точкой, не допускает финализаторов у классов, не реализует JNI, не допускает использования пользовательских загрузчиков классов, имеет очень слабые Security механизмы, не имеет механизма Reflection и еще много чего. Но зато она имеет очень малый размер – несколько сотен килобайт, что позволяет уместить такую виртуальную машину, например, в мобильный телефон с очень небольшим количеством памяти;
• Библиотеки классов доступные в CLDC можно разделить на две группы – первая является подмножеством библиотек J2SE, вторая является специфичной для CLDC. В первую группу входят классы из таких пакетов J2SE, как java.lang.*, java.util.*, and java.io.*. Все классы принадлежащие этой группе совместимы с соответствующими классами из J2SE снизу вверх. Во вторую группу входят классы из пакета javax.microedition. Собственно сама CLDC из этой группы реализует только Generic Connection Framework, речь о которой пойдет позже.
• Входной точкой приложения, написанного для CLDC, является как и в J2SE метод public static void main(String[] args).

Нужно сказать, что спецификация CLDC сама по себе не определяет законченную среду выполнения, поэтому в реализацию CLDC от Sun был включен дополнительный пакет com.sun.kjava, классы которого реализуют тестовый пользовательский интерфейс и некоторые протоколы для Generic Connection Framework.

MIDP

Данный профиль построен на базе конфигурации CLDC и полностью определяет среду выполнения (но не всю инфраструктуру) приложения. Данный профиль нацелен на создание приложений для таких мобильных устройств как сотовые телефоны, пейджеры, PDAs, Smart Phones. Место, которое занимает профиль MIDP в технологии J2ME показывает рис. 2.

Рисунок 1. Стек MIDP приложения.

Не мудрствуя лукаво, приведем цитату из спецификации [3]: “MIDP определяет модель приложения, которая позволяет разделять нескольким приложениям ограниченные ресурсы мобильного устройства, эта модель называется MIDlet. Она определяет, что такое MIDlet приложение, как оно должно быть упаковано, какая среда выполнения доступна для MIDlet’a и как должно себя вести приложение, чтобы мобильное устройство могло им управлять…”. Чтобы не приводить больше теоретических сведений о MIDP профиле перейдем к практическому написанию приложения для него.

Подготовка к разработке

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

1. Среда выполнения: Mobile Information Device Profile (MIDP) Reference Implementation (RI) от Sun [3], редактор: любой;
2. Среда выполнения: Java 2 Platform Micro Edition, Wireless Toolkit [4], редактор: любой;
3. Интегрированная среда выполнения: Forte for Java [5], поверх ставим Wireless Toolkit и указываем при установке, что нужно интегрироваться с Forte for Java;
4. Интегрированная среда выполнения: Inprise JBuilder 4/5, поверх ставим Nokia Developer's Suite [6];

Существует еще огромное количество вариантов (см. [7]), но мы в данной статье будем ориентироваться на 3-ий, как самый честный в смысле соответствия спецификации.

Mobile Messenger

Рисунок 2. Блок-схема приложения.

Предполагается следующий механизм взаимодействия: все сообщения передаваемые клиентом сначала попадают на сервер, который либо пересылает сообщения адресату (другому мобильному клиенту), либо выполняет какие-либо другие действия (например отвечает клиенту, что адресат недоступен). Самый главный вопрос, который встает при проектировании данной системы – как MIDP приложениям общаться с сервером? Вот тут мы и вспоминаем о ранее упомянутой Generic Connection Framework. Основная идея Generic Connection Framework – определить единый высокоуровневый интерфейс к протоколам передачи данных любого вида. Причем CLDC определяя Generic Connection Framework, не реализует ни одного протокола, полагаясь на их реализацию в каждом конкретном профиле (точнее программист полагается на реализацию протоколов в профиле :). Спецификация MIDP в свою очередь требует обязательной реализации только протокола HTTP. Да, казалось бы без серверных сокетов замахиваться на реализацию ICQ было бы просто глупо, но как оказалось все, опробованные мной реализации MIDP (Sun, Nokia, Motorola) включают реализацию протокола серверных сокетов (Sun, Motorola - datagram, Nokia – socket), что позволяет надеется на поддержку аналогичных протоколов в реальных мобильных устройствах. Решено, для обмена сообщениями между клиентом и сервером будем использовать протокол datagram (UDP).

И так, в нашей системе явно вырисовываются три основные части:

• Клиент;
• Сервер;
• Коммуникационная часть;