Система для обработки приложений для мобильного коммуникационного устройства

Изобретение относится к области обработки приложений для мобильного коммуникационных систем. Техническим результатом является повышение быстродействия системы. Система и способ предварительного присоединения классов для использования одним или более приложением. Система и способ могут также использоваться там, где выполнение рабочего цикла разделено между хост-системой и целевой системой. На хост-системе загружаются и присоединяются по крайней мере несколько классов. По крайней мере, один присоединенный к хосту модуль создается из присоединенных классов. Присоединенный к хосту модуль создается таким образом, чтобы быть доступным для использования одним или более приложениями, работающими на целевой системе. 2 н. и 41 з.п. ф-лы, 12 ил.

 

В настоящей заявке содержится ссылка на приоритет предварительной заявки США, серийный номер 60/294,331, озаглавленной «Способ разделения рабочего цикла обрабатывающего устройства между хост системой и целевой системой», поданной 30 мая 2001 года. В настоящем описании согласно этой ссылке полностью раскрыто содержание, включая чертежи, предварительной заявки США, серийный номер 60/294,331.

Уровень техники

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

В настоящее время современным виртуальным устройством является виртуальная машина Java™ (JVM) компании Sun Microsystems, Inc. (Sun). Средоточием технологии Java™ Sun Microsystems является созданный компанией код виртуальной машины Java™, или байтовый код, в настоящее время определенный форматом классификационного файла, как указано в главе 4 второй редакции «Спецификаций виртуальной машины Java™» Тима Линдхолма и Фрэнка Йеллина (The Java™ Virtual Machine Specification by Tim Lindholm and Frank Yellin, Addison-Wesley Pub Co; ISBN: 0201432943).

Байтовый код классификационного файла взаимодействует с рабочей средой Java™ (JRE) фирмы Sun на платформах Solaris™, Win32, Linux™, Mac, а также, возможно, на других платформах. Обычно исходный код, написанный на языке программирования Java™, компилируют в байтовый код виртуальной машины в соответствии с форматом классификационного файла с использованием компилятора Java™, такого как "javac", и потом выполняют, используя JRE или совместимую рабочую среду и обрабатывающее устройство.

Как показано на Фиг.1, блок-схема многослойной архитектуры JRE иллюстрирует некоторые аспекты технологии Sun. Различные механизмы (100А и 100В) обеспечивают программное обеспечение (110А и 110В) классификационных файлов байтового кода. Например, компилятор 100А компилирует программное обеспечение 110А в классификационные файлы байтового кода. Альтернативно, Web-броузер может использовать программный "платан" 110В для загрузки программного обеспечения 100В классификационных файлов байтового кода.

Байтовый код в классификационном файле обычно ссылается на несколько других классов, каждый из которых содержит классификационный файл. По этой причине стандартный пакет 120 классификационных файлов, созданный как общий программный ресурс, может быть повторно использован по запросу программы (110А и 110В). JVM 140 получает классификационные файлы и выполняет программу (110А и 110В) и классификационные файлы 120 стандартного пакета.

Также показаны различные системы 130, сверху которых функционирует JRE 142. Стандартные пакеты в рабочем цикле задают особую рабочую платформу, описанную в интерфейсе прикладного программирования (API).

Стандарты J2SE Java™ являются соответствующей платформой API Sun. Они также обеспечивают соответствующее выполнение, включая JRE, сконфигурированного с набором стандартных пакетов, работающих на JVM. Разработчики приложений могут писать приложения на языке программирования Java™, ссылаясь на классы стандартных пакетов J2SE, и могут ожидать, что приложения будут работать на совместимых с J2SE рабочих системах. Существуют другие платформы, которые обычно описывают в сопоставлении с J2SE. Например, расширенная версия J2SE-J2EE Java™ (спецификация J2EE) добавляет дополнительные возможности. Особый интерес представляет сокращенная версия J2SE - стандарт J2ME Java™.

Хотя платформа J2SE может хорошо подходить для работы в таких системах, как Solaris™, Win32, Mac, Linux™, и других, указанных на Фиг.1 как блоки 130, J2SE может не очень хорошо подходить для работы на многих устройствах. Например, классификационные файлы стандартных пакетов J2SE могут в настоящее время занимать более чем 16 мегабайт дискового пространства, что может превышать емкость памяти многих устройств.

