Система и способ, относящиеся к доступу информации

Система и способ, относящиеся к доступу информации

Иллюстрации

Показать все

Реферат

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

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

УРОВЕНЬ ТЕХНИКИ

Не известно ни одной удовлетворительно функционирующей технологии для ситуации, когда сторона, запрашивающая информацию, запрашивает доступ к информации, находящейся на стороне, поставляющей информацию, или когда приложение запрашивает информацию у поставляющей стороны, в частности, для запросов к динамической информации. Все известные технологии сильно зависят от реализационных структур, таких как используемые таблицы, средства хранения информации, содержащиеся в, или ассоциативно связанные с приложением. SQL (язык структурированных запросов) - одна из таких технологий, которая является особенно подходящей, когда нужно отыскивать одну или более частей информации, которые соответствуют специальным, заданным критериям. SQL требует входных данных, которые являются очень точно определенными, имея в качестве предварительного условия хорошее знание структуры баз данных и реляций. Невозможно динамически, с использованием динамических входных параметров, получить адекватный динамический ответ, особенно, не обратно в соответствующее местоположение. Вообще, когда доступ к информации запрашивается через основанную на IP (Интернет-протоколах) сеть передачи данных, требуются несколько установлений TCP-соединений (протокола управления передачей). В частности, известные системы не могут быть легко адаптированы, чтобы также удовлетворять потребностям конечного пользователя защищать данные, содержащиеся в персональных профилях, расположенных по всей сети, в другом приложении или сайтах снабжения информацией. В общем, не существует удовлетворительного решения, особенно в среде с распределенными приложениями, для осуществления доступа к информации из средства хранения информации без приложения, обладающего знаниями о, и являющегося адаптированным к структуре и контенту конкретного средства хранения информации. Известно, что эту проблему следует решать посредством использования жестко закодированных связей между осуществляющей доступ системой и средством хранения информации. Однако с коммерческой точки зрения, решения с жестко закодированными связями являются невыгодными. Это сложно, или невозможно, вносить изменения без привлечения разработчика SW (программного обеспечения). Эта проблема особенно очевидна, когда информационная структура, например, в базе данных, часто изменяется, так как, в таком случае, разработка программного обеспечения должна будет стать обширной. Если компания, запускающая приложение, не является SW-компанией, будет дорого всегда иметь в штате программиста SW, или, в других показателях, предоставлять интегратору SW глобальную организацию поддержки. Это не является жизнеспособным с финансовой точки зрения. К тому же, проблемой, до настоящего времени решаемой через реализацию жестко закодированных связей, является то, что приложению может потребоваться быть настроенным по заказу на многочисленные разные структуры баз данных с разным контентом. В частности, проблемой является соединять или ассоциативно связывать ответ, выбранный, например, из базы данных, с «местоположением» в документе требования, или запросе. В общем смысле, вернуть ответ в документ просто, но до сих пор не существует решения того, как ассоциативно связать его с надлежащим «местоположением» соответствующего запроса. В частности, не существует решений для проблем, преданных рассмотрению выше, когда употреблено преимущество использования универсального языка разметки, например, XML (расширяемого языка разметки), в каковом случае, связи, например, между XML-деревом (запросом) узлов DOM (объектных моделей документов) и базой данных являются жестко закодированными SQL-операторами, каковое, как указанно ссылкой выше, является невыгодным.

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

РАСКРЫТИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

Фиг. 1 очень схематично иллюстрирует систему, запрашивающую информацию через приложение из средства хранения информации,

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

Фиг. 3 показывает другой вариант осуществления, в котором для запрашивания и поставки данных используется XML-форма и в котором информация соглашения сохраняется внешним образом,

Фиг. 4 показывает вариант осуществления, в котором проверка действительности выполняется посредством сети персональных профилей защиты,

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

Фиг. 6 - структурная схема, схематично иллюстрирующая идею изобретения, когда документ требования реализован в виде XML-дерева узлов DOM,

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

Фиг. 8 - иллюстрация процедуры для размещения информации в средстве хранения информации,

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

Фиг 10 - блок-схема алгоритма, иллюстрирующая одну из реализаций идеи изобретения.

