Програма: " Інформаційні управляючі системи та технології "




Скачати 406,66 Kb.
Сторінка1/2
Дата конвертації01.02.2017
Розмір406,66 Kb.
  1   2





НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ

Києво-Могилянська Академія”


Магістерська програма:

Інформаційні управляючі системи та технології ”



Кваліфікаційна робота

на здобуття академічного ступеня магістра
на тему:
Використання сервісно-орієнтованої архітектури

для підтримки бізнес-процесів”

Виконав:


Студент ІІ року навчання

Михайлов Андрій


Науковий керівник:

доц.. С. С. Гороховський


Київ 2005

Зміст


1 Вступ

2 Сервісно-орієнтована архітектура (СОА)

2.1 Реалізації СОА

2.1.1 Веб-сервіси

2.1.1.1 Концепції

2.1.1.2 Безпека у веб-сервісах

2.1.1.3 Інструментальні засоби та реалізації

2.1.2 ebXML

2.1.2.1 Концепції

2.1.2.2 Інструментальні засоби та реалізації

2.2 Бізнес-процеси та веб-сервіси

2.3 Перспективи розвитку веб-сервісів

2.3.1 Порівняння можливостей веб-сервісів та ebXML,

2.3.2 Методика проектування програмних систем на основі веб-сервісів

3 Висновки

4 Джерела
Додатки.

  1. Глосарій термінів

  2. Приклад проектування

Реферат

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

Не важко передбачити, що багато в чому майбутнє інформаційних технологій пов‘язане з бізнесом, корпоративними (enterprise) системами. А отже, і надалі буде актуальною необхідність у розробці таких архітектур, моделей та інструментів, які будуть найкраще відповідати потребам бізнесу, промисловості, а також знаходженні способів використання вже існуючих програмних та концептуальних рішень для створення ефективних бізнес систем.

Одним з таких концептуальних рішень є Сервісно-Орієнтована Архітектура (СОА), яка може виступати архітектурою для реалізації та підтримки бізнес-процесів.

Ключові слова: сервісно-орієнтована архітектура, бізнес-процеси, веб-сервіси, ebXML, проектування,

Стор. 41, рис. 2



Перелік абревіатур

B2B (Business to Business)

B2C (Business to Customer)

BPMІ (Business Process Managing Initiative)

BPEL4WS ( Business Process Execution Language for Web Services)

EDI (Electronic Data Interchange)

SOA (Service Oriented Architecture)

SOAP( Simple Object Access Protocol )

UDDI ( Universal Dynamic Discovery and Integration )

UMM (UN/CEFACT Modeling Methodology)

W3C (World Wide Web Consortium)

WSDL(Web-Service Definition Language)

XML ( eXtended Markup Language )

1.Вступ
Інформаційні технології – одна з тих галузей, які можна сміливо вважати обличчям кінця ХХ та початку ХХІ століть. Від перших великих обчислювальних машин, програмування на рівні машинних команд та несміливих спроб створення локальних мереж галузь еволюціонувала, проходячи етапи заміни ламп на транзистори, а тих - на мікросхеми, машинних мов - на мову асемблер, асемблеру - на процедурні, функціональні, логічні мови, появу об‘єктних, а потім і об‘єктно-орієнтованих парадигм, до надшвидких мереж передачі даних. І якщо на початку свого виникнення інформаційні технології використовувалися здебільшого для розв‘язку великих наукових та промислових задач, то на даний момент здешевлення як обчислювальної техніки, так і програмного забезпечення, поширення комп'ютерних мереж, популяризація призвело до того, що важко знайти установу, організацію, підприємство, які не використовували б комп'ютери для своєї роботи.

Левову частку ринку інформаційних технологій займають так звані „корпоративні системи” (enterprise systems). Це пов‘язано як з інтенсивною комп'ютеризацією багатьох процесів, так і з появою нових доменів (е-commerce, e-business, e-learning etc.) Ці умови сприяють розвитку інструментальних та концептуальних засобів для проектування, реалізації та підтримки бізнес-систем. Одним із таких концептуальних засобів є сервісно-орієнтована архітектура (СOA).

