RU2250490C2 - Предоставление расширений программного обеспечения на основе использования сети - Google Patents

Abstract

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

Description

Область техники

Данное изобретение касается способов и систем для предоставления программного обеспечения через сеть. В частности, изобретение касается поставки программного обеспечения на основе Интернет.

Обзор известных технических решений

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

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

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

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

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

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

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

Перечень чертежей

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

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

Фиг.3 представляет пример файла описания расширения (EDF) и декларации пакета (PKG) в соответствии с одной из описываемых форм осуществления изобретения.

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

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

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

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

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

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

Фиг.10 представляет собой блок-схему, которая описывает шаги способа в соответствии с одной из описываемых форм осуществления изобретения.

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

Фиг.12 представляет собой блок-схему, которая описывает шаги способа в соответствии с одной из описываемых форм осуществления изобретения.

Фиг.13 представляет собой блок-схему, которая описывает шаги способа в соответствии с одной из описываемых форм осуществления изобретения.

Фиг.14 представляет собой блок-схему шагов способа в соответствии с одной из описываемых форм осуществления изобретения.

Фиг.15 представляет собой блок-схему шагов способа в соответствии с одной из описываемых форм осуществления изобретения.

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

На фиг.17 показана блок-схема архитектуры программного обеспечения в соответствии с одной из описываемых форм осуществления изобретения.

Фиг.18 представляет собой блок-схему шагов способа в соответствии с одной из описываемых форм осуществления изобретения.

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

На фиг.20 показана схема, которая иллюстрирует один из аспектов архитектуры, показанной на фиг.17.

Подробное описание предпочтительной формы осуществления изобретения

Краткий обзор

Способы и системы, описываемые ниже, обеспечивают механизм, с помощью которого к компьютерной программе ("приложению") или программной платформе могут быть динамически добавлены новые функциональные возможности. Функциональные возможности, или "расширения", как они будут здесь называться, удобно добавлять через сеть, такую как Интернет. Расширения, которые могут выполнять новые функции или добавлять возможности существующим функциям, можно добавлять, используя только сетевой адрес, например унифицированный указатель ресурсов (URL), как основу для инсталляции (установки) расширения. То есть все файлы, которые составляют расширение, могут находиться в сети и быть доступными через один или несколько сетевых сайтов.

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

Рассмотрим, например, фиг.1, где показан компьютер 100 пользователя и несколько так называемых источников 102, 104 и 106 расширений. Источник расширения может представлять собой любой объект, от которого через сеть может быть получено расширение для программного обеспечения. В одном примере осуществления изобретения сеть может быть сетью Интернет, хотя, конечно, могут использоваться и другие сети (например, локальные и глобальные сети). Источники расширений могут включать коммерческие организации, такие как магазины розничной торговли, которые могут использовать сетевой сайт, но не ограничиваются такими организациями. В одном из вариантов осуществления изобретения пользователь может использовать программное обеспечение на своем компьютере, который предоставляет пользователю компьютерную программу или платформу программного обеспечения. В этом документе термины "компьютерная программа" ("приложение") и "платформа программного обеспечения" ("программная платформа") будут использоваться взаимозаменяемо. Каждый из различных источников 102-106 расширений может предоставлять расширения программного обеспечения, которые могут включаться в платформу программного обеспечения, работающую на машине пользователя. Эти расширения могут доставляться через сеть, такую как Интернет, и помогать работе приложений, которые могут выполняться на машине пользователя. В описываемой форме осуществления изобретения расширения логически описываются на XML (extensible Markup Language - расширяемый язык разметки), который соответствует новым промышленным стандартам. Кроме того, в будущем использование XML будет способствовать открытости расширений благодаря поддержке использования в Интернет свойств объектных моделей документов (DOM - Document Object Model) XML. Однако должно быть ясно, что для описания расширений может использоваться любой подходящий формат, например двоичное описание.

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

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

Пример компьютерной среды

Форма осуществления изобретения, описываемая ниже, может использоваться в сочетании с различными компьютерными системами. Под компьютерной системой в этом описании понимается любое компьютерное устройство, которое содержит процессор какого-нибудь типа, то есть микропроцессор, и операционную систему какого-нибудь типа. Таким образом, компьютерная система включает (но не ограничивается ими) традиционные настольные компьютеры, более мощные серверы, различные карманные устройства, такие как мобильные телефоны, карманные компьютерные устройства и т.п.

На фиг.2 показан пример компьютерной системы, которая может использоваться для осуществления описываемых здесь вариантов выполнения изобретения. Компьютер 130 содержит один или несколько процессоров или процессорных блоков 132, системную память 134 и шину 136, которая соединяет различные элементы системы, в том числе подключает системную память 134 к процессору 132. Шина 136 представляет собой одну или несколько шинных структур какого-либо из нескольких возможных типов, включая шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессорную или локальную шину, использующую какую-либо из разнообразных шинных архитектур. Системная память 134 включает постоянное запоминающее устройство 138 (ROM) и оперативную память 140 (RAM). Базовая система 142 ввода-вывода (BIOS), содержащая основные управляющие программы, которые помогают пересылать информацию между элементами в пределах компьютера 130, например, во время начальных действий (запуска), хранится в постоянном запоминающем устройстве 138.

Кроме того, компьютер 130 содержит дисковод 144 жесткого диска (не показан) для чтения и записи, дисковод 146 съемного магнитного диска 148 для чтения и записи и оптический дисковод 150 для чтения или записи с использованием съемного оптического диска 152, такого как компакт-диск или другой оптический носитель информации. Дисковод 144 жесткого диска, дисковод 146 магнитного диска и оптический дисковод 150 подключены к шине 136 с помощью интерфейса 154 типа SCSI или некоторого другого подходящего интерфейса. Дисководы и связанные с ними компьютерно-читаемые носители информации обеспечивают хранение, не зависящее от наличия электропитания, компьютерно-читаемых команд, информационных структур, образованных записанными данными, программных модулей и других данных для компьютера 130. Хотя в описываемом здесь примере используются жесткий диск, съемный магнитный диск 148 и съемный оптический диск 152, специалистам должно быть понятно, что в такой операционной среде могут использоваться и другие типы компьютерно-читаемых носителей информации, способных запоминать данные, которые доступны компьютеру, например магнитные кассеты, карты флэш-памяти, цифровые видеодиски, блоки памяти с произвольным доступом, блоки постоянной памяти и т.п.

На жестком диске 144, магнитном диске 148, оптическом диске 152, в постоянной памяти 138 или в оперативной памяти 140 могут храниться несколько программных модулей, включающих операционную систему 158, одну или несколько программ-приложений 160, другие программные модули 162 и данные 164 программ. Пользователь может вводить команды и информацию в компьютер 130 через устройства ввода данных, такие как клавиатура 166 и указывающее устройство 168. Другие устройства ввода данных (не показаны) могут включать микрофон, джойстик, игровой пульт, спутниковую антенну, сканер или аналогичные устройства. Эти и другие устройства ввода данных связаны с процессором 132 через интерфейс 170, который соединен с шиной 136. Монитор 172 или устройство отображения другого типа также связан с шиной 136 через интерфейс, такой как видеоадаптер 174. В дополнение к монитору персональные компьютеры обычно имеют и другие периферийные устройства вывода (не показаны), такие как громкоговорители и принтеры.

