СИСТЕМА И СПОСОБ, ОТНОСЯЩИЕСЯ К ДОСТУПУ ИНФОРМАЦИИ Российский патент 2008 года по МПК G06F12/00 G06F17/30 

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

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

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

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

Если средство 11₁ доступа запрашивающего приложения не принимает никакого ответа от средства доступа 21₁ поставляющего информацию приложения в течение заранее установленного интервала времени, средство 11₁ доступа запрашивающего приложения разорвет TCP-соединение (TCP; протокол управления передачей). Это также будет освобождать данные сеанса после заранее установленного количества попыток получить ответ от одного и того же средства доступа на поставляющей информацию стороне. Возможно, это будет сделано после одной или более попыток по другим средствам доступа поставляющей информацию стороны, в случае, когда, например, существует кластер, многочисленные средства доступа или дублированное средство доступа, или подобное.

Когда средство 21₁ доступа поставляющего информацию приложения принимает требование, (IV), оно извлекает с использованием ID DTD:

- открытый ключ центрального сервера,

- ID центрального сервера и общего DTD и

- общий XSLT-файл для конкретной ID DTD из своей базы 22₁ данных.

Цифровая подпись с помощью средства 11₁ доступа запрашивающей стороны транспортного XML-файла верифицируется в отношении открытого ключа средства доступа запрашивающей стороны из внедиапазонной информации (ID DTD, ID центрального сервера и подпись центрального сервера 31₁ внедиапазонной информации в отношении базы 22₁ данных). Действительность XML-требования проверяется в отношении специфичного конечному пользователю DTD из центрального сервера 31₁. Если требование является недействительным, сообщение об ошибке возвращается средству 11₁ доступа. Если требование является действительным, ID пользователя поставляющей информацию стороны дешифруется. Если сеанс на поставляющей стороне по-прежнему активен, или продолжается, как задано внедиапазонной информацией, дешифрование ID пользователя поставляющей информацию стороны не требуется, поскольку сеанс до сих пор действует в дешифрованном виде. XML-файл затем синтаксически разбирается в XML-дерево узлов, в этот момент, поставляющее информацию приложение 20₁ активизируется посредством отправки контейнера XML-дерева узлов, выработанной ID транзакции, ID DTD через RMI. Действительность каждой новой ID DTD может быть проверена средством 21₁ доступа поставляющей информацию стороны в отношении общего DTD, каждый раз, когда сервер активируется. Это общее DTD представляет максимальное количество элементов данных, которые поставляющая информацию сторона готова выпустить - или содержать модифицированными, в случае «проталкивания» (оперативной доставки без запроса) установки.

Для конкретного сеанса и при обмене данными с поставляющим информацию приложением 20₁ средство 21₁ доступа будет использовать внедиапазонный параметр времени жизни (или времени пассивности), V.

Поставляющее информацию приложение 20₁ затем проверяет, какая информация должна быть получена или установлена из XML-формы дерева узлов, и отправляет ответ, VII, соответствующему средству 21₁ доступа, содержащему XML-дерево узлов, заполненное запрошенной информацией, а также информацию о состоянии завершения. XML-дерево узлов возвращается от поставляющего информацию приложения 20₁, после выборки информации, VI, из базы 23 данных, обратно в соответственное средство 21₁ доступа в контейнере XML-дерева узлов.

Средство 21₁ доступа поставляющего информацию приложения затем преобразует XML-дерево узлов, принятое из приложения 20₁, в транспортный XML-файл общим XSLT-файлом для такого ID DTD. Ответ затем отправляется по HTTPS с новым транспортным XML-файлом возврата в средство доступа 11₁ запрашивающего приложения 10₁, VIII

VI относится к изобретенному преобразованию в SQL-требование и возвращению информации, ответа, в соответствующее местоположение/узел, как будет более основательно описано ниже.

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

