Обзор интегрирующей архитектуры Jazz Integration Architecture (JIA)

По материалам: jazz.net

Вступление

Основная цель архитектуры Jazz Integration Architecture – объединить разнообразные средства, используемые специалистами в организациях, которые занимаются разработкой информационных систем. Данный документ представляет обзор Jazz Integration Architecture и вводит понятие Jazz Team Server (JTS) -- сервера платформы Jazz, который позволяет осуществлять доступ к службам Jazz Foundation Services (JFS). Именно JFS дают возможность объединить различные инструменты для совместной работы. Здесь также показано, какое отношение имеется между Jazz Integration Architecture и открытыми сервисами Rational (Rational Open Services) в рамках развития технологии инициативы Open Services Lifecycle Collaboration (OSLC).

Введение

Мотивация

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

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

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

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

Вдохновение

Рассмотрим всемирную паутину WWW (World Wide Web). Каждый Web-сайт включает web страницы. Web страницы идентифицируются и к ним осуществляется доступ по-средством их URL и любая может включать ссылки на эти URL в виде гиперссылок на тот же или другие web сайты. Web броузер предоставляет web страницы и позволяет пользователям осуществлять переходы на другие web страницы, следуя через встроенные гиперссылки. Клиенты рабочего стола операционных систем запускают Web броузеры и коннектятся к web серверам с помощью стандартного Интернет-протокола HTTP. Пользователь видит World Wide Web, как совместимое объединение переплетенных связями друг с другом web страниц с разных web сайтов. Авторы Web сайтов могут без труда создавать Web сайты и Web страницы, которые хорошо интегрируются с другими Web сайтами и Web страницами. Публикация этих документов в одном из поддерживаемых стандартов Web позволяет огромному числу пользователей работать с содержимым этих документов. И все эти документы доступны с помощью относительно слабо связанных Wеb сайтов, давая возможность каждому Web сайту свободу расти и развиваться независимо от других сайтов. И, несмотря на относительно простую архитектуру, которая ограничивает для клиента возможность отсылать запросы на сервер и получать обратно синхронный ответ, люди находят эффективные и практичные пути эксплуатировать ее различными способами, которые было трудно предсказать заранее.

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

Обзор Jazz Integration Architecture

Цель Jazz Integration Architecture (JIA) - объединить разнообразные средства для совместной работы, создавая интегрированную среду для достижения максимальной эффективности работы команд. Jazz Integration Architecture - это не только другая монолитная платформа, но, скорее даже, набор внутренне связанных технологий и спецификаций. Jazz Integration Architecture состоит из эталонной архитектуры, спецификаций API, набора общих сервисов и строительных блоков для инструментов. Она позволяет создавать на ее основе новые инструменты и легко интегрировать существующие.

В центре Jazz Integration Architecture находится Jazz Team Server (JTS). JTS предлагает базовые сервисы – Jazz Foundation Services (JFS) – что и позволяет группам инструментов работать совместно. Эти сервисы включают функции администрирования пользователями и проектами, управления правами и коммуникацией, функции выполнения запросов и другие межинструментные возможности. После установки инструменты интегрированы и работают через тот или иной JTS.

Огромной мощью Jazz Integration Architecture является стандартизация API в виде, так называемого, RESTful API, а также унифицированные правила определения ресурсов, которые легко позволяют взаимодействующим инструментам работать с данными совместно. Jazz Integration Architecture также включает повторно используемые строительные блоки, которые ускоряют старт новых проектов и адаптацию существующих средств. И, наконец, сюда включаются спецификации, которые позволяют обеспечить улучшенную интеграцию среди пользовательских интерфейсов различных инструментов и навигацию между ними.

Web сервисы RESTful

