Використання рівня Сервісів(Services Layer)

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

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

У наведеному прикладі користувач може отримати доступ до застосування використовуючи рівень представлення, тоді як зовнішні клієнти можуть от- римати доступ до застосування через рівень сервісів. Це дозволяє застосу- ванню підтримувати різні типи клієнтів.

3. Дизайн рівневої структури

Стандартний набір кроків при розробці рівневої архітектури застосування наступний:

1. Вибір стратегії розбиття на рівні

2. Визначення необхідних рівнів

3. Ухвалення рішення про распрделении рівнів(Layers) і компонентів

4. Рішення про необхідність " стиснути" рівні

5. Визначення правил взаємодії між рівнями

6. Визначення наскрізної функціональності

7. Визначення інтерфейсів між рівнями

8. Вибір стратегії реалізації і впровадження

9. Вибір протоколів взаємодії

Вибір стратегії розбиття на рівні

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

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

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

Визначення необхідних рівнів

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

Ухвалення рішення про розподіл рівнів і компонентів

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

Ухвалення рішення про " стискування" непотрібних рівнів

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

Визначення правил взаємодії між рівнями

При визначенні стратегиии міжрівневої комунікації вимагається визначити правила взаємодії між рівнями. Головні проблеми які повинні враховуватися це зменшення залежності між шарами і уникнення кільцевих поси- лань(circular references). Наприклад це випадок, коли з двох рівнів кожен за-

лежить від компонентів іншого рівня. Можливе використання наступних стратегій :

• Взаємодія згори-вниз.

• Слабозв'язана взаємодія.