1. Серія контенту:
2. Цей контент є частиною серії: Огляд термінології SOA
3. організаційне зауваження
4. сервіс
5. архітектура
6. архітектура підприємства
7. Сервіс-орієнтована архітектура
8. Еталонна модель SOA foundation
9. Малюнок 1. Еталонна модель SOA foundation
10. Структура рішень SOA
11. Малюнок 2. Структура рішень SOA
12. управління
13. управління
14. ІТ-управління
15. SOA-управління
16. Життєвий цикл
17. Життєвий цикл SOA
18. Малюнок 3. Життєвий цикл SOA
19. Орієнтація на бізнес
20. Компонентне подання бізнесу
21. Бізнес-моделювання
22. Бізнес процес
23. Бізнес-діяльність і завдання
24. Моделювання бізнес-процесів
25. Завдання для людей
26. BPEL
27. галузі
28. Управління бізнес-процесами
29. Висновок
30. Подякою
31. Ресурси для скачування

Огляд термінології SOA

Серія контенту:

Цей контент є частиною # з серії # статей: Огляд термінології SOA

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Обзор+терминологии+soa

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Огляд термінології SOA

Слідкуйте за виходом нових статей цієї серії.

Семантика важлива в будь-якій області, а особливо - в сервіс-орієнтованої архітектури (Service-oriented architecture - SOA). Оскільки SOA пов'язує між собою команди і організації, узгоджена термінологія надзвичайно важлива. У цій серії статей ми проводимо ознайомлювальний тур по SOA, визначаючи терміни і стоять за ними ідеї. Тут ви вивчите термінологію, достатню для спілкування в області SOA. Ви зрозумієте, чому кожен з термінів важливий для SOA, що він означає в даному контексті, з якими стандартами він пов'язаний і чим відрізняється від інших термінів.

організаційне зауваження

Перераховані нижче терміни не збудовані за алфавітом, так само як і за ступенем важливості. Вони організовані скоріше в блоковому стилі. Ми починаємо з "сервісу", оскільки це фундаментальне поняття в рамках SOA. На цьому понятті ми будуємо визначення таких термінів, як "архітектура", "управління" і "бізнес". У багатьох випадках ми розбиваємо об'ємні терміни на їх складові компоненти.

сервіс

Сервіси є, безсумнівно, серцем сервіс-орієнтованої архітектури: сам термін сервіс широко використовується. Однак різні люди розуміють його по-різному, а тому питання "Що таке сервіс?" часто призводить до тривалих суперечок. Мені доводилося чути, як люди розмовляють про бізнес-задачах, бізнес-сервісах, функціях додатків, технічних сервісах і сервісах з області інфраструктури. Дозвольте, я дам вам визначення, засноване на IBM Rational® Method Composer Plug-in for SOA Governance і на IBM Rational® Unified Process for Service-Oriented Architecture. Додаткову інформацію ви знайдете в ресурсах .

"Сервіс - це видимий ресурс, що виконує повторювану завдання і описаний зовнішньої інструкцією".

Визначити поняття сервісу на початку статті непросто, оскільки воно тягне за собою багато інших визначень. Наприклад, вам може здатися, що наведене вище визначення занадто технічне. Однак враховуйте, що важливо не зациклюватися на формальному визначенні сервісу, а сфокусувати увагу на ключових ідеях, які за ним стоять, таких як:

• Орієнтація на бізнес: сервіси орієнтуються не на можливості ІТ, а на потреби бізнесу. Орієнтація сервісів на бізнес підтримується аналізом сервісу і технікою проектування.
• Інструкції: сервіси самодостатні і описуються в термінах інтерфейсів, операцій, семантики, динамічних характеристик, політик і властивостей сервісу.
• Повторне використання: повторне використання сервісів забезпечується їх модульним плануванням.
• Угоди: сервісні угоди укладаються між сутностями, які називали постачальниками і користувачами. Ці угоди грунтуються на сервісних інструкціях і не впливають на реалізацію самих сервісів.
• Розміщення і видимість: протягом свого життєвого циклу сервіси розміщуються і стають видимі завдяки сервісним метаданих, реєстрів і сховищ.
• Агрегація: на слабо пов'язаних сервісах будуються об'єднують бізнес-процеси і складні додатки для одного або декількох підприємств.

Ці характеристики в сукупності показують, що SOA має справу не тільки з "технологіями", але і з потребами і потребами бізнесу.

Також важливо враховувати, що не всі є сервісом. Є такі ІТ-функції, які розміщувати в якості сервісів сенсу немає. Такі аналітичні техніки, як IBM Service-Oriented Modeling and Architecture (SOMA), допомагають визначати відповідність сервісів перерахованим вище ідеям. Всі ці моменти (включаючи всі виділені терміни з даного розділу) ми детально розглянемо в даній статті.