СОА націлена на реалізацію зв‘язків у таких схемах бізнес взаємодії, як B2B ( Business to Business ) та B2C ( Business to Customer), в корпоративних системах вона є, фактично, проміжним програмним забезпеченням (middleware). Бізнес-процеси у бізнес-моделі відносно легко та природно можна представити сервісами у СОА. Вже існують певні рішення у цьому напрямку такі, як Business Process Modeling Notation ( BPMN – нотація для моделювання бізнес-процесів) від ініціативи Business Process Managing Initiative (BPMI), що дозволяє будувати специфікації сервісів на основі нотацій бізнес-процесів. Оскільки сама по собі СОА є абстракцією проектування, практичні аспекти, пов‘язані з СОА, розглядаються на прикладах існуючих поширених реалізацій СОА.

Фактично, на даний момент існують дві поширені та частково стандартизовані реалізації СОА – веб-сервіси та ebXML. Вони мають багато спільного, оскільки використовують досить велику кількість спільних специфікацій.

Розгляд СОА як архітектури для розробки проміжного програмного забезпечення як на рівні власне архітектури, так і на рівні реалізацій, порівняння її з іншими архітектурами проміжного програмного забезпечення, впорядкування інформації, а саме: стандартів, технічних рекомендацій, описів інструментарію для аналізу стану речей в цій царині та вироблення практичних рекомендацій з використання концепцій та інструментарію, який пропонує СОА для реалізації бізнес-процесів в корпоративних системах, і є метою даної роботи.

Коротко сформулюємо результати тези. Зроблено порівняльний аналіз реалізацій сервісно-орієнтованої архітектури, таких як ebXML та веб-сервісів, крім того проведене порівняння сервісно-орієнтованої архітектури з іншими архітектурами, які використовуються при проектуванні та розробці програмного забезпечення для підтримки бізнес-процесів. Розроблено методику проектування програмних систем, які є сумісними зі специфікаціями та стандартами електронного бізнесу ebXML, що забезпечує можливості повторного використання бізнес-об‘єктів, та з стандартами опису та передачі даних, які існують у веб-сервісах.

Вироблено рекомендації щодо застосування веб-сервісів для порівняно невеликих корпоративних систем, що відповідають поняттям малий і середній бізнес.
2. Сервісно-орієнтована архітектура
Для уникнення термінологічних конфліктів варто одразу з‘ясувати, який зміст вкладається у назву „Сервісно-орієнтована архітектура”. За визначенням, поданим у [Clements 96], „Архітектура ­­– це структура компонентів програми/системи, зв’язки між ними, принципи та ідеї (guidelines) які визначають їх дизайн та розвиток у часі”. Спираючись на це визначення, можна визначити СОА як сукупність незалежних компонентів (сервісів), які можуть бути розділені логічно та фізично, що можуть обмінюватись даними за визначеною наперед, стандартизованою схемою.

З іншого боку можна визначити СОА як розподілену архітектуру, яка повинна відповідати наступним ознакам:



  • Логічне представлення: Сервіс є одиницею логіки системи – логічним представленням певної операції бізнес-рівня (бізнес-процесу). На логічному рівні сервіс визначається у термінах операцій, які він виконує.

  • Орієнтація на обмін повідомленнями: Сервіс формально описується в термінах повідомлень, якими обмінюються агент провайдера та агент споживача, а не характеристиками самих агентів. Внутрішня структура агента, включаючи такі характеристики як мова, на якій він реалізований, структура обробки даних, структура баз даних, навмисне абстраговані в СОА. Фактично, користуючись СОА не потрібно знати, як саме агент реалізує сконструйований сервіс. Від цього можна одержати певні переваги у царині адаптації legacy-систем. Уникаючи будь-яких знань про внутрішню структуру агента, існує можливість „обгорнути” будь-який програмний компонент або прикладне застосування у код – обробник повідомлень, що дозволить дотримуватись та використовувати формальні описи сервісів.

  • Орієнтація на описи (Description orientation): Сервіси описуються мета даними, придатними для машинної обробки. Така форма опису підтримує відкриту природу СОА: тільки ті деталі, які доступні публічно та є необхідними для використання сервісу, повинні включатись у опис. Опис сервісу прямо чи не прямо повинен відображати його семантику.

  • Модульність (Granularity): Сервіси намагаються використовувати невелику кількість операцій для відносно складних та великих повідомлень. Це дозволяє зберігати логічну структуру та створювати ланцюжки пов‘язаних бізнес-процесів (orchestration).

  • Мережна орієнтація: Сервіси зазвичай розробляються для мережного використання, хоча це не є обов‘язковою вимогою. Як і більшість розподілених архітектур СОА може бути реалізована без використання мережі.

  • Платформна незалежність: Повідомлення у СОА повинні передаватися у платформно-незалежному, стандартизованому форматі; бажано, щоб існувало багато інтерфейсів для аналізу такого формату. Існуючі реалізації сервісно-орієнтованої архітектури використовують XML як формат обміну даними. Це пов‘язано з тим, що консорціум W3C активно просуває XML як стандарт представлення даних та обміну повідомленнями, крім того, для більшості сучасних мов програмування вже визначені механізми відображення типів даних в XML та розроблені аналізатори XML, що робить його стандартом де-факто, хоча сама по собі СОА не специфікує мову представлення – так само можна використовувати наприклад IDL.

