.NET: Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) – це нова парадигма проектування розподілених інтегрованих систем. Згідно SOA будь-які частини інформаційних систем мають функціональність розглядаються як служби (service providers, провайдери служб), які надають свою функціональність іншим частинам системи за допомогою викликів їх функцій. Служби є компонентами, які можуть бути знайдені і викликані через локальну мережу або Internet. При цьому різні служби можуть організовуватися (orchestrate) для спільного виконання певної задачі. SOA забезпечує концептуальні архітектурні шаблони і платформи для таких систем. Зазвичай архітектура таких систем і потоки даних в них близькі до структури бізнес-підрозділів, що використовують їх, і взаємодій між ними. В деякій мірі відбувається з’єднання інформаційних технологій та бізнес-процесів на концептуальному рівні. Таке злиття позитивно впливає на розуміння інформаційних систем представниками бізнесу (концепція служби більш наочна ніж терміни “реплікація”, або “віддалений виклик процедури”), і на розуміння бізнес-процесів розробниками системи. В якості платформи для SOA-додатків зазвичай використовуються web-служби. Однак, не всі інформаційні системи, побудовані на основі web-служб, відповідають SOA, і SOA не обов’язково повинна базуватися на технології web-служб. Концепція SOA вперше була описана в 1996 році, але тільки в останні роки на хвилі інтересу до web-службам стала широко відомою. До цієї хвилі популярності доклало руку і Microsoft – в 1999 році Steve Ballmer озвучив концепцію “software as service”, що отримала своє втілення в технології. NET і web-службах. Підтримка web-служб вбудовується в багато продуктів Microsoft – BizTalk Server, MapPoint Server, SQL Server 2005 (Yukon), Office 2003.

Don Box – один з архітекторів нової інфраструктури Microsoft для межпрограммного обміну повідомленнями Indigo виділив 4 основних принципи SOA:

• 
  Явні кордону служб. Для кожної частини системи, для всіх підсистем і компонент з якої вона складається, можна однозначно сказати де вона знаходиться – поза службою або всередині певної служби. Це пов’язано з тим, що системи, побудовані за SOA, складаються з служб, які часто розділені великими відстанями, що працюють на різних платформах і мають різні засоби забезпечення безпеки. Обмін повідомленнями між різними частинами таких систем має суттєві накладні витрати. Тому, SOА засноване на моделі явного обміну повідомленнями, а не на моделі неявного виклику методів (як в DCOM). Явні кордону служб забезпечують автономність служб і незалежність від реалізації.
  
• 
  Автономність служб . Кожна служба працює у власній програмному середовищі, на власній ОС, реалізована на певній мові програмування і від цих чинників не залежить робота інших частин системи, які використовую службу. Вона поводиться як незалежний об’єкт, що володіє власною поведінкою, здатний на взаємодії з іншими незалежними об’єктами. Тому реалізація будь-якої служби або ж її розташування в системі може змінена без порушення загальної роботи системи. У систему також можна додавати нові служби або видаляти існуючі – це теж не повинно позначатися на роботі системи. Автономність служб увазі що будь-який виклик служби може закінчиться невдачею, тому будь-який виклик служби повинен забезпечуватися коректної обробкою помилок. Відкрита архітектура SOA надає більш широкі можливості для зловмисників по злому систем. Згідно з принципом автономності служби самі повинні піклуватися про аутентифікації, авторизації та безпеки. Тому особливу увагу при проектуванні служб повинна приділятися безпеці.
  
• 
  Служби описують свій контракт і схеми повідомлень, але не реалізацію. Клієнти служби знають її контракт (сигнатури методів і їх метадані) і схеми даних, які описують повідомлення служби і використовувані дані. Інформація про те, як реалізована служба, її клієнтам не доступна і не потрібна. Так само формальний опис контракту і схеми за допомогою політик (policy) дозволяє службам здійснювати перевірку вхідних повідомлень. Як і у випадку використання компонент (наприклад, COM), так ж мають контракт, особливу значимість для працездатності системи в цілому має устойчівать контрактів.
  
