Тэговая схема распространения метаданных обновления в системе распространения обновлений

Тэговая схема распространения метаданных обновления в системе распространения обновлений

Иллюстрации

Показать все

Реферат

ОПИСАНИЕ

Область техники, к которой относится изобретение

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

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

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

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

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

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

(1) эффективность, относящуюся к инфраструктуре/ресурсам распространения обновлений, и

(2) административный контроль над распространением и установкой обновлений программного обеспечения.

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

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

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

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

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

Раскрытие изобретения

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

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

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

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

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

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

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

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

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

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

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

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

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

Осуществление изобретения

Согласно аспектам настоящего изобретения, представлена система распространения обновлений, организованная в иерархическом порядке, для распространения обновлений программного обеспечения. На фиг.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 может соответствовать общей корпоративной сети 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 службы обновлений содержит веб-службу 202 обновлений, модуль 204 обновлений клиентов, модуль 206 обновлений потомков и модуль 208 отчетов. Иллюстративный узел 200 службы обновлений также содержит модуль 210 аутентификации/авторизации, программный интерфейс приложений (API) 212 администрирования, хранилище 214 содержимого обновлений, пользовательский интерфейс 218 администрирования и хранилище 216 информации обновлений.

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

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

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

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

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

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

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

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

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

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

На фиг.3 изображена блок-схема иллюстративных логических компонентов корневого узла 300 службы обновлений, например, корневого узла 102 службы обновлений, показанного на фиг.1, сформированного согласно аспектам настоящего изобретения. По аналогии с логическими компонентами узла 200 службы обновлений (фиг.2) корневой узел 300 службы обновлений содержит веб-службу 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 службы обновлений может быть реализован и/или установлен в единичной автономной компьютерной системе или, альтернативно, в распределенной вычислительной системе, содержащей множественные вычислительные устройства.

Чтобы можно было лучше понять, как обновление распространяется от