Программный интерфейс приложений для администрирования распределением обновлений программного обеспечения в системе распределения обновлений

Программный интерфейс приложений для администрирования распределением обновлений программного обеспечения в системе распределения обновлений

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

В то время как Интернет в настоящее время обычно используется как канал для распределения обновлений программного обеспечения от провайдеров программного обеспечения, часто возникают несколько проблем. Две такие проблемы включают в себя (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 администрации.

Как упомянуто выше, согласно одному вариа