Для решения этой проблемы Sun представила платформу стандарта J2ME Java™, дополнительные виртуальные устройства и соответствующие конфигурации устройств.

Конфигурация присоединенного ограниченного устройства (CLDC) и виртуальная машина К (KVM) предназначены для небольших «ручных» потребительских устройств с памятью от 128 до 512 килобайт, и, при использовании вместе с профилем мобильного информационного устройства (MIDP), могут обеспечивать среду приложений для таких устройств, как сотовые телефоны и двухсторонние пейджеры.

Конфигурация присоединенного устройства (CDC) и виртуальная машина С (CVM) предназначены для появившихся потребительских устройств следующего поколения с памятью от 2 мегабайт и выше и, при использовании вместе с основным профилем (FP), могут обеспечивать среду приложений для потребительских устройств следующего поколения.

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

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

Для лучшего понимания данного изобретения представлена следующая информация относительно рабочей технологии Java™. Согласно Линдхолму и др., в разделе §2.17.1 спецификации Sun JVM сказано: «Виртуальная машина Java начинает выполнение запуском основного способа для некоторых специфицированных классов и пересылкой ему единственного аргумента, представляющего собой массив строк. Это заставляет загрузится специфицированный класс (§2.17.2), присоединиться (§2.17.3) к другим типам, которые он использует, и инициализироваться (§2.17.4)». Поэтому, устанавливая имя «основного» класса при запуске JVM (140), как показано на Фиг.1, классификационный файл будет загружен, и начнется выполнение инструкций байтового кода в постоянной основной точке входа этого классификационного файла. Кроме того, указанные типы, такие как классы, используемые «основным» классом, будут присоединены и инициализированы. Значительные рабочие ресурсы будут затрачены для загрузки и присоединения используемых классификационных файлов в зависимости от использования «основным» классификационным файлом других классов.

Рабочая технология Java™ нуждается в том, чтобы рабочая система загружала и присоединяла все необходимые классификационные файлы каждый раз, когда «основной» класс установлен для выполнения, что может привести к стремительной трате ресурсов на целевой системе, такой как устройство.

Типичное приложение Java™ содержит, по крайней мере, один «основной» классификационный файл, содержащий постоянную основную точку входа, а также, возможно, имеющий несколько вспомогательных классификационных файлов.

Ниже рассмотрена следующая распечатка (листинг) программы Java™, приведенная в качестве примера:

public class Hello {

public static void main(String[]a) {

System.out.println("Hello!");

Bye.bye(a);

}

}

public class Bye {

public static void bye(String[]a){

System.out.println("Bye!");

}

}

Данная распечатка (листинг) содержит исходный код для двух классов. Hello и Bye, каждый из которых может быть скомпилирован в формат классификационного файла способом, известным специалистам в данной области техники, таким, как помещение исходника каждого класса в файл Hello.Java и файл Bye.java и использования команды "javac Hello.java Bye.java", с тем, чтобы получить файл Hello.class и файл Bye.class.

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

Как показано на Фиг.2, технология присоединения рабочего процесса, показанного на Фиг.1, рассматривается с учетом вышеуказанного примера программы "Hello". Для виртуальной машины 140 (Фиг.1) доступно множество классификационных файлов 200. Каждый классификационный файл содержит символьную информацию, которая используется виртуальной машиной 140 для разрешения ссылок на другие используемые классификационные файлы.

Обычно файл Hello.class 210A загружается в 220А вначале как описано для запуска JVM 140. Потом JVM 140 продолжает выполнение инструкций байтового кода в основной точке входа загруженного класса 220А. Так как класс Hello 220A использует несколько классов стандартных пакетов, классификационные файлы для используемых классов будут загружены и присоединены к классу Hello 220A. Файл Object.class 210В будет загружен в 220В и присоединен 230В к классу Hello 210A. Подобным образом файл String.class 210С, System.class 210D, и другие классификационные файлы 210, используемые классом Hello, будут загружены в 220С, 220D, 220 и присоединены в 230С, 230D и 230. Класс Hello также использует класс Bye (вспомогательный класс, не являющийся классом стандартного пакета), так что файл Bye.class 210E будет загружен в 220Е и присоединен в 230Е.

