ПРОГРАММНЫЙ ИНТЕРФЕЙС ПРИЛОЖЕНИЙ ДЛЯ АДМИНИСТРИРОВАНИЯ РАСПРЕДЕЛЕНИЕМ ОБНОВЛЕНИЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В СИСТЕМЕ РАСПРЕДЕЛЕНИЯ ОБНОВЛЕНИЙ

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

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

Предшествующий уровень техники

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

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

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

В то время как Интернет в настоящее время обычно используется как канал для распределения обновлений программного обеспечения от провайдеров программного обеспечения, часто возникают несколько проблем. Две такие проблемы включают в себя (1) эффективность, относящуюся к инфраструктуре/ресурсам распределения обновления, и (2) административный контроль над распределением и инсталляцией обновлений программного обеспечения.

В отношении эффективности ресурсов обновления сети, включая и Интернет, обладают только конечным объемом ресурсов связи, часто называемых полосой частот. Конечное значение полосы частот связи часто приводит к возникновению узких мест, особенно в отношении обновлений программного обеспечения для популярных программных продуктов, таких как семейство операционных систем корпорации Microsoft Windows®, и связанных с ними продуктов эффективности. Такие узкие места существуют, даже когда обновления программного обеспечения сделаны доступными на множестве мест загрузки, распределенных по Интернет. Одна из причин, что такие узкие места имеют место, заключается в неструктурированной модели доступа, сделанной доступной посредством Интернет. Например, если первый пользователь на компьютере А запрашивает самую последнюю загрузку программного продукта, загрузка происходит через независимого поставщика услуг первого пользователя (поставщик интернет-услуг, ISP). Кроме того, запрос обрабатывают как одиночный, индивидуальный доступ, означая, что запрос обрабатывают независимо от и вне связи с любым другим сетевым трафиком и/или запросом. Также, если второй пользователь в компьютере B, который так же, как оказалось, имеет того же самого поставщика интернет-услуг, запрашивает ту же самую загрузку, что и первый пользователь, запрос от второго пользователя также обрабатывается как одиночный, индивидуальный доступ. В этом примере одна и та же загрузка будет передана по одной и той же инфраструктуре дважды, потому что каждый запрос был обработан изолированно. Ясно, если количество пользователей существенно увеличивается, конечная ширина полосы связи станет узким местом (критическим параметром). В этом примере, который является весьма общим, было бы намного более эффективно, если бы загрузка могла быть кэширована в локальном местоположении, и каждый запрос пользователя был удовлетворен из локального кэша.

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

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

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

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

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

Согласно аспектам настоящего изобретения представлен узел по обслуживанию обновлений, имеющий программный интерфейс приложений для управления распределением обновлений программного обеспечения на узле по обслуживанию обновлений. Узел по обслуживанию обновлений включает в себя хранилище обновлений для сохранения обновлений программного обеспечения. Узел по обслуживанию обновлений также включает в себя web-службу обновлений, посредством которой узел по обслуживанию обновлений получает обновления программного обеспечения от родительского узла по обслуживанию обновлений по сети связи и посредством которой узел по обслуживанию обновлений распределяет обновления программного обеспечения дочерним узлам по обслуживанию обновлений по сети связи. Кроме того, узел по обслуживанию обновлений включает в себя административный программный интерфейс приложений (API), посредством которого администратор устанавливает средства управления распределением обновлений программного обеспечения для дочерних узлов по обслуживанию обновлений и клиентских компьютеров, причем административный API является объектом, предоставляющим множество интерфейсных вызовов, посредством которых администратор устанавливает упомянутые правила.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробное описание предпочтительного варианта осуществления

Согласно аспектам настоящего изобретения представлена система распределения обновлений, организованная иерархическим способом, для распределения обновлений программного обеспечения. Фиг.1 изображает наглядную схему примерной системы 100 распределения обновлений, сформированной в соответствии с аспектами настоящего изобретения. Согласно настоящему изобретению "наверху" системы распределения обновления, такой как проиллюстрированная система 100 распределения обновлений, находится корневой узел 102 по обслуживанию обновлений. Провайдеры программного обеспечения, такие как провайдер 110 программного обеспечения, распределяют свои обновления программного обеспечения через систему 100 распределения обновлений, представляя обновления корневому узлу 102 по обслуживанию обновлений. Согласно аспектам настоящего изобретения провайдеры программного обеспечения, такие как провайдер 110 программного обеспечения, могут представить свои обновления программного обеспечения корневому узлу 102 по обслуживанию обновлений через сеть, такую как Интернет 108.

Иерархическая система распределения обновлений, такая как примерная система 100 распределения обновлений, будет, вероятно, включать в себя, по меньшей мере, один другой узел по обслуживанию обновлений в дополнение к корневому узлу 102 по обслуживанию обновлений. Как проиллюстрировано на Фиг.1, примерная система 100 распределения обновлений включает в себя корневой узел 102 по обслуживанию обновлений и два дополнительных узла по обслуживанию обновлений: узел 104 по обслуживанию обновлений и узел 106 по обслуживанию обновлений. Согласно настоящему изобретению каждая иерархическая система распределения обновлений организована как древовидная структура ниже корневого узла 102 по обслуживанию обновлений. Другими словами, каждый узел по обслуживанию обновлений в системе распределения обновлений имеет нуль или более дочерних узлов по обслуживанию обновлений. Таким образом, хотя примерная система 100 распределения обновлений показывает, что каждый родительский узел по обслуживанию обновлений, то есть, корневой узел 102 по обслуживанию обновлений и узел 104 по обслуживанию обновлений, имеет только одного потомка, это служит только для целей иллюстрации и не должно быть рассмотрено как ограничение настоящего изобретения. Кроме того, за исключением корневого узла 102 по обслуживанию обновлений, каждый узел по обслуживанию обновлений в системе распределения обновлений имеет один родительский узел по обслуживанию обновлений. Соответственно, как показано на Фиг.1, узел 104 по обслуживанию обновлений является дочерней вершиной для корневого узла 102 по обслуживанию обновлений, и узел 106 по обслуживанию обновлений является дочерней вершиной для узла 104 по обслуживанию обновлений. Как можно видеть, каждый узел по обслуживанию обновлений, за исключением корневого узла 102 по обслуживанию обновлений, может быть и дочерним узлом по обслуживанию обновлений, и родительским узлом по обслуживанию обновлений.

