Uddi

  • 18 апр. 2012 г.
  • 1044 Слова
UDDI
UDDI - важная часть философии SOA, занимающая свое место в знаменитом треугольнике Publish -- Find -- Bind (публикация - поиск - связывание). Провайдеры сервисов публикуют свои сервисы в UDDI, где инициаторы запросов могут найти эти сервисы и установить связь с ними с помощью указанных механизмов. Логическая структура UDDI подразделяется на три категории: «белые страницы», «желтые страницы»и «зеленые страницы». В «белых страницах» хранятся сведения о компании и ее контактная информация; желтые страницы предназначены для хранения информации о сервисах, которые предлагает эта компания; зеленые страницы служат для хранения всей технической информации о сервисе. В UDDI можно выделить четыре основные структуры данных:
1. BusinessEntity;
2. BusinessService;
3. BindingTemplate;
4.TModel.
Элемент BusinessEntity соответствует компании, которая предлагает некоторый сервис, указанный в элементе BusinessService. Элемент BindingTemplate определяет способ, которым потребитель, запрашивающий сервис, может связаться с этим сервисом. Элемент TModel представляет собой техническую модель сервиса. Благодаря этому для каждой записи в реестре создается иерархическая структура; в нейприсутствуют также другие элементы и вложенные элементы, представляющие прочие детали, например, классификации и даты


Пробный проект: Усовершенствование UDDI
Мы подробно рассмотрим различные решения с использованием одного из ведущих серверов приложений J2EE - IBM WebSphere Application Server v6. Этот сервер демонстрирует возможности взаимодействия с сервисом с использованием различных версий иразличных политик безопасности при помощи реестра узлов UDDI. Бизнес-уровень представлен сервером .NET, на котором мы разместим Web-сервисы.
Чтобы протестировать концепцию обмена данными о политиках безопасности, наш провайдер сервисов создает сервисы с двумя различными политиками безопасности. Для проверки поддержки управления версиями мы создаем два сервиса с различными реализациями и еще один сервис ссовершенно другой сигнатурой или интерфейсом. Эти сервисы размещаются на другом компьютере с платформой .NET.
На уровне реестра сервисов мы регистрируем все сервисы компании и конфигурируем их в соответствии с механизмом, который рассматривается в данной статье.
На стороне потребителя мы разделяем клиентские компоненты на две категории. Первый набор клиентских компонентов мы построим таким образом, чтобынаш клиент понимал файлы политик и мог использовать их, чтобы соответствовать реализации политики безопасности, заданной разработчиком сервиса. Затем мы воспользуемся набором клиентских компонентов для доступа к разным версиям сервиса. Этот набор будет иметь механизм обработки исключений, позволяющий ему подстраиваться под постоянно изменяющиеся версии и, в конечном итоге, обращаться к Web-сервису сминимальными сложностями и усилиями. Кроме того, мы создадим клиентскую заглушку и пользовательские компоненты на платформе Java на постороннем компьютере (отличном от тех, где мы разместили реестр сервисов и генератор сервисов).
________________________________________
В начало
Обмен данными о политике безопасности
Текущая ситуация
В текущей версии UDDI обеспечение политики безопасностиWeb-сервисов не описывается. С точки зрения бизнеса безопасность в обмене данными с Web-сервисами важна потому, что большинство бизнес-процессов и транзакций осуществляются через небезопасную зону - Интернет. Еще одно ограничение связано с тем, что транзакции с Web-сервисами больше затрагивают взаимодействия типа процесс-процесс, чем человек-процесс; следовательно, в данном случае динамическая схемаобеспечения безопасности приобретает еще большее значение. В связи с тем, что использование Web-сервисов постоянно расширяется, количество участников среды Web-сервисов будет расти в геометрической прогрессии; следовательно, нам нужен масштабируемый и адаптивный механизм обеспечения безопасности. Такие стандарты, как WS-Security (стандарт безопасности Web-сервисов), XACML...
tracking img