ОСУЩЕСТВЛЕНИЕ ИЗОБРЕТЕНИЯ

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

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

DTD описывает модель структуры контента в XML-документе. Модель задает элементы, которые должны быть предоставлены, какие элементы являются необязательными, каковы их атрибуты и каким образом они могли бы быть структурированы по отношению друг к другу. В качестве сравнения, HTML (гипертекстовый язык разметки) имеет только один DTD; с использованием XML, становится возможным создавать частные DTD-определения для пользовательских приложений, которые предоставляют полный контроль над процессом управления контентом и структурой XML-документа, созданного для приложения. DTD ассоциативно связывается с XML-документом посредством объявления типа документа. Объявление типа документа, DTD, здесь является XML-описанием модели контента типов (или классов) документов. Объявлением типа документа является представление в XML-файле, чтобы разъяснять, что некое DTD принадлежит документу.

В частности, форма содержит XML-дерево (узлов) с запросами, например, в виде атрибутов, которым могут быть заданы значения при заполнении формы. В конкретной реализации атрибуты содержат одно или более из «от», «получить», «обнулить», «ошибка», «установить», значение которых может быть понятно из прочтения.

В одной из реализаций помеченная XML-форма содержит XML-строку. В преимущественной реализации помеченная XML-форма содержит XML-объект (объект дерева узлов DOM). DOM является аббревиатурой от Document Object Model (объектная модель документа), как определено W3C, консорциумом World Wide Web. DOM является стандартизованным, основанным на древовидной схеме, интерфейсом прикладного программирования (API) для XML. Объектная форма требует в качестве предварительного условия обеспечение средством преобразования/синтаксического анализа в соответственных приложениях, то есть, в запрашивающем приложении и поставляющем информацию приложении, для преобразования XML-объектов в XML-строки с использованием таблицы стилей XSL- преобразований (XSLT), и чтобы синтаксически разбирать XML-строку в XML-объект. В конкретных реализациях серверные средства соответственно ассоциативно связаны с запрашивающими и поставляющими приложениями. XML-строка является «видимой» пользователю, то есть, она может быть прочитана, в отличие от XML-объекта, который является «невидимым», то есть, неудобочитаемым.

Согласно изобретению (поставляющее) приложение содержит средство для конвертирования принятого запроса XML-формы в вызов базы данных, например, SQL-формата, чтобы осуществлять выборку запрошенной информации, которая, когда извлечена, вносится/заполняется в форме для повторной передачи запрашивающему приложению (если это операция извлечения или «получения» (выемки)). Приложение, в частности, может функционировать как в качестве запрашивающего, так и поставляющего приложения. Однако, для пары приложений, соглашение также может быть основано на допущении, что одно из приложений всегда действует в качестве запросчика, а другое всегда выступает как поставщик, или держатель. Должно быть понятно, что изобретение не ограничивается SQL-реализацией, наоборот, может быть использован любой протокол доступа или язык для доступа к средству хранения информации, например LDAP (облегченный протокол доступа к каталогам) или любой другой подобный протокол.

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

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

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

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

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

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

В частности, приложение и его ассоциативно связанные средства доступа обмениваются данными через XML-объекты в транспортных XML-объектах, например, XML-дерева узлов в контейнере XML-деревьев узлов, например, с использованием RMI (удаленного вызова метода) или CORBA™ (общей архитектуры брокера запросов к объектам). Средство доступа, ассоциативно связанное с запрашивающим приложением, в частности, будет находить специфичное для пользователя DTD, то есть, персональный профиль защиты, в центральном защитном серверном средстве, используя информацию об общем соглашении (общее или основное DTD), предоставленную от запрашивающего приложения. Заполненная XML-форма подвергается проверке действительности по отношению к специфичному для пользователя DTD.

Фиг. 1 только схематичным образом показывает (внешнюю) систему, или узел 1, поддерживающую XML, и предоставляющую требование приложению 2 в распределенной среде, которая содержит средство 3 преобразования, например, компонент, для преобразования требования, например, в SQL-требование, к примеру, вызов BD (базы данных) (или в более общем смысле, требование доступа для доступа к средству хранения информации), извлекает информацию и возвращает ее в соответствующее местоположение/узел в (XML-) требовании (например, XML-дереве узлов DOM), как будет дополнительно разъяснено особо, со ссылкой на фиг. 6-8.

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

