Система запроса вида IBM® WebSphere® Service Registry and Repository является очень гибким методом создания предопределенных запросов о содержимом реестра. Она использует простой XML-файл, определяющий параметры каждого запроса, назначая этому запросу уникальный идентификатор. Эти запросы - основной метод предоставления ссылок в навигационном дереве для показа соответствующих видов в пользовательском интерфейсе. Пользователи могут настраивать существующие или новые навигационные деревья в UI, определяя дополнительные запросы вида в файле определений запросов вида и ссылаясь затем на новые запросы в навигационном дереве.

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

Определения запросов вида предоставляют богатый набор запросов практически любого типа объектов, которые могут храниться в Service Registry and Repository. Возможными параметрами являются тип объекта, классификации, свойства и взаимосвязи. Эти параметры можно использовать в любой комбинации. Они охватывают все категории метаданных, поддерживаемых в Service Registry and Repository, поэтому предоставляют максимальную гибкость при поиске в реестре необходимых объектов.

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

Листинг 1. Базовый запрос вида
<ViewQueryDefinitionSet xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/ViewQueryDefinitionSet" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.ibm.com/xmlns/prod/serviceregistry/6/0/ViewQueryDefinitionSet ../../schemas/ViewQueryDefinitionSet.xsd"> <QueryDefinitions> <Query id="dWViewAllMonitoredServices"> <ObjectType>WSDLService</ObjectType> </Query> </QueryDefinitions> </ViewQueryDefinitionSet>

Каждый вид состоит из отдельного элемента Query, который содержится в элементе QueryDefinitions. Единственным ограничением по количеству запросов, которые можно определить, является емкость физической памяти, поскольку каждый запрос с момента запуска занимает определенный ее объем. Каждый запрос должен иметь уникальный ID, представленный атрибутом "id" в элементе Query. Необходимо начинать ID запроса с короткого префикса для минимизации шансов конфликта имен с другими определениями запросов вида, уже имеющимися в системе. Существует одно исключение для правила уникальности ID: можно переопределить существующий системный запрос вида пользовательским, создавая запрос вида с тем же самым ID. Используйте это исключение осторожно, поскольку изменение системного запроса вида может повлиять на ожидаемое функционирование видов перспективы по умолчанию.

Запрос в листинге 1 возвращает все объекты WSDLService, хранящиеся в данный момент в реестре, и вставляет элемент ObjectType. Тип объекта - это необязательный элемент, фильтрующий запрос для возврата объектов только данного типа. Можно выбирать только типы из фиксированного списка типов, соответствующих SDO-типам, поддерживаемым в настоящее время в реестре. В таблице 1 показан список допустимых типов объектов, которые можно использовать.

Таблица 1. Допустимые типы объектов
Тип объектаОписаниеWSDLDocumentWSDL-документXMLDocumentXML-документ XSDDocumentДокумент определения XML-схемыPolicyDocumentДокумент политики GenericObjectОбщий объект (в API), отображаемый как Concept в UIWSDLBindingЛогический объект WSDL-связыванияWSDLMessageЛогический объект WSDL-сообщения WSDLOperationЛогический объект WSDL-операции WSDLPartЛогический объект части WSDL-сообщенияWSDLPortЛогический объект WSDL-порта WSDLPortTypeЛогический объект типа WSDL-порта WSDLServiceЛогический объект WSDL-сервисаSOAPAddressЛогический объект SOAP-адреса SOAPBindingЛогический объект SOAP-связывания XSDAttributeЛогический объект XSD-атрибута XSDComplexTypeЛогический объект составного XSD-типа XSDSimpleTypeЛогический объект простого XSD-типа XMLElementЛогический объект XML-элемента SCAModuleКонтейнер SCA-модуляModuleDocumentДокумент (SCA) модуляImportDocumentДокумент (SCA) импорта ExportDocumentДокумент (SCA) экспортаModuleЛогический объект (SCA) модуляImportЛогический объект (SCA) импорта ExportЛогический объект (SCA) экспорта SCAImportBindingЛогический объект связывания импорта SCA SLSBImportBindingЛогический объект (SCA) связывания импорта не сохраняющего состояния сессионного компонента WebServiceImportBindingЛогический объект связывания импорта web-сервиса (SCA)SCAWSDLPortTypeЛогический объект типа WSDL-порта SCASCAExportBindingЛогический объект связывания экспорта SCA WebServiceExportBindingЛогический объект связывания экспорта web-сервиса (SCA)SubscriptionОбъект подписки