Как проиллюстрировано в примерной системе 100 распределения обновлений, корневой узел 102 по обслуживанию обновлений связывается с узлом 104 по обслуживанию обновлений через Интернет 108. Однако должно быть понятно, что это является только иллюстрацией и не должно быть рассмотрено как ограничение настоящего изобретения. Каждый узел по обслуживанию обновлений в системе распределения обновлений должен быть способным только соединяться со своим родителем и/или дочерними узлами через некоторую коммуникационную сеть. Таким образом, в то время как узел 104 по обслуживанию обновлений обменивается со своим родителем, корневым узлом 102 по обслуживанию обновлений, через Интернет 108, он может альтернативно связываться со своими дочерними узлами по обслуживанию обновлений, такими как узел 106 по обслуживанию обновлений, через локальную сеть 124.

Также как показано на Фиг.1, узел 106 по обслуживанию обновлений постоянно находится в подсети 126 локальной сети 124. В качестве примера, локальная сеть 124 может соответствовать общей корпоративной сети организации, и узел 104 по обслуживанию обновлений представляет линию связи корпорации к системе 100 распределения обновлений через ее подключение к своему родителю, корневому узлу 102 по обслуживанию обновлений. Далее, подсеть 126 может соответствовать идентифицируемой группе компьютеров в пределах корпоративной сети связи, такой как группа испытаний/оценки, удаленно расположенный офис или группа с критической миссией. Как описано более подробно ниже, согласно аспектам настоящего изобретения администратор на узле 104 по обслуживанию обновлений способен управлять распределением обновлений на узел 106 по обслуживанию обновлений, и в конечном счете - на клиентские компьютеры.

Должно быть понятно, что каждый узел по обслуживанию обновлений, включая в себя как корневой узел 102 по обслуживанию обновлений, так и узлы 104 и 106 по обслуживанию обновлений, сконфигурирован так, чтобы распределять обновления программного обеспечения обоим дочерним узлам по обслуживанию обновлений, а также клиентским компьютерам. Как показано на Фиг.1, примерная система 100 распределения обновлений включает в себя клиентские компьютеры 112-122. Каждый узел по обслуживанию обновлений, включая корневой узел 102 по обслуживанию обновлений, распределяет обновления дочерним узлам по обслуживанию обновлений и клиентским компьютерам согласно информации о локальной конфигурации. Согласно одному варианту осуществления администратор определяет группы и сопоставляет (ассоциирует) правила распределения обновления с этими группами. Каждый узел по обслуживанию обновлений имеет, по меньшей мере, одну группу распределения.

В качестве примера для иллюстрации того, как работает система распределения обновлений, предположим, что локальная сеть 124 соответствует корпоративной сети связи коммерческой организации. Согласно одному варианту осуществления настоящего изобретения администратор на узле 104 по обслуживанию обновлений может определять множество групп распределения для корпоративной сети 124, включая группу оценки, соответствующую подсети 126, включающей в себя узел 106 по обслуживанию обновлений и клиентские компьютеры 120 и 122, для оценки пригодности обновления для общей корпоративной сети 124, а также общую корпоративную группу, включающую в себя узел 104 по обслуживанию обновлений и клиентские компьютеры 114-118.

В отношении группы оценки администратор включает в себя узел 106 по обслуживанию обновлений в качестве элемента и связывает (ассоциирует) правила с этой группой так, что обновления немедленно распределяются членам группы оценки, как только они станут доступными. Альтернативно, в отношении общей корпоративной группы, администратор добавляет клиентские компьютеры 114-118 и сопоставляет правило так, что обновления распределяются только членам общей корпоративной группы, если специально авторизовано администратором. Предположим также, что администратор для дочернего узла 106 по обслуживанию обновлений создает заданную по умолчанию группу, состоящую из клиентских компьютеров 120 и 122 в подсети 126 оценки, которой может быть немедленно распределено любое новое обновление программного обеспечения.

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

Продолжая вышеупомянутый пример, после приема обновления оценочный узел 106 по обслуживанию обновлений обрабатывает обновление в отношении каждой определенной группы. В этом примере, оценочный узел 106 по обслуживанию обновлений имеет только одну группу. Однако, как упомянуто выше, при фактическом исполнении может быть множество определенных групп, каждая с уникальным набором ассоциированных правил распределения. Для этого примера оценочный узел 106 по обслуживанию обновлений немедленно делает обновление доступным для распределения на клиентские компьютеры 120 и 122. Клиентские компьютеры 120 и 122 могут теперь быть обновлены, и может начинаться процесс/период оценки.

Продолжая вышеупомянутый пример, когда администратор на корпоративном узле 104 по обслуживанию обновлений в достаточной степени удовлетворен, что обновление является подходящим для распределения по всей корпоративной сети 124, администратор затем явно разрешает распределение обновлений членам общей корпоративной группы. Корпоративный узел 104 по обслуживанию обновлений, соответственно, делает обновление доступным клиентским компьютерам 114-118. Должно быть понятно, что оценочный узел 106 по обслуживанию обновлений может также быть включен в общую корпоративную группу. Однако, так как оценочный узел 106 по обслуживанию обновлений уже был обновлен, никакого дополнительного связанного с обновлением действия не нужно выполнять для распределения этого обновления к подсети 126 оценки.