Чтобы сделать данные и сервисы доступными широкому числу клиентов, инструмент предоставляет их через ресурсно-ориентированный набор Web-сервисов [Richardson and Ruby, RESTful Web Services, O’Reilly, 2007]. Начинкой этих Web-сервисов является стабильный и долгосрочный программный API, основанный на принципах Web, позволяющий оперировать с функциями и данными, поддерживаемыми инструментом. Эти Web-сервисы используют классификацию, разработанную на основе использования идентификаторов URI, методов HTTP и стандартов описания данных, таких как XML и JSON, которые полностью соответствуют принципам сети Web. Протоколы не зависят от состояний; состояние клиента значимо только для самого клиента; состояние сервера однозначно отражается на его ресурсах.

REST API обеспечивает наличие трех ключевых условий: стабильность URL для ресурсов инструмента; хорошая документация для использования этих самых ресурсами; наличие протокола и операций для манипулирования этими ресурсами на основе стандартных методов HTTP. Наличие URL для ресурсов инструмента позволяет подключаться к этим ресурсам откуда угодно – характеристика, которая отличает REST от SOAP/WS. Действительно, ресурсы становятся “гиперданными” аналогично тому, как гипертекст предоставляет полностью связанный, гибкий контент – текст, графику и т.д. Подобно остальным API, REST API должен разрабатываться очень осторожно с соблюдением условий стабильности и грамотного будущего эволюционирования. Долгосрочная стабильность URL является важной; без нее разорванные линки когда-нибудь станут серьезной проблемой. Долгосрочная стабильность и принципы совместимости при эволюционировании интерфейсов ресурсов -- это то, что создает предпосылки для разработки клиентов, которые смогут использовать ресурсы широкого диапазона серверов, возможно даже различных версий.

Ресурсно-ориентированные Web-сервисы могут легко обеспечить интерфейс с базовым набором операций CRUD (Create-создания, Read-чтения, Update-изменения, Delete-удаления) над ресурсами с применением методов POST, GET, UPDATE, и DELETE.

Jazz Team Server

Любой сервер Jazz Team Server (JTS) обеспечивает базовые сервисы, которые позволяют совместно работать группе инструментов подобно отдельному логическому серверу и могут включать любое число расширений (Jazz Team Server Extensions), которые предоставляют специфический функционал для инструментов. Все эти базовые и специфические, зависящие от средства, сервисы являются Web-сервисами RESTful.

Схема Jazz Team Server (JTS)

Рисунок 1. Jazz Team Server

Все взаимодействия между средствами осуществляются через узкую воронку REST API. Для обеспечения тесной интеграции инструментария все средства используют URL для обращения друг к другу (за исключением обращения к самим себе) по принципам "черного ящика" и не гадают, где развернуто то или иное средство. То же самое должно соблюдаться для всех клиентов, если необходимо, чтобы эти клиенты плотно взаимодействовали с сервисами.

Jazz Integration Architecture позволяет добавлять к тому или иному серверу JTS множество других серверов со своими собственными клиентами, каждый из которых отвечает за управление своим собственным URL и обработку приходящих от клиентов запросов. Так как URL однозначно идентифицирует сервер, обрабатывающий запросы клиентов к ресурсам и сервисам, размещенным на этих серверах, то запросы клиентов могут осуществлять прямой контакт с любым числом доступных серверов. Внутри самого себя инструмент координирует собственную деятельность со своим Jazz Team Server (снова отметим, что это происходит посредством скрытых вызовов сервисов через REST API). И здесь требуется не просто входная дверь, через которую, как через воронку проходят клиентские запросы. Это позволяет также облегчить интеграцию средств с существующими серверами и означает, что каждый инструмент будет управлять своим пространством URL без необходимости координации с другими инструментами. Сервера, обрабатывающие клиентские запросы, также могут включать сервера с описанием пользовательских интерфейсов UI (User Interface), предназначенных для отображения тех или иных данных пользователям.

Jazz Team Server Extension