Ключовим компонентом сервісно-орієнтованої архітектури, одиницею масштабності є сервіс. Сервіс – це абстрактний ресурс, який репрезентує потенціальну можливість виконання задач та певну функціональність з точки зору таких сутностей як провайдери та споживачі. Для використання сервіс повинен бути реалізований агентом провайдера [W3C WG 2004].
2.1 Реалізації СОА
Сервісно-орієнтована архітектура, як уже зазначалося раніше, є абстракцією проектування, практичні аспекти, пов‘язані з нею, розглядаються на основі її реалізацій.

Фактично, двома найпоширенішими реалізаціями СОА є веб-сервіси та ebXML. Невеличку плутанину у класифікацію вносить різне розуміння стандартів веб-сервісів (створенням яких займається низка різних організацій таких, як W3C, OASIS, робочі групи великих корпорацій, науковці, проекти з розробки програмного забезпечення з відкритим кодом), різними виробниками програмного забезпечення, що використовує веб-сервіси, або базується на них.


2.1.1 Веб-сервіси

2.1.1.1 Концепції

Визначення веб-сервіса: Веб-сервіс - це програмна система (software system), розроблена для підтримки інтероперабельних взаємодій через комп'ютерну мережу. Вона має інтерфейс, описаний в придатному для машинної обробки форматі ( конкретно WSDL). Інші системи взаємодіють з веб-сервісом у спосіб, визначений описанням його інтерфейсу, використовуючи повідомлення SOAP, які зазвичай передаються через HTTP з використанням XML серіалізації в поєднанні з іншими веб-стандартами. Веб-сервіс є абстрактною нотацією, і має бути реалізований конкретним агентом. Агент являє собою конкретне програмне або апаратне забезпечення, яке здатне посилати та отримувати повідомлення [W3C WG 2004]. Таке розділення опису та реалізації дає можливість повторного використання описів веб-сервісів та створення наборів, і, звичайно, можливість змінювати агента без зміни опису веб-сервіса.

В одних джерелах веб-сервіси позиціонуються як новий, еволюційний крок в історії розвитку Інтернет, як технологія, яка повинна перетворити його з мережі, де люди обмінюються повідомленнями, у мережу, де повідомленнями обмінюються програми, створити новий рівень інтеграції [DevelopMentor 2002]. Інші відводять веб-сервісам простішу роль - технологія, яка дозволяє виконувати віддалені виклики процедур простіше ніж, наприклад, CORBA або DCOM.

Ближчим до істини є перший погляд, дійсно, найпоширенішим використанням веб-сервісів є зв‘язування програмних систем. Технології, які використовуються у веб-сервісах, дозволяють абсолютно природним чином використовувати як середовище передачі даних прості протоколи такі, як HTTP, SMTP.

Можна визначити щось на кшталт стеку протоколів веб-сервісів – перелік технологій, які використовуються при створенні веб-сервісів. Технології, зображені на мал. 1 впорядковані знизу вгору, від найнижчого рівня (транспорт), до найбільш абстрактного (директорії). Таке впорядкування, звичайно ж, є умовним, але дозволяє проілюструвати набір технологій.