Обратите внимание на то, что GenericObject - это SDO-имя объекта, появляющегося в Web UI как Concepts. Элемент ObjectType не является необходимой настройкой – если его опустить, то запрос будет рассматривать все доступные для поиска объекты реестра как часть запроса (то есть, все объекты, наследуемые из родительского класса SDO BaseObject).

Запрос в листинге 1 использует для объекта WSDLService определение сборного вида по умолчанию, однако мы можем выбрать другой вид для отображения результатов запроса. В примере сценария WSRR Traders Inc. есть несколько дополнительных свойств, сохраняющихся в наших сервисах программой мониторинга, и мы отобразим эти новые значения в видах, содержащих результаты запроса. Это можно сделать при помощи элемента DisplayType, как показано в листинге 2:

Листинг 2. Использование альтернативных видов
<ViewQueryDefinitionSet> <QueryDefinitions> <Query id="dWViewAllMonitoredServices"> <ObjectType>WSDLService</ObjectType> <DisplayType>dWAllWSDLService</DisplayType> </Query> </QueryDefinitions> </ViewQueryDefinitionSet>

Элемент DisplayType указывает Web UI использовать определение другого вида для отображения результатов запроса. Это определение вида указывается его уникальным ID, которое отображается на определение сборного вида в файле определения перспективы. Более подробная информация по созданию определений перспектив и видов приведена в третьей части данной серии статей. На рисунке 1 показан этот запрос вместе с изменениями пользовательского сборного вида в нашем сценарии WSRR Traders Inc.

Рисунок 1. DisplayType с пользовательским сборным видом

Система запроса вида поддерживает запрос по свойству с использованием элемента Property. Элемент Property имеет два атрибута - имя и значение запрашиваемого свойства. Каждый из этих атрибутов является точным соответствием, то есть, в имени и значении нельзя использовать групповые символы (wild cards). В листинге 3 показан пример из нашего сценария:

Листинг 3. Запрос по свойству
<ViewQueryDefinitionSet> <QueryDefinitions> <Query id="dWViewGoldServices"> <ObjectType>WSDLService</ObjectType> <DisplayType>dWGoldWSDLService</DisplayType> <Property name="serviceLevel" value="gold"/> </Query> </QueryDefinitions> </ViewQueryDefinitionSet>

В данном примере запрос ищет все объекты WSDLService, содержащие свойство "serviceLevel", имеющее точное значение "gold". Чтобы расширить поиск, можно не указывать имя или значение. Пропуск атрибута value изменит запрос таким образом, что будет осуществляться поиск всех объектов данного типа, содержащих свойство с указанным именем, независимо от значения. Также, пропуск атрибута value изменит суть запроса так, что он будет осуществлять поиск всех объектов данного типа, содержащих любое свойство, значение которого точно соответствует указанному.

Запрос по взаимосвязи позволяет найти объекты в реестре по их взаимосвязи с другим объектом. При этом используется элемент Relationship и связанный с ним дочерний элемент Target. Типичным применением этого объекта является ситуация, когда используются шаблонные объекты, чтобы гарантировать нахождение объектов корректного шаблонного типа. В листинге 4 приведен синтаксис именно такого запроса:

Листинг 4. Запрос по взаимосвязи
<ViewQueryDefinitionSet> <QueryDefinitions> <Query id="dWViewTemplated"> <ObjectType>GenericObject</ObjectType> <Relationship name="template"> <Target> <Property name="name" value="MyType"/> </Target> </Relationship> </Query> </QueryDefinitions> </ViewQueryDefinitionSet>