Как можно видеть из вышеприведенного примера, настоящее изобретение предлагает существенные выгоды в терминах управления локальным распределением и эффективностью загрузки. В дополнение к описанным выше аспектам локального управления распределением также реализуется существенная экономия полосы пропускания. Например, в то время как примерная корпоративная сеть 124, проиллюстрированная на Фиг.1, включает в себя пять клиентских компьютеров, обновление программного обеспечения от провайдера было загружено от корневого узла 102 по обслуживанию обновлений в корпоративный узел 104 по обслуживанию обновлений только один раз. Ясно также, что когда увеличивается количество клиентских компьютеров, обслуживаемых узлом по обслуживанию обновлений, использование полосы пропускания между родительским узлом по обслуживанию обновлений и клиентским узлом по обслуживанию обновлений остается постоянным, таким образом, существенно сокращая полосу пропускания, которая иначе могла быть использована. Дополнительно, система распределения обновлений является и расширяемой и масштабируемой. Система распределения обновлений является расширяемой, по меньшей мере, двумя способами: любое количество дочерних узлов по обслуживанию обновлений может быть добавлено к родительскому узлу по обслуживанию обновлений, и дочерние узлы по обслуживанию обновлений могут также быть родительским узлом по обслуживанию обновлений. Каждое поддерево системы распределения обновления может быть, поэтому, приспособлено, чтобы удовлетворить индивидуальные потребности.

Фиг.2 изображает блок-схему, иллюстрирующую примерные логические компоненты узла 200 по обслуживанию обновлений, такого как корпоративный узел 104 по обслуживанию обновлений (Фиг.1) или оценочный узел 106 по обслуживанию обновлений (Фиг.1), сформированного в соответствии с аспектами настоящего изобретения. Как показано на Фиг.2, узел 200 по обслуживанию обновлений включает в себя web-службу 202 обновлений, клиентский модуль 204 обновлений, дочерний модуль 206 обновлений и модуль 208 отчетов. Примерный узел 200 по обслуживанию обновлений также включает в себя модуль 210 аутентификации/авторизации, административный программный интерфейс приложений (API) 212, хранилище 214 содержания обновлений, пользовательский интерфейс 218 администрации и хранилище 216 информации обновлений.

Web-служба 202 обновлений обеспечивает общий набор Web-услуг, посредством которых клиентские компьютеры, дочерние узлы по обслуживанию обновлений и родительский узел по обслуживанию обновлений могут обмениваться с узлом по обслуживанию обновлений. Например, со ссылками на Фиг.1, для того, чтобы дочерний/оценочный узел 106 по обслуживанию обновлений получил обновление программного обеспечения от родительского/корпоративного узла 104 по обслуживанию обновлений, клиент обменивается посредством web-службы 202 обновлений родителя. Точно так же, когда родительский узел по обслуживанию обновлений, такой как корневой узел 102 по обслуживанию обновлений, имеет информацию, включающую в себя обновления, для передачи своему дочернему узлу 104 по обслуживанию обновлений, этот родительский узел по обслуживанию обновлений обменивается посредством web-службы 202 обновлений потомка (дочернего узла).

При фактическом осуществлении настоящего изобретения общий набор Web-услуг, предоставленных web-службой 202 обновлений, обычно называемый как интерфейс web-услуг, включает в себя следующие вызовы: GetServerAuthConfig - для получения информации конфигурации аутентификации от родительского узла по обслуживанию обновлений; GetConfigData и GetServerConfigData - для получения информации и свойств конфигурации узла сервера обновлений родителя; GetServerCookie - для получения маркера авторизации от родительского узла по обслуживанию обновлений; GetRevisionIdList - для получения списка обновлений от родительского узла по обслуживанию обновлений; GetUpdateData - для получения метаданных обновления и полезных данных обновления от родительского узла по обслуживанию обновлений; и ReportEvents - для отчета о действиях по обновлению, которые произошли на узле по обслуживанию обновлений, его родительскому узлу по обслуживанию обновлений.

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

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

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

Модуль 210 аутентификации/авторизации отвечает за аутентификацию, то есть определение идентификационной информации конкретного клиентского компьютера или дочернего узла по обслуживанию обновлений, и определение, авторизованы ли клиентский компьютер или дочерний узел по обслуживанию обновлений обращаться к доступным обновлениям в узле 200 по обслуживанию обновлений. На те клиентские компьютеры и дочерние узлы по обслуживанию обновлений, которые аутентифицированы и авторизованы обращаться к обновлениям на узле по обслуживанию обновлений, модуль 210 аутентификации/авторизации выдает маркер авторизации, который должен быть использован вместе с получением обновлений. Выдача и использование маркера авторизации описаны более подробно ниже со ссылками на Фиг.4A и 4B.

Административный API 212 представляет интерфейс приложения, посредством которого осуществляется управление узлом 200 по обслуживанию обновлений и посредством которого обновления, в конечном счете, сохраняются и распределяются. Когда web-служба 202 обновлений принимает различные связанные с обновлениями запросы от клиентских компьютеров и дочерних узлов по обслуживанию обновлений, эти запросы, в конечном счете, встроены в вызовы в административный API 212, или непосредственно или косвенно, посредством модуля 204 обновления клиента и дочернего модуля 206 обновлений. Вместе с пользовательским интерфейсом 218 администрации или некоторой другой программой, установленной на узле 200 по обслуживанию обновлений, соответственно сконфигурированном для использования административного API 212, администратор в конечном счете управляет всеми аспектами процесса обновления для этого узла по обслуживанию обновлений, а также любых дочерних узлов по обслуживанию обновлений и клиентских компьютеров. Фактический вариант осуществления административного API приложен в качестве приложения к настоящему описанию и описан более подробно ниже со ссылками на Фиг.9-XX.

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

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