Мал. 1. „Стек протоколів” веб-сервісів

  • HTTP, SMTP – поширені Інтернет-протоколи, зазвичай використовуються як транспорт для SOAP повідомлень. Плюсом використання цих протоколів є їх поширеність: практично кожен комп'ютер має клієнта, який може обробити HTTP або SMTP повідомлення.

  • XML – використання XML для представлення даних є „візитною карткою” веб-сервісів. SOAP, WSDL є фактично підмножинами XML. XML є мовою розмітки, яка має багато механізмів розширення. на відміну, наприклад, від HTML. Він дозволяє описувати як елементи даних, так і структури, в які ці дані групуються.

  • XML Schema – якщо XML визначає структуру документу, порядок слідування елементів, то XML Schema дозволяють визначити типи даних, допустимі значення елементів. Крім того XML Schema можна використовувати для опису семантики обробки елементів документу. Однією з дуже важливих можливостей, які надають XML Schema, є можливість визначення відображення (mapping) типів даних XML в систему типів мови, яка використовується для реалізації агента і зворотного відображення. На жаль, на практиці таке відображення не завжди виходить однозначним і способи реалізації відрізняються в залежності від виробника інструментарію.

  • SOAP – протокол, який визначає механізм підключення до веб-сервісів. Специфікація SOAP визначає структуру повідомлення, яке використовується для обміну форматованими XML документами, механізми параметризації, кодування, певні механізми обробки помилок. Існує можливість для використання SOAP як протоколу передачі віддалених викликів процедур. [Бекет 2004]

  • WSDL – XML граматика, яка використовується для опису всіх аспектів взаємодії з веб-сервісом, починаючи від опису транспортних протоколів, вигляду повідомлень та типів даних, які використовуються в них, і закінчуючи визначенням інтерфейсу сервісу. Для коректної взаємодії агента користувача і агента провайдера вони повинні користуватися одним і тим самим WSDL описом.

  • UDDI - протокол на основі SOAP, який використовується для доступу до репозиторіїв метаданих веб-сервісів. Основною перевагою при використанні репозиторіїв метаданих є те, що клієнт, який не знає нічого про місцезнаходження сервісу або навіть про його інтерфейс, може отримати доступ до сервісу. Звичайний сценарій при роботі з репозиторієм виглядає наступним чином:

      • Клієнт надсилає в репозиторій запит на отримання інформації про сервіс певного виду.

      • Репозиторій метаданих виконує пошук по отриманих параметрах, і, у разі знаходження відповідних даних, відправляє клієнту WSDL опис та інформацію про місцезнаходження сервісу.

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

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


2.1.1.2 Безпека у веб-сервісах
В сучасних програмних системах аспект безпеки є одним з ключових і найбільш необхідних. У випадку ж систем, які використовуються у такому домені як E-Business, необхідність наявності серйозних засобів безпеки є життєво важливим. Багато в чому розвиток таких систем та ідеї глобального електронного ринку в цілому залежать від того, наскільки вдало будуть реалізовані аспекти безпеки, оскільки кожен учасник бізнес-взаємодії має бути впевнений у надійності і безпечності ведення бізнесу в електронній формі.

Системи безпеки веб-сервісів мають відповідати офіційним та де-факто стандартам, які існують у царині комп‘ютерної безпеки ( цифрові підписи, схеми кодування), для уможливлення їх використання у країнах, де існують відповідні законодавчі акти, які регламентують вимоги до систем безпеки електронного обміну даними (такі акти зазвичай ґрунтуються на міжнародних загальноприйнятих стандартах). В той самий час системи та механізми безпеки, що використовуються у веб-сервісах, повинні бути достатньо дешевими для того, щоб представники малого і середнього бізнесу могли собі дозволити їх впровадження та підтримку.

На даний час механізмом, який використовується для забезпечення безпеки веб-сервісів, є механізм стандартних розширень для протоколу SOAP. Документом, яким регламентуються механізми безпеки у веб-сервісах є [WSS 2004]. Використовуючи розширення SOAP можна реалізувати різні моделі безпеки (наприклад Kerberos, SSL), крім того їх специфікація достатньо гнучка, що дозволяє реалізовувати на її основі системи, використовуючи різні формати маркерів доступу (тут і надалі під маркером доступу буде розумітися набір ідентифікаторів, які використовуються для авторизації сторони, яка відсилає повідомлення, де ідентифікаторами можуть бути ім’я, ключ, ID, група, привілеї), різні домени довіри (trust domains), різні формати підписів та різні технології криптування.

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


Модель безпеки для повідомлень. Модель безпеки для повідомлень - це абстрактна модель, яка описує методи використання маркерів доступу і цифрових підписів для захисту та аутентифікації SOAP повідомлень. Маркери доступу пред‘являють ідентифікатори (claims), а отже, можуть використовуватись для зв‘язування аутентифікаційних секретів або ключів з сутностями безпеки. Організація може підтвердити відповідність ідентифікаторів у маркері доступу, використовуючи свій ключ для підписування, або закодування маркеру доступу, таким чином дозволяючи аутентифікувати ідентифікатори. Прикладом такої організації безпеки повідомлень можуть бути сертифікати X.509, у яких ідентифікатори зв‘язані з публічним ключем.