И хотя это четко не показано на чертежах, каждый раз, когда классификационный файл 210 загружается в 220 и присоединяться в 230, любые классификационные файлы, которые используются загруженным классом 220, могут быть также загружены и присоединены. Например, в случае загрузки вспомогательного класса Bye 220E, используются многие из тех же классов, что и для класса Hello 210A. В зависимости от того, когда класс Bye 220E загружен и присоединен 230Е, классу Bye 220E не обязательно загружать классификационные файлы 210, являющиеся общими с классами, которые также используются и загружены классом Hello. Однако все классы, используемые Bye 220A, должны в конечном счете быть присоединены к Bye, так же как Hello может использовать вспомогательный класс Bye. Ситуация схожа для классов стандартных пакетов.

Загрузка (в 220) и присоединение (в 230) обычного классификационного файла 210 потребляет значительное количество рабочих ресурсов и может замедлить выполнение «основной» программы 220A в тот момент, когда загрузка и присоединение классификационных файлов запускается спецификацией команды для выполнения программы, что будет обсуждено далее со ссылкой на Фиг.3А и 3В

Далее со ссылкой на Фиг.3А и 3В будет описана блок-схема, иллюстрирующая работу технологии присоединения рабочего цикла, показанной на Фиг.2, в частности раскрывающая дополнительное последнее разрешение. «Основной» класс загружается в 310 из памяти классов 200, такой как жесткий диск или сеть. Класс проверяется и подготавливается в 315. Если последнее разрешение не используется, как указано в 320, все используемые классы присоединяются и загружаются в 325. «Основной» класс инициализируется в 330 независимо от того, используется ли или нет последнее разрешение в 320.

Инструкции из основной точки входа выбираются в 335. Если выбранная инструкция не включает неразрешенную ссылку, как определено в 340, выбранная инструкция выполняется в 345. Однако если выбранная инструкция включает ссылку на неразрешенный идентификатор, как указано в 340, такую как классовая ссылка на класс, который еще не был загружен, тогда если последнее разрешение не используется, как указано в 350, исключение отбрасывается при выполнении. Если последнее разрешение используется, как указано в 350, и если класс, на который ссылаются, не может быть загружен в 355, исключение отбрасывается при выполнении. Однако если последнее разрешение используется, как указано в 350, и класс, на который ссылаются, может быть загружен, класс, на который ссылаются, загружается, и ссылка разрешается в 360 перед выполнением инструкции в 345. Если существуют еще инструкции для выполнения, как указано в 365, то следующая инструкция выбирается в 335, если нет - виртуальная машина заканчивает свою работу.

Если было использовано последнее разрешение, то несколько классификационных файлов загружаются и присоединяются в 360 во время выполнения байтового кода основной программы. Альтернативно, если последнее разрешение не использовалось, несколько классификационных файлов загружаются и присоединяются в 325 перед выполнением байтового кода основной программы, после определения «основного» классификационного файла для JVM 140. В любом случае в промежуток времени между спецификацией «основной программы» для ее выполнения в рабочем процессе JVM 140 и временем, когда основная программа либо завершилась, либо было отброшено исключение, может последовать стремительная трата ресурсов для загрузки и присоединения.

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

Сущность изобретения.

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

Краткое описание чертежей.

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

Фиг.1 представляет собой блок-схему, иллюстрирующую технологию рабочего цикла предшествующего уровня техники;

Фиг.2 представляет собой блок-схему, иллюстрирующую технологию присоединения рабочего цикла, представленного на Фиг.1;

Фиг.3А и 3В представляют собой блок-схемы, которые более подробно иллюстрируют технологию присоединения рабочего цикла, показанную на Фиг.2, в частности чертежи иллюстрируют дополнительное последнее разрешение;

Фиг.4 и 5 представляют собой блок-схемы, иллюстрирующие показанную в качестве примера систему разделенного рабочего цикла;

Фиг.6 и 7 представляют собой блок-схемы, иллюстрирующие различные примеры систем разделенных рабочих циклов;

Фиг.8 представляет собой блок-схему, иллюстрирующую технологию присоединения для системы разделенного рабочего цикла;

Фиг.9 представляет собой блок-схему, дополнительно иллюстрирующую технологию присоединения, показанную на Фиг.8, путем введения стадии связывания с хостом и стадии присоединения к цели;

