Java для мобильных устройств

Размещено на http://www.allbest.ru/

Таразский государственный университет им. М.Х. Дулати

JAVA ДЛЯ МОБИЛЬНЫХ УСТРОЙСТВ

Усипов М.Н.

Платформа Java 2 MicroEdition (J2ME) была разработана для потребительского рынка устройств с ограниченными ресурсами памяти и процессора таких как: сотовые телефоны, пейджеры, смарт карты, органайзеры и миникомпьютеры. J2ME позволяет запускать Java на ресурсо-ограниченных вычислительных устройствах. Для данных целей J2ME адаптирует существующую Java технологию. Рассмотрим два ключевых момента J2ME: конфигурацию и профайлы.

Конфигурация определяет среду выполнения J2ME. Она включает в себя виртуальную машину ограниченную по сравнению с стандартной VM и набор основных классов, в основном заимствованных из J2SE. В настоящий момент определены 2 конфигурации: Конфигурации коммуникационных устройств с ограниченными ресурсами (ConnectedLimitedDeviceConfiguration, CLDC) и Конфигурация коммуникационных устройств (ConnectedDeviceConfiguration, CDC). Первая конфигурация ориентированна на микро устройства, оснащеные 16- или 32-битными процессорами с минимальным объемом памяти около 128 Кб. Сердцем J2ME CLDC является виртуальная машина K VirtualMachine (KVM), специально разработанная для сетевых устройств с небольшим объемом памяти и ограниченными ресурсами. Вторая конфигурация J2ME, CDC, ориентирована на более сложные электронные и встроенные устройства, такие как смарт коммуникаторы, сложные "интеллектуальные" пейджеры, персональные цифровые помощники (PDA) и интерактивные цифровые телевизионные приставки. Как правило, такие устройства комплектуются 32-битным микропроцессором/контроллером и оснащены более 2 Мб памяти, используемой для хранения виртуальной машины и библиотек. CDC работает с виртуальной машиной C VirtualMachine (CVM). CDC включает в себя все классы из CLDC и еще больше классов из J2SE. Главное отличие между CDC и CLDC являеться то что CDC VM поддерживает все возможности J2SE VM включая nativeprogramminginterfaces [1].

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

FoundationProfile- добавляет набор классов из J2SE к CDC но не вводит пользовательского интерфейса. Данный профайл используеться для построения на нем других профайлов. jsr-46.

PersonalBasicProfile - обеспечивает Java API для устройств требующих сетевой доступ и графическую презентацию. Данный профайл является подходящим для интерактивного телевидения и содержит API для поддержки MultimediaHomePlatform. (JSR129) [2].

Personal Profile - обеспечивает Java API для устройств требующих надежный сетевой доступ построен на Personal Basic Profile и Foundation Profile (JSR62).

Рис. 1 Архитектура J2ME

CLDC (Конфигурации коммуникационных устройств с ограниченными ресурсами).

CLDC являеться результатом работы JavaCommunityProcess (JSP) экспертной группы JSR-30 в которую составили следующие компании:

- America Online

- Bull

- Ericsson

- Fujitsu

- Matsushita

- Mitsubishi

- Motorola

- Nokia

- NTT DoCoMo

- Oracle

- Palm Computing

- RIM

- Samsung

- Sharp

- Siemens

- Sony

- SunMicrosystems

- Symbian

CLDC технология используеться для постоения на ней различных профайлов. Цель данной технологии определить стандарт использования Java на устройствах с ограниченными ресурсами.

- 160-500 kb памяти доступной для Java платформы

- 16-32 битный процессор

- низкое потребление энергии

- сетевое соединение 9600 bps или меньше.

Ниже представлены аспекты, которые попадают под "юрисдикцию" CLDC: профайл коммуникационный устройство java

- Java язык и виртуальyная машина KVM

- Основные Java библиотеки (java.lang.*, java.util.*)

- Security модель

- Операции ввода вывода

- Сетевая поддержка

- Интернализация

Нижеследующие вещи не входят в область рассмотрения CLDC: (Как правило, они определяются профайлами.)

- Пользовательский интерфейс

- Обработка событий

- Жизненный цикл приложений

- Взаимодействие пользователя и приложения

Java язык и виртуальyная машина KVM

Основная цель для JVM поддерживающей CLDC быть совместимой с JavaLanguageSpecification насколько это возможно. За исключением различий приведенных ниже, JVM которая поддерживает CLDC, совместима с JavaLanguageSpecification.

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

2. Отсутствует метод finalize() и нет weakreferences. Это требование связано с необходимостью упрощения механизма сборки мусора.

3. CLDC поддерживает exception механизм, однако, его арсенал является ограниченным. Это связано с двумя причинами:

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

- Полная реализация механизма является слишком дорогим удовольствием для микро устройств.

KVM