• 
  Сумісність служб заснована на політиках (policy). Застосування технологій, таких як WS-Policy, надають декларативні і програмні способи опису політик. Політики застосовуються як для служб, так і для клієнтських додатків. Прикладом політики може бути вимога на шифрування обмінюваних даних.

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

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

Об’єктно-орієнтоване програмування відіграє важливу роль при розробці SO систем для розробки самих служб та їх клієнтів, але не систем цілком. Чим же не влаштовує об’єктно-орієнтована архітектура при розробці великих розподілених інформаційних систем? Її суттєвими обмеженнями є

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

Архітектура, заснована на компонентах, (CORBA, COM / DCOM) зняло частину проблем – знизило ступінь деталізації і поліпшило ситуацію з повторним використанням компонент. Компонентні технології забезпечували мови опису інтерфейсів (наприклад, IDL) і засоби для локального та віддаленого виклику компонент.
SOA дозволяє проектувати і створювати додатки, що надають іншим додаткам віддалено викликати їх методи через опубліковані інтерфейси, і можливість знайти ці служби і опису інтерфейсів. На схеми на прикладі web-служб видно 3 основні ролі в SOA – служби (service providers), клієнти служб (service consumers) і брокери (brokers). Доступ до служб відбувається через мережу за стандартними протоколами. Самі служби описуються на стандартній мові (контракт служби) і публікують цю інформацію за допомогою брокера. Служби поділяють свій інтерфейс і його реалізацію. Для виклику служби клієнтського додатку потрібно тільки опис інтерфейсу служби – інформація же про реалізацію служби не потрібна клієнтам. Реалізація служби може змінюватися, не зачіпаючи клієнтів і без необхідності надавати клієнтам нову версію опису служби – в цьому і проявляється низька зв’язаність частин системи (loose coupling). Іншою перевагою поділу інтерфейсу і реалізації є можливість вибору клієнтом служби з декількох служб з однаковим інтерфейсом шляхом простого зазначення адреси потрібної служби. У цьому прихована можливість для розширення і масштабування системи після її створення. У систему також можна додавати нові служби або нових клієнтів служб не порушуючи вже існуючу функціональність. Причому для додавання додавання нової функціональності до системи не потрібно мати доступ до її вихідного коду. Для забезпечення такої незалежності від реалізації при використанні web-служб потрібно уникати використання типів даних, прив’язаних до певної технології (наприклад, замість типізованих DataSet платформи Microsoft. NET використовувати сутнісні класи або спеціально створені об’єкти перенесення даних (DTO)) і розширень WS-*, поки мають відмінності реалізацій на різних платформах.
Брокери зберігають інформацію про служби та надають цю інформацію клієнтам.
Web-служби є найкращою технологією, на якому грунтується SOA. Пошук web-служб відбувається в UDDI-каталозі, інтерфейс служби описаний на WSDL, а виклик відбувається за протоколом SOAP. Так як web-служби базуються на стандартизованих технологіях, вони працюють в крос-плафторменних середовищах і не залежать від мови реалізації.

Характеристики service oriented architecture.Інформаційні системи, побудовані згідно SOA, володіють наступними характеристиками:

• 
  Підставою на індустріальних стандартах. SOA використовує технології, розроблені спільно Microsoft, IBM, SUN, BEA, Oracle, W3C. Це звільняє від прив’язки до конкретної платформі або постачальнику програмних продуктів. Різні частини системи можуть бути розроблені на різних мовах програмування і працювати на різних платформах
  