Фиг.10 - блок-схема, дополнительно иллюстрирующая стадию связывания с хостом, показанную на Фиг.9;

Фиг.11 - блок-схема, дополнительно иллюстрирующая стадию присоединения к цели, показанную на Фиг.9.

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

Сведения, подтверждающие возможность осуществления изобретения.

Подробное описание изобретения.

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

Компилятор (или другое устройство) 405 получает классификационный файл 407, который содержит символьные ссылки 409 на другие классы 411. Компилятор 405 обрабатывает классификационные файлы 407 и 411, выполненные в байтовом коде, таком, что разрешаются символьные ссылки 409. Обрабатываемые классификационные файлы направляются в обрабатывающее устройство 440 как модули 450. Обрабатывающее устройство 440 работает более эффективно на целевых устройствах 430, так как обычно размер модуля существенно меньше обычных рабочих классификационных файлов, например, он может быть примерно восьмикратно уменьшен по сравнению с размером классификационного файла Java. Кроме того, до осуществления многократных выполнении код модуля может быть проверен с использованием санитарных проверок, таким образом увеличиваются скорости последующих выполнении. Модули могут быть сконфигурированы таким образом, чтобы минимизировать кодовую передачу, что особенно важно для связи устройств с ограниченной полосой пропускания. Модули 450 могут быть сконфигурированы таким образом, чтобы минимизировать время установки и выполнения кода, что особенно важно в рабочих циклах устройств с ограниченными ресурсами (возможностями). Модули 450 могут быть приспособлены для существующих обрабатывающих устройств, в то же время поддерживая совместимость с указанными API, как показано на Фиг.5.

Фиг.5 иллюстрирует вариант осуществления, в котором различные механизмы 405А и 405В создают программу 410. Компилятор 405А компилирует программу 410. Альтернативно, для загрузки или получения программы 410 другим способом могут быть использованы другие механизмы 405В. Стандартные пакеты классов 420 представляют собой общие программные ресурсы, используемые повторно разновидностями программ 410. Обрабатывающее устройство 440 получает классы и выполняет программу 410, используя стандартные пакеты классов 420.

Также показаны различные целевые устройства 430, поверх которых работают обрабатывающие устройства 440, такие как мобильное устройство 430А, персональный электронный помощник (PDA) 430B, приспособление 430С, "тонкий" клиент, или другое устройство 430Е.

Как показано на Фиг.5, модули 450 размещены между механизмом, который создает программу 410, и обрабатывающим устройством 440, которое выполняет машинный код. Однако обрабатывающее устройство 440 все еще использует классы в программе 410, а также стандартные пакеты классов 420, отличие заключается в том, что это осуществляется посредством использования модулей 450, а не классификационных файлов напрямую. Классификационные файлы все еще могут быть использованы, так как компилятор принимает на входе как классификационные, так и исходные файлы, а на выходе производит модули.

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

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

В разделенном рабочем цикле хост-системы классификационные файлы (407 и 411) присоединяются в 510 с образованием связанных с хостом модулей 520. Работа по анализу набора закрытых классификационных файлов разгружается в хост-систему 530. В разделенном рабочем цикле целевой системы связанные с хостом модули 520 вызывают присоединения к цели в 550 с образованием присоединенных к цели модулей 560. Если требуется любое дополнительное разрешение класса на целевой системе 430, то нужные дополнительные целевые идентификаторы 562 целевых модулей присоединяются в 550 к связанным с хостом модулям 520 для создания присоединенных к цели модулей 560. Обрабатывающее устройство 440 выполняет присоединенные к цели модули 560.

Фиг.7 представляет собой блок-схему, иллюстрирующую другую систему разделенного рабочего цикла. В хост-системе 530 классификационные файлы 410 связываются с хостом в 510 к связанным с хостом модулям 520. В контексте рассматриваемой системы детали связывания с хостом будут обсуждаться ниже со ссылками на Фиг.8, 9 и 10. В целевой системе 430 связанные с хостом модули 520 устанавливают связь в 540 из хост-системы 530 для присоединения 550 к цели с образованием присоединенных к цели модулей 560. Установление связи 540 между хостом и целью может происходить любым способом (посредством любой среды), обеспечивающим создание модуля(ей) для цели, например через мобильную коммуникационную сеть, если целью является мобильное коммуникационное устройство, или через заключенный в несущем сигнале информационный сигнал. Детали целевого присоединения будут обсуждены ниже со ссылками на Фиг.8, 9 и 11.