Фиг. 2 очень схематично иллюстрирует два обменивающиеся данными приложения, здесь обозначены запрашивающее информацию приложение А 10 и поставляющее информацию приложение В 20. Каждое приложение 10, 20 может содержать или обмениваться данными с держателями соглашения (не показаны) касательно хранящейся информации о соглашениях, установленных между соответственными приложениями. Таким образом, может быть сделано предположение, что соглашение между двумя приложениями, в данном случае - приложениями А и В, сохраняется в обоих соответственных приложениях. Держатель соглашения приложения, если реализован, может содержать большое количество разных соглашений, например, одно для каждого другого приложения, с которым участвующее приложение заключило соглашение, и определяющих, какова информация или каков тип информации, которой дозволено обмениваться внутри соответственной пары приложений. На чертеже проиллюстрировано, что каждое соответственное приложение содержит обработчик XML-требования, который фактически содержит программное обеспечение (то есть, не обязательно специальное средство) для создания XML-формы, которая должна быть заполнена, когда отправляется запрос. В этом первом варианте осуществления предполагается, что приложение A 10 запрашивает информацию у приложения B 20.

Должно быть понятно, что идея изобретения не ограничена XML-«формами», и оно, к тому же, не обязательно должно быть запрашивающим или поставляющим приложением, главная концепция, имеет дело с процедурой между (в данном случае) приложением B, то есть, любым распределенным приложением, и средством хранения информации ((DB), база 23 данных).

Соглашение, установленное между приложениями A и B, которое доступно в держателе информации о соглашении (не показан), в частности, в виде DTD-соглашения (определения типа документа), используется XML-формой, управляющей функциональными возможностями, чтобы создавать XML-форму, например, в виде XML-дерева узлов DOM, с запросами в виде атрибутов, которым должны быть заданы значения в соответствии с отдельным требованием. Таким образом, после того как XML-форма была создана, атрибутам придаются значения, и XML-форма, помеченная информацией (в атрибутах и данных элементов), относящейся к запрошенной информации, передается в приложение B 20 через IP-сеть, например, с использованием HTTP(S(защищенного)) (протокола передачи гипертекстовых файлов), в виде транспортного XML-файла, например, в виде XML-строки.

В предпочтительной реализации XML-дерево узлов содержит XML-дерево узлов DOM. В качестве альтернативы, XML-дерево реализуется в виде XML-строки. Если XML-форма строится как объект, преобразование в транспортную XML-строку требуется в целях транспортировки. XML-форма, принятая в приложении B 20, будет преобразована в вызов базы данных, в данном случае, конкретно, в средстве преобразования. В частности, она преобразуется в SQL-требование, чтобы осуществлять доступ/выборку данных, как указано запросом, из базы 23 данных, хранящей запрошенную информацию. Когда запрошенная информация извлечена из базы 23 данных, форма заполняется, в частности, посредством задания атрибутам и данным элементов надлежащих значений, то есть, согласно изобретению тех, которые извлечены из базы 23 данных. Если вместо этого требование касается установки данных, доступ к «запрошенным» данным осуществляется посредством, например, SQL, а данные устанавливаются в соответствии с атрибутами.

Завершенная XML-форма затем возвращается в приложение А 10, и форма, которая заполнена, может быть представлена пользователю. Фиг. 2 является лишь схематичной иллюстрацией функционирования, при котором задается XML-форма, каковая содержит атрибуты, которым должны быть заданы значения, как для того чтобы определить, какая информация запрашивается (в целях установки или получения), так и для того, чтобы содержать запрошенную информацию (если значима), когда возвращается в запрашивающее приложение. Если XML-форма реализована в виде строки, не требуется никаких средств преобразования/синтаксического анализа, за исключением преобразования (конвертирования) в вызов базы данных (SQL-требование). Однако, если XML-форма представлена в виде XML-дерева узлов DOM, средства преобразования требуются в целях транспортировки между приложениями (и средства синтаксического анализа для преобразования формы в виде строки в дерево узлов DOM). Это изобретение, в частности, касается преобразования в SQL-требование и возвращения ответа в соответствующее местоположение в документе запроса, например, узел XML-дерева узлов.