Компьютер 130 обычно работает в сети, используя логические соединения с одним или несколькими удаленными компьютерами, например с удаленным компьютером 176. Удаленным компьютером 176 может быть другой персональный компьютер, сервер, маршрутизатор, сетевой персональный компьютер, равноправное устройство или другой обычный сетевой узел и, как правило, он включает многие или все элементы, описанные выше для компьютера 130, хотя на фиг.2 показано только запоминающее устройство 178. Логические подключения, показанные на фиг.2, включают локальную сеть 180 (LAN) и глобальную сеть 182 (WAN). Такие сетевые конфигурации являются обычными для офисов, компьютерных сетей предприятий, интрасетей и Интернет.

При работе в локальной сети компьютер 130 связывается с локальной сетью 180 через сетевой интерфейс или адаптер 184. При работе в среде глобальной сети компьютер 130 обычно содержит модем 186 или другие средства для установления связи в глобальной сети 182, такой как Интернет. Модем 186, который может быть внутренним или внешним, подключается к шине 136 через интерфейс 156 последовательного порта. В среде с сетевой архитектурой программные модули, описанные здесь в связи с персональным компьютером 130, или их части могут храниться в удаленном запоминающем устройстве. Должно быть понятно, что показанные сетевые подключения являются только примерами, и могут использоваться другие средства установления связи между компьютерами.

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

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

Расширения

Термин "расширение" в этом описании включает в себя (но не ограничивается этим) функции и содержание (контент) программы, которые могут быть добавлены к программе-приложению или платформе программного обеспечения. Эти дополнения обычно предоставляют пользователю некоторые новые функциональные возможности, которых программа не обеспечивала до включения в нее такого расширения, или изменяют поведение (характер работы) по меньшей мере одной из существующих функций программы. Расширение встраивается или интегрируется непосредственно в программу так, что в некоторой степени изменяется поведение или работа программы. Расширения предоставляют динамически добавляемое содержание и могут предоставлять пользователю приложения (например, программу электронной почты), подключаемые модули для расширения существующих приложений (подобно факсимильному модулю, подключаемому к программе электронной почты) или просто веб-страницы; здесь перечислены только некоторые из возможных расширений.

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

Пример организации расширения

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

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

На фиг.3 показан пример структуры 300 расширения, которая включает файл 302 описания расширения и соответствующую декларацию 304 пакета (PKG). В показанном примере в файле 302 описания расширения используется XML, чтобы описать логические дополнения или расширения к прикладной программе. Соответствующий файл PKG 304 определяет физические файлы и ресурсы, которые связаны с конкретным расширением. Примеры типов этих файлов показаны справа от PKG 304 и включают, не ограничиваясь этим, файлы НТМ, GIF, UDO, XML, DLL и различные другие типы файлов.

Файл описания расширения (EDF)

В описываемом примере файл описания расширения является XML-файлом, который логически описывает расширение. Например, файл описания расширения может описывать HTML (язык разметки гипертекста), который формирует интерфейс пользователя (UI), объекты, которые содержат код для осуществления различных функций, и т.п. Файл описания расширения может также содержать все или часть функций, которые составляют расширение. Например, код HTML, который описывает панель инструментов, может быть непосредственно включен в состав файла описания расширения, и менеджер присоединения панели инструментов может считывать его из файла описания расширения, вместо чтения по адресу, указанному с помощью URL. Информация, содержащаяся в файле описания расширения, обрабатывается (вместе с информацией, содержащейся в PKG), и соответствующие файлы автоматически инсталлируются в компьютер пользователя. Это делается малозаметно, без манипулирования постоянными параметрами настройки компьютера, которое могло бы быть обнаружено в системном реестре пользователя.

Файл описания расширения, написанный на XML, содержит различные тэги, которые связаны с различными расширениями. Эти различные тэги могут соответствовать:

- элементам интерфейса пользователя;

- поведениям/компонентам/объектам;

- элементам хранения;

- объектам, определяемым пользователем;

- или чему-нибудь еще, что предоставляет точку расширяемости в приложении или платформе.

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

Таблица 1
Тип элемента	Определение
Tool Bars (Панели инструментов)	Горизонтальные контейнеры для команд над областью документа
Accelerators (Акселераторы)	Горячие клавиши для команд
Menu Items (Пункты меню)	Пункты всплывающего или раскрывающегося меню, которые третьи стороны могут добавлять к известным, имеющим имя, меню в платформе
Themes (Темы)	Управляемый данными способ замещения известных ресурсов платформы, таких как задаваемые по умолчанию кнопки или таблица стилей

Типичные предопределенные тэги XML для поведения/компонентов/объектов включают тэги для служб ("Сервисов"). Функциональные элементы этого типа используются в однооконном приложении с возможностью навигации и приведены в следующей таблице:

Таблица 2
Тип элемента	Определение
Services (Сервисы)	Сервисы - это объекты, которые расширяют существующие объекты (такие как приложение, окно или документ) в Объектной Модели платформы или приложения. Например, функции редактирования используют Дополнения Объектной Модели, присоединяемые к окну или документу, которые поддерживают контекст документа и состояние редактирования для каждого окна. Они могут также включать Дополнения Объектной Модели, присоединяемые к приложению (такие как объект словаря для проверки правописания)

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

Таблица 3
Тип элемента	Определение
Content Classes (Классы Контента)	Позволяют авторам расширений задавать новые типы XML-документов с новыми схемами.
Offline Data Sources (Автономные источники данных)	Позволяют авторам расширений задавать команды репликации памяти в файле описания расширения.

Схема файла описания расширения

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

На фиг.4 показан пример тэга расширения. Тэги "extension" могут содержать один или несколько из следующих атрибутов, все они являются необязательными:

Таблица 4
Атрибут	Определение
Urn (Унифицированное имя ресурса)	Идентификатор для расширения. Позволяет авторам расширения указать относительные местоположения для содержимого в файлах описания расширения без использования относительных путей или фиксированных адресов URL. Также позволяет администраторам хостинга перемещать расширения на серверах без нарушения каких-либо связей.
Name (Имя)	Имя, которое может использоваться в строке состояния или при отображении сообщения
Version (Версия)	Определяемый продавцом номер версии расширения.
lastUpdate	Дата/время, когда файл описания расширения был последний раз изменен.
description (описание)	Краткое описание расширения.

Внутри внешнего тэга "extension" имеется один или несколько дочерних тэгов, называемых также "тэги верхнего уровня". Каждый из этих тэгов верхнего уровня связан с типом элемента, который может быть добавлен посредством определенного расширения. Примеры типов элементов рассмотрены выше в таблицах 1-3. Под каждым тэгом верхнего уровня может иметься один или несколько дочерних тэгов, по отдельности связанных с определенными элементами, относящимися к тому типу элементов, который должен быть добавлен посредством конкретного расширения.