Этот запрос читается как "найти все обобщенные (generic) объекты, имеющие взаимосвязь под названием 'template', а целевой объект этой взаимосвязи имеет название 'MyType'". При этом в запрос вводятся новые элементы. Во-первых, элемент Relationship, объявляющий, что запрос ищет взаимосвязь у объектов указанного типа. Этот элемент имеет необязательный атрибут с конкретным именем искомой взаимосвязи, которая может быть либо смоделированной взаимосвязью, либо определенной пользователем. Здесь указывается точное соответствие и групповые символы не расширяются. Если не указывать имя взаимосвязи, запрос будет искать целевые объекты для всех взаимосвязей в начальном списке объектов, отфильтрованных по данному типу.

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

Система запроса вида имеет четыре различных элемента, охватывающих все возможные способы использования классификаций как части запроса. Каждый из этих элементов содержит любое количество элементов ClassificationURI, формирующих список классификаций для поиска. Классификации указываются как полностью квалифицированные OWL URI из системы классификации, классифицирующей объект. Кроме того, можно использовать операции поиска, включающие классификации, которые имеют дочерние OWL URI в системе классификации (то есть, существуют дополнительные классификации, являющиеся подклассом subClassOf данного URI в терминах OWL) при условии, что указанный URI и все его подразумеваемые дочерние URI тоже рассматриваются как часть операции поиска. Например, классификационный расширенный поиск по "Fruit" мог бы рассматривать как часть операции поиска также "Apple" и "Orange" в качестве дополнительных классификаций. В таблице 2 приведены четыре элемента и их поведение.

Таблица 2. Элементы классификации
Элемент ЗначениеQueryClassificationsAnyOfНайти объекты, классифицируемые любыми данными URI, и дополнительно рассмотреть все подразумеваемые дочерние URI из каждого URI в начальном списке.QueryClassificationsAllOfНайти объекты, классифицируемые всеми данными URI, и дополнительно рассмотреть все подразумеваемые дочерние URI из каждого URI в начальном списке.QueryExactClassificationsAnyOfНайти объекты, точно классифицируемые любыми данными URI, не используя расширенный поиск.QueryExactClassificationsAllOfНайти объекты, точно классифицируемые всеми данными URI, не используя расширенный поиск.

В примере сценария WSRR Traders Inc. мы используем простой OWL-файл для классификации общего состояния сервиса. Для индикации работы сервиса используется три классификации: Green (в пределах нормы), Amber (внимание, повышенный риск) и Red (аварийный режим).

Листинг 5. Пример OWL-файла
<?xml version="1.0" encoding="utf-8"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xml:base="http://www.ibm.com/wsrr/MonitorStatus"> <owl:Ontology rdf:about=""> <rdfs:label>Monitored Service Status</rdfs:label> <rdfs:comment>Status values for monitored services</rdfs:comment> </owl:Ontology> <owl:Class rdf:ID="Status"> <rdfs:label>Status</rdfs:label> </owl:Class> <owl:Class rdf:ID="StatusGreen"> <rdfs:subClassOf rdf:resource="#Status"/> <rdfs:label>Green</rdfs:label> </owl:Class> <owl:Class rdf:ID="StatusAmber"> <rdfs:subClassOf rdf:resource="#Status"/> <rdfs:label>Amber</rdfs:label> </owl:Class> <owl:Class rdf:ID="StatusRed"> <rdfs:subClassOf rdf:resource="#Status"/> <rdfs:label>Red</rdfs:label> </owl:Class> </rdf:RDF>

В сценарии WSRR Traders Inc. мы применяем запрос вида, используя классификации для показа сервисов с повышенным риском (листинг 6).

Листинг 6. Запрос по классификации
<ViewQueryDefinitionSet> <QueryDefinitions> <Query id="dWViewFailingServices"> <ObjectType>WSDLService</ObjectType> <DisplayType>dWFailingWSDLService</DisplayType> <QueryExactClassificationsAnyOf> <ClassificationURI> http://www.ibm.com/wsrr/MonitorStatus#StatusAmber </ClassificationURI> </QueryExactClassificationsAnyOf> </Query> </QueryDefinitions> </ViewQueryDefinitionSet>