Фиг. 3 схематично иллюстрирует несколько иную реализацию, в которой запрашивающее приложение 10₀ запрашивает информацию из поставляющего приложения 20₀, между каковыми приложениями 10₀, 20₀ было установлено соглашение. Здесь предполагается, что информация о соглашении сохраняется во внешнем держателе 30C соглашения, поддерживающем связь как с запрашивающим приложением 10₀, так и поставляющим приложением 20₀. Обмен данными между держателем 30С соглашения и поставляющим приложением 20₀ здесь указан посредством пунктирной линии, поскольку, когда запрашивающее приложение 10₀ запрашивает информацию у поставляющего приложения 20₀ (или намеревается осуществить доступ к данным на поставляющей/хранящей стороне), поставляющему приложению 20₀ не требуется осуществлять выборку соглашения (по меньшей мере тогда, когда не требуется никакой проверки действительности, но, к тому же, в таком случае, это не является абсолютно необходимым согласно преимущественным реализациям). Здесь предполагается, что соглашения были созданы в виде определений типов документов DTD. Предполагается, что соглашение между запрашивающим приложением l0₀ и предоставляющим приложением 20₀ здесь обозначено DTD₁. Когда приложение 10₀ намеревается получить информацию от приложения 20₀, осуществляется выборка DTD₁, и объект XML-дерева узлов DOM (или XML-строка) создается в обработчике XML-формы в запрашивающем приложении 10_0. Атрибутам в XML-дереве узлов задаются значения (назначенные), относящиеся к запрошенным данным. Примерами по атрибутам являются «от», «получить», «установить», «обнулить», «ошибка».

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

XML-форма, если она имеет вид строки, как только атрибутам были заданы надлежащие значения, передается поставляющему приложению 20₀ в виде XML-строки, необязательно включающей в себя DTD₁. В поставляющем приложении 20₀, в средстве преобразования, то есть, программном обеспечении, которое не обязательно должно быть предусмотрено в «средстве», выполняется преобразование в вызов базы данных, SQL-формата, каковой вызов переправляется в базу 23₀ данных. Запрошенные данные впоследствии возвращаются в поставляющее приложение и заполняются по XML-форме в качестве значений у имеющих отношение атрибутов и данных элементов. Форма возвращается запрашивающему приложению в виде XML-строки (необязательно с содержащимся DTD; DTD₁ - в этом конкретном случае). В одной из преимущественных реализаций XML-форма дерева реализуется в качестве объекта XML-дерева узлов DOM. Объект должен быть конвертирован в строку для транспортировки от запрашивающего приложения А 10₀ поставляющему приложению В 20₀. XML-строка синтаксически разбирается на поставляющей стороне посредством синтаксического анализатора DOM, чтобы быть в виде объекта. Однако, для повторной передачи в запрашивающее приложение, XML-дерево узлов DOM должно быть преобразовано в XML-строку узла.

Фиг.4 показывает отдельную реализацию, в том числе процедуру проверки действительности. Со ссылкой на фиг.3, предполагается, что запрашивающее информацию приложение 10₁ намеревается извлечь (получить) информацию из поставляющего информацию приложения 20₁, не зная, где найти саму информацию. В этой реализации предполагается, что обмен данными с центральным сервером 31₁ обеспечивается средством 11₁ доступа, взаимодействующим с запрашивающим приложением 10₁. Преимущество такой реализации состоит в том, что от сети секретности получают быстрый ответ, то есть, от центрального серверного средства 30₁, в отношении того, возможна ли запрошенная транзакция, даже без обязанности привлекать средство 21₁ доступа поставляющего информацию приложения 20₁ (или само поставляющее информацию приложение). Нагрузка, являющаяся следствием отклоненных транзакций по средству 21₁ доступа на поставляющей информацию стороне, будет значительно снижена, по сравнению со случаем, когда поставляющая сторона привлекается на ранней стадии.