Во-первых, 100, предполагается, что общее соглашение (общее DTD) между запрашивающим приложением A4 и поставляющим приложением В4 установлено. (Конечно, соглашение может уже быть в распоряжении и, может быть, было установлено на более ранней стадии, это не является значимым для функционирования приложения, в этой реализации, однако, установленное соглашение есть). С использованием общего соглашения, создается DTD-соглашение, определяющее, какой информацией дозволено обмениваться между А4 и В4, 101. Как и на предыдущем этапе, DTD-соглашение (ID DTD) может уже быть в распоряжении. Должно быть понятно, что идея изобретения не полагается на установление каких бы то ни было соглашений, это относится лишь к отдельным реализациям.

ID DTD в таком случае используется, чтобы построить XML-форму, реализованную здесь в качестве объекта XML-дерева узлов DOM с атрибутами, представляющими запросы, которые должны содержаться в форме, 102.

В А4 форма затем заполняется посредством задания значимым атрибутам соответствующих значений, как будет дополнительно проиллюстрировано далее, 103. Впоследствии объект XML-дерева узлов DOM, то есть, заполненная форма в объектном виде, преобразуется в транспортную XML-строку, например, с использованием XSLT, таблицы стилей XSL (таблицы расширяемого языка стилей), 104. Помеченное XML-дерево узлов (то есть, помеченное тем, что атрибутам и данным элементов заданы значения, например, получить) отправляется в виде транспортной XML-строки в поставляющее приложение B4, 105. На поставляющей стороне, то есть, на стороне В4, транспортная XML-строка синтаксически разбирается в XML-объект, с использованием синтаксического XML-анализатора DOM, 106. На поставляющей стороне требование XML-формы также конвертируется в вызов базы данных, например SQL-формата (языка структурированных запросов), который отправляется в соответствующую базу данных, хранящую информацию, 107. Из базы данных, запрошенная информация затем возвращается в B4, 108. Извлеченная информация заполняется по XML-дереву узлов DOM (форме) посредством задания надлежащих значений атрибутам и данным элементов согласно информации из базы данных, 109. Это будет дополнительно описано ниже.

Впоследствии XML-объект (форма) дерева узлов преобразуется в транспортную XML-строку, например, с использованием XSLT, как обсуждалось выше, 110. Транспортная XML-строка возвращается запрашивающей стороне, содержащей запрашивающее приложение A4, 111.

В альтернативной реализации XML-форма реализуется и транспортируется в виде строки. Этапы, относящиеся к установлению соглашения и созданию DTD-соглашения (ID DTD) (или нахождению DTD-соглашения), соответствуют этапам 100, 101 по фиг. 5.

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

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

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

Фиг. 6 показывает, в пояснительной манере, XML-дерево узлов DOM и базу данных. XML-дерево узлов DOM содержит, в традиционной манере, корневой узел, узлы элементов и узлы атрибутов. Для преобразования в SQL-оператор в средстве преобразования, используется XSLT, реализующее XPath для LP (LocationPath, пути к местоположению) в качестве указателя. Правила касательно того, каким образом это делается, встроены в XSLT (i). Предварительным условием является то, что структура XML-файла известна (например, из проверки действительности XML, как разъяснено выше), но не известно содержимое атрибутов и элементов. Это значит, что некоторое количество XSLT-таблиц стилей имеется в распоряжении и что, в зависимости от DTD, выбирается одна из них.

Таким образом, в течение этапа преобразования вместе с XPath используется XSLT. Результатом преобразования будет преобразованная строка или целевая строка с информацией пути местоположения и сформированными SQL-операторами. Для операции GET (получить), информация пути местоположения указывает, где в XML-дереве узлов DOM будут вставлены информационные данные, извлеченные из средства хранения информации (например, базы данных). SQL-операторы задают, каким образом извлекать информацию из средства хранения информации (например, базы данных). Для операции SET (установить), информация пути местоположения указывает откуда, в XML-дереве узлов DOM, должна быть осуществлена выборка информации, которая должна быть установлена в средстве хранения информации. SQL задает, каким образом устанавливать информацию в средство хранения информации.

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

