Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Безпека GRID – технологій.doc
Скачиваний:
0
Добавлен:
01.07.2025
Размер:
1.5 Mб
Скачать

1.4.6.1. Сервіс-орієнтована архітектура

Фундаментальною концепцією OGSA є те, що сервісна архітектура складається з компонентів служб GRID, які працюють як спеціальні Web - сервіси, що надають ряд інтерфейсів, що відповідають спеціальним вимогам. SOA визначає, як взаємодіють два обчислювальні об'єкти, для того, щоб один об'єкт дав можливість другому виконати визначену роботу на користь першого. Ця робота співвідноситься з сервісом, а дії сервісу визначаються мовою описів. Кожна взаємодія самостійна і практично не залежить від іншого. Бізнес додатки створюються для автоматизації різних бизнес - процесів, але часто без здійснення в них можливості адаптуватися до потреб, що змінюються; доопрацювання бізнес процесів в даному середовищі, достатньо трудомістке завдання. Все тому, що бізнес додатки традиційно створюються як одиничні, монолітні, такі, що включають всі інструменти. Тому будь - які зміни в них достатньо дорогі і займають багато часу. У середовищі SOA, додатки створюються у вигляді набору сервісів, кожен з яких має свої завдання і властивості. У міру зміни потреб, деякі сервіси можуть додаватися, деякі видалятися або доопрацьовуватися.

Web - сервіси володіють наступними характеристиками:

  • Це Інтернет додаток, що виконує спеціальні завдання і що підкоряється стандартним специфікаціям.

  • Сервіс є здійснимим, він описується на XML і доступі до нього може бути здійснений за допомогою XML - повідомлень.

  • Він може бути анонсований, виявлений і викликаний в розподіленому обчислювальному середовищі.

  • Він не залежить від платформи або мови.

Web - сервіс є системою ПЗ, URL якого ідентифікується, а інтерфейси і зв'язки визначені і описані за допомогою XML. Він може бути виявлений іншими системами ПЗ. Ці системи, у свою чергу, можуть взаємодіяти з Web - сервісом, використовуючи XML повідомлення, що передаються за допомогою Інтернет протоколів. Мова описів Web - сервісів (WSDL) фактично є, заснованим на XML, стандартом для опису Web - сервісів. Простий протокол доступу до об'єктів (SOAP) є, заснованим на XML, стандартним мережевим протоколом для обміну повідомленнями між Web - сервісами (описи W3C).

1.4.6.2. Мова описів Web - сервісів

WSDL документ (мова описів Web - сервісів) визначає Web - сервіс, використовуючи приведені нижче основні елементи:

Таблиця 2. Деякі позначення елементів у мові описів Web – сервісів

Елемент

Визначає

<portType>

Постачальники повинні показувати, чи можливо ефективно управляти процесами GRID, включаючи модель на випадок збитків

<Message>

Повідомлення, використовувані в Web - сервісе. Абстрактне визначення передаваних даних

<Types>

Типи даних, використовувані в Web - сервісе. Надає інформацію про будь - які складні типи даних, вживаних в документах WSDL. У разі використання простих типів даних цей елемент не потрібний.

<Binding>

Протоколи з'єднання, використовувані в Web - сервісе. Описує, як викликається операція, за допомогою визначення протоколу і формату даних

<Port>

Визначає одиночну крайову крапку у вигляді адреси для з'єднання, тобто крайову точку з'єднання

<Service>

Визначає адреси портів з'єднання. Служба – сукупність мережевих крайових крапок або портів

WSDL документ містить описи елементів, що складаються з блоків types, message, portType, binding, і service elements, що описане в таблиці вище. Основна структура документа WSDL виглядає таким чином:

<definitions>

<types>

опис типів. . .

</types>

<message>

опис повідомлень . . .

</message>

<portType>

опис порту . . .

</portType>

<binding>

опис з'єднання . . .

</binding>

</definitions>

1.4.6.3. Web Services Inspection Language

Web Services Inspection Language (WSIL) – простий механізм виявлення Web - сервісів. WSIL – формат XML документа, створений для полегшення збору і виявлення Web - сервісів. Створений IBM і Microsoft і виданий в кінці 2001 року, WSIL є привабливим за рахунок своєї простоти, в порівнянні з UDDI, він простий і краще «піднімає» існуючі Web - сервіси. Модель WSIL децентрализована і «піднімає» існуючі Web - сервіси прямо на місці.

1.4.6.4. Universal Description, Discovery, and Integration

Universal Description, Discovery, and Integration (UDDI) – стандартний протокол опису Web - сервісів і протокол їх пошуку. Реєстр (UDDI) може містити метадані для будь - яких видів сервісів, разом з варіантами «якнайкращої практики», вже визначеними для сервісів, описаних за допомогою WSDL. За рахунок розбиття Web - сервісів на групи, що взаємодіють з категоріями і бізнес процесами, UDDI здатний ефективно шукати Web - сервіси. Специфікація UDDI визначає ієрархічну схему XML, що забезпечує модель для анонсування, перевірки і виклику інформації про Web - сервіси. Вибір ліг на XML, оскільки його формат представлення даних не залежить від платформи і відображає ієрархічні взаємозв'язки. У UDDI використовуються технології, засновані на загальних інтернет протоколах TCP/IP, HTTP, XML і SOAP. Існує 2 види UDDI реєстрів: публічні реєстри UDDI – службовці точками збору різних бізнесів, для повідомлення про їх сервіси, приватні реєстри UDDI, які роблять те ж саме але для організацій.

UDDI регістр містить наступні структурні типи даних:

  • businessEntity. XML - элемент верхнього рівня в бізнес запису UDDI. businessEntity збирає дані по запиту інформації об бізнес обслуговуванні, категорії продукту або виробництва, географічному положенні, а також контактну інформацію. Він підтримує пошук по організаціях, продуктах і географічному положенні.

  • businessService. Логічне продовження структури даних businessEntity і родоначальник структури bindingTemplate. businessService містить описову інформацію бізнес послуг з груп споріднених технічних послуг, включаючи ім'я групи, коротку інформацію про групу, опис технічної послуги, інформацію про категорію.

  • bindingTemplate. Логічне продовження структури businessService. bindingTemplate містить дані, що відносяться до додатків, які необхідно запустити або пов'язати з Web - сервісом. Ця інформація містить URL Web - сервіса, посилання на специфікації інтерфейсу і ін.

  • tModel. Містить описи специфікації Web - сервісів або систематики, які формують основу для технічних ідентифікаторів. Роль tModel полягає в наданні технічних специфікацій Web - сервісів, що дозволяє полегшити пошук Web - сервісів, сумісних з певною технічною специфікацією. Користувачі Web - сервісів можуть легко визначити інші сумісні Web - сервіси, грунтуючись на описі специфікацій в структурі tModel. Наприклад, для того, щоб послати биснес - партнеру RFP, запрошуюча служба повинна знати не тільки URL/местоположение служби, але і в якому форматі повинен бути посланий RFP, які протоколи використовувати, врахувати вимоги безпеки, яку форму відгуку має на увазі відсилання RFP.