Таким образом, когда запрашивающее информацию приложение 10₁ намеревается установить информацию в, или получить информацию от поставщика или держателя информации, запрашивающее приложение 10₁ создает XML-требование по отношению к «его» средству 11₁ доступа. Запрашивающее приложение не знает адреса поставщика информации. Дополнительно предполагается, что средство 11₁ доступа хранит открытый ключ и закрытый ключ. Закрытый ключ PKI (инфраструктуры закрытых ключей) узла может, например, быть сохранен как ключевой объект, например, защищенный объектный файл.

В конкретной реализации требование отправляется (I) через RMI, и оно предпочтительно содержит:

- идентичность (ID) пользователя, ассоциативно связанную с требованием и используемую запрашивающим приложением,

- ID DTD (эквивалент ID-службы),

- ID-транзакцию,

- ID запрашивающего приложения,

- ID межсетевого шлюза и

- Контейнер XML-дерева узлов.

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

Контейнер XML-дерева узлов является объектом для транспортировки XML-дерева узлов между запрашивающим приложением и его средством 11₁ доступа. I указывает требование от запрашивающего приложения 10₁ к средству 11₁ доступа. Средство 11₁ доступа находит общее DTD; то есть, DTD, еще не адаптированное к специальным предпочтениям конечного пользователя по передаче персональных данных, общий XSLT-файл, открытый ключ центрального серверного средства, DNS-имена (сервера доменных имен) и IP-адреса (один или более основанных на IP-номерах URL (унифицированных указателей ресурсов) из главного центрального серверного средства для ID DTD, в случае, когда есть более, чем одно центральное серверное средство - каждый, содержащий ID.

В одной из реализаций, отыскивать специальный ID центрального серверного средства может быть необязательным, если он задан в базе данных (DB-A 12) со специальным открытым ключом центрального серверного средства. Это может быть использовано, когда центральное серверное средство не является единственным в группе с одним и тем же открытым ключом, но, например, единственным, которое использует то же самое доменное имя. Значимая информация для ID центрального серверного средства, DTD-информация и т.д., выбирается посредством средства 11₁ доступа из ассоциативно связанной базы 12₁ данных.

Средство 11₁ доступа запрашивающего приложения 10₁ затем отправляет требование на II, центральному серверному средству 30₁, чтобы найти специфичное DTD для этой конкретной службы и ID конечного пользователя. Конкретно, используется HTTPS, а требование, в частности, содержит:

- идентичность средства 11₁ доступа запрашивающего приложения,

- цифровую подпись средства доступа запрашивающего приложения с его закрытым ключом,

- ID конечного пользователя, используемую запрашивающим приложением 10₁,

- ID DTD (эквивалент ID-службы),

- ID транзакции,

- ID межсетевого шлюза и

- ID запрашивающего приложения.

Затем средство 11₁ доступа ожидает и дожидается ответа от центрального серверного средства 30₁. Тем временем средство 11₁ доступа запрашивающего приложения может по желанию проверить действительность XML-дерева узлов с общим DTD относительно ID DTD (ID службы). Это составляет базовую проверку действительности, и она выполняется, когда DTD используется впервые, начиная с того момента времени, когда сервер находится в состоянии готовности к работе, для того чтобы ограничить нагрузку на средство 11₁ доступа запрашивающего приложения.

Центральный сервер 31₁, который содержит логику управления, проверяет аутентификацию требования, в том числе идентичность средства доступа, IP-адрес (не обязательно) и цифровую подпись относительно открытого ключа средства 11₁ доступа. Затем устанавливается соответствие ID пользователя и ID DTD запрашивающего приложения с ID пользователя поставляющего информацию приложения. Должно быть отмечено, что идентичность конечного пользователя, использованная запрашивающим приложением, может или обыкновенно отличается от идентичности конечного пользователя, используемой поставляющим информацию приложением. То есть, для одного и того же конечного пользователя приложения могут использовать разные ID.

ID пользователя поставляющего информацию приложения 20₁ зашифровывается с датой/временем, с использованием открытого ключа средства 21₁ доступа поставляющего информацию приложения, из условия, чтобы она могла быть прочитана и понята только средством 21₁ доступа поставляющего информацию приложения. Зашифрованный шаблон может быть разным каждый раз, когда средство 11₁ доступа запрашивающего приложения 10₁ создает требование. Центральный сервер 31₁ получает цифровую подпись для специфичного конечному пользователю DTD из базы данных, хранящей информацию 32₁ профиля защиты, подписанной закрытым ключом центрального сервера 31₁. Чтобы получить хорошую производительность, все DTD-определения могут быть подписаны заблаговременно. Элементы «внеполосной» информации также подписываются. (Под «внеполосной» информацией здесь подразумевается прослойка информационного обмена системного уровня, например, включающая в себя управляющую информацию для средства 11₁ доступа. Это может, например, быть реализовано в виде POST (процедуры начального самотестирования) HTTP в прямом направлении, и в виде куки-файла (строки с данными о пользователе, получаемой от веб-сервера) в обратном направлении).

Центральный сервер 31₁ затем возвращает сообщения, III, средству 11₁ доступа запрашивающего приложения, содержащие специфичное для конечного пользователя DTD в качестве внутриполосной информации. (Под «внутриполосной» здесь понимается информация в прикладной прослойке передачи данных, например, на уровне XML-документа). Центральный сервер 31₁ также возвращает «внеполосную» информацию такую, как:

- цифровая подпись специфичного конечному пользователю DTD,

- цифровая подпись «внеполосной» информации центрального серверного средства,

- идентификатор центрального серверного средства,

- зашифрованный ID конечного пользователя, то есть, ID конечного пользователя поставляющего информацию приложения,

- время жизни,

- время пассивности,

- время ответа,

- доменное имя средства 21₁ доступа поставляющего информацию приложения 20₁,

- его IP-адрес и

- открытые ключи соответственных средств 11₁, 21₁ доступа.

ID транзакции от запрашивающего приложения 10₁ (через его средство 11₁ доступа), ID пользователя запрашивающего приложения 10₁ и зашифрованный ID пользователя поставляющего информацию приложения, будут зарегистрированы в центральном серверном средстве 30₁.

В средстве 11₁ доступа запрашивающего приложения 10₁ аутентифицируется цифровая подпись центрального сервера 31₁ с его открытым ключом. Запрашивающее средство 11₁ доступа будет выполнять преобразования XML-дерева узлов в транспортный XML-файл (строку) с общим XSLT-файлом (XSLT-файлом для этого конкретного ID DTD) (XSL-преобразование; XSL, например, описывается в версии 1.0 XSL-преобразований (XSLT), отчет W3C, датированный 10 ноября 1999 года, и рабочим проектом W3C версии 1.1 XSL-преобразований (XSLT), 12 декабря 2000, каковые документы настоящим включены в материалы настоящей заявки посредством ссылки).

Средство 11₁ доступа запрашивающего приложения проверяет действительность транспортного XML-файла (строки) относительно принятого специфичного конечному пользователю DTD. Затем, XML-файл будет подписан. Если есть требование на нечто, посредством XML-атрибута, для которого доступ не разрешен, сообщение об ошибке будет возвращено запрашивающему приложению 10₁ одним из средств доступа 11₁; 21₁.

Однако, если проверка достоверности может быть завершена без ошибок, средство 11₁ доступа запрашивающего приложения отправляет средству 21₁ доступа поставляющего информацию приложения, IV:

- транспортный XML (строку) (в качестве внутриполосной информации) и внеполосную информацию, например, в виде куки-файла, то есть, цифровую подпись для транспортного XML-файла (строки) с закрытым ключом средства 11₁ доступа,

- цифровую подпись внеполосной информации (ID сервера) из центрального серверного средства 30₁,

- зашифрованную ID конечного пользователя (ID пользователя поставляющего информацию приложения),

- время жизни,

- время пассивности,

- время ответа,

- проверку действительности поставляющей информацию стороны,

- ID DTD и

- открытые ключи соответственных средств 11₁, 21₁ доступа.

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

Средство 11₁ доступа запрашивающего приложения в этот момент использует HTTPS для обмена данными со средством доступа поставляющей информацию ст