Моделювання SOA: Частина 1. Ідентифікація сервісів

Як моделювання сприяє підвищенню ефективності SOA


Ефективність SOA полягає в здатності забезпечити динамічність бізнесу за допомогою інтеграції та багаторазового використання бізнес-процесів. У SOA це досягається двома способами: шляхом підтримки рішень, створених на основі багаторазово використовуваних сервісів, інкапсулюючих функціональні можливості, ізольовані від конкретної реалізації, і надання коштів для управління зв'язністю між окремими функціональними можливостями. Сполучною ланкою між бізнес-вимогами та здатних до розгортання рішенням, заснованим на використанні сервісів, може стати моделювання. Моделі SOA переводять розробку на більш високий рівень абстракції, що дозволяє зосередитися на бізнес-сервісах. Принципи керованої моделями розробки можуть використовуватися для створення реалізацій SOA за допомогою таких платформ, як Java 2 Platform, Enterprise Edition (J2EE) або IBM CICS, які дозволяють виконати функціональні та нефункціональні вимоги і в той же час сприяють динамічності бізнесу.


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


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


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


Вирішити ці завдання можна за допомогою моделювання та використання принципів розробки, керованої моделями (model-driven development, MDD). Моделі дозволяють абстрагуватися від деталей реалізації і зосередитися на тих проблемах, від яких залежать архітектурні рішення. До деякої міри описуваний нами підхід застосовує до розробки SOA-рішень один з фундаментальних принципів SOA: ізоляція проблем і слабка зв'язаність. У цьому матеріалі ми чітко розмежовуємо завдання і обов'язки бізнес-аналітиків і співробітників відділів інформаційних технологій.


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


Про даної серії, присвяченої моделювання SOA


У статті демонструється використання UML-моделей і профілю програмування сервісів IBM Software Service Profile для розробки SOA-рішень, що враховують бізнес-вимоги, але незалежних від реалізації. Як правило, людина краще засвоює ідеї, вивчаючи конкретні, типові і готові приклади. Тут ми як раз і використовуємо цей підхід. Ми не будемо витрачати багато часу на докладний опис UML, а зосередимося на те, як використовувати UML у проектуванні та розробці.


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


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


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


Таблиця 1. Ролі, завдання та інструменти процесу розробки























Роль


Завдання


Інструменти


Бізнес-виконавець


Формулювання бізнес-завдань і цілей


Rational RequisitePro


Бізнес-аналітик


Аналіз бізнес-вимог


WebSphere Business Modeler


Розробник архітектури програмного забезпечення


Розробка архітектури рішення


Rational Software Architect


Розробник Web-сервісів


Реалізація рішення


IBM Rational Application Developer і IBM WebSphere Integration Developer


У цій серії статей ми зосередимося на тому, як зібрати бізнес-вимоги, створити моделі сервісів, які будуть забезпечувати їх виконання, створити і розмістити рішення, що втілюють у життя ці проекти. Ми також розповімо про інструменти, які допоможуть нам зробити це. У статтях буде описаний мінімальний набір функцій моделювання SOA, пропонованих в даний час інструментами IBM, які перераховані у таблиці 1; ці функції можна використовувати для моделювання вимог споживача і постачальника сервісу на будь-якому архітектурному рівні. Ми не будемо розповідати про всі методи чи технологіях збору вимог, принципах аналізу та оцінки реалізацій сервісів або секціонування сервісів на різних архітектурних рівнях. Більш детальну інформацію з цих важливих тем можна знайти в IBM Rational Unified Process (RUP) for SOA і RUP for SOMA. Ці Plug-in для IBM Rational Method Composer містять процеси розробки, інструкції, навчальні матеріали щодо використання інструментів та статті, в яких демонструються додаткові методи використання інструментів для розробки моделей сервісу і рішень


Приклад. Обробка замовлень на придбання


Наш приклад побудований на прикладі Purchase Order Process (Обробка замовлень на придбання) з OMG UML Profile і Metamodel for Services (UPMS) RFP і прикладі з специфікації BPEL 1.1. Специфікація BPEL 1.1 містить тільки частину рішення, тому що в ній не визначені корелюють набори, бізнес-дані не відрізняються повнотою і, крім того, в рішенні не передбачена обробка чи компенсація помилок. У даній версії прикладу додані деякі дані для уточнення рішення – зокрема, дані, необхідні для кореляції.


Ми почнемо з того, що скористаємося інструментом IBM Rational RequisitePro для того, щоб описати бізнес-мотивацію для затвердження бізнес-завдань, які необхідно виконати, і цілей, які повинні бути досягнуті. Після цього ми розповімо про високорівневої бізнес-процесі, записаному за допомогою IBM WebSphere Business Modeler і виражає організаційні та функціональні бізнес-вимоги, необхідні для забезпечення вирішення завдань і досягнення цілей. Ці мотивації і моделі процесів створюють контекст для ідентифікації сервісів, що відповідають бізнес-вимогам.


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