Jazz Team Server Extension (расширение Jazz Team Server) является специфическим функционалом инструментария, который адаптирован в рамках конкретного экземпляра JTS. Например, продукты Rational Team Concert и Rational Quality Manager добавляют свой функционал к JTS в виде расширений этого сервера. Каждый инструмент использует определенные возможности, реализуемые посредством JFS, для того, чтобы взаимодействовать с JTS, и предлагает свои собственные сервисы и данные с помощью Web-сервисов RESTful. Ресурсы жизненного цикла – сценарии тестирования, элементы работ или требования, – которые предлагаются с помощью этих сервисов RESTful, как ожидается, также соответствуют стандартам, изложенным в спецификациях OSLC (Open Services for Lifecycle Collaboration). Будучи интегрированными с сервисами REST из JFS, они позволяют серверу Jazz Team Server организовать унифицированный путь для предоставления клиентам своей функциональности. Это позволяет клиентам рассматривать Jazz Team Server, как "черный ящик" - как нечто, что предлагает набор взаимодействующих сервисов REST - без необходимости знать, как эти сервисы реализованы.

Отдельный JTS может состоять из одного или более серверов, работающих совместно. Jazz Foundation Services обычно размещены на отдельном сервере. JTS Extensions могут быть созданы, как приложения Web (т.е. упакованы в виде файлов WAR), и развернуты на подходящем сервере (возможно, но совсем необязательно, на отдельном физическом сервере с JFS). Некоторые расширения JTS Extensions можно развернуть на отдельном сервере, предназначенном специально для них. И некоторые расширения JTS Extensions могут определять специфическую функциональность инструментария с применением простой регистрации конфигурационных файлов и скриптов с помощью специально созданных базовых сервисов. Это означает, что разработчики имеют в инструментах спектр опций, определяющих, как инструменты могут быть упакованы и развернуты на JTS, и обеспечивают гибкость для пользователей при выборе схемы развертывания серверов, которая соответствует их потребностям.

Схема подключения Jazz Team Server Extension на JTS

Рисунок 2. Jazz Team Server Extension

Существующий инструмент, который адаптирован для предоставления JTS Extension, может включать свой собственный сервер и хранилище данных. Это подразумевает, что фактически данные для JTS могут быть размещены в нескольких базах данных. Но поддержка атомарных транзакций для множества баз данных, как известно, является дорогостоящим делом. Где имеет смысл, инструменты будут обеспечивать поддержку транзакций для своих собственных данных. Jazz Integration Architecture не поддерживает механизм транзакций.

Jazz Foundation Services

Jazz Foundation Services (JFS) - это набор Web-сервисов RESTful– REST API – для управления доступом пользователей и администрирования проектов, управления безопасностью, организации коммуникации, выполнения запросов данных и предоставления некоторых других основных межинструментных возможностей. И хотя множество деталей все еще находятся в разработке, следующие наброски чуть более детально описывают типы сервисов, которые предоставляются посредством Jazz Foundation Services.