На фиг.5 показан пример построения XML схемы в соответствии с данной формой осуществления изобретения. Для каждого тэга верхнего уровня в файле описания расширения имеется связанный с ним "менеджер присоединения", который является программным компонентом, принимающим данные, связанные с тэгом, так, чтобы эти данные могли использоваться для включения расширения в платформу или программу. Различные менеджеры присоединения могут интерпретировать данные от тэга различными способами, чтобы обеспечить различные типы расширяемости, так что различные тэги верхнего уровня будут содержать различные типы данных в различных структурах. Это будет пояснено ниже в разделе "Архитектура". Обратим внимание на то, что спецификатор пространства имен XML "edf:" допускает поддержку открытой схемы, где расширения могут предоставлять свои собственные тэги и соответствующие менеджеры присоединения. Тэги в пределах пространства имен edf используются встроенными менеджерами присоединения в приложении или платформе программного обеспечения. Тэги в других пространствах имен используются третьими сторонами для предоставления дополнительных точек расширяемости.

Декларация пакета (файл PKG)

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

При разработке механизма поставки программного обеспечения или файлов с помощью WWW представляют интерес несколько соображений.

Где это только возможно, желательно уменьшать объем загрузок, необходимых во время операций обновления и инсталляции программного обеспечения. Из этих соображений содержимое программного обеспечения разбивается на множество пакетов. Каждый пакет содержит группу из одного или нескольких файлов, которые осуществляют общие или строго определенные функции. При разбиении содержимого на отдельные пакеты размер требуемой загрузки во время инсталляции и обновления может быть минимизирован. Каждый пакет при этом описывается декларацией пакета (PKG), которая содержит информацию о файлах, например местоположение файлов и значения хеш-функции, которые могут использоваться для проверки правильности (верификации) или защиты от несанкционированного доступа и контроля версий.

Также желательно создать для конечного пользователя впечатление, подобное веб-странице. Чтобы сделать это, расширения загружаются таким образом, что эта загрузка воспринимается пользователями скорее как загрузка страниц сети, чем прием традиционных пакетов программного обеспечения, когда пользователи должны ждать, пока не будет загружен полный пакет, прежде чем они смогут взаимодействовать с ним. В описываемой форме осуществления изобретения у пользователей создают впечатление просмотра веб-страницы, направляя поток файлов расширения клиенту так, чтобы пользователи могли начинать взаимодействовать с программой намного раньше, чем она будет загружена целиком. Например, если имеются файлы изображений пользовательского интерфейса (UI), передаваемые потоком, пользователь может видеть пользовательский интерфейс при поступлении этого потока файлов. Рассмотрим, например, единую программу, имеющую множество разных функций.

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

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

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

Все эти соображения и новые решения, учитывающие их, более подробно рассматриваются ниже.

Определение декларации пакета

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

Кроме того, декларация пакета может определять несколько других блоков информации:

- ГРУППА ФАЙЛОВ

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

- ПРИОРИТЕТ ЗАГРУЗКИ ФАЙЛОВ

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

- ЗНАЧЕНИЕ ХЕШ-ФУНКЦИИ ДЛЯ ЗАЩИТЫ/КОНТРОЛЯ ВЕРСИЙ

Индивидуальные файлы в декларации пакета могут иметь сопоставленные им значения хеш-функции. Каждое значение хеш-функции генерируют, пропуская файл через алгоритм шифрования. Типичным алгоритмом шифрования является CryptoAPI фирмы Майкрософт. В описываемом примере каждый файл может быть внесен в список вместе со значением хеш-функции, кодированным с 64-значным основанием, так что файл может быть проверен, как только он достигнет клиента. А именно, декларация пакета посылается клиенту безопасным способом (то есть она снабжается электронной цифровой подписью). Декларация пакета содержит значения хеш-функции для отдельных файлов. Когда отдельные файлы получены клиентом, каждый из файлов может быть пропущен через тот же самый алгоритм CryptoAPI, который использовался, чтобы получить значения хеш-функции для декларации пакета. Если значения хеш-функций для конкретного файла совпадают, то файл не был изменен и является безопасным.

Когда файл обновляется, значения хеш-функции могут обеспечить идентификацию тех файлов, которые одинаковы в различных версиях расширения. Рассмотрим, например, фиг.7. Здесь старый каталог 700 в кэше пакетов клиента содержит пакет, который состоит из двух файлов: файла 1 со значением хеш-функции hash=x и файла 2 со значением хеш-функции hash=y. Предположим, что этот пакет связан со старой версией расширения. Когда создается обновленная версия, ее декларация пакета поставляется клиенту. Обновленная версия расширения находится в исходном каталоге программного кода на веб-сервере 704. Декларация пакета содержит значения хеш-функции для всех файлов в новой версии расширения. Новый целевой каталог 702 клиента задан для всех файлов нового расширения. Если некоторые из значений хеш-функции для файлов в новом расширении совпадают со значениями хеш-функции файлов в старом каталоге 700, то эти файлы могут быть скопированы непосредственно из старого каталога 700 в новый целевой каталог 702. В этом примере значение хеш-функции для файла 1 то же самое, что и значение хеш-функции для файла 1 в исходном каталоге 704, так что файл 1 может быть скопирован в новый целевой каталог 702. Значение хеш-функции для файла 2, однако, отличается от значения хеш-функции для файла 2 в исходном каталоге, так что файл 2 не копируется из старого каталога 700. Вместо этого файл 2 загружается с сервера. Новый файл 3 был добавлен и он также загружается с сервера. Следовательно, в этом примере новая версия расширения приводит к загрузке меньшего числа файлов, чем все файлы в этой версии расширения. Это достигнуто благодаря тому, что значения хеш-функции для каждого из файлов старой версии расширения можно сравнить со значениями хеш-функции файлов в новой версии расширения. Те значения хеш-функции, которые являются одинаковыми, указывают на файлы, которые не изменились в разных версиях.

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

- ПОЛНЫЙ ОБЪЕМ ПАМЯТИ ДЛЯ ХРАНЕНИЯ ПАКЕТА

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

- ИДЕНТИФИКАТОРЫ КЛАССОВ ДЛЯ БИБЛИОТЕК DLL

Список идентификаторов классов ClasslD для каждой динамически подсоединяемой библиотеки DLL необходим, чтобы дать возможность авторам скриптов создавать классы при написании скриптов для объектной модели. Дополнительно это позволяет определить, какой пакет содержит код для конкретного класса.

- ЗАВИСИМОСТИ ЗАГРУЗОК БИБЛИОТЕК DLL

