Типи бізнес-процесів

Бізнес-процеси можуть бути або процесами, що довго виконуються, або мікропотоками :

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

Мікропотоки(micro - flows) виконуються в одному потоці(thread) без перери- вання. Вони також називаються безперервними(noninterruptible) бізнес- процесами. Мікропотоки виконуються за одну транзакцію, мають малу три- валість і складаються тільки з синхронних сервісів.

2. Роль XML

Архітектура SOA використовує відкриті стандарти і забезпечує не-залежну бізнес-інтеграцію.

Інфраструктура СОА базується на використанні XML тому що:

• XML є базою практично усіх стандартів Web- сервісів

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

• XML дозволяє створювати текстові, гнучкі і розширювані представ- лення.

Приклади стандартів, грунтованих на XML і використовуваних в SOA :

• SOAP. Протокол для обміну цими застосуваннями по транспортних протоколах, таким як HTTP.

• WSDL. Документ XML, який описує Web- сервіс. WSDL- файл описує чотири головні суті:

• Послуги, доступні через інтерфейс Web- сервісу, такі як список імен методів і повідомлень-атрибутів.

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

• Інформація про зв'язування для транспортного протоколу

• Адреса сервісу, використовувана для його виклику.

• Electronic Business using eXtensible Markup Language(ebXML). Стандартний способом визначення бізнес-транзакцій, які можуть ви- конуватися між різними бізнес-суб'єктами.Визначає стандартні методи для обміну повідомленнями, встановлюючи торгові зв'язки і реєструю- чи бізнес-процеси між компаніями.

3. Етапи циклу життя СОА

Етап моделювання

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

Етап складання

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

Етап розгортання

На етапі розгортання середовище часу виконання налаштовується на необ- хідний рівень якості сервісу і вимог системи безпеки.

Етап управління

На цьому етапі виконується управління і моніторинг ряду аспектів, таких як доступність сервісів, час реакції, контроль версій сервісів. Важливу роль на цьому етапі грає моніторинг ключових показників продуктивності(key performance indicators - KPI) процесу.

4. Архітектурний шаблон СОА

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

Потоки бізнес-процесів координуються т.з. хореографією(orchestrating ) для объединия сервіси в складені застосування.

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

5. Рівні SOA

Рівень 1: Рівень операційної системи. Складається з існуючих замовлених додатків, що називаються також успадкованими системами. Включає існуючі упаковані додаткі системи управління взаємозв'язками(CRM) і планування ресурсів підприємства(ERP), а також ранні об'єктно-орієнтовані реалізації системи, а заразом і програми для управління бізнесом.

Рівень 2: Рівень корпоративних компонентів. Корпоративні компоненти несуть відповідальність за забезпечення функціональності і підтримку якості обслуговування(QoS) сервісів. Ці компоненти є керованим, регульованим

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

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

Рівень 4: Рівень об'єднання(хореографії) бізнес процесів. У цьому рівні визначається способи об'єднання сервісів, визначених в Рівні 3. Сервіси по- в'язані в потік шляхом угрупування(хореографії) і, отже, вони діють спільно як окреме застосування. Подібні застосування підтримують особливі ситуації і бізнес-процеси. Тут для проектування потоків застосування можуть викори- стовуватися такі візуальні інструменти компонування, як IBM® WebSphere® Business Integration Modeler або Websphere Application Developer Integration Edition.

Рівень 5: Рівень доступу або представлення. Попри те, що цей рівень за- звичай упускається при обговоренні SOA, поступово він стає усе більш зна- чимим. Тут він зображений унаслідок тієї, що зростає конвергенція стан- дартів, таких як Web Services for Remote Portlets Version 2.0 і інших технологій, прагнучих вивести Web- сервіси на рівень інтерфейсу застосу- вання або презентації. Цей рівень можна представити як рівень, який необ- хідно взяти до уваги в подальших розробках. Важливо також звернути увагу на те, що SOA відділяє призначений для користувача інтерфейс від компо- нентів, і в якості альтернативи вам може знадобитися забезпечення наскрізного рішення між каналом доступу і сервісом або набором сервісів.