Сервис обнаружения (Discovery Service). С помощью ссылок URL Сервиса обнаружения можно найти REST API для идентификации тех или иных сервисов и специфических возможностей Jazz Team Server, таких как интерфейс пользователя для вывода Web-представлений для конкретных ресурсов. Сервис обнаружения является долгосрочным механизмом, который позволяет получать и отслеживать важную информацию о самом Jazz Team Server. Существуют закулисные механизмы Сервиса обнаружения, позволяющие pегистрировать такую информацию для доступа к необходимым сервисам. Кроме того, Сервис обнаружения используется всеми сервисами для выявления местоположения других сервисов, предоставляемых другими инструментами и размещенными на данном JTS (Telelogic TDS и Ресурсы обнаружения JRS - JRS's Discoverability Resources - являются родоначальниками подобного механизма).

Сервисы администрирования (Administration Services). Разработка средств с применением максимальной интеграции требует ее наличия, как на уровне пользовательского интерфейса, так и внутри самого сервера. Подобно другим распределенным системам каждый Jazz Team Server включает ядро с набором Сервисов администрирования для проведения операций над пользователями, проектами, операций с правами доступа и лицензиями. Например, некоторые инструменты используют эти сервисы заднего плана, чтобы обеспечивать общие правила аутентификации, которые также могут быть тесно связаны с серверами LDAP в организациях. Другое преимущество состоит в том, что можно единообразно управлять пользователями и проектами, предоставляемых каждым отдельным инструментом, с потенциальными возможностями их расширения (родоначальники разнообразных Сервисов администрирования присутствуют на платформах Jazz Platform 0.6 kernel и Telelogic TDS).

Сервисы процессов (Process Services). При рассмотрении различных сервисов следует отметить, что новаторство Jazz лежит в области управления процессом. Предоставляя базовый движок Jazz Process Engine в виде сервисов REST API, каждый отдельный сервер может быть адаптирован в текущий процесс и полностью участвовать в управлении этим процессом. Это может включать контроль прав доступа и наличия лицензий, проверку существования специфических предусловий на различных этапах процесса и автоматизации необходимых действий, которые должны обязательно выполняться при заранее определенных ситуациях. Этот сервис также сохраняет лог любых успешных действий, обеспечивая централизованный механизм отслеживания операций, выполненных в соответствии с правилами, определенными в рамках такого процесса. Пользователи обычно положительно оценивают возможность централизованной настройки командного процесса и помощь от инструментария в непрерывном указании правильных действий для пользователя в рамках этого процесса (родоначальники Сервисов процессов реализованы на компоненте Jazz Platform 0.6 Process данной платформы).

Сервисы управления данными (Storage Services). Jazz Team Server предоставляет Сервисы управления данными, которые могут быть использованы инструментами при выполнении операций верхнего уровня над данными, что позволяет исключить необходимость прямой работы с конкретными базами данных и, таким образом, непосредственную зависимость от них (Сервис управления данными JRS Storage Service является прототипом данного сервиса).

Сервисы запросов (Query Services). Различным клиентам необходимо осуществлять поиск данных, сохраняемых на Jazz Team Server. Здесь необходимо учитывать то обстоятельство, что некоторые специфические ресурсы можно разместить на Jazz Team Server Extension, который, в свою очередь, может быть развернут в виде отдельного сервера. Сервера Jazz Team Server Extension необязательно обязаны быть гомогенными, и каждый из них может хранить свои ресурсы в своей собственной базе данных. Такой подход предполагает, что данные инструмента могут извлекаться из базы и сохраняться в виде поисковых индексов. Это позволяет объединить индексы в независимости от используемых средств, развернутых на Jazz Team Server, и обеспечить централизованный механизм запросов с помощью Сервисов запросов (Query Services) для осуществления поиска информации по запросам, сформулированных на унифицированном и понятном языке. Для возможности получения структурированной информации по ресурсам извлекаемые индексы основываются на стандартах RDF и SPARQL. Для осуществления полнотекстового поиска используется механизм на основе Apache Lucene (родоначальники и структуры извлекаемых индексов, и структурированных запросов для осуществления полнотекстового поиска присутствуют в JRS).

Сервисы представления (Presentation Services). Четко определенные типы ресурсов и стандартизация RESTful API обеспечивают необходимый хребет для Jazz Integration Architecture, но этого все еще недостаточно для ряда сценариев для организации межинструментного взаимодействия, которые только можно себе вообразить. Сложность состоит в переполнении связями на другие ресурсы, находящихся под управлением других инструментов. Эти связанные ресурсы могут быть далекими от текущего клиентского средства или текущий инструмент не имеет пользовательского интерфейса для этих ресурсов. Например, элемент работы может быть подвязан к требованию. Можно случиться, что инструмент, в котором этот элемент работы используется, будет менее способен предоставить полноценный пользовательский интерфейс для связанных требований.

Presentation Services на Jazz Team Server (JTS)

Рисунок 3. Сервисы представления

Сервисы представления предоставляют возможность для клиентского средства запросить URL пользовательского интерфейса, размещенного на экземпляре JTS (вместе со всеми необходимыми расширениями). При наличии, этот сервис возвращает список URL по доступным пользовательским интерфейсам, которые могут быть использованы для работы с таким ресурсом (механизм Telelogic’s Application Registration был частично создан, чтобы позволить подобный вид взаимодействия).

Сервисы хранилища данных (Data Warehousing Services). Корпоративное хранилище данных может объединять данные одного или более серверов Jazz Team Servers, а также данные из других источников. Отдельные средства Jazz Team Server могут периодически делать снимок данных и экспортировать его информацию в хранилище корпоративных данных с помощью Сервисов хранилища данных (родоначальниками этих сервисов являются компонент Team Reports платформы Jazz Platform 0.6, Telelogic Altair и подсистема Vega enterprise data reporting work).

Сервисы взаимодействия (Collaboration Services). Jazz Team Server предоставляет и другие ключевые сервисы, поддерживающие механизмы коммуникаций, включая сервисы рассылки email и SMS, поддержку механизма подписок на информацию и т.д.

Открытые сервисы для взаимодействия в рамках жизненного цикла (Open Services for Lifecycle Collaboration)

Направление “Открытые сервисы для взаимодействия в рамках жизненного цикла” (Open Services for Lifecycle Collaboration - OSLC) является промышленной инициативой, изначально предложенной IBM в июне 2008 г., которая направлена на упрощение механизмов взаимодействия исполнителей на всем протяжении жизненного цикла разработки и поставки программных решений. Ключевая цель инициативы – позволить командам использовать несопоставимые средства и работать с разделяемыми ресурсами в ходе разработки независимо от того, являются ли инструменты продуктами IBM, других вендоров, результатами проектов с открытым исходным кодом (Open Source) или доморощенными. Инициатива OSLC предлагает интегрирующую архитектуру и набор Web-протоколов и сервисов для организации взаимодействия в рамках жизненного цикла разработки на принципах RESTful. За дополнительной информацией, включая начальные описания ресурсов жизненного цикла, таких как требования и сценарии тестирования, а также протоколов и сервисов для доступа к указанным ресурсам, можно обратиться на “http://open-services.net/”).

Предполагается, что средство, которое оперирует с ресурсами жизненного цикла, соответствует OSLC в некоторой конкретной области. Например, продукты Rational Requirements Composer (RRC) или Telelogic DOORS управляют ресурсами из области управления требованиями в соответствии с OSLC. Это дает возможность клиентским продуктам, работающим по спецификациям OSLC, иметь доступ к ресурсам управления требованиями других инструментов без необходимости что-либо знать о реализации Jazz Integration Architecture и не зависеть от того, работают ли те инструменты с применением JTS Extension.

Подобным же образом, инструменты, которым необходимо взаимодействовать с другими инструментами жизненного цикла разработки, должны соответствовать протоколам и сервисам спецификации OSLC также в конкретной области. Например, продукт Rational Quality Manager (RQM), который может сформировать отчет об обнаруженной ошибке по результатам тестирования некоторого сценария работы пользователя с системой, должен удовлетворять спецификации протокола OSLC при создании такого отчета. Это дает возможность создать описание ошибки для любого инструмента, который поддерживает стандарт OSLC, для подключения линков от результирующего описания ошибки обратно к сценарию тестированию. Сервер, на котором ошибка была сохранена, может быть сервером JTS, также как и сервером совсем другого типа.

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

Построение пользовательского интерфейса (UI)

Jazz Integration Architecture будет также включать спецификации, имеющие отношение к компонентам пользовательских интерфейсов специфических инструментов и построению сложного композитного пользовательского интерфейса из этих компонент (такой подход демонстрируется в системах на базе Lotus iWidget; Telelogic Team Webtop с компонентами UI для Telelogic Change, DOORS и Tau; а также в Web Dashboards в составе Rational Team Concert).

Базовые структуры Jazz (Jazz frameworks)

Термин "Базовые структуры Jazz" относится к специфическим библиотекам, строительным структурам и блокам, которые могут оказаться полезными при адаптации существующих инструментов и их интеграции в рамках Jazz Integration Architecture, а также при разработке новых продуктов для платформы Jazz. Сюда также могут быть включены специфические библиотеки для доступа к различным сервисам Jazz Foundation Services и другим специфическим сервисам, относящимся к той или иной области, а также для построения клиентов Eclipse, Web и клиентов командной строки.

Предполагается, что базовые структуры Jazz будут помогать в большей степени при разработке инструментов; любые варианты интеграции на основе Jazz Integration Architecture могут быть реализованы с помощью любого языка программирования, который может работать с HTTP и XML. Доступный для клиентов и независимый от языка программирования REST APIs обеспечивает основу для разработки клиентских библиотек на любом языке программирования. Так как REST API хорошо документирован, то информация, которая нужна для разработки клиентской библиотеки на любом языке программирования, опубликована и находится в свободном доступе. Базовые структуры Jazz для некоторых популярных языков разрабатываются и поддерживаются на jazz.net, но ожидается, что и другие библиотеки могут создаваться кем угодно и где угодно.

Как инструмент реализует Jazz Integration Architecture

В предыдущей секции были описаны ключевые элементы Jazz Integration Architecture. Эта секция в основном предназначена для разработчиков инструментария; она описывает, как эти элементы применяются на практике при создании нового или адаптации существующего инструмента, чтобы реализовать поддержку Jazz Integration Architecture.

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

Реализуйте поддержку REST API

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

Заметьте, что инструмент может поддерживать REST API без необходимости участвовать в работе самого JTS. В самом деле, это есть рациональная конфигурация для инструментов, которые должны поставляться в виде автономных продуктов и работать независимо от какого-либо JTS.

Документ Jazz Integration Architecture document [Steve Abrams, RESTful Guidance] является руководством по разработке REST API.

Обеспечьте поддержку пользовательского интерфейса (UI)

Инструмент должен поддерживать Сервисы представления, чтобы клиент – "толстый" или "тонкий" – мог обратиться с запросом к его ресурсам и пользователь мог получить возможность для работы с ними.

Обеспечьте взаимодействие с другими средствами жизненного цикла с помощью специфических для области Web-сервисов OSLC

Если от инструмента требуется взаимодействие с другими инструментами жизненного цикла, то такая поддержка организуется через Web-сервисы OSLC для конкретной области применения инструмента. Например, если от инструмента требуется создать элемент работы, то необходимо использовать Web-сервисы OSLC для элементов работ. Таким образом, инструмент сможет оперировать с любыми элементами работ, которые соответствуют стандартам OSLC.

Регистрируйте функционал, как JTS Extension

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

В одних случаях инструмент может быть реализован исключительно в виде JTS Extension и работать через Foundation Services, которые предоставляются JTS. Такой инструмент может поставляться пользователям и устанавливаться в виде расширения для одного из существующих серверов Jazz Team Server (или для пользователей, не желающих иметь отдельный сервер, инструмент может быть поставлен в виде пакета, в который уже включен JTS). В других случаях имеет смысл использовать инструмент без поддержки Jazz Team Server и интегрировать его с JTS, когда наступит время. Это позволит работать на первых порах пользователям автономно и интегрировать его с Jazz Team Server, как только он появится.

Используйте аутентификацию JTS

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

Публикуйте точки входа для Сервиса обнаружения JTS

Каждый Jazz Team Server включает центральный реестр по информации, которая предлагается клиентам (в том числе для расширений JTS) через Сервисы обнаружения, позволяя клиентам определить базовые настройки и идентифицировать ресурсы и сервисы, размещенные на JTS. Статический набор специфичных для инструмента данных может быть включен в центральный реестр Jazz Team Server, когда инструмент конфигурируется, как JTS Extension, позволяя ему объявить и описать себя для использования клиентами через Сервис обнаружения.

Операции, акцентированные на процесс

Jazz Team Server вводит понятие области процессов совместно со связанным процессом, в соответствии с которым участники команды разработчиков действуют, используют артефакты и связи между ними и выполняют операции, которые определены в рамках той или иной области процесса. Пользователи разрабатывают процессы для JTS, обеспечивая возможность автоматизации контроля со стороны JTS за соблюдением правил, определенных в процессах. Функции процессного управления могут быть реализованы в инструменте и тогда они позволят управлять всей работой команды. В инструменте должны быть определены связи ресурсов с областями процесса. В этом случае, если инструмент формирует запрос на выполнение операций с ресурсом, он сначала должен предоставить информацию для Jazz Process Engine (одного из Сервисов администрирования) о типе операции, которая может быть выполнена над таким-то ресурсом в данной области процесса, как это определено правилами текущего процесса.

Используйте Сервисы управления данными

Инструмент должен использовать Сервисы управления данными JTS для сохранения своих ресурсов вместо того, чтобы размещать их в отдельных базах данных.

Управление лицензиями на продукты

Инструмент должен использовать Сервисы администрирования JTS для оперирования с лицензиями на продукт.

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

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

Делайте снимки данных в хранилище данных

Инструмент должен периодически подготавливать снимки данных и экспортировать эту информацию в корпоративное хранилище данных с помощь Сервисов хранилища данных JTS.

Разработайте компоненты пользовательского интерфейса

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

***

В Каталоге Центра IT обучения "Institutio" представлено несколько программ обучения по направлению Jazz и отдельным его инструментальным средствам, отличающихся друг от друга включенными в них модулями:

  1. PCOM0001, Обзор технологии Jazz и основных инструментальных средств (общий обзор технологий Jazz и ключевых инструментальных средств), 4 дня
  2. PCCM0001, Введение в IBM Rational Team Concert (начальный обзор инструментального средства с целью максимально быстро научиться применять его на практике), 1 день
  3. PCCM0002, Возможности IBM Rational Team Concert (начальный обзор инструментального средства и его расширенные интеграционные возможности для организации командной разработки), 2 дня
  4. PCCM0003, Автоматизация командной разработки ПО с помощью IBM Rational Team Concert (введение в дисциплину управления версиями и конфигурациями, начальный обзор RTC и его расширенные интеграционные возможности для организации командной разработки), 3 дня
  5. PREQ0001, Введение в IBM Rational Requirements Composer (обзор базовых возможностей инструментального средства для быстрого старта в его использовании), 1 день
  6. PREQ0002, Возможности IBM Rational Requirements Composer (базовые и расширенные интеграционные возможности RRC, интегрированное использование средства с учетом подхода Collaborative Application Lifecycle Management), 2 дня
  7. PREQ0003, Управление требованиями с использованием IBM Rational Requirements Composer (введение в дисциплину управления требованиями, рассмотрение базовых и расширенных интеграционных возможностей RRC), 3 дня
  8. PTST0001, Введение в IBM Rational Quality Manager (обзор базовых возможностей инструментального средства для быстрого старта в его использовании), 1 день
  9. PTST0002, Возможности IBM Rational Quality Manager (базовые и расширенные интеграционные возможности RQM, интегрированное использование средства с учетом подхода Collaborative Application Lifecycle Management), 2 дня
  10. PTST0003, Интегрированное управление тестированием с использованием IBM Rational Quality Manager (введение в дисциплину тестирования, рассмотрение базовых и расширенных интеграционных возможностей RQM), 3 дня

© 2008-2023 Финэкософт.

 

Oracle Silver Partner
+7 (495) 234 8808
Учебный центр
Центр обучения и сертификации в области информационных технологий (IT).

Широкий выбор курсов и программ обучения. Подробности здесь.

Отправить письмо
Обратная связь

 

Для Ваших вопросов и отзывов