Цель использования раздела с зависимостями состоит в том, чтобы предоставить наследуемый код, который должен быть загружен в силу того, что находится в пути поиска некоторой другой динамически подсоединяемой библиотеки. В этом случае прежде, чем будет загружаться зависимая динамически подсоединяемая библиотека, необходимо удостовериться, что динамически подсоединяемая библиотека, от которой она зависит, находится в каталоге кэша пакетов. На фиг.6 показана типичная декларация 600 пакета, которая написана на иерархическом языке, основанном на тэгах. Удобно, если таким языком служит XML, который является расширяемым и гибким. В этом примере множество тэгов размещено в иерархическом порядке. Тэг "package" ("пакет") содержит информацию о размере пакета. Тэг "files" ("файлы") является дочерним для тэга "package" и содержит информацию о группах файлов, которые находятся в этом конкретном пакете. Тэг "file" ("файл") является дочерним для тэга "group" ("группа") и содержит информацию относительно конкретных файлов, которые входят в состав расширения, то есть имена файлов и значения хеш-функции. Тэг "dependency" ("зависимость") является дочерним элементом тэга "file" и перечисляет все зависимости, как указано выше. Тэг "COMCIass" также является дочерним для тэга "file" и содержит идентификаторы ID, как упомянуто выше. Расстановка групп файлов в этой схеме неявно определяет порядок загрузки файлов.

Доставка пакета

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

Во-вторых, используется способ фоновой загрузки. Фоновые загрузки дают возможность пользователю продолжать работать в прикладной программе, в то время как загружается контент. Приоритетные (не фоновые) загрузки используются, когда пользователь явно запрашивает файл/расширение, например, щелкая на ссылке расширения, или запрашивает выполнение действия, например, нажимая на кнопку почтовой программы "Compose" ("Составить"), которое требует загрузки файлов, недоступных локально.

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

- унифицированный указатель ресурса (URL) для информации о декларации пакета на сервере кода;

- унифицированное имя ресурса (URN) для целевого каталога пакета в кэше пакетов у клиента;

- (необязательное) унифицированное имя ресурса (URN) для старого каталога пакета (если он существует) в кэше пакетов.

Исходя из этой информации, менеджер пакета создает пакетный объект и добавляет его в очередь загрузки. Очередь загрузки предназначена для простого перераспределения порядка загрузки пакетов. Рассмотрим, например, фиг.8, на которой показана часть очереди 800 загрузки, содержащая два объекта: пакетный объект 802 (соответствующий пакету А) и пакетный объект 804 (соответствующий пакету В). Пакетные объекты используют список, указывающий, какие файлы соответствующего пакета были загружены или инсталлированы. В данном примере файлы 1 и 2 из пакета А были инсталлированы, в то время как файл 3 не был инсталлирован; а файлы 1, 2 и 3 из пакета В не были инсталлированы. Очередь загрузки может быть переупорядочена на основании того, что делает пользователь. То есть, на основании действий, которые предпринимает пользователь, приоритет файлов, которые должны быть загружены, может быть изменен. В этом примере менеджер пакетов намеревается обработать первый неинсталлированный файл в пакете в начале очереди загрузки. Однако, если пользователь начинает использовать файл из расширения, которое отличается от того расширения, файлы которого находятся в начале очереди загрузки, то пакет, соответствующий файлу, который пользователь начал использовать, может быть перемещен в начало очереди загрузки. Поскольку пакет файла определен его унифицированным именем ресурса (URN), пакет файла может быть быстро идентифицирован и помещен в очередь загрузки. Например, см. фиг.8, если один из файлов пакета В запрашивается до того, как менеджер пакетов начал инсталлировать файл 3 пакета А, то пакет В будет перемещен в начало очереди загрузки.

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

На шаге 900 принимается один или несколько запросов на расширение. Запросы могут быть сформированы любым подходящим способом. На шаге 902 создается пакетный объект, соответствующий каждому пакету расширения, который должен быть загружен. На шаге 904 пакеты помещаются в очередь загрузки. Затем на шаге 906 загружаются файлы, соответствующие пакетам из очереди загрузки. Загрузка может, например, начинаться с начала очереди и продолжаться до тех пор, пока все файлы пакета не будут загружены, а затем перемещаться к следующему пакету. На шаге 908 выясняется, не требует ли действие пользователя какого-либо файла, который не описан в текущем пакетном объекте. Если действие пользователя не требует такого файла, то согласно способу выполняется возвращение назад, к шагу 906, и продолжается загрузка файлов, связанных с текущим пакетом. С другой стороны, если действие пользователя требует файлов, которые не описаны в текущем пакетном объекте, то тогда на шаге 910 пакетный объект, связанный с требуемым файлом, перемещается в начало очереди загрузки и начинается загрузка файлов, связанных с этим перемещенным в очереди объектом. Этот шаг может быть реализован посредством выяснения того, какие из пакетных объектов связаны с требуемым файлом, что осуществляется путем установления унифицированного имени ресурса (URN), связанного с файлом. Это унифицированное имя ресурса (URN) определяет пакет файла так, чтобы его пакетный объект мог быть быстро найден и перемещен в головную часть очереди загрузки.

Создание пакета

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

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

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

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

Инструментальное средство автоматизированного создания декларации пакета

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

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

- каталог расширения;

- информация о группах файлов и зависимостях загрузки библиотек DLL (необязательный параметр);

- статистика использования файла на основании выполнении сценария (необязательный параметр).

Входной параметр "каталог расширения" определяет каталог, содержащий все файлы, которые будут описаны в декларации пакета. Если этот параметр является единственным, то средство 1100 генерирует декларацию, в которой файл описания расширения и динамически подсоединяемые библиотеки в каталоге перечисляются в наборе "Required" ("необходимые"), а все остальное содержимое является "Offline" ("автономным").

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

Параметр статистики использования файла на основе выполнении сценария является необязательным параметром. Этот параметр позволяет определять приоритет загрузки файла на основании выполнении сценария. Сценарий является последовательностью действий, которой средний пользователь обычно придерживается во время конкретного этапа использования продукта. Например, один из сценариев может относиться к задачам, связанным с посылкой сообщения электронной почты, (то есть, нажать кнопку "new mail" ("новое сообщение"), напечатать имя получателя в клетке "ТО" ("Кому"), напечатать тему сообщения в клетке "Subject" ("Тема") и т.д.). В описываемой форме осуществления изобретения статистические данные использования файла на основе выполнении сценария собираются из протоколов работы IIS (информационных служб Интернета) для различных сценариев. Различные сценарии направлены на обеспечение, с некоторой степенью вероятности, того, что порядок загрузки файлов будет некоторым образом учитывать, какие файлы будут использованы пользователем первыми.

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

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

В одном из вариантов используется несколько более сложный способ. Дополнительная информация (в дополнение к сценарным шагам) сохраняется в протоколе регистрации IIS и включает приоритет сценария и контрольные точки. Приоритет сценария является приоритетом, который назначается для каждого сценария. Так, например, если один сценарий в десять раз более важен, чем другой сценарий, эта информация может учитываться. Приоритет (например, оценка в диапазоне от 1 до 100, где 100 является самым высоким приоритетом) должен равняться наилучшему предположению для процента времени, в течение которого пользователи будут проходить по сценарию, при условии, что они вообще используют данное расширение. Контрольные точки обеспечивают возможность отделить один сценарий от другого. Например, контрольные точки, обозначенные как "Offline" и "Shutdown" ("Автономно" и "Завершение") могут автоматически добавляться в начало и конец сценариев соответственно, так что в протоколе может быть установлено различие между выполнениями сценариев. Дополнительно, авторы скриптов могут факультативно использовать контрольные точки в середине сценария, чтобы указывать изменение в приоритете группы; например, часть скрипта сценария может быть помечена как "On demand" ("По требованию"), а другая часть может быть помечена как "Offline" ("Автономно").

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