• 
  низька зв’язаність (loose coupling) частин системи. Клієнти в SOA системах можуть розроблятися в повній незалежності від служб, використовуючи тільки їх опублікований інтерфейс. Через розділення інтерфейсу і реалізації служб клієнтські додатки підключаються до служб за допомогою пізнього зв’язування (late binding). Низька зв’язаність забезпечує кращу здатність систем до їх розширюваності: зміни у функціональності в службі не повинно зачіпати клієнтів, а при додаванні нових типів даних засоби розробки беруть на себе частину роботи. Низька зв’язаність також сприяє інкрементний і ітеративний підхід до розробки ПЗ, через відсутність труднощів реалізації функцінольності служби за декілька ітерацій
  
• 
  повторно використовуваних служб. Служби набагато легше використовувати повторно в реальних умовах і при вирішенні реальних бізнес-завдань ніж класи або компоненти. Легкість використання забезпечується можливістю пошуку і доступністю служби, не має просторові обмеження, за допомогою виклику через мережу
  
• 
  синхронні і асинхронні виклики служби. Служби підтримують як синхронні виклики методів служби, коли клієнт отримуємо від служби відповідь, так і асинхронні виклики, здатні пересилати великі обсяги інформації і збільшують масштабованість системи.

Типи служб. Служби на основі їх функціональності можна умовно поділити на п’ять типів:

• 
  служби доступу до даних, Що надають читання і зміна даних (CRUD-функції). Вони приховують реалізацію доступу до реальних джерел даних і надають єдиний уніфікований інтерфейс для доступу до даних незалежно від кількості та виду використовуваних джерел даних. Для обміну даними можуть використовуватися спеціально створені сутнісні об’єкти, XML дані або ж об’єкти, інкапсулює таблиці БД (наприклад, об’єкти DataSet платформи. NET). Цей вид служб SOA найлегший у реалізації і найчастіше використовується в додатках
  
• 
  служби бізнес-логіки містять функціональність, використовувану для виконання різних бізнес-операцій (наприклад, оформлення заявки на слад або формування звіту по рівню продажів). В ході виконання бізнес-операцій зазвичай викликаються методи інших служб (наприклад, служб доступу до даних для отримання списку проданих товарів за останній тиждень)
  
• 
  компоненти зовнішніх додатків, Що викликаються через їх власні інтерфейси (наприклад, COM або DCOM). Прикладом такого додатка може бути CRM система, що зберігає дані про покупців і надає доступ до цих даних через COM
  
• 
  низькорівневі допоміжні служби відповідають за аутентифікацію та авторизацію, моніторинг, пошук служб, реєстрацію помилок, допоміжні функції, використовувані в інших службах. Часто їх називають загальні служби (common services) або служби інфраструктури підприємства (interprise infrastructure services)
  
• 
  складові служби, Що делегують роботу іншим типам служб та координують їх дії. Вони інтегрують інші служби системи і виконують контроль за транзакціями і перетворення потоку даних від одних служб до інших шляхом конвертації в потрібні формати

Ступінь деталізації служб (service granularity).Деталізація служб відноситься до масштабу функціональності, що службою. На основі функціональності за кількістю даних, що отримуються і відправляються службою, можна розділити їх на служби з дрібною деталізацією (fine-grained), грубої деталізацією (coarse-grained) і композитні (composite).
Служби з дрібною деталізацією здійснюють прийом і відсилання даних невеликими порціями інформації та й на кожну їхню функцію доводиться невелика кількість функціональність. Додатково може виникнути необхоімость збереження з стану служби між її викликами.
При грубій деталізації відбувається обмін великими порціями інформації і кожна функція реалізують б о більшу функціональність. При цьому передаються даних часто мають складову структуру і використовуються спеціально створені об’єкти перенесення даних (data transfer objects).
Функції з дрібною деталізацією зазвичай викликаються не реальними додатками, а іншими службами – композитними або з грубої деталізацією, що використовують високосоростние мережеві з’єднання. При виклику служб з дрібною деталізацією безпосередньо клієнтськими додатками через велику кількість обмінюваних повідомлень (особливо при низькою швидкістю з’єднання) сумарний час виклику функцій зростає через накладних витрат.
Композитні служби використовують для своєї роботи служби з дрібної і грубої деталізацією, делегуючи їм реальну роботу і здійснюючи контролюючу функцію і збір інформації.
    Microsoft Indigo. Нова версія операційної системи Windows “Longhorn” буде включати в себе інфраструктуру для розробки розподілених систем під кодовою назвою “Indigo”, заснована на. NET. Indigo надає загальну програмну модель для використання web-служб,. NET remoting, System.Messaging і. NET Enterprise Services. Indigo входить до складу WinFX (нової програмної моделлю Windows) і буде поставлятся так само і для операційних систем Windows XP і Windows 2003. Основними підсистемами Indigo є сервісна модель, коннектор, хостингових оточення і служби.