Завершенная преобразованная целевая строка будет содержать XPath-синтаксис пути к узлу значимого элемента, таким образом, представляя навигацию для данных ответа, которые должны быть возвращены к и помещены в имеющий отношение узел элемента/текста. Соответствующая часть программного кода затем использует SQL-операторы/команды и переводит универсальные имена переменных в вещественные имена переменных, полученные в качестве внеполосной информации. Таким образом, как только документ преобразуется в SQL, Java-класс для преобразованного документа используется поверх JDBC (SQL-интерфейса JAVA-приложений) к базе данных, iii, iv. Таким образом, все «помеченные переменные» заменяются и замещаются на вещественные переменные, затем программа, оперирующая файлом целевой строки, построчно «выводит» SQL-команду и LP, оперируя файлом, полученным в результате XSLT-преобразования.

В частности, тег замещения используется, чтобы определять ID пользователя, здесь названного пользователем B. Это называется тегом замещения ID пользователя B (универсального имени переменной). Как указывалось выше, ID пользователя B добавляется посредством замены ID, как задано в теге замещения. Как указывалось выше, это получается в качестве внеполосной информации (ID пользователя В). Впоследствии, ответ возвращается XML-дереву узлов DOM посредством реализации навигации LocationPath, а надлежащий узел (текстовый узел) может быть найден с использованием синтаксиса XPath-пути.

Фиг. 7 показывает процедуру для операции GET, например, для получения адреса кого-нибудь, с использованием идеи изобретения. Здесь предполагается, что XML-форма принимается в поставляющем приложении (от запрашивающего приложения с терминологией, использованной выше). Поставляющее приложение - приложение, обменивающееся данными со средством хранения информации, в этом месте, например, базой данных. На чертеже Address="get" является атрибутом, get является аргументом, а данные элемента (текстового узла) должны быть вставлены между > <. Форма предоставляется, i', синтаксическому XML-анализатору DOM, синтаксически разбирающему ее в XML-дерево узлов DOM, ii', с корнем, узлами элементов, текстовыми узлами, атрибутами и т.д. Требование затем должно быть обработано JAVA-кодом, чтобы выполнить XSLT-преобразование, как описано выше, iii'.Для этой цели соответствующая XSLT-таблица (в зависимости от DTD) выбирается из средства хранения XSLT-таблиц и предоставляется, iv', средству XSLT-преобразования. Это имеет результатом целевую строку, v', с информацией пути местоположения и SQL-операторами с универсальными именами (тегами) переменных. Это также может быть обозначено входной целевой строкой.

Код Java-класса затем оперирует входной целевой строкой (с универсальными именами переменных), чтобы заменить упомянутые универсальные имена переменных вещественными «значениями» имен переменных, vi'. Вещественные имена переменных получаются в качестве внеполосных данных, vii'.Это имеет результатом выходную целевую строку с вещественными именами переменных. (Это означает, что, например, тег замещения пользователя В был замещен вещественной ID пользователя B). SQL-операторы в таком случае исполняются с использованием программного кода JAVA-класса, viii', содержащего две части, которые указаны пунктирной линией на чертеже, одна, использующая целевую строку с действительными, вещественными именами переменных для исполнения SQL-операторов, ix', и одна, чтобы предоставлять информацию пути местоположения, относящуюся к тому, куда (местоположение) в дереве узлов DOM XML извлеченная информация должна быть вставлена. Информация пути местоположения затем используется, x', чтобы вставить извлеченную информацию в соответствующий узел. Посредством XSLT-преобразования извлеченная информация (данные) затем предоставляется в форму, xi', xii'.

Фиг. 8 является чертежом, подобным с фиг. 7, но взамен показывающим процедуру для операции SET, например, для установки адреса кого-либо, согласно идее изобретения. Здесь предполагается, что XML-форма принимается в поставляющем приложении (от запрашивающего приложения, сравните соответствующую процедуру для операции GET). В данном случае предполагается, что поставляющему приложению следует обмениваться данными со средством хранения информации, например, базой данных. На Фиг. 8 Address="set" является атрибутом, set является аргументом, а данные элементов (текстовый узел) установлены между > <, >данные<, где данными являются данные, выбранные из текстового узла, и должны быть установлены в базе данных, например, действительный адрес. Как и в случае с GET, форма предоставляется, i', синтаксическому XML-анализатору DOM, синтаксически разбирающему ее в XML-дерево узлов DOM, ii', с корнем, узлами элементов, текстовыми узлами, атрибутами и т. д. Требование затем будет обработано JAVA-кодом, чтобы выполнить XSLT-преобразование, как описано выше, iii'.Для этой цели соответствующая XSLT-таблица (в зависимости от DTD) выбирается из средства хранения XSLT-таблиц и предоставляется, iv', средству XSLT-преобразования.

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