Запросы вида позволяют использовать только один элемент типа классификации на запрос, выбранный из списка четырех доступных. Поиск полностью квалифицированного OWL URI для значения классификации иногда может быть сложным, даже если вы имеете доступ к исходному коду OWL-документа. Есть простая процедура для использования в Web UI, позволяющая найти полный URI любого значения классификации. В Web UI перейдите к любому объекту в сборном или подробном виде. В сборном виде выберите объект из списка и нажмите кнопку Add classifications, а в подробном виде нажмите ссылку Classifications в разделе взаимосвязей. Вам не нужно обновлять объект с новыми классификациями; это делается только для получения конкретного вида в Web UI. После перехода в вид классификаций вы можете получить полный OWL URI значения любой классификации, выбрав ее в списке классификаций. Все подробности этого значения показываются в таблице внизу страницы. Затем можно скопировать URI из Web UI. Если значения классификации нет в списке, можно добавить его, просмотрев дерево, выбрав значение и нажав кнопку Add. Если вы не намереваетесь обновлять классификации в объекте, не забудьте нажать кнопку Cancel после завершения указанных действий.

>

В Web UI Service Registry and Repository навигационное дерево всегда доступно в левой части страницы и выглядит как таблица с содержимым для текущего вида перспективы. При настройке UI здесь вы решаете, какие виды будут полезны для целевой аудитории перспективы. Хорошо разработанное навигационное дерево позволит найти необходимую информацию при помощи всего лишь нескольких нажатий кнопки мыши. В данном разделе рассказывается, как создать пользовательское навигационное дерево и как скомбинировать файл определения навигационного дерева и файл определения запроса вида для формирования окончательного навигационного дерева. На рисунке 2 показан пример навигационного дерева, формирующего часть сценария для данной серии статей.

Рисунок 2. Пример навигационного дерева

Встроенные стандартные функциональные возможности

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

Навигационное дерево для нашего сценария WSRR Traders Inc. содержит полностью новую группу высокого уровня, называемую Monitored services (Контролируемые сервисы), которые собирают вместе все пользовательские виды, необходимые для мониторинга сервисов в реестре. Оно также повторно использует раздел мастера запросов и раздел классификации из навигационных деревьев по умолчанию, предоставляемых с Service Registry and Repository.

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

Рисунок 3. Навигация по ссылкам и запрос вида

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

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

Листинг 7. Пример навигационного дерева
<NavigationTree xmlns="http://www.ibm.com/xmlns/prod/serviceregistry/6/0/NavigationTreeDefinition" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation= "http://www.ibm.com/xmlns/prod/serviceregistry/6/0/NavigationTreeDefinition ../../schemas/NavigationTree.xsd" name="dWMonitorNavTree"> <node id="navtree_root" node-resource-key="navigationtree.service.registry"> <node id="servicemonitor" node-resource-key="navigationtree.service.monitor" node-resource-bundle="com.ibm.sr.MonitorPerspective"> <node id="allservices" node-resource-key="navigationtree.all.services" node-resource-bundle="com.ibm.sr.MonitorPerspective" view-query-id="dWViewAllMonitoredServices"/> . . </node> <node id="queries" node-resource-key="navigationtree.service.queries"> <node id="qwizard" node-resource-key="navigationtree.service.queries.wizard" forward="QueryWizardPrepare"/> </node> . . </node> </NavigationTree>

Элемент NavigationTree имеет только один атрибут, name, который должен быть уникальным в контексте всех навигационных деревьев Service Registry and Repository. Файлы определения перспективы используют это имя непосредственно для объявления применяемого навигационного дерева. Есть еще только один элемент, node, который помогает сформировать навигационное дерево. Элементы node могут быть любой вложенности, формируя древовидную иерархию в навигационной панели web UI. Самый внешний узел с ID "navtree_root" должен присутствовать в файле определения - он не отображается, но работает как контейнер для всех отображаемых узлов. Узлы первого уровня (от корня) формируют секции главного содержимого дерева и выделяются как основные заголовки в навигационной панели. Разделы содержимого не могут быть установлены как ссылки на виды - они служат только как контейнеры для других узлов и всегда отображаются в навигационной панели.