архітектура

Як і для сервісів, для архітектури теж важко підібрати задовольняє всіх визначення. Однак, на відміну від сервісів, коли люди говорять про SOA, про архітектуру часто забувають, і даремно! По суті, архітектура підприємства і сервіс-орієнтована архітектура мають спільну мету - підтримання бізнесу за допомогою інтегрованої ІТ-стратегії. Архітектори масштабу підприємства, наприклад, є ключовим елементом для успіху SOA, оскільки саме вони розраховують стратегічну еволюцію ІТ-систем підприємства, грунтуючись на що розвиваються потребах бізнесу.

На форумі Open Group Architecture Forum (TOGAF) є два визначення архітектури в залежності від контексту:

1. "Формальний опис або детальний план системи на рівні компонентів для керівництва в процесі її створення.
2. Структура компонентів, їх взаємозв'язку, принципи і напрямки розвитку, що визначають їх розробку і еволюцію. "

Ці два визначення критично важливі для розуміння "A" (архітектури) з абревіатури SOA. Зазирнувши глибше, ми бачимо також, що архітектура необхідна для наступного:

• Розробка і моделювання на різних рівнях абстракції
• Відділення інструкції від реалізації
• Побудова гнучких систем
• Перевірка на відповідність бізнес-вимогам
• Аналіз обсягу змін при появі нових вимог
• Перевірка на відповідність правилам

архітектура підприємства

Ось визначення з Вікіпедії:

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

Головна мета створення архітектури підприємства - узгодження бізнес-стратегії і вкладень в сектор ІТ. Таким чином, архітектура підприємства дозволяє від загальної бізнес-стратегії перейти на рівень нижче, до лежачої в її основі технології. "

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

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

Орієнтація на сервіси

Як написано в технічному огляді IBM SOA foundation, "... орієнтація на сервіси - це шлях інтеграції бізнесу як набору пов'язаних сервісів." Більше інформації про IBM SOA foundation ви знайдете в ресурсах .

Ключове слово тут - "бізнес". Орієнтація на сервіси, наприклад, дозволяє гнучко реалізовувати і пов'язувати сервісами бізнес-процеси з однієї галузі бізнесу (ПРО), різних ПРО, а також з бізнес-партнерами.

Еталонна модель SOA foundation

IBM SOA foundation містить еталонну модель SOA, показану на малюнку 1, в якій відображено ключові характеристики, необхідні для підтримки сервіс-орієнтованої архітектури.

Оскільки сама модель сервіс-орієнтована, вона дозволяє здійснювати поступове прийняття SOA при виникненні у бізнесу нових потреб, починаючи з маленьких проектів і з часом інтегруючись у всю організацію. Більш детальну інформацію про SOA foundation можна знайти в ресурсах .

Малюнок 1. Еталонна модель SOA foundation

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

У IBM SOA foundation SOA визначена наступним чином:

"Сервіс-орієнтована архітектура (SOA) - архітектурний стиль для створення ІТ-архітектури підприємства, що використовує принципи орієнтації на сервіси для досягнення тісного зв'язку між бізнесом і підтримують його інформаційними системами."

SOA володіє наступними характеристиками:

• Вона покращує взаємозв'язок між архітектурою підприємства і бізнесом.
• Вона дозволяє з наборів інтегрованих сервісів створювати складні додатки.
• Вона створює гнучкі бізнес-процеси.

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

Структура рішень SOA

Структура рішень SOA, показана на малюнку 2, являє собою еталонну модель SOA, яка відображатиме концептуальне (високорівневе) пристрій рішень SOA.

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

Вона не залежить від технологій, на яких побудована. Як ви побачите в розділі "Модельна керована архітектура" (Model-Driven Architecture - MDA) у другій статті даної серії, цей поділ важливо.

Малюнок 2. Структура рішень SOA

Структура складається з 5 функціональних шарів (знизу вгору):

• Експлуатаційні системи: представляють існуючі ІТ-рішення, показують цінність і важливість вкладень в ІТ для SOA і можливість їх використання.
• Сервісні компоненти: реалізують сервіси, при цьому можуть використовувати одне або більше додатків з рівня експлуатаційних систем. Як ви бачите з моделі, у користувачів і бізнес-процесів, на відміну від сервісів, немає прямого доступу до компонентів. Існуючі компоненти можуть бути повторно використані або, якщо вони для цього підходять, впроваджені в SOA.
• Сервіси: представляють розміщені в середовищі сервіси. Ці сервіси є керованими видимими сутностями.
• Бізнес-процес: представляє операційні програми, що створюють бізнес-процеси у вигляді хореографії сервісів.
• Користувачі: представляють канали, які використовуються для доступу до бізнес-процесів, сервісів і додатків.

