RU2446456C2 - Интегрирование учрежденческих поисковых систем со специальными интерфейсами прикладного программирования управления доступом - Google Patents

Интегрирование учрежденческих поисковых систем со специальными интерфейсами прикладного программирования управления доступом Download PDF

Info

Publication number
RU2446456C2
RU2446456C2 RU2009126367/08A RU2009126367A RU2446456C2 RU 2446456 C2 RU2446456 C2 RU 2446456C2 RU 2009126367/08 A RU2009126367/08 A RU 2009126367/08A RU 2009126367 A RU2009126367 A RU 2009126367A RU 2446456 C2 RU2446456 C2 RU 2446456C2
Authority
RU
Russia
Prior art keywords
api
document
call
access rights
special
Prior art date
Application number
RU2009126367/08A
Other languages
English (en)
Other versions
RU2009126367A (ru
Inventor
Аршиш Сайрус КАПАДИА (US)
Аршиш Сайрус КАПАДИА
Джоуна Сарбин БЕРК (US)
Джоуна Сарбин БЕРК
Original Assignee
Майкрософт Корпорейшн
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Майкрософт Корпорейшн filed Critical Майкрософт Корпорейшн
Publication of RU2009126367A publication Critical patent/RU2009126367A/ru
Application granted granted Critical
Publication of RU2446456C2 publication Critical patent/RU2446456C2/ru

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6236—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database between heterogeneous systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
    • G06F9/4482—Procedural
    • G06F9/4484—Executing subprograms
    • G06F9/4486—Formation of subprogram jump address

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Bioethics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

УРОВЕНЬ ТЕХНИКИ
Учрежденческие поисковые системы дают возможность, чтобы для авторизованных в рамках организации пользователей осуществлялось индексирование, извлечение и отображение контента, хранимого в рамках организации. Чтобы обеспечивать такую функциональность, учрежденческие поисковые службы обычно должны осуществлять индексирование и запросы по отношению к структурированным и неструктурированным данным и документам, хранимым посредством многих независимых, разработанных сторонними разработчиками учрежденческих программных приложений и систем. Например, во многих случаях учрежденческая поисковая система должна индексировать и запрашивать данные, хранимые во внутренних сетях организаций, системах управления документами и контентом, файловых серверах, корпоративных хранилищах писем или документов, бизнес-приложениях, например приложениях для управления взаимоотношениями с клиентами и интеллектуальными ресурсами предприятия, и других типах хранилищ контента.
В отличие от поисковых служб с открытым доступом, которые осуществляют поиск общедоступных данных и позволяют фактически любому пользователю исполнять запросы относительно данных, таких как поисковые службы «Всемирной паутины» (Web), учрежденческие поисковые системы обычно индексируют данные, для которых может быть ограниченным доступ к ним. Например, документ, индексированный посредством учрежденческой поисковой системы, может иметь связанный с ним «список контроля доступа» (ACL), который включает в себя один или несколько элементов контроля доступа (ACE), устанавливающих права доступа, имеющиеся у пользователя по отношению к документу. В результате, при исполнении учрежденческой поисковой системой запроса, она должна обеспечивать, чтобы исполняющий запрос пользователь имел достаточные права доступа, чтобы просматривать результаты поиска, возвращенные в ответ на запрос.
Чтобы определять, имеет ли пользователь достаточные права доступа для просмотра результатов поиска, учрежденческая поисковая система может извлекать и хранить права доступа к документу во время добавления документа к поисковому индексу. Во время запроса учрежденческая поисковая система может использовать предварительно сохраненные права доступа, чтобы определять, имеет ли исполняющий запрос пользователь достаточные права для просмотра результатов поиска. В качестве альтернативы учрежденческая поисковая система может во время исполнения запроса запрашивать внутреннюю систему, в которой хранится каждый документ из совокупности результатов поиска, относительно прав доступа к документу для пользователя. Комбинация этих способов также может использоваться, чтобы минимизировать недостатки, присутствующие в каждом способе.
Независимо от того, извлекаются ли права доступа во время добавления документа к поисковому индексу или во время запроса, учрежденческие поисковые системы для извлечения права доступа должны взаимодействовать с системами внутреннего компьютера, в которых хранятся индексированные документы. Зачастую, однако, подсистемы безопасности каждой разработанной сторонними разработчиками системы внутреннего компьютера используют прикладные программные интерфейсы (application programming interface, API), которые являются несовместимыми, секретными и составляющими собственность. В результате, может иметься необходимость создавать специальный программный код для осуществления интерфейса с API каждой внутренней подсистемы безопасности всякий раз при добавлении к учрежденческой поисковой системе нового типа внутреннего хранилища контента. Это обычно делает трудной, дорогостоящей, и трудоемкой интеграцию между учрежденческими поисковыми системами и разработанными сторонними разработчиками системами хранилищ данных.
В отношении этих и других соображений в документе представлено раскрытие сущности изобретения.
КРАТКОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
В документе представлены способы и машиночитаемый носитель, предназначенные для интегрирования учрежденческих поисковых систем со специальными API, открыто предоставляемыми внутренними хранилищами контента для получения данных о правах доступа. В соответствии с аспектами, представленными в документе, используется декларативная модель метаданных, чтобы создавать и хранить данные, описывающие специальный API, предоставляемый внутренним хранилищем контента для извлечения прав доступа относительно хранимых в нем документов. Нормализованный API для получения прав доступа относительно документа является также открыто предоставляемым. При выполнении вызова нормализованного API используются хранимые данные, чтобы преобразовать вызов нормализованного API в вызов специального API. Таким образом, может быть получен доступ к правам доступа, хранимым посредством составляющей собственность внутренней вычислительной системы, без написания какого-либо программного кода.
Согласно одному аспекту, представленному в документе, создаются и хранятся данные, которые описывают специальный API, предоставляемый внутренней вычислительной системой для получения прав доступа относительно документа. Хранимые данные могут включать информацию, например, идентифицирующую параметры метода, предоставляемого специальным API для получения прав доступа, и данные, указывающие, является ли каждый из параметров входным параметром или выходным параметром. Один из параметров может также быть помечен для указания, что параметр соответствует идентификатору документа, относительно которого запрашиваются права доступа. Другой из параметров может быть помечен для указания, что он соответствует поставляемому системой значению, например идентификатору пользователя для текущего пользователя. Также могут указываться и храниться заданные по умолчанию значения для каждого из параметров.
Согласно другим аспектам нормализованный API может предоставляться приложениям, исполняющимся в рамках учрежденческой поисковой системы, для получения прав доступа относительно документа. Интерфейс, представленный нормализованным API, является согласованным интерфейсом, который могут использовать различные приложения, исполняющиеся в рамках учрежденческой поисковой системы, чтобы получать права доступа относительно документа, независимо от хранилища контента внутренней части, на котором документ постоянно находится. Например, программа поискового агента и программа процессора запросов обе могут использовать метод, предоставляемый нормализованным API, чтобы получать права доступа относительно документа. Метод, предоставляемый нормализованным API, принимает параметр, идентифицирующий документ, относительно которого запрашиваются права доступа, и может, необязательно, принимать идентификатор пользователя для целей аутентификации.
Когда принимается вызов метода, предоставляемого нормализованным API для извлечения прав доступа относительно указанного документа, вызов нормализованного API динамически преобразуется в вызов надлежащего специального API с использованием хранимых данных. Например, хранимые данные могут использоваться, чтобы создавать экземпляр вызова метода, предоставляемого специальным API, с использованием заданных по умолчанию значений для его параметров. Параметр, идентифицирующий документ, относительно которого запрашиваются права доступа, который принимается вместе с вызовом нормализованного API, затем подставляется вместо заданного по умолчанию значения параметра, помеченного в качестве соответствующего идентификатору документа в специальном API.
Согласно вариантам исполнения идентификатор пользователя, соответствующий текущему пользователю, также может быть подставлен вместо заданного по умолчанию значения параметра, помеченного в качестве соответствующего поставляемому системой значению. Как только параметры были указаны, исполняется вызов специального API. Специальный API затем возвращает запрошенные права доступа в ответ на вызов. Права доступа, возвращенные из специального API, затем возвращаются в ответ на первоначальный вызов нормализованного API.
Вышеописанный объект изобретения также может быть осуществлен в виде управляемого компьютером устройства, вычислительного процесса, вычислительной системы или в виде изделия, такого как машиночитаемый носитель. Эти и различные другие признаки будут очевидны из рассмотрения нижеследующего подробного описания и анализа сопроводительных чертежей.
Данное краткое описание предусмотрено, чтобы представить в упрощенной форме подборку концепций, которые дополнительно описаны ниже в подробном описании. Данное краткое описание не предназначается ни для определения ключевых признаков или существенных признаков представленного в формуле объекта изобретения, оно также не предназначается для использования для ограничения объема, представленного в формуле объекта изобретения. Кроме того, представленный в формуле объект изобретения не ограничивается вариантами осуществления, разрешающими некоторые или все отмеченные недостатки, в любой части данного раскрытия изобретения.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Фиг.1 - схема архитектуры сети и программного обеспечения, показывающая иллюстративную операционную среду для процессов и вычислительных систем, описанных в документе, и несколько программных компонентов, используемых вычислительными системами, описанными в документе;
Фиг.2 - схема архитектуры программного обеспечения, показывающая аспекты программы API-преобразователя, представленной в одном варианте осуществления, описанном в документе;
Фиг.3 и 4 - схемы последовательности операций, иллюстрирующие процессы, представленные в документе в соответствии с вариантами осуществления, предназначенные для получения прав доступа относительно документа во время добавления документа к поисковому индексу и для получения прав доступа относительно документа во время поиска, соответственно;
Фиг.5 - схема архитектуры вычислительной системы, показывающая архитектуру вычислительной системы, подходящую для осуществления различных вычислительных систем, описанных в документе.
ПОДРОБНОЕ ОПИСАНИЕ СУЩНОСТИ ИЗОБРЕТЕНИЯ
Нижеследующее подробное описание направлено на системы, способы и машиночитаемый носитель, предназначенные для интегрирования учрежденческих поисковых систем со специальными API управления доступом к внутреннему хранилищу контента. Хотя описанный в документе объект изобретения представлен в общем контексте программных модулей, которые исполняются на вычислительной системе вместе с исполнением операционной системы и прикладных программ, специалисты в данной области техники признают, что могут быть выполнены другие исполнения в комбинации с другими типами программных модулей.
Обычно программные модули включают в себя подпрограммы, программы, компоненты, структуры данных и другие типы структур, которые выполняют конкретные задачи или реализуют особые абстрактные типы данных. Кроме того, специалисты в данной области техники оценят, что описанный в документе объект изобретения может быть осуществлен с помощью других конфигураций вычислительной системы, включающих в себя переносные устройства, мультипроцессорные системы, микропроцессорную или программируемую бытовую электронику, миникомпьютеры, универсальные компьютеры и подобное.
Описываемая сущность изобретения также описывается как реализуемая на практике в распределенной вычислительной среде, где задачи выполняются посредством удаленных устройств обработки, которые являются связанными посредством системы связи, и при этом программные модули могут располагаться и в локальных, и в удаленных запоминающих устройствах. Однако понятно, что описанные в документе исполнения могут также использоваться вместе с автономными вычислительными системами и другими типами вычислительных устройств. Также понятно, что представленные в документе варианты осуществления могут использоваться с любым типом локальной вычислительной сети (LAN) или глобальной вычислительной сети (WAN).
В нижеследующем подробном описании изобретения выполняются ссылки на сопроводительные чертежи, которые составляют его часть и которые показаны в качестве иллюстрации конкретных вариантов осуществления или примеров. Далее со ссылками на чертежи, на которых сходные ссылочные позиции представляют сходные элементы на чертежах, описываются аспекты вычислительной системы и методы, предназначенные для интегрирования учрежденческих поисковых систем со специальными API управления доступом внутреннего хранилища контента. В частности, на Фиг.1 показана схема архитектуры программного обеспечения вычислительной системы и сети, иллюстрирующая некоторую операционную среду 100 для описываемого в документе объекта изобретения, которая включает в состав клиентский компьютер 102, сеть 122 и один или несколько компьютеров 104A-104B Web-серверов.
Как показано на Фиг.1, клиентский компьютер 102 и компьютеры 104A-104B Web-серверов коммуникативно соединены между собой посредством соответственных соединений с сетью 122. Согласно одному исполнению сеть 122 содержит Интернет. Однако должно быть оценено, что сеть 122 может содержать LAN, WAN или другой тип сети, подходящей для соединения клиентского компьютера 102 и компьютеров 104A-104B Web-серверов. Компьютеры 104A-104B Web-серверов также соединены с внутренней системой 112. Серверная система 112 является вычислительной системой, способной хранить документы в хранилище 114 контента. Как используется в документе, термин «документ» означает любую индексируемую единицу данных. Дополнительные подробности относительно действия внутренней системы 112 представлены ниже.
На Фиг.1, также иллюстрируется ряд программных компонентов, используемых клиентским компьютером 102 и компьютерами 104A-104B Web-серверов. В частности, компьютеры 104A-104B Web-серверов действуют, чтобы исполнять «поисковые агенты» 106A-106B, соответственно. Поисковые агенты 106A-106B являются прикладными программами, разработанными для сбора документов из различных источников, например документов, хранимых в хранилище 114 контента в составе внутренней системы 112. Серверная система 112 может содержать любой тип вычислительной системы, используемой для хранения контента, такой как сервер внутренней сети организации, система управления документами или контентом, файловый сервер, учрежденческое хранилище писем или документов, бизнес-приложения, такие как приложения для управления взаимоотношениями с клиентами и интеллектуальными ресурсами предприятия или другие типы хранилищ контента.
Для выполнения этого процесса идентификации и индексирования документа поисковые агенты 106A-106B первоначально наполняются информацией о хранилищах контента. Поисковые агенты 106A-106B затем извлекают документы из хранилищ контента, индексируют документы и сохраняют индексированный контент, и любые связанные с ним метаданные в базе данных, вызываемой поисковым индексом 108. Поисковые агенты 106A-106B также могут определять содержащиеся в каждом документе гипертекстовые ссылки на другие документы и следовать ссылкам, чтобы получать и индексировать дополнительные документы. Этот процесс именуется "ползанием".
В течение процесса следования ссылкам поисковые агенты 106A-106B могут также получить права доступа относительно каждого документа, который индексируется. Например, поисковые агенты 106A-106B могут получать перечень авторизованных пользователей для каждого документа. Согласно одному исполнению права доступа получают путем использования надлежащего API-преобразователя 110A-110B, чтобы запрашивать внутреннюю систему 112 относительно перечня авторизованных пользователей. Дополнительные подробности, относящиеся к использованию и действию API-преобразователей 110A-110B, представлены ниже.
Согласно одному исполнению клиентский компьютер 102 включает в себя программу 116 Web-браузера (именуемую в документе "браузер"). Браузер 116 действует, чтобы запрашивать, принимать и отображать страницы информации, такие как Web-страницы, от внутренних компьютеров 104A-104B. В частности, браузер 116 действует, чтобы установить соединение с одним из приложений Web-серверов 118A-118B, исполняющимся на внутренних компьютерах 104A-104B. Посредством соединения браузер 116 может запрашивать Web-страницу для исполнения запроса поискового индекса 108. Такой поисковый запрос обрабатывается процессором 120A-120B запросов, выполняющемся на компьютере 104A-104B Web-сервера, который заполняет поля поискового запроса.
Процессоры 120A-120B запросов отвечают на пользовательские запросы согласно идентификации документов в поисковом индексе 108, который содержит ключевые слова из пользовательского запроса. Процессоры 120A-120B запросов также оценивают, следует ли возвращать каждый документ в качестве результата поиска, на основании того, имеет ли пользователь, выполняющий запрос, достаточные права доступа для просмотра каждого документа. Как будет описано более подробно ниже, каждый процессор 120A-120B запросов может динамически запрашивать внутреннюю систему 112 относительно прав доступа, указывающих, имеет ли пользователь, исполняющий запрос, разрешения для просмотра каждого документа из результатов поиска. Этот запрос активизируется посредством надлежащего API-преобразователя 110A-110B.
Как будет обсуждено более подробно в документе, API-преобразователи 110A-110B предоставляют нормализованный API для получения права доступа относительно документа. Например, в одном исполнении, API-преобразователи 110A-110B предоставляют метод для использования поисковыми агентами 106A-106B, предназначенный для извлечения прав доступа относительно документов, выявленных в течение процесса следования ссылкам. В ответ на вызов такого метода API-преобразователи 110A-110B преобразуют нормализованный вызов, принятый от поискового агента, в конкретный специальный API прав доступа, предоставляемый внутренней системой 112. Права доступа, возвращенные из внутренней системы, затем возвращаются вызывающему поисковому агенту.
Согласно другим аспектам нормализованный API, предоставляемый API-преобразователями 110A-110B, может также использоваться процессорами 120A-120B запросов во время запроса, чтобы извлекать права доступа относительно документов, идентифицированных в результатах поискового запроса. В этом случае процессоры 120A-120B запросов могут вызывать нормализованный API, предоставляемый соответственным API-преобразователем 110A-110B. В ответ на такой запрос API-преобразователи 110A-110B преобразуют нормализованный запрос, принятый от поискового агента, в запрос конкретного специального API прав доступа, предоставляемого внутренней системой 112. Права доступа, возвращенные из внутренней системы 112, затем возвращаются вызывающему процессору запросов. Дополнительные подробности относительно использования и действия API-преобразователей 110A-110B представлены ниже. Должно быть оценено, что хотя на Фиг.1 были проиллюстрированы только два компьютера 104A-104B Web-серверов, одна внутренняя система 112 и один клиентский компьютер 102, может присутствовать любое количество этих вычислительных устройств.
Теперь с обращением к Фиг.2 будет описана схема архитектуры программного обеспечения, показывающая аспекты иллюстративной архитектуры 200 программного обеспечения для учрежденческой поисковой системы, которая включает в состав API-преобразователь 110. В частности, как показано на Фиг.2, API-преобразователь 110 предоставляет нормализованный API для извлечения прав доступа относительно документа. Нормализованный интерфейс, представленный посредством нормализованного API, является согласованным интерфейсом, который различные приложения, исполняющиеся в рамках учрежденческой поисковой системы, могут использовать, чтобы получать права доступа относительно документа независимо от внутреннего хранилища контента, в котором документ постоянно находится. Например, поисковый агент 106 и процессор 120 запросов могут оба использовать метод, предоставляемый нормализованным API, чтобы получать права доступа относительно документов. Как будет описано более подробно в документе, методы, предоставляемые нормализованным API, принимают параметр, идентифицирующий документ, относительно которого запрашиваются права доступа, и могут необязательно принимать идентификатор пользователя для целей аутентификации.
В одном исполнении нормализованный API, предоставляемый API-преобразователем 110, включает в состав метод CHECKACCESS (проверка доступа), посредством которого могут быть извлечены права доступа относительно группы документов для отдельного пользователя. В одном исполнении метод CHECKACCESS в качестве параметра принимает массив идентификаторов документов и возвращает «длинное» значение, которое указывает, имеет ли текущий пользователь доступ для каждого из упомянутых документов. Метод CHECKACCESS обычно используется процессором 120 запросов, чтобы определить, имеет ли текущий пользователь права доступа для просмотра совокупности результатов поиска.
Нормализованный API, предоставляемый API-преобразователем 110, может также включать в состав метод PERMITTEDUSERS (разрешенные пользователи), посредством которого могут быть извлечены права доступа для всех пользователей относительно совокупности документов. Этот способ принимает массив идентификаторов документов в качестве входного параметра и возвращает строку, указывающую права доступа всех пользователей для каждого документа, идентифицированного в массиве. Метод PERMITTEDUSERS обычно используется поисковым агентом 106 для извлечения прав доступа для всех пользователей для просмотра документов, извлеченных в течение следования ссылкам. Как будет описано более подробно ниже, API-преобразователь 110 действует, чтобы динамически преобразовать вызовы нормализованных API в вызовы, совместимые со специальным API, предоставляемым внутренними системами 112A-112B.
Как упомянуто выше, внутренние системы 112A-112B могут предоставлять специальные API для извлечения данных прав доступа относительно документов, хранимых в хранилищах 114A-114B контента. Например, в одном исполнении система, которая использует программное обеспечение компании SAP AG, может предоставлять метод GETDISPLAYABLECUSTOMERS (получить отображаемых заказчиков), предназначенный для извлечения прав доступа пользователя относительно одного или нескольких «заказчиков». Этот метод принимает в качестве входных параметров идентификационные данные конечного пользователя и номер заказчика и возвращает булево значение, указывающее, имеет ли конечный пользователь права, чтобы просматривать «заказчика». Система SAP может также предоставлять метод GETAUTHORIZEDUSERSFORCUSTOMER (получить авторизованных пользователей для заказчика), посредством которого могут быть извлечены все права доступа по отношению к конкретному заказчику. Этот метод принимает в качестве входных параметров номер заказчика и возвращает перечень строк, указывающих права доступа для обозначенного заказчика.
В одном варианте осуществления, если API-преобразователь 110 принимает вызов метода CHECKACCESS, он динамически преобразует вызов в вызов, совместимый с методом GETDISPLAYABLECUSTOMERS. Например, если принятым вызовом является PERMITTEDUSERS (BDC://HOST/123/456?ID=34) (где внутренняя система 112A идентифицирована посредством номера 123), API-преобразователь 110 динамически преобразует этот вызов в GETDISPLAYABLECUSTOMERS(34). Затем вызов исполняется во внутренней системе 112A. API-преобразователь 110 будет формировать многократные вызовы метода GETDISPLAYABLECUSTOMERS, поскольку этот API выдает результаты для одного документа заказчика, тогда как метод CHECKACCESS проверку авторизации обычно запрашивает в виде пакетов. API-преобразователь 110 также преобразует данные неявной идентификации конечного пользователя, содержащиеся в потоке операционной системы, в строковое значение идентификационных данных, которое использует внутренняя система.
Если API-преобразователь 110 принимает вызов метода CHECKACCESS, такой как CHECKACCESS(BDC://HOST/333/456?ID=36) (где внутренняя система 112B идентифицирована номером 333), API-преобразователь 110 этот вызов динамически преобразует в вызов в форме GETAUTHORIZEDUSERSFORCUSTOMER(36), направленный внутренней системе 112B. Должно быть оценено, что эти API внутренней части являются лишь иллюстративными и что представленные в документе варианты осуществления могут использоваться вместе с любым специальным API для извлечения прав доступа относительно документа.
Для того чтобы выполнять такую обработку, API-преобразователь 110 использует метаданные, хранимые в хранилище метаданных 202, чтобы преобразовывать вызов нормализованного API в вызов специального API, предоставляемого внутренними системами 112A-112B. Хранилище метаданных 202 используется, чтобы хранить данные, которые описывают фактический API, предоставляемый внутренними системами 112A-112B, и тип соединений, необходимый для связи с каждой из внутренних систем 112A-112B. Например, в одном исполнении, пользователь, знакомый с внутренней системой 112A, может создать описание фактического API, предоставляемого системой, и информацию соединения в виде файла на расширяемом языке разметки гипертекста (XML). XML-файл загружается в учрежденческую поисковую систему и сохраняется в хранилище метаданных 202. Как только XML-файл был загружен, соединение с интерфейсами API прав доступа, обеспечиваемыми внутренней системой 112A, непосредственно доступно для использования. Посредством представления возможности пользователю декларативно определять интерфейс для извлечения прав доступа из внутренней системы, и посредством обработки метаданных описанным в документе образом не требуется программирование для осуществления интерфейса с новым типом внутренней системы хранения контента.
В одном варианте осуществления данные, хранимые в хранилище метаданных 202, для каждой внутренней системы 112 включают в состав данные, идентифицирующие каждый из параметров в API, предоставляемом внутренней системой. Например, параметры могут быть определены посредством использования сложных типов, представляющих параметры конкретного API, определяемых в виде агрегаций элементарных типов, таких как строки или целые. Совокупности могут определяться в виде групп сложных типов. Данные, хранимые в хранилище метаданных 202, могут также включать данные, указывающие, является ли каждый параметр входным параметром или выходным параметром и заданные по умолчанию значения для некоторых или всех параметров.
Согласно вариантам осуществления данные, хранимые в хранилище метаданных 202 для каждой внутренней системы 112, могут также включать описание каждого типа данных, обеспечиваемого внутренней системой 112, и какие поля уникально идентифицируют экземпляр данных этого типа. Например, могут храниться данные, указывающие, что типом данных является «заказчик» во внутренней системе SIEBEL или «заказ» в системе SAP. Взаимосвязи, называемые тегами, также могут храниться в хранилище метаданных 202 для базовых типов специального API и параметров в API, соответствующих экземпляру типа данных. Например, параметр, который используется для уникальной идентификации документа в API, может быть помечен в качестве такового. Когда поисковый агент 106 или процессор 120 запросов предоставляет идентификатор документа, относительно которого запрашиваются права доступа, API-преобразователь 110 может вставить идентификатор документа в надлежащее положение в вызове API, обеспечиваемом внутренней системой 112. Дополнительные подробности относительно этого процесса представлены ниже.
Согласно вариантам осуществления параметры внутреннего API, которые соответствуют поставляемым системой значениям, могут быть помечены тегом в качестве таковых в хранилище метаданных 202. Например, согласно одному варианту осуществления поставляемым системой значением является параметр, идентифицирующий текущего пользователя. Таким образом, процессор 120 запросов может поставлять идентификационные данные текущего пользователя на API-преобразователь 110. API-преобразователь 110 затем может выполнить подстановку идентификационных данных текущего пользователя для соответствующего параметра в вызове внутренней системы 112. Дополнительные подробности относительно этого процесса представлены ниже.
Согласно другим аспектам данные, хранимые в хранилище метаданных 202 для каждой внутренней системы 112, могут также включать информацию соединения, предназначенную для разработанной сторонними разработчиками системы хранилища данных, так что может выполняться соединение с системой для исполнения проверки доступа. Данные могут также включать в состав тип протокола, необходимый для исполнения внутреннего API. Например, в вариантах осуществления могут использоваться удаленный вызов процедуры (RPC) или Web-служба, чтобы исполнять вызов внутреннего API.
В одном варианте осуществления хранимые в хранилище метаданных 202 данные организованы в виде ряда таблиц данных. Например, одна таблица может использоваться для хранения данных, идентифицирующих различные внутренние системы, а другая таблица может использоваться для хранения информации, идентифицирующей тип данных, хранимых в каждом хранилище контента. Еще одна таблица может использоваться, чтобы хранить данные, идентифицирующие методы защиты, предоставляемые каждым хранилищем контента согласно типу данных. Например, доступ к «коммерческим заказам» во внутренней системе может использовать API, отличный от доступа к «заказчикам». Может также использоваться таблица для хранения данных, идентифицирующих каждый из параметров специального внутреннего API, и могут использоваться другие таблицы, чтобы хранить информацию, определяющую элементарные типы данных, используемые каждым параметром. Должно быть оценено, что хранилище метаданных 202 может быть организовано различными другими способами.
Как также проиллюстрировано на Фиг.2, API-преобразователь 110 использует один или несколько модулей обеспечения совместимости вызовов API (shim) 204A-204N, чтобы выполнять зависящие от протокола вызовы специальных API, предоставляемых внутренними системами 112A. Например, может обеспечиваться модуль 204A обеспечения совместимости Web-службы для вызовов Web-службы, может обеспечиваться модуль 204B обеспечения совместимости RPC для удаленного вызова процедур, и может обеспечиваться модуль 204C обеспечения совместимости баз данных для взаимодействия с базой данных. Может также использоваться другой модуль 204N обеспечения совместимости. Как кратко описано выше, в хранилище метаданных 202 могут храниться данные, определяющие конкретный модуль 204A-204N обеспечения совместимости для использования для каждой внутренней системы 112A или тип данных. Например, могут храниться данные, указывающие, что должен использоваться модуль 204A обеспечения совместимости Web-службы для некоторых типов документов, хранимых в хранилище 114A контента внутренней системы 112A. В хранилище метаданных 202 также могут храниться данные, указывающие, что модуль 204C обеспечения совместимости базы данных должен использоваться для извлечения прав доступа к документам, хранимым в хранилище 114B контента внутренней системы 112.
Далее со ссылкой на Фиг.3 приведены дополнительные подробности относительно представленных в документе вариантов осуществления интегрирования учрежденческих поисковых систем со специальными API управления доступом внутреннего хранилища контента. В частности, на Фиг.3 показана схема последовательности операций, иллюстрирующая действие учрежденческой поисковой системы, включающей в состав API-преобразователь 110 для получения прав доступа относительно документа, во время следования ссылкам. Должно быть оценено, что описанные в документе логические операции осуществляются (1) в виде последовательности реализуемых компьютером действий или программных модулей, исполняющихся на вычислительной системе и/или (2) в виде взаимосвязанных схем машинной логики или схемных модулей в рамках вычислительной системы. Реализация является вопросом выбора, зависящего от требований рабочей характеристики вычислительной системы. Соответственно, логические операции, описанные в документе, именуются различно как операции, структурные устройства, действия, или модули. Эти операции, структурные устройства, действия и модули могут быть реализованы в виде программного обеспечения, микропрограммного обеспечения, в виде специализированной цифровой логики и любой комбинации.
Программа 300 начинается с операции 302, где поисковый агент 106 запрашивает документ от одной из внутренних систем 112A-112B. Программа 300 затем переходит к операции 302, где поисковый агент 106 вызывает API-преобразователь 110 с унифицированным указателем ресурса (URL-адрес) для извлекаемого документа. Программа 300 затем переходит к операции 306, где API-преобразователь 110 из принятого URL извлекает для документа адрес внутренней системы, тип данных документа и идентификатор документа. Например, если принятым URL является bdc://hostname/123/456?id=34, адресом внутренней системы является 123, типом данных является 456 и идентификатором документа является 34. Затем могут осуществляться ссылки на данные в хранилище метаданных 202, чтобы определить, что внутренней системой является система SAP, типом данных является «заказчик» в SAP, и идентификатор документа относится к «заказчику» с номером заказчика 34.
Как только были извлечены адрес внутренней системы, тип данных и идентификатор документа, программа 300 переходит к операции 308. В операции 308 API-преобразователь 110 создает экземпляр вызова надлежащего метода внутренней системы. В одном варианте осуществления экземпляр вызова создается с использованием заданных по умолчанию значений для каждого из параметров, хранимых в хранилище метаданных 202. Программа 300 затем переходит к операции 310, где API-преобразователь 110 осуществляет подстановку идентификатора документа, принятого вместе с вызовом нормализованного API, для надлежащего параметра созданного экземпляра вызова API внутренней системы. API-преобразователь 110 использует данные, хранимые в хранилище метаданных 202, чтобы определить корректное положение для параметра идентификатора документа. В варианте осуществления идентификатор пользователя, принятый вместе с вызовом нормализованного API, также может вставляться в соответствующее положение в вызове API внутренней системы.
Как только создан экземпляр вызова специального API, обеспечиваемого внутренней системой, и все параметры установлены, программа 300 переходит к операции 312, где API-преобразователь 110 исполняет вызов надлежащей внутренней системы 112. Как описано выше, может использоваться надлежащий модуль 204A-204N обеспечения совместимости, чтобы фактически выполнить вызов удаленного метода. В ответ на исполнение метода внутренняя система возвращает запрошенные права доступа в операции 314.
API-преобразователь 110 затем поставляет возвращенные права доступа на поисковый агент 106 в ответ на первоначальный вызов нормализованного API, предоставляемого API-преобразователем 110. Это происходит в операции 316. В операции 318 поисковый агент 106 сохраняет возвращенные права доступа в поисковом индексе 108 или другом надлежащем хранилище данных. Процессор 120 запросов может использовать эту информацию, чтобы обработать результаты поиска во время запроса без необходимости взаимодействия с внутренней системой, которая поставила права доступа. От операции 318 программа 300 переходит к операции 320, где она завершается.
Далее со ссылкой на Фиг.4 описана иллюстративная программа 400, предназначенная для получения прав доступа относительно документа во время поиска в учрежденческой поисковой системе, которая включает в состав API-преобразователь 110. В частности, программа 400 начинается с операции 402, где клиентский компьютер 102 исполняет поисковый запрос в процессоре 120 запросов. В ответ на исполнение поискового запроса программа 400 переходит от операции 402 к операции 404, где процессор 120 запросов извлекает URL-адреса документов, совпадающие с заданными поисковыми терминами из поискового индекса 108. Процессор 120 запросов затем вызывает нормализованный API, предоставляемый API-преобразователем 110, с идентифицированными URL-адресами. Это происходит в операции 406.
От операции 406 программа 400 переходит к операции 408, где API-преобразователь 110 извлекает для документа из принятых URL-адресов адрес внутренней системы, тип данных для документа и идентификатор документа. Например, если принятым URL-адресом является bdc://hostname/123/456?id=34, адресом внутренней системы является 123, типом данных является 456 и идентификатором документа является 34. Затем могут осуществляться ссылки на данные в хранилище метаданных 202, чтобы определить, что внутренней системой является система SAP, типом данных является «заказчик» в SAP и идентификатор документа относится к «заказчику» с номером заказчика 34.
Как только были извлечены адрес внутренней системы, тип данных и идентификатор документа, программа 400 переходит к операции 410. В операции 410 API-преобразователь 110 создает экземпляр вызова надлежащего метода внутренней системы. В одном варианте осуществления экземпляр вызова создается с использованием заданных по умолчанию значений для каждого из параметров, хранимых в хранилище метаданных 202. Программа 400 затем переходит к операции 412, где API-преобразователь 110 вставляет идентификатор документа и идентификатор пользователя, принятый вместе с вызовом нормализованного API, в надлежащее положение в вызове API внутренней системы.
Как только был создан экземпляр вызова специального API, обеспечиваемого внутренней системой, и все параметры были установлены, программа 400 переходит к операции 414, где API-преобразователь 110 исполняет запрос надлежащей внутренней системы 112. Как описано выше, может использоваться надлежащий модуль 204A-204N обеспечения совместимости, чтобы выполнять вызов удаленного метода. В ответ на исполнение метода внутренняя система в операции 416 возвращает запрошенные права доступа. API-преобразователь 110 затем поставляет возвращенные права доступа на процессор 120 запросов в ответ на первоначальный вызов нормализованного API, предоставляемого API-преобразователем 110. В операции 418 процессор 120 запросов обрабатывает результаты поиска на основании возвращенных прав доступа. Например, не будут отображаться результаты, для которых текущий пользователь не имеет разрешения «на чтение», тогда как будут отображены результаты, для которых текущий пользователь имеет разрешение «на чтение». От операции 418 программа 400 переходит к операции 420, где она завершается.
Далее со ссылкой на Фиг.5 описана иллюстративная архитектура вычислительной системы для компьютера 500, используемая в различных вариантах осуществления, представленных в документе. Показанная на Фиг.5 архитектура вычислительной системы иллюстрирует традиционный, в настольном исполнении, портативный компьютер или внутренний компьютер. Показанная на Фиг.5 архитектура вычислительной системы включает в состав центральный процессор 502 (CPU), системную память 508, включающую в себя оперативное запоминающее устройство 514 (RAM), и постоянное запоминающее устройство (ROM) 516, и системную шину 504, которая соединяет память с CPU 502. Базовая система ввода-вывода, содержащая базовые подпрограммы, которые помогают передавать информацию между элементами внутри компьютера 500, например в течение запуска, хранится в ROM 516. Компьютер 500 дополнительно включает в состав запоминающее устройство 510, чтобы хранить операционную систему 518, прикладные программы и другие программные модули, которые будут описаны более подробно ниже.
Запоминающее устройство соединено с CPU 502 посредством контроллера запоминающего устройства (не показано), соединенного с шиной 504. Запоминающее устройство 510 и связанный с ним машиночитаемый носитель обеспечивают энергонезависимое запоминающее устройство для компьютера 500. Хотя содержащееся в документе описание машиночитаемого носителя относится к запоминающему устройству, такому как накопитель на жестком диске или ROM на компакт-диске (CD-ROM), специалистам в данной области техники должно быть понятно, что машиночитаемым носителем могут быть любые доступные носители, к которым может быть осуществлен доступ посредством компьютера 500.
В качестве примера, а не ограничения, машиночитаемый носитель может включать в себя энергозависимые и энергонезависимые, съемные и несъемные носители, реализованные любым способом или технологией для хранения информации, такой как машиночитаемые команды, структуры данных, программные модули или другие данные. Например, машиночитаемый носитель включает в себя, но без ограничения, RAM, ROM, стираемое программируемое ROM (EPROM), электрически стираемое программируемое ROM (EEPROM), флэш-память или другую технологию твердотельной памяти, ROM на компакт-диске (CD-ROM), цифровые многофункциональные диски (DVD), DVD высокой плотности записи (HD-DVD), диск по технологии BLU-RAY или другое оптическое запоминающее устройство, носители на магнитных кассета, магнитной ленте, магнитом диске, или другие магнитные запоминающие устройства, или любой другой носитель, который может использоваться для хранения требуемой информации и к которому можно осуществлять доступ компьютер 500.
В соответствии с различными вариантами осуществления изобретения компьютер 500 может работать в сетевой среде, используя логические соединения с удаленными компьютерами по сети 122, например Интернет. Компьютер 500 может соединяться с сетью через сетевой интерфейсный блок 506, соединенный с шиной 504. Должно быть оценено, что сетевой интерфейсный блок 506 также может использоваться для соединения с другими типами сетей и удаленными вычислительными системами. Компьютер 500 также может включать в себя контроллер 22 ввода/вывода для приема и обработки входных данных от ряда других устройств, включая клавиатуру, мышь, или электронное перо (не показано на Фиг.5). Подобным образом контроллер ввода/вывода может обеспечивать вывод на экран устройства отображения, принтер или другой тип устройства вывода (также не показано на Фиг.5).
Как кратко упомянуто выше, в запоминающем устройстве 510 и RAM 414 компьютера 500 может храниться ряд программных модулей и файлов данных, включая операционную систему 518, подходящую для управления функционированием сетевого настольного или внутреннего компьютера, такую как операционная система WINDOWS VISTA корпорации MICROSOFT (Редмонд, Вашингтон). Могут использоваться другие операционные системы, такие как операционная система LINUX или операционная система OSX корпорации APPLE COMPUTER, INC. Должно быть оценено, что, хотя представленные в документе варианты осуществления описаны в контексте настольного или портативного клиентского компьютера 102 и удаленного внутреннего компьютера 104, могут использоваться многие другие типы вычислительных устройств и систем для осуществления различных аспектов, представленных в документе.
Запоминающее устройство 510 и RAM 514 могут также хранить один или несколько программных модулей. В частности, запоминающее устройство 510 и RAM 514 могут хранить Web-браузер 116, приложение Web-сервера 118 и другие программные модули, описанные выше относительно Фиг.1 и 2. Другие программные модули также могут храниться в запоминающем устройстве 510 и использоваться компьютером 500.
На основании вышеизложенного должно быть оценено, что в документе представлены системы, способы и машиночитаемый носитель, предназначенные для интегрирования учрежденческих поисковых систем со специальными API управления доступом внутреннего хранилища контента. Хотя представленный в документе объект изобретения был описан на языке, конкретно определенном для структурных характеристик компьютера, методических действий и машиночитаемого носителя, должно быть понятно, что изобретение, определенное в прилагаемой формуле изобретения, не является обязательно ограниченным конкретными признаками, действиями или машиночитаемыми носителями, описанными в документе. Предпочтительнее, конкретные признаки, действия и носители являются раскрытыми в качестве примерных форм осуществления пунктов формулы изобретения.
Описанный выше объект изобретения представлен лишь в качестве иллюстрации и не должен толковаться ограничительно. Могут выполняться различные модификации и изменения по отношению к описанному в документе предмету изобретения, не следуя проиллюстрированным и описанным примерным вариантам осуществления и применения, без выхода за рамки объема и существа изобретения, изложенного в нижеследующей формуле изобретения.

Claims (20)

1. Способ интегрирования учрежденческой поисковой системы со специальным прикладным программным интерфейсом (API) управления доступом к документам, содержащий этапы, на которых:
сохраняют данные (202), описывающие специальный API, предназначенный для получения одного или более прав доступа относительно документа;
предоставляют нормализованный API для получения прав доступа относительно документа;
принимают (304) вызов предоставляемого нормализованным API метода, запрашивающего права доступа относительно указанного документа;
в ответ на прием вызова метода, предоставляемого нормализованным API, преобразуют (310) вызов метода, предоставляемого нормализованным API, в вызов метода, предоставляемого специальным API, для получения прав доступа относительно указанного документа;
принимают (314) права доступа в ответ на вызов метода, предоставляемого специальным API; и
возвращают (316) запрошенные права доступа в ответ на вызов метода, предоставляемого нормализованным API.
2. Способ по п.1, в котором данные, описывающие специальный API, содержат данные, идентифицирующие один или несколько параметров метода, предоставляемого специальным API, и данные, указывающие, является ли каждый из параметров входным параметром или выходным параметром.
3. Способ по п.2, в котором данные, описывающие специальный API, дополнительно содержат заданные по умолчанию значения параметров.
4. Способ по п.3, в котором данные, описывающие специальный API, дополнительно содержат данные, идентифицирующие один из параметров в качестве соответствующего идентификатору документа, относительно которого запрашиваются права доступа, при этом метод, предоставляемый нормализованным API, принимает параметр, идентифицирующий документ, относительно которого запрашиваются права доступа.
5. Способ по п.4, в котором этап преобразования вызова метода, предоставляемого нормализованным API, в вызов метода, предоставляемого специальным API, для запрашиваемых прав доступа относительно указанного документа содержит этапы, на которых:
создают экземпляр вызова метода, предоставляемого специальным API, с использованием заданных по умолчанию значений для параметров;
подставляют параметр, идентифицирующий документ, относительно которого запрашиваются права доступа, принятого вместе с вызовом нормализованного API, вместо заданного по умолчанию значения параметра, соответствующего идентификатору документа, относительно которого запрашиваются права доступа; и
исполняют вызов метода, предоставляемого специальным API.
6. Способ по п.5, в котором данные, описывающие специальный API, дополнительно содержат данные, идентифицирующие один из параметров в качестве соответствующего поставляемому системой значению, и при этом метод, предоставляемый нормализованным API, принимает параметр, идентифицирующий текущего пользователя.
7. Способ по п.6, в котором этап преобразования вызова метода, предоставляемого нормализованным API, в вызов метода, предоставляемого специальным API, для прав доступа относительно указанного документа дополнительно содержит этап, на котором:
подставляют параметр, идентифицирующий текущего пользователя, вместо заданного по умолчанию значения параметра, соответствующего поставляемому системой значению.
8. Способ по п.3, в котором вызов метода, предоставляемого нормализованным API, формируется программой поискового агента.
9. Способ по п.3, в котором вызов метода, предоставляемого нормализованным API, формируется процессором поисковых запросов.
10. Машиночитаемый носитель с хранящимися на нем машиноисполнимыми командами, которые при исполнении компьютером побуждают компьютер
предоставлять нормализованный прикладной программный интерфейс (API) для получения одного или более прав доступа относительно документа;
принимать (302) вызов метода, предоставляемого нормализованным API для извлечения прав доступа относительно документа, причем вызов включает в себя идентификатор документа относительно документа и идентификатор пользователя;
создавать (310) вызов метода, предоставляемого специальным API для получения прав доступа относительно документа, в ответ на вызов метода, предоставляемого нормализованным API, причем запрос создается с использованием хранимых данных, описывающих один или несколько параметров метода, предоставляемого специальным API, идентификатора документа и идентификатора пользователя;
исполнять (312) вызов метода, предоставляемого специальным API;
принимать (316) права доступа относительно документа в ответ на вызов метода, предоставляемого специальным API; и
возвращать (318) права доступа относительно документа в ответ на вызов метода, предоставляемого нормализованным API.
11. Машиночитаемый носитель по п.10, в котором данные, описывающие один или несколько параметров метода, предоставляемого специальным API, дополнительно содержат заданные по умолчанию значения для одного или нескольких параметров.
12. Машиночитаемый носитель по п.11, в котором данные, описывающие один или несколько параметров метода, предоставляемого специальным API, дополнительно содержат данные, идентифицирующие один из параметров в качестве соответствующего идентификатору документа и один из параметров в качестве соответствующего идентификатору пользователя.
13. Машиночитаемый носитель по п.12, в котором метод, предоставляемый нормализованным API, содержит метод для извлечения прав доступа для множества документов, при этом метод, предоставляемый специальным API, содержит метод для извлечения прав доступа относительно одиночного документа, при этом машиночитаемый носитель содержит хранимые на нем дополнительные машиноисполнимые команды, предназначенные для создания отдельного вызова метода, предоставляемого специальным API, для каждого из множества документов, идентифицированных в вызове метода, предоставляемого нормализованным API.
14. Машиночитаемый носитель по п.12, в котором вызов метода, предоставляемого нормализованным API, принимают из программы поискового агента.
15. Машиночитаемый носитель по п.12, в котором вызов метода, предоставляемого нормализованным API, принимают от процессора поисковых запросов.
16. Способ интегрирования учрежденческой поисковой системы со специальным прикладным программным интерфейсом (API) управления доступом к документам, содержащий этапы, на которых:
сохраняют данные (202), которые описывают один или несколько методов, предоставляемых специальным API управления доступом к документам, причем данные содержат заданные по умолчанию значения для одного или нескольких используемых методами параметров, данные, идентифицирующие параметры, которые соответствуют идентификатору документа, и данные, идентифицирующие параметры, которые соответствуют идентификатору пользователя;
предоставляют нормализованный API для получения одного или более прав доступа относительно документа, причем права доступа сохранены во внутренней вычислительной системе (112) и доступны с использованием одного из методов, предоставляемых специальным API управления доступом к документам;
принимают (302) вызов метода, предоставляемого нормализованным API, причем вызов включает в себя идентификатор документа, соответствующий документу, для которого нужно получать права доступа, и идентификатор пользователя для текущего пользователя;
в ответ на вызов метода, предоставляемого нормализованным API, преобразуют (310) вызов метода, предоставляемого нормализованным API, в вызов метода, предоставляемого специальным API управления доступом к документу с использованием заданных по умолчанию значений, идентификатора документа и идентификатора пользователя;
в ответ на вызов метода, предоставляемого специальным API управления доступом к документу, принимают (316) один или более прав доступа относительно документа; и
возвращают (318) права доступа относительно документа в ответ на вызов метода, предоставляемого нормализованным API.
17. Способ по п.16, в котором вызов метода, предоставляемого нормализованным API, формируется посредством программы поискового агента.
18. Способ по п.17, в котором метод, предоставляемый нормализованным API, действует для извлечения прав доступа для одного или нескольких пользователей относительно одиночного документа.
19. Способ по п.16, в котором вызов метода, предоставляемого нормализованным API, формируется посредством процессора поисковых запросов.
20. Способ по п.18, в котором метод, предоставляемый нормализованным API, действует для извлечения прав доступа к одному или нескольким документам для текущего пользователя процессора поисковых запросов.
RU2009126367/08A 2007-01-10 2008-01-09 Интегрирование учрежденческих поисковых систем со специальными интерфейсами прикладного программирования управления доступом RU2446456C2 (ru)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/651,657 US8341651B2 (en) 2007-01-10 2007-01-10 Integrating enterprise search systems with custom access control application programming interfaces
US11/651,657 2007-01-10

Publications (2)

Publication Number Publication Date
RU2009126367A RU2009126367A (ru) 2011-01-20
RU2446456C2 true RU2446456C2 (ru) 2012-03-27

Family

ID=39595143

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2009126367/08A RU2446456C2 (ru) 2007-01-10 2008-01-09 Интегрирование учрежденческих поисковых систем со специальными интерфейсами прикладного программирования управления доступом

Country Status (7)

Country Link
US (1) US8341651B2 (ru)
EP (1) EP2118786B1 (ru)
JP (1) JP2010518467A (ru)
KR (1) KR101458234B1 (ru)
CN (1) CN101583952B (ru)
RU (1) RU2446456C2 (ru)
WO (1) WO2008086380A1 (ru)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2602972C2 (ru) * 2015-03-12 2016-11-20 Публичное акционерное общество "Татнефть" им. В.Д. Шашина(ПАО "Татнефть" им. В.Д. Шашина) Система для управления интеллектуальными ресурсами предприятия
RU2666460C2 (ru) * 2013-04-30 2018-09-07 МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи Поддержка тегированных результатов поиска

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7941419B2 (en) * 2006-03-01 2011-05-10 Oracle International Corporation Suggested content with attribute parameterization
US8332430B2 (en) * 2006-03-01 2012-12-11 Oracle International Corporation Secure search performance improvement
US8027982B2 (en) * 2006-03-01 2011-09-27 Oracle International Corporation Self-service sources for secure search
US8214394B2 (en) * 2006-03-01 2012-07-03 Oracle International Corporation Propagating user identities in a secure federated search system
US9177124B2 (en) * 2006-03-01 2015-11-03 Oracle International Corporation Flexible authentication framework
US8868540B2 (en) 2006-03-01 2014-10-21 Oracle International Corporation Method for suggesting web links and alternate terms for matching search queries
US8433712B2 (en) * 2006-03-01 2013-04-30 Oracle International Corporation Link analysis for enterprise environment
US8005816B2 (en) * 2006-03-01 2011-08-23 Oracle International Corporation Auto generation of suggested links in a search system
US8707451B2 (en) 2006-03-01 2014-04-22 Oracle International Corporation Search hit URL modification for secure application integration
US8875249B2 (en) 2006-03-01 2014-10-28 Oracle International Corporation Minimum lifespan credentials for crawling data repositories
US7996392B2 (en) 2007-06-27 2011-08-09 Oracle International Corporation Changing ranking algorithms based on customer settings
US8316007B2 (en) * 2007-06-28 2012-11-20 Oracle International Corporation Automatically finding acronyms and synonyms in a corpus
US9489177B2 (en) * 2008-02-25 2016-11-08 Adventive, Inc. Methods for integrating and managing one or more features in an application and systems thereof
US20100005085A1 (en) * 2008-07-03 2010-01-07 Oracle International Corporation Creating relationship maps from enterprise application system data
US9639609B2 (en) 2009-02-24 2017-05-02 Microsoft Technology Licensing, Llc Enterprise search method and system
US20110106853A1 (en) * 2009-10-30 2011-05-05 Microsoft Corporation Declarative model security pattern
US20110137884A1 (en) * 2009-12-09 2011-06-09 Anantharajan Sathyakhala Techniques for automatically integrating search features within an application
US8527556B2 (en) * 2010-09-27 2013-09-03 Business Objects Software Limited Systems and methods to update a content store associated with a search index
CN102075560A (zh) * 2010-11-19 2011-05-25 福建富士通信息软件有限公司 一种基于系统耦合的福富企业搜索引擎技术
US9043358B2 (en) 2011-03-09 2015-05-26 Microsoft Technology Licensing, Llc Enterprise search over private and public data
US9244984B2 (en) 2011-03-31 2016-01-26 Microsoft Technology Licensing, Llc Location based conversational understanding
US9858343B2 (en) 2011-03-31 2018-01-02 Microsoft Technology Licensing Llc Personalization of queries, conversations, and searches
US9298287B2 (en) 2011-03-31 2016-03-29 Microsoft Technology Licensing, Llc Combined activation for natural user interface systems
US9760566B2 (en) 2011-03-31 2017-09-12 Microsoft Technology Licensing, Llc Augmented conversational understanding agent to identify conversation context between two humans and taking an agent action thereof
US9842168B2 (en) 2011-03-31 2017-12-12 Microsoft Technology Licensing, Llc Task driven user intents
US10642934B2 (en) * 2011-03-31 2020-05-05 Microsoft Technology Licensing, Llc Augmented conversational understanding architecture
US20120278318A1 (en) * 2011-05-01 2012-11-01 Reznik Alan M Systems and methods for facilitating enhancements to electronic group searches
US11841912B2 (en) 2011-05-01 2023-12-12 Twittle Search Limited Liability Company System for applying natural language processing and inputs of a group of users to infer commonly desired search results
US9454962B2 (en) 2011-05-12 2016-09-27 Microsoft Technology Licensing, Llc Sentence simplification for spoken language understanding
US9064006B2 (en) 2012-08-23 2015-06-23 Microsoft Technology Licensing, Llc Translating natural language utterances to keyword search queries
WO2013144937A1 (en) * 2012-03-27 2013-10-03 VARONIS SYSTEMS, INC. 1250 Broadway street 31st Floor New York, New York 10001 A method and apparatus for enterprise-level filtered search
CN106611118B (zh) * 2015-10-27 2020-05-12 北京国双科技有限公司 申请登录凭证的方法和装置
CN105653363B (zh) * 2015-12-28 2018-10-26 北京致远互联软件股份有限公司 一种接口功能实现方法及装置
US10176232B2 (en) 2016-03-01 2019-01-08 Microsoft Technology Licensing, Llc Blending enterprise content and web results
US10397189B1 (en) 2016-09-27 2019-08-27 Amazon Technologies, Inc. Peered virtual private network endpoint nodes
EP3388954A1 (de) * 2017-04-12 2018-10-17 Siemens Aktiengesellschaft Verfahren zum betrieb eines datenspeichersystems, computerprogramm zur implementierung des verfahrens sowie nach dem verfahren arbeitendes datenspeichersystem
KR102258241B1 (ko) * 2019-11-18 2021-06-01 주식회사 오픈드래프트 개발과 유지보수를 지원하기 위한 서버 사이드 데이터 컴포넌트 및 데이터 컴포넌트의 실행 방법
KR102549006B1 (ko) * 2020-12-11 2023-06-27 주식회사 포인트테크놀러지스 사용자 행동 기반 질의 벡터 자동 보정을 활용한 기업 검색 시스템 및 그 방법
US11790104B2 (en) 2021-02-18 2023-10-17 Glean Technologies, Inc. Permissions-aware search with document verification
US11593409B2 (en) 2021-02-19 2023-02-28 Glean Technologies, Inc. Permissions-aware search with intelligent activity tracking and scoring across group hierarchies
US11995135B2 (en) 2021-02-18 2024-05-28 Glean Technologies, Inc. Permissions-aware search with user suggested results
CA3223309A1 (en) * 2021-06-18 2022-12-22 James Douglas Beecham Security driver external functions
US11797612B2 (en) 2021-09-29 2023-10-24 Glean Technologies, Inc. Identification of permissions-aware enterprise-specific term substitutions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5675782A (en) * 1995-06-06 1997-10-07 Microsoft Corporation Controlling access to objects on multiple operating systems
RU2237275C2 (ru) * 1999-02-18 2004-09-27 Ситрикс Системз, Инк. Сервер и способ (варианты) определения программного окружения клиентского узла в сети с архитектурой клиент/сервер
RU2257687C2 (ru) * 1998-09-25 2005-07-27 КАНАЛЬ+ Сосьетэ Аноним Таблица данных о приложениях для системы цифровой передачи, предоставляющей множество сервисов
RU2259020C2 (ru) * 1998-03-06 2005-08-20 КАНАЛЬ+ Сосьетэ Аноним Мультимедийный терминал для множества пользователей

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5761669A (en) * 1995-06-06 1998-06-02 Microsoft Corporation Controlling access to objects on multiple operating systems
US5903720A (en) * 1996-12-13 1999-05-11 Novell, Inc. Object system capable of using different object authorization systems
US7031954B1 (en) * 1997-09-10 2006-04-18 Google, Inc. Document retrieval system with access control
US6182142B1 (en) * 1998-07-10 2001-01-30 Encommerce, Inc. Distributed access management of information resources
US6928469B1 (en) 1998-12-29 2005-08-09 Citrix Systems, Inc. Apparatus and method for determining a program neighborhood for a client node in a client-server network using markup language techniques
US6643690B2 (en) 1998-12-29 2003-11-04 Citrix Systems, Inc. Apparatus and method for determining a program neighborhood for a client node in a client-server network
US6381602B1 (en) * 1999-01-26 2002-04-30 Microsoft Corporation Enforcing access control on resources at a location other than the source location
US6934859B2 (en) * 2000-06-09 2005-08-23 Northrop Grumman Corporation Authenticated search engines
US7426730B2 (en) * 2001-04-19 2008-09-16 Wre-Hol Llc Method and system for generalized and adaptive transaction processing between uniform information services and applications
EP1399846B1 (en) * 2001-06-26 2013-02-13 Sealedmedia Limited Search engine and digital rights management
US7146637B2 (en) * 2001-06-29 2006-12-05 International Business Machines Corporation User registry adapter framework
US20030135582A1 (en) * 2001-12-21 2003-07-17 Docomo Communications Laboratories Usa, Inc. Context aware search service
US6944613B2 (en) * 2002-12-13 2005-09-13 Sciquest, Inc. Method and system for creating a database and searching the database for allowing multiple customized views
US20050262190A1 (en) * 2003-08-27 2005-11-24 Ascential Software Corporation Client side interface for real time data integration jobs
US20050262189A1 (en) * 2003-08-27 2005-11-24 Ascential Software Corporation Server-side application programming interface for a real time data integration service
US20050060286A1 (en) * 2003-09-15 2005-03-17 Microsoft Corporation Free text search within a relational database
US7716324B2 (en) * 2004-05-12 2010-05-11 Baytsp.Com, Inc. Identification and tracking of digital content distributors on wide area networks
US20060036748A1 (en) * 2004-07-28 2006-02-16 Nusbaum Edward S Apparatus and method for computerized information management
US20060080316A1 (en) * 2004-10-08 2006-04-13 Meridio Ltd Multiple indexing of an electronic document to selectively permit access to the content and metadata thereof
US20060155581A1 (en) * 2005-01-10 2006-07-13 George Eisenberger Systems with user selectable data attributes for automated electronic search, identification and publication of relevant data from electronic data records at multiple data sources
US7549144B2 (en) * 2005-02-22 2009-06-16 Microsoft Corporation Custom API modeling for source code static analysis simulator
CN100336339C (zh) * 2005-09-02 2007-09-05 清华大学 通用型协同交流系统中模型批注与操作传输的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5675782A (en) * 1995-06-06 1997-10-07 Microsoft Corporation Controlling access to objects on multiple operating systems
RU2259020C2 (ru) * 1998-03-06 2005-08-20 КАНАЛЬ+ Сосьетэ Аноним Мультимедийный терминал для множества пользователей
RU2257687C2 (ru) * 1998-09-25 2005-07-27 КАНАЛЬ+ Сосьетэ Аноним Таблица данных о приложениях для системы цифровой передачи, предоставляющей множество сервисов
RU2237275C2 (ru) * 1999-02-18 2004-09-27 Ситрикс Системз, Инк. Сервер и способ (варианты) определения программного окружения клиентского узла в сети с архитектурой клиент/сервер

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2666460C2 (ru) * 2013-04-30 2018-09-07 МАЙКРОСОФТ ТЕКНОЛОДЖИ ЛАЙСЕНСИНГ, ЭлЭлСи Поддержка тегированных результатов поиска
RU2602972C2 (ru) * 2015-03-12 2016-11-20 Публичное акционерное общество "Татнефть" им. В.Д. Шашина(ПАО "Татнефть" им. В.Д. Шашина) Система для управления интеллектуальными ресурсами предприятия

Also Published As

Publication number Publication date
KR20100014305A (ko) 2010-02-10
WO2008086380A1 (en) 2008-07-17
CN101583952A (zh) 2009-11-18
RU2009126367A (ru) 2011-01-20
EP2118786A1 (en) 2009-11-18
US8341651B2 (en) 2012-12-25
KR101458234B1 (ko) 2014-11-04
JP2010518467A (ja) 2010-05-27
US20080168037A1 (en) 2008-07-10
EP2118786A4 (en) 2011-06-22
CN101583952B (zh) 2011-10-05
EP2118786B1 (en) 2017-12-27

Similar Documents

Publication Publication Date Title
RU2446456C2 (ru) Интегрирование учрежденческих поисковых систем со специальными интерфейсами прикладного программирования управления доступом
US11341263B2 (en) Efficient data query and utilization through a semantic storage model
JP4726545B2 (ja) データソースを発見して接続するための方法、システムおよび装置
US9390179B2 (en) Federated search
US7299171B2 (en) Method and system for processing grammar-based legality expressions
US10152607B2 (en) Secure access to hierarchical documents in a sorted, distributed key/value data store
US8914323B1 (en) Policy-based data-centric access control in a sorted, distributed key-value data store
US8326848B2 (en) Proactive analytic data set reduction via parameter condition injection
US7979458B2 (en) Associating security trimmers with documents in an enterprise search system
US7792857B1 (en) Migration of content when accessed using federated search
US20240119048A1 (en) Real-time analytical queries of a document store
US7562286B2 (en) Apparatus, system, method and computer program product for document management
US11372859B2 (en) Efficiently supporting value style access of MOBs stored in SQL LOB column by providing value based semantics for LOBs in RDBMS
US10007667B2 (en) Systems and methods for document management for sharing documents according to document category
Chudnovskyy et al. Data portability using Webcomposition/Data grid service
Sacco et al. Privacy aware and faceted user-profile management using social data
Cerullo ISS Project: The Integrated Search System in the National Bibliographic Services
Van Twist Designing a Power Tool for Policy Analysts: Dynamic Actor Network Analysis
Kumar Documentum Content Management Foundations: EMC Proven Professional Certification Exam E20-120 Study Guide

Legal Events

Date Code Title Description
PC41 Official registration of the transfer of exclusive right

Effective date: 20150526

MM4A The patent is invalid due to non-payment of fees

Effective date: 20200110