1. Нет поддержки floatingpoint. Это связано с тем, что в устройствах с ограниченными ресурсами отсутствует поддержка floatingpoint. Поддержка же на программном уровне была бы слишком дорогим удовольствием. В JVM которая поддерживает CLDC отсутствуют байткоды связанный с типами float и double.

2. KVM нереализует Java Native Interface (JNI).Поддержка JNI была отклонена по двум причинам.

- Ограничения, накладываемые security моделью CLDC. (Данная модель запрещает использовать native вызовы.)

- Полная реализация JNI была признана слишком дорогой для устройств с ограниченными ресурсами.

3. KVM не позволяет создавать свойclassloader. Это ограничения накладываемое security моделью.

4. KVM не поддерживает Reflection механизм. Java приложения не могут инспектировать классы, объекты, методы, поля, нитки, выполняемые стэки в виртуальной машине. Как следствие сериализация, JVMDI (DebuggingInterface), JVMPI (ProfilerInterface) и другие технологии J2SE основанные на Reflection механизме отсутствуют в CLDC.

5. KVM реализует многопоточность, но не поддерживает Threadgroup и daemonthread. Операции, такие как запуск и остановка могут быть применены только над отдельной ниткой.

6. Отсутствует метод finalize() и нет weakreferences. Это требование связано с необходимостью упрощения механизма сборки мусора.

7. Ограниченный еrrorhandling механизм по сравнению с J2SE.

8. Преверификация.

CLDC библиотеки.

CLDC библиотеки можно разделить на две категории:

1. В первую категорию входят классы, наследованные из J2SE.

2. Во вторую классы которые вводит CLDC.

Классы, принадлежащие к первой категории находятся, в пакетах java.lang.*, java.util.*, и java.io.*. Эти классы производные из Java 2 StandardEdition версии 1.3. Данные классы являются идентичными соответствующим классам J2SE. Семантика классов и их методов не будет изменяться. К классам не будут добавляться любые public или protected методы, которые не являются доступными в J2SE. [3]

Системные классы.

Данные классы внутренне связаны с виртуальной машиной. Некоторые Java приложения требуют наличия данных классов. Например, J2SE Javacompiler (javac) генерируя код, требует наличия определенных функций String и StringBuffer классов. java.lang.Object

java.lang.Class

java.lang.Runtime

java.lang.System

java.lang.Thread

java.lang.Runnable (interface)

java.lang.String

java.lang.StringBuffer

java.lang.Throwable

Классы представлющие типы.

Каждый из этих классов представляют собой подмножество соответствующих классов из J2SE.

java.lang.Boolean

java.lang.Byte

java.lang.Short

java.lang.Integer

java.lang.Long

java.lang.Character

Collection классы.

java.util.Vector

java.util.Stack

java.util.Hashtable

java.util.Enumeration (interface)

Классывводавывода.

java.io.InputStream

java.io.OutputStream

java.io.ByteArrayInputStream

java.io.ByteArrayOutputStream

java.io.DataInput (interface)

java.io.DataOutput (interface)

java.io.DataInputStream

java.io.DataOutputStream

java.io.Reader

java.io.Writer

java.io.InputStreamReader

java.io.OutputStreamWriter

java.io.PrintStream

Классы Reader, Writer, Input Stream Readerи Input Stream Writer обеспечивают поддержку интернализации.

Механизм их работы такой же, как и в J2SE. Последние два класса имеют точно такие же конструкторы, как и в J2SE.

newInputStreamReader (InputStream is);

newInputStreamReader (InputStream is, String name);

newOutputStreamWriter (OutputStreamos);

newOutputStreamWriter (OutputStreamos, String name);

Вслучаях, гдеприсутствует String параметр, используется заданный character encoding, иначе используется character encoding, имякоторого содержится в переменной microedition.encoding. Если конвертер не доступен, выкидывается UnsupportedEncodingException.

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

Календарь и время. CLDC, включает небольшое подмножество стандартных J2SE классов: java.util.Calendar, java.util.Date, andjava.util.TimeZone. По умолчанию одна временная зона поддерживается.

java.util.Calendar

java.util.Date

java.util.TimeZone

'Вспомогательные' классы. java.util.Random класс содержит простой генератор случайных чисел.

java.lang.Math имеет в своем наборе методы abs, max и min для int и long типов.

В CLDC отсутствует класс java.util.Properties. Однако,property могут быть доступны при помощи статического метода System.getProperty (Stringkey). Минимальный набор properties предоставляемый CLDC следующий.

microedition.encoding

microedition.platform

microedition.configuration

microedition.profiles

Классы, принадлежащие ко второй категории находятся в пакетах javax.microedition.*. Пакет javax.microedition.io вводит новый механизм сетевой поддержки [4].

CLDC ConnectionFramework.

java.io.* и java.net.* пакеты J2SE не подходят для микро устройств с их ограниченными ресурсами. Поэтому был разработан новый пакет javax.microedition.io.