Код Java-класса затем оперирует упомянутой входной целевой строкой (с универсальными именами переменных), чтобы заменить универсальные имена переменных вещественными именами переменных. Это будет иметь результатом выходную целевую строку с вещественными именами (значениями) переменных, vi'. Вещественные имена переменных получены в качестве внеполосных данных, vii'.(Это означает, что, например, тег замещения пользователя В был замещен вещественной ID пользователя B.) Данные, которые должны быть установлены, выбираются из текстового узла с использованием информации пути местоположения из целевой строки. Выбранные данные вставляются в SQL-операторы соответствующего тега, vii'', например, ValueToReplace (переменная для замещения). Соответствующий тег может, например, быть найден отыскиванием в SQL-утверждениях тега замещения SQL, куда должны быть вставлены данные.

SQL-операторы затем исполняются с использованием программного кода JAVA-класса, viii', содержащего две части, как указано пунктирной линией на фиг. 8, одну, использующую целевую строку с действительными, вещественными именами переменных для исполнения SQL-операторов, ix', и одну, чтобы предоставлять информацию пути местоположения, относящегося к тому, куда (местоположение) в XML-дереве узлов DOM извлеченная информация должна быть вставлена. Информация пути местоположения в таком случае используется, x', чтобы вставлять результат в надлежащий узел. Результат может, например, относиться к результату выполненной операции, например, "O.K.", если она была успешной. Посредством XSLT-преобразования, это затем предоставляется в форме, xi', xii'.

На блок-схеме алгоритма по фиг. 9 указаны главные функциональные этапы. Прежде всего предполагается, что требование (запрос) найден в XML-дереве узлов DOM (сравните с фиг. 6), 200.

В средстве преобразования, например, компоненте «поставляющего» приложения, XSLT-файл (соответствующий или выбранный XSLT-файл, как более тщательно оценено ранее) используется, чтобы сформировать SQL-оператор. Посредством использования XPath, устанавливается путь местоположения (LP), 201. Затем теги от начала до конца замещаются вещественными переменными, 202.

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

Фиг. 10 - блок-схема алгоритма, подобная той, что на фиг. 9, но показывающей этапы несколько более подробно. На первом этапе, 300, найдены запросы из XML-дерева узлов DOM, выполнено преобразование с использованием XSLT-файлов и найдены XPath-LP-пути для запросов, для того чтобы предоставить преобразованный файл/строку документа. В конкретной реализации активизируется Java™-класс, для преобразованного документа, 301, сравните также с фиг. 6, 7.

Затем теги от начала до конца замещаются вещественными переменными, 302. Java-класс затем вызывает базу данных через JDBC SQL-операторами, 303.

Данные ответа затем принимаются Java-классом, который также используется, чтобы возвратить данные ответа в соответствующее местоположение XML-дерева узлов DOM, в соответствии с путем местоположения, 304.

Затем проверяется, завершен ли преобразованный XML-документ DOM, 305. Если да, процедура завершается, в противном случае этапы 303, 304 повторяются до тех пор, пока преобразованный DOM-документ не завершается. В таком случае процедура заканчивается, 306.

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

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

Ниже показан пример документа требования в виде XML-формы, которая в заявке обсуждалась ранее.

Пример XML-формы для операции «Get»:

<Privacy>

<Address Address="get"> </ Address >

<Shoesize ShoeSize="get"> </ Shoesize >

(1)(2)

<Privacy>

(1)=Тег для запроса данных, который должен быть найден посредством XSLT

(2)= Данные, которые должны быть вставлены

Файл XSLT-преобразования может быть следующим:

Файл XSLT-преобразования

<?xml version="1.0"?>

<xsl:stylesheet mlns:xsl=http://www.w3.org/1999/XSL/Transform version="1.0">

<xsl:output method="text" />

<xsl:template match="/">

<xsl: apply-templates select="//Address"/> (5)

<xsl: apply-templates select="//Shoesize"/> (5)