В соответствии с аспектами настоящего изобретения обновление программного обеспечения может быть представлено как являющееся "доступным" на узле 200 по обслуживанию обновлений для клиентских компьютеров и дочерних узлов по обслуживанию обновлений даже при том, что обновление не сохранено физически в хранилище 214 содержания обновлений. Более конкретно, вместо немедленной загрузки и сохранения фактических файлов обновления на узле 200 по обслуживанию обновлений, на узле по обслуживанию обновлений может вместо этого быть сохранена ссылка, ссылающаяся на файлы обновления на родительском узле по обслуживанию обновлений или в другом месте. Таким образом, если клиентский компьютер запрашивает обновление, или дочерний узел по обслуживанию обновлений запрашивает фактическое обновление, то обновление доставляется от родительского узла по обслуживанию обновлений и сохраняется в хранилище 214 содержания обновлений при подготовке к доставке его на клиентский компьютер или дочерний узел по обслуживанию обновлений. Специалисту ясно, что этот тип доступа к обновлению назван как оперативная (just-in-time) загрузка. Таким образом "доступное" обновление не должно быть распределено по различным сетевым каналам, пока оно фактически не будет запрошено. Согласно аспектам настоящего изобретения администратор узла 200 по обслуживанию обновлений может выборочно определить, нужно ли получать обновления программного обеспечения оперативным способом.

В то время как вышеупомянутое описание Фиг.2 иллюстрирует различные компоненты примерного модуля 200 по обслуживанию обновлений, должно быть оценено, что также могут существовать другие компоненты модуля по обслуживанию обновлений. Кроме того, должно быть понятно, что вышеупомянутые описанные компоненты являются логическими компонентами, не обязательно фактическими компонентами. При реальном воплощении вышеупомянутые идентифицированные компоненты могут быть объединены вместе и/или с другими компонентами согласно намерениям реализации. Дополнительно, должно быть оценено, что, в то время как узел 200 по обслуживанию обновлений может рассматриваться как серверный компьютер в сети, при фактической реализации узел по обслуживанию обновлений может быть осуществлен на любом количестве типов компьютерных устройств. Например, каждый узел 200 по обслуживанию обновлений может быть осуществлен и/или установлен на одиночной автономной компьютерной системе или, альтернативно, на распределенной вычислительной системе, содержащей множество компьютеров.

Фиг.3 изображает блок-схему, иллюстрирующую примерные логические компоненты корневого узла 300 по обслуживанию обновлений, такого как корневой узел 102 по обслуживанию обновлений, проиллюстрированный на Фиг.1, сформированного в соответствии с аспектами настоящего изобретения. Подобно логическим компонентам узла 200 по обслуживанию обновлений (Фиг.2), корневой узел 300 по обслуживанию обновлений включает в себя web-службу 202 обновлений, дочерний модуль 206 обновлений и модуль 210 аутентификации/авторизации. Дополнительно, примерный корневой узел 300 по обслуживанию обновлений также включает в себя административный API 212, хранилище 214 содержания обновлений и хранилище 216 информации обновлений. Необязательно, корневой узел 300 по обслуживанию обновлений может также включать в себя модуль 204 обновления клиента, модуль 208 отчетов и пользовательский интерфейс 218 администрации.

Модуль 204 обновления клиента является необязательным компонентом для корневого узла 300 по обслуживанию обновлений в зависимости от того, предоставляет ли корневой узел по обслуживанию обновлений обновления программного обеспечения непосредственно на клиентские компьютеры. Например, со ссылками на Фиг.1, корневой узел 102 по обслуживанию обновлений может включать в себя необязательный модуль 204 обновления клиента в качестве корневого узла по обслуживанию обновлений, который непосредственно обслуживает клиентский компьютер 112. Однако если корневой узел 300 по обслуживанию обновлений не должен непосредственно обслуживать клиентские компьютеры, клиентский модуль 204 обновлений может отсутствовать.

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

В дополнение к логическим компонентам, включенным в узел 200 по обслуживанию обновлений (Фиг.2), корневой узел 300 по обслуживанию обновлений также включает в себя интерфейс 302 провайдера программного обеспечения. Интерфейс 302 провайдера программного обеспечения обеспечивает интерфейс связи, посредством которого провайдер 110 программного обеспечения (Фиг.1) представляет обновления программного обеспечения непосредственно корневому узлу 300 по обслуживанию обновлений, и косвенно - примерной системе 100 распределения обновлений.

Аналогично узлу 200 по обслуживанию обновлений согласно Фиг.2, вышеупомянутое описание Фиг.3 иллюстрирует различные компоненты примерного корневого модуля 300 по обслуживанию обновлений. Однако должно быть понятно, что могут также существовать другие компоненты корневого модуля по обслуживанию обновлений. Кроме того, вышеупомянутые описанные компоненты должны быть восприняты как логические компоненты, а не обязательно как фактические компоненты. При фактической реализации вышеупомянутые идентифицированные компоненты могут быть объединены вместе и/или с другими компонентами согласно целям осуществления. Дополнительно, должно быть понятно, что хотя корневой узел 200 по обслуживанию обновлений может рассматриваться как серверный компьютер в отношении сети, при фактической реализации узел по обслуживанию обновлений может быть осуществлен на любом количестве компьютеров. Например, корневой узел 300 по обслуживанию обновлений может быть осуществлен и/или установлен на одиночной автономной компьютерной системе или, альтернативно, на распределенной вычислительной системе, содержащей множество компьютеров.

Чтобы лучше понять, как обновление распределяется от корневого узла по обслуживанию обновлений по всей системе 100 распределения обновлений, приводится иллюстрация примерного обмена между родительским узлом по обслуживанию обновлений и дочерним узлом по обслуживанию обновлений. Фиг.4 изображает блок-схему, иллюстрирующую примерный обмен 400 между родительским узлом 402 по обслуживанию обновлений и дочерним узлом 404 по обслуживанию обновлений при распространении обновления программного обеспечения от родительского узла по обслуживанию обновлений до дочернего узла по обслуживанию обновлений, в соответствии с аспектами настоящего изобретения. Как можно видеть, примерная диаграмма 400 разделена пополам, левая половина которой соответствует действиям и событиям родительского узла 402 по обслуживанию обновлений, а правая половина соответствует действиям и событиям дочернего узла 404 по обслуживанию обновлений.

С целью обсуждения со ссылками на Фиг.4, должно быть понятно, что родительский узел 402 по обслуживанию обновлений может быть или может не быть корневым узлом по обслуживанию обновлений в системе 100 распределения обновлений. Дополнительно, с целью описания предполагается, что родительский узел 402 по обслуживанию обновлений был сконфигурирован администратором так, что дочерний узел 404 по обслуживанию обновлений не может принимать обновления программного обеспечения, если он администратором явно не авторизован делать это.

Как показано в примерном обмене 400, начиная с события 406, родительский узел 402 по обслуживанию обновлений принимает обновление программного обеспечения от провайдера 110 программного обеспечения или непосредственно, если родительский узел по обслуживанию обновлений является корневым узлом 102 по обслуживанию обновлений, или косвенно через систему 100 распределения обновлений. В некоторый момент после того, как родительский узел 402 по обслуживанию обновлений принимает обновление программного обеспечения от провайдера 110 программного обеспечения, дочерний узел 404 по обслуживанию обновлений начинает процесс для получения обновлений программного обеспечения от родительского узла по обслуживанию обновлений.

Согласно одному варианту осуществления дочерний узел 404 по обслуживанию обновлений может быть конфигурирован так, чтобы автоматически получать обновления программного обеспечения, доступные от родительского узла 402 по обслуживанию обновлений, на периодической основе. Более конкретно, администратор посредством пользовательского интерфейса 218 администрации может выборочно конфигурировать дочерний узел 404 по обслуживанию обновлений, чтобы автоматически получать самые последние обновления программного обеспечения, доступные на родительском узле 402 по обслуживанию обновлений, на периодической основе. В качестве одного примера, администратор может сконфигурировать дочерний узел 404 по обслуживанию обновлений, чтобы получать самые последние обновления программного обеспечения от своего родительского узла 402 по обслуживанию обновлений на ежедневной и/или почасовой основе, а также определять "время дня", когда должен начаться автоматический процесс обновления. Могут также использоваться другие периодические графики и критерии. Точно так же, администратор может вручную инициализировать процесс обновления посредством пользовательского интерфейса 218 администрации.

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

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

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

Согласно аспектам настоящего изобретения дочернему узлу 404 по обслуживанию обновлений не требуется распространять все обновления программного обеспечения, доступные на его родительском узле 402 по обслуживанию обновлений. Например, со ссылкой на примерную систему распределения обновлений согласно Фиг.1, корпоративный узел 104 по обслуживанию обновлений может иметь лицензии узла только для части программных продуктов, доступных на корневом узле 102 по обслуживанию обновлений. Соответственно, может быть не нужно для корпоративного узла 104 по обслуживанию обновлений получать все обновления программного обеспечения, доступные в корневом узле 102 по обслуживанию обновлений, поскольку большинство из них никогда бы не использовались. Соответственно, администратор на узле по обслуживанию обновлений может выборочно устанавливать, какие обновления программного продукта должны быть доступны на узле по обслуживанию обновлений.

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

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

Во время события 418 дочерний узел 404 по обслуживанию обновлений подает запрос синхронизации обновления, наряду с маркером авторизации, идентифицируя выбранные продукты, для которых в настоящее время дочерний узел по обслуживанию обновлений ищет обновления. В запрос синхронизации включена информация, идентифицирующая самое последнее обновление, доступное для продукта на дочернем узле 404 по обслуживанию обновлений. Информация, идентифицирующая самое последнее обновление для продукта, ниже упомянута как "анкер обновления". Анкеры обновления для каждого программного продукта обычно сохраняются в хранилище 216 информации обновлений (Фиг.2). В одном варианте осуществления анкер обновления включает в себя номер редакции и дату, связанную с номером редакции.

В ответ на запрос синхронизации обновления, во время события 420 родительский узел 402 по обслуживанию обновлений определяет, какие, если таковые вообще имеются, новые обновления являются доступными для дочернего узла 404 по обслуживанию обновлений. Как упомянуто выше, это определение основано на конкретных правилах, связанных с конкретными обновлениями программных продуктов, и группе или группах, членом которых является дочерний узел 404 по обслуживанию обновлений, а также анкере обновления. Для этого примера, как упомянуто выше, ранее принятое обновление программного обеспечения не было явно авторизовано для дочернего узла 404 по обслуживанию обновлений. Поэтому обновление программного обеспечения, принятое во время события 406, не определяется как "доступное" дочернему узлу 404 по обслуживанию обновлений. Соответственно, во время события 422 список обновлений возвращается дочернему узлу 404 по обслуживанию обновлений без идентификации обновления программного обеспечения, принятого во время события 406. Согласно аспектам настоящего изобретения список обновлений идентифицирует все обновления, "доступные" на родительском узле 402 по обслуживанию обновлений согласно запросу синхронизации. В одном варианте осуществления список обновлений идентифицирует каждую "доступную" информацию обновления уникальным идентификатором, связанным с обновлением.