Как показано на Фиг.8, блок-схема иллюстрирует загрузку классификационных файлов, разделенное присоединение к модулям и выполнение рабочего цикла разделенного модуля, как показано на Фиг.6 и 7. Работа по анализу набора закрытых классификационных файлов разгружена в хост-систему 400А. Там классификационные файлы 600 загружаются в 610 и присоединяются с образованием связанных с хостом модулей 520А и 520F. Изображен прикладной модуль, например модуль "Hello" 520A, содержащий оптимизированную информацию, найденную в файле Hello.class 610A и файле Bye.class 610E, причем класс Hello предварительно присоединен к классу Bye. Модуль 520A также содержит символьную ссылку 615 на библиотечный модуль 520F, который содержит в себе все стандартные пакеты классов, которые используют классы Hello и Bye, такие как классы, представленные классификационным файлом Object 610B, классификационным файлом String 610С, классификационным файлом System 610D, и другими классификационными файлами 610. Библиотечный модуль 520F может экспортировать все доступные символы, такие, что многие другие «основные» классы, такие как Hello, могут повторно использовать все файлы стандартных пакетов классов. Альтернативно, библиотечный модуль может содержать только лишь те классификационные файлы, которые используются классами Hello и Bye, или даже все используемые классы могут быть включены непосредственно в модуль 520A. В последнем случае исключается потребность в любом символьном разрешении на целевой системе.

Когда доступен по крайней мере один присоединенный к хосту модуль (520А и/или 520F), возможно установить связь в 540 с модулем-кандидатом 620А и 620F для разделения рабочего цикла на целевой системе 400В. Как только модули-кандидаты (620А и 620F) получены целевой системой, модуль присоединяется к присоединенному к цели модулю 560А и 560F, и любые модульные символьные ссылки 615 разрешаются, как показано в 630. Основной модульный класс, такой как класс Hello 640, может быть специфицирован для выполнения. Однако преимущественно, каждый раз, когда выполняется основная программа класса Hello, не возникает потребности в разрешении ссылки 650, так это обеспечивается присоединением к цели 630.

Блок-схема на Фиг.9 дополнительно иллюстрирует технологию присоединения, показанную на Фиг.8, путем описания стадии присоединения хоста и стадию присоединения цели. В системе разделенного рабочего цикла на хосте классы 600 загружаются и присоединяются к хосту в 800 с образованием связанных с хостом модулей 520. Потом, по крайней мере, один присоединенный к хосту модуль 520 направляется к системе разделенного рабочего цикла на цели.

В системе разделенного рабочего цикла на цели в 720 с хоста получают, по крайней мере, один присоединенный к хосту модуль-кандидат 620. Присоединенный к хосту модуль-кандидат 620 присоединяется к цели в 900 с образованием присоединенного к цели модуля 560. По крайней мере, один присоединенный к цели модуль 560 выполняется в 730. Если новый модуль является искомым, как показано в 740, могут начать повторяться процесс 800 связывания с хостом, коммуникационные процессы (710 и 720) и процесс 900 присоединения к цели. Однако если ни один новый модуль не является искомым, то повторное выполнение в 730 присоединенных к цели модулей будет продолжаться без дополнительных загрузок и присоединений.

Блок-схема на Фиг.10 дополнительно иллюстрирует описанную на Фиг.9 стадию связывания с хостом. В системе разделенного рабочего цикла на хосте экспортированные символы связанных с хостом модулей 520 создают в 810 внешние модульные идентификаторы 815. Кроме того, классы 600 создают в 820 хост классы-кандидаты 825. Классовые ссылки в хост классах-кандитах 825 заменяются в 830 на модульные ссылки с использованием внешних модульных идентификаторов 815, создавая таким образом закрытый набор модульных классов-кандидатов 835. Затем в 840 создаются идентификаторы 845, экспортированные модулем-кандидатом. Затем модульные классы-кандидаты 835 и экспортированные идентификаторы 845 проверяются в 850. Если результат проверки удовлетворителен 860, то в 870 присоединенный к хосту модуль-кандидат создается как присоединенный к хосту модуль 520. Если результаты проверки неудовлетворительны 860, исключение отбрасывается.

