.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 є черговим етапом в архітектури програмного забезпечення. Вирішуючи питання підвищення складності розроблюваних систем, забезпечення більшої гнучкості рішень, роботи в гетерогенних середовищах, зниження витрат на розробку і супроводження, кращої відповідності потребам бізнесу за 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, володіють наступними характеристиками:


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


Ступінь деталізації служб (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, імпорту та експорту метаданих, аутентифікації, шифрування, розподілених транзакцій і автоматичної активації.

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


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

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

Ваш отзыв

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

*

*