Элемент node имеет всего лишь два обязательных атрибута: id, который должен быть уникальным в файле определения навигационного дерева, и node-resource-key, который определяет ключ, используемый в файле ресурсов для отображения текста узла. Для работы с ключом ресурсов имеется необязательный атрибут node-resource-bundle, который позволяет указать другой файл ресурсов для загрузки отображаемого текста. Если он не указан, пакетом ресурсов (resource bundle) по умолчанию являются встроенные ресурсы, используемые Web UI. Любой предоставленный пользователем файл свойств ресурса должен быть доступен в WAS classpath - в профиле по умолчанию самым простым каталогом для использования мог бы быть WAS_HOME/profiles/default/classes.

Существует два метода указания способа работы активной ссылки при использовании элемента node. Основным способом является использование атрибута view-query-id и указание его значения в качестве ID запроса вида, хранящегося в файле определения запроса вида. Ссылки на запросы вида обычно используются для отображения наборов объектов, хранящихся в реестре, однако не каждый возможный вид или действие в Service Registry and Repository может быть представлено запросом вида, поэтому имеется второй атрибут, forward (перенаправление), который указывает специализированный вид, мастер или действие. В таблице 3 подробно перечислены перенаправления, которые вы можете использовать, и выполняемые ими действия.

HTTP

Заметка

1. Содержит загрузочные файлы WSRR для серии из четырех статей.

Роб Бридс (Rob Breeds) работает инженером-программистом и консультантом в IBM Hursley Laboratories, Великобритания в группе разработки WebSphere Service Registry and Repository. До этого был ведущим разработчиком пользовательских интерфейсов и инструментальных средств для WebSphere UDDI Registry в WebSphere Application Server 6.0 и 5.0, а еще раньше - соавтором книги "Разработка и программирование CICS-приложений". Степень бакалавра по химии, полученная в University of Bath, и профессия школьного учителя не помешали Робу приобрести двадцатилетний опыт разработки программного обеспечения, технических продаж, маркетинга и публикаций. До прихода в IBM он был разработчиком ЭВМ TPF в Galileo International.

Кевин Марш (Kevin Marsh) в настоящее время работает инженером-программистом в IBM Hursley Laboratories, Великобритания в группе поддержки WebSphere Service Registry and Repository (ранее - в группе разработки пользовательского интерфейса). До этого Кевин помогал созданию WebSphere UDDI Registry для WebSphere Application Server (версии 6.0 и 5.1), приобретая ценный опыт работы с J2EE. Кевин начал свою карьеру в IBM в 2001 после получения степени бакалавра по вычислительной технике в University of Kent в Кентербери.

Дэйв Сигер (Dave Seager) работает инженером-программистом в группе WebSphere Service Registry and Repository в IBM Hursley Laboratories, Великобритания. Имеет девятилетний опыт разработки программного обеспечения и поддержки пользователей в IBM. Является соавтором книги "CICS Transaction Gateway V5 WebSphere Connector для CICS" и автором нескольких статей по WebSphere на developerWorks. Имеет степень по разработке программного обеспечения от Oxford University.

Филипп Таунтон (Philip Taunton) работает старшим инженером-программистом в IBM Hursley Laboratories, Великобритания в группе разработки WebSphere Service Registry and Repository. Раньше работал в отделе Pervasive Computing. Является экспертом по компьютерной телефонии и по продуктам для голосовой связи в режиме реального времени (Java, Unix и Windows). Также специализировался на разработке и программировании пользовательских интерфейсов. Имеет степень по электротехнике и электронике от Bath University. Обладает четырнадцатилетним опытом разработки программного обеспечения и поддержки пользователей.

Помощь по сообщениям о нарушениях

Спасибо. Эта запись была помечена для модератора.

>

Помощь по сообщениям о нарушениях

Сообщение о нарушении не было отправлено. Попробуйте, пожалуйста, позже.

>

developerWorks: вход

>

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

Вся введенная информация защищена.

Выберите ваше отображаемое имя

При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

>

Вся введенная информация защищена.

SITE_ID=40

Zone=WebSphere, SOA и Web-сервисы

ArticleID=217298

ArticleTitle=Настройка пользовательского интерфейса WebSphere Service Registry and Repository: Часть 2. Создание определений запросов вида и навигационных деревьев

publish-date=05042007