Контроль цілісності повідомлення забезпечується використанням XML Signature спільно з маркерами доступу. Підписи (тут і надалі під підписом розуміється значення, згенероване певним криптографічним алгоритмом, яке зв‘язується з даними таким чином, щоб отримувачі документа могли використати це значення для перевірки того, що дані не були змінені і/або походять від підписувача повідомлення), необхідні для підтвердження походження повідомлення та його цілісності. Підписи можуть вираховуватись і перевірятись за симетричним алгоритмом, коли один і той самий ключ використовується для підпису і для перевірки, або за асиметричним, коли для підпису і для перевірки використовуються різні ключі (публічний і захищений). Крім того, підписи використовуються організаціями для засвідчення знання ключа (що зазвичай походить від третьої сторони), який використовується для аутентифікації ідентифікаторів у маркері доступу і, відповідно, зв‘язування їх з повідомленнями, які вони відсилають. При цьому для забезпечення цілісності повідомлення може використовуватись більше ніж один підпис, що може бути необхідним, коли у взаємодії беруть участь більше ніж дві сторони (агента, ролі).

Для забезпечення конфіденційності повідомлення використовуються механізми XML Encryption та маркери доступу. Так само як і у випадку з підписами, для забезпечення конфіденційності може використовуватись більше ніж одна операція кодування у випадку, коли у взаємодії беруть участь більше ніж дві сторони.
01

02

03

04

05

06 FHUIORv...

07

08

09

10

11

12

13

14 LyLsF0Pi4wPU...

15

16

17 DJbchm5gK...

18

19

20

21

22

23

24

25

26

27 QQQ

28

29
Приклад 1. Використання маркеру доступу та підпису для захисту повідомлення
Наведене SOAP-повідомлення є типовим прикладом використання механізмів захисту повідомлень. У даному повідомленні використовується закодований кодуванням base64 підпис, генерований за симетричним алгоритмом. Отримувач має використати той самий алгоритм для валідації підпису, що дозволить йому аутентифікувати відправника.

Варто трошки детальніше переглянути повідомлення для роз‘яснення механізмів, що використовуються.

Рядки 1-2 містять початок конверту SOAP. Третій рядок розпочинає SOAP заголовок. Рядки 4-24 містять опис заголовку , який визначає необхідну отримувачу інформацію про засоби безпеки [WSS 2004].

Рядки 5-7 визначають маркер доступу (у даному випадку формат маркера доступу є зовнішнім по відношенню до повідомлення).

Рядки з 8 по 23 визначають цифровий підпис, який має забезпечувати цілісність підписаних елементів. В даному прикладі для опису підпису використовується специфікація XML Signature. Рядки 9-16 описують, які частини повідомлення є підписаними, і який спосіб нормалізації даних повинен використовуватись для підписаних даних. У данному випадку підписане тількі тіло повідомлення, але можна підписувати усі критичні елементи повідомлення.

Зважаючи на те, що веб-сервіси зазвичай використовуються як проміжний шар при взаємодії програмних ситем, крім механізмів безпеки, які можуть використовуватися на рівні веб-сервісів для захисту повідомлень (використання маркерів доступу, підписів для забезпечення цілісності повідомлення, криптування для забезпечення конфіденційності, їх комбінацій) варто використовувати і додаткові механізми безпеки на більш високих рівнях.


2.1.1.3 Інструментальні засоби та реалізації

Для реалізації вищенаведених технологій та протоколів розроблена велика кількість програмних засобів. Основними виробниками програмного забезпечення, яке підтримує веб-сервіси, є такі компанії як BEA systems, IBM, Sun Microsystems, Oracle, Microsoft.

Оглянемо продукти, які пропонують ці компанії.

BEA systems

BEA systems як компанія, яка є автором мови WSDL та співавтором багатьох інших стандартів, існуючих у царині веб-сервісів, є активним гравцем на ринку веб-сервісів. Основним продуктом, який вона пропонує для розробки та розгортки веб-сервісів, є сервер WebLogic, до складу якого входить інтегроване середовище розробки (IDE – Integrated Development Enviroment) WebLogic Workshop. WebLogic дозволяє розробляти агенти провайдерів на основі технології J2EE Proffessional, крім того WebLogic Workshop надає можливість використовувати візуальне програмування для розробки веб-сервісів. WebLogic забезпечує автоматичне перетворення даних між XML та Java.


  1   2


База даних захищена авторським правом ©uchika.in.ua 2016
звернутися до адміністрації

    Головна сторінка