Рівень 6: Інтеграція(ESB). Цей рівень допускає інтеграцію сервісів шляхом представлення перевіреного набору таких можливостей, як інтелектуальна маршрутизація, посередництво протоколів і інших механізмів перетворень,

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

Рівень 7: Якість обслуговування(QoS). Цей рівень надає можливості для моніторингу, управління і підтримки таких аспектів якості обслуговування, як забезпечення безпеки, продуктивності і доступності. Він є фоновим про- цесом, що використовує механізми запитів і відповідей, і інструменти, кон- тролюючі загальний стан застосувань SOA. Сюди включені усі важливі стан- дартні реалізації WS - Management і інших значимих протоколів і стандартів, що реалізовують якість обслуговування для SOA.

7. Проектування стратегії кешування

Включає наступні кроки:

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

2. Вибір місця кешування даних

3. Визначення формату кешування даних

4. Вироблення стратегії управління кешем

5. Вибір методу завантаження кешованих даних

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

Під час проектування для кожного шару додатку створюється список даних, які можуть бути кэшированы. Кандидатами є наступні типи даних :

• Загальні дані додатку. Статичні дані, які використовуються усіма кори- стувачами додатку, наприклад, списки продуктів і зведення про продукти.

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

• Відносно статичні Веб-сторінки. Веб-сторінок або частин Веб- сторінок, які міняються рідко.

• Параметри процедур, що зберігаються, і результати запитів. До них ві- дносяться часто використовувані параметрів і результати запитів.

2. Вибір місця зберігання кешованих даних

При виборі місця зберігання визначаються як фізичне розміщення кеша так і його логічне розміщення.

Фізично кеш може розміщуватися в пам'яті, на диску у файлах або базі да- них.

• Кеш розміщують в пам'яті, якщо застосування використовує дані час- то; якщо кэшированные дані відносно часто міняються, і часто просяться повторно; і у випадку якщо об'єм даних порівняно невеликий.

• Кеш розміщують в системі або базі даних, якщо використання дані з кеша ефективніше в порівнянні з їх запитом з початкового джерела; якщо кэшированные дані змінюються рідко; чи, якщо сервіси для повторноой завантаження даних можуть бути не завжди доступні.

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

Логічне розміщення кеша - це його місце в логіці застосування. Важливо кэшировать дані як можна ближче до місця їх використання для підвищення продуктивності.

• На стороні клієнта кэшируются дані, характерні для сторінки або кори- стувача; дані, які що не містять конфіденційних відомостей; і дані невели- кого об'єму.

• На проксі-сервері або веб-сервері(для Веб-застосувань) кэшируются відносно статичні сторінки, які часто просяться клієнтами; сторінки, що оновлюються з відомою періодичністю; чи результати, повертані Веб- сервісами.

• У шарі представлення кэшируется відносно статичне виведення сторі- нок; невеликі об'єми даних про переваги користувачів ; чи елементи UI, створення яких ресурсоємне. Також кэшируются ресурсоємні дані

• У бізнес-шарі кэшируются ці, необхідні для збереження стани сервісу, бізнес-процеса або робочого процесу; чи якщо відносно статичні дані для обробки запитів від рівня представлення.

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

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

3. Визначення формату кешованих даних

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

го правила слід дотримуватися, якщо дані кэшируются в пам'яті, якщо кеш не використовуватиметься спільно різними процесами або комп'ютерами, якщо немає необхідності переміщати кэшированные дані в різні ділянки пам'яті.

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

4. Вироблення стратегії управління кешем

Необхідно визначити політику терміну дії кеша і скидання кеша. Видалення після закінчення терміну дії, і скидання даних є стратегіями видалення кэши- рованных даних з сховища кеша. При скиданні можуть віддалятися дійсні дані для вивільнення пам'яті під частіше використовувані елементи, у разі ж видалення даних після закінчення терміну їх дії віддаляються дані, які стали недійсними.

Стратегія терміну дії кеша повинна забезпечувати, щоб в кеші знаходилися тільки дійсні дані і елементи. Політика терміну дії може використати як термін дії за часом, так і термін дії з повідомлення:

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

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

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

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

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

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