Інтеграція OWSM і BPEL

Вільям Батерст

Вступ

Сервіс-орієнтована архітектура (SOA - Service Oriented Architecture) - це архітектура програмного забезпечення, в якій панують прозорість розташування (location transparency) і інтероперабільность (interoperability - здатність до взаємодії). Компанії розглядають SOA, як засіб для інтеграції систем і процесів організацій і партнерів. Щоб забезпечити масштабування, злагодженість та ефективність функціонування, SOA необхідні деякі ключові компоненти. У цій статті описуються два таких найважливіших компонентів SOA: Oracle BPEL Process Manager і Oracle Web Services Manager.

BPEL виступає як стандарт компонування безлічі синхронних і асинхронних сервісів в спільно працюють, погоджені потоки процесів. Це дає перевагу підприємствам, які бажають реалізувати свої бізнес-процеси стандартним і стерпним способом, уникаючи заданих Вендом правил, які не завжди здійсненні.

Oracle BPEL Process Manager (Oracle-менеджер BPEL-процесів) забезпечує легке в використанні та надійне рішення для проектування, розгортання та управління BPEL бізнес-процесами. Він включає до свого складу JDeveloper BPEL Designer, який дозволяє використовуючи BPEL, моделювати, редагувати, і проектувати бізнес-процеси. Ядро BPEL-механізму забезпечує найрозвиненішу, масштабовану і надійну реалізацію доступного сьогодні BPEL-сервера. BPEL здійснює управління бізнес-процесами, як SQL - управління даними.

Сущесвует потреба убезпечити ці потоки бізнес-процесів. Наприклад, бізнес-процес може взаємодіяти з бізнес-партнером по Інтернету. Має бути запропонована політика безпеки, щоб гарантувати безпеку корпоративних даних.

Oracle Web Services Manager (OWSM - Oracle-менеджер Web-сервісів) дозволяє компаніям визначити політику (образ дій), яка керує діями web-сервісів, як-то: доступ, авторизація, реєстрація, балансування навантаження, а потім згорнути (wrap) цю політику в web-сервіси. Також OWSM здійснює моніторинг статистики, щоб забезпечити якість обслуговування, тривалість роботи, виявлення загроз безпеки, і показує її на своєї панелі. Ця функціональність тепер може бути застосована до бізнес-процесів, керованим BPEL.

Захист потоків BPEL-процесів

Однією з можливостей Oracle Web Service Manager Оракула є здатність захистити потоки BPEL-процесів. OWSM захищає BPEL, використовуючи PEP (Gateway Policy Enforcement Point - Шлюзова точка втілення політики), до якого перехоплюються SOAP-запити і видаються відповіді в різні точки BPEL-процесу. Даайте розглянемо демонстраційний приклад Loanflow, наведений у підручнику BPEL 101 Tutorial, щоб проілюструвати, як OWSM захищає BPEL-процеси. BPEL-приклад Loanflow демонструє автоматичне отримання банківської позики:

Заявник представляє банку на розгляд свою заявку.

Банк проводить кредитна перевірку заявника позики і отримує оцінку його кредитоспроможності.

Якщо ця оцінка гарна, то банк направить заявку двом кредитним бюро і вибере найкраще для клієнта пропозицію.

В цьому демонстраційному прикладі "оцінка кредитоспроможності" - синхронний Web-сервіс. BPEL-процес буде чекати відповідь від цього кредитного сервісу перед переходом до наступних кроків. Потім демо-приклад починає паралельний діалог з двома асинхронними сервісами обробки позик (Star Loan і United Loan).

Діаграма 1. Демонстраційний BPEL-приклад Loanflow

Цей сценарій цікавий тим, що в ньому змодельований бізнес-процес, який звертається з кон'юнктурні даними (наприклад, номер [картки] соціального забезпечення), але цей бізнес-процес не захищений. Ми ж бачимо, що:

Ні ніякої авторизації або аутентифікації, обов'язково подаються кожної заявкою.

Номер Social Security ([картки] соціального забезпечення) заявника представлений у відкритому коді.

Дуже важливою є перевірка достовірності повідомлення. Наприклад, може статися, що будь-яка позика запитує понад сто тисяч доларів.

До BPEL web-сервісів можна звернутися по інтернету. Якщо запит спочатку проходить шлюз, то вони повинні бути віртуалізувати і вже доступні.