Описаний процес ідентифікації відповідних сервісів з бізнес-моделі також відомий як декомпозиція предметної області. У IBM Rational Unified Process (RUP) SOMA описується метод декомпозиції предметної області та деякі інші методи, які, якщо використовувати їх в поєднанні один з одним, забезпечують підвищену точність ідентифікації всіх сервісів, необхідних бізнесу.


Бізнес-вимоги


Сценарій: Якийсь консорціум компаній прийняв рішення про організацію спільної роботи зі створення сервісу багаторазового використання для обробки замовлень на придбання. Завдання проекту:



На малюнку 1 показані вимоги, документовані в RequisitePro. Зверніть увагу на те, що бізнес-прецедент Process Purchase Order задовольняє всім нашим вимогам.


Малюнок 1. Бізнес-вимоги в RequisitePro


Крім того, ми створимо ключовий показник ефективності (key performance indicator, KPI) для завдання № 2: Своєчасна обробка замовлень (див. малюнок 2).


Малюнок 2. Ключовий показник ефективності


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


Організаційні бізнес-процеси


Бізнес-аналітики компаній-членів консорціуму аналізують вимоги і виносять рішення про те, що запропонований бізнес-процес IBM WebSphere Business Modeler виконує бізнес-завдання, а також не суперечить операційним обмеженням бізнесу. Для того щоб цей процес можна було використовувати в якості основи офіційної угоди про рівень сервісу (service level agreement, SLA) між сторонами, його необхідно доопрацювати та деталізувати. Отже, наше SOA-рішення, що задовольняє цим бізнес-вимогам, повинна суворо дотримуватися їх (рисунок 3).


Малюнок 3. Модель бізнес-процесу "Обробка замовлень на придбання"


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


Ми скористалися інструментом WebSphere Business Modeler, щоб створити бізнес-показник Максимальний час обробки замовлення, Який буде відповідати KPI Максимальний час обробки замовлення з бізнес-вимог. Цей бізнес-показник відстежує час обробки процесу "Обробка замовлення на придбання" і генерує попередження у тому випадку, якщо час обробки замовлення перевищить п'ять днів (малюнок 4).


Малюнок 4. Бізнес-показники для KPI


Бізнес-аналітики для імітації бізнес-процесу можуть скористатися інструментом WebSphere Business Modeler. Він може використовуватися в наступних важливих цілях:





Ми також зв'язали процес "Обробка замовлень на придбання" в WebSphere з бізнес-прецедентом BUC1 "Обробка замовлень на придбання" в RequisitePro, щоб показати, що процес реалізує прецедент. "Реалізує" – Це стандартний термін моделювання прецедентів. Ми бачимо, що бізнес-прецедент і процес в піктограмі бізнес-прецеденту BUC в поданні браузера вимог Requeiment Explorer в WebSphere Business Modeler зв'язані за допомогою маленької стрілки (малюнок 5).


Малюнок 5. Зв'язування бізнес-процесів з реалізованими бізнес-прецедентами


Ви можете користуватися перспективою Requirements в WebSphere Business Modeler для переходу між бізнес-процесами і реалізованими ними бізнес-прецедентами в поданні браузера вимог Requirement Explorer в WebSphere Business Modeler, клієнт RequisitePro або вимога в Microsoft Word.


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


Ідентифікація сервісів


Деякі бізнес-процеси можуть виконуватися безпосередньо на платформі, наприклад, в середовищі сервера процесів IBM WebSphere Process Server. Однак існують такі ситуації, в яких бізнес-процеси недостатньо враховують ІТ-завдання і, можливо, повинні зазнати рефакторінгу для поліпшення підтримки багаторазового використання та виконання таких нефункціональних вимог, як продуктивність, масштабованість і безпеку. У цьому випадку бізнес процеси можуть розглядатися як специфікації вимог до того, які завдання має виконувати SOA-рішення.


Вимога до сервісу


Вимоги до процесу "Обробка замовлень на придбання" можуть бути отримані на основі бізнес-процесу WebSphere Business Modeler. Ці вимоги розглядаються як контракт для сервісу; вони показують, які ролі беруть участь у бізнес-процесі, які завдання вони мають виконувати і за якими правилами взаємодіяти. Контракт для сервісу є формальною, архітектурно-нейтральною специфікацією бізнес-вимог, яка створюється шляхом взаємодії зі споживачами та постачальниками сервісу і не вирішує жодних питань, що мають відношення до архітектури або реалізації ІТ. У цьому випадку контракт для сервісу містить ту ж інформацію, що й вихідний бізнес-процес, він просто є уявлення бізнес-процесу, створене при відкритті моделі WebSphere Business Modeler за допомогою IBM Rational Software Modeler або IBM Rational Software Architect.