Блок-схема на Фиг.11 дополнительно иллюстрирует стадию присоединения к цели, показанную на Фиг.9. В системе разделенного рабочего цикла на устройстве полученный модуль-кандидат 620 создает в 910 ссылки 915 модуля-кандидата. Кроме того, присоединенные к цели модули 560 создают в 920 целевые модульные идентификаторы 925. Затем разрешение модульных ссылок в модуле-кандидате создает в 930 разрешенный модуль 935. Разрешенный модуль 935 проверяется в 940, и если результаты проверки удовлетворительны, как указано в 950, то разрешенный модуль 935 сохраняется в 960 с другими присоединенными к цели модулями. Однако если результаты проверки неудовлетворительны, как указано в 950, исключение отбрасывается.

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

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

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

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

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

3. Мобильное коммуникационное устройство по п.2, отличающееся тем, что целевая система содержит средства для присоединения к цели для присоединения предварительно присоединенного модуля к другим модулям для использования приложением.

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

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

6. Мобильное коммуникационное устройство по п.1, отличающееся тем, что предварительно присоединенный модуль является проверенным.

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

8. Мобильное коммуникационное устройство по п.1, отличающееся тем, что предварительно присоединенный модуль содержит множество модулей, и упомянутые модули присоединяются динамически, тем самым по существу сводя к минимуму количество символьных ссылок.

9. Мобильное коммуникационное устройство по п.1, отличающееся тем, что приложение выполнено с возможностью работы с устройством, причем предварительно присоединенный модуль непосредственно выполнен как память на устройства.

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

11. Мобильное коммуникационное устройство по п.1, отличающееся тем, что предварительно присоединенный модуль создают перед выполнением приложения.

12. Мобильное коммуникационное устройство по п.1, отличающееся тем, что предварительно присоединенный модуль конфигурируют на основе времени установки и выполнения кода.

13. Мобильное коммуникационное устройство по п.1, отличающееся тем, что приложение работает на устройстве с ограниченной полосой пропускания.

14. Мобильное коммуникационное устройство по п.1, отличающееся тем, что приложение работает на мобильном информационном устройстве.

15. Мобильное коммуникационное устройство по п.1, отличающееся тем, что приложение работает на персональном электронном помощнике.

16. Мобильное коммуникационное устройство по п.1, отличающееся тем, что приложение работает на приспособлении.

17. Мобильное коммуникационное устройство по п.1, отличающееся тем, что приложение работает на приложении «тонкого» клиента.

18. Мобильное коммуникационное устройство по п.1, отличающееся тем, что классы включают основанные на Java классы.

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

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

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

22. Способ по п.19, отличающийся тем, что целевая система содержит устройство с ограниченной полосой пропускания.

23. Способ по п.19, отличающийся тем, что целевая система содержит обрабатывающее устройство для выполнения приложения.

24. Способ по п.19, отличающийся тем, что целевая система содержит виртуальную машину для выполнения приложения.

25. Способ по п.19, отличающийся тем, что целевая система содержит мобильное информационное устройство.

26. Способ по п.19, отличающийся тем, что целевая система содержит персональный электронный помощник.

27. Способ по п.19, отличающийся тем, что целевая система содержит приспособление.

28. Способ по п.19, отличающийся тем, что целевая система содержит приложение «тонкого» клиента.

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

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

31. Способ по п.19, отличающийся тем, что классы включают в себя основанные на Java классы.

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

33. Способ по п.19, отличающийся тем, что присоединенный к хосту модуль включает в себя множество модулей, которые содержат все классы, требуемые приложением.

34. Способ по п.19, отличающийся тем, что присоединенный к хосту модуль содержит множество модулей, которые присоединены динамически, тем самым по существу сводя к минимуму количество символьных ссылок.

35. Способ по п.19, отличающийся тем, что связанные с хостом модули выполняют непосредственно из памяти на целевой системе.

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

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

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

39. Способ по п.19, отличающийся тем, что присоединенный к хосту модуль создают перед выполнением приложения.

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

41. Способ по п.19, отличающийся тем, что присоединенный к хосту модуль конфигурируют на основе времени установки и выполнения кода.

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

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