Архітектура Indigo

     Сервісна модель Indigo відповідає за зв’язування коду, відповідального за обробку повідомлень, і приходять повідомлень. На неї покладено функції підтримки транзакцій, забезпечення безпеки передачі повідомлень і їх гарантовану доставку. Для спрощення розробки активно застосовується декларативний підхід.
     Конектор забезпечує з’єднання між службами, засноване на SOAP і метаданих служб. Приховуючи деталі реалізації і оперуючи такими поняттями як порт, канал і повідомлення він дозволяє створювати високопродуктивні додатка, незалежні від транспортних протоколів, що забезпечують безпеку, регулювання навантаження і надійність передачі повідомлень і здатних налаштовуватися на різні конфігурації мереж (SSL, проксі-сервери, файрволи та ін.) Для цього в конектор входить кодіровщік, що конвертує повідомлення в дані, що передаються по конкретному транспортному протоколу, і назад. Для гарантованої доставки повідомлень можна застосовувати одну з двох моделей гарантованої доставки: експрес, при якій в пам’яті міститься буфер повідомлень, доставка яких ще не підтверджена, і надійний, при якому цей буфер знаходиться на жорсткому диску.
    Хостингових оточення. Сервісна модель Indigo і коннектор можуть бути завантажені в будь домен програми. Оточення хостніга було розроблено для використання Indigo в максимально великій кількості систем хостингу (dllhost.exe, svchost.exe, IIS і пр.).
     Системні служби та служби повідомлень. Для забезпечення функціональності служб Indigo використовує спеціальні служби. В якості приклад системних служб можна навести служби для забезпечення транзакцій. Служби повідомлень забезпечують розширену функціональність для черг повідомлень і підтримку подій.
Як ми бачимо всі підсистеми можна поділити на 2 рівня – на високорівневі шар, що має зручний для розробки додатків інтерфейс, і низькорівневий шар, що забезпечує б о більшу продуктивність і контроль над тонкощами реалізації.
Indigo дозволяє створювати служби двох видів: web-служби і RemoteObject служби. Web-служби в Indigo являють собою традиційні asmx служби ASP.NET, відповідні SOAP 1.2 і доповнені розширеними можливостями: підтримкою розподілених транзакцій, гарантованою доставкою повідомлень, підтримкою web-serivce farms для збільшення масштабованості і можливістю обміну повідомленнями між службами та клієнтами в обох напрямках.
Служби RemoteObject є покращеною версією. NET remoting, що дозволяє створювати екземпляри віддалених об’єктів або віддалено викликати їх методи. Поновлення та поліпшення торкнулися поліпшеної підтримки SOAP, імпорту та експорту метаданих, аутентифікації, шифрування, розподілених транзакцій і автоматичної активації.

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

• Функція пошуку в бета-версії Windows Vista SP1 (0)
• Примхи Windows Vista (0)
• Прикраса екрана привітання Windows XP (0)
• Перші тести 3-Way SLI (0)
• Час безперервної роботи Windows Vista (0)
• SADT: Синтаксис моделей і робота з ними (0)
• Серверні операційні системи провідних виробників (0)

---

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

ЕasyСode