Во время события 424, так как список обновлений пуст, то есть, нет в настоящее время "доступных" обновлений на родительском узле 402 по обслуживанию обновлений, процесс обновления дочернего узла 404 по обслуживанию обновлений просто задерживается, или бездействует, в течение заранее определенного промежутка времени. Согласно настоящему примеру в течение этого времени задержки во время события 426 администратор в родительском узле 402 по обслуживанию обновлений авторизует обновление программного обеспечения, принятого во время события 406, для распределения дочернему узлу 404 по обслуживанию обновлений.

Во время события 428 (Фиг.4B) дочерний узел 404 по обслуживанию обновлений снова начинает автоматический процесс обновления посредством аутентификации и авторизации себя в родительском узле 402 по обслуживанию обновлений. В ответ, во время события 430, родительский узел 402 по обслуживанию обновлений возвращает маркер авторизации дочернему узлу 404 по обслуживанию обновлений.

Во время события 432 дочерний узел 404 по обслуживанию обновлений выдает запрос, наряду с маркером авторизации, к родительскому узлу 402 по обслуживанию обновлений для получения каталога обновления продуктов. Во время события 434 родительский узел 402 по обслуживанию обновлений возвращает каталог обновления продуктов дочернему узлу 404 по обслуживанию обновлений. Во время события 436 дочерний узел 404 по обслуживанию обновлений выбирает в каталоге обновлений продукты, для которых обновления желательны. Во время события 438 дочерний узел 404 по обслуживанию обновлений выдает запрос синхронизации обновления, идентифицирующий эти выбранные продукты маркером авторизации.

Поскольку дочерний узел 404 по обслуживанию обновлений был авторизован для получения обновления программного обеспечения, предварительно принятого во время события 406, во время события 440 родительский узел 402 по обслуживанию обновлений определяет, что обновление программного обеспечения "доступно" для дочернего узла по обслуживанию обновлений, и включает соответствующую информацию обновления в список обновлений. После этого, во время события 442 родительский узел 402 по обслуживанию обновлений возвращает список обновлений, теперь идентифицирующий обновление программного обеспечения, принятое во время события 406, дочернему узлу 404 по обслуживанию обновлений.

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

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

Как показано на Фиг.4B, при обновлении, идентифицированном в списке обновлений, во время события 444 дочерний узел 404 по обслуживанию обновлений запрашивает метаданные обновления для "доступного" обновления программного обеспечения согласно его уникальному идентификатору в списке обновлений. Как и для большинства других коммуникационных обменов с родительским узлом 402 по обслуживанию обновлений, запрос обновления подается с маркером авторизации. Должно быть отмечено, что в то время как в иллюстрированном примере все метаданные обновления загружают за одно обращение, согласно альтернативным аспектам настоящего изобретения (не показаны), метаданные обновления могут быть загружены более чем за одно обращение. Например, при первом обращении только элементы метаданных обновления необходимы для того, чтобы определить, является ли обновление программного обеспечения соответствующим (приемлемым) и/или желательно сначала загрузить, например, правила применимости и зависимости от других обновлений программного обеспечения. Затем, после того как определено, что обновление является соответствующим и/или желательным, может быть получена оставшаяся часть метаданных обновления. В ответ, во время события 446, родительский узел 402 по обслуживанию обновлений возвращает метаданные обновления для обновления программного обеспечения узла 404 по обслуживанию обновлений, который, в свою очередь, сохраняет метаданные обновления в хранилище 216 информации обновлений.

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

Необязательно, во время события 448 дочерний узел 404 по обслуживанию обновлений подает запрос на загрузку полезных данных обновления от родительского узла 402 по обслуживанию обновлений. В ответ, во время события 450, родительский узел 402 по обслуживанию обновлений возвращает полезные данные обновления дочернему узлу 404 по обслуживанию обновлений, который, в свою очередь, сохраняет их в хранилище 214 содержания обновлений.

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

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

Фиг.5 изображает последовательность выполнения операций, иллюстрирующую примерную подпрограмму 500, выполняемую на дочернем узле по обслуживанию обновлений, таком как корпоративный узел 104 по обслуживанию обновлений согласно Фиг.1, для периодического получения обновлений от его родительского узла по обслуживанию обновлений. Начиная с этапа 502, дочерний узел по обслуживанию обновлений получает синхронизированный список обновлений "доступных" обновлений от родительского узла по обслуживанию обновлений. Получение синхронизированного списка обновления "доступных" обновлений от родительского узла по обслуживанию обновлений описано ниже со ссылками на Фиг.6.

Фиг.6 иллюстрирует блок-схему последовательности операций примерной подпрограммы 600, подходящей для использования в примерной подпрограмме 500 согласно Фиг.5, для получения синхронизированного списка обновлений "доступных" обновлений от родительского узла по обслуживанию обновлений. Начиная с этапа 602, как описано выше со ссылками на Фиг.4A и 4B, дочерний узел по обслуживанию обновлений аутентифицирует и авторизует себя в родительском узле по обслуживанию обновлений и в ответ на надлежащую аутентификацию и авторизацию принимает маркер авторизации. На этапе 604, имея маркер авторизации, дочерний узел по обслуживанию обновлений устанавливает параметры связи с родительским узлом по обслуживанию обновлений. Устанавливающие связь параметры разрешают родительскому и дочернему узлам по обслуживанию обновлений должным образом устанавливать общее основание, которое понимают и родитель, и потомок. Параметры связи включают в себя, но не ограничиваются ими: протоколы или версии обновления связи; группирование продуктов и т.п.

Установив параметры связи с родительским узлом по обслуживанию обновлений, на этапе 606 дочерний узел по обслуживанию обновлений получает каталог обновления продуктов, описывающий программные продукты, для которых родительский узел по обслуживанию обновлений обеспечивает/распределяет обновления. На этапе 608 дочерний узел по обслуживанию обновлений выбирает те обновления программных продуктов, для которых в настоящее время разыскиваются обновления. На этапе 610 дочерний узел по обслуживанию обновлений выдает запрос синхронизации обновления к родительскому узлу по обслуживанию обновлений, включающий в себя и маркер авторизации и "анкер", связанный с выбранными программными продуктами, идентифицирующими текущую редакцию, и выполняет обновление уже на дочернем узле по обслуживанию обновлений.

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

Со ссылкой снова на Фиг.5, получив синхронизированный список обновления от родительского узла по обслуживанию обновлений, на этапе 504 принятия решений, выполняют определение относительно того, являются ли какие-либо обновления программного обеспечения в настоящее время "доступными" для загрузки от родительского узла по обслуживанию обновлений. Это определение делается согласно тому, имеются ли какие-либо идентификаторы обновлений, перечисленные в синхронизированном списке обновлений. Если никакие обновления программного обеспечения в настоящее время не "доступны" для загрузки, примерная подпрограмма 500 переходит к этапу 510 задержки, где выполняется программа задержки/бездействия до следующего периода обновления. Альтернативно, если имеются обновления, "доступные" для загрузки от родительского узла по обслуживанию обновлений, на этапе 506 дочерний узел по обслуживанию обновлений получает обновления от родительского узла по обслуживанию обновлений. Получение "доступных" обновлений от родительского узла по обслуживанию обновлений описано ниже со ссылками на Фиг.7.

Фиг.7 изображает последовательность выполнения операций подпрограммы 700, подходящей для использования в примерной подпрограмме 500 согласно Фиг.5, для получения "доступных" обновлений программного обеспечения от родительского узла по обслуживанию обновлений. Начиная с этапа 702, выбирают первый идентификатор обновления в списке обновлений. На этапе 704 дочерний узел по обслуживанию обновлений получает метаданные обновления, соответствующие выбранному идентификатору обновления, от родительского узла по обслуживанию обновлений и сохраняет их в хранилище 216 сообщений обновлений.

Согласно одному варианту осуществления на этапе 706 дочерний узел по обслуживанию обновлений получает полезные данные обновления, соответствующие выбранному идентификатору обновления, от родительского узла по обслуживанию обновлений и сохраняет полезные данные обновления в хранилище 214 содержания обновлений. Необязательно, содержание обновления не должно быть немедленно загружено в дочерний узел по обслуживанию обновлений. Как упомянуто выше, дочерний узел по обслуживанию обновлений может быть выборочно сконфигурирован так, чтобы загрузить обновления от родительского узла по обслуживанию обновлений оперативным способом. Согласно этой необязательной обработке, как проиллюстрировано на Фиг.7, вместо перехода от этапа 704 на этап 706, примерная подпрограмма 700 необязательно переходит от этапа 704 на этап 708 принятия решения.

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

Обращаясь снова к Фиг.5, получив "доступные" обновления от родительского узла по обслуживанию обновлений, на этапе 508 дочерний узел по обслуживанию обновлений выдает отчет о действиях по обновлению родительскому узлу по обслуживанию обновлений. После того, на этапе 510 задержки примерная подпрограмма 500 задерживается/бездействует в течение заранее определенного промежутка времени до следующего периода обновления, и затем переходит на этап 502, чтобы повторить вышеупомянутые процедуры обновления.

Как проиллюстрировано на Фиг.5, на этапе 504 принятия решения, даже когда никакие обновления не "доступны" на родительском узле по обслуживанию обновлений, дочерний узел по обслуживанию обновлений может быть необязательно сконфигурирован так, чтобы выдавать отчет о своих действиях по обновлению родительскому узлу по обслуживанию обновлений. Согласно этой альтернативной конфигурации, когда не имеется каких-либо доступных обновлений, примерная подпрограмма 500 не может переходить на этап 508, чтобы сообщать о действиях по обновлению.

Фиг.8 изображает последовательность операций примерной подпрограммы 800, реализованной на родительском узле по обслуживанию обновлений, для формирования синхронизированного списка обновления, идентифицирующего "доступные" обновления, в ответ на запрос синхронизации обновления от дочернего узла по обслуживанию обновлений. Начиная с этапа 802, родительский узел по обслуживанию обновлений принимает запрос синхронизации обновления от дочернего узла по обслуживанию обновлений для списка обновления, идентифицирующего "доступные" обновления. На этапе 804 выбирают первый программный продукт, идентифицированный в запросе синхронизации обновления.

На этапе 806 принятия решения выполняют определение относительно того, имеются ли какие-либо доступные обновления для идентифицированного программного продукта. Это определение делают согласно метаданным для программного продукта, сохраненного в хранилище 216 информации обновления, согласно анкеру обновления, обеспеченному дочерним узлом по обслуживанию обновлений, и согласно правилам распределения, связанным с группой, к которой принадлежит дочерний узел по обслуживанию обновлений. Согласно этому определению, если имеются "доступные" обновления, на этапе 808 уникальные идентификаторы обновления, связанные с "доступными" обновлениями, записывают в список обновлений. После записи уникальных идентификаторов обновления для "доступных" обновлений в список обновлений на этапе 810 принятия решения выполняют определение относительно того, имеются ли еще дополнительные программные продукты, идентифицированные в запросе синхронизации обновления. Если имеются дополнительные программные продукты обновления в запросе синхронизации обновления, на этапе 814 родительский узел по обслуживанию обновлений выбирает следующий программный продукт, идентифицированный в запросе синхронизации обновления, и возвращается на этап 806 принятия решения для определения, имеются ли "доступные" обновления для выбранного программного продукта. Альтернативно, если не имеется больше программных продуктов, идентифицированных в запросе синхронизации обновления, на этапе 814 список обновлений возвращают дочернему узлу по обслуживанию обновлений. После этого примерная подпрограмма 800 завершается.

Как упомянуто выше, узел по обслуживанию обновлений управляется посредством административного API 212 через пользовательский интерфейс 218 администрации или некоторый другой аналогично оборудованный модуль. Чтобы лучше понять, как работает административный API 212, на Фиг.9 изображена наглядная схема для иллюстрации, как административный API используется применительно к конфигурированию узла по обслуживанию обновлений, чтобы распределить обновления программного обеспечения клиентским компьютерам.

Как показано на Фиг.9, администратор использует административный API, чтобы сгенерировать подписки 904 и группы 906. Узел по обслуживанию обновлений, в течение процесса 908 обновления, использует обновления 902, доступные для этого узла по обслуживанию обновлений, а также подписки 904 и группы 906, чтобы распределять обновления клиентским компьютерам, таким как клиентские компьютеры 912-922.

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

Согласно одному варианту осуществления настоящего изобретения клиентские компьютеры организованы в группы, и подписки и обновления применяются к группам. В фактическом варианте осуществления каждый клиентский компьютер принадлежит двум группам: группе всех компьютеров, и одной другой группе. Согласно этому фактическому варианту осуществления узел по обслуживанию обновлений определил группу всех компьютеров и одну другую группу неназначенных компьютеров. Посредством административного API 212 администратор свободен определить любое количество других групп и назначенных клиентских компьютеров группе. Неназначение клиентского компьютера группе оставляет клиентский компьютер в группе неназначенных. Короче говоря, согласно этому варианту осуществления клиентский компьютер принадлежит группе всех компьютеров и одной другой. Группы могут включать в себя любое количество компьютеров клиентов. Группы клиентских компьютеров для применения обновлений программного обеспечения проиллюстрированы на Фиг.9 как рамки 910, 924 и 926.

Согласно фактическому варианту осуществления административный API 212 является интерфейсом, посредством которого служба обновлений программного обеспечения Windows корпорации Microsoft конфигурируется и управляется. В этом варианте осуществления административный API 212 обычно реализуется или является доступным с помощью интерфейсного объекта IUpdateServer. Описание фактического варианта осуществления интерфейсного объекта IUpdateServer приведено в конце этого раздела как Таблица. Этот интерфейсный объект IUpdateServer является частью документа административного API, включенного в качестве части предварительной заявки США на патент № 60/553042, поданной 12 марта 2004, которая включена здесь по ссылке. Однако различные интерфейсные вызовы, идентифицированные в Таблице 1, в общем, описываются ниже со ссылками на Фиг.10.

Фиг.10 изображает блок-схему, иллюстрирующую некоторые вызовы административного API для управления распределением обновлений программного обеспечения на узле по обслуживанию обновлений. Обращаясь к объекту 1002 IUpdateServer, вызывающий абонент может делать интерфейсные вызовы для получения информации 1004 о конфигурации узла по обслуживанию обновлений, информации 1006 о текущей подписке, текущих одобренных правилах 1008, информации 1010 о статусе узла по обслуживанию обновлений, о получении обновлений 1012, о клиентских компьютерах 1014 и получении групп 1016.

Интерфейсный вызов 1004 информации конфигурации обеспечивает доступ к конфигурируемым (и считываемым) значениям узла по обслуживанию обновлений, включающим, но не ограничиваясь ими, доступные языки, кто является родительским узлом по обслуживанию обновлений, и местоположение для этого родительского узла по обслуживанию обновлений, прокси-серверы и адреса, режим, в котором узел по обслуживанию обновлений синхронизирует обновления с его родительским узлом по обслуживанию обновлений, и т.п. В фактическом варианте осуществления, как описано в прилагаемом приложении, интерфейсный вызов 1004 информации конфигурации является интерфейсным вызовом "GetConfiguration" в отношении объекта IUpdateServer, который возвращает экземпляр интерфейсного объекта IConfiguration для узла по обслуживанию обновлений. Интерфейсный объект IConfiguration описан более подробно во включенном API предварительной заявки.

Интерфейсный вызов 1006 информации о подписке обеспечивает доступ к информации о подписке, включающей в себя, но не ограничиваясь им, состояние о самых последних работах по подписке, когда следующая работа по подписке (например, загрузка конкретного обновления на клиентский компьютер) будет закончена, частоту синхронизации подписки и т.п. В фактическом варианте осуществления имеются, по меньшей мере, два различных интерфейсных вызова для получения информации подписки. Интерфейсный вызов "GetSubscrition" для объекта IUpdateServer возвращает интерфейсный объект ISubscription, соответствующий конкретной подписке на узле по обслуживанию обновлений, и интерфейсный вызов "GetSubscriptions" возвращает совокупность (коллекцию) интерфейсных объектов ISubscription. Дополнительно, подписка создается с использованием интерфейсного вызова "CreateSubscription", который создает пустую подписку на узле по обслуживанию обновлений. Подробности интерфейсного объекта ISubscription описаны во включенном API предварительной заявки.

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

Интерфейсный вызов 1012 получения обновлений обеспечивает доступ к информации относительно доступных обновлений программного обеспечения. Более конкретно, интерфейсный вызов обеспечивает доступ ко всем обновлениям программного обеспечения, доступным в системе. В фактическом варианте осуществления имеются несколько интерфейсных вызовов для получения информации обновления. Интерфейсный вызов "GetUpdate" возвращает объект IUpdate, который обеспечивает информацию относительно конкретного обновления в отношении системы. Дополнительно, интерфейсный вызов "GetUpdates" возвращает совокупность объектов IUpdates, доступных для системы. Дополнительные подробности относительно этих интерфейсных вызовов обеспечиваются во включенном API предварительной заявки.

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

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

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

В отношении следующей таблицы, сокращение WUS получено от Windows Update Server (Сервера обновлений Windows).

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

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