управління

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

Цей розділ містить визначення з IBM Rational Method Composer Plug-in for SOA Governance. Тут визначаються терміни "управління", "ІТ-управління", "SOA-управління", а також визначається різниця між управлінням, керівництвом і відповідністю. Тут же описуються проблеми, що стоять перед SOA-керуванням. Більш детальну інформацію про Rational Method Composer ви знайдете в ресурсах .

управління

"Під управлінням ми маємо на увазі:

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

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

Частиною будь-якого управлінського рішення є відповідність організаційним правилам відповідності. Відповідність - це документований доказ того, що управління є і реалізується: рішення документуються, а правила прийняття рішень дотримуються. "

ІТ-управління

"ІТ-управління стосується тих моментів управління, які відносяться до процесів в сфері інформаційних технологій в організації та того, наскільки ці процеси відповідають цілям бізнесу."

ІТ-управління може бути описано як призначення прав на прийняття рішень і засобів оцінки ІТ-процесів.

SOA-управління

"SOA-управління - це надбудова над ІТ-управлінням, орієнтована на сервіси та інші продукти життєвого циклу SOA."

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

"SOA-керування призначене для вирішення наступних проблем:

• Які нові організаційні посади і структури потрібні для ідентифікації, розробки і спільного використання сервісів?
• Які метрики підтримують вкладення коштів, обслуговування, життєздатність і спільне використання сервісів?
• Як бізнесу вирішити питання про інвестиції в створення і обслуговування сервісів?
• Що таке зрілість виробництва в області сервіс-орієнтованості?
• Які необхідні освіту, навчання або наставництво? "

Життєвий цикл

Життєвий цикл сервісу

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

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

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

Наприклад, SOA-управління може визначати такі сервісні стану: ідентифіковане, профінансоване, специфіковану, запрограмоване, схвалене, робоче, опубліковане, схвалене до вилучення, вилучене.

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

Життєвий цикл SOA

У визначенні життєвого циклу SOA IBM SOA foundation відзначає чотири фази:

• Модель складається з бізнес-аналізу і розробки (вимоги, процеси, цілі, ключові показники продуктивності) та ІТ-аналізу і розробки (визначення і специфікація сервісів).
• Збірка складається з програмування сервісів і побудови складних додатків.
• Розміщення складається з розміщення додатків і засобів часу виконання, таких як Enterprise Service Buses (ESB).
• Керівництво складається з підтримки операційного середовища, моніторингу продуктивності сервісів і стеження за дотриманням сервісних політик.

Певні вище SOA-управління та процеси підтримують ці чотири фази. Це відображено на малюнку 3.

Малюнок 3. Життєвий цикл SOA

бізнес

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

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

Орієнтація на бізнес

Ключ до успіху SOA лежить в повторному використанні існуючих ІТ-ресурсів, наприклад, успадкованих додатків. Однак SOA, на відміну від сервісів, побудованих на ізольованих інформаційних системах, дозволяє бізнесам зосередити свої зусилля на підтримуючих їх потреби або процеси сервісах - наприклад, операції сервісів можуть відповідати завданням бізнесу. Ця орієнтація на бізнес веде до більш тісного зближення й полегшення зв'язку між бізнесом та ІТ. В наступній частині статті, щоб зрозуміти, як можна перетворити бізнес-моделі в ІТ-моделі і як можна підвищити їх функціональність, ми розглянемо різні підходи до SOA-аналізу та розробки: "зверху вниз", "знизу вгору" і "збіжність в центрі ".

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

Компонентне подання бізнесу

IBM Component Business Model® - стратегічний метод, що дозволяє компаніям фокусуватися на своїх ключових сферах діяльності - на тому, чим компанія відрізняється від своїх конкурентів, на відстеженні споживання ресурсів і встановлення кращого зв'язку бізнесу зі сферою ІТ. В ресурсах ви знайдете додаткову інформацію про Component Business Model. За допомогою та завдяки орієнтації на сервіси досягається інтеграція та взаємодія цих компонентів бізнесу, а також гнучкість, завдяки якій можна проводити аутсорсинг компонентів: у кожного з компонентів бізнесу є своя унікальна мета, а повідомляються вони між собою за допомогою набору бізнес-сервісів, які вони постачають інших компонентів або отримують від інших компонентів. Це можна розглядати як частину "бізнес-архітектури".

Бізнес-моделювання

Бізнес-моделювання визначається IBM Rational Unified Process® наступним чином:

"Дисципліна Rational Unified Process Business Modeling надає точне керівництво для опису за допомогою набору підходів і технік, на різних рівнях формалізації" поточного "або" бажаного "бізнесу".

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