На шаге 1200 предоставляется средство создания декларации пакета. Этот средство может быть программным средством, которое постоянно находится в машине автора расширения. На шаге 1202 в качестве первого входного параметра принимается информация о каталоге расширения. На этом шаге определяется, имеется ли какая-либо информация о группе файла или информация о зависимостях загрузки, предоставленная автором расширения. Если имеется, то на шаге 1206 эта информация принимается как входной параметр. На шаге 1208 определяется, имеется ли какая-либо статистическая информация об использовании файла. В одной из форм осуществления изобретения такую информацию можно получать исходя из выполнении сценария, как описано выше. Если такая информация предоставляется, то тогда на шаге 1210 эта информация принимается как входной параметр. Затем на шаге 1212 вся информация, предоставленная в качестве входных параметров, используется для автоматического формирования декларации.

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

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

На шаге 1300 файлы сортируются по группам файлов. Напомним, что в вышеприведенном примере файлы могли группироваться в одну из четырех возможных групп: Required, Offline, On Demand и Online Only (Необходимые, Автономные, По требованию и Только в онлайновом режиме). Сначала группа файла определяется в соответствии с декларацией, а если она не дает никакой информации о группе, то по группе с самым высоким приоритетом, которую она использует согласно информации о контрольной точке в файле журнала. Файлы в наборе Required ("Необходимые") не должны рассматриваться, поскольку их порядок загрузки уже известен. Если никакая информация о группе не содержит данные о файле, то делается предположение, что файл описания расширения и все динамически подсоединяемые библиотеки являются Required ("Необходимыми") файлами, а все другие файлы в каталоге -Offline ("Автономными").

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

Сценарий 1 использования файла: 1) FileA.gif, 2) FileB.xml, 3) FileE.dll

Сценарий 2 использование файла: 1) FileC.xml, 2) FileA.gif

Сценарий 3 использование файла: 1) FileD.js, 2) FileA.gif

Сценарий 1 = приоритет 80

Сценарий 2 = приоритет 80

Сценарий 3 = приоритет 40

В этом примере имеются три сценария, которые имеют связанные с ними файлы. Каждый из сценариев имеет приоритет, который ему присваивается. Файлы сначала сортируются по группам (на шаге 1300). Напомним, что в эвристической процедуре упорядочивания динамически подсоединяемые библиотеки являются Required ("Необходимыми"), а все другие файлы рассматриваются как Offline ("Автономные"). Это дает следующие отсортированные группы файлов:

Необходимые файлы

FileE

Автономные файлы

FileA, FileB, FileC, FileD

На шаге 1302 файлы сортируются на основе приоритетов сценариев (от самого высокого к самому низкому). Файлы с более высоким приоритетом упорядочивают так, чтобы они были загружены первыми. Этот шаг обеспечивает следующую сортировку файлов:

Необходимые файлы

FileE

Автономные файлы

Группа с приоритетом 80:

файлы, используемые в Сценариях 1 и 2 = File A, File В и File С

Группа с приоритетом 40:

файлы, используемые в Сценарии 3 (которых еще нет в списке) = File D.

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

File А: средний порядковый номер = (порядковый номер Сценария 1 + порядковый номер Сценария 2)/2=(1+2)/2=1,5.

File В: средний порядковый номер = (порядковый номер Сценария 1)/1=(2)/1=2.

File С: средний порядковый номер = (порядковый номер Сценария 2)/1=(1)/1=1.

Здесь File А используется первым в сценарии 1 и вторым в сценарии 2, в среднем он имеет номер 1,5 и так далее. File С имеет самый маленький порядковый номер из Автономных файлов, поэтому посылается первым. Окончательный порядок файлов приведен ниже:

Необходимые файлы

FileE

Автономные файлы

FileC, FileA, FileB, File D

Код, компоненты и "биты"

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

- Настраиваемый пользовательский интерфейс UI и клавишные комбинации быстрого вызова

- Компоненты и Поведения

- XML-компоненты просмотра и редактирования (включая стилевые таблицы XSL и объекты бизнес-логики)

- Статические страницы или другие ресурсы

- Заказное содержимое, определяемое третьими сторонами

Пользователи инсталлируют расширения, переходя путем сетевой навигации к сетевому сайту для этого расширения. В Интернете пользователь перемещается к соответствующему указателю URL для этого расширения. Администраторы хостинга могут также способствовать "продвижению" расширений так, чтобы пользователи могли автоматически принимать их, добавляя строку в соответствующие "Preference" ("Предпочтения") настроек пользователя.

Установка платформы и инсталляция расширения

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

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

На шаге 1400 пользователь посредством сетевой навигации заходит на определенный сайт Интернет, связанный с программной платформой, которая должна использоваться как основа для описываемой ниже инсталляции расширения. На шаге 1402 пользователь щелкает на кнопке "install" ("установить"), которая посылает серверу программной платформы сообщение, указывающее, что пользователь желает инсталлировать программную платформу. Этот шаг может быть необязательным. Затем на шагах 1404 и 1405 клиенту загружается программное обеспечение, связанное с программной платформой. В показанном примере на шаге 1404 загружается пакетный файл для однооконного приложения с возможностью навигации, и на основе содержимого этого файла на шаге 1405 в компьютер пользователя загружаются другие компоненты и файлы. На шаге 1406 программный код устанавливается на клиентскую машину, и могут быть созданы локальные каталоги для кэша приложений, локальное хранилище и настройки предпочтений. Однако должно быть понятно, что локальные каталоги или настройки предпочтений не обязательны. На шаге 1408 программная платформа запускается.

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

На шаге 1410 для доступа к расширению используется ссылка, которая связана с ним. Этот шаг может быть реализован пользователем, перемещающимся посредством своего Интернет-браузера на определенный сайт Интернет, через который может быть получен доступ к одному или нескольким расширениям. Альтернативно, ссылка может быть помещена в настройки ("предпочтения") пользователя или настройки рабочей группы, с которой связан пользователь (например, администратор системы может поместить ссылку в настройки группы). Ссылка может быть связана с Интернет-сервером или Интернет-сайтом третьей стороны. На шаге 1412 файлы расширения загружаются согласно декларации PKG, связанной с файлом описания расширения. Файлы поставляются клиенту, и на шаге 1414 файлы расширения помещаются в локальное запоминающее устройство, как определено спецификацией PKG. С этого момента расширение инсталлировано, и пользователь может использовать предоставляемые им функциональные возможности. На шаге 1416 определяется, имеются ли в наличии обновления расширения. Это может быть обеспечено периодическим опросом каталога расширений (рассматриваемого ниже в разделе "Каталог расширений"), чтобы установить, имеются ли какие-либо обновления к различным расширениям. В качестве варианта, уведомления могут автоматически посылаться клиенту, чтобы клиент узнал об обновлении, или может использоваться любой другой способ определения, имеются ли в наличии обновления. Если обновления имеются, то на шаге 1418 выполняется переход по ветви к шагу 1418, на котором загружаются файлы расширения, связанные с обновлением, и эти файлы инсталлируются у клиента.

Разработка расширений

Разработка расширений для программной платформы является довольно простым процессом. Разработчик создает содержимое расширения, используя программу типа Notepad (Блокнот) или другие средства, такие как Visual Studio. Затем расширение описывается в файле описания расширения и PKG, PKG снабжается цифровой подписью и, кроме того, может быть сжата. Затем расширение может быть помещено на конкретном сервере сети.

На фиг.15 показана блок-схема алгоритма, которая описывает шаги способа разработки расширения в соответствии с одной из описываемых форм осуществления изобретения. Один или более из этих шагов могут быть выполнены разработчиком программного обеспечения или организацией, которая создает конкретное расширение. Некоторые из шагов реализуются в программном обеспечении. На шаге 1500 разрабатывается расширение. Для разработки расширения могут использоваться любые подходящие средства. Затем на шаге 1502 для этого расширения создается файл описания расширения (EDF). В данном примере файл описания расширения создается с использованием XML, как описано выше. Конечно, чтобы описать файл описания расширения, могут использоваться и другие форматы. На шаге 1504 для расширения создается декларация пакета (PKG). В этом примере декларация пакета создается с помощью XML, как описано выше. Затем на шаге 1506 файл описания расширения и декларация пакета размещаются на сетевом сервере, например, на сервере Интернет. Дополнительно, связанные с расширением файлы, которые описываются в декларации пакета, также могут размещаться на сетевом сервере или сервере Интернет (шаг 1508). После того, как вышеуказанные действия выполнены, пользователи могут перемещаться путем сетевой навигации непосредственно к файлу описания расширения (используя, например, соответствующий URL или некоторый другой сетевой адрес), который затем инсталлирует расширение путем помещения любых необходимых файлов в локальный кэш и помещения ссылки на расширение в настройки пользователя.

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

Каталог расширений

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

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

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

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

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

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

На фиг.16 показана типичная структура каталога XML. Записи в каталоге могут быть структурированы следующим образом:

Таблица 5
Атрибут	Тип	Необходимость	Описание
ExtensionURN	uri (унифицированный индикатор ресурса)	Да	Идентификатор для расширения. В одном каталоге для urn расширения могут иметься несколько записей, представляющих различные версии, языки и т.д.
Name (имя)	String (Строка)	Нет	Удобное имя для расширения.
Package URN	uri (унифицированный индикатор ресурса)	Да	Необходимое urn (унифицированное имя ресурса) для пакета. Urn пакета соответствует дискретному набору битов. Отличается от urn расширения: для каждого пользователя urn расширения соответствует определенному набору файлов, основанных на настройках языка и версии. Это означает, что для общих машин различные пользователи могут иметь на основе своих настроек различные extensionURN для отображений packageURN.
packageURL	uri	Да	URL сжатого файла с цифровой подписью, содержащего PKG файл, необходим.
language	String (Строка)	Нет	Language является необязательным спецификатором языка.
Version	String (Строка)	Нет	Version является необязательным спецификатором версии.
defaultLanguage	String (Строка)	Нет	DefaultLanguage является необязательным атрибутом, определяющим заданный по умолчанию пакет языка. Для определенной версии расширения должна иметься только одна запись с атрибутом DefaultLanguage.
defaultVersion	String (Строка)	Нет	DefaultVersion является необязательным атрибутом, определяющим заданную по умолчанию версию расширения. Для данного urn расширения и атрибута языка должна иметься только одна запись с атрибутом DefaultVersion.

В этом конкретном примере:

- Заданным по умолчанию языком netdocs-планировщика является английская версия.

- Заданной по умолчанию английской версией является версия 1.1. Заданной по умолчанию французской версией является версия 1.0. Если на платформе нет никакой версии, доступной на указанном пользователями языке, то они получат английскую версию 1.1 по умолчанию.

- Английская версия netdocs-планировщика была обновлена с версии V1 до версии V1.1.

- Имеется также французская версия. Она имеет такое же URN расширения, что и у английской версии. Поскольку еще нет версии 1.1 для французского языка, то для пользователей, говорящих на французском языке, текущей версией является 1.0.

- Запрос к каталогу возвращает только те строки, в которых язык соответствует настройкам языка пользователя. Запрос также мог бы возвращать все строки, в которых язык является языком пользователя или имеет значение по умолчанию = 'yes' ("да") и отклонять дубликаты для одного и того же имени.

Архитектура

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

Файл описания расширения, как сказано выше, может быть задан в виде XML-схемы, которая содержит корневой узел (то есть тэг "extension" - "расширение") и один или несколько дочерних узлов. В данном конкретном примере дочерние узлы, как правило, соответствуют отдельным типам функций расширения, которые желательны для включения в программную платформу. Например, напомним, что приведенные выше таблицы 1-3 описывают различные примеры предопределенных типов элементов, которые могут быть добавлены посредством расширения с использованием предопределенной XML схемы.

Рассмотрим теперь случай, когда разработчик хочет добавить в программную платформу два меню и панель инструментов. Меню и панель инструментов могут быть связаны с магазином розничной торговли, который имеет веб-сайт для своих покупателей. Магазин розничной торговли может хотеть, чтобы покупателю, посещающему его веб-сайт, был представлен пользовательский интерфейс, который предоставляется только этим магазином и предоставляет услуги, специально разработанные для этого магазина. Чтобы сделать это, разработчик создает два различных меню, одно из которых может быть связано с показом самых новых товаров, а другое – с предоставлением поискового механизма, посредством которого пользователь может искать определенные изделия. Панель инструментов может содержать определенные кнопки, которые предназначены только для этого магазина розничной торговли. Упрощенный файл описания расширения "retail, ей'f" для магазина розничной торговли показан ниже:

Здесь внешний тэг "extension" определяет этот XML-файл как расширение. Внутренние тэги "menus" и "toolbars" являются тэгами верхнего уровня, которые показывают, что информация между этими тэгами касается соответственно меню и панелей инструментов, соответствующих расширениям, добавленным разработчиком. Выделенные жирным шрифтом тэги "menu" и "toolbar" описывают данные, касающиеся фактического расширения и содержащие URL, который соответствует каждому из расширений, как описано выше. Файл описания расширения, приведенный выше, логически описывает расширения, которые содержат два меню и одну панель инструментов.

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

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

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

- XML точка присоединения, которая загружает XML-файл и представляет узлы верхнего уровня XML как объекты ее коллекции.

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

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

В рассматриваемом примере архитектура содержит коллекцию из одной или нескольких точек присоединения, включая концентрирующую структуру, обозначенную как EDFHub 1700, менеджер 1702 точек присоединения и многочисленные менеджеры 1704 присоединений. EDFHub 1700 принимает все файлы описания расширений, объединяет их и показывает в виде единого списка. Другие индивидуальные точки присоединения обеспечивают механизмы, которые манипулируют (включая фильтрацию, объединение и расширение) единым списком, который предоставляет EDFHub 1700. Когда новое расширение или файл описания расширения добавляются в EDFHub или удаляются из него, различные точки присоединения следят за тем, чтобы был уведомлен соответствующий менеджер (менеджеры) присоединения. Это выполняется путем запуска событий для соответствующих менеджеров присоединения. Менеджер 1702 точек присоединения создает, уничтожает и управляет различными точками присоединения в системе и позволяет легко осуществлять многократное повторное использование идентичных точек присоединения.

Для каждого тэга верхнего уровня (то есть тэгов "menus" и "toolbars") имеется соответствующий менеджер 1704 присоединения, который использует данные, предоставляемые точками присоединения, для включения функции определенного типа в программную платформу. Каждый менеджер присоединения запрашивает набор точек присоединения у менеджера 1702 точек присоединения. Они манипулируют данными, предоставляемыми концентратором EDFHub 1700. В данном примере точки присоединения могут запрашиваться как цепочка предикатов, которую менеджер точек присоединения использует для создания и формирования набора точек присоединения, оперирующих данными, предоставляемыми EDFHub1700.

На фиг.18 показана блок-схема алгоритма, которая описывает шаги способа в соответствии с описываемой формой осуществления изобретения. Способ реализуется программными средствами, в этом примере - программными компонентами, показанными на фиг.17.

На шаге 1800 принимается множество файлов описания расширений. Эти файлы могут быть приняты любым подходящим способом. Например, пользователи могут задавать в своих настройках конкретные расширения, которые они хотят загрузить, когда они находятся в онлайновом режиме. В качестве варианта, пользователь может осуществлять сетевую навигацию, заходя с использованием ссылки на определенный Интернет-сайт, который распознает, что пользователь имеет платформу программного обеспечения, которая конфигурирована так, чтобы динамически добавлять расширения. Файлы описания расширений в этом примере концентрируются в EDFHub 1700, который использует точки присоединения для объединения файлов описания расширений (шаг 1802). В этом примере файлы описания расширений являются XML-файлами и их узлы объединяются в единый XML-список. На шаге 1804 предоставляются объединенные файлы описания расширений. В этом конкретном примере файлы описания расширений объединяются в единый список XML, который предоставляется другимразличным точкам присоединения, манипулирующим этими данными далее (шаг 1806). Одна из задач точек присоединения состоит в том, чтобы менеджерам 1704 присоединения не было необходимо повторно запрашивать всю систему каждый раз, когда расширение добавляется или удаляется из системы. Так, если расширение добавляется или удаляется, точки присоединения гарантируют, что только соответствующий менеджер 1704 присоединения будет уведомлен о конкретных добавлениях или удалениях расширения. Например, если файл описания расширения указывает на добавление меню, то уведомляется только менеджер присоединения, связанный с меню. Соответственно, на шаге 1808 соответствующий менеджер присоединения уведомляется о любых новых данных, которые соответствуют требованиям этого менеджера присоединений.

Точки присоединения и менеджер точки присоединения

Точки присоединения являются объектами, которые предоставляют коллекции упорядоченных объектов и запускают уведомления, когда новые объекты вставляются или удаляются. В типичной системе объектами являются XML узлы, но ими могут быть и объекты другого типа. Хотя имеется много типов точек присоединения, все они выполняют сходную процедуру:

1) Первоначальное присоединение к одному или нескольким источникам данных. Ими могут быть файлы или, обычно, другие точки присоединения.

2) Обработка данных на основе некоторой логики. Обычно эта логика весьма проста и может включать в себя что-либо подобное фильтрации объектов на основе некоторых критериев.

3) Предоставление результатов шага 2 в виде новой коллекции объектов.

4) Запуск событий, чтобы указать, как изменена предоставленная коллекция объектов (Onlnserted(index, count) или OnRemoved(index, count)).

5) В качестве опции, продолжение наблюдения за изменениями в источниках данных и повторение шагов 2-4, когда эти изменения происходят.

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

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

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

Explode(Fitter("menus",Explode(URL("retail.edf"))))

Эта строка представляет все меню в файле retaii.edf. XML-файл, расположенный в retail.edf, загружается точкой присоединения URL, которая представляет корневой узел XML-файла в качестве единственного объекта своей коллекции. Внутренняя точка присоединения Explode (Развертывание по компонентам) использует точку присоединения URL как источник данных и представляет все дочерние элементы объектов этой исходной коллекции. В данном случае дочерние элементы корневого узла являются тэгами верхнего уровня XML "menu" ("меню") и "toolbars" ("панели инструментов"). Точка присоединения Filter (Фильтр) использует точку присоединения Explode как свой источник данных и фильтрует предоставленные ей объекты, отыскивая только узлы, которые являются меню. Внешняя точка присоединения Explode использует точку присоединения Filter как свой источник данных и предоставляет все дочерние элементы узлов фильтруемых меню, чтобы представить список, содержащий два меню, которые добавляются расширением. Так как этот конкретный XML-файл содержал меню, которые были идентифицированы точками присоединения, связанными с менеджером присоединения меню, этот менеджер присоединения уведомляется о том, что расширением добавлены два меню.

Этот процесс схематически иллюстрирован на фиг.19, где показаны точки 1900, 1902, 1904 и 1906 присоединения. Каждая точка присоединения предоставляет список XML узлов. Точка 1900 присоединения URL берет входные данные (URL для XML-файла, например, файла retait.edf) и предоставляет список XML узлов. Этот список содержит только корневой узел "<edf:extension>". Точка 1902 присоединения Explode получает в качестве входных данных данные от точки 1900 присоединения и предоставляет список XML узлов, которые являются дочерними элементами исходных XML узлов. В этом примере список XML узлов, предоставляемых точкой 1902 присоединения, содержит узлы "<menus>" ("меню") и узлы "<toolbars>" ("<панели инструментов>"). Фильтрующая точка 1904 присоединения получает входные данные от точки 1902 присоединения и выделяет из них меню ("menus"). Затем она предоставляет список XML, содержащий только узлы "<menus>". Точка 1906 присоединения Explode получает входные данные от точки 1904 присоединения и предоставляет список XML узлов, которые содержатся в узлах "<menus>", в данном случае -оба узла "<menu>" ("<меню>").

Предположим дополнительно, что менеджер присоединения панели инструментов запросил предикатную цепочку точек присоединения, которые также будут использовать точку присоединения URL, точку присоединения Explode и фильтрующую точку 1904 присоединения, которая фильтрует "<toolbars>" ("панели инструментов"). Таким образом, соответствующая точка 1906 присоединения Explode будет предоставлять список XML, содержащий только узел "<toolbar>" ("панель инструментов"). Но менеджер точки присоединения обнаружил бы при этом общность точки присоединения URL и внутренней точки присоединения Explode, так что он повторно использовал бы те же самые точки присоединения, которые были созданы для менеджера присоединения меню. Точки присоединения Filter (Фильтр), используемые менеджером присоединения панели инструментов и менеджером присоединения меню, использовали бы одну и ту же точку присоединения Explode как их источник данных, но представили бы различные коллекции узлов, потому что фильтровали бы их на основе различных критериев.