Ні ніякої журналізацію або подання трафіку повідомлень протягом всього потоку.

Цей приклад показує наскільки потужною може стати комбінація BPEL і OWSM. OWSM підсилює BPEL за рахунок:

Контролю Доступу (Access Control)

BPEL-процес може бути захищений, якщо перед ним поставити шлюз. Тільки Аутентифіковані/авторизовані (authenticated/authorized) користувачі можуть почати потік [одержання] позики. Наприклад, якщо перед BPEL-процесом знаходиться COREid-шлюз політики аутентифікації/авторизації (authentication/authorization), то він дозволить прохід тільки привілейованим користувачам. Контроль доступу може також бути застосований для окремих сервісів BPEL-процесу.

часткового/повного шифрування сервісних запитів (Partial/full encryption of service calls)

Клієнт, посилає запит до BPEL-процесу, може надіслати зашифроване повідомлення, і BPEL-процес повинен бути здатний розшифрувати це повідомлення в певній точці BPEL-процесу, коли це буде необхідно. BPEL-процес повинен помістити шлюз перед сервісом, який повинен отримати розшифроване повідомлення.

Клієнт має можливість надіслати зашифроване повідомлення, яке повинно бути розшифровано в деякий момент в BPEL-процесі. Якщо повернутися до демо-приміром Loan, клієнт може надіслати зашифроване повідомлення BPEL-процесу. Web-сервіс Loan Flow BPEL-процесу отримує зашифрований запит. На наступному кроці потрібно викликати сервіс, який дасть кредитну оцінку. Тому бажано помістити шлюз, який може розшифрувати повідомлення, перед цим - Credit Rating Service - Сервісом.

DMZ-віртуалізації асинхронних BPEL-сервісів (DMZ Virtualization of asynchronous BPEL services)

Архітектори служб безпеки та web-сервісів часто хочуть віртуалізувати повернення (callback) до BPEL-процесів. Це означає те, що клієнт не повинен безпосередньо спілкуватися з BPEL-процесом. Замість цього, повернення повинні проходити через якийсь модуль доступу (proxy) і тільки потім бути відповідно маршрутизувати (route). Для подібних запитів OWSM може встановити режим шлюзу (Gateway mode) і proxy-модуль. Одночасно OWSM також може виконувати і інші інтелектуальні завдання обробки, як-то: перевірка достовірності повідомлень (message validation), реєстрація (logging) і застосування додаткових політик безпеки (extra security policies).

Моніторингу (Monitoring)

OWSM-шлюз, який захищає BPEL-процес, посилає свої дані OWSM-монітора. ІТ-службовці можуть використовувати монітор, щоб побачити в реальному часі в загальний стан, продуктивність і безпеку BPEL-процесу. Наприклад, за діаграм аутентифікації/авторизації вони дізнаються, які BPEL-процеси вчинили спроби несанкціонованого доступу. Використовуючи монітор, ІТ-службовці можуть задати правила моніторингу та автоматично отримувати Алерт-сигнали по електронній пошті, коли мають місце певні стану.

Аналіз бізнес-процесів

Перший крок до забезпечення безпеки бізнес-процесу полягає в аналізі бізнес-процес на предмет слабкості його безпеки. У разі демо-прикладу Loanflow ми відзначили кілька можливих слабкостей та місць, де були б корисні аудит і моніторинг. Така діаграма являє приклад того, як в демо-прикладі Loanflow може бути розгорнутий OWSM, щоб забезпечити безпеку цього бізнес-процесу:

Висновок

Коли організація починає реалізовувати SOA, вона виставляє свої бізнес-функції як сервіси. Ці сервіси, подібно до сервісу оцінки кредитоспроможності, потім спільно використовуються в потоках бізнес-процесів. Oracle надає два ключових інструментальних кошти, щоб реалізувати і розгорнути SOA: BPEL і OWSM.

Кожен інструмент грає свою роль: BPEL використовується для оркестровки (orchestrate) бізнес-потоків. Наприклад, якщо будуть потрібні сервіси, типу Credit Rating, Star Loan і United Loan, він оркестру їх у бізнес-процес. OWSM використовується для забезпечення безпеки і моніторингу кожного з цих сервісів в потоці бізнес-процесу. Природне взаємодію цих двох інструментальних засобів призводить до комплексних рішень, забезпечуючи оркестровку і безпеку.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://citcity.ru/