Побудова СОА є ітераційним циклічним процесом, який включає такі етапи:
1. Створення моделі. Моделлю називають перетворення загального уявлення про цілі і завдання бізнесу в бізнес-проект або у формалізовану модель. Якщо модель підтримує достатній рівень формалізму, то вона може бути використана для оцінювання роботи бізнесу. Для цього у модель мають бути включені датчики, тобто ключові індикатори продуктивності (key performance indicators).
2. Компоновка системи. У компоновці системи беруть участь архітектор підприємства, бізнес-аналітик, архітектор, IT-директор. Разом вони транслюють модель у компоненти системи. Кінцева мета компоновки - створення програмної моделі.
3. Впровадження. На етапі впровадження створюються інформаційний простір і застосунки, які функціонують у цьому просторі.
4. Управління. На цьому етапі оцінюються результати, а одержані відомості використовуються для вдосконалення бізнес-проекту і моделей на наступній ітерації створення СОА.
У SOA Foundation передбачено створення логічної, програмної і фізичної моделей СОА. Логічну модель СОА (рис. 4.5) можна представити як сукупність множин, близьких за функціональністю послуг, об'єднаних корпоративною сервісною шиною (Enterprise Service Bus, ESB), а саме:
o сервіси взаємодії (Interaction services) - забезпечують зв'язок між застосунками і джерелами зовнішньої інформації. Джерелами можуть бути як люди, так і пристрої, зокрема дат
Рис. 4.5. Логічна модель СОА
чики RFID, промислові роботи, обладнання систем промислової автоматики та ін. Взаємодія може здійснюватися в рольовому контексті (role-sensitive context), де важливі не тільки параметри, які передаються, але і те, хто їх передає, що дає змогу здійснювати низку допоміжних бізнес-процесів, зокрема ау-тентифікацію, вибір джерел за пріоритетами;
o сервіси процесів (Process services) - реалізують логіку управління, зокрема організовують потоки бізнес-процесів (business process flows) і контролюють стан бізнес-транзакцій (business state machines: за IBM, машина станів - це керована подіями бізнес-транзакція, в якій зовнішні події переводять систему з одного дискретного стану в інший). Ці самі сервіси здійснюють оркестровку процесів;
o прикладні бізнес-сервіси (Business application services) - реалізують ядро бізнес-логіки, вони можуть бути декомпозовані на дрібніші послуги або, навпаки, зібрані в послуги вищого рівня. Прикладні послуги компонуються в бізнес-процеси за допомогою послуг процесів, але можуть викликатися і сервісами взаємодії;
o інформаційні послуги (Information services) - оперують даними бізнес-процесів і реалізують два типи функцій: 1) безпосереднє забезпечення бізнес-процесів даними, які можуть надходити за запитами з реляційних баз даних, різних каталогів баз даних, файлів систем, репозиторіїв XML та інших джерел; 2) інший тип функцій належить до управління життєвим циклом інформації і здійснює міграцію даних, наповнення сховищ даних, підтримку бізнес-аналітики й управління кон-тентом;
o сервіси доступу (Access services) - призначені для включення в сервісну архітектуру успадкованих застосувань. Це досягається шляхом вміщення цих застосувань у спеціальну "оболонку" і представлення їх у подальшому у вигляді послуг;
o сервіси для роботи з партнерами (Partner services) - поєднують властивості послуг взаємодії і послуг доступу, проте орієнтовані на роботу з підприємствами-партнерами;
o взаємодія між сервісами здійснюється за допомогою корпоративної шини ESB. Для створення ESB можуть бути використані різні технології, зокрема WebSphere Enterprise Service Bus. WebSphere ESB є архітектурним шаблоном, за допомогою якого може бути побудована інтеграційна платформа.
Крім основних послуг до складу логічної моделі SOA Foundation входять такі групи допоміжних підтримуючих послуг:
o сервіси розвитку й оптимізації бізнесу (Business innovation and optimization services) - включають інструменти і структури метаданих, призначені для кодування бізнес-проек-тів. До них належать також засоби моделювання бізнес-процесів, вимірювання метрик процесів та аналізу продуктивності;
o сервіси розробки (Development services) - складаються з архітектурних інструментів, інструментів для розробки і компоновки застосувань, методик, засобів верифікації, а також спеціалізованих механізмів публікації, необхідних для створення застосувань, призначених для роботи в середовищі СОА;
o сервіси менеджменту IT (IT Service Management) - слугують для моніторингу роботи інших сервісів, аналізу збоїв і вузьких місць, відновлення після збоїв і реалізації адміністративної політики;
o інфраструктура сервіси (Infrastructure services) утворюють ядро IT-середовища, в якому функціонують застосування СОА. За допомогою цих послуг здійснюється віртуалізація комп'ютерної платформи.
Логічна модель відображається у відповідну програмну і фізичну моделі СОА. Програмна модель СОА існує як набір ролей, завдань, правил кодування, мов програмування, яким потрібно слідувати та які потрібно використовувати у процесі створення ПЗ. Цю модель створюють, враховуючи такі вимоги: модель має підтримувати основні мови програмування, застосування і компонентні моделі, які вже використовуються, наприклад CICS, IMS, MQ, J2EE.NET, BPEL, XML, DB2, продукти Oracle, SAP. Модель має забезпечувати повторне використання компонентів відповідно до потреб бізнес-проектів.
В основі програмної моделі лежить концепція послідовного розкриття (progressive disclosure), яка припускає можливість використання програмних компонентів. У процесі створення програмної моделі реалізуються такі основні цілі: програмування логіки, призначеної для користувача взаємодії (презен-таційної логіки), управління бізнес-логікою, композиційною логікою і логікою взаємодії послуг. Для того, щоб реалізувати концепцію послідовного розкриття, сервіси всіх множин логічної моделі програмуються як сервісні компоненти (service components), які обмінюються сервісними даними (service data) та ініціюються засобами сервісної шини (service bus):
o сервісний компонент - фундаментальні будівельні блоки СОА;
o сервісні дані - нейтральні стосовно мов і технологій представлення даних. Сервісні дані можна описувати як документи або повідомлення, якими обмінюються послуги;
o сервісна шина - засоби для обміну даними між послугами і для забезпечення правил їх взаємодії.
Для реалізації програмної моделі мають бути виконані такі
дії:
1) моделювання бізнес-проекту з включенням основних індикаторів продуктивності;
2) перетворення моделі у програмну архітектуру;
3) кодування потоків процесів і машин станів;
4) пошук успадкованих застосувань і раніше створених послуг;
5) перетворення успадкованих застосувань на послуги і створення нових послуг;
6) визначення схем обміну даними і повідомленнями між послугами;
7) завдання потоків управління, політик і бізнес-правил;
8) компонування послуг;
9) тестування і впровадження.
Фізична модель слугує для опису компонентів операційного середовища реалізації СОА. Ця модель встановлює відповідність і потенційні відносини між компонентами цього середовища, але не є детальним архітектурним проектом.
Фізична модель подається у вигляді набору серверів, проте реально такий поділ на фізичні сервери не обов'язковий. Фізична архітектура, як і логічна архітектура, концентрується навколо корпоративної шини ESB. У свою чергу головну роль у реалізації ESB відіграє спеціалізований сервер ESB server.
Проте сервісна шина не зосереджена тільки в цьому сервері, вона є віртуальним утворенням і фізично розподілена по всій корпоративній мережі. ESB server здійснює управління шиною, але потоки даних при обміні між сервісами можуть його обходити.
Функції ESB може виконувати вся внутрішня корпоративна мережа з такими традиційними серверами, як сервер захисного екрану (firewall server), що відокремлює зону мережі від внутрішньої частини, захищеної від зовнішніх дій; буферний сервер (proxy server), що зберігає сторінки, розподіляє навантаження і виконує інші допоміжні функції; портальний сервер (portal server), який забезпечує взаємодію із зовнішніми користувачами; сервер процесів (process server), що відповідає за виконання бізнес-процесів; сервер застосувань (application server), що підтримує виконання застосувань і забезпечує прямий доступ до послуг; сервер інтеграції даних (information integration server), що містить дані, сховища даних і послуги бізнес-аналітики (business intelligence services); сервер модернізації (enterprise modernization); сервер безпеки (security server), який вирішує проблеми ідентифікації, авторизації та аудиту і реалізує інші дії щодо захисту послуг у межах SOA Foundation; сервер IT-менеджменту (management server), що відповідає за управління ІТ-інфраструктурою.
Створення динамічних бізнес-систем на базі СОА може надати імпульс розвитку таких перспективних технологій, як, наприклад, технологія самокерованого комп'ютингу (autonomic computing). Інфраструктура COA має бути побудована так, щоб вона сама могла виявляти власні несправності і за можли-востю виправляти їх, здійснюючи відповідну перебудову.
Для вирішення цього завдання SOA Foundation пропонує інструментальні засоби, що дають змогу реалізувати цикл моніторинг - аналіз - планування - виконання (Monitor- Analyze-Plan-Execute). Наявність такого циклу додає інфраструктурі СОА можливості елементів самоуправління.
Практичні аспекти сервісно-орієнтованої технології дають змогу розв'язати проблеми масштабованості, інтегрувати мережі передачі даних, спростити процедури проектування й управління мережами, а також створити інші розподілені застосування економічних інформаційних систем на основі вже наявних, прозоро взаємодіючи з ресурсами систем за допомогою прикладних програмних інтерфейсів і відкритих стандартів.
Система адресації в Internet
Висновки
Розділ 5. Автоматизація управління проектами на підприємствах
5.1. Сутність та поняття проекту
5.2. Автоматизована система управління ІТ-проектом
Програмний продукт управління проектами Office Project Standard-2007
5.3. Програмні продукти управління проектами
Програма Альт-Інвест 3.0
Програма COM FAR (версія 3.0)