</xsl:template>

(5) = пути местоположения (LP), которые будут сопоставлены посредством XPath.

Файл XSLT-преобразования (SQL-выбор)

<xsl:template match="Shoesize">

<xsl:if test="@ShoeSize[.='get']">

<xsl:text>

&#10;//Shoesize &#10;

SELECT ShoeSize FROM Databasetable WHERE UserIDB1='User IDB1'

(4)

&#10;

(3)

</xsl:text>

</xsl:if>

</xsl:template>

<xsl:template match="Address">

<xsl:if test="@Address[.='get']">

<xsl:text>

&#10;//Address &#10;

SELECT Address FROM Databasetable WHERE

UserIDBl='User IDB1'

(4)

&#10;

(3)

</xsl:text>

</xsl:if>

</xsl:template>

</xsl:stylesheet>

(3) = Разделитель (&#10)

(4)= Входные данные будут замещены в текстовом синтаксическом анализаторе

Ниже показан

Пример XML-формы для «Set»

<Privacy>

<Address Address="set"> Kista </ Address >

<Shoesize ShoeSize="set"> 37 </ Shoesize >

<Privacy>

а затем, продолжение файла XSLT-преобразования, файла XSLT-преобразования (SQL-обновление).

Файл XSLT-преобразования (SQL-обновление)

<xsl: template match="ShoeSize">

<xsl:if test="@ShoeSize[.='set']">

<xsl:text>

&#10;//ShoeSize &#10;

UPDATE Databasetable SET ShoeSize='ValuelToReplace'

WHERE UserIDBl='UserID'

&#10;

</xsl:text>

</xsl:if>

</xsl:template>

<xsl:template match="Address">

<xsl:if test="@Address[.=^?set']">

<xsl:text>

&#10;//Address &#10;

UPDATE Databasetable SET Address='Value2ToReplace'

WHERE UserIDBl='UserIDBl'

&#10;

</xsl:text>

</xsl:if>

</xsl:template>

</xsl:stylesheet>

ValueToReplace (значения для замещения) (1), (2) должны быть выбраны так, чтобы их можно было отыскать, и в этом месте могла быть введена информация из XML-дерева.

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

Настоящее изобретение относится к системе обмена данными между запрашивающей системой с протоколом и средством хранения. Техническим результатом является обеспечение доступа к средству хранения информации без необходимости знания жестко закодированных связей между осуществляющим доступ приложением и средством хранения. Система содержит средство хранения и распределенные приложения, которые содержат поставляющие информацию приложения, запрашивающие информацию приложения и преобразующее конвертирующее средство. Распределенные приложения взаимодействуют с преобразующим конвертирующим средством для преобразования/конвертирования требования в виде документа, содержащего форму на универсальном языке разметки, для средства хранения информации, в требование доступа, использующее протокол доступа для доступа к средству хранения информации, взаимосвязанное с указателем на местоположение в документе на универсальном языке разметки, представляющем требование. Упомянутое требование доступа к средству хранения информации активизируется при обычном запросе к средству хранения информации, а средство преобразования/конвертирования возвращает ответ к средству хранения информации, в соответствующее место в документе требования. 2 н. и 26 з.п. ф-лы, 10 ил.

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

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

предоставляют/принимают требование в виде документа, содержащего форму на универсальном языке разметки XML, в преобразующем конвертирующем средстве содержащемся или взаимосвязанным с приложением;

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

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

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

находят/выбирают XSLT;

выполняют преобразование с использованием найденного/выбранного

XSLT;

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

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

возвращают ответ обратно в соответствующее местоположение (узел) XML-дерева узлов DOM с использованием XPath-указателя.

используют XPath для установления соответствия со значениями атрибутов «get» или «set», относящимися к пути абсолютного узлового элемента XML-дерева узлов DOM, чтобы предоставить универсальное имя переменной;

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

используют универсальное имя переменной в качестве тега замещения для ID пользователя поставляющей стороны;

получают ID пользователя поставляющей стороны в качестве внеполосной информации;

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

используют информацию пути местоположения для осуществления навигации по данным возврата (ответа) к соответствующему узлу в XML-дереве узлов DOM.