Основи Yukon: XML, T-SQL і CLR відкривають нові перспективи в програмуванні баз даних, Інші СУБД, Бази даних, статті

Ерік Браун
Стаття була опублікована на сайті Microsoft №7/2004


Наступна версія SQL Server з кодовою назвою “Yukon” включає ряд удосконалень і забезпечує розширену підтримку мов програмування. Наприклад, Transact-SQL тепер більшою мірою відповідає специфікації SQL ANSI-99, а запити стали більш гнучкими і чіткими. Yukon дозволяє виконувати користувальницькі функції, збережені процедури і тригери, написані на CLR-сумісних мовах, зокрема на Visual Basic. NET та C #. Він також підтримує підмножину мови XQuery, пропонованого W3C в якості стандарту, і містить вбудовані засоби роботи з XML. Автор статті розглядає найбільш значимі можливості мови і показує їх застосування на прикладі програми для введення замовлень.


На етапі планування чергової версії Microsoft SQL Server з кодовою назвою “Yukon” велика увага приділялася перспективам баз даних і можливостям програмування SQL Server. Розробники Microsoft усвідомили, що в майбутньому будуть потрібні більш симетрична модель програмування і набагато більш гнучка підтримка різних моделей даних. Вимога симетричності моделі програмування означало, що типові задачі доступу до даних і маніпулювання ними можна було б вирішувати найрізноманітнішими способами – за допомогою XML, Microsoft. NET Framework або T-SQL (Transact-SQL).


У підсумку платформу програмування баз даних розширили в декількох областях. По-перше, здатність служити хостом для. NET Framework CLR (common language runtime) дозволяє застосовувати при роботі з базою даних процедурне програмування та керований код. По-друге, завдяки такій інтеграції с. NET Framework бази даних SQL Server тепер володіють потужними об’єктними засобами. Введення повнофункціонального типу даних XML, що володіє всіма можливостями реляційних типів, забезпечує поглиблену підтримку XML. Також додана підтримка стандартів XQuery (XML Query) і XSD (XML Schema Definition) на серверної стороні. Нарешті, в Yukon внесені значні вдосконалення в мову T-SQL.


Нові моделі програмування і розширені мови утворюють середовище програмування, яка спирається на поточну модель реляційної бази даних та доповнює її. Кінцевим результатом роботи над новою архітектурою є можливість створювати більш масштабовані, надійні, стійкі до збоїв програми та прискорення розробки. Інший результат появи цих моделей – нова інфраструктура SQL Service Broker. Це розподілена прикладна інфраструктура асинхронної доставки повідомлень. Надалі я детальніше розповім про Yukon SQL Service Broker, але спочатку ознайомимося з основними змінами і вдосконаленнями в моделі програмування. Почнемо з T-SQL.


Удосконалення в Transact-SQL


У Yukon в T-SQL введено стільки нових конструкцій і примітивів, що повністю перерахувати їх тут не можна. Всі вони описані в SQL Server Yukon Books Online. Удосконалення мови T-SQL полягають у більшій сумісності зі специфікацією SQL ANSI-99, що відображає побажання користувачів. Багато удосконалення T-SQL спрямовані на підвищення чіткості (expressiveness) запитів. Введено кілька нових типів запитів, що дозволяють використовувати код T-SQL при вирішенні типових завдань. Наприклад, при генерації рахунків або ієрархічного набору результатів можна застосовувати рекурсивні запити.


T-SQL в Yukon підтримує оператори PIVOT і UNPIVOT. Ці оператори обробляють вхідний табличне вираження і генерують табличний набір результатів. Оператор PIVOT по записах початкової таблиці формує поля вихідний, при цьому може виконуватися агрегація або які-небудь інші математичні операції. Він розширює вхідний табличне вираження відповідно до заданого зведеним полем (pivot column) і генерує вихідну таблицю, в якій є своє поле для кожного унікального значення зведеного поля. Оператор UNPIVOT виконує протилежну операцію: формує записи по полям. Оператор UNPIVOT звужує вхідний табличне вираження у відповідності зі значеннями зведеного поля.


У Yukon введений простий, але потужний механізм обробки виключень – конструкція TRY / CATCH мови T-SQL. Cтало можливим перехоплювати й обробляти помилки аварійного припинення транзакцій, які раніше приводили до завершення роботи пакетів. Крім того, з’явилися нові мовні конструкції для підтримки захисту, реплікації, Notification Services, XML і всієї функціональності, що надається. NET Framework. Реалізація. NET Framework на сервері – важливий етап еволюції SQL Server.


. NET-програмування SQL Server Yukon


Тепер розробники можуть писати збережені процедури, тригери і призначені для користувача функції (UDF) на будь-якій мові, сумісному з Microsoft. NET, зокрема на Visual Basic. NET та C #. В керованому коді можна створювати три нових об’єкти – призначені для користувача типи (UDT), агрегати і функції. CLR є серцевиною. NET Framework і надає середовище виконання будь коду, заснованому на. NET Framework. CLR підтримує різні функції та сервіси, необхідні для виконання програм: компіляцію за запитом, управління пам’яттю, введення суворого контролю типів, обробку виключень, управління потоками і захист. SQL Server Yukon служить хостом для всіх цих функцій, що багато в чому аналогічно тому, як операційна система служить хостом для застосування.


Yukon за рахунок інтеграції з CLR також забезпечує автоматичне керування пам’яттю, виділення ресурсів та збір сміття. SQL Server надає. NET-збірок прямий доступ до об’єктів бази даних через простір виконання (execution space) SQL Server. Доступ до даних здійснюється за допомогою спеціальної різновиди ADO.NET. Опис функціональності ADO.NET, реалізованої в базі даних, виходить за рамки цієї статті, але, оскільки методи доступу аналогічні методам, вже знайомим розробникам, використовувати функціональність CLR нескладно.


Інтеграція. NET Framework з SQL Server Yukon надає розробникам баз даних декілька істотних переваг.



Використання CLR


У попередніх версіях SQL Server програмістам баз даних при написанні коду, що працює на сервері, доводилося обмежуватися застосуванням T-SQL. Завдяки інтеграції CLR розробники баз даних тепер можуть вирішувати завдання, які складно або не можна вирішити на одному тільки T-SQL. Visual Basic. NET та C # – сучасні мови програмування з повноцінною підтримкою масивів, структурної обробки виключень та наборів (collections). Інтеграція з CLR дозволяє писати код, який має більш складну логіку і більше пристосований для вирішення обчислювальних задач, ніж код на T-SQL.


Більш того, Visual Basic. NET та C # підтримують об’єктно-орієнтоване програмування: інкапсуляцію, успадкування і поліморфізм. Код, що працює з базою даних, тепер легко впорядкувати в класи і простору імен. Завдяки цьому, коли доводиться писати великий обсяг коду, що працює на сервері, стає простіше впорядковувати і супроводжувати код. Можливість логічно і фізично впорядкувати код в збірки і простору імен – величезна перевага, що полегшує пошук і зв’язування блоків коду при реалізації великих баз даних.


Проектуючи UDT, доведеться враховувати такі обмеження, як допустимість порожніх значень і виконання умов. Можна навіть використовувати закриті функції, щоб розширити можливості типу даних; наприклад, можна додати вбудовану підтримку XML-сериализации.


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


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


Найвищий рівень захисту, SAFE, допускає лише обчислення і доступ до даних. Наступний рівень, EXTERNAL_ACCESS, додатково дозволяє доступ до зовнішніх системних ресурсів. Найнижчий рівень захисту, UNSAFE, не накладає ніяких обмежень, крім заборони операцій, які можуть порушити стабільність роботи сервера.


Вибір між T-SQL і керованим кодом


Керований код на рівні доступу до даних дозволяє проводити над об’єктами бази даних складні математичні розрахунки і застосовувати будь-яку логіку. . NET Framework забезпечує велику підтримку роботи з рядками, регулярних виразів, перехоплення помилок та ін Функціональність базової бібліотеки класів. NET Framework дозволяє отримати повний доступ до тисяч вже розроблених класів і підпрограм, до яких легко звернутися з будь-якої збереженої процедури, тригера або UDF. У ситуаціях, де потрібні обробка рядків, математичні функції, робота з датами, доступ до системних ресурсів, просунуті алгоритми шифрування, доступ до файлів, обробка зображень чи маніпулювання XML-даними, виявляється, що керовані збережені процедури, функції, тригери та агрегати надають значно простішу програмну модель, ніж T-SQL.


Ще одна перевага керованого коду – контроль типів. Перед виконанням керованого коду CLR здійснює на стороні сервера перевірки, щоб упевнитися, що запуск коду дійсно безпечний. Наприклад, перевіряється, як код звертається до пам’яті, щоб не було читання з тієї області, в яку нічого не записано.


Тепер при написанні збережених процедур, тригерів і UDF програміст повинен вирішити, що використовувати – традиційний T-SQL або CLR-сумісний мову, наприклад Visual Basic. NET або C #. Відповідь залежить від потреб конкретного проекту. T-SQL краще використовувати, коли код в основному звертається до даних і містить мінімум процедурної логіки (або взагалі не містить її). CLR-сумісні мови кращий для інтенсивних математичних обчислень і написання процедур зі складною логікою, а також для рішень на основі базових бібліотек класів. NET Framework.


Ще одна важлива особливість інтеграції з CLR – розміщення коду (code placement). І T-SQL-, і CLR-код виконуються ядром баз даних на сервері. Той факт, що код для. NET Framework і база даних працюють в одному середовищі, дозволяє використовувати потужні можливості сервера по обробці даних. Я рекомендую використовувати SQL Server Profiler для оцінки продуктивності додатків, а потім робити вибір, грунтуючись на емпіричних результатах тестування. SQL Server Profiler тепер дозволяє профілювати продуктивність CLR-коду, що виконується в SQL Server, зокрема використовується новий графічний формат виводу, дозволяє порівнювати продуктивність.


Тепер розглянемо деякі можливості. NET Framework і те, як вони доповнюють Yukon.


Користувальницькі типи, функції та агрегати


Yukon підтримує розширювану систему типів CLR. Ці типи можна використовувати як частину визначень таблиць на сервері, а на клієнті – для маніпуляцій як об’єктами. Крім того, UDT дозволяють розширювати існуючу систему типів, створюючи нові типи, реалізовані в керованому коді. Прикладами UDT є нестандартні типи фінансових даних, специфічні типи дати / часу і т. д. UDT можна розглядати як контракт між серверним ядром і кодом.


З точки зору. NET, UDT – це структурний або контрольний тип, а не клас чи перечислимого. Це означає, що використання пам’яті буде оптимальним. Однак UDT не підтримують успадкування і поліморфізм. У них можуть бути присутніми як відкриті, так і закриті функції. По суті, такі завдання, як перевірка обмежень, слід вирішувати за допомогою закритих членів класів. Якщо ваш UDT складається з декількох фрагментів інформації, як, наприклад, у випадку географічного типу, що містить довготу, широту і, можливо, висоту, вам буде потрібно визначити закриті поля, що містять ці фрагменти. Після створення UDT можна скористатися T-SQL для реєстрації типу в SQL Server.


UDF бувають двох видів: скалярні і табличні. Скалярний функція повертає єдине значення такого типу, як string, integer або bit, а таблична функція – набір результатів, що містить одну або кілька полів.


Можливість створювати крім вбудованих додаткові агрегатні функції (aggregate functions) не була доступна розробникам, застосовували попередні версії SQL Server. У Yukon розробники можуть створювати власні агрегатні функції в керованому коді і забезпечувати доступ до цих функцій з T-SQL або з іншого керованого коду. Користувальницький агрегат також є. NET-класом, що очікують посилання на збірку, вже доступну в базі даних.


Для перетворення даних, що зберігаються в базі даних, в математичні значення можна використовувати UDAgg (user-defined aggregates). Візьмемо, наприклад, статистичні функції. Припустимо, є якась таблиця, де зберігаються результати збору кількісної інформації. Щоб дізнатися середньозважене значення або середньоквадратичне відхилення цих результатів, ви могли б викликати UDAgg, який обчислює і повертає цю інформацію.


Керовані збережені процедури


Підпрограми керованого коду, що працюють як збережені процедури, найбільш ефективні, коли вам потрібно повернути викликав коду простий набір результатів зі змінами чи просто виконати оператор DML (Data manipulation language) або DDL (data definition language). Після реєстрації на сервері цей код використовується за аналогією з збереженої процедурою.


Щоб обернути метод керованого коду збереженої процедурою, застосовується оператор CREATE PROCEDURE. В CREATE PROCEDURE використовується синтаксис, показаний на прикладі наступного прототипу:


CREATE PROCEDURE mysproc (@username NVARCHAR(4000))
AS
EXTERNAL NAME YukonCLR:[MyNamespace.CLRCode]:: myfunction


XML і Yukon


Насправді історія застосування XML в SQL Server Yukon починається з SQL Server 2000. У тій версії SQL Server була введена можливість повертати реляційні дані як XML, масова завантаження (bulk load), шреддінг XML-документів і доступ до об’єктів баз даних як до Web-сервісів XML. Web Services Toolkit, також відомий як SQLXML 3.0, надає збереженим процедурам можливості Web-сервісів і забезпечує підтримку XML-шаблонів і SQL Server UDF. Але в XML-технології бракувало двох важливих елементів: вбудованого механізму зберігання XML-даних (типу даних XML) і складного мови запитів, що підтримує запити напівструктурованих даних. У Yukon додані ці два елементи, а також деякі вдосконалення Web-сервісів і розширення оператора FOR XML мови T-SQL. Почнемо з основного удосконалення вбудованих типів даних SQL Server – типу даних XML.


Тип даних XML


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


Тип даних XML – повноцінний тип. Він володіє тими ж можливостями, що й інші типи даних SQL Server. Значимість цього важко переоцінити. Як і поле будь-якого іншого типу, XML-поле можна індексувати, накладати обмеження на записи і поля через XSD-схему (хоча задавати XSD-схему необов’язково) і виконувати запити, використовуючи XQuery-вирази, вбудовані в T-SQL. Ці функції додані до W3C-специфікації XQuery. Крім того, за допомогою методу xmldt :: modify користувач може додавати і видаляти піддерева, а також оновлювати скалярні значення.


Тип даних XML дуже гнучкий. При необхідності можна пов’язати з полем XSD-схему (XML Schema Definition). XML-поле, пов’язане з XSD-схемою, вважається універсальна, а XML-поле, не пов’язане з XSD, – нетипізовані. За допомогою XSD-схеми ви можете типізувати XML-поле після імпорту в базу даних. Потім цю схему можна задіяти при створенні індексів та інших метаданих системного каталогу. Типізовані XML-поля при пошуку запитуваної інформації обробляються набагато швидше і гнучкіше, ніж нетипізовані. Тип XML-поля залежить від ситуації, в якій воно використовується, але в більшості програм звичайно потрібно вказувати посилання на XSD-схему.


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


XSD і тип даних XML


Створюючи XML-поле, ви повинні додати XSD-документ і пов’язати його з полем. Зв’язок з XSD-схемою можна задати в SQL Server Workbench або DDL-оператором:


CREATE TABLE T (pk INT, xCol(“mySchema”))


Коли схема імпортується в базу даних, з неї виділяються компоненти різних типів: ELEMENT, ATTRIBUTE, TYPE (для простих або складних типів), ATTRIBUTEGROUP і MODELGROUP. Ці компоненти і всі простори імен, що зв’язуються зі схемою, потім заносяться в різні системні таблиці. Ці компоненти можна побачити в спеціальних системних уявленнях. Іншими словами, схема не зберігається в незмінному вигляді. З цього випливає мінімум два наслідки. По-перше, тег схеми і його атрибути не зберігаються. Замість цього значення атрибутів тега XML-схеми – targetNamespace, attributeFormDefault, elementFormDefault і т. д. – присвоюються компонентів схеми. По-друге, SQL Server не дозволяє після імпорту відновити і переглянути вихідний документ схеми. Рекомендується зберігати копію кожної схеми або поміщати вміст всіх схем в спеціальну таблицю бази даних. Для цього підійде XML-поле. Альтернативний варіант – зчитувати XML-схеми з допомогою вбудованої функції XML_SCHEMA_NAMESPACE (“uri”). Вона повертає вміст простору імен uri.


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


Отже, зі зберіганням даних ми розібралися, тепер перейдемо до XQuery. Без нього моя розповідь була б неповною.


XML Query


XML Query Language, зазвичай званий XQuery, – це “інтелектуальний” і надійний мову, оптимізований для запитів всіх типів XML-даних. За допомогою XQuery можна виконувати запити до змінних і полях типу XML за допомогою методів, пов’язаних з цим типом. При виклику методу запиту допускається запитувати в одному і тому ж пакеті реляційні і XML-дані.


Як і у випадку багатьох інших XML-стандартів, розробка XQuery, в даний час знаходиться в стадії робочого проекту, ведеться під наглядом W3C. Yukon підтримує підмножину XQuery 1.0 Working Drafts, опублікованих в період з 20 грудня 2001 по 15 листопада 2002 р. (див. всі робочі проекти за посиланням www.w3c.org (EN)).


XQuery – результат еволюції мови запитів Quilt, заснованого на ряді інших мов, таких як XPath 1.0, XQL і SQL. Він також включає підмножина XPath 2.0. Ви можете використовувати свої навички роботи з XPath – вивчати абсолютно нову мову не доведеться. Проте в SQL Server Yukon внесені значні вдосконалення, що виходять за рамки XPath, зокрема спеціальні функції і поліпшена підтримка ітерацій, сортування результатів і конструювання.


XQuery-оператори складаються з прологу і тіла. Пролог містить одне або кілька оголошень просторів імен та / або оголошень імпорту схем, що створюють контекст обробки запиту, а тіло – послідовність виразів, які задають критерій запиту. Ці оператори використовуються одним з вищезазначених методів типу даних XML (query, value, exist або modify).


За допомогою XQuery можна запитувати типізовані XML-дані (дані, пов’язані з XML-схемою) і XML-документи.


Microsoft XQuery Designer


XQuery Designer – новий засіб, інтегроване в SQL Server Workbench і полегшує роботу з XML-даними. XQuery Designer допомагає писати запити для вибірки і маніпулювання даними як з XML-полів, так і з XML-документів. Основний мотив розробки XQuery Designer – надати можливість створення XQuery-запитів без освоєння всіх тонкощів XML Query Language. Приклад роботи з XQuery Designer показаний на рис. 1.

Рис. 1. XQuery Designer


До цього моменту я говорив про нову. NET-і XML-функціональності Yukon як про щось роздільному. Поєднання цих технологій відкриває нові можливості у вирішенні прикладних задач в таких популярних областях, як електронна комерція. При розробці для SQL Server основна увага буде приділятися розподіленим додаткам, де бізнес-процеси та бізнес-логіка визначені в програмі, що працює з базою даних. Розглянемо потужну підтримку Web-додатків, вбудовану в Yukon, і заглибимося в нові функціональні можливості, про які я розповім нижче.


SQL Server Service Broker


Останнє десятиліття ознаменувалося бурхливим розвитком додатків електронної комерції, внаслідок чого виникла потреба в більш досконалому управлінні додатками, що працюють з базами даних. Якщо ви розробляли систему введення замовлень або здійснювали онлайнову покупку, то знайомі з моделлю робочого процесу (workflow model). Коли покупець розміщує замовлення на книгу, потрібно зафіксувати транзакцію в системах обліку товарів (inventory), відвантаження (shipping) та операцій з кредитними картами, а потім відправити підтвердження замовлення через інше Web-додаток. Очікування завершення кожного з цих процесів в синхронному режимі негативно позначиться на масштабованості. Раніше розробникам доводилося писати складні збережені процедури і використовувати віддалений виклик процедур для постановки повідомлень в чергу. Yukon надає нову масштабовану архітектуру, яка дозволяє направляти повідомлення асинхронно.


SQL Server Service Broker – технологія Yukon, завдяки якій внутрішні чи зовнішні процеси можуть гарантовано відправляти і приймати асинхронні повідомлення за допомогою розширень звичайного DML-мови T-SQL. Повідомлення можна надсилати в чергу бази даних, яка використовується спільно з відправником, іншій базі даних того ж примірника SQL Server або іншого екземпляра SQL Server, що виконується на тому ж або на віддаленому сервері.


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


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


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


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


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


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


Розглянемо типове додаток обробки замовлень. Повідомлення A з інструкціями щодо створення заголовка замовлення і повідомлення B з інструкціями щодо створення позицій замовлення поміщаються в чергу. Якщо ці два повідомлення витягуються з черги різними екземплярами сервісної програми і обробляються одночасно, може вийти так, що система спочатку спробує зафіксувати транзакцію по позиціях замовлення. Ця спроба потерпить невдачу, оскільки замовлення ще не існує, і, отже, транзакція відкотиться назад. Повідомлення доведеться знову помістити в чергу і обробити, що призведе до марної витрачання ресурсів. Зазвичай цю проблему вирішують, об’єднуючи інформацію з повідомлень А і B в одному повідомленні. У випадку двох повідомлень такий підхід простий, але він погано масштабується, коли доводиться координувати десятки або сотні повідомлень.


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


Одна з найбільш корисних функцій Service Broker – активізація (activation). При використанні активізації сервіс запускаються автоматично і зчитує повідомлення з черги по мірі їх надходження. Якщо повідомлення надходять швидше, ніж обробляються, запускаються додаткові екземпляри сервісу, поки їх число не досягне максимуму, заданого в конфігурації. Якщо інтенсивність надходження повідомлень знизилася і активний екземпляр сервісу, перевіривши чергу, виявляє, що в ній немає повідомлень, які мають обробки, він завершується. Завдяки цьому кількість запущених екземплярів сервісу автоматично збільшується і зменшується відповідно до зміни навантаження на систему. Якщо система зупинена або перезавантажена, після повернення системи в робочий режим екземпляри сервісу автоматично запускаються наново і зчитують повідомлення. Традиційним системам обміну повідомленнями не вистачає такої функціональності, і часто буває, що який-небудь черги в той чи інший момент виділяється занадто багато або занадто мало ресурсів.


Інтеграція з базою даних


Інтегрована архітектура Service Broker забезпечує виграш в продуктивності і зручності адміністрування програми. Інтеграція з SQL Server дозволяє здійснювати транзакційний обмін повідомленнями, тобто кожен робочий цикл сервісу (прийом повідомлення, його обробка і відправлення відповідного повідомлення) можна укласти в одну транзакцію бази даних. Якщо транзакція зазнає невдачі, всі операції відкочуються тому і повідомлення, знову ставиться в чергу, щоб система спробувала обробити його повторно. Поки програма не зафіксує транзакцію, що виконуються операції ні на що не впливають. Додаток залишається в цілісному стані, тому можна обійтися без витрат ресурсів і складнощів координації розподілених транзакцій.


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


Загальна середу розробки також є перевагою. У додатку з підтримкою Service Broker частини, які здійснюють обмін повідомленнями і роботу з даними, можуть бути створені за допомогою одних і тих же мов і коштів. Це дозволяє розробникам використовувати свій досвід програмування баз даних при створенні додатків, які обмінюються повідомленнями. Збережені процедури, що реалізують сервіс Service Broker, можна писати на T-SQL або на одному з CLR-сумісних мов.


Завдяки інтеграції з базою даних стає можливим автоматичне керування ресурсами. Service Broker виконується в контексті примірника SQL Server, тому брокер може отримати сукупне уявлення всіх готових до передачі повідомлень від всіх баз даних примірника. Завдяки цьому кожна база даних може підтримувати власні черзі, при цьому збережеться рівноправний доступ до ресурсів примірника SQL Server в цілому.


Приклад програмування для SQL Server Yukon


Подивимося, як всі ці концепції застосовуються при розробці програми введення замовлень, що розміщуються клієнтами на Web-сайті. Повідомлення, якими обмінюються сервіси, зберігаються в XML-поле. В ілюстративних цілях я скористаюся Web-сервісом ASP.NET, який реєструється і виконується в примірнику CLR, хостом для якого служить SQL Server. Щоб відправляти й одержувати інформацію про замовлення на купівлю товару, цей сервіс взаємодіє з іншими сервісами. Застосування XML-поля для зберігання повідомлень дозволяє інкапсулювати схему і спростити обробку даних.


Клієнт розміщує замовлення на Web-сайті. Коли транзакція замовлення фіксується, повідомлення з інформацією про замовлення поміщається в чергу Order Entry Service. Замовлення відправляється сервісу Order Entry Service як XML-поле. Завдяки цьому вся інформація про замовлення об’єднується в одному полі. Повністю процес введення замовлень зображений на рис. 2.

Рис. 2. Додаток Order Entry Service


Order Entry Service починає транзакцію, приймає повідомлення і обробляє його. Потім він відправляє запит сервісу Credit Limit Service, щоб перевірити платоспроможність клієнта. Якщо все в порядку, Order Entry Service переходить до наступного етапу.


Order Entry Service перевіряє наявність товару по кожній позиції замовлення. Перевірка виконується за допомогою XQuery-запиту. У цей момент, якщо товар по цій позиції можна відвантажувати, відправляється повідомлення в чергу Shipping Service.


Shipping Service – це процедура, що зберігається T-SQL, що використовує XQuery для аналізу XML-повідомлення. Для генерації даних з відвантаження замовлення використовується інформація, отримана від клієнта. Коли відвантаження завершена, відправляється повідомлення в Order Entry Service. Отримавши повідомлення “відвантаження виконана”, Order Entry Service оновлює інформацію про стан замовлення в базі даних, щоб вказати, що замовлення доставлений. Всі повідомлення, що приймаються і відправляються Order Entry Service, записуються в таблицю аудиту для подальшого аналізу та усунення проблем.


Цей простий приклад показує, як використовувати нові можливості програмування Yukon – XML, CLR, Service Broker і розширений T-SQL – при розробці надійних, масштабованих і повнофункціональних додатків, працюють з базами даних.


Висновок


Я торкнувся лише деякі з захоплюючих нововведень в архітектурі Yukon. У розробників баз даних ніколи не було такого широкого вибору способів доступу до даних і зберігання інформації. Приклад використання SQL Server Service Broker показує тільки частину нових можливостей SQL Server. Приступайте до роботи з бета-версією SQL Server Yukon і продовжуйте стежити за його освітленням в MSDN Magazine. Ще до того, як ви дізнаєтеся все нові можливості Yukon, ви будете застосовувати його без оглядки на минуле.

Додаткова інформація



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


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

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

Ваш отзыв

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

*

*