Рассмотрим фиг.20, где имеется точка 2000 присоединения EDFHub. Эта точка присоединения принимает все файлы описания расширений и, как описано выше, объединяет их в единый список XML. Затем EDFHub указывает корневые узлы всех файлов описания расширений. Точка 2002 присоединения Explode тогда предоставляет список XML, который содержит все узлы верхнего уровня для всех файлов описания расширений. Например, могут иметься многочисленные файлы описания расширений, каждый из которых содержит узлы меню верхнего уровня, узлы панелей инструментов, узлы акселераторов и т.п. Точка 2002 присоединения Explode предоставляет список XML, который содержит все эти узлы верхнего уровня для всех файлов описания расширений. Затем точка 2004 присоединения Filter может фильтровать список XML, предоставляемый точкой 2002 присоединения Explode, в соответствии с некоторыми подходящими параметрами (то есть, фильтровать по узлам меню, узлам панелей инструментов, узлам акселераторов и т.п.). Конечная точка 2006 присоединения Explode предоставляет затем список отдельных дочерних узлов из списка, представленного фильтрующей точкой 2004 присоединения. Этот список описывает все конкретные элементы (определенного типа, которые отфильтрованы), которые были добавлены всеми файлами описания расширений.

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

Таблица 6
Точка присоединения	Назначение
URL (Унифицированный указатель ресурса)	Загружает URL и представляет узел верхнего уровня XML в качестве элемента коллекции
Context (Контекст)	Для каждого элемента вычисляет атрибут "expression" ("выражение") и связывает его с этим элементом. Если выражение истинно, то элемент предоставляется.
EDF (Файл описания расширения)	То же самое, что точка присоединения URL, но также предоставляет сформированный элемент с данными для создания АРР на основе URL и URN (существует в XML DOM).
Merge (Слияние)	Получает нулевое или большее число точек присоединения (любого типа) и соединяет их вместе. Порядок и непрерывность первоначальных коллекций будут сохраняться.
Filter (Фильтр)	Контролирует отдельную точку присоединения и выделяет только те узлы, которые соответствуют указанному имени. Порядок первоначальной коллекции будет сохраняться.
Duplicate (Дублирование)	Контролирует отдельную точку присоединения и отфильтровывает любые дубликаты. Дубликат определяется, как элемент, имеющий тот же самый атрибут URN. Если никакого атрибута URN нет, то тогда узел предоставляется. Будет сохраняться порядок первоначальной коллекции.
Explode (Развертывание по компонентам)	Контролирует отдельную точку присоединения и для каждого элемента показывает его дочерние элементы в качестве собственных элементов. Порядок первоначальной коллекции будет сохраняться, как и порядок дочерних элементов внутри узлов.
Link (Ссылка)	Контролирует отдельную точку присоединения, для каждого элемента ищет атрибут URL, создает точку присоединения URL и включает ее в себя. Если установлена опция включения содержимого, оно также будет включено в исходную коллекцию,
Order (Порядок)	Контролирует единственную точку присоединения. Для каждого элемента получает три атрибута: id, before и after (идентификатор, "прежде" и "после"). На основании этой информации переупорядочивает элементы в заданном порядке. Если никакой информации об упорядочении не предоставляется, порядок первоначальной коллекции будет сохраняться.
EDFHub	Эта точка присоединения является центральной точкой слияния, которая представляет все точки EDF.

Заключение

Формы осуществления изобретения, описанные выше, предоставляют такое решение для компьютерной платформы, которое обеспечивает настройку на соответствие требованиям потребителей и расширяемость посредством непротиворечивого и логически расширяемого механизма и объектной модели, которая может быть легко понята разработчиками третьей стороны. Загрузки расширений из Интернет могут быть выполнены без значительного вмешательства пользователя и без манипулирования постоянными параметрами пользовательских настроек. Расширения могут предоставляться в программной платформе или прикладной программе динамически, исходя из текущей ситуации в компьютерной среде, в которой работает пользователь (на основе "контекста").

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

Claims (61)

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

2. Способ по п. 1, отличающийся тем, что указанная сеть включает Интернет.

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

4. Способ по п. 1, отличающийся тем, что указанные описания включают XML-описания.

5. Способ по п. 1, отличающийся тем, что указанная сеть включает Интернет и указанные описания включают XML-описания.

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

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

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

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

10. Способ по п. 1, отличающийся тем, что расширения программного обеспечения обеспечивают предоставление поведений, компонентов или объектов.

11. Способ по п. 1, отличающийся тем, что расширения программного обеспечения обеспечивают предоставление элементов хранения.

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

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

14. Способ по п. 1, отличающийся тем, что по меньшей мере одно расширение обеспечивает способность добавлять новые точки расширяемости.

15. Способ по п. 1, отличающийся тем, что шаг описания одного или более расширений программного обеспечения включает описание расширений с использованием файла описания расширения (EDF), который включает XML-файл, описывающий логическое присоединение к программной платформе.

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

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

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

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

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

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

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

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

24. Способ по п. 18, отличающийся тем, что одно или более расширений программного обеспечения обеспечивают предоставление поведений, компонентов или объектов.

25. Способ по п. 18, отличающийся тем, что одно или более расширений программного обеспечения обеспечивают предоставление элементов хранения.

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

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

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

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

30. Способ по п. 29, отличающийся тем, что файлы описания расширения составлены на иерархическом языке.

31. Способ по п. 29, отличающийся тем, что указанная сеть включает Интернет.

32. Способ по п. 29, отличающийся тем, что упомянутые операции хранения осуществляют путем размещения упомянутых файлов на сервере Интернет.

33. Способ по п. 29, отличающийся тем, что файлы описания расширения включают XML-файлы.

34. Способ по п. 33, отличающийся тем, что XML-файлы содержат предопределенные тэги, которые соответствуют типам элементов, которые должны быть добавлены к указанной программе.

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

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

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

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

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

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

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

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

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

44. Способ по п. 43, отличающийся тем, что один из XML-файлов содержит файл, который логически описывает расширение, и один из XML-файлов содержит файл, который описывает файлы расширения.

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

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

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

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

49. Способ по п. 47, отличающийся тем, что иерархический язык, который описывает логическое присоединение расширения программного обеспечения, включает расширяемый язык разметки (XML).

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

51. Способ по п. 47, отличающийся тем, что дополнительно определяют, доступно ли обновление для расширения программного обеспечения, и если оно доступно, то принимают обновленные файлы расширения.

52. Способ по п. 51, отличающийся тем, что упомянутое определение доступности обновлений включает опрос каталога расширений.

53. Способ по п. 51, отличающийся тем, что упомянутое определение доступности обновлений включает опрос каталога расширений, содержащего XML-файл.

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

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

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

57. Компьютерное устройство по п. 56, отличающееся тем, что указанный иерархический язык включает расширяемый язык разметки (XML).

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

59. Способ по п. 58, отличающийся тем, что он включает направление в каталог запроса для выяснения описания расширения.

60. Способ по п. 58, отличающийся тем, что он включает направление в каталог запроса на основе персональных пользовательских настроек.

61. Способ по п. 58, отличающийся тем, что описания расширений составлены на XML.

Images