Бізнес-аналітики зазвичай використовують WebSphere Business Modeler; тоді як розробники ІТ-архітектури воліють працювати в Rational Software Architect. Малоймовірно, що ці інструменти будуть використовуватися одночасно, як правило, вони не використовуються для доступу до робочої області одного і того ж користувача. Щоб розробники ІТ-архітектури могли використовувати результати роботи бізнес-аналітиків, в Rational Software Architect передбачена можливість імпорту бізнес-моделей WebSphere Business Modeler в робочу область Rational Software Architect, після чого розробник архітектури зможе відкрити модель і переглянути зміст роботи бізнес-аналітика, інтерпретоване у формі еквівалентних UML-моделей. На малюнку 6 показані вибрані фрагменти нашої моделі WebSphere, інтерпретовані Rational Software Architect у вигляді UML-діаграми.


Малюнок 6. Контракт для вимог до сервісу


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


Кооперація <<serviceCollaboration>> "Обробка замовлень на придбання" відповідає бізнес-процесу "Обробка замовлень на придбання".


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


При моделюванні вимог до сервісу або видобування вимог з бізнес-процесів кооперація відповідає на наступні питання:








"Обробка замовлень на придбання" – це кооперація сервісу, що включає чотири ролі, одну з яких виконує сам процес. Ці ролі отримані на основі бізнес-процесу шляхом вивчення завдань, привласнених ролям в доріжках на діаграмі бізнес-процесу. Інструмент WebSphere Business Modeler використовує орієнтоване на процеси подання бізнес-вимог, тоді як у контракті для сервісу використовується уявлення, орієнтоване на ролі. Це забезпечує більш сервіс-орієнтоване бачення контрактів для бізнесу і спрощує перехід від вимог до процесу до архітектури сервіс-орієнтованих рішень.


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


Кооперація сервісу може також реалізувати прецеденти, які документують додаткову інформацію про функції високого рівня і нефункціональних вимоги до бізнес-процесу з точки зору ключових сторонніх зацікавлених осіб або виконавців. Ці прецеденти можна побачити на діаграмах прецедентів в Rational Software Architect і пов'язати з прецедентами в RequisitePro. Це підтримує зв'язок між контрактом для вимог до сервісу, бізнес-процесами, бізнес-прецедентами і бізнес-завданнями і бізнес-цілями.


Контракт для кооперації сервісу, показаний на малюнку 6, може бути представленням моделі бізнес-процесу WebSphere Business Modeler або бути розробленим безпосередньо в Rational Software Architect. Який з двох підходів використовувати залежить від переваг, фахівця, що виконує моделювання, а також від того, чи використовується для перевірки коректності бізнес-процесів імітація. У будь-якому випадку підтримується повна отслеживаемость. Безумовно, якість контрактів для кооперації сервісів, отриманих на основі бізнес-процесів WebSphere Business Modeler буде залежати від рівня деталізації цих процесів.


Організація проекту сервісу


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


Спочатку ми створимо проект моделювання сервісу в Rational Software Architect з ім'ям PurchaseOrderProcessModel. Цей проект містить модель сервісів PurchaseOrderProcess. Дана модель складається з інформаційної моделі для сервісів, даних сервісів, специфікацій наявних і необхідних інтерфейсів і компонентів, що надають необхідні сервіси. Але в цій статті ми зосередимося, головним чином, на ідентифікації сервісів.


Як показано на малюнку 7, модель PurchaseOrderProcess складається з 5 основних пакетів:







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


Малюнок 7. Діаграма залежностей пакету


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


Топологія сервісів


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


На рисунку 8 представлена проста діаграма класів (або діаграма у вільній формі) у Rational Software Architect; ця діаграма показує пакунки, що представляють описані вище функціональні області бізнесу, і ключові сервіси, які нам належить створити в кожному пакеті. Єдиною інформацією про сервіс на цей момент є ім'я сервісу.


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


Малюнок 8. Схема топології сервісу


Примітка:
У цій статті ми не розповідаємо про те, як спроектувати і розробити топологію сервісу Модуль IBM RUP for SOMA містить процес, методи і керівництво з виявлення сервісів за функціональними областям.


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


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


Малюнок 9. Виконання контракту для вимог до сервісу


Тим не менше, з цієї діаграми видно, як сервіси виконують контракт для вимог до кооперації сервісу. Контракт використовує кооперацію і є екземпляром кооперації сервісу "Обробка замовлень на придбання ". Частини компонента" Обробка замовлень на придбання "прив'язані до ролей, які вони виконують у цьому контракті. Завдяки цьому забезпечується формальна зворотній зв'язок з бізнес-вимогами і демонструється значимість для бізнесу кожного з інтерфейсів сервісів, які ми збираємося визначити і реалізувати. Поведінка кооперації сервісу "Обробка замовлень на придбання" визначає, як компоненти сервісу мають взаємодіяти в реалізації сервісу. Ми повернемося до цього моменту після визначення і реалізації сервісу, щоб переконатися, що рішення виконує вимоги контракту.


Що далі


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


У наступній статті цієї серії, "Моделювання SOA: Частина 2. Специфікація сервісу," ми займемося моделюванням докладної специфікації для кожного з таких сервісів. Як правило, в таких специфікаціях вказують наявні та необхідні інтерфейси, ролі, що виконуються цими інтерфейсами в специфікації сервісу, а також правила та протоколи, що описують взаємодію цих ролей при наданні сервісу.

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*