Данный пакет имеет только один класс: Connector, 8 интерфейсов и ConnectionNotFoundException.

Класс Connector - это сердце ConnectionFramework, он имеет ряд статических методов для получения Connection объекта. Если операция происходит успешно метод возвращает объект реализующий Сonnection интерфейс иначе выкидывается IOException. На рисунке 2 представлена иерархия интерфейсов.



Рис. 2 Иерархия интерфейсов

Объект, реализующий Connection интерфейс, может быть получен при помощи класса Connector, как уже было сказано выше. Интерфейс Connection имеет единственный метод close. Данный метод закрывает сетевое соединение.

- InputConnection интерфейс "представляет устройство", из которого можно прочитать данные. Методы openInputStream и openDataInputStream возвращает поток для чтения.

- OutputConnection интерфейс "представляет устройство", в которое можно записать данные. Методы openOutputStream и openDataOutputStream возвращают поток для записи.

- StreamConnection интерфейс сочетает в себе IntputConnectionиOutputConnection.

- ContentConnection под интерфейс StreamConnection.

- StreamConnectionNotified ждет, пока соединение будет установлено. Метод acceptAndOpen() возвращает StreamConnection объект.

- DatagramConnection интерфейс определяет дейтаграммное соединение.

- ConnectionNotFoundException выкидывается, когда соединение не может быть установлено.

Connector.

Параметр String метода open класса Connector имеет следующий формат. "protocol: address; parameters".

Вот несколько примеров:

HTTP Connection

Connector.open ("http://java.sun.com/developer");

Socket

Sockets: Connector.open ("socket://129.144.111.222:9000");

Datagram Connection

Connector.open ("datagram://address:port#");

Communicate with a Port

Connector.open ("comm:0;baudrate=9600');

Open Files

Connector.open ("file:/myFile.txt");

Networkfilesystems:

Connector.open ("nfs:/foo.com/foo.dat");

Security.

Одно из огромных преимуществ Java динамическая загрузка приложений через сеть, к клиенту используя надежный security механизм. Реализация данного механизма в J2SE превышает возможности доступного бюджета памяти для JVM поддерживающей CLDC. Для CLDC был разработан иной механизм, который можно разбить на два уровня: Уровень виртуальной машины и уровень приложения.

Уровень виртуальной машины - подразумевает, что запускаемое приложение в VM не должно иметь способность каким-либо образом повредить устройство. Данное требование должно обеспечиваться Javaclassfileverifier, который должен гарантировать, что загружаемый байткод не содержит ссылок к недействительным областям памяти или памяти находящейся вне JavaHeap. Verifier должен отклонить загрузку таких классов.

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

В JVM поддерживающая CLDC реализована sandboxsecurity модель. В данной модели предполагается, что приложение должно выполняться в ограниченном окружении, в котором приложение может иметь доступ только к тем, API которые определены в конфигурации, профайлах и линензированных классах.

Более точно sandbox модель означает:

- Загружаемые Java класс файлы должны пройти верификацию

- Приложение может иметь доступ только к тем, API которые определены в конфигурации, профайлах и линензированных классов.

- Загрузка приложений может выполняться только native кодом виртуальной машины и не может осуществляться classloader определенным пользователем. Поэтому в CLDC нельзя создать свойclassloader.

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

CLDC реализация должна обеспечивать невозможность перезагрузки системных пакетов java.*, javax.microedition.*

Помимо этого профайлы могут добавлять свои ограничения к вышесказанным.

MIDP

MobileInformationDeviceProfile расширяет CLDC добавляя три новых пакета:

- javax.microedition.midlet

- javax.microedition.lcdui

- javax.microedition.rms

Выдвигает требования к инсталляции мидлетов, которые должны содержаться в MIDletSuites Добавляет несколько классов в уже имеющиеся пакеты, определенные в CLDC:

- javax.microedition.io к java.io пакету добавляет HttpConnection интерфейс.

- java.langКjava.lang пакету добавляет IllegalStateException (java.lang.IllegalStateException).

- java.util Добавляет функциональность, которая позволяет приложениям создавать таймеры. Для этих целей были добавлены классы java.util.Timer и java.util.TimerTask из J2SE.

Литература

1. Анисимов С.Н. Управление проектами. Российский опыт / Анисимов С.Н., Анисимова Е.В. М.: Вектор, 2006.

2. Балабаев М.А. Организация мониторинга рисков в сложных системах /Балабаев М.А // Информационные технологии моделирования и управления. 2007. №7.

3. Грей К.Ф. Управление проектами: Практическое руководство / Грей К.Ф., Ларсон Э.У. М.: Дело и сервис, 2003.

4. Barry W. Boehm Software Cost Estimation with Cocomo II. Prentice Hall // PTR.: August 11, 2000.

Размещено на Allbest.ru

...