Перевірка вводу

При проектуванні стратегії перевірки керуйтеся наступними рекомендаціями:

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

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

• Повертайте інформативні повідомлення про помилки у разі збою вали- дации.

• Для доступу до форматованим XML- даним використайте легковагі ме- тоди читання і запису XML даних, особливо для дуже великих наборів XML- даних. (не DOM а SAX - парсеры)

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

• Зберігайте XML в стовпцях бази даних, що типізуються, якщо такі є. Це забезпечить максимальну продуктивність. Якщо передбачається, що

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

Проектування додатків з використанням сервісів

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

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

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

Шар сервісів зазвичай включає наступні компоненти:

• Інтерфейси сервісів. Сервіси надають інтерфейси, в які передаються усі повідомлення, що входять.

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

Принципи проектування сервісів

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

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

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

• Відділяйте функціональність шару сервісу від функціональності інфра- структури. У шарі сервісів реалізація наскрізної функціональність не по-

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

• Створюйте сутності із стандартних елементів. По можливості компо- нуйте складні типи і об'єкти передачі даних, використовувані сервісом, із стандартних елементів.

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

• Забезпечте в сервісі функціональність для виявлення і обробки повідо- млень(идемпотентность), що повторюються. Реалізація широко відомих шаблонів, таких як Receiver і Replay Protection, при проектуванні сервісу забезпечить, що дублюючі повідомлення не оброблятимуться, або що по- вторна обробка не впливатиме на результат.

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

1. Етапи проектування шару сервісів

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

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

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

• Визначення контрактів збоїв, які повертають дані про помилки спожи- вачам сервісу.

• Проектування об'єктів перетворень, які забезпечують перетворення між бізнес-сутностями і контрактами даних.

• Проектування абстракції, використовуваної для взаємодії з бізнес- шаром.

• Проектування сервисів REST

При проектуванні REST- ресурсів керуйтеся наступними рекомендаціями

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

• Виберіть підхід для представлення ресурсів. Хорошою практикою є ви- користання значущих імен для вихідних точок REST і унікальних іденти- фікаторів для конкретних екземплярів ресурсів. Наприклад, http://www.contoso.com/employee/ представляє вихідну точку службовець. http://www.contoso.com/employee/smithah01 використовує ID службовця для позначення конкретного службовця.

• Прийміть рішення про необхідність підтримки безлічі реалізацій для різних ресурсів. Наприклад, про те, чи повинен ресурс підтримувати фор- мати XML, Atom або JSON, і зробіть це частиною запиту до ресурсу, тоді ресурс надаватиметься в різних форматах(наприклад, http://www.contoso.com/example.atom і http://www.contoso.com/example.json).

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

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

• Проектування сервисів SOAP

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

• Прийміть рішення про те, як оброблятимуться збої і помилки, і як по- вертатимуться клієнтам відповідні відомості про помилку.

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

• Виберіть відповідну модель безпеки для сервісів.

Уникайте використання складених типів в повідомленнях. Застосування тіль- ки простих типів забезпечить максимальну можливість взаємодії.

2. Рекомендації по розгортанню шару сервісів

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

• Якщо сервіс розміщується на одному рівні із споживачем сервісу, ви- користайте іменовані канали або протоколи загальної пам'яті.

• Якщо сервіс використовується тільки застосуваннями локальної мере- жі, використайте для взаємодії протокол TCP.

• Якщо сервіс публічно доступний через Інтернет, використайте HTTP в якості транспортного протоколу

7. Концепції Сервіс-Орієнтованої Архітектури

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

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

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

SOA припускає наявність трьох основних учасників : постачальника сервісу, споживача сервісу і реєстру сервісів . Постачальник сервісу реєструє свої сервіси в реєстрі, а споживач звертається до реєстру із запитом.

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

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

• Модель, орієнтована на повідомлення(Message Oriented Model, MOM). Зосереджена на повідомленнях, їх структурі, способах транспортування і інших компонентах, не пов'язаних з причинами обміну повідомленнями і їх семантикою;

• Модель, орієнтована на сервіси(Service Oriented Model, SOM). Зосере- джена на діях, що виконуються сервісами;

• Модель, орієнтована на ресурси(Resource Oriented Model, ROM). Зосе- реджена на системних ресурсах;

• Модель політик(Policy Model, PM). Визначає політики, пов'язані з архі- тектурою(в основному вона є обмеженнями, що накладаються на поведін- ку агентів і сервісів, у тому числі обмеження, пов'язані з вимогами безпе- ки і якості обслуговування);

• Модель управління(Management Model, MM).

1. Концепції

Визначення сервісу в SOA

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

Реєстри сервісів

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

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

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

Елементи бізнес-процеса

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

• Вхідні дані(input) - інформація, необхідна процесу для формування ре- зультату.

• Вихідні дані(output) - усі дані і інформація, згенеровані процесом. Ви- хідними дані є бизнес-цели і показники, необхідні для бізнес-діяльності.

• Події(events) - повідомлення про виникнення чого-небудь важливого, наприклад, візуальна індикація. Вони можуть виникати до, в час і після виконання процесу.

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

• Дія(activity) - найменший елемент роботи в процесі.

• Показники продуктивності(performance metrics) - атрибути, що пред- ставляють ефективність процесу для визначення його відповідності необ- хідної продуктивності.