ПОДДЕРЖКА УПРАВЛЕНИЯ ВЕРСИЯМИ В ЯЗЫКАХ И ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВАХ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ Российский патент 2009 года по МПК G06F21/22 

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

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

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

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

Отчасти это затрагивает процесс генерирования компьютеризованных инструкций (также упоминаемых в данной заявке как “программное обеспечение” или “программы”) для компьютеризованной системы. Первоначально, разработчик программного обеспечения должен был сначала обдумать требуемые функции или результаты, которые программа должна выполнять, и затем ввести соответствующие инструкции в текстовом формате в электронный текстовой файл, обычно в виде исходного кода программирования. В некоторых случаях, таких как с интерпретируемыми языками программирования (например, JavaScript, Perl и т.д.), компьютеризованная система непосредственно интерпретирует введенные инструкции в текстовом формате и выполняет требуемую функцию. В других случаях, таких как с компилируемыми языками программирования (например, С# произносится “си-шарп”, C++ и т.д.), инструкции в текстовом формате сначала компилируются в объектные или машинные коды, которые компьютеризованная система может исполнять.

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

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

В основном, запрашивающий компонент включает в себя ссылку на целевой компонент. Может оказаться, что запрашивающий компонент ссылается на конкретную версию целевого компонента (строгая ссылка). Ссылка на конкретную версию целевого компонента может иметь место, например, когда разработчик запрашивающего компонента имеет априорные сведения о целевом компоненте и желает сделать запрашивающий компонент явно зависимым от конкретной версии целевого компонента. Например, запрашивающий “компонент 1” может быть сконфигурирован для ссылки на целевую “версию 1.1” “компонента 3”, вызывая явную зависимость “компонента 1” от “версии 1.1” “компонента 3”. С другой стороны, может быть, что запрашивающий компонент ссылается на целевой компонент, который может существовать или может даже не существовать, когда запрашивающий компонент разрабатывался (свободная ссылка). Таким образом, разработчик ссылается на целевой компонент без априорных сведений о целевом компоненте. Следовательно, запрашивающий компонент может обнаружить существование версии целевого компонента на этапе выполнения. Например, “компонент 1” на этапе выполнения может найти “версию 2.1” “компонента 3”.

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

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

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

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

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

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

Краткое изложение сущности изобретения

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

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

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

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

Перечень фигур чертежей

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

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

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

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

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

фиг.4 - примерная логическая блок-схема способа предоставления доступа к компонентам в соответствии с принципами настоящего изобретения;

фиг.5А - примерная логическая блок-схема способа управления обновлениями компонентов в соответствии с принципами настоящего изобретения;

фиг.5В - примерная логическая блок-схема способа ограничения области применения компонента в соответствии с принципами настоящего изобретения; и

фиг.6 - подходящая среда для применения на практике аспектов настоящего изобретения.

Подробное описание предпочтительных вариантов выполнения

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

Варианты выполнения в объеме настоящего изобретения также включают в себя машиночитаемый носитель для переноса или хранения на нем машиноисполняемых инструкций или структур данных. Таким машиночитаемым носителем может быть любой доступный носитель, к которому может обращаться компьютер общего назначения или специального назначения. В качестве примера, но не ограничения, такой машиночитаемый носитель может содержать оперативное запоминающее устройство (ОЗУ, RAM), постоянное запоминающее устройство (ПЗУ, ROM), электрически стираемое программируемое ПЗУ (ЭСППЗУ, EEPROM), ПЗУ на компакт-диске (CD-ROM) или другое запоминающее устройство на оптических дисках, запоминающее устройство на магнитных дисках или другие магнитные устройства хранения данных, или любой другой носитель, который может использоваться для переноса или хранения требуемого средства программного кода в виде машиноисполняемых инструкций или структур данных, и к которым может обращаться компьютер общего назначения или специального назначения.

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

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

На фиг.1 показана примерная архитектура компьютера для применения на практике реализации настоящего изобретения, в которой определяющий модуль 100 принимает один или несколько запросов от запрашивающего компонента 105 на доступ к другому компоненту или программе, такому как компоненты 120, 125 и 130. Для целей данного описания изобретения и формулы изобретения “определяющий модуль” 100 может включать в себя модуль любого типа, исполняемые инструкции которого сконфигурированы, например, для идентификации ссылки на целевой компонент, которая включает в себя имя компонента и первоначально предполагаемую версию, и выбора соответствующего целевого компонента, который будет использоваться для выполнения запроса. В некоторых ситуациях это может включать в себя принятие решения в отношении того, что такого доступного целевого компонента нет, так что определяющий модуль 100 будет сконфигурирован на возврат ошибки. Как также подробно описывается ниже, определяющий модуль 100 также может быть сконфигурирован для идентификации другой информации, например, информации о том, какие другие компоненты уже стали доступны для доступа в системе, процессе или подпроцессе компьютера.

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

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

Как изображено на фиг.1, определяющий модуль 100 может принимать запрос или объявление от запрашивающего компонента 105 на доступ к целевому компоненту, такому как компонент 120, 125 и 130. Для целей данного описания и формулы изобретения термин “целевой компонент” соответствует компоненту, в отношении которого запрашивающий компонент стремится осуществлять доступ. Понятно, однако, что то является ли компонент целевым компонентом или запрашивающим компонентом, по существу, является вопросом перспективы, в зависимости от того, какой компонент запрашивает доступ к другому. По существу, изложение, применимое к целевым компонентам в данном описании изобретения и формуле изобретения, в равной степени может применяться к запрашивающим компонентам, и наоборот.

В любом случае, запрашивающий компонент 105 может инициировать запрос 110 доступа к компоненту при помощи определяющего модуля 100, где запрос указывает, что запрашивающий компонент 105 сконфигурирован для доступа к данной версии целевого компонента 120, 125 и 130. В некоторых реализациях запросом 110 может быть ссылка, обнаруживаемая в исходном коде запрашивающего компонента 105, когда запрашивающий компонент 105 изначально устанавливается в заданной компьютеризованной системе (не показана). Альтернативно, запрос 110 может быть выполнен запрашивающим компонентом 105, когда запрашивающий компонент 105 запрашивает доступ к заданной версии целевого компонента, такого как компоненты 120, 125 и 130, на этапе выполнения.

“Политика управления версиями”, для целей данного описания изобретения и формулы изобретения, включает в себя любое из заданного набора свойств, которое может быть передано с целевого компонента (например, 120, 125, 130) на определяющий модуль 100. Политика 131, 132 или 133 управления версиями определяет, может ли использоваться соответствующий целевой компонент 120, 125, 130 вместо версии заданного целевого компонента с меньшим номером версии. Политика управления версиями может включать в себя дополнительную информацию, предназначенную для использования определяющим модулем 100 для принятия решения в отношении того, может ли использоваться целевой компонент в заданной конфигурации. Таким образом, политика 132 управления версиями может задать, что целевой компонент 125 (версия 1.2) может использоваться, когда запрашивается версия 1.1. В некоторых вариантах выполнения политика управления версиями может находиться в предопределенном месте в целевом компоненте. В других реализациях политика управления версиями может передаваться на определяющий модуль 100, когда компонент устанавливается в системе, или когда выполняется первый запрос на доступ к заданному компоненту, и т.д.

Следовательно, запрашивающий компонент может запросить доступ к целевому компоненту посредством запроса конкретной версии целевого компонента, например, запроса 110 “версии 1.1” “компонента 1”. Если запрашивающий компонент 105 запрашивает или сконфигурирован для работы с конкретной версией целевого компонента, определяющий модуль 100 может предоставить запрашивающему компоненту 105 доступ к конкретной версии компонента, в зависимости от политики 131, 132, 133 управления версиями, которая присутствует в целевом компоненте. Как показано на фиг.1, например, запрашивающий компонент 105 запрашивает “версию 1” “компонента 1” посредством посылки запроса 110. Следовательно, определяющий модуль 100 разрешает доступ запрашивающему компоненту 105 к “версии 1.1” “компонента 1”, даже если в системе существует более поздняя версия “компонента 1”, например “версия 1.2” 125.

В противоположность этому, в некоторых вариантах выполнения запрос одной версии компонента приводит к доступу к другой (например, обновленной или более поздней) версии компонента. Например, запросом 100 может быть запрос на получение доступа к “версии 1.1” “компонента 1”. Однако политика 131 управления версиями может указать, что “версией 1.1” является компонент платформы (и, таким образом, наиболее поздняя версия “компонента 1” должна быть предоставлена в ответ на запрос). Кроме того, в некоторых реализациях, тем не менее, могут быть многочисленные версии заданного компонента платформы в системе.

По существу, запрашивающий компонент также может включать в себя информацию в своем запросе, которая указывает наименьшую возможную версию целевого компонента платформы, которую запрашивающий компонент 105 может принять. Например, может быть, что запрашивающий компонент 105 запрашивает “версию 1.4” “компонента 1” и что младшие версии “компонента 1” не должны возвращаться в ответ на запрос. Следовательно, определяющий модуль 100 может предоставить запрашивающему компоненту 105 доступ к “версии 3” “компонента 1”, даже если доступны “версия 1.1” и “версия 1.2”.

Когда все доступные версии запрашиваемого компонента имеют обозначения версии, которые младше, чем конкретная запрашиваемая версия, определяющий модуль 100 может возвратить соответствующий ответ (например, сообщение об ошибке) запрашивающему компоненту. Например, когда определяющий модуль 100 не имеет доступа к “версии 3” “компонента 1”, определяющий модуль 100 может послать сообщение об ошибке запрашивающему компоненту 105 в ответ на запрос “версии 1.4 или более старшей” “компонента 1”.

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

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

На фиг.2А иллюстрируется примерная архитектура компьютера, которая принимает более новые версии существующих компонентов. Т.е. определяющий модуль 100 может принимать обновления для целевых компонентов, которые уже являются резидентными в соответствующей компьютеризованной системе. Например, определяющий модуль 100 может принимать компоненты 215 и 210 от поставщика сетевых услуг (не показан), подсоединенного к сети 240. Определяющий модуль 100 может принимать компоненты 215 и 210 в результате выполнения программы установки в соответствующей компьютеризованной системе (или на поставщике сетевых услуг).

Как описано, компоненты 210 и 215 включают в себя информацию о политике управления версиями, такую как, например, информация о том, что обновленный компонент 210 представляет собой обновление “версии 3” “компонента 2” и что компонентом является компонент платформы. Также, компонент 215 может включать в себя информацию в виде политики управления версиями о том, что компонентом 215 является компонент библиотеки или что компонент 215 сконфигурирован иначе, так что запрашивающему компоненту может быть предоставлен доступ к конкретной версии, представленной компонентом 215.

В ответ на прием компонентов 210 и 215 определяющий модуль 100 определяет, сохранить ли предыдущие версии (что может упоминаться как “параллельное” обновление) или заменить предыдущие версии (что может упоминаться как обновление “на месте”) каждого принятого обновленного компонента. Например, как показано на фиг.2А, компонентами 220 и 235 являются, соответственно, компоненты библиотеки и платформы. Более конкретно, в ответ на прием компонента 215 определяющий модуль 100 может идентифицировать, что, поскольку “компонентом 1” является компонент библиотеки, другие программы или компоненты могут быть сконфигурированы для доступа конкретно к “версии 1” “компонента 1”. Следовательно, определяющий модуль 100 может определить, что должны быть сохранены как компонент 215, так и компонент 220.

Более конкретно, в ответ на прием компонента 210 определяющий модуль 100 может идентифицировать, что, поскольку “компонентом 2” является компонент платформы, запрашивающим программам и компонентам будет предоставлен доступ к наиболее поздней версии компонента 2. Следовательно, определяющий модуль 100 может определить, что компонент 235 должен быть заменен компонентом 210.

На фиг.2В иллюстрируется примерная архитектура компьютера по фиг.2А, после того как определяющий модуль определил версии компонентов, которые должны быть сохранены. Как изображено на фиг.2В, как “версия 1” (компонент 220), так и “версия 2” (компонент 215) компонента 1 остаются в системе (параллельное обновление). Также, как изображено на фиг.2В, только “версия 3” “компонента 2” (компонент 210) остается в системе (обновление на месте).

На фиг.3 иллюстрируется примерная архитектура компьютера для стратификации области применения компонента на различных уровнях обработки данных в соответствии с реализацией настоящего изобретения. Стратификация основывается на области применения компонента, которая применяется к целевым компонентам. В качестве объяснения, но не ограничения, на фиг.3 указаны три уровня области применения, т.е. уровень 330 “машины”, уровень 340 “процесса” и уровень 350 “подпроцесса”. Понятно, однако, после прочтения данного описания и формулы изобретения, что может быть большее или меньшее число уровней, как целесообразно. В частности, аспекты изобретения дают возможность целевому компоненту подать политику управления версиями, которая требует, чтобы только одна версия целевого компонента была сделана доступной на заданном уровне (т.е. только одна версия на всей машине, или только одна в заданном процессе, или только одна в заданном подпроцессе).

Например, политика управления версиями, которая связана с заданным целевым компонентом 300, может включать в себя набор области применения компонента. Обращаясь кратко опять же к фиг.1, область применения компонента может указывать на то, что запрашивающий компонент 105 должен осуществить доступ к целевому компоненту 300 на заданном уровне процесса. Как показано на фиг.3, например, “версия 1” 300 “компонента 1” идентифицируется для доступа на уровне машины. Любой запрашивающий компонент, установленный в системе, который запрашивает доступ к целевому компоненту 300, должен использовать “версию 1” “компонента 1”, так как целевой компонент 300 сконфигурирован для доступа на уровне машины. Как и в случае с другими свойствами политики управления версиями, данное ограничение уровня процесса может быть указано разработчиком целевого компонента до установки этого компонента в заданной системе.

Область применения компонента также может указывать большие или меньшие области применения для целевого компонента 300, 310, 315, 320 и 325. Например, “политики управления версиями”, идентифицированные с заданным компонентом 310, могут указывать, что заданная версия целевого компонента 310 требуется только в некотором процессе 342, 345 или подпроцессе 352, 355. Как показано на фиг.3, например, любой запрашивающий компонент 105, который запрашивает доступ к заданной версии компонента 310, может делать это в процессе 342 без необходимости того, чтобы другие запрашивающие компоненты (в системе) использовали этот же целевой компонент в других процессах 315. Как таковой, компонент 310 может использоваться в процессе 342, тогда как компонент 315 может использоваться в процессе 345. Кроме того, когда процесс А 342 не выбрал конкретную версию, подпроцесс 350, который зависит от процесса 340, может использовать различные версии компонента 310, такие как компоненты 320 и 325. Данный уровень гранулированного доступа к различным компонентам может, поэтому, указываться, когда заданный компонент разрабатывается, а не системным администратором, когда заданный компонент устанавливается в системе. Определяющий модуль 100 может объединять любую идентифицированную область применения компонента для каждого целевого или запрашивающего компонента для предоставления запрашивающему компоненту соответствующего доступа к целевому компоненту.

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

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

На фиг.4 изображена примерная логическая блок-схема способа предоставления доступа к компоненту в соответствии с реализацией настоящего изобретения. Способ по фиг.4 включает в себя действие 400 приема запроса версии целевого компонента. Действие 400 может включать в себя прием запроса на доступ к конкретной версии целевого компонента, причем этот запрос принимается от запрашивающего компонента. Например, запрашивающий компонент 105 может запросить доступ к целевому компоненту, такому как компонент 120, 125 и 130, при помощи определяющего модуля 100. Также может быть, что запрос включает в себя политику управления версиями версии целевого компонента.

Способ также включает в себя функциональный ориентированный на результат этап 440 предоставления соответствующего целевого компонента. Этап 440 может включать в себя любое количество соответствующих действий для реализации настоящего изобретения. Однако, как изображено на фиг.4, этап 440 включает в себя действие 410 идентификации политики управления версиями. Действие 410 может включать в себя идентификацию политики управления версиями конкретной версии целевого компонента. Если политика управления версиями была включена в запрос, то определяющий модуль 400 может идентифицировать такую включенную политику управления версиями. Альтернативно, определяющий модуль 100 может ссылаться на одну или несколько версий целевого компонента и идентифицировать политики управления версиями, хранимые в одной или нескольких версиях целевого компонента. Например, определяющий модуль 100 может идентифицировать, что многочисленные версии компонента, такие как “версия 1” 120 и “версия 2” 125 одного и того же “компонента 1”, существуют в системе, причем каждая имеет соответствующую политику 131, 132 и 133 управления версиями. Разработчик программного обеспечения может включить политику управления версиями в целевые компоненты 120, 125 и 130 и т.д., так что определяющий модуль 100 идентифицирует политику управления версиями при компиляции, установке и/или выполнении разработанной программы или компонента.

Этап 440 также включает в себя действие 430 предоставления соответствующей версии целевого компонента. Действие 430 может включать в себя идентификацию соответствующей версии целевого компонента на основе политики управления версиями конкретного целевого компонента. Например, определяющий модуль 100 может предоставить запрашивающему компоненту 105 конкретную версию запрашиваемого целевого компонента (компонента библиотеки), такого как компонент 120. Альтернативно, определяющий модуль 100 может предоставить запрашивающему компоненту 105 наиболее позднюю версию компонента (компонента платформы), такого как компонент 130.

На фиг.5А изображена примерная логическая блок-схема способа управления обновлениями компонентов в соответствии с реализацией настоящего изобретения. Способ по фиг.5А может быть реализован так, что запрашивающий компонент, который выполняет доступ к целевому компоненту, продолжает эффективно работать после обновления целевого компонента. Как изображено, способ, изображенный на фиг.5А, включает в себя действие 500 приема обновления компонента. Действие 500 также может включать в себя идентификацию того, что к целевому компоненту выполняет доступ запрашивающий компонент. Например, ссылаясь обратно на фиг.1, определяющий модуль 100 может быть связан, или содержать, с системным реестром или базой данных, которая после установки запрашивающего компонента 105 идентифицирует, что установленная программа или компонент или компонент 105 сконфигурирован для доступа к конкретной версии целевого компонента, такой как “версия 1” 120 “компонента 1”. Этот определяющий модуль 100 может получить данную информацию, основываясь на любой политике управления версиями, содержащейся в установленной программе, а также содержащейся в любых компонентах, для доступа к которым программа сконфигурирована.

Способ, изображенный на фиг.5А, включает в себя действие 510 идентификации политики управления версиями. Действие 510 может включать в себя идентификацию политики управления версиями в предыдущей версии целевого компонента и в обновленной версии целевого компонента. Например, определяющий модуль 100 идентифицирует политику управления версиями в любом целевом компоненте 120, 125 и 130, который, как ранее описано, может указывать версию целевого компонента 120, 125 и 130 и может указывать, что целевой компонент, как предполагается, является компонентом платформы или библиотеки.

Способ, описанный на фиг.5А, дополнительно включает в себя действие 520 добавления обновления компонента к системе на основе, по меньшей мере частично, политики управления версиями. Действие 520 может включать в себя удаление предыдущей версии целевого компонента и/или добавление обновленной версии целевого компонента на основе идентифицированной политики управления версиями. Например, если конкретная предыдущая версия 220 компонента требуется для доступа другой программой или компонентом, например, если компонентом является компонент библиотеки, определяющий модуль 100 не будет переписывать предыдущую версию 220. Определяющий модуль 100 просто добавит новую версию 215 компонента, так чтобы программы или компоненты, которые запрашивают новую версию 215 компонента, могли выполнить доступ к ней. Аналогично, программы или компоненты, которые требуют предыдущую версию 220 компонента, также могут выполнить доступ к ней, что сохраняет целостность запрашивающей программы или компонента. В противоположность этому, если не идентифицируется программа или компонент, требующий конкретную версию заданного компонента (компонента платформы), определяющий модуль 100 может просто переписать предыдущую версию 235 компонента последней версией 210 компонента.

На фиг.5В изображена примерная логическая блок-схема способа предоставления доступа к компоненту на одном или нескольких уровнях процесса в соответствии с реализацией настоящего изобретения. Способ по фиг.5В может быть реализован для организации одного или нескольких целевых компонентов, так чтобы доступ к одному или нескольким целевым компонентам был органичен. Способ, изображенный на фиг.5В, включает в себя действие 550 идентификации политики управления версиями. Действие 550 может включать в себя идентификацию политики управления версиями в целевом компоненте. Например, определяющий модуль 100 может принять запрос доступа к компоненту от запрашивающего компонента и может идентифицировать управление версиями из принимаемого обновления 215, 210 в существующем целевом компоненте 220, 225 и т.д. Как ранее описано, политика управления версиями может помочь системе идентифицировать номер версии целевого компонента, а также определить то, является ли целевой компонент 220, 225 и 230 компонентом библиотеки или платформы.

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

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

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

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

Со ссылкой на фиг.6, примерная система для реализации изобретения включает в себя вычислительное устройство общего назначения в виде обычного компьютера 620, включающего в себя блок 621 обработки данных, системную память 622 и системную шину 623, которая соединяет различные системные компоненты, включая системную память 622, с блоком 621 обработки данных. Системная шина 623 может быть любого из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину и локальную шину, используя любую из многочисленных шинных архитектур. Системная память включает в себя постоянное запоминающее устройство (ПЗУ) 624 и оперативное запоминающее устройство (ОЗУ) 625. Базовая система 626 ввода-вывода (BIOS), содержащая базовые процедуры, которые способствуют переносу информации между элементами в компьютере 620, например во время запуска, может храниться в ПЗУ 624.

Компьютер 620 также может включать в себя накопитель 627 на магнитных жестких дисках для считывания и записи на магнитный жесткий диск 639, дисковод 628 для магнитного диска для считывания и записи на съемный магнитный диск 629 и дисковод 630 для оптического диска для считывания и записи на съемный оптический диск 631, такой как компакт-диск или другой оптический носитель. Накопитель 627 на магнитных жестких дисках, дисковод 628 для магнитного диска и дисковод 630 для оптического диска подсоединены к системной шине 623 при помощи интерфейса 632 накопителя на жестких дисках, интерфейса 633 дисковода для магнитного диска и интерфейса 634 дисковода для оптического диска, соответственно. Накопители и дисководы, связанные с ними машиночитаемые носители обеспечивают энергонезависимое хранение машиноисполняемых инструкций, структур данных, программных модулей и других данных для компьютера 620. Хотя в примерной среде, описанной в данной заявке, используется магнитный жесткий диск 639, съемный магнитный диск 629 и съемный оптический диск 631, могут использоваться другие типы машиночитаемых носителей для хранения данных, включая магнитные кассеты, карты флэш-памяти, цифровые многофункциональные диски, картриджи Бернулли, ОЗУ, ПЗУ и т.д.

Средство программного кода, содержащее один или несколько программных модулей, может храниться на жестком диске 639, магнитном диске 629, оптическом диске 631, в ПЗУ 624 или ОЗУ 625, включая операционную систему 635, одну или несколько прикладных программ 636, другие программные модули 637 и данные 638 программ. Пользователь может вводить команды и информацию в компьютер 620 при помощи клавиатуры 640, указательного устройства 642 или других устройств ввода (не показаны), таких как микрофон, джойстик, игровой планшет, антенна спутниковой связи, сканер и т.д. Эти и другие устройства ввода часто подключаются к блоку 621 обработки через интерфейс 646 последовательного порта, соединенный с системной шиной 623. Альтернативно, устройства ввода могут подключаться при помощи других интерфейсов, таких как параллельный порт, игровой порт или универсальная последовательная шина (USB). Монитор 647 или другое устройство отображения также подключается к системной шине 623 через интерфейс, такой как видеоадаптер 648. В дополнение к монитору персональные компьютеры обычно включают в себя другие периферийные устройства вывода (не показаны), такие как громкоговорители и принтеры.

Компьютер 620 может работать в сетевой среде, используя логические соединения с одним или несколькими удаленными компьютерами, такими как удаленные компьютеры 649а и 649b. Каждый удаленный компьютер 649а и 649b может представлять собой другой персональный компьютер, сервер, маршрутизатор, сетевой ПК, одноранговое устройство или другой общий сетевой узел и обычно включает в себя многие или все элементы, описанные выше в отношении компьютера 620, хотя только устройства 650а и 650b хранения данных и связанные с ними прикладные программы 636а и 636b изображены на фиг.6. Логические соединения, изображенные на фиг.6, включают в себя локальную сеть (ЛС, LAN) 651 и глобальную сеть (ГС, WAN) 652, которые представлены здесь в качестве примера, но не ограничения. Такие сетевые среды являются общепринятыми в компьютерных сетях масштаба офиса или предприятия, интрасетях и Интернете.

При использовании в сетевой среде ЛС компьютер 620 соединяется с локальной сетью 651 при помощи сетевого интерфейса или адаптера 653. При использовании в сетевой среде ГС компьютер 620 может включать в себя модем 654, беспроводную линию связи или другое средство для установления связи по глобальной сети 652, такой как Интернет. Модем 654, который может быть внутренним или внешним, соединен с системной шиной 623 при помощи интерфейса 646 последовательного порта. В сетевой среде программные модули, описанные в отношении компьютера 620 или его частей, могут храниться в удаленном устройстве хранения данных. Понятно, что показанные сетевые соединения являются примерными, и могут использоваться другие средства установления связи по глобальной сети 652.

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

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

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

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

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

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

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

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

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

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

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

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

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

12. Способ по п.10, в котором каждая политика управления версиями в каждой версии целевого компонента идентифицирует конкретную версию запрашивающего компонента, сконфигурированного для доступа к этому целевому компоненту.

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

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

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

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

17. Способ по п.16, в котором при идентификации соответствующей версии целевого компонента идентифицируют обновленный сервис целевого компонента.

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

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

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

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