SOA - довгострокова стратегія реорганізації бізнесу та ІТ-систем, мета якої - швидке реагування на зміни. В ресурсах є посилання на журнал IBM Systems (том 44, номер 4), що розповідає про SOA, в якому ви знайдете більш докладний розгляд пов'язаних з бізнесом сторін сервіс-орієнтованого мислення.

Бізнес процес

Бізнес-процес - це послідовність дій, що дає корисний результат.

Бізнес-процес включає в себе протікають крізь нього пов'язані бізнес-елементи (дані), в тому числі вхідні та вихідні дані процесу.

Бізнес-діяльність і завдання

Бізнес-діяльність і завдання - це елементи, які, будучи пов'язані, утворюють бізнес-процеси.

З бізнес-діяльністю можна пов'язати такі характеристики, як тривалість, вартість, дохід, ресурси, вхідні та вихідні дані. Всі ці елементи є складовими частинами бізнес-процесів. Техніки ідентифікації сервісів дозволяють розібрати бізнес-процеси на дії і завдання, виходячи з яких і визначаються існуючі або необхідні сервіси (і їх операції). Такі сервіси іноді називають "бізнес" -Сервис.

Моделювання бізнес-процесів

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

Моделювання бізнес-процесів дає не тільки візуальне уявлення, а й дозволяє пізніше зв'язати елементи моделі бізнес-процесу з елементами ІТ - в тому випадку, якщо здійснюється в інфраструктурі, яка працює з лежачими в основі процесів метаданими.

Завдання для людей

Досить часто в процесах потрібно людське втручання (наприклад, твердження відрядження або кредиту). Такі завдання при моделюванні бізнес-процесу визначаються як ручні, і для кожного завдання призначається певна роль. Після розміщення для виконання процесів SOA буде потрібна підтримка завдань, які виконуються людьми. Такі продукти, як, наприклад, IBM WebSphere Process Server, надають користувачам списки очікують їх завдань для людей. При їх комбінуванні з такими продуктами, як IBM WebSphere Portal і Lotus Sametime, користувачі також можуть співпрацювати між собою і оповіщати систему про прийняті ними рішення, щоб система могла продовжувати виконання процесів. Цей людський фактор критично важливий для успіху SOA.

BPEL

IBM, Microsoft та інші компанії брали участь у розробці мови Business Process Execution Language (BPEL) for Web services specification (мова виконання бізнес-процесів для створення специфікацій Web-сервісів), що є засобом формального опису бізнес-процесів і протоколів взаємодії.

Версія 1.1 була опублікована в травні 2003 року; опублікований затверджений OASIS проект версії 2.0, яка тепер називається Web Services Business Process Execution Language (WSBPEL). Посилання приведена в ресурсах .

галузі

У різних сферах діяльності і галузях бізнес-процеси можуть мати свою специфіку, як, наприклад, в страхуванні. Галузеві бізнес-процеси визначаються промисловими консорціумами. Наприклад, TeleManagement Forum визначає enhanced Telecom Operations Map (eTOM) для телекомунікаційної галузі. Крім того, компанії, щоб виділитися серед конкурентів, можуть впроваджувати свої власні бізнес-процеси, засновані на перевірених моделях, таких як IBM Industry Models. В ресурсах наведено посилання на IBM Insurance Application Architecture (IAA), яка є прикладом IBM Industry Models.

Управління бізнес-процесами

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

BPM проводить моделювання, симулювання, оптимізацію, розміщення, прогонку, керівництво і моніторинг бізнес-процесів, після чого видає потрібні для поліпшення моделей результати і знову починає цикл удосконалень. Разом з IBM WebSphere поставляється набір різноманітних необхідних для BPM продуктів.

Висновок

У цій першій частині серії статей, присвячених термінології SOA, ми визначили такі основні терміни SOA, як сервіс, SOA, а також зв'язок SOA з архітектурою. Ми визначили два терміни - життєвий цикл сервісу і SOA-управління, - які є основними елементами SOA. Крім того, ми обговорили зв'язок SOA з бізнесом і описали бізнес-процеси. І це только початок. У наступних статтях ми визначимо терміни SOA, пов'язані з ІТ-дизайном, розробкою, робочим процесом і управлінням. Так що залишайтеся на зв'язку з developerWorks!

Подякою

Я хотів би подякувати моїх колег з IBM, які внесли великий вклад в сервіс-орієнтовану архітектуру і описані в статті ідеї. Особливу подяку висловлюю Річарду Джонсону (Richard D. Johnson) і Стіву Кіндеру (Steve Kinder) за рецензію на цю статтю.

Ресурси для скачування

Схожі тими

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів